Start with an observable outcome
A coding agent can produce a convincing screen before you have decided what the screen should do. Start with a small user outcome: a signed-in user edits their profile, saves it, and sees the saved name after reloading. That gives both the implementation and the review a concrete target.
Include the current behavior, the desired behavior, and the important failure cases in the brief. Name the existing module that owns the work. A request to add profile editing should point to the authentication layer, rather than leave the agent to invent a second user store. Keep credentials out of prompts and screenshots.
Make the repository explain itself
Document how to run the application, which checks are deterministic, and where ownership is enforced. In supastack, AGENTS.md records the workspace boundary and .ai/ records file-level decisions. These notes are useful when they tell the next contributor why an implementation exists, not just what files changed.
Ask the agent to read the relevant code before editing. A narrow change usually needs the UI, its server boundary, and the tests around that boundary. Loading the entire repository is less useful than understanding the few places that decide whether the new behavior is correct.
Review one complete change at a time
Write an acceptance check before changing behavior. For profile editing, cover a valid update and an unauthorized attempt. Build the smallest implementation that satisfies those cases, then inspect the actual interaction with realistic text and a narrow viewport.
Review the diff as well as the result. Look for duplicated business logic, broad exception handling, and new dependencies that solve a problem the existing stack already handles. Run the project's checks and record what they establish. A browser fixture can verify a form interaction; it cannot establish that the production database or an external provider is configured correctly.
pnpm test
pnpm check
pnpm build