Make an AI coding task small enough to review and finish

A request to “add team invitations” grows into a new permission framework, email service abstraction, redesigned settings page, and account migration. The assistant may be following every opportunity it discovers, while the reviewer loses the ability to determine whether any one behavior is complete.

A task is small enough when its outcome is understandable and its evidence is affordable to inspect. File count alone is a poor measure. One coherent permission change can touch several files; one large utility file can hide multiple unrelated features. This article uses an illustrative invitation flow to show how to divide work by contracts.

Identify the first complete user outcome

Describe one journey: an authorized owner enters an email address, the server creates an invitation, and the page displays its pending status. That journey has a clear boundary. Accepting the invitation, provisioning access, resending mail, and revoking invitations can be separate outcomes if the initial contract supports them.

Write the end condition before listing implementation tasks. “Owner can create a pending invitation without creating a member account” is clearer than “build invitations backend.” It tells the assistant what success means and what premature side effects to avoid.

Include the negative case that makes the outcome safe. An ordinary member cannot invite someone if policy reserves invitations for owners. Duplicate requests should follow the agreed rule. A coherent slice includes these constraints because a happy-path demonstration alone is not a usable feature.

Draw the contract between slices

Define the request, response, stored state, and errors for invitation creation. The response might contain an invitation identifier, email, status, and expiration. It should not contain an acceptance token if the UI does not need that secret. The contract allows frontend and backend work to agree without implementing every future feature.

Identify what later acceptance needs from creation. For example, a durable pending record and a unique token digest may be required. Decide these relationships early, but avoid implementing an entire acceptance workflow merely to prove that the creation record exists.

A slice can include foundational code if its purpose is explicit and its behavior is tested. Adding a small invitation type used by the current endpoint is different from designing a generic workflow engine for hypothetical future products. The contract should justify each new abstraction.

Divide by risks rather than arbitrary layers

Separate uncertainties that need investigation from implementation that already has a known pattern. If email delivery infrastructure is unclear, inspect that boundary first. If owner authorization already exists, reuse it rather than starting a new role system.

A useful sequence is contract and permission evidence, creation endpoint, interface submission, then integration verification. The endpoint can be checked with synthetic requests before the UI exists. The UI can use the agreed response fixture while integration follows. Each part has a clear completion condition.

Avoid slices that merely produce unused scaffolding. “Create twenty empty components” is not an observable outcome. A smaller functioning path is easier to review and reveals assumptions earlier. If a foundational migration must precede behavior, document why it is necessary and how compatibility will be verified.

Give the assistant an explicit stopping rule

An assistant needs to know what to do with adjacent problems. Tell it to report unrelated defects separately and continue only when they block the current outcome. Define permitted dependencies, files likely to change, and behavior that must remain stable.

An illustrative brief is: “Implement pending invitation creation using the existing owner policy and database client. Return the agreed public fields. Do not implement acceptance, resend, or settings redesign. If an existing defect blocks this path, identify it and propose a narrow correction.” This leaves room for discovery without making scope unlimited.

Ask for a plan that names the observable result of each step. A list of file edits is useful but insufficient. Require a verification action for each behavior, such as a denied member request or a duplicate create request. Completion then depends on evidence rather than the amount of generated code.

Keep review size tied to reasoning cost

A review becomes difficult when it mixes different kinds of reasoning. Schema changes require compatibility analysis; authorization requires ownership tracing; UI changes require interaction checks. Putting all three into one PR can be justified for a small feature, but adding unrelated design cleanup multiplies the review burden.

Look for a diff that tells one story. Every change should either implement the invitation outcome, preserve compatibility, or verify it. If the reviewer cannot explain why a new package is needed, ask for its role before accepting it. Smallness is about coherence as much as line count.

Keep generated artifacts separate when they obscure the meaningful diff. Large snapshots, lockfile updates, and reformatted files can hide a removed permission condition. Necessary generated changes still belong in the work, but the review should make their relationship to behavior clear.

Verify a slice before expanding it

Run the owner success case, member denial case, validation failures, and agreed duplicate behavior. Inspect the stored record and public response. Confirm that no member access is granted merely because an invitation exists. These checks establish the creation boundary.

Then test the UI's pending and error states with the endpoint. A created record and a failed email delivery are different outcomes if sending occurs after persistence. The page should reflect that distinction rather than presenting a generic successful invitation when the recipient received nothing.

Use an assistant to enumerate missing cases from the contract, then choose those that protect meaningful invariants. Avoid generating dozens of tests that repeat one branch. The guide on evidence checklists shows how to record verified and unverified boundaries concisely.

Expand when the completed slice reveals a real need

After creation is coherent, move to acceptance with its own journey, permission rules, and atomicity requirements. The creation contract becomes context for the next task. This progression preserves momentum while keeping each result understandable.

Sometimes splitting introduces temporary feature flags or dormant endpoints. Account for that cost. A partially visible workflow can confuse users, so keep unfinished paths inaccessible until their intended journey works. Small engineering tasks do not require exposing incomplete product experiences.

A task is too small if it cannot be meaningfully checked without several unimplemented neighbors. It is too large if it contains multiple independent outcomes with different failure models. Adjust the boundary until the assistant can finish a useful change and the reviewer can explain why it is safe to continue.

Sources

GitHub Copilot best practices includes breaking down complex requests.

Anthropic: Building effective agents distinguishes defined workflows from dynamic agent behavior.