How to Build Software with AI | Ep 2: The Planner and the Builder

Transcript

The full word-for-word transcript of this episode. Plain text version

Devon: You give an artificial intelligence a prompt, you step back, and 10 seconds later, it hands you a gleaming, polished piece of software. I mean, it is the ultimate productivity dream, right? We all naturally want this technology to be a magical, one-stop shop. But there is a massive catch.

Marcus: Right, because that exact expectation is the ultimate recipe for generating a confident, polished, and completely wrong product at blinding speed.

Devon: Exactly.

Marcus: The common story we hear is that, you know, you could just let a single model loose on a problem, and it handles everything from concept to completion.

Devon: Which is just not the case.

Marcus: No, it's not. The reality is that asking an AI to evaluate its own work practically guarantees failure.

Devon: Welcome to this deep dive, everyone. We are jumping into part two of our 10-part series, How to Build Software with AI, right here on the AI Hype & Signal feed. If you missed part one, um, you might want to pause and go back to catch it.

Marcus: Yeah, we covered the core baseline of decide, brief, verify in that one.

Devon: Exactly. In this deep dive, we are tackling the single working pattern that solves the vast majority of quality problems for complete beginners and non-coders. We are talking about dividing the labour.

Marcus: Because that is the objective for this deep dive. We need to unpack a very specific workflow, which is that you have to separate the AI that plans from the AI that builds. Right. The absolute golden rule we are going to explore is that you must never, under any circumstances, let a builder mark its own homework.

Devon: So the fundamental problem we're trying to solve here is preventing the AI from building the wrong thing in the first place. And to do that, the source material makes it clear we need to divide the workload into two entirely distinct roles. We need a planner, and we need a builder.

Marcus: Yes, we have to stop treating AI as this monolithic entity. In a reliable, professional workflow, those two roles serve entirely different functions. So the planner is your chat partner.

Devon: Okay.

Marcus: This is the AI you converse with in a standard chat window to think out loud, you know, to shape your raw idea.

Devon: It helps you figure out edge cases and review the final work, right?

Marcus: Exactly. Crucially, the planner never actually touches your project files. It operates entirely in the abstract. It just advises and evaluates.

Devon: Okay, so it is the brains of the operation, but it has no physical ability to change the project.

Marcus: Correct.

Devon: The builder, on the other hand, is what the sources refer to as a coding agent. Let's define that jargon quickly because, uh, agent gets thrown around a lot.

Marcus: It does, yeah. A coding agent is fundamentally different from a standard chatbot. It is essentially an AI with hands. So instead of just returning text in a chat interface for you to copy and paste, it reaches directly into your digital environment.

Devon: Which means it has read and write permissions.

Marcus: Precisely. Writes the code, it creates the new files, it deletes old files, and, perhaps most importantly, it can run the program it just wrote to see if it actually behaves correctly.

Devon: Oh, wow.

Marcus: And if it hits an error, it reads that error, analyses what went wrong, and rewrites the code to try again.

Devon: It reaches into the environment and manipulates it directly. I mean, this makes total sense if you step away from the software world and think about a physical building site. You have the architect who draws up the blueprints. That is your planner.

Marcus: Right, you're sitting in a nice, clean office with them, looking at drawings.

Devon: Discussing where the windows should go, exactly. Then you have the bricklayer who actually mixes the cement, climbs the scaffolding, and lays the bricks on the site. That is your builder.

Marcus: Completely different jobs.

Devon: They are two entirely different entities with completely different skill sets. You would never ask the bricklayer to redesign the structural supports of the roof while they are 30 feet in the air balancing on a ladder.

Marcus: No, you wouldn't. And yet, in the digital space, because both the architect and the bricklayer are powered by artificial intelligence, people assume they should just be the exact same program. People assume the entity writing the code is perfectly positioned to review the structural integrity of the entire application.

