Specification has long been considered a necessary evil.
The agile manifesto, in 2001, preferred “software that works” to “exhaustive documentation”, and twenty years of projects have made it a habit: we document little, late, and no one really proofreads. This disenchantment remained inconsequential as long as humans wrote the code. It’s becoming a serious problem since agents are writing it for them.
From vibe coding to Agentic Engineering
Application development has gone beyond the circle of developers and IT departments: it is often business teams, seduced by the apparent magic of generative AI, who take it on, and the majority of product code is now generated by LLM models. What drives this production remains largely artisanal: prompts improvised in a chat window, then lost when the session closes. Andrej Karpathy called it “vibe coding” in 2023: coding based on intuition, without formalized intention. On an information system, this creates a debt of a new kind, the debt of understanding: code that works, but that no one knows how to explain or master it anymore.
Vibe coding can serve a POC; deployed on a large scale, it becomes a danger, and IT departments understand this. Because a business application requires expertise and mastery at all levels. This is what Agentic Engineering and its emblematic practice, Spec-Driven Development, cover: describing precisely what is expected, in a structured and versioned document, then letting the agents generate the code. The code becomes a verifiable artifact, comparable to the intention, even regenerable. But the real change is not in the tools: engineering thinking is moving from code to specification. The methodology imperatively imposes a code understood and validated by humans, which remains maintainable over time.
Neither return to the V-shaped cycle, nor utopia of “all spec”
Let us guard against two misunderstandings: the return to the documentary V-cycle, or the utopia of software whose code will never be edited again. Recent work distinguishes three levels of maturity. The first, “spec-first”: the specification initiates the generation, the code can then diverge. The second, “spec-anchored”: specification and code evolve together, automated tests verifying their alignment. The third, “spec-as-source”, where the human only edits the specification, never the generated code, remains an early aspiration. In production, the second constitutes the good balance point. Hallucinations and drifting do not disappear because you have written your spec well; they are reduced, and are managed methodically.
We still need to agree on what a specification is in the agentic era. Not a prose specification, but a semi-structured artifact, readable by humans and by agents, whose requirements are based on explicit and standardized business rules, and whose acceptance criteria adopt a formalism inherited from Behavior-Driven Development. Written like this, they are transposed almost directly into the test case: the specification becomes executable.
What this changes in the mechanics of delivery
This shift takes place very early on. Structuring the inputs becomes a real engineering work, organized around a chain of artifacts: a PRD which sets the precise product intention, SPECS which the business analyst carefully validates, an implementation PLAN which the developer validates with the same requirement, and end-to-end tests versioned before the first line of code generated. Added to this is an up-to-date changelog, a trace of each evolution and condition of application maintainability over time. The whole provides a contextual corpus, architectural rules, conventions, project decisions, which the agents consult via standardized protocols.
This return to grace reshuffles the role cards. The business analyst finds a central value: it is he who transforms the business need into requirements that can be exploited by the agents and guarantees that the formalization says what the business wants to express. The client no longer only validates screens in acceptance: he validates the source of truth itself. Acceptance criteria and end-to-end tests are approved in the workshop, then compared to the software at each merge and delivery.
The specification then becomes the contract between the profession, the team and the agents, and the reference when the observed behavior deviates from the declared intention. This drift, once discovered in recipe, is now monitored continuously: tests and static analysis deliver a verdict that does not depend on the mood of a model.
The logic extends beyond the product. Industry standards now codify the very way agents work, in the form of skills versioned like code: cutting a plan into verifiable micro-tasks, writing the tests before implementation, having each increment reread for compliance with the specification then for the quality of the code. In our eyes, this is the already acquired heart of an agentic delivery methodology: this know-how is capitalized from project to project. The object of human judgment shifts: less typing, more review and arbitration on business semantics, software structure and risk. The specification architect is taking over from the prompt engineer.
For the CIO, a governance asset
Why worry about it now? Because a heritage of versioned specifications, aligned with the code, changes the position of the IT department on several fronts. The documentation stops lying, since the tests verify it. Auditability becomes native, when European regulations on AI impose traceability. Reversibility becomes real again, with regard to service providers and tools. And they will be the raw material for regeneration, the day it is necessary to change framework or architecture.
Code has never been easier to produce. The formalized and qualified intention which governs it has become rare again. In the agentic era, the question to ask is no longer “what have we coded?”, but “what have we specified?”. The quality and maintainability of the code remain non-negotiable.
