Boris Cherny’s advice to Claude Code users is to stop telling the agent exactly how to do every step of a task. At Y Combinator’s Startup School on July 25, Anthropic’s head of Claude Code argued that newer models are often being held back by users who turn a goal into a rigid sequence of instructions, according to Business Insider, whose report was republished by AOL. His prescription was simple: state the desired outcome, define guardrails and success criteria, then give the model room to work.
The practical takeaway for developers and IT teams is more demanding than “use shorter prompts.” Replace procedural prompting with testable delegation. A coding agent should have a clear objective, relevant repository and environment context, constraints it must not violate, and an unambiguous way to prove it succeeded. It should not receive a hand-written imitation of the agent’s own planning loop.
Y Combinator’s Startup School materials confirm Cherny was a featured speaker at the July 25–26 event in San Francisco. Other accounts of the session describe the same central message: make the model attempt work that seems beyond its assumed limits, observe where it fails, and add instructions, tools, or context only in response to a demonstrated failure.
That is a meaningful shift from the prompt engineering playbook many teams built around earlier chat models. But it also comes with a boundary Cherny’s slogan can obscure: fewer instructions about method do not mean fewer controls over access, validation, and deployment.
Anthropic’s public Claude Code guidance does not actually endorse vague requests followed by blind trust. Its documentation says the agent can inspect files, run commands, change code, and work autonomously; it also recommends giving it a way to verify its work, providing project-specific context, configuring permissions, and course-correcting early.
That is the important distinction in Cherny’s advice. The instructions to remove are the unnecessary how-to directions: “open this file, make these three edits in this order, then use this exact implementation pattern.” The instructions to keep are the durable facts a competent new engineer would need:
Anthropic’s older Claude Code best-practices material also recommends project-level
The better rule is: retain instructions that describe the organization and its systems; remove instructions that merely compensate for limitations the current model no longer has.
For a Windows administrator or platform engineer, the difference is immediate. Asking an agent to “modernize the PowerShell deployment module, preserve existing parameters, add Pester coverage, and provide a dry-run report” is appropriate outcome-based delegation. Asking it to make arbitrary production changes under a domain-admin token because it has passed a few repository tests is not.
The security model has to remain outside the model’s discretion. An agent may be free to choose its implementation path inside an isolated branch, disposable virtual machine, Windows Sandbox instance, or restricted CI runner. It should still encounter a hard stop before it can:
The distinction becomes especially important when agents can browse documentation, query issue trackers, read build logs, or use MCP-connected tools. Every additional source of context can improve the agent’s work, but it can also expose the system to malicious instructions embedded in files, tickets, webpages, or logs. Anthropic itself warns that a model can fail to follow prompted rules under pressure, during long sessions, in ambiguous situations, or when it encounters prompt injection in material it reads.
A concise task brief is not a security boundary.
An organization can do this without turning its development process into a public experiment. Start with a bounded task that has known acceptance criteria: refactor a component without changing behavior, update a dependency and repair failing tests, explain a recurring build failure, or add coverage for a previously reproduced bug. Give the agent access to the same tests and static-analysis tools a developer would use. Then compare the output against a human-reviewed baseline.
If the agent succeeds, remove a piece of redundant process prompting on the next run. If it fails, diagnose why before adding another rule. Was the failure caused by missing context? An absent test harness? A poor specification? Insufficient permissions in a safe environment? A model limitation? Or did a project instruction genuinely need to remain?
That empirical approach is more useful than endlessly expanding a
Anthropic’s documentation flags context-window pressure as a practical limitation for Claude Code sessions. That reinforces the case against indiscriminately stuffing prompts with process detail. A long-running debugging or codebase-exploration session accumulates messages, file contents, and command output. Adding obsolete rules does not merely make the prompt untidy; it can compete with the repository details the agent actually needs to reason about the current problem.
That matters because “give the model freedom” produces very different outcomes across tasks. An agent may perform well when it can inspect a self-contained codebase, run deterministic tests, and iterate in a branch. It may perform poorly when requirements are ambiguous, validation is weak, critical knowledge lives only in people’s heads, or the work crosses identity systems, financial controls, regulated data, and production infrastructure.
Andrew Ng made a related case in 2025 for what he called “lazy prompting”: start with minimal direction and add detail only when necessary. But Ng also described it as an advanced practice best suited to cases where the model has enough existing context and the user can iterate rapidly. Cherny’s advice has the same precondition, even if the “let it cook” formulation is more memorable.
The operational lesson is not to abandon prompting discipline. It is to spend that discipline on the parts humans uniquely own: defining the objective, supplying missing organizational context, constraining authority, and checking the result.
The agent should own the route; the team must own the destination and the release gate.
Y Combinator’s Startup School materials confirm Cherny was a featured speaker at the July 25–26 event in San Francisco. Other accounts of the session describe the same central message: make the model attempt work that seems beyond its assumed limits, observe where it fails, and add instructions, tools, or context only in response to a demonstrated failure.
That is a meaningful shift from the prompt engineering playbook many teams built around earlier chat models. But it also comes with a boundary Cherny’s slogan can obscure: fewer instructions about method do not mean fewer controls over access, validation, and deployment.
Claude Code’s own documentation still calls for context and verification
Anthropic’s public Claude Code guidance does not actually endorse vague requests followed by blind trust. Its documentation says the agent can inspect files, run commands, change code, and work autonomously; it also recommends giving it a way to verify its work, providing project-specific context, configuring permissions, and course-correcting early.That is the important distinction in Cherny’s advice. The instructions to remove are the unnecessary how-to directions: “open this file, make these three edits in this order, then use this exact implementation pattern.” The instructions to keep are the durable facts a competent new engineer would need:
- The service must preserve a documented API contract and remain compatible with Windows Server 2022 deployment.
- The change must not alter authentication, write outside the repository, rotate secrets, or modify production infrastructure.
- The work is complete only when the unit tests, integration tests, linter, build, and security checks pass.
- The agent must produce a patch, test evidence, and a concise explanation of any design tradeoffs or unresolved failures.
Anthropic’s older Claude Code best-practices material also recommends project-level
CLAUDE.md files. That may appear to conflict with Cherny’s newer push to strip away accumulated prompting scaffolding. It does not, if teams treat such files as living operational documentation rather than a graveyard of workaround instructions written for a previous model generation.The better rule is: retain instructions that describe the organization and its systems; remove instructions that merely compensate for limitations the current model no longer has.
“Let it cook” is not permission to let it deploy
Cherny’s framing is aimed at the planning and execution loop, where models can waste time obeying an overly constrained sequence that is less efficient than their own approach. It should not be read as advice to disable approvals or give an agent unrestricted credentials.For a Windows administrator or platform engineer, the difference is immediate. Asking an agent to “modernize the PowerShell deployment module, preserve existing parameters, add Pester coverage, and provide a dry-run report” is appropriate outcome-based delegation. Asking it to make arbitrary production changes under a domain-admin token because it has passed a few repository tests is not.
The security model has to remain outside the model’s discretion. An agent may be free to choose its implementation path inside an isolated branch, disposable virtual machine, Windows Sandbox instance, or restricted CI runner. It should still encounter a hard stop before it can:
- Change Azure AD or Active Directory permissions.
- Create or rotate production secrets.
- Modify firewall, endpoint security, or Group Policy settings.
- Run destructive PowerShell commands against shared infrastructure.
- Merge code, publish packages, or deploy to production without a human or deterministic release gate.
The distinction becomes especially important when agents can browse documentation, query issue trackers, read build logs, or use MCP-connected tools. Every additional source of context can improve the agent’s work, but it can also expose the system to malicious instructions embedded in files, tickets, webpages, or logs. Anthropic itself warns that a model can fail to follow prompted rules under pressure, during long sessions, in ambiguous situations, or when it encounters prompt injection in material it reads.
A concise task brief is not a security boundary.
The real test is whether the agent can verify the result
The strongest part of Cherny’s argument is not the call for brevity. It is the implied demand that users test their assumptions about model capability rather than carry forward habits formed around older models.An organization can do this without turning its development process into a public experiment. Start with a bounded task that has known acceptance criteria: refactor a component without changing behavior, update a dependency and repair failing tests, explain a recurring build failure, or add coverage for a previously reproduced bug. Give the agent access to the same tests and static-analysis tools a developer would use. Then compare the output against a human-reviewed baseline.
If the agent succeeds, remove a piece of redundant process prompting on the next run. If it fails, diagnose why before adding another rule. Was the failure caused by missing context? An absent test harness? A poor specification? Insufficient permissions in a safe environment? A model limitation? Or did a project instruction genuinely need to remain?
That empirical approach is more useful than endlessly expanding a
CLAUDE.md file after every bad run. Over time, large instruction files can create their own failure mode: conflicting directions consume context, obscure the task, and force an agent to spend attention following rituals rather than understanding the system.Anthropic’s documentation flags context-window pressure as a practical limitation for Claude Code sessions. That reinforces the case against indiscriminately stuffing prompts with process detail. A long-running debugging or codebase-exploration session accumulates messages, file contents, and command output. Adding obsolete rules does not merely make the prompt untidy; it can compete with the repository details the agent actually needs to reason about the current problem.
The missing evidence behind the broad claim
There is one significant limitation in the reporting around Cherny’s comments. Business Insider did not identify a specific Claude model, task category, evaluation method, failure rate, or benchmark supporting the claim that users are broadly underestimating what modern models can do. The article reports Cherny’s view and quotes his recommended prompting pattern, but it does not establish where autonomy improves results versus where it increases rework.That matters because “give the model freedom” produces very different outcomes across tasks. An agent may perform well when it can inspect a self-contained codebase, run deterministic tests, and iterate in a branch. It may perform poorly when requirements are ambiguous, validation is weak, critical knowledge lives only in people’s heads, or the work crosses identity systems, financial controls, regulated data, and production infrastructure.
Andrew Ng made a related case in 2025 for what he called “lazy prompting”: start with minimal direction and add detail only when necessary. But Ng also described it as an advanced practice best suited to cases where the model has enough existing context and the user can iterate rapidly. Cherny’s advice has the same precondition, even if the “let it cook” formulation is more memorable.
The operational lesson is not to abandon prompting discipline. It is to spend that discipline on the parts humans uniquely own: defining the objective, supplying missing organizational context, constraining authority, and checking the result.
The agent should own the route; the team must own the destination and the release gate.
References
- Primary source: aol.com
Published: 2026-07-27T22:08:02+00:00
Loading…
www.aol.com - Related coverage: code.claude.com
Loading…
code.claude.com - Related coverage: support.claude.com
Claude Code power user tips | Claude Help Center
support.claude.com
- Related coverage: anthropic.com
Best practices for Claude Code - Claude Code Docs
Tips and patterns for getting the most out of Claude Code, from configuring your environment to scaling across parallel sessions.www.anthropic.com - Related coverage: claude.com
Loading…
claude.com - Related coverage: code.claude.com
Loading…
code.claude.com - Related coverage: tech.yahoo.com
Loading…
tech.yahoo.com - Related coverage: platform.claude.com
Loading…
platform.claude.com - Related coverage: support.anthropic.com
Loading…
support.anthropic.com - Related coverage: fortune.com
The head of Claude Code hasn't 'written a line of code by hand' in 8 months | Fortune
Boris Cherny was asked at Brainstorm Tech if he was concerned about the rapid progress of AI: "Yes."fortune.com
- Related coverage: platform.claude.com
Loading…
platform.claude.com - Related coverage: claude.com
Loading…
claude.com - Related coverage: resources.anthropic.com
- Related coverage: www-cdn.anthropic.com
- Related coverage: assets.anthropic.com
Loading…
assets.anthropic.com - Related coverage: resources.anthropic.com
Loading…
resources.anthropic.com - Related coverage: tomsguide.com
Loading…
www.tomsguide.com - Related coverage: techradar.com
Anthropic gives Claude Code new 'auto mode' which lets it choose its own permissions | TechRadar
Claude Code gets new auto mode, in research previewwww.techradar.com - Related coverage: tomsguide.com
Loading…
www.tomsguide.com - Related coverage: tech.yahoo.com
Loading…
tech.yahoo.com - Related coverage: startuphub.ai
Loading…
www.startuphub.ai - Related coverage: anthropic.com
Loading…
www.anthropic.com - Related coverage: alignment.anthropic.com
Loading…
alignment.anthropic.com - Related coverage: alignment.anthropic.com
Loading…
alignment.anthropic.com