A research note on making coding agents more predictable, reviewable, and useful when they work across real production repositories.
Reliability starts before the first edit
A coding agent feels reliable when it understands what kind of work it is doing before it starts changing files. A small copy fix, a dashboard layout change, a migration, and a payment verification bug should not all be treated with the same level of freedom.
In production codebases, reliability comes from a rhythm. The agent should inspect the repository, identify the relevant files, understand the risky boundaries, and then make the smallest useful change. That sounds simple, but it is where many sloppy agent sessions go wrong.
The real problem is usually not that an agent cannot write code. It is that it writes code before it has enough evidence. It guesses a helper name, invents a table relationship, ignores an existing style pattern, or changes a nearby file because it looks convenient.
Nap is built around the opposite habit. It should read first, patch second, and explain the path between the two in language a developer can actually review.
Predictable agents make smaller promises
A reliable agent does not need to sound heroic. In fact, the best agents are often calm and narrow. They say what they checked, what they changed, what they could not verify, and what still needs a human decision.
That matters because production work is full of hidden context. A component may be reused in three places. A route may rely on middleware. A Supabase table may have an RLS policy that changes what a query can see. A payment flow may look fine in the browser while the server callback is still the source of truth.
When Nap works well, it keeps those conditions visible. It should avoid large rewrites unless the user asks for one, avoid changing unrelated files, and avoid presenting a build as proof of business correctness.
This makes the output more predictable. You know where the change came from, why it exists, and how to check it before shipping.
Verification is part of the product
A coding agent without verification is just a confident patch generator. Useful reliability requires evidence: a build, a test, a typecheck, a local reproduction, a browser check, or at least a clear manual checklist.
Verification does not have to be heavy every time. A Tailwind spacing change may only need a visual check. A database migration may need a much stricter path. The important part is matching the check to the risk.
Nap should make that matching explicit. If it changes auth, billing, organization membership, tokens, usage limits, or API access, it should treat the work as sensitive and say exactly how the change was tested.
That is the difference between speed and slop. Speed still respects evidence. Slop only cares that something appears to work once.
