Claude for Development
Working with Claude
Repo facts, intent, constraints, and a verification path.
Juan M. Cornejo
Notes, no. 10
Repo facts, intent, constraints, and a verification path. Phrases for pairing, planning, debugging, refactoring, and reviewing without thrash.
1Claude for Development
Part 01
Underspecified requests get plausible-but-wrong code. State these and you'll get code that fits your repo.
Underspecified requests get plausible-but-wrong code. State these and you'll get code that fits your repo.
What "done" looks like. Concrete criteria let Claude self-check instead of guessing scope.
page, limit, total and has tests.Language, framework, and versions. Prevents APIs from the wrong era or ecosystem.
Point at how the codebase already does things so new code matches, not fights, the patterns.
/services, match its error handling and naming.No new deps, must stay backward-compatible, performance budget, security rules.
Say what NOT to touch. Stops well-meaning refactors that balloon the diff.
Part 02
Lead with the verb that matches the help you want.
Lead with the verb that matches the help you want.
Write new code to a spec. Strongest with acceptance criteria and conventions attached.
Ask for an approach before code on anything non-trivial. Cheaper to correct a plan than a diff.
Improve structure without changing behavior. Name the goal: readability, performance, testability.
Find and fix a defect. Give the symptom, the trace, and how to reproduce.
Evaluate a diff or file for bugs, security, and style. Ask for severity-ranked findings.
Understand existing code. Great for onboarding to an unfamiliar repo.
Improve a measurable metric, name it (latency, memory, bundle size) and the target.
Generate tests for behavior, edge cases, and regressions. Name the framework.
Part 03
The single biggest lever for code quality. Claude reasons over what you show it, show the right things.
The single biggest lever for code quality. Claude reasons over what you show it, show the right things.
Full stack trace, not a paraphrase. The exact line and message carry most of the signal.
Give the actual code that matters, plus its callers. Don't make Claude guess interfaces.
A directory tree orients Claude on where things live and where new code belongs.
Exact input → expected vs actual output. Turns "it's broken" into a solvable problem.
When it has file access, let it read the code itself instead of you pasting everything.
A persistent file of project rules (commands, style, gotchas) Claude loads every session.
pnpm test before claiming done.Part 04
Precise engineering terms collapse a paragraph into a word Claude already understands.
Precise engineering terms collapse a paragraph into a word Claude already understands.
Pull code into its own function/module (extract) or fold it back (inline).
No side effects, same input → same output. Ask for these where you want testability.
Running it twice has the same effect as once. Key for retries and APIs.
Remove duplication; one canonical definition. Use when copy-paste has crept in.
The boundary inputs: empty, null, huge, concurrent, malformed. Always ask for them.
A bug from unpredictable ordering of concurrent ops. Name it when timing is suspect.
No any, exhaustive checks, narrowed types. Ask for it explicitly.
any, handle every case.Existing callers keep working. Critical when touching shared APIs.
A clean boundary hiding implementation. Ask Claude to define one before coupling things.
Part 05
When Claude can run commands and edit files, these moves keep it on the rails.
Tasks moving to done. The agent is a chip on the card it works on, and the waiting column asks for a person. The board is drawn with invented tasks.
When Claude can run commands and edit files, these moves keep it on the rails.
Have Claude propose a plan you approve before it starts changing files.
Incremental changes you can review beat one giant diff you can't.
Tell Claude to verify its own work by running the suite before declaring done.
TDD, capture the bug or spec as a red test, then make it green.
Fence off files or areas so the agent stays scoped.
Delegate parallel or exploratory work (searching, verifying) to a separate agent.
Part 06
Name the lens and Claude reviews like a specialist instead of skimming.
One change under review: a four-line diff, the file count, and the decision left to a person. The panel is drawn with an invented change.
Name the lens and Claude reviews like a specialist instead of skimming.
Does it actually do the thing for all inputs, including the nasty ones?
Injection, authz, secrets, unsafe input. Ask for an explicit security pass.
Hot paths, N+1 queries, unnecessary allocations, big-O.
Naming, structure, comments where the "why" isn't obvious.
What's untested, especially branches and failure modes.
Coupling, hidden state, things that'll bite in six months.
Part 07
A structured ask gets a root cause, not a shot in the dark.
A structured ask gets a root cause, not a shot in the dark.
Ask for the underlying cause, not just a patch that hides the symptom.
When the cause is unclear, have Claude add targeted logs to narrow it down.
Ask for ranked possible causes before fixing, keeps debugging systematic.
Narrow down when it broke (commits) or where (binary search the code path).
Reduce to the smallest case that still fails, often reveals the cause itself.
After a fix, lock it in with a test so the bug can't return.
Elsewhere
Claude for Design