Vibe Coding - Part Deux

A new approach to software development is disrupting the industry

I found last month’s vibe coding episode interesting and fun. I shared the article (and the video blackjack game!) with a few people and got good feedback.

As impressed as I was with ChatGPT and Codex, I’ve seen many founders dismiss AI as suitable only for lightweight applications. A week ago, I had a bit of space on my calendar and decided to embark on a second more advanced experiment to see if I could get closer to professional quality development.

I’m going to take you on a journey of how I used AI to create a native Macintosh application called Zudio that generates new music. I’ll show you how I used AI, discuss the ups and downs of the project to highlight how software development is changing and the impact this will have on the industry. AI is not just a productivity boost, it’s opening up an entirely new field of software development.

Zudio: A Generative Music App

For the last several years, I’ve thought about building an application that creates music based on a set of rules, what’s known as a generative music system. Lacking the coding skills to tackle this project, it lurked in the back of my mind.

So I decided to turn this into test of how far I could get with AI. But I never expected to build a functional prototype in 3 days and a finished application in a week!

As a lifelong mediocre musician, I’ve always been fascinated by music technology. I used GarageBand to compose an open source rock opera with my buddy Rob. I’ve played guitar and bass in terrible bands. And I occasionally write electronic rock music.

Two generative music applications have captivated me: Reflection by the godfather of Ambient, Brian Eno and EON by electronic music pioneer Jean-Michel Jarre. They’re cool apps, but they are black boxes. You can’t shape the music in any way. Could I build a generative music app that gave me more control? I’m no Eno, but I met a guy named Claude who was eager to help!

The application I built, called Zudio, is well beyond my programming abilities. I don’t know Swift or SwiftUI, and I know just enough music theory to know a I-IV-V chord progression.

Although my taste in music skews more towards 70s rock (Beatles, Television, The Clash) I decided to build an app that creates Motorik songs in the style of Kraftwerk and Neu! You might not know the music by name, but you would probably recognize it if you hear it. It’s got a never-ending feel to it, like you’re driving down the autobahn at high speed in the dead of night. The Doors’ L.A. Woman is pretty close to Motorik.

Defining the Requirements

More importantly for this project, Motorik is decidedly formulaic. It uses the so-called Apache beat, a relentless 4/4 rhythm that drives everything. The bass locks in with the drums and not much else happens. Motorik songs usually stay on one chord the whole time to convey a hypnotic pulse. We used to play a classic Motorik song Hallogallo in the Duo Security band. We used to joke: If you could play an E chord, you could join the band.

Here are some typical prompts from the design stage:

Please analyze these Electric Buddha Band MP3s as potential examples: Time Loops, Dark Sun, Vanishing Point, Into The Night, Blakely Lab, Schulers Dream.

Would it be useful to run this analysis on other classic motorik songs like Fur Immer and Hallogallo? Please analyze Hallogallo, Neuschnee 78, Fur Immer, Seeland, and Wave Mother in the same fashion. In particular, I want you to try to derive rules for bass, lead, and rhythm instruments.

Now that the drum track is before the bass track, are there any additional rules for the bass player to follow the drum track? I want them to feel like a very locked-in rhythm section. Although classic Motorik such as Fur Immer or Hallogallo does not have much variation in the drums, I think for most cases it is better to have more variation so it is not too boring. Does this suggest any new rules?

Please carefully review the development plan and prototype docs, and any others, to determine what improvements could be made to these documents to increase the likelihood of success in the programming phase to create good code that can replicate motorik style music.

Rather than diving right into coding, I spent a couple days using ChatGPT 5.4 to undertake preliminary research and build the necessary requirements documents and plans. While ChatGPT did a great job on the video poker and blackjack games, for this project, it never felt like we were converging on music generation rules that were clear enough to translate into code. Undaunted, and with a self-imposed deadline looming, I fired ChatGPT and hired Claude Code (Sonnet 4.6) to take over. The new AI economy is nothing if not brutal!

While I don’t think Claude necessarily has a sustainable long-term advantage (feel free to argue among yourselves) it seemed more informed and decisive about what it was doing. It was like going from an intern programmer to a ten-year veteran. Claude ran agents to analyze classic Motorik songs as well as some of my own music to come up with the rules that would guide song generation. Then I asked Claude to assess the research and requirements to determine if we had enough detail. It deemed it ready to go. Who was I to argue?

Working Prototype in an Hour

The next morning I had Claude generate code. I’m always a bit nervous about the first build because a lot can go wrong. But with a few additional prompts, I had a working prototype generating music and displaying the MIDI tracks on screen like GarageBand does. It wasn’t good music, but the app worked, following the rules, more-or-less.

