Posts from Geldrop
Bridging the odds, with LSP
- 2026/07/26
- Geldrop
- English
- ScenerySketching
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.
Document your thoughts (with gptel)
- 2026/07/05
- Geldrop
- English
- ScenerySketching
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”?
Applying BDD & TDD in legacy
- reading-time:
8m45
As I described in Introducing BDD & TDD, understanding the common goals of Behavior & Test Driven Development
and defining your specific needs is the first and most critical step to start using this essential discipline.
Whenever the goal is to use new tools, it is simple: purchase them, shop for some hands-on training, and you are
done.
Our ambition is different: we want to become Agile and Lean.
Then, it depends on the starting point too. B&TDD in greenfield development is relatively simple: start writing your
tests and code!
However, starting with B&TDD in (Modern) Embedded Software can be more challenging due to the existing and often
extensive codebase that was developed before the emergence of B&TDD.
Then, the question ‘How to start?’ is more like ’How to get out of the waterfall?’
The Never-ending Struggle on CodeQuality due to the growth of teams and codebases
- reading-time:
6m
As your embedded software codebase grows, the risk of introducing errors and bugs increases exponentially. Doubling
the number of developers will roughly double the risk of mistakes. We need new “tricks” to strive for the
ever-demanded high quality.
This is a constant battle. As embracing tools, processes, or disciplines helps only once.
Why Modern Embedded Software Systems nowadays embrace webserver-technology
- reading-time:
3m45
Whether it’s your office printer, your internet router at home, or your future top-notch embedded system, they all
use technologies that, only a decade ago, nobody imagined using in an embedded system! How did this happen?
And why?