On this page#
- How we judged them
- The shortlist
- What we rejected and why
- The one nobody talks about
- Choosing by repo shape
- FAQ
How we judged them#
A Claude Code best practice is valuable only if it improves the resulting diff: smaller scope, preserved invariants, reviewable intent, and evidence that the change works. Convenience does not count if the agent produces a broad patch that reviewers cannot confidently explain, test, or reverse.
Claude Code is an agentic coding tool that can inspect a codebase, edit files, and use development tools. That power makes the diff—not the quality of the conversation—the correct unit of evaluation.
We judge every practice against five questions:
- Did it reduce unnecessary change? A good patch touches the smallest coherent surface.
- Did it preserve repository invariants? Architecture, public APIs, compatibility rules, and security boundaries outrank local elegance.
- Can a reviewer reconstruct the intent? A diff should communicate why each changed line belongs.
- Did verification target the actual risk? Passing an unrelated test suite is weak evidence.
- Is failure recoverable? Smaller commits and explicit checkpoints make bad assumptions cheaper to remove.
This standard exposes a common mistake: optimizing prompts for impressive output. A polished explanation can accompany a terrible patch. The official overview describes what Claude Code can do; your engineering process must decide what it is allowed to change.
The practical rule is simple: never accept “the task is complete” as evidence. Read the diff, trace it back to the requested behavior, and verify the repository’s invariants yourself.
Photo by mali maeder on Pexels.
The shortlist#
The strongest practices constrain the agent before generation, then make the result easy to inspect. None is universally correct. Choose the smallest control that addresses the failure mode in front of you; piling every control onto every task creates ceremony without improving the patch.
| Practice | Best for | When not to use it | |---|---|---| | State invariants before the task | Mature repositories with compatibility, security, or architectural boundaries | Tiny, isolated edits where the invariant is already mechanically enforced | | Ask for a plan before edits | Cross-module changes, migrations, unfamiliar ownership boundaries | Obvious one-file fixes where planning would only restate the request | | Give a narrow change budget | Bug fixes and maintenance work prone to opportunistic refactoring | Deliberate redesigns whose purpose is to change several connected surfaces | | Require diff-based self-review | Any patch large enough to hide accidental edits | Generated or mechanical changes whose source is reviewed elsewhere | | Specify risk-matched verification | Behavior changes, regressions, boundary conditions | Documentation-only edits with no executable behavior | | Split discovery from implementation | Ambiguous bugs or repositories with weak internal documentation | Tasks whose location and expected behavior are already known |
“Invariants” means conditions the patch must not violate, even if another implementation looks cleaner. Useful invariants are concrete: keep the public interface unchanged, preserve error semantics, do not add dependencies, or modify only the named subsystem.
A change budget is equally concrete. Name the files, modules, or categories of change that are permitted. Claude Code can navigate and act across a repository, as its official documentation explains, but capability is not authorization.
For higher-risk work, use this sequence:
- Ask the agent to locate the behavior and identify affected invariants.
- Review its proposed change surface.
- Authorize implementation with explicit exclusions.
- Inspect the diff before accepting its summary.
- Run verification aimed at the failure being fixed.
If you want packaged workflows instead of assembling these controls yourself, PairFoundry tools are the direct next step. The point of a workflow is not more prompting; it is repeatable control over what reaches the diff.
What we rejected and why#
We rejected practices that optimize agent activity rather than reviewer confidence. The worst advice sounds productive—bigger prompts, longer autonomous runs, and exhaustive instruction files—but often increases the distance between the requested change and the patch that must be owned afterward.
The giant permanent instruction file is not a substitute for task-specific constraints. Repository guidance should contain stable truths, not every preference anyone has ever expressed. When critical invariants are buried among style notes, the file becomes background noise.
The one-shot mega-prompt is also wrong for uncertain work. Combining discovery, architectural judgment, implementation, cleanup, and verification into one instruction prevents you from correcting a bad model of the repository before it becomes code.
“Keep going until all tests pass” is unsafe as a blanket rule. Tests can fail for unrelated reasons, and an agent can widen the patch to satisfy the suite rather than preserve the requested behavior. The Claude Code overview establishes the tool’s broad coding capabilities; it does not make every repository action appropriate.
We also reject three familiar shortcuts:
- Accepting a clean test run without reading the diff. Tests rarely encode every architectural or product invariant.
- Requesting refactoring during a bug fix by default. It mixes behavioral correction with structural change and makes regression analysis harder.
- Treating the agent’s summary as a change log. The summary is a claim; the diff is the artifact.
For engineers still building the underlying habits, the free PairFoundry foundations track is a better next step than adding more elaborate prompts.
Photo by Jakub Zerdzicki on Pexels.
The one nobody talks about#
The underrated practice is asking the agent to produce a deletion case before implementation: what should remain untouched, which plausible changes are unnecessary, and what it would remove from its own plan. This forces scope discrimination before code generation and gives reviewers an explicit boundary to enforce.
A normal plan lists actions, so it naturally grows. A deletion case does the opposite. It distinguishes required work from attractive cleanup, speculative abstractions, and defensive changes unsupported by the task.
Use three prompts:
- What is the smallest coherent change that satisfies the request?
- Which nearby improvements are deliberately excluded?
- What evidence would prove that another file must be touched?
The third question matters most. It turns scope expansion into a claim requiring evidence rather than an automatic consequence of exploration.
This practice complements the documented capabilities of Claude Code without pretending the tool can infer your organization’s acceptance boundary. Official documentation can explain operation and features; it cannot know which unchanged behavior your team considers contractual.
The deletion case is especially useful when the agent proposes a new abstraction. Ask what duplication or invariant requires that abstraction now. If the answer is merely that it may help later, reject it. Future flexibility is not free when it enlarges today’s review surface.
For reusable patterns at different levels of intervention, PairFoundry packs provides the overview. Choose based on the control your repository lacks, not on how sophisticated the workflow appears.
Choosing by repo shape#
Choose practices according to where the repository stores truth. A monorepo, a library, a legacy service, and a generated-code project fail differently. There is no single “best” setup; there is a correct control surface for each repository shape.
| Repository shape | Prioritize | Main failure to prevent | |---|---|---| | Large monorepo | Ownership boundaries, narrow search scope, targeted verification | Unrelated cross-package edits | | Public library | API invariants, compatibility constraints, explicit exclusions | Accidental contract changes | | Legacy service | Discovery before implementation, characterization of current behavior | “Cleaning up” behavior consumers rely on | | Fast-moving application | Small change budgets, risk-matched tests, short review cycles | Large patches becoming stale or conflicted | | Generated-code repository | Source-of-truth identification, generator verification | Editing outputs that will be overwritten | | Security-sensitive codebase | Explicit trust boundaries, human approval points, minimal diffs | Locally correct changes weakening system guarantees |
In a monorepo, tell the agent where authority ends. In a public library, define the observable contract before discussing implementation. In a legacy service, do not ask for elegance first; ask what current behavior must be preserved.
Generated code needs a harder boundary: identify whether the requested artifact is source or output before permitting edits. Security-sensitive work needs the smallest diff and the strongest human review, regardless of how convincing the agent’s reasoning sounds.
The broader PairFoundry landscape helps place these workflows among other approaches. The durable rule remains local: match the process to the repository’s failure mode, then judge the process by the diff it produces.
Photo by Daniil Komov on Pexels.
Related reading#
- Effective context engineering for AI agents: what each one is genuinely good at
- AI coding tools: a short list, with the reasons we rejected the rest
FAQ#
What is the best practice to use the Claude code?#
Start by stating the repository invariants and the permitted change surface, then review the resulting diff against both. For uncertain or cross-module work, require discovery and a plan before edits. Do not treat successful execution or the agent’s completion summary as proof that the patch is acceptable.
What are the best skills for Claude code?#
The most valuable skills are repository navigation, scope control, invariant identification, diff review, and risk-matched verification. Language-specific knowledge helps, but it does not compensate for changing the wrong surface. A coding agent becomes safer when it can explain what must remain unchanged as clearly as what it intends to edit.
How is Claude code so good at coding?#
Claude Code combines language-model reasoning with the ability to inspect code, edit files, and use development tools, as described in the official overview. That makes it effective at connected coding tasks. It does not eliminate the need for repository-specific constraints or human ownership of the final diff.
What is the best mode for coding on Claude?#
Use a staged mode for consequential changes: inspect, plan, authorize, implement, and review. Direct editing is appropriate for small, obvious, reversible tasks. The deciding factor is not task prestige or line count; it is whether a wrong assumption could spread across boundaries before you notice it.
What do most people use the Claude Code for?#
Claude Code is suited to understanding codebases, implementing changes, fixing defects, refactoring, and supporting development workflows. The better question is which tasks your repository can safely delegate. Start with bounded, reviewable work, then expand only when your constraints and verification reliably produce diffs your team can own.