Our Halloween show ships every October 31st. The release date has never slipped, and we have never once started over.

Every October, the driveway in front of our house turns into a graveyard. Skeletons climb out of the ground, toxic waste barrels glow in the front yard, and the street fills with families walking past on their way to more candy.

Why the second film usually disappoints, and what that has to do with an engineering team that just got a blank check.

Something I noticed in film school took me until this year, and an AI-assisted engineering team, to fully understand.

We named a skill after the first people who did it, and the mistake is keeping AI stuck in one department.

I built a tool to feed my engineering team faster. What I actually built was a business analyst.

I ended a recent essay by dodging a question. This is me coming back to it, still without an answer, because the question got sharper the longer I looked at my own org chart.

The consensus move in AI-era hiring is to buy judgment fully formed. Hire seniors only. Why pay someone to learn on work the tooling already does?

A companion essay for "Claude Codes on Classics"

Last week I was digging through a music licensing library, trying to find the sound for a show about teaching an AI to program forty-year-old computers. I knew what I wanted. I couldn't name it. I typed genres. I typed moods. I typed increasingly desperate combinations of both.

A follow-up to "More Done, More Tired," prompted by a chef who found the same problem in a completely different kitchen.

A Maître Cuisinier de France I worked with years ago recently told me how he analyzes a six-week menu cycle.

I mandated AI tooling across my engineering org expecting faster code. I got faster code. It was the least interesting thing that happened.

Here is the thing I got wrong, and I got it wrong in the most ordinary way possible: I thought the bottleneck was typing.

An AI agent will hand you two hundred lines in ninety seconds, and it will look plausible. The risk is not that the code is bad; it is that confident, unreviewable work arrives faster than anyone can catch it. CasaFlow is our answer: a staged pipeline of Claude Code skills, built on Duro's open-source Jig, that walks a piece of work from brainstorm to merged PR and leaves a durable artifact at every step.

The parts that matter most sit between the stages. One gate makes you explain what the last stage produced before the next one opens; the other demands evidence before anything gets called done. Neither cares whether you are a person or an agent. Process stops being a tax on the work and becomes exhaust from it.

Releases used to have a single point of failure, and it was me. The process was ad hoc and quietly nerve-wracking, the kind of thing where you clear your afternoon and hope. Nobody wanted to own it, so it fell to the person with the most access and the most to lose.

What fixed it is unglamorous underneath: staged environments, automated checks, human approval gates, git as the source of truth. On top sits a deadpan British rail announcer calling stations, a steam whistle on departure, a bell at Production Terminal, and delays attributed to leaves on the line. The whimsy is not decoration. It is the adoption strategy, and it is why rotating ownership stuck.

Ninety days ago I rebuilt my engineering team from scratch: four engineers, one shared start date, a clean slate. Thirty days in they shipped to production, and my first reaction was not pride. It was suspicion. Output that good, that fast, that early is usually output you are borrowing against, and with AI in the loop the reflex only gets louder.

So I watched, closely, looking for the corner that had been cut somewhere I could not see. It never showed up. Throughput roughly doubled, review coverage went from 24% to 85%, reverts and hotfixes more than halved, and time-to-merge got slower on purpose. What I found instead was the reason the speed held, and a better question to ask the next time good work arrives ahead of schedule.