Shipping 30 builds with Claude in 10 weeks
I know engineers with twenty years of experience who can't ship a Claude app in an afternoon. Not because they lack skill — they're better programmers than I am. They lack reps.
That's the gap Gencay is trying to close in his Claude: Build It series on Learn With Me AI, where he commits to thirty small Claude builds across ten weeks. The pitch: stop saving tutorials, stop reading threads about the model that just dropped, and build something — anything — every few days. By summer, you can look at a new tool on Monday and ship with it by Friday.
It's a good pitch. I think it's mostly right. I also think most people who try it will quietly stall around build twelve, and the reason is worth understanding before you start.
Tutorials teach syntax. Builds teach recovery.
The point of the sprint isn't the apps. The apps are throwaway. The point is the failure modes you can't read about: the moment your prompt produces six layers of folders you didn't ask for, the moment your agent loops forever, the moment a tool call silently swallows an exception. You learn to recognise these in your gut, and you learn the three or four moves that get you out.
That's the reflex. It really doesn't come from reading.
A useful analogue: musicians don't get faster by reading about scales. They get faster by playing scales until their hands stop asking permission. The work is boring on day three, humbling on day six, and somewhere around day twenty it goes quiet — meaning you stop noticing the friction because the friction is gone.
If you've used Claude Code or Cursor for a year and still feel like you're "trying things," you haven't done the reps. The good news is that thirty builds, even small ones, is enough to push past that.
Where the sprint actually fails
The failure mode isn't laziness. It's that builds 1–10 are obviously different from each other — a recipe parser, a Slack summariser, a CLI wrapper — and each one teaches you something. Builds 11–20 start to feel similar. The reps are happening but the variable isn't changing, so the learning curve flattens.
If you're going to commit to this, decide ahead of time how the constraint escalates. A few options:
- Time pressure. Build 1 gets thirty minutes. Build 15 gets fifteen. Build 25 gets seven.
- Stack drift. First ten in your comfort language. Next ten in something new. Last ten with a runtime you've never touched.
- Eval discipline. Early builds, you ship when it "works for me." Middle ten, write three tests before merging. Last ten, write the eval before you write the prompt.
Without one of those, you'll do thirty similar builds and exit with roughly the skill you had at build six, just more tired.
A concrete first build
Pick something boring. The boring ones teach better.
Mine recently was a script that reads my last week of git commits and writes a one-paragraph "what I worked on" summary I can paste into our team's weekly. It took twenty minutes. Most of that twenty minutes was Claude proposing a 200-line solution and me deleting it down to forty.
The skill that build taught me wasn't "how to summarise commits." It was that Claude's first instinct is almost always to over-engineer, and the second-fastest path to a working artefact is to push back hard on the initial scaffold. I now do this reflexively on every project, including ones I'm paid for. That's a transferable reflex from a throwaway app.
The senior-engineer trap
If you're five-plus years in, the sprint will tempt you to skip the small builds and go straight to "real" projects. Don't. The whole point is volume, and a real project is going to take you two weeks and teach you one lesson.
The other trap, which I fall into constantly: turning a thirty-minute build into a side project. You start with "summarise my commits" and three hours later you're designing a plugin system. The constraint is the lesson. Cap the time, ship the ugly version, throw it in a scrap-builds/ folder, move on.
Gencay's framing — every build has a simple version anyone can run, and a harder version that pushes further — is the right shape. I'd add a third tier: a destructive version where you deliberately break something (rate limits, auth, malformed input) and watch how Claude recovers. That's where the reflex actually compounds, because recovery is what real work looks like and tutorials never show it.
The prediction you can disagree with
Here's the take I'd push back on in the source: the reflex isn't fully transferable across tools. Gencay's argument is that the tools change every week and the reflex doesn't. I think that's about 70% true.
The portable part is real: prompt structure, eval discipline, knowing when to hand off versus when to dig in. Those carry. But the muscle for one specific tool — Claude Code's particular failure modes, Cursor's quirks, the way a given agent framework loses state — has to be re-learned every time the tool ships a major version. I've now done two of these sprints (Cursor in 2024, Claude Code in 2025) and the second one was faster but not free. About a third of the friction came back.
So if you do the thirty builds in Claude Code today, plan for a smaller follow-up sprint the next time the tool changes meaningfully. Five builds, not thirty. But not zero.
The small move I'd start with
Pick a date for build #1. Block ninety minutes. Don't pick the cool idea — pick the boring one. Set a hard scope: one file, one prompt, one feature. Ship it. Put it in a folder. Write three lines about what surprised you.
Then do it again on Thursday.
The first ten will feel pointless. The reflex shows up around build fifteen, the same way it does in any practice. By build thirty, you'll look at a new model release the way a chef looks at a new knife — interested, not anxious.
Read Gencay's series if you want the prompt-by-prompt walkthroughs. But don't read instead of building. That's the trap the sprint exists to break.
Sources I drew from: