Agentic Coding Workflows That Actually Ship

The quality of an agent run is usually decided before any code is generated. Give it a vague outcome such as improve the booking module and it has to invent the scope, the risk tolerance, and the definition of done. The result may look tidy while changing behavior nobody asked it to touch.

A task becomes workable when the boundary is visible: add idempotency to this endpoint, preserve the current response contract, do not change the schema, and verify the duplicate-request path. That is enough room for implementation judgment without quietly delegating product or architecture decisions.

I also point the agent toward the part of the repository that carries the real conventions. A route file alone rarely tells the whole story. The related service, validation schema, error mapper, and nearest integration test are often more useful than another paragraph of prompting.

My first checkpoint is not a diff. It is a short account of what the agent found: where the behavior lives, which callers depend on it, what existing pattern is closest, and what remains unclear. If that account is wrong, correcting it is cheaper than reviewing a confident patch built on the wrong mental model.

This matters in backend work because the visible handler is often the least interesting part. Authorization may be middleware, transaction ownership may sit in a service, and retry behavior may be controlled by a worker. Reading only the file named in the task produces code that works locally and breaks the surrounding contract.

The first pass is behavioral. I check authorization, validation, state transitions, retry safety, database boundaries, and the response seen by existing clients. The second pass is maintenance: does the change use local abstractions, can another engineer debug it from the logs, and did it add a second way to solve a problem the repository already solved once?

Green tests are evidence, not approval. Generated tests can repeat the implementation's assumptions and still miss the business rule. For a payment-adjacent change, I want to see duplicate submission, timeout after an external side effect, and replay after a worker crash. Those scenarios say more than a coverage percentage.

Large diffs get split for the same reason large human-written diffs do: review quality falls as unrelated decisions accumulate. If a small feature suddenly needs a broad refactor, I stop and make the refactor a separate decision.

I use agents freely for repository discovery, test matrices, repetitive migrations, type tightening, and small changes inside an established pattern. I raise the review bar around permissions, money, booking state, public contracts, and destructive data operations. In those areas the agent can map the terrain, but a person must own the invariants.

The handoff should be boring: files changed, behavior changed, checks run, assumptions made, and remaining risk. That record lets the reviewer evaluate the reasoning instead of reverse-engineering it from the patch.

The practical goal is not maximum generated code. It is less time spent on mechanical work without lowering the team's ability to explain and own what reaches production.