VESC Mods Made Via Vibe Coding

[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 reins 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.

18 thoughts on “VESC Mods Made Via Vibe Coding

  1. I need the world to stop calling it ‘vibe coding.’ It’s being a project manager. Vibe coding is when I have a glass of whiskey and write a stream of garbage code guided by pure vibes until it works, then come back the next day and write it again sober and neatly. It’s the old ‘write drunk, edit sober.’

    There are no vibes in telling a robot to work harder for you.

    1. Welp, the good old time…
      I even remember some robotic article project teaching you how to build and code positioning devices, and having a selection of beer for the reader to go with the maths involved.

      I like the “code drunk, edit sober”, I’m stealing it from you = )

    2. Dead on.
      I decided to give the “vibe coding” thing a try and set up Cursor and started having it generate a few basic applications for me, to mixed results. After a few hours I had a grasp on how to communicate with it effectively, so I had it recreate a library I’d been working on but got stuck with an issue. It ended up creating a more elegant structure than mine and after two days of telling it to add features, integration and regression tests, and preparing it for GitHub Actions CI/CD it suddenly failed to build and once it fixed the build failures all the tests were failing and the demo program wasn’t working the way it should. I kept working with the AI to fix it but it was going in circles and clearly couldn’t figure out the problem itself.

      It took a day of reading through the code (and the thorough docs the AI had written, top quality at that!) to figure out the root problem was all a single line in a build file that shouldn’t have been added in the first place.

      The lesson I learned was to treat the AI like a junior dev or an intern. I design things myself, maybe by writing out an Interface class or just defining an API specification, and tell the agent to color inside the lines. After every major change I tell it to make sure the code is thoroughly commented and to include XML comments for static documentation generators like Doxygen and DocFX, but also to assist with IDE hints/tooltips/etc. through Intellisense, Intellicode, whatever. Above all, I learned to always make it work in version control, commit after each major change, and make it write descriptive commit messages.

      That sequence is important, actually. I found that the AI agent will sometimes make logical errors in its implementation and discover this when going through a documentation pass. I have also found that the AI is a lot more competent when working with code that’s well commented (even if it wrote the comments itself) and if nothing else the comments it writes let me check that it has a clear perception of what the code is doing, what it is used for, and what it is intended to do.

      Vibe Coding implies giving up control and concern and trusting the AI to do it all without oversight. What is actually entails is more involved, and leans heavily on project management skills.

    1. I’m sorry you feel that way. I did spend a bit of time directing Gemini and bug squashing to make the screen usable but in the end Gemini wrote 100% of this code, and it does what I want it to do. Like it or not I think this is going to get much more common as English becomes the programming language of choice.

      1. I feel that if you can write out your prompts/instructions well enough that a LLM can interpret, understand, and write working code based on them, you’re most of the way to being a coder yourself. A large part of computer programming is understanding what you want to do, and being able to write out a logical series of instructions to achieve that goal in a particular programming language. You’re further along than you think you are.

      2. It is common and there’s nothing wrong with it. The error is on the part of Hackaday’s editors. This approach to making isn’t what Hackaday’s audience gathered around and it’s very off-putting to see these posts keep popping up. We’re here to celebrate bloody-minded, did-it-the-hard-way, that-wasn’t-really-necessary, could-have-just-bought-it type projects.

        It really feels like the editors have forgotten what hacking is all about.

        1. I disagree, personally.

          AI is a tool. Hacking doesn’t mean doing it the hard way. If you use Visual Studio instead of vim, is it still a hack? Of you use a Raspberry Pi instead of hacking a router into a SBC, is it still a hack? If you use an Arduino instead of 17 555s, is it still a hack?

          “Could have just bought it” is more fitting, IMO. You don’t have to do it the hard way, it’s okay to use tools. What matters is you did it, you did it your way, and whether it works or not is academic. It’s the journey, not the product.

          Could have used a 555, though.

    1. ‘It is better to be lucky than good.’ (Not sure which rule of acquisition that is)

      Everybody wants to ‘get lucky’.

      ‘Getting good’ involves work, lots of work, too much for most of population.

      1. You can’t be good at everything, either. If you have that much time and energy to put in enough work to get good at every toolset, platform, and technique, you probably don’t have a 9-to-5 job.

        I like writing code and designing systems. I don’t really grok CI/CD, nor do I want to be good at CI/CD enough to invest the time and energy required. I also don’t want to write documentation for my systems. Or develop my own Jekyll templates.

        The time and energy I have to work on project after my day job and family responsibilities are scarce and precious, and I’ll proudly use any tool that lets me do more of my craft while wasting less on things I don’t care about.

  2. The term “vibe coding” needs to die (unless referencing the field of dildonics)

    If writing out a series of instructions in your native language is “coding” then recipe books are culinary coding.

Leave a Reply to TDTCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.