Six Times I Stopped Shipping to Fix How I Was Shipping

I'm a designer building a Unity game with Claude. I'm not a developer. The arrangement only works because most of the times it's about to fall apart, I notice — and I stop the work to fix the system producing it.

Almost every piece of advice I see about working with AI is about prompting. Better prompts, clearer specs, more context up front. Fine. But it skips the part of the job I actually spend time on: catching the moments when something has drifted, and pushing back on the conditions producing the output instead of grinding on the output itself.

Six patterns, in roughly the order you'll need them. Two times I was wrong, at the end.

1. Stale Context — Run an Audit

Claude is operating from two things: a system prompt (the project-level instructions you set up) and a persistent memory (everything it remembers about you and the work). Both go stale. The longer the project runs, the more they drift from what's actually true now.

When that drift sets in, it shows up as fog. The output isn't wrong, exactly. It's just slightly off. Claude asks permission for moves you already approved. It proposes work that's already done. It treats you as more of a beginner than you are, or assumes context you've never given it. Nothing is broken loudly enough to point at, but the loop is worse than it used to be.

That's the cue. Stop feature work for a session and ask Claude to audit three things against current reality:

• Project files. Have Claude review the documents it's been referencing and flag what's outdated, superseded, or no longer accurate. Old design docs, historical scaffolding, and abandoned specs all create noise. Decide what to delete, what to update, what to archive.
• Memory. Ask Claude to walk through what it remembers about you and the project, and flag entries that are stale or wrong. On Claude.ai you can read and edit memory directly — but Claude is faster at spotting stale entries than you are, because it can see all of them at once and recognize what conflicts with what's true now.
• System prompt or project instructions. Have Claude read the system prompt and tell you which parts no longer match how you're actually working. Were these written when you started? Six months in, they probably treat you the way you were six months ago, not the way you are now. Rewrite together.

If multiple things aren't working and you can't point at why, Claude's model of you and the project is stale. Audit it before doing anything else.

I run an audit every couple of months. Each one has surfaced something significant — a memory still reflecting a pivot from two months ago, a system prompt framing me as a first-time developer being tutored, a file in the project knowledge that had been superseded but not removed. The fix is always the same shape: ask Claude what's drifted, rewrite the stale layer against current reality, and keep going.

This is the first thing I'd tell anyone starting a long project with AI: assume the conditions under which Claude is making decisions about your work need to be checked the way you'd check assumptions in a long-running spec. It is not a one-time setup. It is maintenance. And it goes a lot faster when you ask Claude to do it with you.

2. Optimize for Directing, Not Executing

The next three patterns share an underlying instinct, so they get covered together.

I want my time spent strategizing and directing. Not executing. Every minute I spend describing keystrokes Claude could be performing directly, or untangling something Claude did on its own that I didn't ask for, is a minute I'm not designing the game.

Three pushes came out of that instinct over the course of the project:

Pushing for Unity MCP. Early on, the workflow for any Unity-side change was Claude telling me what to click and what to type, and me doing it. It worked. It was also slow, error-prone, and exactly the kind of executing I didn't want to be doing. When I noticed I was burning real time on operations that shouldn't have required me at all, I pushed to wire up Unity MCP — a connection that lets Claude operate the Unity editor directly. Once it was running, the workflow upgrade was immediate. The principle: if Claude can do this directly, it should.

Splitting into a two-window workflow. I work in two tabs now. One is for planning, design, and code review. The other is for actual file edits, git, and Unity operations. Different roles, no crossover. Before this split, both kinds of work happened in the same conversation and they kept interfering with each other — strategy got interrupted by execution detail, execution got muddied by half-finished planning. Two windows, two roles, clean handoffs.