Personally, I had no idea how to display the generated MIDI tracks, scroll during playback, export to MIDI or any of that. But others do, and Claude knows how to apply their knowledge to my application. That is amazing. I have no idea where the design patterns came from, but with a few minor tweaks it was working surprisingly well. I could load MIDI files into LogicPro for further refinement.

I followed a traditional iterative process of development: Keep the build working, add one thing at a time and test the heck out of it as you go. I also had Claude continue to update the design documents as we built the application, capturing new rules and developing detailed plans for new features.

While it was impressive to get the scaffolding in place, the initial songs were weak. I had Claude build a status text area that served as a log of what was generated to give me visibility into what was working and what wasn’t.

SONG Dunkel Licht
Chords B Aeolian Static tonic: I Bm7, F#m, B7
Form Steady A section
MOT-DRUM-001 Classic Motorik Apache beat
MOT-BASS-015 Kraftwerk driving bass
MOT-PADS-001 Harmonia sustained notes
MOT-PADS-005 Harmonia charleston
MOT-LD1-001 Neu! motif first
MOT-LD2-003 Rhythmic Counter
MOT-RTHM-001 8th-note Stride
MOT-TEXT-001 Cluster sparse

When a song is played, the status area also shows when we enter each new section (A, B, bridge, intro, outro) and how parts are evolving (new bass line, drum fills, solos.)

You can regenerate individual tracks. For example, if the Kraftwerk-style bass doesn’t fit, I can generate a new one. I might get something more suitable, like a driving Giorgio Moroder bass line or a melodic McCartney part.

Quite often in playback, I could identify something was wrong with a rule and tell Claude to fix it. Then I asked Claude to create a secret test mode that lets me generate songs using new or recently changed rules. Piece of cake.

Here are some typical prompts during code generation and musical testing phase:

The music is now sounding much better. But as each track gets better, we are also starting to end up with situations where there’s so much going on it’s overwhelming: there are too many notes! I’d like you to come up with some additional guard rails during the generation phase, whereby if the lead, lead 2, rhythm and pads instruments all have a lot going on, you fall back to some alternatives to randomly reduce what’s going on in some tracks for some bars.

Here’s an idea I’d like to explore. Sometimes electronic songs will have a feeling of constant morphing as sound patterns evolve over time. So instead of playing one set melodic piece over all bars, the melodic piece changes over time, with small changes to the melody or the timing or both. That way it doesn’t get too boring. I wonder if we could do the same thing. have the bass part mutate with subtle changes, then in some cases evolve back. In other cases, restart from the beginning. What do you think of running some experiments on bass parts to do this?

I noticed that the bass pattern BASS-011 Kraftwerk Roboter was not evolving in a song. It stayed the same for 100 bars. Please double check that recently added bass patterns are subject to the existing evolve/devolve rules that we have used previously. Otherwise it’s too boring.

Also, when there is a three bar fill (and sometimes on a 2 bar drum fill) it is important for the bass part to still feel ‘locked in’ to that. So when we generate 2 beat or 3 beat drum fills, please update the corresponding bass part so it is in time with that. That could mean that the bass part has similar note rhythms to the drum fill (though less complex), or it could be that the bass part drops out (no notes) or perhaps plays its own fill in a corresponding rhythm.

Going Meta: Using AI to Test AI

Once we got the basics in place, it became apparent that I needed a more sophisticated approach. AI built the rules (with my guidance) so why not have AI analyze the songs themselves and identify the next set of improvements?

Not surprisingly Claude found even more errors than I did, including significant tonal clashes. Sometimes these were bugs in the code, e.g. Claude forgot to adjust song fragments to the current scale, and sometimes they were more subtle problems of two instruments stepping over each other. At any rate, rules were adjusted and new ones were created to ensure that the tracks were working together. With a couple of rounds of testing this way, the songs improved considerably.

New Musical Styles

Feeling pretty good with the results so far, I decided to push further by adding two new musical styles: Kosmic (Tangerine Dream, Jean Michel Jarre) and Ambient (Brian Eno) style songs. Each of these styles has its own distinct rules, structures, instrument choices and effects. Kosmic, the most complex style, took about two to fully research, analyze, implement and test. Having gone through the process twice already, Ambient music was more straightforward taking just a few hours.

Claude came up with generalized ideas about the songs (including popular keys, song structures, chord changes.) But to move from generalized analysis to good quality songs required coming up with instrument specific rules for each different track.

