The AI Coding Workflow That Ships One Feature: Idea to Merged PR

Last week someone on r/codex asked a question that has no business being asked anymore: "How do you use Codex like a professional AI builder?" The tools are a year past magic. The models are good enough that "build me a login page" produces a login page. And yet the most upvoted answer was not a clever prompt or a secret setting. It was a workflow, hand-assembled by someone who had clearly been burned: write a spec first, break it into a phased plan, give each phase a definition of done, plan before you code, then review the diffs like a lead engineer.

Read that again. The top answer to "how do the pros use this AI tool" was not about the AI tool at all. It was a process for working around it. The fastest path to shipping something real with an agent turns out to be the part of software development that has nothing to do with the agent. That is the contradiction this whole piece rests on, and it is the most useful thing you can learn this year: the AI coding workflow that actually ships is mostly the workflow you build around the AI.

#The workflow everyone keeps reinventing

Spend an hour reading how working builders describe their setup and you notice they have all converged on the same shape without coordinating. Addy Osmani's LLM coding workflow going into 2026 describes a virtuous cycle where the AI writes code, automated tools catch issues, and the AI fixes them. The most-shared System Design newsletter version lists five steps and the second one is literally "Plan Before You Code." The dev.to post that keeps circulating is titled, with no irony, "Separate Planning From Execution." Different people, different tools, same skeleton.

Here is that skeleton, the one a thousand builders are rebuilding by hand in a thousand slightly different ways:

Loading diagram...

The shape is not the interesting part. The interesting part is which step does the work. Most people assume the agent, the "Build" box, is where the magic lives, because that is the box that got a thousand times better. They are wrong, and you can prove it to yourself. Take a strong agent and give it a vague idea. You get a confident, plausible, wrong result. Now take a mediocre agent and give it a precise spec with a clear definition of done. You get something you can actually ship. The power is not in the model. It is in the box labeled "what done means," and that box is the one no tool writes for you.

#One feature, start to finish

Abstractions are easy to nod along to and useless when you sit down to build. So walk one real feature through the loop: a password reset flow, the kind of thing every app needs and nobody wants to write.

The amateur version is one sentence. "Add password reset." You paste it into your agent, watch it generate four hundred lines across six files, see a form appear in the preview, and merge it because it looked done. Three days later a user emails that the reset link works twice, or never expires, or silently fails for anyone with a plus sign in their email. The demo worked. The feature did not. You shipped the gap.

Now the version the r/codex commenter was describing. Before any code, you write down what done actually means, in conditions a person can check:

The user requests a reset by email. A one-time link is sent that expires in 30 minutes and works exactly once. An invalid or expired link shows a clear error, not a crash. After a successful reset, all existing sessions are logged out. An unknown email address returns the same neutral confirmation as a known one, so the form cannot be used to discover who has an account.

That is five testable conditions, and notice what just happened. You did not write code. You did not need to. But you now have something the one-sentence version never had: a definition of done that exists outside your head, that the agent can build against, and that you can check the result against later even though you cannot read a line of the code that produced it. The spec is the deliverable. The code is downstream of it.

From there the rest of the loop has somewhere to stand. You slice the work into phases, send the agent off to build, and when the pull request comes back you do not stare at the diff feeling unqualified. You walk your five conditions. Request a reset, click the link twice, watch the second click fail. Wait thirty-one minutes, confirm the link is dead. Enter an email that does not exist, confirm the message gives nothing away. You are reviewing behavior against a checklist you wrote, which is exactly the kind of review a non-engineer is qualified to do. We went deep on that skill in reviewing a pull request when you cannot read code; the point here is that the checklist is what makes the review possible at all.

#Why the spec is the workflow

There is a backlash worth taking seriously. A sharp comment on a recent Hacker News thread called the whole agentic-workflow paradigm "a narrative trend pushed by AI companies to get people to 10x their token consumption." That critic is half right, and the half they are right about is the half that matters. A loop with no definition of done is exactly what they describe: an expensive way to keep rolling the dice. You prompt, the agent generates, you squint, you do not like it, you prompt again, and every turn burns credits while you converge on nothing, because there is nothing for the loop to converge toward.

The thing that turns that slot machine into a workflow is the one ingredient the skeptics never mention. Not a better model. Not more autonomy. A spec the output can be measured against. With it, every loop iteration has a target and a stopping condition: done is when the evidence matches the spec. Without it, "done" is whenever you get tired of pulling the lever. The definition of done is not a nice-to-have step in the workflow. It is the workflow. Everything else is plumbing.

