here's how Shopify engineers use Claude Code to its fullest

The reason your vibe coded app isn’t breaking because you aren’t using the latest Claude model. It’s because you skipped this crucial step. Hi, I’m Nelson. I spent years as a software engineer at Shopify and am now building my own startup, Solarium, with paying customers and real money moving through it. Your feed is probably full of people using Claude Code to spin up an entire app from a single prompt. Try that on a production code base, and it’ll collapse instantly. So here’s the process that I use to ensure that I get the most out of Claude Code. 1. Write Technical Specifications Outside Claude Code. First, I stay out of Claude Code before I write any code. I sit in Claude Desktop with Opus 4.8, and we draft serious technical specs together - multiple markdown files on every feature, edge case, how the data moves, the UI, the UX, the entire picture map before a single line of code gets written. 2. Break the Tech Specifications into GitHub Epics + Issues. Next, I refuse to run that entire plan at once. No model should be trusted to one-shot tens of thousands of lines of code against a live code base. Instead, I hook up Claude Code into my GitHub and have it convert that spec into an Epic, split into issues, split into sub-issues. Now, everything is traceable. Each chunk of ticket with its own defined scope and a clear finish line. Now, I can watch exactly what’s happening, sign off on each step, and kill problems before they snowball into bigger issues. 3. Use Claude Code to Execute Each Issue & Sub-Issue. Then comes the actual building. Here’s where I actually let Claude Code do the work. It goes through each issue at a time. These are small, bounded, easy-to-review pieces instead of one massive black box. When something can pinpoint to the exact ticket that did it. This is the gap between five coding and genuinely shipping things to production. The one-prompt demos look unreal on TikTok, but they fall apart the second they hit a real code base with real users and real complexity. So spec it out, decompose it, and build it in parts. There’s another benefit, too, before I let you go. Y—I save the most powerful model to do the planning, and so the actual coding is done with something lighter, like Opus 4.6 or GPT 5.4. It’s faster, cheaper, and with comparable results. And so if you want the one-pager on how to break down your code into structured GitHub issues, comment “Claude Code” down below and I’ll DM it over to you. Follow for more Claude Code tips.