The short answer
Use coding agents for bounded changes to a codebase you can review. Set the intended behavior and checks before implementation, then inspect the results and diff before merging. An engineering founder reports that 52% of his team’s merged pull requests last month were automated through a workflow that returns verification evidence to engineers.1 A coding-workflow creator reports pretty equivalent results when splitting planning, implementation and review across models; on complicated tasks, using the stronger model for everything cost more than twice as much.2
What founders did
6 real examples, each linked to the moment in the source. Results are self-reported.
- X
Darko Fabijan
Reports that 52% of pull requests his team merged last month were automated through SuperPlane.
Described selecting suitable backlog tickets, verifying agent work through CI and review feedback, and leaving shipping to engineers.
- YouTube
Cole Medin
Reports pretty equivalent results; the stronger model doing everything cost more than twice as much on complicated tasks.
Compared a stronger model doing all coding work with using it for planning and review while another model implemented.
- X
Arvid Kahl
Reports far fewer corrections after delegating those edits.
Delegated seemingly innocuous edits after encountering unintended effects from manual changes.
- X
Hiten Shah
Proposed comparing original requests with implemented behavior to surface unspecified user-facing choices without editing code.
- YouTube
Zen van Riel
Set up parallel coding-agent windows while limiting concurrent work to what he could track.
- YouTube
The Gray Cat
Reports that the browser checks often try overlooked edge cases and that the added checks increased confidence in what they ship.
The creator describes reusable project checks, browser testing for web work, and a table recording check outcomes.
Your playbook
Use this when
Use this if you can review code in an existing project and have a feature or fix to implement.
You’ll leave with
Build a change worksheet containing scope, approved behavior, checks, observed results and a merge decision.
Bound the change before opening the agent
- Do
Choose a feature or fix. Start the change worksheet with intended behavior, the relevant code, what must remain unchanged, and product or architecture choices you will make. Ask the agent to flag missing information before editing.
- Make
Add a bounded change request and reserved decisions to the worksheet.
- Check
If you cannot describe the behavior or resolve a consequential choice, clarify the request before allowing edits.
Why this step is in the plan
Arvid Kahl reports fewer corrections after delegating small edits that had previously caused unintended effects, including responsive-layout breakage.3 The AI Master creator contrasts a vague dark-mode request with a hypothetical prompt specifying existing CSS variables, toggle placement, persistence and files to leave alone.7
Approve the plan and checks
- Do
Request a read-only plan naming the approach, affected files and checks. Add expected behavior and a failure or edge case to the worksheet. Review the plan and checks before authorizing implementation.
- Make
Add an approved approach and observable acceptance checks to the worksheet.
- Check
If the checks could pass while the feature is wrong, revise them before implementation.
Why this step is in the plan
The Learn Code With Durgesh creator describes putting features, user roles and business requirements in a PRD while retaining personal judgment over its contents.8 In an AI LABS demo, feature requirements become eval files; the creator says a person should review those checks before the agent builds.9
Implement a reviewable slice
- Do
Create a Git checkpoint and give the agent the approved plan and relevant project instructions. Request only the bounded change. Record the resulting diff and unresolved decisions in the worksheet.
- Make
Add a reviewable diff linked to the approved scope.
- Check
If the diff expands into unapproved behavior or architecture, pause and reapprove the scope.
Why this step is in the plan
Cole Medin tested using a stronger model for planning and review while another implemented. He reports pretty equivalent results to using the stronger model throughout, with lower cost on complicated tasks.2 Zen van Riel describes parallel agent windows but says his own capacity limits how many work streams he can track.5
Collect behavioral evidence
- Do
Have the agent run the approved tests and relevant build checks. Inspect the behavior yourself in the appropriate interface. Add commands, observed results, failures and retests to the worksheet.
- Make
Add a check record comparing expected and observed behavior.
- Check
If a check fails or behavior differs, request a targeted fix and rerun the check before proceeding.
Why this step is in the plan
Audit choices and decide whether to merge
- Do
Review the diff and check record. Ask the agent to identify consequential choices absent from your original request without making edits. Record your decision on each choice, then merge, request a revision or stop.
- Make
Add a merge decision and accepted or rejected choices to the worksheet.
- Check
Do not merge if you cannot explain a consequential change, unexpected diff or failed check.
Why this step is in the plan
Hiten Shah proposes comparing the original requests with the implementation to expose unspecified user-facing choices, without letting the agent edit during that audit.4 Darko Fabijan reports that his team’s automated workflow returns evidence to engineers, who decide what ships.1
Move a coding-agent change from request to merge
- Change state
The request is vague
Your next moveDefine behavior and boundaries before allowing edits
Continue only ifContinue when the intended behavior is clear and consequential choices have an owner.
- Change state
The plan is ready
Your next moveApprove the approach and checks
Continue only ifContinue when an incorrect implementation would fail a proposed check.
- Change state
The agent has changed code
Your next moveRun checks and inspect behavior and the diff
Continue only ifRequest a revision if behavior differs from the worksheet or unrelated changes appear.
- Change state
The change appears ready
Your next moveMake the merge decision yourself
Continue only ifMerge only when the evidence is visible and you understand the consequential choices.
Where to spend attention
Keep business rules, architecture and customer-facing choices under direct review; delegate bounded implementation.
Whether to add agents
Try parallel tasks or a model split only when each change remains independently testable and reviewable.
Make it yoursChange worksheet
A fill-in template for your own test
Change: [specific behavior] Affected area: [files or components] Keep unchanged: [behavior or files] Decisions for me: [product or architecture choices] Passing behavior: [observable result] Failure case: [input and expected result] Evidence: [test output, build result or interface check] Diff review: [unexpected changes] Decision: [merge, revise or stop]
When this works
- Favor this workflow when you can specify the change, test it in the real project and review its diff before merging.
When to avoid
- Do not delegate an unresolved product decision or critical code you cannot assess. Work through the design before requesting implementation.
Related questions
Should I run several coding agents at once?
Zen van Riel describes four parallel work streams as his personal capacity, not a target for other teams.5 Parallelize independent changes only if you can still review each one.
Do I need a more expensive coding-agent plan?
AICodeKing suggests starting with Claude Code’s Pro plan while gauging usage and considering an upgrade when its limits regularly interrupt useful work.10 Base a capacity upgrade on actual interruptions, not on an expectation of better code.
What belongs in a coding agent’s project instructions?
A guest in Y Combinator’s video describes keeping team engineering practices in Claude MD and skills files.11 Keep stable project conventions in those instructions and change-specific acceptance checks in the worksheet.
