Keep AI code changes small: reduce review cost without hiding necessary work

A worked example: where the task becomes difficult

A fictional storefront has a cart-total bug after quantity changes. The agent proposes a new styling system, state library and checkout layout alongside the arithmetic fix. Those additions obscure the relevant change and increase regression risk. Start by identifying the existing calculation owner, preserving the current dependencies and testing a quantity update against an approved expected total.

Decisions to make before implementation

Set boundaries based on responsibility rather than an arbitrary line count. A change may legitimately touch a function, its callers and a behavioral test. Keep formatting-only churn separate, and explain any necessary public contract modification. If the cause requires a broader patch, have the agent state why the original scope is insufficient before adding a replacement subsystem.

A practical sequence for the work

Use the sequence below as a task boundary, not as a claim that the example has been executed. Work with approved inputs and the project’s actual architecture. If a required integration or permission is unavailable, keep that stage visibly incomplete rather than generating a plausible substitute result.

• Write the single customer behavior that needs to change.
• Identify the existing owner and callers from inspected source.
• Apply the smallest coherent patch and inspect the diff for unrelated churn.
• Run a behavioral check that would fail before the repair and pass afterward.

A detailed brief you can adapt for your agent

Replace the illustrative context with your approved facts and controlled inputs. Keep the stated boundaries when adapting the brief. The expected deliverable matters more than a particular tool name: ask for an explanation grounded in the inspected material and evidence for the requested outcome.

Repair cart recalculation after quantity edits using the current state and pricing functions. Preserve styling, dependencies and checkout layout. Trace the calculation owner, change the supported cause and add one representative behavioral check. Explain every changed file. If a contract change is necessary, state why instead of silently redesigning the cart.

Failure modes that an attractive preview can hide

Removing a failing assertion or returning a constant total makes a diff look small while destroying correctness. Review the test expectation and the business rule, not just the changed lines. An agent can also touch generated files unintentionally. Keep the source/build boundary visible and verify that dependency manifests have not changed without a reason.

Technical references: GitHub: getting useful results from coding tasks

Acceptance checks and the evidence to retain

Provide the focused diff, original failure reproduction and verified pricing result. Record postponed cleanup separately so it cannot be mistaken for required work on the cart bug.

Specific answers

Common questions