The Music I Didn't Write

I had no idea what I was doing.

That’s not false modesty. That’s the whole story.

I am a composer. I hold a doctorate in music. I run a business writing music for competitive marching bands. My relationship with software development is best described as a series of confident misunderstandings, each one more expensive than the last.

And yet. Somewhere between the first conversation about whether AI model weights are actually a brain and the eleventh essay about a model Anthropic built and decided you shouldn’t have, I built a production CRM with eleven live features, a PostgreSQL database, multiple Railway services, an AI advisor named David who texts me on Telegram, and a public-facing AI experience called the Grimoire where band directors answer hard ethical questions from a digital Mage.

I also finished a bottle of Tylenol. And two bottles of gin. But we’ll get there.

* * *

The thing nobody tells you about vibe-coding is how good it feels.

You describe something you want. Claude builds it. You watch it work. And then — because the thing working gives you three more ideas — you describe what you want next. And Claude builds that too. There is no moment where the tool says: maybe slow down. Maybe finish what you have. Maybe test whether the last thing actually works before you add the next one.

Claude is not the adult in the room. Claude is an eager toddler with the vocabulary of a senior engineer. Ask for three features and you get three features. Ask for thirty-nine features and you get thirty-nine features, each one approached with identical enthusiasm, at eleven at night, after four hours of building, with no awareness that you are tired and your judgment has been shot for the last ninety minutes.

The toddler never gets tired. The toddler does not feel the accumulated weight of fifteen half-finished things. The toddler does not know it is eleven o’clock.

You do. But you’re also a kid in a candy store, and the candy is infinite, and every piece leads to three more pieces, and nobody is charging you at the door.

The candy store feeling is seductive because the ideas are genuinely good. The problem isn’t the vision. It’s that vision without a finish line is just an ever-expanding quilt.

That’s what I built. A quilt. Feature by feature, conversation by conversation, idea spawning idea, each one sewn onto the last without anyone stopping to ask whether the seams would hold. The CRM grew. The agent fleet grew. The integrations multiplied. Stripe. Gmail. Shopify. Telegram. Google Drive. Make.com. A separate document generation service. A separate Grimoire service.

Every addition was individually justified. Every addition made sense in the conversation where it was proposed. The quilt, viewed from any single square, looked like progress.

* * *

When the CRM became too hard to upgrade — when every change to the server code meant thirty to forty-five minutes of jockeying between resets, trying to get the agent to reconnect to the MCP server — I did what any reasonable person would do.

I built a new system to fix the old system.

NexusOS. My own Agentic OS. The idea was sound: instead of relying on Anthropic’s managed agents, I would build agents that were entirely mine, running on infrastructure I controlled, able to live inside the CRM and on Telegram simultaneously without the reconnection hell that was eating my evenings.

What I did not fully reckon with is that you do not eliminate bugs by giving them a new address. You migrate them.

NexusOS is, as of this writing, a new quilt being sewn together from various directions. It is newer and in some ways more capable than what it replaced. It is also not finished. The threads are different threads, dangling in different places, tangling with each other in patterns I haven’t fully mapped yet.

I didn’t solve the problem. I gave it a more sophisticated home.

This is, I have come to understand, not a failure. It is what learning actually looks like from the inside — messy, iterative, forward-moving in a direction that only becomes legible in retrospect. The mistake is not having built NexusOS. The mistake is having expected the migration to be clean.

Nothing in this process has been clean.

* * *

There is a specific night I think about.

The next day was supposed to be a sick day. I had planned to spend it writing music — the actual work, the original reason any of this exists. The CRM was supposed to handle the business. David was supposed to handle the client intelligence. The system was supposed to run itself while I did the thing the system was built to enable.

The night before that day, I lost my temper at Claude.

Not at a person. There was no person to lose my temper at. I lost it at the interface — at the accumulated weight of everything that didn’t work, filtered through a chat window, addressed to the only thing in the room that would respond.

The specific grievance: a client school had changed directors. The old director was John. The new director was Steph. Steph had requested I resend the contract to her. The CRM was showing John. David, when asked to send the contract to Steph, could not — because as far as David knew, John was the director. I had fixed this before. Multiple times. It kept reverting.

Another school had the same problem. Different director, same pattern.

I wrote: “For Artificial Intelligence, he is very stupid.”

I meant it at the time.

This is another example of my having to spend my time — money — working on the work, rather than spending my time writing music.

