The game sat quiet for 63 days straight — zero commits — then came back with 257 commits in two weeks. That gap was not abandonment. The project was blocked, not stalled, and knowing the difference changed how I approached every build after it.
A project that goes quiet is one of two things. Stalled means nobody is pushing: I lost interest, priorities shifted, or I haven't decided what I want yet. Blocked means the tools can't do it. Stalled fixes itself the moment I show up again. Blocked only fixes itself when the ecosystem moves.
The game's gap traced to a single missing capability in Unreal Engine 5.7. I needed it, the engine version I was running didn't have it, and no amount of prompting Claude Code was going to invent it. Work resumed the day Unreal Engine 5.8 shipped, and the commit intensity went from two days of scaffolding to roughly ten times that rate across the next two weeks.
Why it matters
I used to treat every quiet project the same way: assume I was the problem, revisit the approach, rewrite the prompts. That works for stalled projects — the ones where I haven't clarified the decision or haven't asked for the right thing yet. It does nothing for blocked ones.
The interactive fiction engine is parked for a different reason, and I know it because I can name it. The harness is extremely good. If I look only at the bullet points the prompt says need to be accomplished in any given passage, they are spot-on. It's the prose that struggles to actually achieve its goals. There's also the product fit question: time and battery life on a phone may mean the product itself was poorly conceived. Two reasons, both specific. The first might be a model gap — possibly awaiting a better model — rather than a harness defect. The second is a product question I can answer by trying it on real people, but I haven't done that yet.
The game was blocked by the engine version. The interactive fiction engine might be blocked by prose quality, or it might be stalled because I haven't validated product fit yet. I can tell them apart now because I have a rule: separate "my approach is wrong" from "the tools cannot do this yet" from "I cannot do this yet." Two of those fix themselves only if I keep building something else in the meantime.
How to apply it
When a build stalls, I ask three questions in order:
- Is there a decision I haven't made? (Stalled. The fix is to make the decision or cut the project.)
- Is there a capability the tools don't have? (Blocked. The fix is to wait for the ecosystem, or route around it if I can name what's missing precisely enough.)
- Is there something I don't know how to ask for yet? (Also blocked, but by me. The fix is to build something else until I learn the question.)
The game answered question two. The commit log shows two days of scaffolding on 4–5 July 2026, then nothing until 7 September, then 257 commits across the next two weeks. The gap was not me losing interest. Unreal Engine 5.8 shipped, and with it the one feature the project couldn't route around. The engine itself unblocked the project, and I knew to come back because I had written down exactly what was missing.
The interactive fiction engine might answer question two or question three, and I won't know until I either try a better model or put the app in front of real users. In the meantime it stays parked, with the reason stated plainly: prose quality (possibly a model gap) and product fit (time and battery life). If a new model ships and I re-test the engine, I'll know within an hour whether it was blocked or whether I was asking the wrong question.
A toy project with no business case is the only place you can afford to find out how agents actually fail, before that failure costs you anything real. I learned the stalled-versus-blocked distinction on the game because the game had no deadline and no client waiting. The interactive fiction engine taught me to separate model gaps from harness gaps, because I could measure them independently: the bullet points landed, the prose didn't, and I have 19 distinct scored evals that show exactly where the boundary is.
What I do differently now
I keep a one-line reason for every parked project. Not "on hold" or "paused" — the actual reason, specific enough that I'll recognise the unblock when it happens. The game's reason was "waiting on Unreal Engine 5.8 for [capability name]." The interactive fiction engine's reason is "prose quality (possibly model) and product fit (battery/time)." If I can't write that line, the project is stalled, not blocked, and the fix is to make a decision or kill it.
I also separate the things I'm building now from the things I'm waiting on. LEGION, Sadyr and Content Ops are live and serving real work; the game is in development and playable under playtest; the interactive fiction engine and a creature-battler in Godot are both parked with their reasons written down. When something unblocks, I know exactly what to re-test, because I wrote down what was missing in the first place.
The creature-battler is parked for a third kind of block: no automated 2D-art pipeline good enough yet. The engine itself is, in my own assessment, fully functional and tested. That project taught me the same lesson eight months earlier, in a different form. I tried to build LEGION in April 2025 and kept trying by different means without success. It came together only after I learned to work with coding agents and new models were released in December 2025; the first working files on disk are dated 13 March 2026. The gap there was question three: I couldn't ask for what I wanted yet, because I didn't know the shape of the question. I learned it by building other things — the creature-battler, the interactive fiction engine, smaller tools — until the question clarified itself.
Blocked projects fix themselves on someone else's schedule, or they teach you what you need to learn before you can ask the right question. Stalled projects fix themselves the moment you show up with a decision. The only expensive mistake is treating a blocked project like a stalled one and burning time on an approach that was never going to work.