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.