“What do I need that for?”

That is the number one question I get after a meeting updating the architecture with a function owner. How do you answer that question? The architecture already exists in their head, is written down somewhere else, the function is already being built, and many decisions have already been made. We just finished the first session—one of many—and the first thought of the function owner was: What do I need that for?

How do you answer this question? The go-to response is usually: “We need to keep the system architecture up to date.” While this is true, it takes responsibility away from the function owner. Additionally, the function owner is asking what they need it for, which implies they don’t see any value in a shared system architecture. So how do you answer a question when the other person doesn’t see the value? The go-to answer actually confirms what the function owner implies: there is no direct value for them.

If the function owner asks this question, we have to assume that they already have an architecture in their head or written down somewhere else—not in the shared system architecture. Otherwise, the question would never cross their mind in the first place.

If we take a step back and ask ourselves why we create a system architecture, the answer is simple: to provide every discipline with a shared foundation for making decisions.

So, what does it mean when we update the architecture together with a function owner? By updating the system architecture, we add new information to it, making it the single source of truth. Instead of giving the academic, go-to answer, we should explain that the function owner needs the architecture for their next decision.

More importantly, they are not updating it just for themselves—they are updating it for every other function owner who needs to make decisions that align with the rest of the system. Furthermore, updating the architecture often reveals information the current function owner hadn’t considered. Looking beyond the boundaries of their own function and into the surrounding system often exposes gaps, dependencies, or assumptions that would otherwise remain hidden.

The function owner who asks, “What do I need that for?” is treating the architecture as a record of the past. By updating the architecture, the architecture grows together with the system.

Every decision changes the system. Every change should update the architecture. Otherwise, the next engineer is making decisions based on yesterday’s understanding. When the architecture can no longer be trusted, everyone starts building their own version of the system – whether it’s in their head, on a whiteboard, or in a spreadsheet. Function owners do not suddenly stop making decisions; they simply stop making them together. That is the moment the single source of truth stops being singular.

So our answer to the question:

“What do I need this for?”,

should never be:

“Because it’s part of the process”.

Our answer should be:

“Because someone else’s next decision depends on yours. And you never know what you didn’t think about until the architecture shows you.”

As the name suggests, ASPICE is there to determine the capability of a software development process. ASPICE has the reputation of being about documentation. So when people hear they have to fulfill a certain ASPICE level, all they hear is that they have to document their every move.

Additionally, ASPICE requires you to think about the architecture beforehand, develop different architectural solutions, compare them, and choose one. This shifts the focus toward architecture and takes time.

So when it was my turn to create a comprehensive architecture, after interviewing different department heads and sitting at my desk in the middle of an open-plan office, I suddenly felt my manager breathing down my neck, asking me why I was wasting time on architecture and hadn’t built anything yet.

To which I replied:

“If you are complaining about the cost of good architecture, do you know how much no architecture costs?”

Situations like this follow me wherever I go.

Another situation was when a function owner didn’t know where their component lived in the system architecture. They owned it on paper but couldn’t see it in context.

Or when I played charades with a different function owner. While we were creating the system architecture, I asked them what one of their signals was called. Their answer wasn’t a name, nor was it “I don’t know.” It was:

“I think.”

The second function owner had just enough visibility to assume they understood. Just enough knowledge to feel confident.

The result in the first case? The model changes, decisions get made in isolation, and people don’t know. Communication flows shift, and no one updates their mental model.

The second function owner made decisions based on incomplete information. Integration then revealed surprises that should have been visible in the architecture from day one.

This is where Model-Based Systems Engineering (MBSE) comes into play: an approach that places systems engineering artifacts into a model, using SysML as the de facto standard language to visualize the system architecture.

Everything in the development process is based on the architecture. Therefore, I am convinced that the time spent creating a good architecture is worth it.

It costs far more time to figure out decisions that were made without a shared architectural understanding, but those costs are rarely accounted for because people are busy building hardware or software. The additional iterations, the extra engineering effort, and the missed deadlines are often treated as separate problems instead of consequences of not having a shared architecture.

The upfront investment, however, is highly visible. It takes longer before the first element of the system architecture is created.

Which is why my manager was breathing down my neck.

