With Agentic AI, the Specification Becomes the Real Software Asset Again

From Vibe Coding to Agentic Engineering

Application development has spread beyond the circle of developers and IT departments: it's often business teams, drawn in by generative AI's apparent magic, who take it up, and most of the code produced today is now generated by LLM models.

What drives this production remains largely artisanal: improvised prompts in a chat window, then lost once the session closes. Andrej Karpathy coined the term in 2025: "vibe coding". Coding by intuition, without formalised intent.

Within an information system, this creates a new kind of debt: comprehension debt: code that works, but that no one can explain or truly control anymore.

Vibe coding can serve a proof of concept; but deployed at scale, it becomes a danger, and CIOs have understood this. An enterprise application demands expertise and control at every level.

That's what Agentic Engineering covers, along with its flagship practice, Spec-Driven Development: precisely describing what is expected, in a structured, versioned document, then letting agents generate the code.

Code becomes a verifiable artifact, comparable against intent, even regenerable. But the real change isn't in the tools: engineering thinking shifts from the code to the specification. The methodology strictly requires code that is understood and validated by humans, and that remains maintainable over time.

Neither a Return to Waterfall, Nor the Utopia of "All Spec"

Let's avoid two misreadings: a return to documentation-heavy waterfall development, or the utopia of software whose code we would never edit again. Recent work distinguishes three levels of maturity:

-Spec-first: the specification kicks off generation, and the code can then drift.
-Spec-anchored: specification and code evolve together, with automated tests verifying their alignment.
-Spec-as-source: humans only ever edit the specification and never the generated code. (This is still an early aspiration.)

In production, the second level is the right point of balance. Hallucinations and drift don't disappear just because the spec was well written; they are reduced, and managed with method.

We still need to agree on what a specification is in the agentic era. Not a prose-based requirements document, but a semi-structured artifact, readable by humans and agents alike, whose requirements rest on explicit, standardised business rules. Its acceptance criteria, in turn, adopt a formalism inherited from Behavior-Driven Development. Written this way, they translate almost directly into test cases: the specification becomes executable.

What This Changes in Delivery Mechanics

This shift plays out very far upstream. Structuring inputs becomes real engineering work, organised around a chain of artifacts:

-a PRD that sets the product's precise intent;
-SPECS that the business analyst carefully validates;
-an implementation PLAN that the developer validates with the same rigour;
-end-to-end tests versioned before the first line of generated code.

On top of that, a changelog kept up to date, tracing every change and underpinning long-term application maintainability. All of this feeds a contextual corpus: architecture rules, conventions, project decisions, that agents consult via standardised protocols.

This reshuffles roles. The business analyst regains central value: it's the business analyst who turns business needs into requirements agents can act on, and who ensures the formalisation says what the business actually requires.

The client, for their part, no longer just signs off on screens during acceptance testing: they validate the source of truth itself. Acceptance criteria and end-to-end tests are approved in workshops, then checked against the software at every merge and release.

The specification then becomes the contract between the business, the team, and the agents, the reference point whenever observed behaviour strays from stated intent. This drift, once discovered only during acceptance testing, is now monitored continuously: tests and static analysis deliver a verdict that doesn't depend on a model's whimsy.

The logic extends beyond the product itself. Industry standards are now codifying the very way agents work, in the form of versioned skills, just like code: breaking a plan into verifiable micro-tasks, writing tests before implementation, having every increment reviewed for compliance with the specification and then for code quality.

In our view, this is already the established core of an agentic delivery methodology: this know-how compounds from project to project. The focus of human judgment shifts: less typing, more review and arbitration on business semantics, software structure, and risk.

The specification architect succeeds the prompt engineer.

A Governance Asset For the CIO

Why care about this now? Because a portfolio of versioned specifications, aligned with the code, changes the IT department's position on several fronts:

-documentation stops lying, since tests verify it;
-auditability becomes native, just as European AI regulation requires traceability;
-reversibility becomes real again, both with vendors and with tools;
-these specifications will be the raw material for regeneration the day it becomes necessary to change framework or architecture.

Code has never been easier to produce. The formalized, qualified intent that governs it, however, has become rare again.
In the agentic era, the question to ask is no longer "what did we code?" but "what did we specify?"

The quality and maintainability of the code, meanwhile, remain non-negotiable.