The AI Agent Coding Workflow I Use Now

After a few months of experimenting — and a fair number of moments where I had to clean up after trusting the output too quickly — here’s the AI-agent coding workflow that’s worked best for me so far, especially as a solo developer who needs to be efficient with limited time and has nobody but himself to review the work.

Start with context, not a direct code request. Before asking the agent to build something, I give context: what already exists, why this change is needed, what constraints have to be respected. Early on I used to skip the long context and just ask for “build feature X” directly — the result was often too generic, didn’t follow patterns already in the codebase, and I ended up spending more time fixing it than I would’ve spent giving context upfront. The clearer the context, the less often I need to correct the result.

Small tasks, quick review. Instead of asking for “the whole feature X” in one go, I break it into small tasks I can review one by one. That keeps me aware of what’s actually changing in the codebase, instead of blindly trusting it and only noticing something’s off once changes have piled up. One incident made me stricter about this: I once asked an agent to refactor a fairly large module in one pass, skimmed the diff because it looked clean, and two days later realized one function’s behavior had subtly changed — no error, just a slightly different result in one edge case. If I’d reviewed it in smaller pieces from the start, I’d almost certainly have caught it before committing.

Let the agent explore the codebase itself. Modern agents can read files, find existing patterns, and follow the conventions already in use. I don’t need to re-explain the project structure every time — just make sure it reads first before writing, usually by asking it to look at a few similar files before creating a new one. This also means I don’t need to write exhaustively detailed architecture docs just to “brief the AI” — consistent code is already enough documentation for an agent to read.

Verify, don’t just trust. Every meaningful change I build and test manually before committing. AI can “hallucinate” in a way that’s genuinely misleading — not the kind that looks obviously off and easy to be suspicious of, but the kind that looks confident and clean while being wrong, sometimes more convincing than code I’d have written myself in a hurry. Testing stays my responsibility, and it can’t really be delegated to the same agent that wrote the code — that’s like asking someone to check their own work with no incentive to find their own mistakes.

Keep architectural decisions in my own head. Strategic things — stack choices, data structures, trade-offs like where state lives, when to use a server component versus a client component — I still decide myself. The agent can offer options if I ask, but it doesn’t know the business context or client constraints that never made it into the code, so the final call still has to go through me.

This workflow isn’t about “AI does everything” — it’s about how I can focus on the decisions that matter, while AI handles the more mechanical execution. The part I most often forget is verification itself — not out of laziness, but because the better the agent’s output gets, the easier it is to forget it can still be wrong in ways that don’t show up at a glance.