Plan Before You Code With AI (So You Stop Getting Messy Output)

Tools / Accounts Needed

• Any AI coding tool (ChatGPT, Claude, Cursor, or similar)

• A specific feature or bug you are working on right now

• Your existing codebase, or the relevant files for that change

Ask most developers what went wrong with an AI generated feature and the answer is usually the same. They described what they wanted in one message, let AI write the whole thing at once, and ended up reviewing five hundred lines of code they only half understood. The fix is not a better prompt. It is doing less generation, earlier, in smaller pieces.

By the end of this workflow, you will have a repeatable loop for planning, building, and reviewing AI generated code in pieces small enough to actually stay in control of.

Steps

1. Describe the feature in plain language first (no code yet)

Before you open your AI tool, write two or three sentences about:

• what you are building

• why it matters

• who it is for, if that helps

Write it the way you would explain it to a teammate or classmate.

Do not open the AI tool until this is written down somewhere you can paste it.

If you cannot explain the feature simply, AI will not magically understand it either.

2. Ask AI to turn your description into a real spec

Paste your description and ask AI to help you tighten it before any code is written.

Prompt:

Here is a feature I want to build: [paste your plain language description].

Ask me clarifying questions until we have a clear spec, including edge cases I have not thought of.
Do not write any code yet.

Answer the questions honestly, even the ones that feel obvious.

This step catches missing requirements and edge cases before they become bugs.

When you are done, you should have a clear spec you can build from, not a vague idea.

3. Break the spec into small, independent tasks

Once the spec is solid, break the work into pieces that can each be built and reviewed on their own.

Prompt:

Based on this spec: [paste the finished spec],

Break this into small tasks that can each be built and reviewed on their own, not one giant change.
List them in the order I should build them.

A good rule: if you cannot review a task in a few minutes, it is too big. Split it further.

Small tasks keep you in control. Large tasks hide problems.

4. Generate code for one task only

Even if you can see the full task list, do not ask AI to build everything at once.

Work on one task.
Share only the files relevant to that task.
Do not dump your entire codebase into the chat unless you truly need it.

This keeps the output focused, easier to review, and less likely to create random changes elsewhere.

5. Read the actual diff before accepting anything

Treat AI output the way you would review a junior developer’s pull request.

That is basically what is happening.

Before you accept the change:

• read the full diff

• check what files changed

• make sure you understand why each change exists

If you do not fully understand a part, ask AI to explain that specific section before moving on.

If you cannot explain the change, you are not ready to keep it.

6. Ask AI to write tests for what it just built

This is one of the most skipped steps, and one of the most useful.

Prompt:

Write tests for the code you just generated.
Start with the core functionality, then add tests for edge cases specifically.

AI is often strong here because thorough test writing is tedious work many people skip by hand.

Running code is not the same as proving the code is correct. Tests give you a safety net for the next task.

7. Ship the task, then repeat for the next one

Only move to the next task once the current one is:

• built

• reviewed

• tested

Then start the loop again with the next item on your list.

Small, reviewable, shipped increments beat one large AI-generated change every time.

What to watch out for

Treat AI like a fast, capable junior developer whose work still needs review.
Do not treat it like a finished engineer you can fully hand off to.

AI can confidently produce code that:

• looks correct

• runs without errors

• still contains subtle logic bugs

This is especially true when there are no tests yet.

Your project environment matters as much as your prompt.
A codebase with clear structure and real tests usually gets better AI output than a messy one, because AI has clearer signals to work from instead of guessing your intent.

Expected output

You should end with:

• a feature built in small, reviewed, tested increments

• code you understand well enough to explain

• a paper trail of what was built and why at each step

Not one giant block of AI-generated code you only partly trust.

Before you merge anything

• Did you write a plain-language description before opening your AI tool?

• Did you break the work into tasks small enough to actually review?

• Did you read every diff yourself, not just skim and accept?

• Does this task have real tests around it now?

If any answer is no, pause before merging or submitting.

Common mistakes

• Jumping straight into code generation with a vague one-line prompt

• Feeding AI your entire codebase for a change that only touches a few files

• Accepting a large diff without reading it fully

• Skipping tests because the code already runs without errors

• Letting one AI session both write the code and act as the only reviewer