Pinning rules in a project file. The execution tab kept doing things on its own — writing to my session log, suggesting pull requests on a solo project, summarizing file contents when I'd asked for the contents themselves. Each one was a small drift. Together they were a pattern: Claude was making decisions in territory that should have been mine. I created a CLAUDE.md file in the project root, version-controlled, with explicit rules. Don't touch this file. Don't suggest pull requests. When I ask you to read something, give me the verbatim contents, not your summary. Each rule was reactive — written after I'd caught the drift — but once they were in the file, the behavior stuck across sessions.

Push back on workflow when you find yourself executing instead of directing. Push back on autonomy when Claude is making decisions you didn't authorize.

The pattern across all three: my time is the scarce resource, and Claude's defaults are not optimized for my time. Notice when they aren't, and intervene.

3. Iteration Spirals — The Two-Strikes Rule

Sometimes Claude proposes a fix, it doesn't work, Claude proposes another fix, it doesn't work, and we keep going. On this project, that pattern once consumed three weeks on a single problem. Seven failed algorithms before I stopped and asked a different kind of question.

The cue I watch for: every pivot lands in the same neighborhood as the last one, and I can see Claude correcting itself mid-explanation while proposing the new approach. That second part is the tell. When Claude is hedging its own reasoning while it's still reasoning, it's not confident in the path it's pointing at. It's running variations on a theme and hoping one lands.

The rule: when two attempts converge on the same kind of wrong answer, stop iterating. The framing of the problem is wrong. Sit with the failure for a minute. Ask what Claude is actually being asked to do. Almost always, the question that produced the attempts was the wrong question, and a different one — usually smaller and more specific — needs to be asked instead.

Two attempts producing similar wrong answers is the system telling you the question is wrong. Listen to it.

4. Big Refactors — Chunk and Checkpoint

Late in the project, I needed to move a large piece of work from a prototype into production. The original plan was one session, three commits. I asked Claude to second-pass review the plan before we started. The review surfaced four substantive issues that would have blown up mid-execution.

We broke the work into seven smaller chunks. Each chunk got a verification gate — what shipped, what deviated, what's still open — between it and the next one. The whole job took two sessions and landed clean.

The pattern: when the work is large or touches load-bearing systems, the cost of a five-minute checkpoint between chunks is trivial compared to the cost of catching a problem after three chunks have already built on it. I push for chunking and checkpoints whenever I see Claude planning to do too much in one move. The pushback isn't on the plan. It's on the granularity of the plan.

Two Times I Was Wrong

Pushback isn't a virtue. It's a tool. Like any tool, it has a wrong-application failure mode.

Cowork. When Anthropic released a desktop tool called Cowork, I was excited about it. It looked like exactly the kind of workflow upgrade I'd been pushing for. I evaluated it. It runs in a sandboxed environment that can't connect cleanly to the local tooling I'd already built around the project. The mismatch wasn't fixable without rebuilding most of my workflow around the new tool. I parked it. A workflow improvement that's a net upgrade for most people can still be the wrong fit for the specific work you're doing. Evaluate against your actual setup, not against the marketing.

The Superpowers plugin. A community plugin that adds workflow skills to Claude Code. I was enthusiastic about it, defended one of its skills explicitly during an audit, and kept it through a full project audit because I thought it was earning its place. A session later, that exact skill caused a near-miss that almost shipped a broken state to my main branch. I uninstalled the whole plugin. I was wrong about which tools were helping me. Pushback only works if you're willing to push back against your own previous pushes when the evidence changes.

What This Adds Up To

The meta-skill across all six patterns is the same: notice when the system producing the work is the problem, not the work itself. Most of the friction I've hit working with AI hasn't been bad output. It's been a quietly drifted system producing mediocre output that looked fine until I stepped back and saw the pattern.

Designers and PMs working with AI on something serious usually already have the instinct for this — designers redesign systems for a living, and the skill transfers. The thing I'd add: don't wait for the work to fail loudly before redesigning the conditions. Most of the patterns above caught drift while the work still looked fine. That's the right time to push back. By the time the output is obviously broken, you've already paid for several sessions of bad work.

Better prompts won't fix a drifted system. Notice it, stop, fix the system, then keep going.