Additionally, SysML has its own syntax and semantics, which means you can fully describe a system. But, like every language, it requires fluency—both to create the architecture and to understand it. Neither function owner was fluent in the language, which became obvious through their lack of understanding of the architecture.

Lastly, I want to show you a third function owner. The one who openly says:

“I’ve heard that term once, during a training session last year, and haven’t touched the architecture since.”

Now I come in to update the architecture, but I also have to explain why I am doing things a certain way - the same way they had been done for the past year.

For this function owner, integration doesn’t come as a surprise. What they see are updated names they no longer like, even though they previously approved them without really understanding what those names represented.

What we have here are a few examples of the archetypes you encounter when introducing a new tool, a new process, or even a new modeling guideline.

I call them archetypes because they are recurring patterns. These types emerge, in one form or another, whenever something new is introduced into an existing way of developing systems.

MBSE is becoming increasingly important in Germany and across European industry. It is intended to help manage the growing complexity we continue to pour into our systems.

However, MBSE also requires a change in thinking and in human behavior. Because of this, it initially seems harder to implement. There is an upfront investment in teaching and training.

Furthermore, that knowledge needs to be cultivated. A training session once a year isn’t enough. Neither is owning a component you can’t locate. Or approving a signal name you can’t define.

As I said before, SysML is a formal language. It requires fluency to both read and write the architecture.

My manager wasn’t wrong to notice a cost. He was looking at the wrong one. He saw the price of creating a good, agreed-upon architecture. He never saw the price of not having one at all.

The same way we learn to read is by reading. The same way we become fluent in architecture is by reading it, using it, and understanding it—step by step.

I don’t mind filling out any form. I do mind that, in 2026, there is no standardized way of entering my data digitally. I have a national ID card with NFC and my data stored on it. I have a national insurance card with my personal data stored on it. Shouldn’t that be enough?

If you use paper, why does it have to be three separate forms with all the same information on them? Aren’t you digitizing those for better storage? Then why not digitize them from the start? Why is it that, in 2026, there is no single way in Germany to capture my data, medical history, and GDPR preferences digitally?

Paper does not create enough friction to digitize paper. Additionally, paper has always been used to gather personal information.

Another point is that a cross-section of the population is visiting a doctor’s office at any time: people who are more used to technology and people who are less used to technology. Giving people who are not as keen on technology a device to enter their personal information could create more friction than just a paper form, or three.

And yet, in the same country, in the same year, we can find some smart factories such as BMW’s, where they can assemble a car almost automatically. The friction involved in creating this technology seems to have been worth it.

This is not coincidental. If we look back in history, Germany developed a strong industrial culture rooted in mechanical engineering. If a company released a product, it was mechanical work, it worked flawlessly, and how it worked was transparent.

Then, around the turn of the millennium, software entered the stage. The main difference between mechanical systems and software is that software is less transparent and more prone to errors, which also has to do with the underlying hardware. Software is less predictable than mechanical systems because it interacts with user behavior and different hardware environments. But this uncertainty can be designed for.

In other words, the perfectionism behind the label “Made in Germany” was built on systems you could see, touch, and verify.

Lastly, when I finished high school, I did some sales work for a local phone carrier. My task was to sell phones with an internet flat rate. While I couldn’t sell internet for your smartphone, I tried to sell “mobile internet.” Unfortunately, this did not help, as people thought it was the same thing. They were not “going onto Google” while they were on the go. The fact that apps need an internet connection was not established knowledge.

What we see here is that while software has arrived in industry, software hasn’t fully arrived in society. We had information at our fingertips, but didn’t know how to use it.

Germany has a unique view of technology. On the one side, we have the idea that mechanical work is transparent and more reliable compared with software, which enhances the need for perfectionism. At the same time, we see software as a toy rather than a tool.

While industry shows what is possible with software, it is outside of the engineering halls that this statement holds true.

Michael Jastram writes that the problem is not the engineer; it is, however, the system they operate in, as he puts it in terms of slow adoption rates, which are caused by a deep preference for certainty over speed [S1].

Philipp Raasch describes it as a coordinated collective versus individual players: China building an industrial system designed for speed, while German companies compete alone. He adds that Germany does not understand software and that engineers in companies such as CARIAD try to break free of a world of tradition [S2].

