Everyone talks about how a new model can "one shot" an app, but that novelty wears off once you need to produce a quality product that will get used in production, whether it's a developer tool, a CI pipeline, or a consumer app.

When i started using agentic coding tools we all still read and wrote the code, we used tab complete, and you understood every single line of the codebase. Now the truth is that barely anyone does, the agents write the code, review the code and deploy the code. I don't think that's ever going back.

But i'm still the one responsible for what i ship, and if i'm not the one reading every line of code anymore then that responsibility has to go in somewhere else. For me it goes into the plan.

Setup

All our agentic workflows are specific to ourselves, we all have skills that we use, our own global AGENTS.md files that specify our preferences (if you haven't done this i recommend you create one for sure), and other lil things that our coding harness might add. My primary setup is Claude Code, which i run through a UI i built for it called August. It also lets me copy my AGENTS.md and my skills to multiple dev machines and sandbox vm's so i can adapt my workflow as i go (this is very important).

Planning

We still need to make sure the agent does what we want it to do. This for me often starts with trying to break down the problem, great way to do that is starting a chat with a big model like Fable and telling it exactly what you want to achieve, including the architecture you want to use. Tell it if you want to use Kafka, Redis or Postgres, tell it where you'd want to deploy it, and tell it to ask you specific questions to get the plan together so YOU fully understand it along with the agent. You should have it cover how the thing will run once it's deployed too and have it write it down in the plan file, i'll come back to why at the end.

Often for me this prompt starts with "I have an idea for ... i'd like you to riff with me on this, explore it, look things up and let's write a plan together." This along with my personalized global AGENTS.md file lets me make sure that i have a thorough understanding of what i'm building, and that all the decisions have been made and written down into an APP_PLAN.md file. Think of the planning session as an RFC you co-author with the agent.

Execution

Once APP_PLAN.md is done and we're happy with it, we now need to build it. I normally just dump it into the project folder and tell the agent "I've placed a plan for x in APP_PLAN.md, i'd like you to follow it and build it out, if you have any questions along the way don't be afraid to ask me. If you do want to make any changes to the plan, ask me first!" and i let it rip. Most of the time this gets me nearly all the way to a product i'd want to use and would be happy to release.

The last few passes are making sure that it conforms to all my preferred specifications and that it works well. I work with the agent to make sure it tells me if it followed the plan, if it deviated at any point, i ask it to show me all the judgement calls it's made. I will often ask the agent to create a test fixture if i'm trying to conform to an RFC spec, recently i used this for SAML, SCIM and OIDC with all their little quirks that companies like to do differently about them.

After this i've found that it gives me a version of a tool that's ready for deployment, so i ask it to deploy. In my own workflow i've set up a simple kubernetes cluster that my agents can just deploy things to, and i have a skill that the agent reads that explains how it's set up, where the templates are stored, how to setup the DNS for the preferred domain, etc.

What the agent won't ask

There's a part of this i keep coming back to. Let's say the plan uses Kafka, do you actually know how Kafka works? Do you know how its replication settings are setup, do you know the retention policy? Do you know how your Redis server is set up, and which options it's running with? Does it store everything? Will it get wiped after a restart and will your app have to refill it? Will your Postgres handle the number of clients you're going to throw at it, are you pooling properly, or do you need pgBouncer sitting in front of it?

The agent won't ask you any of that unless you tell it to. The deploy goes green either way, and the first time those questions come up is when you get paged at 3am and the answer turns out to be a big fat no.

So i have to tell it to, and that's why the planning chat matters so much. It's the one place where i can make the agent ask me things, and where i can ask things back until i can answer every single one of those questions myself. Being asked isn't enough on its own though, if the agent asks whether you need pgBouncer and you say "you decide", you're right back where you started. You should ask it to explain it to you and then you make the decision. Use the agent what it's good for, explaining things well.

My agents write nearly all of my code now, but my name is still on everything I ship, so the plan is where my judgement goes in, and the understanding is how I stay responsible for what comes out.