**Our goal: **use AI to develop faster without quietly dumping the cost onto whoever reviews your PR. Or, more plainly: use AI without making your reviewer hate you.
You are still the engineer, so you own, understand, and should be able to explain every line you submit, no matter *what *generated it. The reviewer is not your rubber stamp, and the AI code agent will not be standing next to you when someone asks why this broke.
My ultimate humble appeal, don’t let the agent sprint into the codebase with scissors on the first turn. Before we let an agent touch anything non-trivial, make it write the plan first. Read that plan like you would review a design doc: wrong assumptions, missing edge cases, obvious overkill, unclear test strategy. Once the plan is sane, I will highly encourage you to include a version of it in the PR so the reviewer gets the why and how before the diff hits them in the face.
Note: Use a strong frontier model for generating the plan. This is one of the places where the fancy model actually earns its snack budget.
Sample Prompt:Don't write code yet. Read the relevant existing code, wiki pages, epics, then give me a short plan for [Jira story]. List the files you will change and why, the approach, edge cases and error paths, how you will test it, and any assumptions or open questions. Flag a simpler approach if one exists. If the story is small, keep the plan to a paragraph. Wait for my approval.
A giant PR is unreviewable no matter who wrote it, and AI makes giant PRs dangerously easy to produce. Do the slicing up front, aim for ≤400 lines per PR, one logical change each, with refactors kept out of the PRs that change behavior.
The ~400-line target is not magic, but it is a useful tripwire: once reviews get too large, humans stop being good bug detectors and start becoming diff archaeologists (SmartBear/Cisco code review study). If a story can’t be sliced under that, it is perhaps too big and needs breaking down first (time to talk to the Product team).
Sample Prompt:Don't write code yet. Based on [Jira story / the plan], propose how to split this into PRs of approx 400 lines each, one logical change per PR, with refactors separate from behavior. For each PR, provide: title, one-line description, rough size, and dependencies. Show me the breakdown and get approval.
You would be surprised how often agents, including the shiny expensive ones, give BS explanations with absolute confidence. Ask, rather, *push *the agent to explain the code it wrote, the tradeoffs it made, and the simpler options it rejected. If the answer sounds like a TED talk about “leveraging synergies,” keep pushing until it sounds like code. I often prompt, “I don’t understand what you are saying. Your explanation is going above my ahead. I want an explanation I could repeat and defend in review. Try again.”
Bonus: You will often get very satisfying U-turns from your smart agent (see the image below)
Before you put the PR in front of a human, open a fresh agent with no prior context and ask it to explain the branch back to you. The fresh context matters. A thread full of yesterday’s wrong turns will confidently defend yesterday’s wrong turns! If a fresh agent can’t reconstruct your intent, the PR is not ready, and neither are you to defend it.
Prompt: Don't assume this branch is correct. Compare it to main: explain what it does, why each part is correct, and the edge cases it handles. Then flag anything you would raise in review e.g., logic errors, missing error handling, risky assumptions, leftover debug/TODO code, or anything inconsistent with the repo, the [Jira story] and our rules files. Rank by severity.
AI has a suspicious talent for writing tests that pass without testing anything: assertions too loose, or that just confirm the code ran. Make the agent prove otherwise and the fastest check is to break the implementation and confirm the tests go red. Then read the asserted values against real or production-like data, because that is where the “the date looks fine but is actually lying to you” bugs hide.
Prompt:For the tests you added/changed: list what each asserts, and confirm those are the values the code should produce, not just what it does now. Then break the implementation, run the tests, show they fail, and restore it. Finally, name uncovered edge cases (nulls, empties, boundaries, dates, error paths) and suggest adding the ones that matter.
Handwritten PR descriptions are where the standards quietly fall apart, so let the Skill be the boring adult in the room. A good /create-pr Skill should fill out the PR template, attach evidence that the change works, warn when the diff blows past the size cap, and tag how much was AI-generated so the reviewer knows where to look harder.
At minimum, the Skill should enforce our commit standards, complete the PR template, self-review the diff, check the branch against the Jira ticket, and call out missing tests, risky assumptions, oversized diffs, and unclear ownership. The goal is not to make the PR look fancy. The point is to stop handing your reviewer a mystery box.
AI almost always writes more than the problem needs: extra abstractions, config knobs nobody asked for, defensive handling for cases that can’t happen, and helpers used exactly once. Before you open the PR, do a deliberate simplicity pass over everything the agent touched and ask what could be removed without losing behavior.
Note: For this step, explicitly choose a strong frontier model as that is where model capability actually pays off.
Prompt:Take a step back and review the entire code base, both the existing code and the new additions. Is everything consistent across the code and comments? Can anything be simplified? Is anything over-engineered? Ask repeatedly: would we include this if we were writing this from scratch? List your suggestions and wait for my approval.
Agents don't remember last session. Without a version controlled rules file you re-teach the same preferences every time: plan before code, respect the architecture boundaries, push back when the diff is getting weird, and fix from evidence instead of vibes. Put those lessons in .cursor/rules/ (or your IDE's equivalent) so every new chat starts with the same guardrails, and extend the file when you learn something.
A useful Rules file should encode the stuff you would otherwise re-argue every session: plan and get a yes before code, explain tradeoffs in plain engineering terms, push back when the requested change conflicts with the repo, describe who writes and who reads each design, and fix from evidence such as logs, traces, test output, and diffs rather than only from the symptom someone reported.
It will not be perfect, but it should be good enough that new sessions stay productive instead of re-hashing the same debates. At the end of the task, make the agent do one useful little retro.
Prompt:What from this work should become a durable rule in our working arrangement and what was a one-off? Propose exact bullet additions. I will approve before you edit the rules file.
AI can help you move faster, but it does not absorb the responsibility. The rule is simple: if you ship it, you own it.
How to Use AI to Code Faster Without Creating Review Debt was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.