Vibe Coding a Plugin: What AI Can Build, and What It Can’t

I recently made a decision on a plugin I’m building that I thought worth surfacing as an example, one that shows exactly where issues arise when vibe coding a plugin. A prompt wouldn’t have made it for me and trying to one shot a task without understanding would have most likely missed it completely. I had a waveshaper, a non-linear process that requires oversampling, and a linear mid/side matrix feeding it. The obvious, lazy path is to wrap the whole lot in one module and oversample everything. It compiles. It runs. It sounds fine. It’s also wrong, and it quietly wastes a chunk of CPU for no reason at all.

The design decision to favour modularisation meant it was easy to encase just the non-linear stage, so only that pays the oversampling tax. Small call, perhaps mildly insignificant, but this kind of thing compounds. The kind of call that decides whether a plugin is efficient or just functional. And it’s exactly the kind of call that vibe coding, on its own at this stage at least, will probably not make for you.

What vibe coding actually is

The term comes from Andrej Karpathy, who coined it in February 2025: “you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” You describe what you want, the model writes it, you run it, and you keep prompting until it works. No line-by-line review. Just vibes.

I want to be fair here, the barrier to producing working code has genuinely dropped through the floor. I’ve taught myself basics in Python, a bit of Javascript etc. over the years, but I’m not fluent in C++. I’ve built things this year I would never have had the time nor ability to hand-write. Whole Webview interfaces, DSP prototypes, utilities that used to mean a week of trawling through reference guides, manuals and so on. The scope of what is possible now is huge.

So the popular line, “AI means anyone can build software now”, is half right. Anyone can generate code now. That is not the same thing as building good software, and the gap between those two is the entire point of this piece.

The decision no prompt made for me

Back to the mid/side matrix…

Oversampling exists to stop a non-linear process from aliasing. When you distort or saturate a signal, you create new harmonics, and some of those land above the Nyquist frequency and fold back down into your audio. Running the process at a higher internal sample rate gives those harmonics somewhere to go before you filter and downsample. That’s why a waveshaper wants oversampling.

A mid/side matrix does none of that. It’s linear. It’s sums and differences, a bit of gain… no filtering, no crossovers, no generated harmonics. It creates no new frequencies, so there is nothing to alias, so oversampling it achieves precisely nothing except making your CPU work several times harder on that process.

If you let a model architect that section with no direction, it lumps them together, because they’re near each other in the signal flow and the code is simpler that way. In fact, you may end up with a single module with all your DSP bundled together. It’ll work. You’ll ship it. And you’ll have no idea you’re running a linear operation at eight times the rate it needs, and potentially no way to reuse what you’ve made in another context. The knowledge that these two things belong in separate modules didn’t come from a prompt. It came from understanding what each part is actually doing to the signal.

The code is the part you can skip

So, my view currently… You can bypass writing the code. You cannot bypass the engineering.

Those are different skills, and AI has only automated one of them. The other one, deciding what to build and how it should be structured, is still entirely on you. Sure, the AI will help explain which decision you should make, but you have to ask it. And make the wrong decision, good chance it won’t push back on you. Modularity, so components have clear jobs and clean boundaries. Not repeating yourself, so a change happens in one place and not fifteen. Thinking about how a codebase holds together as it grows past the point where you can keep it all in your head. These are old, boring, unglamorous fundamentals, and they are exactly what separates a plugin you can maintain from a pile of generated code no one understands anymore.

You also have to be able to read it, at least to the point that you have a vague understanding of what is happening in specific module. I spend real time in VS Code following the structure of things I didn’t type, tracing the signal flow, checking that a module does what I think it does. I don’t always understand all of the math in the DSP, but I know why it’s there and what it’s doing. I’m not familiar with all of C++ syntax, but I understand the basics of a function call, variables and logic. Not because I don’t trust the model, but because I’m the one who has to answer for the result. If you can’t open the code and follow it at least at a basic level, you’re not building software, you’re stabbing in the dark.

Testing is where the slop gets exposed

The other half of this is testing, and knowing what you’re even looking for.

Vibe coding is very good at producing something that appears to work. It runs, it doesn’t crash, the happy path is fine. Whether it’s correct under load, at edge cases, across sample rates and buffer sizes, with automation moving fast, is a completely different question, and the model won’t ask it for you. You have to know that a saturation stage needs checking for aliasing, that a filter needs checking for stability at extreme settings, that stereo processing needs checking for phase and mono compatibility. If you don’t know what failure looks like, you won’t know if you’ve failed.

My actual setup

For anyone curious about the stack I’m working with, it’s a multi-model approach rather than one tool. Mostly VS Code as my IDE running the Claude Code (I favour the CLI in a terminal window), with GLM-5.2 in the mix as a second option. GLM doesn’t do vision, so it’s great for straight up coding, but planning how an algorithm will function for example, I’ll often screenshot sketches or clip excalidraw doodles to make sure my intent gets across properly. For interfaces I’ve used Figma Make running various models, plus Figma wired in through an MCP connector to go from design to Webview UI.

Apart from custom skills and agent frameworks I’ve built for myself, I’ve also spent time with GSD, Get Shit Done, an open-source spec-driven framework that runs whole milestones fairly autonomously. It’s capable and genuinely impressive in places in terms of planning. It’s also heavy, and it burns through tokens at a rate that adds up quickly, so “free framework” doesn’t mean “cheap to run”. Useful to know before you point it at a large job and walk away. None of these change the argument though.

Vibe-coded slop versus software that just wasn’t hand-written

If there’s one thing to take from this, it’s the distinction that gets flattened in every hyped thread: well-designed software and hand-coded software are not the same thing.

You can absolutely use AI to build something excellent. Plenty of good, thoughtful, well-architected software is going to be built this way, mine included, and there’s nothing wrong with that. The slop isn’t necessarily caused by the AI. It’s caused by the absence of judgement directing it. Same tools, same models, wildly different outcomes, and the variable is the person holding the wheel.

So if you’re building with AI, and you should be I think, put the work into understanding what you’re actually making. Learn enough to read what comes back. Learn the failure modes so you can test for them. That’s the difference between generating slop and shipping something you’d put your name on, and it’s a difference the models still can’t make for you.

I’ll be writing more about building plugins as this work takes shape. If that’s your kind of nerdy, the newsletter is the place to follow along.