For example, I asked Claude to come up with a suitable Ambient drum pattern and appropriate instrumentation. If you run the app you might see the rule

AMB-DRUM-004 Claude hand percussion

I think it did a good job adding shakers, bongos, congas etc.

When I asked Claude how it came up with it said:

It was modelled on Brazilian/Afro-Cuban hand percussion as used in ECM-style ambient jazz — Brian Eno’s Ambient 4: On Land, Jon Hassell records, that kind of thing. The shaker-as-pulse with sparse conga syncopation over it is a classic texture that adds organic movement without imposing a strong grid the way a kick/snare would.

Better than I could do!

Things that seem difficult to me as an out-of-practice programmer, weren’t hard for Claude. For example, Ambient songs often don’t use a conventional tempo or beat, instead they evolve over time. Brian Eno originated this technique in the mid 1970s by stringing up magnetic tape loops of varying lengths, each playing a different part.

But just because mapping varying length loops onto a MIDI grid would be hard for me, there’s no reason not to have Claude rip off pay homage to that technique.

Looking Under the Hood

Though I’ve not read much of it, I suspect that the underlying Zudio code is a bit of a mess. Some of the tracks now have a dozen or more rules and each of those parts evolves differently over time. Occasionally, I’ve found weird bugs, like regenerating the drum track in Kosmic resulting in the same drum patterns every time. When I tell Claude to fix it, it does, but I have no idea whether the fixes are a good design or are just making things more brittle.

Periodically, when I noticed CPU utilization spiking, I asked Claude to optimize the song generation and playback loops.

There were a few times when I got quite frustrated. One is when I decided to add some new Motorik solos. I think neither one of us had enough understanding of the code base or musical theory to properly insert Pentatonic major solos into an Aoleian i-v chord structure. It took some trial and error to get there and to be on the safe side, I asked Claude to refactor some of the common code for transposing songs and adjusting scale before we attempted to add new solos for Kosmic and Ambient.

Nonetheless, it identified the sources behind some of the tonal clashes. Some notes were not being adjusted. So as I listened to songs, I found certain bass lines or solos that occasionally clashed. Then I told Claude to find and fix the issues. It turned out there are some hard coded notes used in some of the earliest generated bass parts. I’m not sure why that is.

When Claude tells me:

The b7 is +10 in Dorian/Aeolian but +11 in Phrygian, and doesn’t exist at all in Ionian — so +10 blindly applied is wrong whenever the chord isn’t a dominant 7th and the mode isn’t minor.

I have no idea whether this is true or not, but it makes sense to me.

When I asked Claude to explain why this particular bass track had the problem, it’s response was quite funny:

On why Vitamin Hook rule had hardcoded notes: The CAN “Vitamin C” bass line is a real, transcribed riff — Czukay’s original uses chromatic passing tones deliberately. The b3 (+3), tritone (+6), and minor 6th (+8) are in the actual recording. Whoever wrote that code was directly referencing the source material, which makes sense as a stylistic choice in Dorian (CAN mostly worked in minor/Dorian contexts). The problem is Zudio generates across multiple modes and keys — what’s a chromatic ornament in C Dorian becomes a genuine clash in E Ionian or another mode. The code assumed the song would always be in a minor-flavoured mode, which isn’t guaranteed.

The +10 b7 issues are a similar story — they were written with Dorian in mind (where +10 is always correct), and nobody checked whether the note lands in-scale for other modes.

Nobody checked!

In this case, Claude had found that particular song from its research, pulled out the bass line, created the rule and coded it.

This reveals an important difference between humans and AI. I caught the problem because I was actually listening. Something bothered me and I went looking for the cause. The AI had no way to know it should be bothered. It had written code that was internally consistent for the context it was designed for, and it would have gone on generating music with occasional clashes indefinitely, because nobody asked whether those notes would hold up across all keys and modes.

The AI can explain music theory, find bugs when directed and generate surprisingly good code. What it can’t do (yet) is notice that something is wrong. AI is a remarkably capable collaborator, but it needs guidance from someone with taste and curiosity asking the right questions and framing the work.

From my recent not-very scientific tests, Claude is better at this than ChatGPT, but it can still get lost if there isn’t a detailed plan and review cycle.

When In Doubt, Add More Rigor

The first time I tried to create a signed binary (one that is easily installable and verified free of malware) or when I changed the file save format from a plain text file to a plain text file with a .Zudio document type, it took a dozen attempts. Claude would happily tell me it worked, though testing proved otherwise. I suspect every noob Apple developer has problems with these tasks. Nonetheless, more detailed planning on my part (meaning asking Claude to verify in advance that the approach will work and implementing rigorous automated testing) would have helped.

