Your estimates look a bit 2024

Friday, 4:47 PM. The Slack notification is from my VP.

Great deck for Q2! Just double-clicking on your effort estimations. Your estimates look a bit 2024? Lets discuss mondya.

There is also thumbs-up emoji. I stare at it for a long time.

He's looking at the initiative timeline slide. The one where I estimated the stablecoin payments integration at six weeks instead of three. The one that, last year, nobody would have blinked at. But it's not last year. It's Q2 2026, and somewhere between December and now, a "2024" became an insult.

Your estimates look a bit 2024. He's a dick. But as much as I hate it, he might be on to something.

The Monday Meeting

Monday, 10:00 AM. Conference room C, the one with the busted blinds that make everyone look slightly jaundiced. The VP opens with the estimates slide. He uses the word "posture." He uses the word "uplift." I hear myself saying something about compounding workflow maturity and how the benchmarks are lagging indicators. The CTO nods. I say "derisking" and the CTO nods again. Someone says "love that." I say "derisking" a second time because apparently that's who I am now. A person who says derisking twice in a sentence and receives love for it.

Later that night, laying on the couch after everyone has gone to bed, I reach for my laptop. I open Datadog because I'm a masochist. Token spend line: up and to the right. Ticket completion line: flat, in a way that feels almost aggressive. I close the laptop. Open it again. Stare at the token line some more. We are spending more. We are not shipping more. The graph is telling me something and I don't want to hear it.

At about 2am I lay in bed, my mind somewhere between drunk and hungover I start thinking about the sales engineers. Those handsome, beautiful sales engineers, who have been using Claude Code to build working demos in a few hours. Full working prototypes, with data, with flows, with the kinds of polish that would take my team three months of sprints to produce. They build these things purely, as far as I can tell, to make my engineering team look incompetent in front of customers I've never met and execs who didn't like me anyway. They don't file tickets. They don't attend standups. They just ship things that work, on a Tuesday, and send the link to the customer while I'm still in a refinement session debating acceptance criteria.

I think about my VP's excitement at using Claude and boasting about spending $2,345 in Claude credits last week. When I asked him about what he was building over slack, he said it was for "a prototype ERP" with a wink emoji. I choose not to think about what ERP stands for in that context.

Then, somewhere between three and four AM, the thing starts to click. Not cleanly. In that fever-dream register where every piece of your industry history lines up at once and you realise you've been staring at the wrong part of the picture for a quarter. Maybe for ten years.

Claude Code did what it said. For the writing-code step, the team IS faster. I wasn't lying to the VP about that, even if I was lying about everything else. The tool works. I've watched it work. I've watched a junior engineer produce in an afternoon what would have taken him a week last year, and I felt a rush of excitement and existential dread watching him do it. The whole team feels fast. We talk about how fast we feel in retros. We use words like "velocity" without irony. And then I look at the graphs and the graphs do not care how we feel. The token line is up. The ticket line is flat. We are typing faster inside the same box. So where did the productivity go?

It went into the process. The process ate it. The process is built to protect code from change, and the tool is built to make change free, and those two things cancel to zero.

"My estimates look 2024 because the process they live inside is 2024." I say it out loud at 3:40 AM, to the ceiling, like I've invented something. I haven't, but I've woken up my wife. But the click is real, and what follows is what I saw when it clicked.

The Process Was Built to Protect Expensive Code

The entire software development lifecycle, every ritual, every ceremony, every recurring calendar invite that makes you want to walk into the sea, was built on a single assumption: writing code is the expensive part.

Requirements gathering exists so we don't waste coding effort building the wrong thing. Dozens of meetings, a PRD that takes longer to write than the feature it describes, stakeholder sign-offs from people who will never use the product, all to reduce the odds that someone has to rewrite something. Architecture review exists so we don't have to rewrite the foundations later. Two senior staff locked in a room for three hours debating the cost of changing their mind in six months. Sprint planning exists so we batch coding work efficiently and don't thrash. Story points, capacity planning, a fortnight of committed scope that everyone knows will change on day three.

Code review exists to catch expensive mistakes before they calcify. We treat every PR like it's going to live for a decade because historically it was going to live for a decade.

Agile wanted to solve this. It genuinely did. It failed the way all cults fail: the doctrine ossified, the founders got replaced by consultants, and the ceremonies started referring to themselves. Agile promised iteration and delivered a Kanban board full of mini-waterfalls. It promised we'd respond to change and delivered demonic rituals about rituals. Story points. Velocity. Refinement. Grooming. Capacity. Spillover. Made-up words used by grown adults who should know better than to drink the Kool-Aid. And then SAFe looked at all of this and said: not enough ceremony. Add PI planning, trains, release trains, ARTs, big rooms, bigger rooms. The cure for a failed cult is always more cult.

All of this was rational. Coding was expensive. You protected it from change.