This is also why the workflow does not get easier as the models get better, which is the part that surprises people. A more capable agent makes more decisions per turn, and every decision you did not write down is one it makes for you, silently, in a direction you will discover later. The more the agent can do on its own, the more the written spec is the only thing standing between its speed and your weekend. The hard part moves toward planning, not away from it.

#Where this stops being a hand-rolled process

You can run this entire loop yourself with sticky notes and discipline, and many good builders do. But look at what you are actually maintaining by hand: a definition of done for every feature, a way to slice it into buildable phases, a record of which conditions were checked and which were not, and a memory of what this product is supposed to do that survives from one session to the next. That is real work, and it is the same work whether you are one person or a team of fifty. The reason it keeps getting reinvented in Reddit comments is that nobody ships it as a product.

That is the gap BrainGrid sits in. You describe the feature in plain language, and the Planning Agent turns it into a requirement with explicit acceptance criteria, asking the clarifying questions you did not think to answer, the kind that catch the expired-link and plus-sign-email cases before any code exists. The Builder Agent then builds against that spec, either in a managed cloud sandbox with a live preview or in your own GitHub repo with Claude Code, Cursor, or Codex. When it is done, verification checks the result against every acceptance criterion, so the pull request arrives with evidence attached instead of a diff you have to decode. That is the full loop, Plan, Build, Verify, Repeat, and the part that does the work, the captured definition of done, is the part the product remembers so you do not have to rebuild it every project. We cover the planning half in depth in building the BrainGrid way, and the spec craft itself in how to write acceptance criteria an AI agent can verify.

The honest limit: a spec does not write itself, and a bad one ships a bad feature with full confidence. If you write down the wrong conditions, the agent will satisfy them perfectly and you will have built the wrong thing precisely. The workflow does not remove your judgment about what good looks like. It just makes sure that judgment gets recorded once, up front, where it can actually steer the build, instead of living as a fuzzy feeling you compare the result against at the merge button.

So the next time you catch yourself asking how the pros use the latest agent, remember what the pros actually answered. They did not share a prompt. They shared a workflow, and the center of it was the least glamorous step there is. Write down what done means before you build. The agent got fast. Deciding what it is allowed to call finished is still your job, and it is the only job that ships.

#FAQ

#What is an AI coding workflow?

An AI coding workflow is the repeatable process you wrap around an AI agent to turn an idea into shipped software, rather than just prompting an agent and hoping. In practice it has converged on a consistent shape: write a spec that defines what "done" means, slice the work into phases, let the agent build against the spec, then verify the result against your original conditions before merging. The agent handles the code generation; the workflow handles everything that makes the code generation aim at the right target. The most common mistake is treating the prompt as the workflow when the spec is the part that actually does the work.

#How do I set up an AI coding workflow?

Start with the step everyone skips: before any code, write down what done looks like as a short list of conditions a person can check, not as a one-line prompt. Then break the feature into phases small enough to review one at a time, send each to your agent, and when it returns, walk your conditions against the running result instead of reading the diff. Keep a record of what this product is supposed to do so each new session does not start from zero. You can do this manually with notes and discipline, or use a tool that captures the spec, runs the build against it, and verifies the result for you.

#Is planning really necessary if the AI model is good enough?

Yes, and counterintuitively it matters more as models improve, not less. A more capable agent makes more decisions per turn, and every decision you did not specify is one it makes on its own, in a direction you discover after the fact. A strong model with a vague request produces a confident, plausible, wrong result; a modest model with a precise definition of done produces something you can ship. The work that decides the outcome is in the spec, because that is the only thing the agent's speed has to aim at. Skipping planning is how a loop becomes an expensive way to keep rolling the dice.

#How do I review an AI pull request if I can't read code?

Review the behavior, not the syntax. Read the summary and confirm the scope matches what you asked for, then open the preview and walk through your acceptance criteria the way a real user would, including the failure cases like expired links, wrong inputs, and empty forms. Notice how many files changed and be more cautious of a sprawling change than a small one. Approve only when the running feature satisfies every condition you wrote up front. This works precisely because you defined done before the build, so the review is checking a list instead of guessing against a fuzzy memory.

#What's the difference between vibe coding and an AI coding workflow?

Vibe coding is prompt, generate, eyeball, repeat, with no written definition of done and nothing to verify against, which is great for prototypes and a fast way to ship hidden gaps when the app matters. An AI coding workflow adds the missing piece: a spec the output is measured against, so each iteration has a target and a clear stopping condition. The difference is not how good the model is or how fast you go. It is whether there is anything in the loop that can say "not yet," which is what turns generation into shipping.

BrainGrid turns your idea into acceptance criteria, builds against them with your choice of agent, and verifies every change with evidence, so the workflow you keep rebuilding by hand is just the product. Try it at braingrid.ai.