Remove the execution. See what's left.
I went where I had no expertise to see which skills actually matter.
🤖 Building with AI · For developers rethinking how they work.
This week’s challenge: pick something you’ve always wanted to build outside your expertise. Spend 30 minutes describing it to AI. Not asking AI to build it, just describing what you want. Notice where your clarity runs out.
I wanted to prove something. Everything I’ve written in this newsletter argues that thinking matters more than coding, but I’d only ever tested that claim inside software, where I already know what I’m doing. Easy to believe you’re winning because of your thinking when you also happen to have the technical skill to execute.
So I removed the skill. Deliberately. I picked two domains where I have zero technical ability, music production and game development, and tried to ship real products using nothing but AI for execution and my own thinking for everything else.
There’s a musician on Spotify right now that I created. I also built a fully playable strategy game. I don’t play any instrument, I’ve never composed anything, I don’t know game engines, and I’d never built a game in my life. It worked anyway.
What made it work was what has always made software work: the thinking. I already believed this. Every edition of this newsletter argues it. The experiment wasn’t to discover it. It was to prove it, in domains where I couldn’t cheat.
Building music without knowing music
A friend asked me not long ago what music I listen to during focused work. Every developer has an answer to this. Lo-fi beats, ambient soundscapes, classical, electronic. I told him I don’t listen to music, and haven’t in decades. He didn’t believe me. But it was true. I like heavy metal, I enjoy a few bands, and somewhere along the way I stopped engaging with music entirely. I’m a quiet person who thinks constantly, processes ideas through reflection rather than noise. Music was never part of that process.
That gap made me curious. And curiosity plus AI turned out to be enough to build something I never could have built alone.
I created an artist. His name is Magnus Jow. He’s on Spotify, and every one of his songs explores the cosmos, the universe, and scientific concepts expressed through poetry. He’s the artist I would have listened to if I’d ever found music that matched the way I think.
Here’s what I don’t know how to do: play an instrument, compose a melody, write lyrics that scan properly, arrange instruments into a coherent track, mix audio, produce a finished song. Every technical step in the music production process was beyond my ability.
Here’s what I did know: what I wanted to express. The themes. Cosmic, scientific, reflective. The feeling I wanted a track to carry. The difference between lyrics that captured an idea precisely and lyrics that sounded nice but said nothing. I knew the what and the why. I had no access to the how.
AI handled the how. It generated lyrics, melodies, instrumentation, vocals. Every technical layer of music production that I couldn’t perform, AI could. In theory, this should have been simple: describe what you want, get music back.
In practice, it demanded more from me than most software projects I’ve built.
The refinement was the real work
The first outputs weren’t right. They were competent, technically sound, sometimes even pleasant, but they didn’t match what I had in my head. The problem was never that AI couldn’t produce music. The problem was that I needed to figure out how to communicate what I wanted with enough precision for AI to get close, and then refine the gap between close and right.
Four dimensions needed to be solid before anything good came out:
The lyrics required cycles of generation, reading, filtering, injecting my own ideas, regenerating, reading again, cutting what felt wrong, sharpening what felt close. AI could write lyrics. I couldn’t. But I could read a verse and know immediately whether it carried the weight of the idea I was trying to express. That judgment, the ability to evaluate creative output against an internal standard I couldn’t articulate technically, was the entire contribution.
The music style needed definition that went beyond genre labels. Saying “ambient electronic” produced generic results. Describing the specific texture I wanted, the pace, the mood, how the sound should feel at different moments in the track, produced something closer. Every round of refinement taught me that the quality of the output depended entirely on the quality of my description.
The singer’s voice was a decision with consequences. The wrong voice made good lyrics feel hollow. The right voice made the same words land differently. This was a taste decision, not a technical one, and no amount of AI capability could substitute for knowing what I wanted to hear.
The album theme held everything together. Individual tracks needed to work on their own, but the album needed a coherent arc. That arc existed in my head before any music was produced. It was a product vision, the same kind of thinking I apply when designing a software system’s architecture, just expressed through sound instead of code.
Each of these dimensions went through multiple iterations before reaching a version I was willing to ship. The process looked exactly like the refinement loops I use in software development, except I couldn’t cheat by writing any of the implementation myself. Every version was produced by AI. My job was to evaluate, direct, and decide.
The pattern I recognized
Halfway through the album, I realized I’d seen this workflow before. The hardest software projects I’ve worked on were never the ones with the most complex code. They were the ones where the requirements were unclear, the stakeholder didn’t know what they wanted, and no one had taken the time to think through what the product actually needed to do.
When those pieces are solid, when the vision is clear, the requirements precise, the decisions made deliberately, the coding becomes the straightforward part. Difficult, sometimes. Creative, occasionally. But the execution follows from clarity. The thinking is where the real work lives.
I’d known this for years. But knowing it while you’re the one who can also write the code is different from knowing it when you can’t. Music stripped away the safety net. I couldn’t fix a bad track by jumping into the production layer, the way I might fix a bad feature by jumping into the code. All I had was my thinking: my vision, my taste, my ability to evaluate and direct.
And it was enough to ship an album.
Building a game without knowing game development
When I was a teenager, I played a Korean-made strategy game called Vital Device. Think StarCraft: you build bases, manage resources, command units in real time. This one had a biological sci-fi theme. Units that felt alive, organic structures, a world that was strange and specific enough to stick with me for decades.
I played the demo version because I couldn’t afford the full game. I spent countless hours in those limited missions, imagining what the rest of the game would be like. When I eventually had the money to buy it, the game had disappeared. Too old, too obscure, too hard to find.
I know StarCraft exists. I could buy it right now and play essentially the same genre. But I didn’t want the genre. I wanted that game. The specific one from my memory, with its particular aesthetic and the feeling it gave me as a teenager who couldn’t afford the full version.
So I rebuilt it. Using Claude, Gemini AI Studio, and a game engine I’d never opened before, I built a fully playable version of the game I’d been carrying in my head for over two decades.
Same pattern, different domain
I don’t know game engines. I don’t know game architecture. I don’t know how to build a strategy game from scratch. What I know is how to think about systems: what components need to exist, how they interact, what the user experience should feel like, where the complexity lives. Software architecture gave me a mental model for decomposing a game into buildable pieces, even though I’d never built a game before.
The same refinement cycle from the music project played out here. And the result was the same: the game is fully playable. Built by someone who had never made a game, using tools he’d never used, in an engine he’d never opened.
What building outside your domain reveals about building inside it
Here’s what I couldn’t see clearly until I left software: when you’re the person who can write the code, the execution and the thinking blur together. You move between them so fluidly that it’s hard to tell where the valuable work ends and the mechanical work begins. You might spend an hour on a problem and attribute the difficulty to the code, when the real difficulty was figuring out what the code needed to do.
The Portuguese word for this is desapego. Letting go. Letting go of the execution, of the identity tied to being the one who writes the code, of the comfort that comes from knowing you could always jump in and fix things at the implementation level.
When I removed that comfort, what remained was enough to ship. That’s the point.
Edition #4 covered the skills that don’t expire. This was the stress test. Every skill I used to ship music and a game was a skill I’d built through software, not through those domains. The domain-specific execution didn’t transfer, because it didn’t need to. AI handled that part.
The real lesson from Magnus Jow
There’s a personal dimension to this that goes beyond the professional argument.
I spent decades as someone who doesn’t engage with music. That was never a problem to solve. But creating Magnus Jow gave me access to something I didn’t know I was missing: a way to express ideas that don’t fit into technical writing, into newsletter essays, into the formats I’m comfortable with. The cosmic themes, the poetic framing of scientific concepts, that was a part of my thinking that had never found an outlet.
AI didn’t give me creativity I didn’t have. It gave me execution capability I didn’t have, which unlocked creativity that was already there. The ideas existed. The taste existed. The vision existed. What was missing was the craft, and for the first time in history, the craft can be delegated.
This is what I mean when I say developers need to rethink what they are. You are not your ability to write code. You are your ability to think about problems, envision solutions, evaluate results, and direct execution toward an outcome. The code was always just one medium. Now that AI can handle the medium, what’s left is you.
Try This
The exercises from previous editions built outward: a delegation map, a judgment breakdown, a problem statement, a decision analysis, an evaluation document, a mentoring reflection. This week, the exercise goes sideways.
Think of something you’ve always wanted to build that has nothing to do with your professional expertise. An illustrated book. A short film. A mobile app for a hobby you care about. A visual identity for a side project. Anything where you care about the outcome but you don’t have the technical skill to produce it.
Now spend 30 minutes describing that thing to an AI tool. Describe it in detail: what it should look like, how it should feel, what it needs to accomplish, who it’s for, what makes it different from existing versions. Write it as if you’re briefing someone who has every technical skill in the world but no understanding of your vision.
When you run out of things to say, look at what you wrote. The places where your description is precise are the areas where your thinking is clear. The places where you got vague, where you wrote something like “it should feel right” or “something cool,” are the areas where you haven’t done the thinking yet.
That gap between precision and vagueness is the same gap that exists in your software work. You’ve just never seen it this clearly because your technical ability fills in the blanks automatically. When you can’t fill them in, the gaps become visible.
Keep that description. If you want, use it. Start a project outside your expertise and see what transfers. Magnus Jow started as 30 minutes of description. He ended up on Spotify.
The Deeper Cut
The most counterintuitive discovery from these projects was that my taste improved as I created. I started with a vague sense of what I wanted and ended with a precise internal standard I didn’t know I was developing. Each round of evaluation, each moment of recognizing that an output wasn’t right, each decision to push further. All of it built a judgment muscle I couldn’t have trained by consuming music or playing games passively.
That’s the compound effect of building: you don’t just produce an output, you develop the ability to produce better outputs next time. This applies to software, to music, to games, and to every domain where the thinking matters more than the execution. The builders who start now, in any domain, will have a judgment advantage that passive consumers will never catch.
Paid subscribers get the creative project briefing template: a structured format for describing a non-technical project to AI, with specific prompts for vision, style, evaluation criteria, and refinement loops. It’s the same framework I used for both Magnus Jow and the game, adapted so you can apply it to whatever you’ve always wanted to build but never had the craft for.