[David Bloomfield] wanted to make some tweaks to an embedded system, but didn’t quite have the requisite skills. He decided to see if vibe coding could help.

[David]’s goal was simple. To take the VESC Telemetry Display created by [Lukas Janky] and add some tweaks of his own. He wanted to add more colors to the display, while changing the format of the displayed data and tweaking how it gets saved to EEPROM. The only problem was that [David] wasn’t experienced in coding at all, let alone for embedded systems like the Arduino Nano. His solution? Hand over the reigns to a large language model. [David] used Gemini 2.5 Pro to make the changes, and by and large, got the tweaks made that he was looking for.

There are risks here, of course. If you’re working on an embedded system, whatever you’re doing could have real world consequences. Meanwhile, if you’re relying on the AI to generate the code and you don’t fully understand it yourself… well, the possibilities are obvious. It pays to know what you’re doing at the end of the day. In this case, it’s hard to imagine much going wrong with a simple telemetry display, but it bears considering the risks whatever you’re doing.

We’ve talked about the advent of vibe coding before, too, with [Jenny List] exploring this nascent phenomenon. Expect it to remain a topic of controversy in coding circles for some time. Video after the break.

This week, the hackerverse was full of “vibe coding”. If you’re not caught up on your AI buzzwords, this is the catchy name coined by [Andrej Karpathy] that refers to basically just YOLOing it with AI coding assistants. It’s the AI-fueled version of typing in what you want to StackOverflow and picking the top answers. Only, with the current state of LLMs, it’ll probably work after a while of iterating back and forth with the machine.

It’s a tempting vision, and it probably works for a lot of simple applications, in popular languages, or generally where the ground is already well trodden. And where the stakes are low, as [Al Williams] pointed out while we were talking about vibing on the podcast. Can you imagine vibe-coded ATM software that probably gives you the right amount of money? Vibe-coding automotive ECU software?

While vibe coding seems very liberating and hands-off, it really just changes the burden of doing the coding yourself into making sure that the LLM is giving you what you want, and when it doesn’t, refining your prompts until it does. It’s more like editing and auditing code than authoring it. And while we have no doubt that a stellar programmer like [Karpathy] can verify that he’s getting what he wants, write the correct unit tests, and so on, we’re not sure it’s the panacea that is being proclaimed for folks who don’t already know how to code.

Vibe coding should probably be reserved for people who already are expert coders, and for trivial projects. Just the way you wouldn’t let grade-school kids use calculators until they’ve mastered the basics of math by themselves, you shouldn’t let junior programmers vibe code: It simultaneously demands too much knowledge to corral the LLM, while side-stepping any of the learning that would come from doing it yourself.

And then there’s the security side of vibe coding, which opens up a whole attack surface. If the LLM isn’t up to industry standards on simple things like input sanitization, your vibed code probably shouldn’t be anywhere near the Internet.

So should you be vibing? Sure! If you feel competent overseeing what [Dan] described as “the worst summer intern ever”, and the states are low, then it’s absolutely a fun way to kick the tires and see what the tools are capable of. Just go into it all with reasonable expectations.