Between 2012 and 2020, I worked at Valeo as a software development engineer and later as a SW project manager. There, I learned what a bureaucracy overdose feels like. 🦾 We had to learn and strictly follow the ASPICE (Automotive SPICE) standard, which describes automotive software development processes. This was essentially based on the development processes of the so-called V-model (Germany, MOD, 1992) and adapted for the automotive industry. (I’ll write more about the relationship between the V-model and ASPICE in another post.)

System Engineering and Verification

Source: [Wikipedia]

The model can be divided into two main parts. The left (descending) arm of the V is the specification stream, which includes cost-effective requirement analysis, where tasks related to specification and design are performed.

The right (ascending) arm of the V is called the testing stream because it’s all about testing. Mentioning several levels, including the most common (and minimum): unit, feature, integration, performance, and user acceptance testing.

At the apex of the V is the implementation itself (writing the CODE code 😎).

I wrote this just to give a brief insight into the fact that these existed before (in the ’80s and ’90s), and to show how predictable, pre-planned, document-centric development processes handled requirements and designs.

So, What is Important?

The design. A common question and a source of confusion is: “What is the difference between a requirement and a specification (detail)?” This is relatively simple to answer.

While the requirement focuses on “What?” (What) needs to be created, the specification already focuses on “How?” (How). Often at several levels: technical details, high-level design, low-level design, integration, etc. If you understand the essence of these two levels well, many things become simplified from then on. (It’s like life above or below water. It’s quite hard to confuse them if you’ve ever tried to breathe underwater as a child.)

How Does Artificial Intelligence Enter the Picture?

The Spec-Driven Development method, well-prepared and supported by AI, is also based on these abstractions and logical breakdowns. I have already examined several solutions (BMAD, Github SpecKit, Open Spec), and they all start from this premise. They couldn’t start from anything else, as it is so logical and effective that it would be a shame to discard the well-proven knowledge of our predecessors.

We, software developers, hate creating documentation. It’s true: well-written code speaks for itself. It doesn’t even need comments. For decades, we have been fighting documenting with fire and sword, and it almost counts as an insult if someone says: “This should be written down in a doc” or “Is there documentation for this?”. Eeeeh… we usually don’t like it.

Unfortunately (or thank God), this thinking will (must) turn around from now on, because in the AI world, documentation is one of the greatest values. Why? Because AI is truly in its element when it can consume, process, and analyze massive amounts of documentation. Of course, it was raised on this, this is what it learned.

You can’t just give a Large Language Model a torn-out page of a book and say: “Here, learn!” Large amounts of input data are its lifeblood. Not only in its “childhood” but also when you tell it in your prompt: “You are now a principal engineer…”

The Bottom Line

In the coming times, it won’t be the code that holds the business value (it already isn’t), but the well-formulated idea, specification, and documentation. Why? Because this is what can be talked about, shown to others, and sold to a customer. It is written in human language, which anyone active in the given domain (e.g., healthcare, home buying, psychology) can understand.

Don’t get me wrong, I also started my career as a software developer, but I often realized that even my direct boss didn’t understand what I wanted with the code if I didn’t write it down or draw it for him. So how much would a manager (owner) three levels above understand? Does it even interest them? No.

So, until now, we documented because the process or the boss asked for it. From now on, we won’t just do it for that, but for our own well-understood developer interest, because this is how we can effectively collaborate with AI. Or rather: this is how we can properly instruct it on what to create for us. Or have it perform a risk analysis, resource estimation, and cost estimation before some modification.

We are already at the 5th generation of language abstraction, which we can write in natural human language. This is already intention-based design. We describe what we want, plus our constraints. AI can already work (develop) from this.

Further Benefits

• Architectural Evolution: The developer learns an architectural mindset from artificial intelligence. At a very high level, as if talking to a principal engineer 24/7. You must see: even if you don’t want to write your code with AI, it already represents a huge advantage in the design phase.
• Meaningful Client Needs: Owners and clients finally learn to formulate what they want in a meaningful, thoughtful way before coming to a developer with their vague requests. In fact, some will be so prepared that they arrive with graphic designs (e.g., Figma), which can already be discussed.
• Multimodal Inputs: Thanks to AI’s capabilities, the client can now convey their ideas not only with text but also with photos, hand-drawn sketches, or even a quickly recorded voice message. Modern models can process these mixed formats into a unified, structured specification, so nothing gets lost in translation.

In the automotive industry, I learned that the mechanical design (the black plastic) drives the project, not the software. (In many cases, project managers used it to solve development or manufacturing inaccuracies.) Both the car manufacturer and the buyer only see the black plastic in the end, so the design, the feeling moves the market. This is what makes something sellable (or not).

In a future post, I will also cover how we can turn the wheel even more in our favor with the help of AI. Which, in my opinion, will remain the only value-creating path for software developers.