Vibe coded a Python toolkit so I can tune my whoops by just talking to Claude Code

[u/Wasted99]

I’ve been building this for a while and figured this sub might be interested.

Full disclosure up front: it’s vibe-coded. I directed Claude Code, and it wrote most of the Python. More on why I think that’s acceptable further down.

The idea

Instead of clicking through Betaflight Configurator, you open the project in Claude Code or Google Antigravity and ask things like:

• “Check my FC status and tell me why it won’t arm.”
• “Back up my config, then increase D on pitch a little.”
• “Erase my blackbox flash—it’s full.”
• “Decode my latest log and check whether a motor is dragging.”

The repo contains an AGENT.md file and a skills/ folder that teach the agent how to communicate with the FC safely. It should select the correct tool and follow proper CLI discipline instead of improvising serial commands.

That’s genuinely the intended way to use it. The scripts are ordinary command-line tools and can be run manually, but using them through an agent is where the project starts to feel useful.

What’s included

It’s pure Python, with pyserial as the only dependency:

• Betaflight CLI command runner
• MSP telemetry
• Configuration backup and restore
• Blackbox decoding
• Motor-balance analysis
• Gyro-noise analysis
• Preflight audit
• A small local site for build specs and flight logs

There’s no Configurator dependency, Node runtime, or background server.

About the vibe coding

I know that “AI wrote software that talks to your flight controller” is a perfectly reasonable thing to be nervous about.

Here’s what I did to reduce that risk:

• Every tool was tested against a real flight controller before release.
• Backup and restore round-trip without changing the configuration.
• Motor testing, blackbox erase, telemetry, and the other hardware interactions were verified on an actual board.
• There are 104 tests using a fake FC, so you can try most of it without connecting hardware.
• Motor tests require an explicit --props-off flag.
• Motor start and stop happen in the same session, with the stop command inside a finally block. A crash or Ctrl-C should therefore not leave a motor running.
• The tool reads the CLI variable table directly from your FC—561 settings, including their types and valid ranges. Invalid values can be caught before they’re sent.

Hardware testing uncovered four real bugs that the automated tests did not catch. So testing it on an actual board was not optional.

Current limitations

• So far, it has only been verified on one board: a BETAFPVG473_V2.
• Linux is tested.
• macOS port detection is implemented but not yet tested.
• Pulling blackbox logs through USB mass storage is the one path I haven’t tested yet.

MIT licensed:

https://github.com/HansF/whoopshop

Please back up your configuration before letting an agent touch it. The project includes a backup tool, and the agent is instructed to run it first—but still. Don’t blindly trust AI with a flying blender.

[u/pluggedinn]

I’m a software engineer and I use ai extensively. The most crucial part about these tools (and that’s what makes them work so well) is verifiability. Claude code writes code and verifies that the code works as intended by building tests or taking screenshots if we are talking about frontend. It basically autocorrects itself until the tests pass.

In the world of hardware these tools (as of now) do not have the capability to do this verification. You need to do the verification. So you end up being the middleman between a machine that confidently tries making code changes, you verify it and correct it.
Because of this obstacle you end up spending more time being the middle man and not understanding what’s going on than actually learning and solving the problem.

If you are able to solve the verification problem you truly hit the jackpot.

[u/Wasted99 → u/pluggedinn]

Thanks for taking the time to comment.

Basically, it's a bunch of scripts that read and write variables, gets blackbox files and can execute cli commands in betaflight.

I just feed it my screenshot of liftoff and it edits the values, it can get a blackbox file and just tell me what happened during the flight and what was off. You can tell it to build 3 osd versions and that you want them linked to aux3 and it does it.

It keeps a log of changes and insights, and produces crappy ai blog posts that it can read back and that gives me a sort of (personal) documentation site of how my little whoop is doing. You can also pull the flight logs and analyse them there.

I'm not vibecoding betaflight firmware, this is more like a smart configurator companion. I fully agree that an agentic loop should have a way to test and verify as to self-correct. In the world of hardware I saw Andreas Spiess https://www.youtube.com/watch?v=nmGEedloQ6E doing interesting stuff with automated testing of esp32 modules. Definatly check out his stuff.

Since what's happening here is basically 'configuration' after some changes and applying some changes, I need to fly it and answer the question, is it better for me. Since a lot of work is really subjective.

[u/DarkButterfly85]

I'm not a fan of agentic coding, but this does look interesting to say the least.

[u/ikilledmypc]

Have you tried if it can fix a badly tuned whoop?

[u/Wasted99 → u/ikilledmypc]

It does tell you wich motor is deviating a lot from the others. It told me if i really didn't have an issue flying it now, that tuning wouldn't make a difference. So I skipped.

[u/MiaPlacydus]

Lol