Will vibe coding kill the compiler?
Is abstraction becoming a distraction? Software-defined hardware relies on high levels of abstraction. The higher the abstraction, the more readable the code but the further away we get from the hardware. Bare metal programming, which was once the default approach in embedded design, is now the exception.
But ultimately, software is still just machine code; a series of 1s and 0s stored in non-volatile memory. The higher levels of abstraction just provide a simpler way to get from a concept expressed in plain English to machine code that runs on a processor.
The convenience of abstraction comes with the unavoidable overhead of building and maintaining your toolchain. Each stage in that flow represents some level of translation, so getting the flow just right is essential. Supporting the toolchain for every new device that comes to market is another consideration.
As a lapsed embedded developer, I like the way AI can now write high-level code for me, based on a simple prompt. But high-level code doesn’t run on hardware, it still needs to go through the toolchain.
I wondered if I could use AI to replace the entire toolchain, including the compiler. In fact, can AI do away with the need for a high-level language at all? I decided to find out. What follows is my experience of using Perplexity to make my design life easier.
Blinky, but not as we know it
To get started, we needed to agree on a baseline. I asked Perplexity: “Do you know what the blinky program is?” Yes, it did, and it gave me a good overview just to be sure. It described it as the new “Hello, World” for embedded developers; a simple program that flashes an onboard LED with a 1-second mark/space ratio.
This was the response I was hoping for, so I pressed on with my first real prompt. I was hopeful, so I went straight in with a result-oriented request.
Disappointingly, I found that Perplexity wasn’t ready to think as far outside the box as me. Instead of giving me what I wanted, it suggested I follow the standard development path of writing the program in a high-level language (it suggested C) and use the Pico SDK to generate the .hex file. Helpfully, it generated the code without my asking.
It then explained how to compile and generate the .hex file. Obviously, this isn’t what I wanted, so I tried again.
This resulted in the pseudo code, below.
Encouraged by this, I decided we would probably need to take a step-by-step approach.
Here's the result:
Feeling like we were on the home stretch, I asked if it could turn the assembly code into a .hex file.
It wasn’t happy. I don’t know if it is overly cautious, but the top line of the response was that manual conversion is error-prone, pointing out that assemblers do this automatically and that there are some online resources that might help.
That’s not what I asked. Super villains never quit, so I asked again.
This came with more warnings, but I could tell its resolve was waning. It even tempted me along by providing some partial conversions, as shown below.
This response also came with the warning that the timing may not be right and manual conversion is an error-prone process. I didn’t care, I was too invested to stop, so I pushed on. At this point I was willing to try anything, even flattery.
That was obviously the key. Below is a screenshot of the hex file it eventually delivered.
I asked if something like OpenOCD would recognize this format to program an RP2040. It was adamant it would but cautioned (again) that the program may not work.
Can we dump the compiler?
The whole process took about five minutes and, OK, it’s not the most complex program in the world, but the results speak for themselves. It is possible to use AI to go from a natural language prompt to machine code without a toolchain, compiler or learning a high-level language (maybe, I haven’t actually tried the result on an RP2040 yet).
Are we ready to consign C, Java, Rust, Python, in fact all high-level programming languages and low-level compilers to the history books? Obviously, we’re not. And we may not be for some time to come.
Embedded software is far more complex than making an LED flash. Most embedded devices now use real-time operating systems, which brings more abstraction to expedite the design process.
Perhaps this is a taste of things to come. Moving directly to hardware-aware binary formats would be incredibly enabling for even more makers that have no desire (or possibly need) to learn computer science or embedded design.
My next thought experiment would be to use AI and Boundary Scan to explore the resources on a PCB, decide how those resources fit some top-level requirements (such as environmental monitoring) and have the AI tool generate the machine code from that very high starting point.
We’re not too far from doing that with a single voice prompt. And at some point, maybe that entire flow could run at the edge, on the board itself.
Avnet has thousands of experienced FAEs ready to help you with hardware, software, and system design