‹ Zurück

There is no spec-driven development. There is just rigorous software engineering.

Everything else is vibe coding — to be a bit provocative here.

 

How you approach working with a software development agent — which software engineering practices you choose — depends on a constellation of factors:

• How well do you understand the problem or feature? Are you exploring an idea or optimizing a known solution?
• Is this brownfield or greenfield development? Are there existing conventions, patterns, or tech stack decisions that are non-negotiable? What existing code can be used as reference?
• Who else needs to understand the purpose and the implementation, and over what time horizon? Are we building something that will be rebuilt from scratch in a year, or maintaining a piece of software for two decades?
• How familiar is this territory for the agent? Has the problem space been well represented in its training data, giving it something similar to draw on — or is this novel enough that it's operating without a good reference point? Remember: it's not true understanding; it's about predicting the next token.
• How much risk can you tolerate if the agent does it sub-optimally? Is this something you can fine-tune with the customer to find the best solution or are there clear expectations?
• What is the scope? A complete product, a feature, a user story, a change request, a bug fix? The narrower the scope, the less leeway the agent has.

 

As Simon Wardley described — there is no one-size-fits-all engineering process, even within a single company or product. And by the same logic, there is no single correct way to use an agent or agent framework. The right approach varies: how much information you need to provide and when, and how and when to review what the agent produces.

 

This post focuses on information provisioning — because that's where the most important shift is happening.

 

What's genuinely new here, compared to traditional software engineering, is the way and granularity at which the right information needs to be made available — user stories, requirements, architecture descriptions, test case specifications, and so on.

A junior developer learns over time. An agent cannot. All relevant information has to come from somewhere, every single time. It has to be explicitly available — everything that previously lived in the mind of a developer, absorbed through collaboration, context, and experience, now has to be written down and surfaced deliberately. Martin Fowler's team puts it well when they talk about encoding team standards.

 

This creates a new need: a structured, reliable way to manage what information gets provided to an agent and when. This is what the emerging practice of context management and harness engineering addresses. The question is whether we're comfortable letting an agent explore a hierarchical structure of markdown files and hope it finds the relevant bits — or whether we need a more controlled mechanism to steer it in the right direction, without resorting to manual prompting every time.

 

Well — it depends on what we're trying to achieve. (See the questions above.)

 

 

Here is where I think something genuinely interesting emerges for certain industries.

 

Given the need to make information explicit and structured for agents, I believe that software and systems organizations in regulated domains — automotive, aerospace, transport, command-and-control, medical — are extremely well positioned to take advantage of agent-based development. These domains have long demanded well-defined processes, carefully structured engineering artifacts, and managed relationships between those artifacts through traceability.

 

What was once largely compliance overhead now becomes a strategic asset. Engineers in these fields already know how to do proper requirements engineering and rigorous review. They know how to test and validate. The information is connected, structured, and — crucially — already there, ready to be consumed by agents.

 

There is now a real opportunity for organizations that live these processes to extract compounding value from the investment they've already made in regulatory compliance.

 

In my next post, I'll outline how software engineering process modeling is one concrete mechanism for addressing the obstacles — Limited Context Window, Selective Hearing, … — and the anti-patterns — Obsess Over Rules, Distracted Agent, … — that get in the way of efficient agent usage. And not just in regulated domains, though that's where the opportunity is clearest.

 

 

Until then: however you develop, whatever process you follow — just don't do waterfall.