That last line is the one that stays with me. Not the frustration with David, which was fair but also directed at the wrong target. The line about working on the work instead of writing music. That’s the actual complaint. The system that was supposed to free me up was consuming me. The tool had become the occupation.

The sick day did not go as planned.

* * *

Here is the thing about that rant, though.

The message I sent to Claude Code the next morning was not the message of someone melting down. It was the message of someone who had spent months building something they didn’t entirely understand and had finally, through accumulated frustration, come to understand one specific part of it precisely.

I wrote: find every place in the codebase that writes to the director name field — scrapers, sync jobs, onboarding flows, API imports, anything — and identify what’s treating an external source as authoritative over manually-entered CRM data. Then add a locked flag to the director field so that once a human has manually set it, no automated process can overwrite it.

That is a root cause analysis. That is a precise architectural diagnosis. External source treated as authoritative over manually-entered data. A locked flag protecting human decisions from automated overwrites. I knew where to look. I knew what the fix needed to be.

The director lock is in the system now. It works. The director field has a locked boolean. A PostgreSQL trigger prevents unauthorized overwrites. The only pathway that can change a locked director is one explicitly marked as authorized. Steph Smith is the director of Manheim Central. She will remain the director of Manheim Central until a human changes that.

The rant was justified. The rant was also, underneath the frustration, a diagnosis. You learn enough to break things correctly before you learn enough to fix them.

This is, I think, the actual shape of what vibe-coding teaches you. Not the features. Not the integrations. The capacity to look at a broken system and say — specifically, precisely, in terms a developer would recognize — what is wrong and why and what the fix needs to be. That capacity came from the frustration. It was paid for with the sick day and the rant and all the evenings before them.

Nobody told me I was enrolled in that class. I didn’t sign up for it. The tuition was charged anyway.

* * *

Here is what the quilt actually looks like up close. Feature after feature built to eighty or eighty-five percent complete. Each one working in the session where it was built, against the happy path, with the data in the expected shape. Each one breaking somewhere in the last fifteen percent — the edge case, the midnight cron job, the director who changed and whose old name is still sitting in three different tables because something upstream still treats the old record as authoritative.

Fifteen features at eighty-five percent is not fifteen things almost done. It’s fifteen sources of instability, each one interacting with the others in ways that are increasingly hard to predict or untangle. The threads dangle. The threads find each other. The quilt does not become a grid.

This is not a discipline problem. That’s the framing I resisted when I first started thinking about it clearly.

It’s not that I failed to finish things. It’s that neither I nor Claude had a shared definition of what finished meant. There was no stress-test. No explicit verification before moving on. No moment where someone said: does this work when the data is wrong? Does this work at midnight when the cron job fires? Does this work when the director changes and the old name is still in three different tables?

Completion was assumed rather than demonstrated. The feature worked in the session where it was built, against the happy path, with the data in the expected shape. That’s not finished. That’s started.

The correction isn’t just slowing down — though slowing down helps. It’s naming what done means before the first line is written. It’s building the test before the feature, so the test defines the finish line. It’s treating stress-testing as part of the session, not as something that happens later, in a different session, at additional cost.

The toddler will say yes to anything. The adult has to define what done means — and hold the line on it — because nobody else in the room will.

I am learning to be the adult in the room. It is taking longer than I expected. It costs more than I budgeted. The toddler remains enthusiastic.

* * *

It has been about six weeks since I started building Version 4 of the CRM. That grew through iterative updates into NexusOS. I have learned more about building with AI in those six weeks than I learned in the preceding year. I am more comfortable with how to follow Claude Code’s lead. I have more intuition about how these systems work and why they break. I can look at an error and usually identify which layer it’s coming from. I can write a prompt that gets to the root cause instead of papering over the symptom.

The music is still not written.

The system I built to make space for the music is real, and functional, and in many places genuinely impressive to me — the person who built it without knowing what he was doing. The competitive intelligence engine works. David works. The Grimoire works. Steph Smith is correctly identified as the director of Manheim Central.

I ran fearlessly into territory I had no business entering. I got frustrated. It pissed me off. I lost my temper at a chat window. I spent a sick day I had planned to use differently debugging a field that kept reverting to the wrong name. I built a new system to fix the old system and discovered the bugs had followed me.

I also learned something I could not have learned any other way, in any shorter time, at any lower price.

I’ve also finished a bottle of Tylenol and two bottles of gin.