What it is
“Vibe coding” describes a way of building software where you talk to an AI assistant in plain language, run what it produces, react to the result, and ask for the next change. You steer by outcome — does it sound right, does it feel right — rather than by reading every line.
For audio, the loop looks like this:
- Describe a small behaviour: “When I hold a key, play a soft saw pad that fades in over two seconds.”
- Run it and listen.
- Describe the difference between what you hear and what you want: “Darker. Less buzzy. The fade-in is too abrupt.”
- Repeat, committing working versions as you go.
That loop is the whole skill. Everything else — which framework, which plugin format — is detail you can learn once the loop feels natural.
Why musicians are using AI coding tools
Ideas that don’t exist yet
Every producer has a “why doesn’t anyone make…” idea: a click track that drifts by a few BPM on purpose, a drone box tuned to a specific scale, sample pads that randomize start points. Commercial plugins rarely cover those niches, and the ideas are often small enough to build yourself.
Ears are already the hard part
Musicians are good at the part software engineers often find hardest: knowing what sounds good and noticing small differences. Vibe coding rewards that. You don’t need to know how a one-pole filter is implemented to notice that the top end is harsh.
Learning by building
Working on a real instrument is a far more motivating way to learn audio concepts — oscillators, envelopes, filters, buffers — than a textbook. The AI explains as it goes if you ask it to.
Realistic expectations
This is where most people get burned, so it is worth being direct.
| Usually goes well | Usually goes badly |
|---|---|
| Small instruments with one job (pad, drone, click, drum pattern, sample pads) | “Serum but better” or a full DAW in a plugin |
| Browser prototypes using Web Audio | Asking for a compiled VST/AU in one prompt |
| One feature per request, tested by ear | Ten features at once, then debugging all of them |
| Clear sound descriptions and a written scope | Vague goals that change every session |
| Simple UIs: sliders, buttons, a few pads | Pixel-perfect skeuomorphic interfaces on day one |
A few honest truths:
- The AI will confidently make mistakes. It may invent APIs, mix up versions of a framework, or introduce clicks and pops. Your job is to notice and say so.
- Real-time audio has strict rules. In native plugins, the audio thread can’t wait on memory allocation, file reads or locks. AI assistants don’t always respect that unless you tell them to.
- Native plugins add a whole layer. Build systems, code signing, host testing, and plugin formats are a separate learning curve from the sound itself. See browser prototype to VST/AU.
- Progress is uneven. Some evenings you’ll add three features; some you’ll spend chasing one bug. That’s normal.
Browser first, native later
Most people who succeed start in the browser. The Web Audio API ships in every modern browser and can do oscillators, filters, envelopes, sample playback and effects. There’s nothing to install, a reload is instant, and a crash just means refreshing a tab rather than restarting your DAW.
A browser prototype is not a VST. You can’t load it in a plugin slot. But you can play it, record its output into your DAW, share it with a link, and — most importantly — find out whether the idea is any good. Once you know it is, the JUCE learning path covers the native route.
A starter path
Week 1: get sound out of something
- Pick an AI coding editor and get comfortable asking it to explain code.
- Start from a project that already makes sound — the free sample pad works — so you aren’t debugging silence.
- Make five tiny changes by ear: attack time, a chord, a filter cutoff, volume, a new slider.
Week 2: scope your own idea
- Write the idea in three lines and a Will / Won’t list. See scope your first plugin and writing your idea.
- Put the scope in a file the AI can read at the start of each session.
Weeks 3–4: build feature by feature
- One feature per request. Test. Save a working version with git before the next one.
- Keep a short “Build-next” list so you always know the next small step.
- Record the prototype into your DAW and use it in a real track. That tells you more than any code review.
After that: decide whether to go native
If you keep reaching for the prototype in real sessions, it may be worth porting. If not, iterate in the browser or start the next idea — that’s a perfectly good outcome.
Habits that help
- Project rules. A short rules file (“use Web Audio only; no external libraries; keep audio code in audio.js; never allocate inside the audio callback”) keeps the AI consistent. The blog post on Cursor rules for music goes deeper.
- Protect your ears. Keep a master gain low and add a limiter early; buggy audio code can produce sudden loud noise.
- Ask “why.” When something works, ask the AI to explain it in two sentences. That’s how vocabulary builds up.
- Save often. Being able to roll back to the last version that sounded good is the most underrated tool you have.
If you’d rather skip the blank-page stage, Spec → Scaffold gives you a written scope, a playable browser prototype for your idea, and an ordered prompt chain to keep building — $49 on Gumroad. Either way, the path above is the same.
Keep going
- Learn hub — the full path map
- What vibe coding audio plugins really means
- How to scope your first plugin
- From browser prototype to VST/AU
- A JUCE learning path
- Writing your plugin idea (intake guide) · Blog