Leadership

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.

I've shipped more in the last few months than at any point in my career, and I've never been this tired at the end of a day. Both are true, and the relationship between them is the part nobody's writing about. Some of it is my own doing — when attempting something costs almost nothing, you attempt everything, and I've been a kid in the candy store. The rest is structural. The boilerplate, the builds, the Googling: never the valuable parts of my day, but they were the low-intensity parts, and removing them leaves a concentrate of pure judgment with the rest stops engineered out.

It's an operational problem rather than a personal one. Tripling output can quietly mean tripling cognitive load, and that doesn't show up on any dashboard. I've stopped reading the exhaustion as a sign I'm doing it wrong.

I had a spreadsheet budget that worked. What I didn't have was a monthly reset that wasn't manual, a way to bring my wife into it, or any hope of querying a few years of my own history. So I went shopping. YNAB wanted envelopes. Monarch wanted my bank logins. Copilot wanted a subscription. Every option wanted me to trade a method that worked for its interpretation of how budgeting should feel.

A day and a half later I had my own, built around my spreadsheet logic, connected to nothing and hosted nowhere. That's the piece: not that vibe coding kills SaaS, since I run a SaaS company and would rather not announce my own funeral, but that the personal layer of software, the one the 80s took for granted, is coming back to the user.

Forty-plus candidates screened, four engineers hired, and a taxonomy I wasn't expecting to find. Making AI fluency a hard requirement filtered the applicant pool, but the more interesting result was the spectrum it exposed among everyone who made it through: non-users, reluctant adopters who reach for it on boilerplate and tests, green users who accept whatever the tool suggests, collaborators who push back on it, and vibe coders who can ship a demo but can't explain the architecture underneath it.

The gap that matters sits between the third stratum and the fourth, and it's nearly invisible on a resume. Both groups produce working code. One follows the AI, the other leads it. A take-home that required AI usage, plus a presentation on the process rather than the output, was the only thing that reliably told them apart.

The interview industrial complex broke in two directions. The FAANGs over-optimized until leetcode prep became its own industry; startups never built the rigor in the first place and hired for velocity. Both missed the same thing. Code was never the hard part. Knowing what to build and why was always the hard part.

I started as the engineering department at a startup and hired every person who came after, and I filtered for how people reason through ambiguity rather than how they perform while someone watches them type. Some people thought that wasn't rigorous enough. Then AI commoditized code production and the startup math got brutal: one thinker with AI tools does what used to take a thinker plus two implementers. Here's what I hire for now, and how the interviews changed.