Posted in 2026

Why? the ADR!

reading-time:

1min46

LinkedIn:

https://lnkd.in/p/eGQBcEbY

June 1996: The maiden flight of Ariane 5 –a €666M rocket– failed, with a big explosion!
But Why?

You probably remember: it was a software flaw. An expensive one, but not a very complicated one. Or, as studies show, a couple of them. Some dead code, a calculation overflow, and faulty error handling. Each of them shouldn’t happen —but can you guarantee that your system doesn’t have them?

But Why? Why did the code have those kinds of stupid mistakes?
Or maybe more importantly: How can you, as an architect, prevent them?

Read more ...


Agentic Coding with MCP

“Writing code” is more than just writing text. When human engineers work with code, they need a variety of tools to build (a compiler) and verify (several test runners) the software. We can also enable LLMs to run these tools; this offers many benefits. And may introduce huge risks.

In this article, we briefly cover MCP, the protocol that enables agentic AI. But be warned! MCP is extremely powerful, and —as an LLM has no conscience— it will happily wipe all your work, or worse. More on that in an upcoming article: “MCP safety”.
Now we focus on how agentic coding fits into the scenery, and how we can speed up engineering by asking LLMs to run those tools for us.

Read more ...


Two Cups Behaviour

reading-time:

1min31

LinkedIn:

https://lnkd.in/p/egnF9kUR

I always wonder why the Ultimo Superior Brewmaster luxury coffee machines only discover they are low on water after brewing the first shot when the double-cup option is selected. Its water sensor can differentiate between espresso and regular coffee, but somehow it forgets that two cups need more water too.
What a stupid behaviour!

Read more ...


Debounce Noise

reading-time:

1min19

LinkedIn:

https://lnkd.in/p/erCkP23a

Everybody likes to push buttons. And every engineer knows you must debounce them to avoid noise. But who decides how to do that? Is there a best strategy? Today we do a deep dive and consider all details that might be architecturally important.
And, as we will see, we might even find some noise in the organization.

Read more ...


NoCode Architecting

reading-time:

1min13

LinkedIn:

https://lnkd.in/p/eni5fszP

An architect isn’t a bricklayer, so why should a software architect write code? Don’t they have more important work? This is a hard question and depends heavily on subjective personal preferences. But avoiding the question degrades the craft.
So, what is a genuine embedded systems/software architect? And how do you become one?

Read more ...


Scaling Big (1)

reading-time:

1m17

LinkedIn:

https://lnkd.in/p/ex67jcaB

You shouldn’t build a 350m-high skyscraper like a bike shed; likewise, Linux (35M lines of code) needed a different principle than HelloWorld. All software starts small, though. Once, Linux fit on a single page.
Architecture helps to scale! E.g., Linux is based on the ‘Common Unix Architecture’, with drivers, CPU abstraction, file- & networking-I/O, etc. Even version v0.0.1 of the Linux kernel used it.

Read more ...


Global Details

reading-time:

1min5

LinkedIn:

https://lnkd.in/p/egCu5sUr

Any senior (embedded) software engineer knows (s)he should focus on details, as the devil is in those details. But what is a detail?
Often, a client —as a user— will focus on the most important pieces and call everything else a detail: “We hardly use that”. Yet they still assume every part is bug-free.

Read more ...


Sovereignty with Ollama

Frequently, SW engineers complain they aren’t allowed to use CodeAI, because ‘GDPR’ enforces strict rules on personal data — as a result, all kinds of cloud services are forbidden by their organization.
At the same time, there is a strategic risk in the operational habit of “uploading” all your embedded software to American AI providers, to gain a bit of productivity. The big question is: Who is reading it?

Even when the contract mentions “will not be used for …”, US law stands above that. By law, the US government can demand all that data. Secret agencies can demand a copy of our code, and even forbid the provider from mentioning it.

This article will show that you can use CodeAI without disclosing any of your code. With a tool like ‘Ollama’, I can use CodeAI even in airplane mode!

Read more ...


The costs of a mistake

reading-time:

59 sec

LinkedIn:

https://lnkd.in/p/eYPJtsPc

A typical code bug takes between one hour and one week to solve. Annoying, but the costs are minor — a few thousand euros at most. Sure, a bug escaping your sprint is a bit more expensive. And once it hits production, it can increase sevenfold.

But what about an architectural mistake? Let’s be honest: it is just as easy to make. Just a few lines in a 256-page document. But if it’s a real architectural error, it is fundamentally wrong! Let us take a trivial example: choosing the (wrong) programming environment for a new, modern Embedded System. That can be the OS, the language, or an open-source library.
And yes, those mistakes have been made …

Read more ...


Bridging the odds, with LSP

As CodeAI makes mistakes, code-checking has become even more important. And, it needs to be smarter than traditional static checkers. Where human developers traditionally make mistakes around syntax details, generated code is often correct on that aspect — but the reverse is often true for ‘names’. An engineer will hardly ever calls an internal function that does not exist, but CodeAI might use a name because it is often named that way …
Especially when using hardware-related details, this can become erroneous. Reading register ‘X’ —because that is statistically likely— may even compile and yield a bit, but when your pin is connected to register ‘Y’, it’s the wrong result.

So, we need a checker that knows these kinds of details about your teams’ code. And when possible, can talk with the CodeAI to contribute that kind of detail. It is possible to connect those ideas, although it is not obvious. We need a few big steps to bridge the gap.
In this article, we introduce LSP; later, we will handle the other parts, such as MCP.

Read more ...


Document your thoughts (with gptel)

Many teams use AI to “type faster”, either by using tools that produce ghost code or by practicing vibe coding. But “building sovereign software” isn’t like building a house—where high-speed brick-laying does shorten takt time. Determining “what” the (embedded) system should do and “how” the (technically complex) software should interact takes a significant amount of time.
As engineering is mostly reasoning, typing speed is futile.

To speed up engineering, the real question is: How to use CodeAI to “think faster”?

Read more ...