Never Jump Straight Into Coding

The fastest way to get bad software out of an AI coding agent is to ask for the software.

Tools like Cursor, Claude Code and Codex will happily start writing code the second you describe a feature. The code will look confident. It will often even run. And a week later you find out it solved a slightly different problem than the one you actually had, with assumptions baked into every file that are now expensive to remove.

The agent was not the problem. The order of operations was.

I use a four step workflow on everything non-trivial. It costs maybe ten extra minutes up front and saves hours of unwinding.

Step 1: Ask for a plan

Before any code exists, make the agent explain what it intends to do.

Before writing any code, give me a step-by-step implementation plan. List the files you will create or change, what each change does, the order you will do them in, and any open questions or assumptions. Do not write code yet.

A plan is cheap to argue with. Code is not. This is also where you find out whether the agent understood the request at all. Half the time, my real feedback happens here, in plain English, before a single line exists.

Step 2: Ask for an adversarial review of the plan

A plan written by an AI reads well because it was written to read well. So make the same agent attack it.

Now review your own plan like a hostile senior engineer. What are the three most likely ways this plan fails? What edge cases, security problems, race conditions or wrong assumptions are hiding in it? Then revise the plan based on what you found.

This is the step people skip, and it is the highest value step in the whole workflow. The model knows where plans like this usually break. You just have to make it say so before the code exists, while fixing the problem is still an edit to a paragraph instead of a rewrite of five files.

Step 3: Ask for a test plan based on the plan

Based on the revised plan, write a test plan. List the tests that would prove this works, covering the main flow, the edge cases, and the failure cases you found in the review. Do not implement anything yet.

The test plan does two jobs. It forces the plan to become concrete, because vague plans cannot produce specific tests. And it gives you the acceptance criteria before the agent starts grading its own homework. If a test in the plan surprises you, the plan was wrong, and you found out for free.

Step 4: Ask for the implementation

Only now do you let it code.

Implement the revised plan. Write the tests from the test plan first where practical, run them as you go, and if reality disagrees with the plan at any point, stop and tell me instead of improvising.

That last clause matters. Agents improvise silently. A plan gives you something to hold them to.

What breaks when you skip the steps

Skip the plan and you review finished code instead of intentions, which is slower and harder. Skip the adversarial review and you become the only quality gate, at the exact moment you are least able to see the problems. Skip the test plan and "done" means whatever the agent felt like it meant. Skip straight to implementation and you get the demo version of your product: impressive for a day, a liability after that.

The pattern underneath all four steps is simple. AI made implementation cheap. It did not make judgment cheap. Planning, hostile review and test design are where the judgment lives now, and they are still your job.

Plan first. Make it attack its own plan. Then tests. Then code.

Dr Helmi posts a short AI coding tip like this every day on Instagram at @doc.helmi. He is the founder of Orgenix, which builds AI that turns product decisions into software.