Why AI Pilots Hit a Ceiling Nobody Can Explain

On the fifth of December, we flew out of Bari into the hills of Puglia, to a trullo with a stone cone for a roof and a terrace that looked straight out over the sea. We had come there to build something. For four days we argued about nWave, about the reveal we were planning in Geneva, about whether a machine could be made to behave like an engineer instead of a gambler. We drew it on a chart, there on the terrace, the way you sketch a thing you are not yet sure is real.

On the eighth we said goodbye in the morning, the sun coming up over the water, certain in the quiet way you are rarely allowed to be certain that the effort had been the right one. Alessandro Di Gioia left for his flight back to London. He was still at the airport when Claudio Perrone called.

And on that call, between a terrace we had only just left and a plane he had not yet boarded, the two of them made a bet. Build Rippily. Build it with nWave.

Then everyone went home for Christmas. Nobody really stopped working.

Over the break, two of us bought a book. Andre Kaminski had just published his work on the AI-native software lifecycle, and reading it felt less like discovery and more like recognition. He had measured the thing we had sketched on the terrace:

The discovery and context work, the part most teams treat as a warm-up before the real building starts, is only ten to fifteen percent of a project’s token budget. And it decides everything that comes after.

You already know this law by another name. Pareto saw it a century ago. A small, vital share of the effort governs the great majority of the result. The first twenty percent builds the other eighty. Kaminski simply found where that “twenty” percent lives in AI-native work, and it is not in the code. It is in the context, the domain.

Kaminski calls that “twenty” percent context. We call it product engineering, because in our hands it is not a document, it is a new discipline. It begins with the unhurried work of understanding the domain and the people who live inside it, the ground that Domain-Driven Design, Lean UX, design sprints and disciplined product management were all built to cover. Then it moves fast. A thin architecture. A walking skeleton. The first tests that prove the shape is real. An MVP a human being can open and touch (even on the paper). The aim is to collapse the distance from a need to something you can hold until it is almost nothing, the blink of an eye. Get those few days right and the months look after themselves. Get them wrong, and no amount of generation will save you.

This is why we had spent four days on a terrace arguing about it, and why nWave goes past spec-driven development to something Andrea Laforgia calls expectation-driven. The difference matters more than it sounds, and it deserves its own story another day. For now, hold the simple version:

describing what you want is not the same as constraining what you get.

Kaminski makes the point through two teams building the same feature, a customer onboarding flow for a financial company. The first team was good, a mature agile shop with real practitioners. They discovered the compliance rules in one sprint, the security requirements in the next, the international edge cases in the one after that. Every discovery meant going back and reworking what they had already built. Three months, and a sound system at the end of it.

The second team spent two days capturing the whole context first, the rules, the constraints, the security, the edge cases, all of it, before a line of code existed. Then they generated. Three weeks. Same features. Same compliance. Same security.

The line that stays with me is his: the security and compliance were embedded, not discovered afterward. The agents did not write code and then test it for compliance. They wrote compliant code, because the context required it. Said plainly, a specification stops being a document you read and becomes a contract the system is built to honor. Intent, captured in language a machine can verify. That is not only good engineering. It is governance by construction, the audit trail written before the first commit.

Here is where Kaminski stops, and where the terrace argument went further.

He proved the input matters. He showed how to capture it. And then he assumed the rest would behave. But between the well-written context and the running system sit two things he never governs, and both of them improvise (by nature).

The first is the agent. A language model is, by nature, a generator of plausible variation. Give it perfect context and it will still wander, because wandering is what it does.
The second is quieter and more costly: the orchestrator, the layer that decides which agent runs, in what order, on which handoff. Kaminski makes orchestration the centre of his whole vision, the developer reborn as a conductor. But by default that conductor is itself a language model, one model directing others. The conductor is improvising too.

Two improvising layers do not add their uncertainty. They multiply it. That is why a flawless specification still drifts on the way to production, and why teams who did the upfront work right are puzzled to find the output unreliable anyway. The context was sound. The musicians were not.

nWave was built to close exactly this gap, on both surfaces. Each agent carries the discipline of software craftsmanship and modern software engineering within it, shaped through behavioral engineering to act with congruence, like a seasoned engineer rather than by a roll of the dice. And the orchestration runs on deterministic rails, a system that holds the agents to contracts so the workflow follows a score instead of a mood. The craft knowledge lives in the agents; the product knowledge becomes the context they answer to. There is a great deal more underneath this, the waves, the contracts, the way the rails are enforced, the agents’ personalities. That, too, is a story for another week.

While we supported Claudio building Rippily, we were also sitting with companies, walking them through the AI readiness assessment, measuring where their gaps actually were. A pattern showed up again and again.

Most of them run the same pilot. They set the old way of working beside an AI-augmented way, hand their developers a harness, BMAD, GSD, GasTown, SuperClaude, sometimes ours, and they watch for the lift. It comes, for a while. Then they hit a ceiling none of them can explain, and they go looking for it in the code, because the code is the only place they have ever had to look. But, it is not there.

The bottleneck moved. It is no longer at the keyboard. It moved upstream, to the product. The scarce person now is not the faster coder; it is the one who can hold both depths at once, the technical depth to know what is buildable and the product depth to know what is worth building. That combination has a name on our side. We call it delivery depth, and the person who carries it is a product engineer.

So we tell them to start running two more experiments. In the first, the team sharpens its craft in the dojo, with nWave and a coach beside them. In the second, a smaller team learns both sides, the craft and the product, handed nWave and the same coaching. The first team gets faster. The second starts shipping the right thing at a pace that looks unreasonable from the outside. We have the data on the gap between them. And yet, underneath every one of these pilots, the same thing keeps surfacing, and it is not a shortage of talent. It is fear.

Organizations are wary because the last digital transformations (Agile, DevOps, scale Agile, etc.) cost them dearly and delivered slowly. The caution is earned. So when people who have done this work for years offer to walk beside them, they hesitate, afraid of paying again for a journey that disappointed them before. It seems reasonable. It feels safer to do it alone. But in the long run, it is, quietly, the most expensive choice on the table.

Come back to the terrace for a moment. The chart, the sea, the bet made from an airport gate.

Forty days after that sketch, Claudio, our first alpha user, had Rippily in production. Running on a real infrastructure. Fully automated DevSecOps, security scanning, proper test and code posture, proper product design, the kind of quality you would expect from a team ten times the size. Hundreds of people moved through it in the first demo run. Forty days, from a drawing on a terrace to a live product, while organizations many times larger were still deciding whether to begin.

The chart was the twenty percent. The certainty we felt at sunrise was not luck. It was preparation arriving exactly when the moment did.

The quiet good news is that you can find your own twenty percent before you spend a single euro building. That is what the readiness assessment is for. Its two product dimensions measure precisely this, whether your intent is clear enough for a machine to build from without guessing, and if your feedback loop is at the pace of the agentic-coding. It costs nothing, and what it shows you is yours to keep. We have sat through this with a lot of leaders, not to hand them a framework, but to help them see where their leverage is leaking before it becomes expensive. When you are ready to walk that stretch, we are beside you. Your timeline. Your choice.

Next Week: I have shown you one road through this. It is not the only one. Next week I lay every serious answer side by side, the academic, the practical, the popular, and trace the one truth they all arrive at from completely different directions. It is the truth most organizations are spending the most to avoid hearing.