A few months ago, I discovered the Lean Tech Manifesto by Fabrice Bernhard and Benoit Charles-Lavauzelle, an approach that immediately appealed to me for its ability to enrich traditional agility with lean concepts. Today, as specification-driven approaches gain popularity in application development, I find myself asking a fundamental question: are these new trends compatible with the principles of the Lean Tech Manifesto, or do they mark a real paradigm shift?

This reflection particularly strikes me because I observe, in my current projects, a rise in practices like OpenAPI-first, contract-first testing, or architectures driven by specifications. These approaches sometimes seem to be in tension with certain lean principles I’ve adopted, notably “just in time” and the priority given to immediate customer value.

My understanding of specification-driven approaches

When I talk about specification-driven approaches, I’m referring to this growing trend that places specification at the heart of the development process. Unlike traditional methodologies where documentation often follows code, here it precedes and guides it.

In my recent experience, I’ve been able to observe several manifestations of this approach. API-first development, for example, where we start by rigorously defining the OpenAPI contract before even writing the first line of code. Or contract testing, where specifications become the source of truth for validating interactions between services.

I’ve also had the opportunity to explore in detail the GitHub Spec Kit, which perfectly illustrates this specification-centered philosophy. GitHub’s approach transforms documentation from an administrative chore into a real quality catalyst, with a structured seven-step process that values upstream thinking.

What strikes me most is the underlying philosophy: rather than letting architecture and interfaces emerge during development, we explicitly define them from the start. This approach promises better predictability, clearer communication between teams, and a reduction in integration errors.

But I also notice that this method imposes a particular discipline. It requires understanding the need well before starting to code, which may seem obvious but goes against certain agile practices where we sometimes favor rapid iteration and learning through experimentation.

The legacy of the Lean Tech Manifesto: what remains relevant

Rereading my notes on the Lean Tech Manifesto, I realize that several of its fundamental principles retain all their relevance in a specification-driven context. And this is perhaps where the first key to compatibility between these two approaches lies.

The principle of “Value for the customer” remains absolutely central. Whether we start from a detailed specification or a more iterative approach, the ultimate goal remains creating value for the customer. Specification-driven approaches can even reinforce this principle by forcing us to make this value explicit from the design phase. When I define a functional specification, I must necessarily ask myself: “How does this bring value to the end customer?”

The notion of “Building a learning organisation” also finds its place in specification-driven approaches. Contrary to what one might think, writing detailed specifications doesn’t mean freezing the learning process. On the contrary, it can structure it. Each iteration on a specification, each documented feedback, each contract evolution contributes to the team’s collective learning.

What particularly strikes me is the persistence of the importance of timing in problem detection. As I had highlighted in my discovery of the manifesto, the moment when we detect a problem is more critical than the problem itself. Specification-driven approaches excel in this area: they allow identifying inconsistencies, ambiguities, and design errors well before the development phase.

Finally, the spirit of technology-enabled network of teams naturally translates into specification-driven practices. Specifications become a common language, a means of synchronization between distributed teams, exactly in the spirit of the Lean Tech Manifesto.

The tensions I observe between the two approaches

Despite these points of convergence, I cannot ignore certain real tensions between the spirit of the Lean Tech Manifesto and specification-driven practices. These frictions deserve to be explored honestly because they reveal fundamentally different philosophical choices.

The first tension concerns the principle of “Right first time and just in time”. The Lean Tech Manifesto advocates an approach where we deliver just what’s needed, at the right time, without over-engineering. However, specification-driven approaches can push toward the opposite: exhaustively defining functional specifications and behaviors before even knowing if certain functionalities will actually be used.

The second friction concerns iteration speed. One of the concepts I had particularly appreciated in the Lean Tech Manifesto was this ability to react quickly to changes, to pivot without excessive friction. Specification-driven approaches, by their very nature, introduce a certain inertia: modifying a functional specification often involves cascading changes across multiple documents, updating acceptance criteria, resynchronizing teams.

