But what happens when the tools get fast enough to outrun the rider?

Code has become the cheap part. The expensive parts are constraint definition, taste, validation, and figuring out when a technically impressive system makes the product worse.

the tl;dr: I built a word puzzle game called Right Words as a side project while working full-time. You trace two-word phrases in a grid and jump a gap between the two words. Every tile belongs to exactly one phrase.

The Problem Behind the Puzzle

A Right Words puzzle is a cluster of six two-word phrases crammed into a grid. The packing has to meet a series of constraints that are, frankly, deceptively convoluted:

• every cell can belong to only one answer

• consecutive tiles have to be grid-adjacent, including diagonals

• the gap between word1 and word2 of a phrase must be one tile skip (cardinal or diagonal) giving a max of 8 possible tiles to jump to

• no alternative tile arrangement can spell the same phrase (requires exhaustive path enumeration)

• if two tiles share a letter, swapping them can’t produce a valid alternative traversal

• no repeated words across answers, no word1 that doubles as another answer’s word2

• every phrase has to be a real two-word phrase people actually recognize, within a tight character limit

• the difficulty system optionally requires one answer to have a readable “gimme” word while preventing all others from having straight-line words

The packer uses MRV heuristic for phrase selection, seeded RNG for reproducibility, and restart limits to escape dead ends. False positive detection runs DFS against the full grid for every placed answer.

Friends keep asking when it’ll go daily. Six valid, non-overlapping, theme-coherent two-word phrases that pack into a grid with zero false positives and the above constraints is not something I can produce on that schedule (hello, Tracy Bennett? Sam Ezersky?!). 🥲

I hadn’t built a constraint-satisfaction solver before, so I designed the rules and architecture, then used Claude Code to accelerate the implementation. I defined what the solver needed to enforce, Claude built the packer, validator, and path generator. I tested the output and caught the cases it missed, like a path ambiguity bug where two same-letter tiles separated by a different letter could be swapped without breaking adjacency.

That division (I define, Claude builds, I verify) is what made the scope possible.

note: I previously discussed this dynamic in Judgment Doesn’t Scale With Speed

The Breadth Problem Solved

Justin Searls wrote about “full-breadth developers”, people who do both technical execution and product thinking. His take is that AI rewards this combination disproportionately. I’d say it more plainly: I could design Right Words before AI. But I couldn’t implement the full stack alone in any reasonable timeframe. It would’ve sat in the backlog of ideas piled high on my list of purchased and unhosted domain names.

None of the individual subsystems were impossible. In fact, all of them are pretty doable on their own (a constraint solver, puzzle packer, fun UI/UX interactions when selecting words and creating skip chains, and all the usual mobile game goodness in share cards, etc.). The hard part’s keeping product intent coherent across all of them at once, and doing it in the margins of a full-time job. That’s the breadth problem. An AI collaborator that could move between the packer algorithm and a CSS animation timing bug in the same conversation is ultimately what made the scope feasible.

Peter Steinberger (of OpenClaw fame) has a technique for bulletproofing specs using two AI contexts, one generates, one critiques. I applied that combo to a layered doc hierarchy (SPEC.md → ARCHITECTURE.md) that the AI reads every conversation (and applies to its own memory & CLAUDE.md), each layer narrowing from broad product intent to specific code constraints. Precise specs meant precise output, which meant speed. Vague specs meant debugging the spec, not the code, and the bugs nearly always came from the vague parts.

The Human Element Remains

I even had AI try to generate the puzzle content. It returned a Greek mythology theme that included STAR FISH (theme incoherency aside, starfish is one word!). The same list had TROJAN HORSE twice and HERCULES STRENGTH (?), and a bunch of one-word “phrases.” You cannot delegate content curation.

Picking themes is harder than it sounds. The theme name itself is a difficulty lever: “Fast Food” is obvious, “Legendary Lines” requires you to realize these are all idioms from Greek mythology (after ideally spending no more than a couple of minutes looking for a “Here’s Johnny!”). Monday themes run more cryptic than Friday themes, by design. I choose each one knowing that a confused player bounces and a condescended player stops coming back.

Word selection is worse. Every phrase has to be immediately recognizable, but not so common that it shows up in multiple themes. The two words have to be long enough to create interesting paths (minimum three characters each, for now) but short enough to fit the grid. Some perfect phrases just don’t pack: too many common letters create false positives, and consecutively repeated letters leave the packer with no room to route other answers around them. I’ve thrown away dozens of great phrases because the algorithm couldn’t use them without creating an alternate valid path.

I hand-curate every word list. I hand-place the paths I care about. For example, I placed GORDIAN KNOT tile-by-tile in the visual designer, locked it, and told the packer to arrange five other phrases around my shape, a puzzlingly unnecessary use of my time to give one phrase of one puzzle a specific aesthetic. This required building shape-shifting, pre-placed chain support, and updating the CLI to support completion of a --partial pack. Claude built the machinery in an hour. I spent three days deciding what the puzzle should look like. It can build anything you want! It just won’t want it for you (and in an era of creative slop being dispensed like warm soft serve, that’s a good thing).

The Difficulty Trap

I spent entirely too much time building a hard mode that rejected any packing where a word read in a straight line. Maximum difficulty.

Then, a friend played it and said, “95% of the addressable market does these puzzles to feel clever. You get better uptake by adding confetti to winning than figuring out how to obscure things.”

I’d been building for my five most hardcore friends. Analytics revealed that the players who actually left were leaving because they had no foothold.

So I (sadly) scrapped it. Fridays get a word that reads left-to-right. Mondays get one readable vertically on an edge. The “gimme” system exists because someone with fresh eyes identified the difficulty I had grown accustomed to (and thus kept trying to crank higher). I cannot stress the importance of early user testing enough!

Fast Feels Free

