How to scope a coding-agent task so the diff stays reviewable

A coding agent is good at a bounded edit and bad at an open-ended one. The difference shows up in the diff. If you cannot review it, you do not have a finished change. You have a suggestion that happens to compile.

Name the failure

A request that works names the files and the case that fails.

The list drops a row when the score field is null. Here are the mapper, the screen, and the fixture. Add a test that fails on null, then the smallest change that makes it pass. Do not edit auth.

A request that wanders is "make the flow better." That one will touch middleware, copy, and a model other routes import. Reject it and rewrite it before you accept a patch.

Keep three areas closed

• secrets, connection strings, and signing keys
• migration history
• production configuration

If the task needs one of those, do that edit yourself. The agent can draft the sentence next to the file. It should not be the thing that commits the file.

Read the diff before you run the app

Read the patch, then run the new test and one test you already trusted. If the new test only asserts what the new code returns, it cannot catch a real mistake. Throw it out.

Also check the size. A normal task touches one screen or one route. When the diff crosses a module you did not name, revert it and tighten the prompt. That is cheaper than debugging a drive-by refactor.

What still costs money

Refusing a second subscription does not make tokens free. Pasting a whole models directory into a chat is the expensive move, and it copies the most structure into a log you do not control. Paste the function, the type, and the failing assertion.

Do not paste production rows. A fixture with fake numbers teaches the same bug. The same rule applies to tokens and keys: they are not prompt context. The handler checklist is the bar the agent does not get to skip.