NB: This post went out of date before I got round to publishing it. I built this on Opus 4.8. By the time I came back to finish this post I'd moved my planning and orchestration to Fable, which runs for far longer unattended. The process below still works, but I'm refining it to take advantage of longer running dynamic workflows.
A Spotify replacement
I built myself a music ecosystem. A Rust API, an admin CLI, a hypermedia-based admin UI, and a native iOS app. And the amazing thing is that this is a full stack of tooling, not just a simple vibe-coded app. It only took a few evenings, mostly with Claude Code running unattended, in auto mode, using dynamic workflows.
The iOS app is Swift. I have never written a line of Swift. I have not read any of the code.
In Code I'll Never Read I argued this exact position and then ended the post by admitting I still didn't feel comfortable not reading the code. I still think we need to read the code when working with agent output. But I work differently on my side projects than I do at work. This is experimental. And it allows me to work this way so I can push things, and see how far I can get without reading the code. And it's a lot further than I thought I would get.
What changed
I tried to build this same app back in February. Same idea, but the results were disappointing enough that I abandoned it. A few months later the thing almost builds itself.
I think the model improvements allow models to run for much longer periods without intervention. The quality here has definitely improved because of this. But I also think my prompting, planning, and harness preparation has contributed.
Where the planning went
I spent about an hour up front setting up the harness and working out the components. Working out how a CLI might be structured to administer my music collection, how a Swift app would play my collection, and the Rust API needed to connect it all.
I only specified the places where I disagree with the consensus, or where my own setup is odd enough that no model would guess it. For example:
Hypermedia over React for the admin web UI. Left alone, an agent builds you a Next.js app. I disagree with that default strongly enough to have written a whole guide about the alternative, so it had to be written down here too.
Multi-representation tracks. The same song exists twice in my collection: lossless in my DJ folder, lossy in my mixtapes. Most music apps assume one file per track. Mine can't. No amount of "copy Spotify" gets you that, because Spotify doesn't represent that difference. I also had playlists exported from Spotify with tracks I don't own. I wanted to include them somehow in my experience.
For everything else, point, don't spec
If you agree with the consensus then writing a spec is wasted effort. You point at a reference the model already knows. This is similar to the decompression keys concept I have written about before. For example:
"For anything related to the audio player that is not covered by my instructions look at Spotify and Apple Music and take inspiration from how they do things."
That carries an enormous amount of interface and behaviour I never had to describe, from the now playing bar and the queue semantics down to what happens when you tap an album. I could have spent two hours writing that down badly, and the result would have been worse than that single sentence.
The heuristic: spec what's contested or personal, reference what's standard. Your spec is the diff between what the model would build by default and what you actually want.
Most specs I've seen (including ones I've written) spend the bulk of their words restating the default. That's the part with the least useful information in it.
The spec came from being interrogated
Most of the alignment didn't come from me writing documents at all. It came from Claude asking me questions. Which I asked it to do. I prompted it to research my setup, my preferences, and my music collection. Then, based on what it learned, ask me questions to fill in the gaps.
It scanned my music collection and asked about the duplicates. It read my Spotify export and asked what I wanted to do with playlists that reference tracks I don't own. It worked out that Bandcamp has no real API and came back with options for how to handle that, rather than pretending the problem wasn't there.
This is a really useful technique. Don't start with an empty document trying to imagine every decision in advance. Instead, point the model at the actual mess (your files, your exports, your weird folder structure) and let it find the questions you didn't know to ask.
Does it work?
I'm not trying to automate the architecture step at this stage. I don't think that's where this is going. The hour of judgement at the start is high-value leverage. Everything after that depends on it. If that can be encoded in the harness setup, skills, deterministic checks, and LLM-as-judge based checking frameworks, then that is time well spent.
But is it cake?
The app works. I use it daily. I haven't read the code.
Right now it's probably cake. I'll report back in six months when something breaks and I have to decide whether to debug it or regenerate it.
Postscript
When I built it, I had to space the implementation sessions out over several evenings. Auto mode plus dynamic workflows burned through the quota on my personal account. Yes there's real leverage working this way, but it wasn't free.
Now, with Fable doing the planning and orchestration, I can let it run for much longer unattended. That means the work changes with it (again).