This shows that it is a systematic issue rooted deeply in our society.

The issue is not that we use paper rather than digital forms. Paper has been used for over 2,000 years to store information. The issue lies in the uncertainty.

Uncertainty avoidance plus mechanical engineering equals world-class reliability.

In that framing, uncertainty avoidance plus software tends to lead to paralysis.

The trait isn’t wrong. The application is mismatched.

This uncertainty, this not knowing how a system actually works, stands in the way of progress.

Next time you use a system, explore what other functionality the system offers. Simply because people who don’t understand the systems around them adapt to them. People who do understand them shape them.

S1: https://productvelocity.org/resources/its-not-the-engineers/

S2: https://www.linkedin.com/pulse/das-ende-der-autonation-deutschland-philipp-raasch-5p1gf?utm_source=share&utm_medium=member_android&utm_campaign=share_via

We started with verification and validation – not because AI can’t do more, but because we needed to prove the basics work first. And while doing that, I realised something: the tasks AI handles first are exactly the ones humans do worst. Repetitive checks, pattern matching, copy-paste errors, and ensuring that standards are upheld in documents. So why requirements? On the one hand, fixing a requirement costs more and more depending on the development stage. A requirement error that is caught in the design phase is cheaper to fix compared to when it is found during acceptance testing. On the other hand, requirements engineering is one of the first steps of systems engineering. If we master the basics, we can compound more tasks and disciplines.

So when AI can do a repetitive task as well as humans, does it imply it can replace me? Or does adding more tasks that AI can do imply I will be replaced step by step? If we take my AI assistant and continue to add tasks and engineering disciplines, we thereby create a closed-loop system: where the AI performs safety and security analysis, where risks need to be mitigated by requirements, those then have to be verified and validated. Based on those requirements, the architecture has to be updated, and lastly, test specifications have to be created. It is a very futuristic-sounding image, but not that far from the present. It is only a matter of time before we see AI do one of those tasks fully autonomously. If we take that picture of the closed-loop system, we can argue that, yes, I am building my own replacement – slowly but steadily.

According to an Anthropic study [1], AI doesn’t create structures; it works within them. Well-structured inputs lead to consistent outputs. But consistency is not the same as correctness. The vice versa is also true: poorly structured inputs increase the likelihood of inconsistent or unreliable outputs. It is important to mention that this is not only true for me and my situation – It is true for everyone. Which means AI can only replace me if the underlying structure is already there. In other words, AI first and foremost makes workflows visible, and the AI result tells us about the state of those workflows. While a lot of industries have good workflows in place that can be automated, automation does not automatically mean replacement. So does AI replace me?

Even though I am working from within, I can’t see that far into the future. So I don’t know. However, if AI only amplifies structure – and we are the ones defining that structure – then maybe the question answers itself: it won’t replace me. Because I think AI will do two things: on the one hand, highlight the value of the current workflow faster; if the output is not as imagined, the AI is not to blame – the workflow is. On the other hand, when it does a lot of the mechanical work, it will change what I spend my time on, solving problems in a new way.

This is my take on the current situation, but the question is not only mine to answer. The question should be answered by everyone. Lastly, there is the question underneath: “How can AI assist us so we can solve problems in a way we haven’t had the chance to try before?”

[1] Anthropic Economic Index report: Economic primitives \ Anthropic

But in systems engineering, the question is: can we actually trust it?

I’d been using LLMs for proofreading and brainstorming. But Systems Engineering? That’s different. We’re not writing blog posts, we’re designing safety-critical systems with requirements that must be traceable, testable, and correct.

So when my manager asked “How can AI be used in Systems Engineering?” I was excited. But also sceptical.

Then the industry started talking about “agentic workflows” - autonomous agents that work independently. That sounds impressive. But for Requirements Engineering? When these requirements are used in real-world systems, we need them to be correct, not hallucinated, and complete.

I had no deep knowledge of agentic workflows or AI pipelines. So I did what most engineers would do: I asked Claude to show me what’s possible. Not to build a product. Just to understand: What can AI actually do today? And how does it work?

I started with a simple question: “Can you help me build a pipeline that derives system requirements from customer requirements?” - Seven minutes later, I had a working prototype.

