AI Governance Is Not Optional

Andre Kaminski mapped the AI-native transformation in eighteen months, and schedules governance for month sixteen. You need it on day one.

It was Christmas morning, and it was snowing. One click, and Kaminski’s new book was on my Kindle. I had bought it thinking about nWave; what he had found in his research, what was new, what it might teach us. I started to read, and the pages flowed as if there were no outside.

By the time the snow had thickened on the sill I understood two things at once. Kaminski had nailed it! The process, the roadmap, the eighteen months, all of it sound. And what we had been building, after two decades in the Dojo, and the past seven years in AI-R&D, already lived a step past the page. A way to take the stochastic nature of AI and make it deterministic, and in the enterprise version, to make it zero-trust deterministic. We were past spec-driven. We were ready to showcase what Andrea Laforgia defined as expectation-driven development.

I closed the book with a quiet conviction underneath the excitement. The roadmap was a beautiful map. It could not, on its own, walk the last mile for anyone; the AI-readiness gap. I did not yet know how clearly the months ahead would prove it.

For a while I had watched the industry circle the same questions, and here was a practitioner who had sat down and drawn the whole territory. Kaminski lays it out as a six-stage lifecycle: discovery & context engineering, prompt architecture & design, AI-orchestrated development, intelligent quality engineering, automated deployment & operations, and the slow work of continuous learning & evolution, letting a system learn from its own life in production. Then he does the harder thing. He turns the lifecycle into a calendar 🗓️. Eighteen months, four phases; foundation in the first quarter, capability through the third, scaling and integration past the first year, and the organization itself remade by month eighteen. He is honest about where it stands, calling it an emerging practice without long case histories behind it, a proposal more than a proven playbook. That honesty is part of why it lands.

If you have read it, or even heard it described well, the natural thought is the one I would have had in your chair. We have the budget. We have the tools. We have bought the AI. Now we have the map. We can do this ourselves. It is the right instinct. Wanting to own your own transformation is not a weakness; it is the posture of every leader who has ever built something that lasted. And yet, six months of conversations later, I keep meeting the same quiet result. The map is on the wall, the OSS AI-coding framework repo is forked, the pilot has been kicked off, and somewhere in the second month the thing stops moving in a way no one can quite name. I have come to understand why, and it has almost nothing to do with the map.

The first place it shows is the technical floor. nWave, like any serious agentic workflow, runs on a constant exchange. The agent surfaces options, names a tradeoff, asks a question about the domain, the architecture, the test strategy, and waits. To answer well, an engineer needs the time and the judgment to know what is actually being asked. Where that judgment is thin, the answer becomes a guess, the output drifts toward the merely plausible, and the path of least resistance becomes vibe coding; prompt after prompt, each one quietly compounding debt the team cannot yet see. The tool gets called too difficult. The difficulty was never the tool.
Where the technical floor is solid, the constraint simply moves upstream. A strong engineering team feeds an agentic workflow faster than a product function can describe what it truly wants. Discovery, discuss, the patient refinement of intent; all of it becomes the new constraint, and a product organization that was never staffed for that depth turns into the place the whole transformation waits.

Either way the shape is the same, and notice that it is not technical. It is social. Friction between divisions, each doing its honest best, is what stalls an AI transformation, and friction is a human matter, not a tooling one. There is a cost hiding in that friction that compounds faster than most leaders expect. Technical depth and product depth do not add; they multiply. The deeper and larger a codebase grows, the more the model has to reconcile, the more it reworks, and the more every unclear intent upstream is paid for downstream in tokens and time. What we have measured is blunt: a weak code base paired with a fragile production posture can push token spend past 300% percent, the bill for complexity, for rework in production, and for the bugs that should never have shipped. Adam Tornhill‘s research at CodeScene confirms the mechanism from the other side: in an unhealthy codebase AI does not accelerate the work, it amplifies the debt and waste 50% more tokens. We have a name for that compounding, and a way to read it before it runs away from you, but that is a story for another week.