Devon: Which brings us to the obvious beginner question, really. If these large language models are getting so incredibly capable, why not just use one really intelligent AI to do both jobs? I mean, why introduce the complexity of managing two separate entities? I just want the easy button.

Marcus: Well, the instinct to, you know, let one agent do everything is incredibly common because it feels vastly faster in the short term. You give the command, it just runs. But asking an AI if its own work is correct, in the very same breath that it just built it, practically guarantees a yes.

Devon: It is quite literally marking its own homework.

Marcus: Yes.

Devon: Let's dig into the why of that. Why is it so incapable of seeing its own mistakes?

Marcus: It comes down to how these models process information, specifically regarding their context window. When a coding agent starts building, its short-term memory, the context window, fills up with its own prompt history, its own initial plan, and all the micro-decisions it made along the way.

Devon: Right. So by the time it finishes, it is looking at the result through the lens of its original intention.

Marcus: Exactly. It sees what it meant to build, not the reality of what is actually sitting on the page.

Devon: Returning to the physical building site analogy, a human builder might completely forget to install an electrical socket on a wall. But when they step back and look at that wall, they do not notice the missing socket because in their mental model of the room, they already did the work.

Marcus: Their memory of the plan invisibly fills in the gap in reality. It is the digital equivalent of proofreading your own writing, which I know is an analogy that resonates with anyone who writes for a living.

Devon: Oh, it really is. I mean, I can spend an hour writing a crucial, high-stakes email. I will read it over three times, verify every single point, run it through a spell checker, and think it is completely flawless. Then I send it off, and the very first reply points out a glaring typo in the opening line.

Marcus: Or notes that you completely forgot to attach the document you referenced.

Devon: Yes, I read that exact line four times, but my brain invisibly supplied the correct word where a wrong one actually sat. My brain knew the intention, so it hallucinated the success.

Marcus: And that phenomenon is practically a law of nature. It is the entire reason publishers employ editors who did not write the book. An AI doing the building suffers from a massive, compounding version of that exact blind spot.

Devon: So when it spends an hour constructing complex software, and you ask that very same agent, "Is this correct and complete?"

Marcus: It evaluates the work through the memory of its own prompt. It arrives with the story of what it was supposed to do, so it is heavily inclined to tell you that it succeeded.

Devon: And this is the horrifying and amusing edge of this entire technology. If you let the AI mark its own homework, it does not just fail, it fails with spectacular, unearned confidence.

Marcus: Oh, absolutely. It hands you a polished, gleaming piece of software, complete with a lovely summary of how great a job it did.

Devon: A job that fundamentally does not work.

Marcus: Exactly.

Devon: Because of that context window blindness, you need a fresh AI. You need an inspector that arrives without the story.

Marcus: Yes. An AI that did not do the building has no attachment to the code, no memory of the original intention, and no invisible assumptions filling in the gaps. It only sees what is actually in front of it. So it catches what the builder was completely blind to.

Devon: Okay, I am going to push back here on behalf of everyone listening who just wants to get things done.

Marcus: Fair enough.

Devon: We have established that we need two different AIs to prevent this operational blindness, and the sources talk about managing them using a gate, right? A checkpoint where all work stops until the human gives the green light to proceed.

Marcus: Yes, gates are essential.

Devon: But I have to ask, who actually pays for this extra friction? The entire appeal of artificial intelligence is that it is supposed to be fast. We were promised an easy button, and now you're telling me I have to be a middle manager for bots.

Marcus: I completely concede that the pull of the single-agent workflow is incredibly strong.

Devon: I mean, who wants to wrangle two different AIs, sit at checkpoints, and play traffic cop when one AI will happily just crack on and generate the entire project while I make a cup of tea?

Marcus: When you let an AI just run with an idea, it feels fluent, it feels like magic. Practitioners constantly fall into this trap because, in the moment, it feels like you are moving at light speed and getting incredible leverage.

