Skip to content

How to Structure Prompts for AI Coding Agents: 5 Techniques That Actually Work

I spent months fighting with AI coding agents. My prompts were getting longer, more complex, and producing worse results. I tried every framework and course out there. Nothing worked.

Then I discovered something unexpected: the biggest jump in quality didn’t come from better prompts. It came from changing how I structure my prompts and sessions.

Here’s what I learned.

The Problem with God-Prompts

I used to write prompts like this:

My old approach
Build a complete authentication system with:
- Login form
- Session handling
- Protected routes
- Password reset
- OAuth integration
- Rate limiting
- Error handling
Use TypeScript, Next.js, and Prisma. Include tests.

The agent would generate 500+ lines of code. I’d accept it. Then spend hours debugging cryptic errors.

The code worked—mostly. But when it broke, I had no idea where to look. The agent had made assumptions I didn’t understand. I was trapped in a cycle of copy-paste-fix.

Technique 1: Write a Project Spec (For Yourself, Not the AI)

Before writing any code, I now create a spec document. This isn’t for the AI. It’s for me.

project-spec.md
# Authentication System
## What does it do?
Allow users to log in with email and password.
## Core Entities
- User: email, password_hash, created_at
- Session: user_id, token, expires_at
## File Structure
src/
auth/
login-form.tsx
session.ts
protected-route.tsx
types/
user.ts
## Data Flow
1. User enters credentials in login-form.tsx
2. Form sends to /api/auth/login
3. Server validates credentials
4. Server creates session with token
5. Client stores token in cookie
6. Protected routes check token on each request

This takes 5 minutes. But it saves hours of confusion.

When I started doing this, two things happened. First, I caught design flaws before coding. Second, I could write much smaller, more focused prompts.

Technique 2: Break Features into Vertical Slices

I used to ask for “build auth” in one prompt. Now I break it down:

Step 1: “Create a login form component with email and password fields.”

Step 2: “Add form validation that checks email format and password length.”

Step 3: “Create a session utility that generates and verifies JWT tokens.”

Step 4: “Add a protected route wrapper that checks for valid tokens.”

Each slice produces 20-50 lines of code. I can review it quickly. Test it. Understand it. Then move to the next slice.

This approach transformed my workflow. Instead of one massive prompt producing a black box, I now have a series of understandable, testable components.

Technique 3: State Machine, Not God-Prompt

I used to write prompts with everything:

The wrong way
Build a todo app with:
- Add todos
- Delete todos
- Edit todos
- Mark complete
- Filter by status
- Sort by date
- Drag and drop
- Local storage
- And...

Now I think in states:

State machine approach
Current state: Empty todo list
User action: Click "Add" button
Next state: Form open
Current state: Form open
User action: Submit with text
Next state: Todo added, list updated

Each state transition becomes a separate prompt:

Prompt 1: “I have an empty todo list. When user clicks ‘Add’, open a form. Here’s the current component: [code]. Add the form functionality.”

Prompt 2: “The form is now open. When user submits with text, add a new todo to the list. Current component: [code]. Current state: [state]. Add the submit handler.”

This keeps context focused. The agent doesn’t need to understand the entire system at once.

Technique 4: The Retrospective Feedback Loop

After each session, I write three things:

retrospective.md
## What worked
- Breaking auth into vertical slices helped me catch an issue early
- The spec caught a missing edge case
## What didn't work
- I forgot to handle loading states
- The session token wasn't being stored properly
## Pattern for next time
When building forms, always prompt for loading states upfront.
Example: "Include loading, error, and success states for this form."

These patterns go into my prompt templates. Over time, they compound.

Technique 5: Review Diffs, Don’t Accept Blindly

This was the hardest habit to build. When an agent shows me code, I want to accept it and move on.

But I force myself to read the diff:

What I look for in diffs
1. Are there any new dependencies?
2. Did it modify files I didn't expect?
3. Are there any `console.log` statements?
4. Does the error handling make sense?
5. Are types consistent?

I’ve caught so many issues this way. Secret keys accidentally logged. Missing null checks. Incorrect type assumptions.

The agent isn’t infallible. Reviewing diffs is my last line of defense.

Common Mistakes I Made

Asking for Everything at Once

I wanted fast results. So I asked for the moon. The agent delivered—sort of. But I couldn’t understand or maintain the code.

Not Writing a Spec First

I thought specs were for large teams. But even for solo projects, specs force clarity. They expose assumptions I didn’t know I had.

Using God-Prompts

Long prompts feel sophisticated. But they produce fragile code. State machine thinking produces modular, understandable code.

Accepting Output Blindly

I trusted the agent too much. AI coding agents are powerful, but they make mistakes. Reviewing diffs is essential.

No Retrospective Loop

I repeated the same mistakes. Without writing down what worked and what didn’t, I couldn’t improve. The retrospective loop turned one-off lessons into lasting patterns.

In this post, I…

In this post, I shared five prompt structuring techniques that transformed my AI coding agent workflow. The key insight: better results come from better session organization, not more complex prompts. Write specs for yourself. Break features into vertical slices. Use state machine thinking. Keep a retrospective loop. Review every diff.

These techniques take practice. But the payoff is dramatic: clearer code, fewer bugs, and a workflow that scales with project complexity.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments