Home Subscription Advisory Assessment Tools Delivery Risk Calculator Blog Contact Book a Call
Building on Solid Ground

Building on Solid Ground, Part 1: The Build Site — Why Everyone Bought Power Tools and Forgot the Blueprint

person Gerhart S. Dunn calendar_today Jun 22, 2026 schedule 7 min read
arrow_back Back to Blog

Let me tell you about the most expensive nail gun in the world.

A man buys it. Top of the line. Fires faster than he can aim. He's so thrilled with the speed that he never quite gets around to drawing the blueprint, or pouring the foundation, or checking which wall is load-bearing. He just starts firing. And for about a week, he is the most productive man on the street. Walls go up like magic.

Then the inspector comes. Then the rain comes. Then the second floor comes down through the first.

That man is your technology organization, and the nail gun is generative AI.

The demo always works. The demo is one man building one wall in an empty field. Nobody asks where the plumbing goes.

The Build Site — Why Everyone Bought Power Tools and Forgot the Blueprint
The Build Site — Why Everyone Bought Power Tools and Forgot the Blueprint

We're all holding the same tool

I've watched a lot of hype cycles. Client-server. Object orientation. "The cloud will fix everything." Agile, which somehow became seventeen ceremonies and a man with a beanbag. Each time, the tool was real and the promise was inflated by exactly the amount of money in the room.

Generative AI is different in one respect: it's fast. Genuinely, alarmingly fast. It will write you a function, a test, a migration, and a heartfelt apology before you've finished your coffee. This is not nothing. This is, in fact, a great deal.

But speed is not direction. A car with no steering wheel also goes very fast, right up until it doesn't.

The uncomfortable truth that vendors won't print on the box is this: AI does not fix a broken delivery shop. It accelerates it. If your requirements are vague, you will now generate vague software at industrial scale. If nobody knows why a feature exists, you'll ship ten of them by Friday and remember none of them by Monday. Power tools don't make you a carpenter. They make you a faster source of sawdust.

Meet the Magic Intern

I want you to picture a particular kind of employee, because we're going to spend six essays together and you'll need to keep this character in mind.

The Magic Intern is brilliant and tireless. Reads everything in seconds. Never sleeps, never complains, never asks for a raise. Will cheerfully attempt any task you name.

The Magic Intern also has no memory of yesterday, no idea what your business is for, an unshakeable confidence even when completely wrong, and a tendency to invent a plausible-sounding answer rather than admit ignorance. You would never hand this person the keys to production and walk away. You'd give them a clear brief, a senior engineer to check their work, and a very firm rule about not touching anything important without a signature.

And yet, watch how organizations deploy AI. They hand the Magic Intern the keys, point at the codebase, and go to lunch.

The entire point of this series is what the grown-ups in the room put around that intern so the brilliance pays off and the confidence doesn't burn the building down.

The job was never "write code faster"

Here's where I lose the people who came for a magic trick. The hard part of software was never the typing.

A serious delivery shop has to be good at the whole lifecycle, the unglamorous span from a half-formed idea, through honest requirements, through planning, into delivery, automation, testing, and then the part everyone forgets, watching the thing actually behave in the wild. Idea to production to observation. The code is one station on a long assembly line, and it was never the bottleneck.

AI is fantastic at the station everyone already enjoyed. It is useless, worse than useless, actively dangerous, at the stations nobody wanted to staff. Ask it to "build the feature" and it will. Ask it which feature, for whom, why, at what cost, and how you'll prove you built it responsibly when the regulator calls and it will make something up with total conviction, because that is what it does.

So the question stops being "how do we code faster" and becomes the only question that matters:

What has to be true *before* you let the machine off the leash?

Five things, foundational by design

At GSD we have an annoying habit of saying the same five things until people either agree or leave the room. They are the spine of this series, one essay each, and they all share a property: you cannot bolt them on afterward. They are foundations. You pour them first or you pour them never.

1. A real Program comes before the robots. You run a disciplined sequence: vision, objectives, the shape of the problem, the breakdown of work, the honest sizing. All of this before a single agent fires. The blueprint precedes the build. (Part 2.)

2. You understand the machine you're using. Not the math, the behavior. How it works, why it works, and crucially, where it must wear a leash. An agent that can approve its own work is not an employee; it's an accident with a résumé. (Part 3.)

3. You know what it costs. All of it: the machine, the infrastructure, and the very real human hours AI creates in review and oversight. "AI made us faster" is half a sentence. The other half has a dollar sign in it. (Part 4.)

4. Audit is a first-class citizen. Not a fire drill before the quarterly review. Every decision traceable, every claim sourced, nothing quietly deleted. When Risk and Compliance knock, you answer with a query, not a panic. (Part 5.)

5. It all stands on one shared source of truth. A single living record where the original idea and the shipped code point at each other, so the organization actually remembers what it knows. (This is the solid ground under all of it, and yes, it's in the name.)

Before you swing a hammer, survey the lot

Here's the thing about foundations: you can't see them, so it's tempting to skip them. Nobody photographs the footings. They photograph the kitchen.

But you already know, in your gut, whether your shop is building on bedrock or on sand. You know whether a line of shipped code can be traced back to the objective that asked for it. You know whether anyone could tell you what last week's AI spend actually bought. You know whether "show me the audit trail" produces a document or a long, sweating silence.

If you don't know, and most don't, honestly, that's not a moral failing. It's just an un-surveyed lot. The fastest way GSD has found to draw the real map is the Maturity Assessment: a short, behavior-driven look at where your delivery organization actually stands, before you spend a fortune buying tools to fix problems you haven't located. You find the gaps first. Then you close them. In that order. Always in that order.

Because here's how the next six weeks go. We're going to walk the whole build site together: the blueprint, the machine, the bill, the inspector, and the bedrock underneath. By the end you'll have a builder's playbook and a dare.

For now, just go look at your own foundation.

The man with the nail gun never did. He was too busy admiring the speed.

Measure twice, prompt once.

Next in the series — Part 2: "Run the Program Before You Run the Robots."


*Curious where your own foundation actually sits? GSD's Maturity Assessment is the entry point — a structured look at where your delivery org really stands before you invest in closing the gaps.*

arrow_back Back to Blog
×

WANT TO WORK WITH US?

Let's talk about how we can accelerate your next project.

Get in Touch