The tutorial has a trampoline animation on the gap tile during a jump. Worked fine in the normal game. In the tutorial, it replayed on every subsequent tap.

I prioritized AI “correction” speed over diagnosis and went with the first fix: suppress the pulse on the gap tile. This killed the visual hint showing players which tile to tap next.

Second attempt: stabilize the key so pulse changes wouldn’t remount the tile. Pulse animations went out of sync.

Third: timed effect, apply the trampoline for 500ms then clear it. Rapid tapping re-triggered it.

Fourth: ref-based tracking. Didn’t fire at all on one answer due to setState timing.

Fifth: duplicate the Grid component for the tutorial, decouple the trampoline from React’s key system entirely.

Five worked. But I should have gotten there on attempt one. The bug only appeared in the tutorial because the normal game’s validMoves empties after a jump, a !state.jump gate. The gap tile is never pulsed in normal gameplay. Asking “why only here?” instead of “how do I fix it?” would have saved four attempts.

Claude gave me five implementations in the time it would’ve taken to try two. But I was moving fast because fast felt free, and I skipped the part where you explain the bug to yourself before trying to fix it.

“95% of the addressable market does these puzzles to feel clever. You get better uptake by adding confetti to winning than figuring out how to obscure things.”

What Stayed Difficult

The hard parts were deciding what difficulty means for casual players. Or a puzzle feeling “less fun” until I traced a new version that “felt” right. Or deciding to duplicate a 250-line component rather than risk a small change to the Grid in production, now that there’s a small but loyal group of people who play every week.

That is the part I think people understate about AI-assisted development. It does not remove engineering judgment. It changes where judgment is spent.

Jobs said we’re tool builders, and the best tools amplify our inherent abilities to spectacular magnitudes. The bicycle for the mind assumed the rider knew the route. AI is not a bicycle. It’s an orchestra. You still need a conductor, a score worth playing, and the ear to know when it sounds like shit.

Without Claude Code, Right Words would still be a purchased domain name on my list of ideas I’ll get to someday. 💀 With it, the game shipped, people play it every week, and I spend my time on what the next puzzle should feel like instead of debugging a path validator at 2am. I mean… I still debug path validators at 2am. But now it’s a choice.

One example stuck with me. I merged a refactor last week that passed CI without issue. Three days later, I had to reread the diff to remember why I chose that approach over a simpler one. Nothing was broken, but I wasn't sure it was the right call and that bothered me more than an actual bug would have.

Comprehension Debt

Technical debt is what happens when the codebase degrades. There’s another kind: when your understanding of it degrades. I think of that as comprehension debt. You don’t notice it building until something breaks at 2 a.m., and then you realize you can’t reason about code with your name on it.

I’ve been using AI coding tools aggressively for over a year: agentic tools, chat workflows, autocomplete, all of it. I’m faster than I’ve ever been. I’ve shipped enough code I couldn’t explain a week later to know going faster without understanding it is a trap. Anthropic's own research backs this up. AI tools can absolutely increase output. They can also weaken your ability to reason about the code you ship.

If comprehension debt is the problem, the real question is: what am I protecting when I review AI-generated work? I’m not sure I have this fully answered.

What I Protect, What I Don’t

Most of the discourse is useless binary stuff: either you use AI or you don’t, either you’re a “real engineer” or you’re dependent. You don’t want to be the person flooring it toward a wall with blinders on to everything but the speedometer. But I also don’t want to be the one still taking a horse to work clutching punch cards. The actual skill is knowing which tasks need your full attention and which ones don’t.

What I won’t delegate. Architecture. System design. Tracing a production issue through three services at midnight when something’s on fire (log parsing aside, which AI is fantastic at). All this stuff comes from reps, and I don’t think reviewing AI output builds it the same way.

What I’ve let go. Exact API signatures. CRUD boilerplate. Stuff I've written a hundred times and will never learn anything new from writing again. It's long division at this point. Knowing it exists and when to reach for it is enough.

The middle ground. First drafts of tricky logic. Reading docs vs. asking an AI to summarize them. Manually stepping through a stack trace. I still do these because they keep my instincts sharp… but, the line does move. The question I keep coming back to: is doing this manually still teaching me something, or is it just habit? I don’t always know.

How I Actually Work With These Tools

LLMs list the options. I pick. In unfamiliar territory, I ask for approaches, tradeoffs, and failure modes instead of “the best solution.” If I let the AI make the design decision, I’ve skipped the part of the work that matters most. I’ve caught myself doing this more than I’d like to admit.

I don’t touch code until I can describe what “done” looks like. What am I building? How will I know it works? What’s out of scope? No amount of prompting fixes unclear thinking on my end.

Small pieces, reviewed like someone else wrote them. Because someone else effectively did! I break work into chunks small enough to hold in my head. That’s usually the moment I either catch it or let it compound.

If I’m getting faster but less sure, something’s wrong. These tools should make me faster and more confident. If speed is climbing while certainty drops, I need to change something in the process.

Staying Honest

After doing this long enough, I’ve learned to watch for certain signals in myself. Copying prompts without thinking about what I’m actually asking. Accepting a design I don’t fully understand because the output looks right. Skipping review because the tests passed. That low-grade unease about a piece of code that I convince myself isn’t worth investigating.

When those show up, I take the next piece of work and do it manually. Not because hand-writing code is inherently better, but because the discomfort is telling me I’m losing the thread.

Honestly, the biggest fear is needing AI because I can no longer do the work without it. I want it to make me faster, not to become something I can’t function without.

Where This Lands

I don't have this fully figured out, and it shifts as the tools do. But I've got a framework that’s started to move with it. I keep coming back to this: speed is the easy part now. In my experience, judgment is the hardest thing to build and the easiest thing to weaken if you are not paying attention.