I have worked in software for most of the last ten years, and the last two have been strange. Writing code became much cheaper and much faster. Not free, but fast enough that the slow part of the job moved somewhere else.

For the past few months I have been looking at where it moved to. Mostly at the point where software meets physical hardware. These are notes, not conclusions.

The gap

Writing firmware is fast now, in the same way that writing any other code is fast. You describe what you want, you get something back, and you can try again in seconds.

Then you have to put it on a board.

At that point the speed disappears. Someone has to power the board and connect the wires. Someone has to set up the instruments. Someone has to decide what “working” means, measure it, and then understand the result when the answer is no. None of that got faster. It takes about as long as it did ten years ago, because it depends on physical setup and human attention.

So the two halves of the loop are now very different in size. Producing the code is maybe ten times faster than before. Checking that it works on real hardware is the same as before. The part that used to be small is now most of the time you spend.

The hard part is not robotics

The first idea people usually have is that you need a robot, something that can move probes around the bench. I do not think that is the main problem, or at least not the first one.

The bigger problem is that nobody writes the knowledge down. An experienced engineer looks at a board and knows which rail to check first. They know what a good signal looks like on that specific scope. They know which failures matter and which ones are normal for this revision. Almost none of this exists in a document. It lives in one person’s head, and the next person has to learn it again.

That is a boring problem, and it is not really a question of how smart the model is. It is closer to why developer experience matters. One automated check is not worth much by itself. The value comes from having many of them, so that nobody has to keep the whole system in their head.

I wrote before that developer experience stopped being a nice-to-have when AI started writing code. Your tests and your types are the only thing standing between a change that looks correct and a system that is quietly broken. The same argument is stronger for hardware. A wrong answer about a physical board can cost a week, a bench, and sometimes the board itself.

What I think so far

Three things seem right to me at the moment.

The slow part is testing, not writing. A tool that makes firmware faster to produce, but does not change how you prove that it works, is improving the half that is already fast.

Testing should leave something behind. Finding a problem once is useful. Finding it in a way that creates a repeatable check is much more useful, because the next revision then starts from a better place.

The instruments are usually fine. Most labs already own what they need. The missing part is connecting them and reading the output, not buying more equipment.

I am not sure about any of this, and I would like to be corrected on some of it. If you work on hardware testing and think I have it wrong, please tell me. The contact form on the about page reaches me.

More when I have something useful to add.