Use coding assistants without surrendering review

Use an assistant as a fast junior collaborator, not an authority

AI coding tools can shorten the time to a first draft. They can also confidently invent an API, miss a hidden requirement, or change a working behavior outside the requested scope. The useful loop is: inspect, specify, plan, change a small unit, verify, review, and record what you learned.

Before the change: create enough context

Start with the user-visible outcome and the constraints that must remain true. Include the relevant files, existing conventions, error message, supported versions, and how you will verify success. Ask the tool to inspect the existing implementation before editing. For a broad change, ask for a short plan that names files, risks, and checks; correct that plan before implementation.

A task prompt can be as small as:

Goal: Let a signed-in user export only their own invoices as CSV.
Constraints: Keep the existing route and UI. Do not add dependencies. Escape CSV cells.
First inspect the route, auth checks, invoice schema, and current tests. Report the relevant files and any ambiguity; do not edit yet.
Done means: server checks ownership, export handles empty data and commas/newlines, existing tests pass, and a new unauthorized-access test fails safely.

This is more useful than a long role prompt because it describes the actual boundary and observable completion conditions. Never paste live credentials or real customer records into a prompt. Use synthetic examples.

Make one coherent change at a time

Ask for a proposed diff or plan before a high-impact change. Keep the change narrow enough to inspect. If a tool edits files, inspect the full diff and run the focused check yourself. Ask what assumptions remain and what was not verified. A generated test is not proof if it repeats the implementation’s assumptions; inspect the test input and expected behavior.

For unfamiliar dependencies or APIs, check the project’s installed version and the official documentation. Do not accept a made-up import just because the code compiles in the model’s example. Review lockfile changes, package scripts, configuration, and any generated files. Reject unrelated formatting or refactors that make the diff harder to reason about.

Verify at the layer where failure matters

• Pure logic: unit tests for normal, boundary, and invalid inputs.
• Data access: integration test that attempts another user’s resource ID.
• UI journey: operate with keyboard and a realistic account state; check loading, empty, error, and success states.
• Deployment: build with the production command and inspect the deployed path, environment, and logs.
• Security-sensitive change: review authorization on the server, data exposure, secret handling, and abuse limits separately.

Run the smallest relevant checks after each step, then the project’s full required checks before merge. If a check cannot run, say so; never report it as passed. Keep a clean git status before beginning and review git diff before committing so unrelated user work is not swept in.

Keep the maintainer in charge

The human maintainer decides product behavior, data policy, dependency risk, and whether the result is ready to ship. Ask the assistant to explain unfamiliar code in terms of the user journey and failure modes. Preserve the final decision in project documentation when the reasoning will matter later.

Anthropic’s Claude Code guide is specific to that product; adapt tool-specific features rather than assuming they apply everywhere. Continue with a maintainable build workflow and the AI app security checklist.