A friend of mine once hired a contractor who was, by all accounts, a genius with a circular saw. Fast hands. Beautiful cuts. The man could frame a wall before you'd finished describing it.
There was one small issue. Nobody had decided where the bathroom went.
So my friend got a house framed at remarkable speed, with a bathroom in what turned out to be the middle of the living room, because when you don't tell a fast person what to build, they build something, quickly, and it's your problem now. The speed didn't save him a dime. It just got him to the mistake sooner. Well, I just made this up, but you get the point.
This is the whole argument for Part 2, so let me put it plainly: the most expensive thing in software is building the wrong thing efficiently. And AI is the most efficient wrong-thing-builder ever invented.
Skipping discovery to "go faster with AI" is pouring the foundation after you've already framed the second floor.
The blueprint is not bureaucracy
The moment I say "you need a process before you start," half of you flinch, and I don't blame you. You're picturing a 90-page requirements document that took a quarter to write, that nobody read, that was obsolete before the ink dried. You're picturing the Big Up-Front Design that Agile spent twenty years trying to kill, and rightly.
That is not what I'm talking about. A blueprint is not a phone book. A blueprint is the small set of decisions you have to make before swinging a hammer makes sense. Where does the load go. Where does the water go. What is this room for.
In software those decisions are remarkably stable and remarkably skippable, which is exactly why everyone skips them:
Why are we doing this at all? The vision, the actual business outcome, stated in words a human would defend in a meeting.
How will we know it worked? Real objectives with measurable results, not "delight the customer", a thing you can't ship and can't measure.
What's the shape of the problem? The domain, the moving parts, the events that actually happen in the business, modeled before they're coded.
What's the work, broken down? A map from the big idea down to the pieces small enough to build and verify.
How big is it, honestly? Sizing that lets you make a decision with money attached, instead of a hope with a deadline attached.
In what order, and why? A roadmap that reflects priority and dependency, not whoever shouted loudest in standup.
At GSD we call this sequence the Program, and we are deadly serious about the order of operations: you run the Program before you run the robots. The Program is the blueprint. The robots are the nail guns. You already know what happens when you mix those up.
Who decides, and who drafts
Here's the part people get backwards in the AI era, so I'm going to be blunt.
Humans decide what to build. The machine helps work out how.
The vision, the objectives, the priorities, the what and the why, those are human jobs, and they always will be, because they're judgments about value, and value is a human thing. The machine has opinions about everything and stakes in nothing. You do not outsource your destination to a tool that has never once cared where you end up.
But the how, the first draft of the domain model, the proposed breakdown, the candidate estimates, the suggested ordering, that's exactly where a tireless, brilliant intern earns its keep. Let it draft. Let it propose. Let it do the heavy lifting of the first ninety percent so your senior people spend their scarce hours on the ten percent that's actually judgment.
The Magic Intern is a phenomenal drafter and a catastrophic decider. The Program is just the discipline of keeping those two roles separate.
Gates, not gates-for-the-sake-of-gates
So how do you keep a fast machine from framing the bathroom in the living room? You put a human signature between each phase and the next.
GSD's (and pretty much everyone else's) name for this is the human-in-the-loop gate, and the rule is gloriously simple: nothing advances on a robot's say-so. The machine can propose the objectives. A person approves them before they become real. The machine can draft the breakdown, a person signs off before anyone sizes it. Each phase produces something; a human looks at that something and says "yes, proceed" or "no, go back."
This sounds slow. It is the opposite of slow. The slow path is discovering in month four that month one was built on a misunderstanding. A gate is a thirty-second decision that saves a thirty-day rework. The contractor with the misplaced bathroom didn't lack speed. He lacked a single moment where someone with authority looked at the plan and said "wait."
And, this matters, when a gate sends work back, that's not failure. That's the system doing its job. A blueprint you revise on paper costs paper. A building you revise costs a building.
Distill, don't dump
Now, the part I care about most, because it's the difference between a shop that gets smarter over time and one that just gets busier.
When you run the Program, you generate a tremendous amount of thinking. Conversations, decisions, dead ends, the reason you rejected option B, the constraint that ruled out option C. Most organizations do one of two things with all that thinking: they throw it away, or, worse, they dump the entire raw transcript into a folder and call it "knowledge management." A swamp is not a reservoir just because both contain water.
GSD's rule is distill, don't dump. You don't keep the three-hour recording. You keep the claims, the small, specific, true things, each one tagged with where it came from and why you believe it. "We decided X, because of Y, on this date, and here's the constraint that forced it." Not the whole haystack. The needles, labeled.
Do that, and something quietly powerful happens. The reason behind a decision is still there in two years when someone asks "why on earth did we build it this way?" The dead end you already explored doesn't get re-explored by a new hire or by the Magic Intern, who has no memory and will absolutely suggest the thing you ruled out in 2024 unless someone wrote down why.
One record the whole shop can stand on
This is the bedrock I promised you in Part 1, so here it is.
Every one of those distilled claims lives in one shared, living record. This is a single source of truth that the entire organization, human and machine, reads from and writes to. The half-formed idea from discovery and the line of code that eventually shipped point at each other inside it. You can stand at the finished feature and walk backward to the objective that asked for it. You can stand at the objective and walk forward to everything it became.
That is not a filing cabinet. That is an organizational memory. And it's the thing that makes the next five years compound instead of repeat. Without it, every project starts from amnesia, every AI agent starts from zero context, and your shop relearns the same lessons forever, just faster now, because the robots are involved.
A quiet test
Here's how you know whether you have a Program or just a backlog.
Pick any feature you shipped last quarter. Can you, in under a minute, name the objective it served, the decision that shaped it, and the reason you built it that way instead of the obvious other way?
If yes, then congratulations, you have a blueprint, and you're ready to let the machine help you build faster.
If it's a shrug and a "I'd have to ask around", then that's not a memory problem in your people. That's a missing foundation. It's exactly the kind of gap GSD's Maturity Assessment is built to surface: not whether you have a process, but whether your process actually holds when the building goes up.
Find the bathroom before you frame it. The fast contractor never will.
Measure twice, prompt once.
Next in the series — Part 3: "Know Thy Machine: How AI Actually Works, and Why It Wears a Leash."
*Want to know whether your delivery org runs a real Program or just runs fast? Start with GSD's Maturity Assessment, the fastest way to find the gaps before you invest in closing them.*
Back to Blog