Which brings me to the thing I noticed on that snowy morning, the thing this whole piece has been circling. Kaminski writes the word governance more than two hundred times. He instruments it almost never; in the entire book the language of OKRs appears exactly once, and governance itself is something his roadmap establishes in the final phase, somewhere around month sixteen. Read that again. The single layer that determines whether any of this is safe, auditable, and defensible is scheduled for the end.

Governance is not a phase. In an AI-native organization it is the instrumentation that has to run from day zero, because what changed is not the speed of the work; it is the nature of the actor. The thing writing your code is now an agent, or a person and an agent together. When something goes wrong, when a regulator or a court asks who is accountable, the answer cannot be improvised in month sixteen. This is why AI governance refuses to behave like the digital transformations leaders remember. It reaches deeper. It changes how people work, how processes run, how data is gathered and cleaned and trusted, how risk is even defined. And it cannot be read from the technical side alone, or the product side alone. It has to see both at once, which is precisely what a dashboard built on shared OKRs is for; one surface where the board, the engineers, the product team, and the people closest to the customer can all see where the organization is truly leading.

So what does the crossing actually take, if not a better map? It takes the things a map cannot carry. It starts with an honest assessment of the gap, not of skills alone but of behavior and governance readiness. It takes a short, sharp workshop to get a team moving with the minimum it needs, not a six-month syllabus. It takes a pilot with a specialist embedded in it and coaches beside the team, so the organization learns while it builds something of real business value, rather than learning in a sandbox and hoping it transfers. It takes scaling that follows the business challenges that matter, led by the human bridge that carries people across the change rather than a process rolled out over their heads. And underneath all of it, from the first day, it takes that governance dashboard, watching the whole system; organization, processes, board, people, customers, product, and technology.

That is the work, and it is why we made the readiness assessment a free, open portal, and why nWave itself is open source and free to anyone. The roadmap alone was never going to be enough. Forking a tool was never going to be the same as crossing. The open-source nWave is, in the most affectionate sense, a water pistol; the enforced, zero-trust deterministic engine lives in the enterprise, because the day we stopped treating AI’s output as something to hope about and started treating it as something to enforce was the day we moved past spec-driven work entirely, into what we now call expectation-driven development. That is a longer story, and I will tell it soon. The proof is already public. Claudio Perrone built Rippily on nWave, layering his own agents on top of ours, and he puts the lesson plainly:

a framework can hold the rigor, but it cannot make the choices for you.

He brought the craft; the structure matched his standard. Few organizations hold that much craft in a single person, and that is exactly what the nwave coaches and the SW Craftsmanship Dojo are there to build. It is the pairing that works, and the one a forked repository, on its own, can never be.

I am watering the Japanese cherry tree, and across the garden my daughter is working through her swimming exercises; the same movements, again and again, a little truer each time, me always within reach of her. Six months have passed since that snowy morning, and I have sat in many rooms since, and run many AI-readiness assessments with the related follow-ups, and the pattern barely changes. Capable organizations; the tools bought, the AI in place, Kaminski’s roadmap on the wall, nwave forked; deciding to walk it alone. We have the map and your OSS nWave version, they tell me. We will manage.

Not one of them has yet shown me the return they were promised. And when I look at the people doing the walking, the journey does not seem to have been much of a pleasure, because the two things they needed most were the two things a map can never hand you: someone beside them on the field, and governance from day zero. Those are the things we chose to build, and to give.

The book is on the shelf inside. The tree will flower in its own time, the way these things do when someone tends them. It was a beautiful map. It was never the hard part. The crossing was, and no one should have to make it alone.

If you are somewhere on this road, let me say the thing I say in those rooms. You made the right call. You invested when investing was the brave and difficult thing to do, and you are far closer to the finish than the silence in your second month suggests. The free readiness assessment will show you, in thirty honest minutes, exactly where your gap sits and which of the two bottlenecks is yours. nWave is yours to take, no charge and no catch. And when you decide the crossing is worth a companion, I am beside you; your timeline, your choice.

See where your gap sits, in thirty minutes.

Next week: the ten to fifteen percent of the work that quietly decides the other eighty-five. Kaminski calls it the start of everything. Most teams spend almost nothing on it, and pay for the rest of the project.