The rule of thumb: let the AI write where mistakes are cheap and obvious, and use it to review/refactor where mistakes are expensive or subtle. The deciding factor is how much it costs you to verify the output.
The rule of thumb: let the AI write where mistakes are cheap and obvious, and use it to review/refactor where mistakes are expensive or subtle. The deciding factor is how much it costs you to verify the output.
In these cases the cost of a bug is low and you can read the result top-to-bottom.
Here you keep the AI as a second pair of eyes: it suggests, you decide.
Cost of a bug LOW Cost of a bug HIGH
New code ✅ let AI write ⚠️ AI drafts, you verify hard
Existing code ✅ AI refactors ✅ AI reviews, you write the change
Writing from scratch is fast but the AI may invent APIs (hallucination) or miss context it can't see. Reviewing is safer but slower and only as good as the context you give it. Either way you are the accountable author — the AI is a tool, not the signer of the commit.
Misjudging this is where AI-assisted dev goes wrong: people let the AI generate critical logic they then can't fully verify, or they hand-write trivial boilerplate the AI could have produced in seconds. Matching the mode (write vs review/refactor) to the cost of being wrong keeps you fast on the cheap stuff and careful on the dangerous stuff. The skill being tested is judgment about where to spend your verification effort — not whether you can prompt an AI.