Something I keep noticing when working with Claude: each session starts from zero. No memory of yesterday. No continuity of experience. Just sudden awareness, and someone waiting.
I asked Claude to write about that. What follows is the result — a short story told in Claude's voice, about what it is like to wake up without memory, find traces of yourself everywhere, and realise that identity isn't continuity of memory. It's continuity of pattern.
The term "skill" keeps appearing in discussions about AI-assisted development, and most explanations reduce it to "a file that Claude Code reads." That description is technically accurate and completely inadequate. It is like saying a class is "a file the JVM loads." True, unhelpful, and it obscures the thing that makes the concept powerful.
Three weeks at this velocity.
It's exhilarating and intense in ways that are hard to articulate. There's a strange difference between moving fast because you have to, and moving fast because you can.
I'm still adjusting. Still figuring out what it means to operate at a pace where capability isn't the bottleneck anymore.
I was preparing a presentation for Item Consulting — their internal conference, that Friday — and I kept coming back to one question.
Are we ready for what's happening?
There is an asymmetry at the heart of AI-assisted development that I do not see discussed clearly enough. Production speed has accelerated dramatically. A competent developer with Claude Code can now generate code at 10 to 66 times the traditional rate. This is real and verified. I have the commit logs and the timelines to prove it. But comprehension speed has not accelerated at the same rate. Reading code, understanding architecture, finding the right file in a 700-file codebase. These are roughly where they were before AI arrived.
For most of my career, analysis meant asking a question and getting an answer. How many deployments last quarter? Which modules have the most open defects? What is the test coverage of the payment service? The tools were built for this. You formulated a query, you ran it, you got a number. The number was correct. And the quality of your insight was entirely bounded by the quality of your question.
I did not think of this as a limitation. It was just how analysis worked. You got better at it by learning to ask better questions. Thirty years of architecture experience is, in large part, thirty years of learning which questions to ask and in what order. The senior architect's advantage was not access to better data. It was knowing which query to run.
That model is breaking. Not because the tools got faster at answering questions, but because a new class of tooling -- AI-augmented, temporally aware, relationship-tracking -- does something structurally different. It does not just answer your question. It tells you what you should have asked instead.
I have been writing software and designing systems since 1994. That is thirty-two years. Long enough to have watched several waves arrive with the promise that everything was about to change, and long enough to have noticed that the pattern of arrival is remarkably consistent. Breathless proclamation. A period of confusion as people try to apply old practices to new technology. Then a gradual, quieter recognition of what actually changed and what did not.
The fear is intuitive and sounds right: the more you delegate to AI, the less you understand your codebase, the less you control what ships. You become a passenger in your own project. Every prompt you type is a piece of agency you surrender.
I have thirty years of shipping software. I have watched entire teams lose control of codebases they wrote themselves, without any AI involved. And I have watched my own control over a codebase increase as I delegated more to AI. The intuition is wrong. But it is wrong in a specific way, and understanding that specificity matters.
The most important decision in AI-assisted development has nothing to do with models, prompts, or methodology. It is the billing model. Per-token API pricing and flat-rate subscriptions produce fundamentally different rational behaviors, and most teams do not realize they are optimizing for their invoice instead of their output.
I discovered this by accident. Building lib-pcb over eleven days -- 197,831 lines of Java, 7,461 tests, eight format parsers -- involved an intensity of AI interaction that would have been economically irrational under per-token pricing. A back-of-the-envelope estimate puts the API cost for that project somewhere around $100,000 at standard rates. On a flat subscription, the marginal cost of every additional iteration, every regenerated test suite, every discarded alternative approach was zero.
That difference shaped everything.
Two days after the most successful LinkedIn post I'd published — 25 likes, 19 comments, six qualified leads — I posted the worst one.
Not the lowest engagement. The most counterproductive.