One particular instance was a conversation about electric vehicles. A fascinating thing happens when adults talk about EVs: they share their experiences around charging, range, and what particular vehicle they own. Like teenagers talking about their new flip phones, way back when we had flip phones and compared their functionality.

One father stood out. He talked about how he had a trailer and needed a new car, so he looked at EVs that had enough power for his trailer. He did not ask the question of whether an EV could actually take on a trailer. He looked for an EV that could do it and bought one. He does not regret his choice.

While this story sounds like an outlier, it is not. We count the success of technologies by total units sold and compare them with each other. The company that sells more has won the race, while the company that has sold less has lost the race. Additionally, when it comes to the adoption of new technologies, we tend to ask the undecided rather than the user.

Here, heat pumps are a popular example. Instead of only asking whether they can work in cold climates, we can look at places where people are already using them. In fact, some of Europe's coldest countries have some of its highest heat-pump penetration rates. In 2021, Norway had more than 60 heat pumps installed per 100 households, while Sweden and Finland had around 45 each [1]. You rarely hear that people choose a heat pump because it can deliver around four units of heat for every unit of electricity consumed [2].

Adoption is not the end of the story. It is the moment a product enters the environment it was actually built for. Suddenly, thousands of users are generating something that was scarce before the product was released: real-world experience. What can we do with that information? Enter the possibilities of software updates.

Companies still treat software updates as a necessity rather than an opportunity for improvement. Providing software updates is not just about fixing bugs anymore. It is about accepting the reality that a product can have a longer lifecycle than anticipated – which is a good thing.

A physical product and its software evolve on different timescales. The physical product may remain useful long after its original software has aged. We have seen this with computers, then smartphones, and now cars. The longer we keep a device, the more valuable meaningful software updates become. The world changes, and the device should be able to adapt to it.

Users might even be willing to pay for a good software update – but make it reasonable and let the user decide whether they want the update or not.

But software can also achieve the exact opposite. Instead of extending a product’s useful life, it can introduce dependencies with much shorter lifecycles than the physical product itself. Like when companies force us to use our smartphones to interact with a device, preferably over a server.

Take a wallbox, for instance. Because of safety, you cannot simply pull out the cable while charging – only when the car is not charging. But every so often, the cable gets stuck in the wallbox. The only way to unlock the cable is by using the app. What if there is no internet, your phone is empty, or you don’t want to use the phone? There is no security lever or NFC tag you can use.

It is not that companies don’t think about this; they do. The wallbox itself doesn’t need the internet to physically release the cable. So why does my recovery path depend on an app and potentially a server?

We know of companies that went bankrupt, and features that needed servers became useless. Users paid for them and relied on them every day, but when the company went bankrupt and the servers went down, those features became useless.

A product that can change after it has been sold does not have to become dependent on the company that sold it. Quite the opposite. If software allows us to extend the useful life of a physical product, we should design the software around that lifetime as well.

Don’t feel embarrassed because you made your product better. Do it – be the company that learns, adapts, and even listens to user feedback to improve the product. Don’t hide behind imaginary numbers that someone chose for a race that then decided whether the product was a success or not.

Next time you are in a meeting discussing a lifecycle decision about a product, ask whether this serves the user or the release schedule.

Remember: let the user decide. Build it together with them.

Source:

1: “Coming in from the cold: Heat pump efficiency at low temperatures” www.cell.com/joule/fulltext/S2542-4351(23)00351-3

2: The Future of Heat Pumps from INTERNATIONAL ENERGY AGENCY

What does a systems engineer do when they get solar panels with battery storage, a heat pump, a wallbox, and dynamic pricing?

They are trying to understand how they talk to each other. The question is: how?

Additionally, I found out that I need a smart meter that broadcasts in real time how much I feed into the grid or consume from the grid. As it turns out, I do have a simple inverter that cannot broadcast those values. So I have to get another device until the government provides a true smart meter.

Imagine sitting there, ready to set everything up, then learning that the grid information is missing—the very information the whole operation is based on.

In the meantime, I learn how all devices should work together. As it turns out, while all devices have an API and are able to provide basic communication, no device is built to be the manager.

Luckily for me, it is summer, so the days are longer than the nights. I can get most of the power I need while the sun is shining, my heat pump does not have to work as much, my EV can be charged during the day using only solar power, and my battery is only being tapped overnight.

How would that work at night then? My EV needs a little more power, the heat pump has to do a little work, and the solar panels do not generate enough power during the day, so my battery has to do some heavy lifting.

Here is where dynamic pricing comes into the picture: charge the battery only when prices are low. The battery can know that and do that, but power still has to be distributed equally among the devices, so the question arises: who is managing that distribution?

The Energy Transition is only going to work when a dedicated layer of communication is available. Installing hardware without coordination is like building a road network without traffic management. Cars can move - but nobody decides who has priority, where congestion should be avoided, or how the flow should be regulated

This is where a Home Energy Manager (HEM) comes into place and tells the devices how they can operate. It tells which device can operate when. If nobody is home, the heat pump can wait a cycle in order to avoid tapping into the grid while other devices are running.

In theory, this sounds reasonable and like a piece of hardware that future-proofs our homes. In practice, tech companies want to build ecosystems with very high walls, and managers think sharing operational data is a bad thing.

What nobody is telling you is that companies building those HEMs need not only software, but also need to know how those devices operate in order to connect them and make them usable.

Some companies are providing you with an all-in-one solution—one ecosystem. At the same time, companies make it harder for HEMs to fully connect to them.

If all that sounds familiar, that is more or less how we got AUTOSAR: a unified software architecture that allows devices from different manufacturers to talk and exchange information in a car.

A step 0 before we got to Software Defined Vehicles (SDVs). It is important to mention that SDV relies on AUTOSAR. The main difference is that AUTOSAR is a standard for devices, while SDV is a philosophy of how to build a car.

The philosophy is that a car’s features are not defined by its hardware but rather by its software.

Like our smartphones, the camera sensor and the lens are not the main parts that determine picture quality. It is the software that computes that information.

That being said, smartphone manufacturers are now building cars. Not because they know anything about cars, but because they know how software can be used to build cars, including the user experience.

If we compare the evolution of the car to our own personal power grid, we can see that there is no AUTOSAR equivalent. However, smart home standards such as Matter or Modbus are trying to be a substitute for AUTOSAR.

All this is just the first wave. If we want to optimize our own personal grid so that devices get power when they need it and save power when they are not needed, the second wave will be the Software Defined Energy Transition.

That philosophy - that layer of intelligence - is a true turning point for the energy transition.

While we can control individual smart home appliances, in the age of AI we do not want to control devices. We want to go to work, come home, or even go on vacation.

The smart home should not only control devices, but power management should also be able to shut down power usage when it is not needed and regulate power depending on how long it is not needed.

We are in the middle of the transition between the first wave of getting devices into our homes and the very start of wave two, where the Software Defined Energy Transition begins.

We have seen the drama of SDV and can draw parallels to see where this is going.

We are in the early stages where customer feedback around the functionality of devices can shape the future. At the same time, engineers have established software workflows that focus more on customer value than ever before.

Furthermore, the feedback does not have to go directly to manufacturers, but can also go via standards and lawmakers.

We are at the same moment the car industry was before AUTOSAR.

What we decide today determines whether the Energy Transition gets its Software Defined moment or remains a collection of dust collectors that happen to be scattered around the house.

“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.