Poorly defined requirements may yield working software that is hard or impossible to maintain. Those with domain expertise and a solid engineering background will have an advantage in using AI by likely being more thorough.

Zudio still has more randomization than musical coordination, so sometimes the songs sound great and sometimes not so good. Nonetheless, it’s good enough I can listen to it as background music, same as I do for other generative music applications. If I get time later on, I may pull in a more skilled musician with a better understanding of scales and modes to help me tune the rules further. I’d also like to add a continuous play mode and maybe an iPad version.

Once I had the App working reasonably well, I had Claude go summarize a proper explanation of the architecture and the design details for each of the musical styles. So if you want to nerd out on how AI came up with the rules for Motorik, it’s all there.

More Than A Productivity Boost

I asked Claude to estimate the effort it would take to create the docs and code without AI. What I did in 3 days of design docs and a week of vibe coding was likely 6-9 months of human effort –roughly a 15-30x productivity gain.

But AI is more than just a productivity boost. Vibe-coding is a fundamentally new way of developing software. I doubt I could have written this application in any amount of time. Vibe coding is opening the field to a new field of developers.

Plan-driven development isn’t new. But using AI to undertake what would have been a 3 week development sprint in a couple of hours is a remarkable transformation. Adding AI tools to verify the work and further improve the process takes things into uncharted territory.

As a new form of development, AI requires a different approach. Building strong specifications, whether by hand or leveraging AI is essential. When I strayed from this approach, for example by not specifying in detail how new solos work, or not researching how the Mac handles custom doc types, the results were mediocre. These problems were typically solved in under 30 minutes, but only because I was testing as I went along and enlisting AI to help with that work. It helps to have the approach of a disciplined programmer even if you’re not writing the code. Without that, you can easily end up with an application that is brittle and impossible to maintain.

The new emerging pattern is to use AI not just to do the work but to specify it, analyze it, test it and then improve it. You need to know when to use AI and when to hit the brakes and apply your own judgement.

Over the past six months, I’ve observed a kind of breakthrough that happens when people shift from using AI as a productivity tool to working with AI as a partner. In the latter case, they evolve their own approach to get better results.

Now Is The Time

Despite the rapid pace of innovation (and acceleration) in AI, I continue to meet CEOs who seem to view AI as just a “a nice to have” productivity boost. “Sure, our marketing guys use it.” Or: “I tried vibe coding. It can’t build an Enterprise grade app.”

For founders and CEOs this is a do-or-die moment. Either you’re embracing AI to do new things or you’re going to get run over by those who do. The disruption will come from someone who is brave or foolish enough to go all-in on AI, despite the current limitations. It might come from a 23-year old founder or a 55-year old greybeard, but it’s coming.

The effort required to build applications has been reduced so much that the traditional technical barriers to entry are gone. There are no technical moats. Not only can your existing competitors build your product in one tenth or less of the effort that you took, so can your partners and your customers. And even if they won’t, they can and will wield that threat in negotiations. And as the technical barriers collapse, so will the traditional high margins software companies have relied on.

The impact on the software industry is going to be profound. AI’s impact will be bigger than that of graphical user interfaces, the internet, open source software or mobile computing. Maybe more than all of those combined. The internet took fifteen years to go from an interesting curiosity (Microsoft bundled its first browser in 1995) to workplace and ecommerce dominance ($1b in Cyber Monday online sales in 2010.) The adoption of Ai and its rate of improvement are moving much faster.

But no one knows exactly how this will all unfold.

So my advice is it’s better to dive in and shape the future than to stay stuck in the past. If you want to have a white collar job 3 years from now, you’d better start using AI.

A good product manager or designer armed with AI has the power of a 24x7 development team that can build applications exactly the way you want them. Any application that uses known design patterns can be built with AI, whether it’s a CRM system or a music application.

As the barriers to development are lowered, there will be more software created. And as with any industry that has done away with gatekeepers, there will be a lot more bad software. Let’s face it, you can half-ass your way through anything with AI.

The tools are cheap and the technical barriers are gone. What isn’t free and can’t be automated is judgment — knowing when something is genuinely good versus when it’s just a facsimile. That gap is where AI shovelware will fail, and where people with discipline, taste and judgment will win.

The Zudio application is now available for iPhone, iPad and Mac on the App store.
Design documents, prompts, source code and an audio sample are available here: https://github.com/ZUrlocker1/Zudio#Zudio.

The latest version includes Chill-out jazz, Endless mode for continuous playback, a visualizer, fast audio export and more. These features went beyond the initial development timeline.