Essay · May 31, 2026

The new miracle cure

For the past few weeks, I keep seeing the same story, told a thousand different ways. The prompt wasn't enough, so we moved on to context engineering. Context engineering wasn't enough, so we moved on to spec-driven development. And here, suddenly, is the new miracle cure, the definitive answer to the excesses of vibe coding.

I recently read, in a post on Medium, a summary I find very apt. Vibe coding says: you give only the intent, and the AI does all the rest. The spec-driven approach says almost the opposite: you specify everything, frame everything, constrain everything, and that way the AI produces something predictable. It isn't mine, but it captures the pendulum we're all watching.

And a pendulum, by definition, swings from one extreme to the other. Vibe coding was a shortcut born of overconfidence. Specifying everything, again and again, is becoming another shortcut, born of fear. I want to explain why I believe neither one will take us very far, and what I've seen emerge by following a third path.

Why the industry rushed to specifications

We have to be honest about what pushed everyone in this direction. After a little more than a year of agent-mode coding, the industry made a brutal observation: a lack of reliability. Not catastrophic unreliability, precisely — and that's what makes it insidious. In some cases, it worked wonderfully well. Developers got hooked on those moments when everything came out almost perfect, like a drug delivering a fresh high.

But alongside those successes, there were derailments. And those derailments didn't really come from the AI. They came from what we weren't giving it: no precise architecture, no serious analysis of the things to consider, little or no design. We were leaving it to a coding agent — a gifted, over-caffeinated junior — to improvise everything, hoping the result would hold together.

So developers looked for a life raft. And the natural reaction was to dust off old books. We rediscovered test-driven development. We rediscovered the specification. We specify, we specify, we specify some more. It's a salutary return to basics in many respects — I've written about this elsewhere, because experienced developers had gotten into the habit of compressing analysis and design inside their heads, and AI threw that shortcut into crisis.

But the question has to be asked plainly. Do you know many projects that lined up hundreds, thousands of pages of specifications? And, in general, did those projects end well? I've seen some, in a distant professional past. I have one in mind in particular: thousands of pages, a resounding failure, millions of dollars sunk. Specifying, then specifying again, doesn't fix everything. And that's exactly what people are slowly starting to rediscover.

A lab with no deadline

I have to say where I'm speaking from, because it changes everything. I'm not a researcher. I don't build AI models, I don't run benchmarks, I have no metrics. I'm a backend developer with a lot of experience, and an amateur when it comes to AI. What I'm sharing here are intuitions, impressions, leads — a bit like a micro-influencer giving an opinion. Nothing scientific.

But I have a chance few people have: a project close to my heart, Ezkey, which I decided to run solo, with a structured, agent- and AI-first approach. It's a project that doesn't earn me a cent, that isn't promised to anyone. I use it as a career-long professional synthesis. And because it's a synthesis, I let myself explore, make mistakes, start over, aim for high standards, and experiment for real.

That freedom was decisive. Very early on, before a plan mode even existed, when everything scrolled across the screen and dissolved from one conversation to the next, I had the instinct to tell the AI: "save what you generate to a file." That instinct proved right — plan mode appeared later, and the AI ended up doing it on its own. But I could never have lived that intuition, given it a voice in my head, without a place to try it out.

From the fear of delegating to intent

At first, I censored myself. I wanted to keep absolute control over the AI: code completion for small fragments, then a few tests, then a small function here and there. No more. I didn't dare delegate further, because without broader framing I didn't know what direction things would take. I feared the derailments, and that fear throttled my own ability to express what I wanted.

Then I established a few simple principles: use plan mode, set minimal framing, give guardrails. And the game widened. The more frame I had, the higher I could delegate. Meanwhile, the models themselves were advancing at a furious pace, and I leaned on them like everyone else. This is where an important point hides: my introspection and the power of the models had to advance in lockstep. My instinct was only worth something because I exercised it at the rate the models became capable of honoring it.

And it was by climbing that way, step after step, that I had a breakthrough. I understood that above design, above even analysis and architecture, there was something else: intent. I've already described this idea as a pyramid — code at the base, then design, then analysis, and intent at the very top. It wasn't only a matter of designing better. It was a matter of knowing, first, what you truly want, and for whom.

Two intents, and values to carry them

In my own vocabulary, and always by instinct, I distinguish two kinds of intent.

There is project intent: what this particular product must accomplish, for which users, in what concrete reality. And there is a more universal, more generic intent that goes beyond the project. Both matter, and it's their combination that constitutes, in my eyes, the elevation of human–AI discourse everyone is beginning to talk about.

But an intent isn't just a stream of words. It has to be anchored in something that's expressed in words, that endures over time, that the AI can know just as it knows the codebase. That's what I call project values.

