Claude Code at Ninety Days: What Held

I started keeping a list of sessions that produced nothing I shipped. These weren't failed sessions. Claude delivered exactly what I asked for, and I deleted it anyway. That list got longer than I expected.

Claude Code has been my primary development environment for the better part of this year. I use it daily across both the CLI and the claude.ai project context. The ninety-day window this essay covers is the one where the patterns got specific enough to name.

The Yield

I built fifty Claude skills. About fifteen fire regularly. Thirty percent. I read that as a yield rate, and it's the number that tells me whether to keep building or stop and audit first.

The dead seventy percent breaks down roughly like this: a third are too narrow (the task comes up quarterly, not daily, not enough reps to justify dedicated encoding), a third are too broad (the description triggers the skill on adjacent tasks it wasn't built for, adding noise to sessions that didn't need it), a third are under-maintained (the instructions were right when I wrote them and the environment shifted since). None of them failed at deployment. They just stopped getting used.

The fifteen that held have something in common: they encode judgment I had already formed before I wrote the skill. I wrote them because I already knew how the task should go and was tired of making the same corrections every session. The skills I drafted to teach the model something I was still working out are the ones that died.

The thirty percent is an accurate reading of where my own judgment was specific enough to encode versus where I was still negotiating with the problem. The model can't do that negotiating for me. It shows me where I haven't done it yet.

What Doesn't Ship

The list tracked something narrower than failure.

A production gap session looks like this: I'm building an integration. I ask Claude Code to wire the auth flow against the existing session pattern. It does. Clean code, right idioms, passes lint without a flag. I look at it and delete it. It handled the happy path and nothing else. The error states aren't there. The retry logic isn't there. The failure mode I've been burned by twice in this codebase wasn't in the prompt, so it's not in the output.

The model delivered exactly what I asked for. I asked for the wrong thing, and the session log looks the same either way.

The hard part is that production gap output is plausible. It passes the taste test. You have to run it against something real, against the error states, against the edge cases that live in your head and nowhere else, to find that the floor isn't there. By then you've already spent the session.

The list I was keeping was tracking this: how often I arrived without a complete picture of what I needed, let the model generate against an incomplete frame, and deleted the output when the incompleteness surfaced. Often enough that it was the pattern to fix first.

Context Is Architecture

The change that helped most: I stopped treating each session as a fresh task and started treating it as the next turn in a known architecture.

In practice, three layers, each doing a different job:

The model doesn't remember the previous session. The architecture around the model does. CLAUDE.md is the context that carries between sessions, and keeping it current is the work. The deleted-output list got shorter when I took that seriously. The model didn't change. The sessions started with more of the picture.

"1" in the stats row is the count on changes that materially affected output quality across the ninety days. Everything else I changed was tuning on top of a broken layer.

What the Model Doesn't Know

Claude Code is faster than anything I've used for implementation work. It is not smarter about what to implement.

The sessions that worked were the ones where I arrived with a complete picture: spec, failure modes, edge cases, definition of done. Sessions on the deleted-output list were the ones where I was still figuring out what I needed while the model was generating against whatever frame I'd given it. The model optimized toward plausible output on the frame. When the frame was thin, the output was plausible and wrong.

A senior engineer using this well doesn't get more output. They get earlier signal on where the spec was thin. It shows you, fast, where your thinking is thin. Once I stopped expecting it to do that thinking for me, that became the most useful thing about it.

The tool can build anything you can describe precisely. After ninety days, that's still the limit.

A skill is a file. The judgment has to exist before you open Claude Code, and ninety days was long enough to show me where mine did.