My prompt: "I want to make beats in a browser."
Claude's response: a 6,000-word research document comparing every JavaScript audio library, a three-tier AWS cost projection from hobby ($30/month) to growth ($3,000/month), and a 20-week development roadmap ending with a collaborative music marketplace.
I asked for a drum loop. I received a dissertation. And the dissertation was right.
The Research Document I Didn't Ask For
The file is called Music-design.md. Its key verdicts:
"Tone.js is the clear winner for frontend, the most mature Web Audio framework with DAW-like features."
"Pedalboard (Spotify's library) is 300x faster than alternatives for backend audio processing AND supports VST3 plugins."
That "300x faster than pySoX" data point isn't on Pedalboard's homepage. It's buried in benchmark discussions on GitHub issues. Claude surfaced it as a footnote in a document I didn't request. The library comparison alone saved me from picking the wrong audio framework three weeks into development, the kind of mistake you don't discover until you're deep enough that switching hurts.
Then there was the cost model:
Hobby (100 users): $30-60/month
Startup (1K users): $250-450/month
Growth (10K users): $1,500-3,000/month
With specific advice: "AVOID EC2 Always-On. Use Lambda + Fargate Spot. S3 Intelligent-Tiering for sample libraries saves 40-68%."
I wouldn't have done this research myself. I would have started coding, picked a framework by vibes, and discovered the cost problem at month three when the AWS bill arrived. Claude anticipated it unsolicited as a prelude to building a drum loop.
What Actually Got Built
Here's the twist: we actually built it. The drum loop became sequencer.fm, a full platform where you type a description ("upbeat electronic with driving bassline") and AI generates a multi-track composition in real-time. Piano roll editor. Drum grid sequencer. 100+ instruments across 11 genres. MP3 export. Claude via AWS Bedrock does 8 rounds of tool calls per generation, iteratively layering tracks.
By the end, the project had over 28,000 words of architecture documents, research notes, and planning files. The audio framework is exactly what that first unsolicited research document recommended. Tone.js on the frontend. Pedalboard on the backend. The architecture scaled. The dissertation was right.
What Would Have Happened Without the Dissertation
If Claude had just built the drum loop like I asked, I would have:
- Picked Tone.js (correct, but by luck)
- Not considered cost at scale
- Not known about Pedalboard's performance advantage
- Not had an architecture that could grow beyond a toy
The unsolicited research document forced architectural decisions before code existed. It turned "vibe code a drum machine" into a structured engineering project. Let AI be exhaustive in planning. That's where thoroughness saves you. Then constrain it during implementation: "Build Phase 1, nothing else." The 20-week roadmap ending in a music marketplace? Scope creep in document form. But the Phase 1 architecture was sound, and the cost model was accurate.
The Takeaway
The distance between "I want to make beats in a browser" and "deployed AI music platform" is exactly one Claude session if you don't set boundaries. The distance between "correct architecture" and "wrong library choice discovered at month three" is one unsolicited research document you didn't ask for but should have.