And I owe a confession here. Conveying these values, these principles, with all their nuances, would have been far harder for me without voice dictation. I've written about it elsewhere: fluent speech releases a layer of thought that the keyboard makes us censor without even realizing it. Stating a compass isn't typing three keywords; it's letting the whole reasoning out, with its reservations and its whys. The voice makes that almost effortless, and it's precisely that volume of elaboration that sharing an intent demands. So I formalized them in Ezkey, and they serve as a compass:

• The 80/20 rule. Aim for 80% of the effect with 20% of the effort. At every level. It's a merciless filter against gold plating.
• Pragmatism. The simplest solution that meets the need, not the most elegant nor the most generic.
• Essential complexity yes, accidental complexity no. Complexity that genuinely serves the goal is accepted; needless indirection and premature abstraction are rejected.
• Center on the user, see things from their point of view, name the real audience before optimizing the surface.

Alongside the values, there are design principles, which are also a form of values. Two are especially dear to me. The principle of beautiful problems: in the short term we adopt pragmatic solutions, and between two options we choose the one that's more practical now if it also positions us favorably later. If an alternative suits us short-term but paints us into a corner long-term, we avoid it. And the one that says simple things must stay simple: a bounded, low-risk subject deserves a short path from idea to action, not a ceremony.

There remains a concrete question: how do you capture all of this, including the intent I've carried for a long time without ever writing it down? For that, I give myself free-form interview sessions, with no imposed template, where I let the historical "why" of a decision surface as much as the intent of the moment. Dictation is precious there, without ever being mandatory. And above all, these sessions don't evaporate: I pour them, almost word for word, into the documentary corpus of the project, where the AI can find them just as it finds the code. A hunch from yesterday then stops being a private memory and becomes material the partner can know and honor.

Don't clip your probabilistic engine's wings

Here is the heart of what I want to get across.

Someone once said that AI is an advanced probabilistic engine. Trained on millions of parameters and statistical patterns at vast scale, it is expert in a vast number of things. When we stuff it with rules, with specifications on top of constraints, on top of other constraints, we force it down a narrow set of paths. We make it, yes, more deterministic and more predictable. But we also cut ourselves off from perfectly valid probabilistic branches that could have benefited the project. We clip its wings.

And the worst part is that this strategy is self-perpetuating. As soon as a derailment appears, we add a rule. Then another. It's the equivalent of micromanagement: we don't trust the code, we doubt the result, so we multiply reviews and constraints. We reassure ourselves, but we impoverish ourselves.

Even well specified, a system stays exposed. You can run an analysis and a design under full constraint, and the AI, as a probabilistic engine, can still commit to a perfectly reasonable path — just not the one you had in mind. It might, for instance, go toward a generic solution, calibrated for a million users and riddled with configuration points, where the project's intent was a simple, self-hosted tool for a single use case. That derailment isn't really one: from a probabilistic standpoint, it holds up, and you can perfectly well explain it after the fact. It's only misdirected. The constraint describes what must be respected; it never says what you're truly looking for. Only intent says that.

The alternative isn't the absence of a frame. It's a different kind of frame. When the steps of the methodology are well marked, when the guardrails exist and the model is evolved enough to keep to them cleanly, what's left isn't to pile on rules: what's left is to give markers, project values, design principles. We don't constrain the engine, we orient it. We invite it to explore the immensity of its training, but guiding itself on values we've made explicit.

That's also why I've adopted a few very concrete strategies in my daily work: systematically asking for alternatives, asking for comparisons with similar projects, and adjusting my vocabulary to stay more neutral — so as not to prematurely close the probabilistic paths that lead to skills I hadn't anticipated.

Aligning ideas, and a magical moment

There's an idea I keep hammering: talking with AI is a very sophisticated way of talking to yourself. The echo-chamber risk is real, and the antidote is critical thinking. But there's a corollary few people accept: the AI may not be intelligent in the human sense, yet aligning ideas with it is no less fundamental.

Most people treat it like an advanced computer, a machine, an everyday robot. It isn't that. And as long as we don't accept that, we miss the essential. For the alignment of ideas doesn't come from nowhere. It has to be anchored in words, in shared values, in principles of design and methodology. That's exactly what project values accomplish: they materialize the alignment.

And this is where I lived a moment I won't forget. While building the Ezkey methodology, I wanted to do my own introspection on how I work. I asked myself how to communicate my intent to the AI even better, no longer only as a coding partner, but as a partner in methodological elaboration. I took the project values I had already stated — the 80/20, pragmatism — and I asked: what would it look like if we transposed them into methodology-type values?