Seven minutes of conversation with Claude - describing what I wanted, iterating on the design, refining the approach. The first thing it built: A pipeline for deriving system requirements from customer requirements, with built-in validation rules.

It looked like this:

1. Requirement Interpretation Agent

2. Structuring Agent

3. Quality Validator

4. Consistency Checker

5. Traceability Matrix Generator

At first, I had no control over the prompts. The pipeline worked, but it was a black box. So I asked for an update: “Let me edit the prompts myself.”

Claude updated the interface immediately. Now I could see every prompt, edit them, inject domain knowledge. This changed the rules I wasn’t just using AI – I was controlling it.

That changed everything.

Generic prompts produce generic output.

But when I could write: “Check if this requirement follows our company’s naming convention for safety-critical systems” - the quality jumped and we are in control.

Then I wanted more. If I can derive requirements, can I generate test cases from them?

I asked Claude to build a test case generator. Same approach: a pipeline that takes system requirements and generates test cases across the V-Model: Unit, Integration, System, Acceptance tests.

Again, I wanted full control over prompts. Again, Claude complied.

Now I had two pipelines that connected:

• UC1: Customer Requirements → System Requirements

• UC2: System Requirements → Test Cases

Seeing that in action made me realize: these aren’t independent tools – they form a system. UC1 creates the requirements that UC2 needs. The validation criteria from UC1 inform the test generation in UC2. The traceability matrix connects them. Changes in one cascade to the other.

This is not the future anymore; we are living it.

Claude built these pipelines in minutes. This is not production-ready by any means, however this is a proof of concept. They show what’s possible today, right now, with technology anyone can access.

Not magic. Not science fiction. Just structured prompts, clear architecture, and an LLM that can follow instructions. The question shifted from “Can AI do this?” to “How do we design this to actually work?” As I mentioned earlier, What I built was a pipeline, not an autonomous agent. That distinction matters.

A pipeline is a sequence of controlled steps. Each prompt is defined, visible, and editable. As engineers, we decide how each step works.

Autonomous agents may produce results, but the process remains opaque. Without visibility into how decisions are made, you cannot debug or systematically improve the system. In safety-critical systems, autonomy without traceability is not innovation – it is risk.

Furthermore, LLMs are non-deterministic. If you run the same prompt twice, you get different answers. That’s how they work – there’s randomness built into the generation process. For creative writing? That’s fine, even desirable. For requirements that are used in safety-critical systems? That’s a big no-go.

Non-determinism is acceptable - as long as control and validation are in place. This is how we can make it work:

1. Human validation is mandatory

It is important to highlight here, engineers review every output. The AI suggests & humans decide. That’s the workflow.

For example: If an AI-generated requirement says: “The system SHALL respond in less than 2 seconds” and the engineer knows the hardware can’t support that - they can change it.

The AI isn’t making final decisions. It’s doing mechanical work that humans then verify.

2. Pipelines give you visibility

Because each step is explicit, you can see exactly what happened:

• Step 1: interpreted the customer requirement

• Step 2: structured it in IEEE 830 format

• Step 3: checked it against IREB criteria

• Step 4: found a potential conflict with SR-042

You can trace the output. You can see where it went wrong. You can fix the prompt at Step 3 if it’s producing false information.

It seems that autonomous agent, cannot give you that degree of visibility. Additionally, how do we know that the agent knows that the hardware doesn’t support 2 seconds response time?

Currently, agents give you a result. You don’t know what path it took. You don’t know what it considered and rejected. You can’t debug it. You can’t improve it systematically.

This shows the bigger picture:

Systems people don’t understand are systems they can’t control. This implies we need to ensure that we build systems that are transparent so we can trust them and use them. The experiment did not prove that AI can replace engineering work. It showed something more important.

The value is not in the AI itself, but in how it is structured.

When AI is treated as a controllable system—broken into steps, with visible logic and human validation—it becomes usable in engineering contexts. Not because it is perfect, but because it is understandable.

That is the shift: AI is no longer just a tool. It becomes part of the system we design.

If we can capture engineering decisions, patterns, and feedback from everyday work and turn them into structured, reusable knowledge, then AI becomes a mechanism for scaling expertise rather than replacing it.