I also feel tension around progressive needs discovery. My lean experience taught me the importance of letting solutions emerge through interactions with users. But when I must define detailed functional specifications from the start, I partially deprive myself of this capacity for organic adaptation. It’s a dilemma I regularly encounter: how to reconcile the need to clearly specify expected behaviors with the flexibility necessary for innovation?

Finally, there’s this question of initial cognitive investment. The Lean Tech Manifesto encourages starting simple and gradually complexifying. Specification-driven approaches often require significant intellectual investment from the start, which can go against the principle of minimizing intellectual waste.

My analysis of their potential complementarity

These two approaches may not be as antagonistic as they appear at first glance. In fact, I think they can reinforce each other if we know how to articulate them intelligently.

My first intuition is that specification-driven approaches can serve as guardrails against lean drift. Because let’s be honest: the lean approach, when misunderstood, can lead to “quick and dirty” disguised as agility. The discipline of specification forces us to ask the real questions from the beginning: what exactly are we building? For whom? Why? This constraint can paradoxically liberate the team by clarifying scope and objectives.

Conversely, the lean spirit can avoid the pitfalls of over-specification. By keeping in mind the principles of customer value and “just enough,” we can use specification-driven approaches with discernment. It’s not about specifying everything, but specifying what has value. This nuance makes all the difference between a productive specification-driven approach and bureaucratic drift.

What particularly excites me is the possibility of iterative specification. Rather than seeing specification as a fixed deliverable, we can envision it as a living artifact that evolves with our understanding of the problem. Start with a minimal specification covering priority use cases, then enrich it as we learn. This is exactly the lean spirit applied to specification-driven practices.

This approach becomes all the more realistic with the emergence of AI agents capable of generating and maintaining specifications. One of the traditional barriers to specification-driven approaches was precisely the human cost of creating and maintaining these documents. But when an AI agent can produce a detailed functional specification in minutes, revise an interface contract in real-time, or automatically synchronize multiple specification documents, the paradigm changes completely. Modification velocity becomes compatible with lean agility, and documentation thoroughness is no longer a barrier to rapid iteration.

I also observe that these two approaches share a common obsession with reducing costly errors. The Lean Tech Manifesto emphasizes early problem detection, specification-driven approaches allow anticipating them even earlier. It’s complementary: specification prevents design errors, lean optimizes detection of execution errors.

Finally, both approaches value communication and team alignment. Specification becomes a shared language, lean provides the methodological framework to maintain this alignment over time. One structures communication, the other optimizes it.

What I retain for the future of development

At the end of this reflection, I no longer see specification-driven approaches and the Lean Tech Manifesto as competing philosophies, but rather as two complementary facets of an emerging methodological maturity.

My conviction today is that the future of development will be hybrid. We no longer have to choose between agility and specification rigor. Artificial intelligence acts as a catalyst that makes this synthesis not only possible, but necessary. In a world where system complexity is exponentially increasing, we need both the discipline of specification to manage this complexity, and lean agility to maintain our adaptability.

What guides me now is the idea that each project context will call for its own dosage between these two approaches. For a critical system with multiple distributed teams, I’ll lean toward more initial specification. For an exploratory prototype, I’ll favor the pure lean approach. And for most projects, I’ll aim for that balance zone where specification structures without rigidifying, where agility guides without compromising quality.

I’ve also gained the conviction that specification skills will become as crucial as coding skills. Knowing how to clearly express a need, model interactions, anticipate edge cases, these are no longer secondary “soft skills” but technical competencies in their own right. And paradoxically, mastering these skills makes you more agile, not less.

Finally, I retain that this evolution toward AI-assisted specification-driven approaches could well solve one of lean’s great challenges: how to keep documentation up to date without slowing development pace. If specifications become as easy to modify as the code itself, then we will have truly reconciled these two worlds.

This synthesis between Lean Tech Manifesto and specification-driven approaches doesn’t represent an end in itself, but rather a step toward methodological maturity that will allow us to build systems that are both robust and adaptive. This is the direction I plan to explore in my future projects, always keeping in mind that the best methodology remains the one that effectively serves end users.