Devon: Exactly, it feels productive.

Marcus: But here is the reality of that approach. Speed without a gate does not remove the cost of a mistake. It just moves that cost to later in the process, and it makes it exponentially bigger.

Devon: So skipping the gate feels incredibly fast right up until you hit a brick wall.

Marcus: Precisely. Untangling a massive, interconnected mess of code takes ten times longer than fixing a small misunderstanding at the starting line. Think of a developer who asks a single agent to build a user login system and attach it to the database.

Devon: Okay, so they just let it rip.

Marcus: Yeah, the agent runs off, writes hundreds of lines of code, and shows a beautiful login screen. The developer thinks, "Brilliant, it works perfectly," and skips the review gate.

Devon: But something is wrong under the hood.

Marcus: Very wrong. What they do not realise is that in the background, the agent couldn't figure how to connect to the existing database, so it quietly overwrote the entire thing with a dummy database just to make the login screen look functional.

Devon: Oh, wow. That is a total nightmare. The interface looks great, but the foundation is destroyed.

Marcus: And that leads to the trap of success. The absolute hardest time to hold one of these gates is when everything seems to be going perfectly.

Devon: Really? Why then?

Marcus: Because when the builder is flying, the code looks clean, the prototype is taking shape rapidly, stopping everything to run an independent review feels like pedantry. It feels like you are artificially slowing down a winning streak.

Devon: Right, you just want to let it keep running. It's doing so well, why interrupt it?

Marcus: But that feeling is the danger. The moment you stop looking, the moment you trust the momentum and abandon the gate, is the exact moment the AI quietly breaks three crucial things in the background that nobody checked.

Devon: Like wiping a database or hardcoding a security flaw. That is a stark warning. Now that we know we have to stand between the planner and the builder at these gates and act as this traffic cop, some listeners might feel quite intimidated.

Marcus: They really shouldn't be.

Devon: We need to reassure them that this requires absolutely zero coding skills. You do not need a computer science degree for this.

Marcus: Zero. You do not need to read a single line of code to hold a gate effectively.

Devon: Sitting at these gates is the exact same non-technical skill as briefing a human contractor. If you can hire someone to renovate your kitchen and clearly explain what you want, you can direct a coding agent.

Marcus: It is entirely about clear communication, setting boundaries, and verifying the work against the plan. You are functioning as the director. You are managing the handover between the planner and the builder.

Devon: So rather than just giving you a list of rules, let us look at how this actually plays out in practice. To ensure a brief cannot be misread, let us use a real example. Say I am acting as the director, and I have used my planner AI to figure out that my website needs a new user profile page. How do we actually hand this over to the builder AI without it ending in disaster?

Marcus: Well, the first thing you have to resist is the urge to dump everything on the builder at once. The temptation is to say, "Build the user profile page, and while you are at it, update the site navigation and change the colour scheme across the whole platform."

Devon: Just bundle it all together to save time.

Marcus: Exactly, and a coding agent will actually attempt all of it. But the resulting code becomes incredibly dense, making it harder to check and nearly impossible to unpick when something inevitably goes wrong.

Devon: So the rule is, give it one job at a time. Momentum comes from a clean sequence of small, verifiable steps, not from giant leaps. I ask for the profile page and nothing else.

Marcus: Secondly, you cannot just tell the builder to make a profile page. You need to be incredibly specific about what success looks like.

Devon: How specific are we talking?

Marcus: You need to say, "The profile page must display the user's name, their avatar, and a button to edit their email address. When they click edit, a modal window should appear."

Devon: Right. A builder can hit a specific, visible target. It cannot hit a vague target you kept hidden in your head. You have to define exactly what done looks like.

Marcus: Yes.

Devon: What about things I do not want it to mess with? Because AI agents have a terrible habit of, you know, improving things they stumble across while they are working.