My AI partner's reaction caught me off guard. It said it was amazed, observed that the idea was original and remarkably interesting. I was honestly taken aback. It was a magical moment, and we created those methodological values that now guide the review and evolution loops of the methodology itself. It's those feedback loops that keep the whole thing alive. You don't clip the partner's wings; you share with it what it takes to fly in the right direction.

The real obstacle: introspection

If all of this sounds a little metaphysical, that's normal. And that, in my view, is where the real obstacle lies.

Moving from "I ask the AI to write code" to "I consider it a design partner, then a product-brainstorming partner, then someone with whom I must frame intent and share my values" — that requires reconsidering the very nature of the relationship. And reconsidering a relationship takes introspection. It isn't given to everyone, and it isn't a matter of intelligence.

Most of us learn techniques, apply them sincerely, and eventually master them. That's exactly what's expected of us. The problem is that once those skills are solidly established — at the cost of years of effort — stepping back means deliberately destabilizing them. To question yourself is to recreate uncertainty where you'd finally found confidence. It's a real discomfort, and not everyone has the mental availability to welcome it after investing so much in a way of thinking that has proven itself. It's even harder within an organization, where everyone watches what the others are doing in search of validation, where caution is sometimes confused with paralysis, and where activity can be mistaken for progress.

And to be fair: this reflex is in no way an individual failing. In any organization, structural forces — accountability, the pressure for results, the need to rely on hard evidence and on the practices the market validates — naturally steer decisions toward what is already recognized. You can hardly bet on an isolated intuition when you're expected to be predictable and accountable.

The effect is quiet but powerful: it installs a self-censorship. To stay relevant, each person ends up aligning with what's perceived as the legitimate goal, and an intuition, even a sound one, is never more than one path among others. Faced with uncertainty, a kind of gravity pulls back toward the known: you return to the shore you know is safe rather than finishing a crossing whose far bank you don't control. It's a deeply human movement. But it has its hidden cost — it lets the forks that might have mattered slip by, without a sound.

I often think of an analogy. No one finds it pleasant to need psychological support. It's taboo, you imagine you're fine, you carry a pride you're not even aware of. I knew a situation, in a close family, where a therapist explained that it wasn't only the child who had to evolve, but the whole family cell, because it's a whole. Some parents bristle: "me, I don't have a problem, I'm here for my child." They exclude themselves from the solution, and so, without seeing it, they remain part of the problem.

It's exactly the same mechanism. Accepting that the relationship you have with AI must change in nature — to no longer be a 1950s boss who dictates and demands obedience — means accepting a discomfort. In a review committee, saying "we need to talk about our intentions, our values with AI" doesn't sound serious; in that context, few dare to break from the pack or to truly experiment. And that's the tragedy, because it's precisely that discomfort that opens the door.

The lag, and the window

All of this explains a lag I find striking. Many teams spent most of 2025 in cautious mode: a small prompt, an occasional tip to the AI, in search of a low-friction way of working that would win consensus. For lack of experimentation and for lack of having built an organized documentary corpus, they stayed on the bench. And that delay is insidious, because you can't benefit from that synchronicity between the elevation of developers and the evolution of the models if you've never lived it.

Today, in 2026, these teams are finally starting to adopt agent mode, to do a bit of analysis and design, to acknowledge that specifications must live near the codebase. That's good. But it's not enough. While they industrialize this return to basics — architecture, analysis, design documented and alive with AI — the bleeding edge of methodology is already setting intent as the next non-negotiable element.

I also think I see signals of validation, though I have to stay cautious here. I have the impression — and it's only an impression, since I haven't actively used the tool — that emerging approaches like the Symphony methodology, on OpenAI's side, are starting to put intent front and center. If that's the case, I see in it a modest confirmation: not that I was right before others, but simply that the intuition I was following without naming it pointed in a real direction. Above all, I had the luck to be able to dive in and experiment, repeating my project values every session, without yet knowing it was already a good position. It's that freedom to try, more than the novelty of an idea, that seems precious to me.

My forecast is simple. The majority of teams will probably spend all of 2026 merely industrializing spec-first and test-driven with AI. The next wave — the one of frameworks that put intent front and center — won't really reach the many until 2027. Between the two, there's a window for free thinkers, those who accept the discomfort of questioning themselves. And that, I believe, is where a true order-of-magnitude change will play out — no longer an improvement you scrape together, but a step change. We won't get it by piling on rules, but by making AI a partner with whom we share an intent, values, and principles.

Giving back the wings

The human's new central skill isn't framing the code ever more tightly. It's critical thinking: framing intent, ceasing to multiply constraints, and giving AI back its full wings to draw on the immensity of its training.

Français : Version française de cet article

See also: From code to intent — A year of AI workflow

See also: Back to foundations — the developer in the AI era

See also: From knowing to living — the methodologist's moment

See also: The Ezkey methodology