Converent
AI Forces The Hand Of Systems Thinkging
Perspective

AI Forces The Hand Of Systems Thinkging

Requirements didn’t disappear because they were wrong. They lost leverage because control moved downstream. As AI shifts development toward spec‑to‑test‑driven workflows, that control moves back upstream — and requirements regain their role as the system’s source of truth.

Requirements Resurrection?

For years, “requirements” have been treated as a necessary evil – something to rush through, minimize, or bypass entirely in the name of speed and agility. When projects succeed, requirements are forgotten. When they fail, requirements are blamed.

And yet, we are approaching a moment where requirements may become more important than they have ever been.

Not because humans suddenly got better at writing them – but because we finally ran out of ways to avoid them.

The Great Misunderstanding of Requirements

Requirements are often viewed as the primary output of systems engineering. They are not.

In reality, requirements typically represent maybe 20% of what systems engineers manage. The rest includes architecture, interfaces, trade studies, risk management, safety and reliability analysis, verification strategy, and lifecycle governance.

Contrast that with software engineering, where the dominant deliverable is code. Or any other downstream stakeholder that has ownership over a more constrained set of deliverables.

This difference matters. Systems engineering exists to define and control intent across complex, multi‑disciplinary systems. Software engineering exists primarily to realize behavior within that intent. Again, same applies to other disciplines that have had cascade of allocated requirements released to them.

When teams conflate these roles – or treat requirements as a lightweight preamble to “real work” – they create a vacuum that inevitably fills with assumptions, misinterpretations, and late‑stage surprises.

Why Requirements Feel Like Overhead

The real cost of requirements is not process – it’s language.

Requirements are:

That is an extraordinarily high bar for humans to adhere to when managing 100s or 1000s of objects.

A single word choice can change test scope, implementation strategy, or safety interpretation. A missing qualifier can invalidate an entire verification plan. A vague statement can be “satisfied” in a dozen incompatible ways.

How many times have the Engineers left the meeting with “decisions made” that weeks or months later manifest in a curious set of similar but slightly different decisions?

This is why requirements engineering feels slow and painful. It demands precision from humans who are simply not wired for sustained linguistic rigor at scale.

The Convenient Scapegoat

Humans are remarkably bad at rigorous requirements engineering.

And yet, when systems fail – especially late in the lifecycle – the first thing blamed is “bad requirements” or “not enough requirements.”

What’s often missing from that conversation is this:

The same teams blaming requirements rarely reviewed them properly in the first place.

Instead, requirements were written once, filed away, and ignored – until they became inconvenient. If, indeed, they were written at all.

Complexity Broke the Old Model

Modern systems evolve faster than most teams can comprehend.

Requirements don’t just grow in number; they grow in interdependence. Emergent behavior, cross‑domain coupling, and safety interactions quickly outpace what any individual – or isolated agile team – can reason about locally.

Many organizations respond to this by doubling down on “agility,” which in practice often means:

This works – until it doesn’t.

At scale, complexity overwhelms intuition. Traditional, human‑centric requirements practices simply stopped keeping up.

In that sense, requirements didn’t die because they were wrong.

They died because humans couldn’t manage them anymore.

And as an aside the Agile Manifesto never once said that to be Agile was to disregard the need for Requirements Engineering.

Enter AI (and the Wrong Assumptions)

Now AI arrives, promising to:

And the immediate assumption is: finally, the requirements problem is solved.

But here’s the uncomfortable truth:

AI does not remove the need to review requirements.

It amplifies it.

Every serious AI system today must be grounded. Its outputs must be checked, validated, and contextualized. Which means the very activity many teams avoided – careful review of requirements – is now mandatory.

Ironically, the people most excited about AI‑generated requirements are often the same ones who never reviewed human‑written requirements properly either.

The technology changed. The humans didn’t.

So why would the outcome be different?

Spec‑Driven Development Is the Real Shift

The real change isn’t AI writing requirements.

It’s spec‑driven development.

As code generation becomes increasingly automated, the developer’s role shifts. Writing implementation code becomes less central as generation and synthesis improve.

What replaces it is not chaos, but clarity:

Those specifications may be textual, model‑based, or both. But they will be authoritative.

The bottom of the lifecycle – implementation – will demand less human oversight. The effort is shifting upward, toward definition and verification.

This aligns naturally with test-driven development. As specifications become executable and verifiable, tests automatically derived from specs, and implementation is progressively absorbed into tooling.

Why Requirements Are Coming Back

This is where requirements re‑enter the spotlight – not as documentation artifacts, but as control mechanisms.

They are no longer there to describe what was built after the fact.

They exist to ensure the system that is built is exactly what was intended.

In a spec‑driven world:

That makes them more — not less — valuable. In fact, they are now positioned to realize their true potential as the backbone — or perhaps the nervous system — of the digital thread.

Systems Engineering Comes to the Fore Again

We’ve seen this before.

In automotive, the shift to model‑based development pulled most control engineers up the lifecycle. Many can no longer read – or even care about – the generated code. Although they may not realize it they are largely satisfying the software design step more than implementation. The two are steps are now almost inseparable.

AI will push this further.

As implementation becomes abstracted away, systems engineering becomes unavoidable. Someone must own:

That someone is not a coding assistant.

It’s systems engineering.

What This Means for Teams Building Real Systems

I see this shift already well underway and gathering a momentum.

Not in the hype cycles around AI tooling, but in the quiet realization many teams are coming to: complex systems don’t fail because teams can’t build fast enough – they fail because intent is lost.

As our ability to build accelerates, the risk compounds. We will produce more systems faster, while steadily losing track of what those systems were meant to do. The result is not just technical debt but mounting financial and organizational costs.

Some may say that some organizations are not Model Based at the implementation end of the lifecycle and this may prove to be true – but they are essentially ahead of the majority in deferring to spec-driven development and weighing more heavily on systems engineering practices.

Requirements, specifications, models, and verification are not bureaucratic artifacts. They are the only scalable way to preserve intent as complexity, automation, and abstraction increase.

AI will expose where systems thinking is missing and amplify the consequences when it is. This makes the case for a systems-first approach unavoidable.

Spec‑driven development, grounded requirements, and verification‑first thinking demand a discipline that is comfortable operating above code – one that can define what must be true, not just what can be built.

That discipline is systems engineering.

Converent exists to help teams make this transition deliberately:

The resurgence of requirements isn’t about returning to the past.

It’s about building systems that survive the future.

And in a world where machines increasingly write the code, the value shifts to those who can clearly, unambiguously, and correctly state what the system must do – and prove that it does exactly that.

← Back to perspectives