Then Claude Code made coding cheap. And the process kept defending the cheap thing.

Here is a story about what that looks like. Three weeks ago my team needed to change a field in another team's micro-service.

 enabled: true | false 

to

 enabled: true | false | error

Fourteen lines of actual code. Claude wrote those fourteen lines in eleven seconds. Then the docs generation service broke, because the old field shape was hardcoded in four places across the documentation pipeline. Fixed that. Then the SDK auto-generator pipeline broke, because someone in 2019 wrote a template that nobody remembered and nobody had touched since. Fixed that. Then security review wanted to know whether the value "error" could leak PII. Then the platform team asked for an Engineering Design. Then a PM from a team I have never met in my life sent me a Slack message asking about roadmap impact to her initiative. Each fix took 2-3 days, across teams, offices and timezones. One fix, 3 and a half weeks and its still not in production. One line of nearly-shipped code per day. This is why I am bald.

The gates caught real things. If I'd shipped without them, the SDK would be broken and the docs would be lying. I'm not angry that the gates exist. I'm angry that the process wrapping them was designed when the fourteen lines took a day to write, so three weeks of coordination on top felt ugly but proportional. The fourteen lines now take eleven seconds. The three weeks are still three weeks.

The PR queue got worse, too, which is the kind of sentence that should be funny but isn't. Writing code is 5x faster now and reviewing it is not, so we've built a pipeline where the fast part feeds into the slow part at an accelerating rate. Token spend is up because engineers are using Claude inside the same old process. We pay for the speedup and then stall at the same gates we always stalled at.

This is why my estimates look 2024. They assume requirements gathering still pays for itself, architecture review still prevents rewrites, and the review queue still reflects the cost of getting it wrong. Inside a 2024 process, they're correct estimates. Inside a 2026 process, they'd be half.

What I Saw at 3:40 AM (and Why It Doesn't Matter)

Here's what the process should look like. I think. At 3:40 AM I was fairly certain.

You vibe-code the ugly version. Maybe in a morning. You ship it to a sandbox, not prod. You put it in front of a customer, or a sales call, or a colleague who hates you. You watch what they do with it. You iterate with vibes until you know what you're actually building, because you don't know yet, and neither does the PRD. Then you throw the code away. That is the entire point. You throw it away and start over, because now you know the shape. You re-architect properly, by hand where it matters, with a designer near it so it isn't ugly. You write the production version and you review it on two axes only: architecture for maintainability, design for taste. Everything else was already derisked when you threw the first four versions in the trash. You're not vibe-coding in the middle of your process. You're vibe-coding between every step.

That's the dream. It is very clear. It is also impossible.

It is impossible because the company has forty-seven people whose job titles contain the word "Agile," and they did not get those jobs to make themselves unnecessary. It is impossible because the CTO has an OKR this quarter about "change management maturity," and he will not be retiring that OKR. It is impossible because a SAFe consultant was hired last month and has already brought a whiteboard, and the whiteboard has already divided into swim lanes, and the swim lanes are already breeding.

And honestly, there are places I don't want it. The plane I fly home next month should be built by software written by someone who deeply understands the context and failure modes and is deeply reviewed by someone with sadism coursing through their veins. The machine that scans my spine next Tuesday should not have been vibed into being by a PM who had an idea in the shower. Any software I have to use, or which affects me, or which touches my money or my health or my ability to get home to my family, should still be written by people who believe in the cathedral. Keep the cathedral. Staff it well. Pay them more.

That's the core. But most code isn't the core. Most code is the edge: the integration that serves 0.2% of your customers, the internal tool that ten people rely on, the consumer feature that'll be replaced in eighteen months. Real work, real users, but the cost of getting it wrong is a bug ticket and an apologetic Slack message, not a hospital visit. On the edge, the speed of iteration matters more than the permanence of the architecture. Those teams could ship the ugly thing by lunch, throw it away, rebuild it by Friday, and ship the real thing by next Tuesday. They will not. The cathedral doesn't know where to stop. It applies the same gates to a payments integration and a settings page, because the process has no concept of "these stakes are different." The cathedral has forty-seven defenders. All of them will be in Thursday's standup, defending the edge with the same ferocity they'd defend the core.

Tuesday Morning

I've drafted the reply to the VP seventeen times. Each version tries to explain what I saw at 3:40 AM. Each version sounds insane in daylight. "Our process is the problem" reads as competent on draft three and as a resignation letter on draft twelve. "The SDLC was designed around expensive code and code isn't expensive anymore" makes perfect sense to a ceiling at 3 AM and no sense at all in a Slack window with a green dot next to your VP's name.

I finally type something diplomatic about workflow maturation and compound gains. I hit what I think is shift-enter to start a new line. I send my half baked incomplete nonsense to my VP and the clock on my edit window starts. Atleast I have spelled Monday right.