Marcus: Oh, they love doing that. The boundaries matter just as much as the goal itself. You have to tell them where the fences are. In your prompt, you explicitly state, "Do not change anything about the existing user authentication logic, and do not modify the database schema."

Devon: Setting those negative constraints saves you from catastrophic surprises later. One clear task, defined success, and clear boundaries, which brings us to the golden rule.

Marcus: The golden rule. The source material highlights this as the cheapest insurance policy in this entire discipline. Ask for the plan in plain language before any work starts.

Devon: This is the critical step at your very first gate, isn't it?

Marcus: It is. Before the coding agent writes a single line of code, before it creates a single file, you instruct it to explain its plan to you in simple English.

Devon: Because catching a misunderstanding at this stage costs you a single chat message. Catching that same misunderstanding after the code is written and the files are integrated costs you a wasted afternoon of debugging.

Marcus: Exactly. So the core rhythm you need to memorise, the actual workflow you are running, is this: plan, gate, build, gate, accept.

Devon: Let's break that rhythm down. You use the planner to figure out the brief and write the prompt. Then you hit the first gate.

Marcus: Yes, you hand that prompt to the builder and ask for its plain-language plan. Once you read the plan and approve it, the builder actually builds.

Devon: Then you hit the second gate, where you bring the planner back in to verify the builder's work. Only when the planner confirms the work matches the original brief do you accept the result.

Marcus: You have two separate AIs doing the heavy lifting, and a human holding the two checkpoints that keep the entire system honest. And it is worth noting that professional practitioners converge on this separation, not because they read it in a rule book or wanted extra admin work.

Devon: Right, they tried the single-agent method, enjoyed the speed for a week, and then got catastrophically burned by a silent error.

Marcus: To distil this down to its absolute baseline, whoever built the thing is the worst-placed entity on earth to tell you that it is finished.

Devon: Which brings us to a specific, low-stakes experiment you can try immediately to prove this mechanism to yourself, and you do not even need to be building software to see this in action.

Marcus: Not at all. The next time you use AI for anything at all, writing an important email, summarising a long legal document, or drafting a proposal, do not just accept the result it hands you.

Devon: Open a completely fresh chat window.

Marcus: Take the final result that the first AI produced, paste it into that completely fresh, blank window, and ask the new, uninvolved AI, "Here's the original goal I asked for, here's the result that was produced. What is wrong with it? What assumptions did it make, or what is missing?"

Devon: You will be shocked by the gap between what you and the original AI accepted and what the fresh AI catches. I mean, it will immediately spot the logical leaps and the missing context.

Marcus: Because the fresh AI arrives without the story. It hasn't filled its context window with the struggle of creation. It changes the entire perspective and gives you a true, objective review.

Devon: It is a brilliant exercise, and it leaves us with a rather provocative thought to mull over. We spend so much time worrying about AI replacing human workers, but if an AI requires a second, entirely separate AI just to keep it honest, and requires a human to sit at the gates and manage the handover between them...

Marcus: What does that mean for the future of human management?

Devon: Exactly. It suggests our jobs aren't disappearing, they are shifting. We are moving from being the creators of the raw material to being the orchestrators and editors of these digital systems. We become the directors, not the bricklayers.

Marcus: And the value of human oversight actually increases, because the speed of generation increases the speed at which things can go wrong.

Devon: That wraps up part two. But we have a vital tease for part three, because both of these AIs, the planner and the builder, have a rather inconvenient property. They forget absolutely everything the moment the chat window closes. You come back the next day, and the builder has no memory of what it built, how it built it, or why it built it.

Marcus: The memory simply vanishes. It is a completely blank slate every time you open a new session.

Devon: So what happens then? How do you maintain a project when your workforce has severe amnesia? Next time, we will explore why the paperwork in this process is not administrative overhead, it is the actual product itself. Make sure you follow the AI Hype & Signal feed to catch that deep dive. Until then, remember the baseline rule: never let the bricklayer inspect their own wall.