ai — jd:/dev/blog

The Human Is the New Bottleneck

Tue, 04 Aug 2026 00:00:00 GMT

The dirty secret of running a company on AI is that the AI stopped being the bottleneck. I am.

On a busy day I have somewhere between five and twenty agents working for me at once, and barely any of it is code. Agents drafting marketing copy, agents prepping sales follow-ups, agents working through an HR policy, agents pulling apart a data export, agents writing the first pass of the thing you're reading. Every function of my job as a CEO now has a swarm behind it. Each one finishes in a couple of minutes and comes back wanting a decision. I'm the slowest part of my own company, and there's no GPU I can buy to fix that.

You might reasonably ask why I run that many. Because the economics leave no choice. An agent costs cents and there are effectively infinite of them. My attention costs a day and there's exactly one of me. When one input is free and unlimited and the other is scarce and fixed, the rational move is to push the free one as hard as the scarce one can absorb. Running a swarm isn't a flex, and it isn't a mistake. It's just what the incentives do to you. Which is the whole problem: the thing you can't get more of is you.

The story everyone tells about AI and productivity is that the machine does the work and you get more done. That's half true. The machine does the work. Whether you get more done rides entirely on the part that didn't get faster: the human deciding what happens next.

Twenty agents, one me

You feel it earlier than you'd think. At three or four agents it's a pleasant buzz. Push past your real limit, wherever yours sits, and it stops failing gracefully. It fails four ways at once.

I lose the thread and forget what the marketing agent was even drafting. I stop reviewing properly, waving through a sales email I haven't really read. My thinking goes shallow, so the calls that need me most, the actual judgment, get the least of me. And underneath it all I'm just fried, wrung out by the switching, not the work.

The word that matters is "once." These aren't four problems to fix one at a time. They're one problem wearing four faces.

It's not a skill issue. It's architecture.

All four break together because they all draw on the same resource: me. And me is not something you can parallelize, however good you get at it.

At the very bottom, the wiring is serial. Harold Pashler spent decades on the central bottleneck: even at the millisecond scale, when your brain selects a response to one task, the selection for a second one waits. Not slows down. Waits. His experiments are about reflexes in a lab, not about juggling agents, and I'm stretching them to make a point. But the direction holds. If the brain won't parallelize decisions at the millisecond floor, it doesn't suddenly learn the trick when the tasks are minutes apart and a hundred times more complex. The cost doesn't disappear at human timescales. It compounds.

And at human timescales it has been measured. Sophie Leroy named what a switch leaves behind: attention residue, the part of your head that stays on the task you just left. The agent you closed is still burning cycles in your skull while you stare at the next one. Gloria Mark's work on interrupted work puts a number on the recovery: north of twenty minutes to fully return to something once you're pulled off it, and you detour through two other tasks on the way. Now trigger that every ninety seconds, twenty times over.

It's a denial-of-service attack on your own attention.

You can't train this away. It isn't discipline. It's wiring.

Not all velocity is the same

Here's the part that sharpens the claim instead of softening it.

Not all agent work costs you the same. Point an agent at a big mechanical grind, set it running for hours, and walk away. It doesn't need you every ninety seconds, so you pay almost nothing. Set a loop and go live your life. For that kind of work I referee my agents more than I babysit them, and it scales beautifully.

The tax lands entirely on design and exploration, the work where every couple of minutes there's a fork only you can take. That's the work that actually matters, whether it's a product decision or a positioning call, and it's exactly the work where you are the ceiling. Which is why throwing more agent-speed at it changes nothing: the constraint was never the agents. Make them twice as fast and they just reach your desk twice as often. Speed on their side becomes pressure on yours.

Somebody already solved this, for drones

The good news is that this has a literature, and an older one than you'd expect. Twenty years ago, researchers working out how one operator could fly several drones hit exactly this wall.

They named it fan-out (Olsen and Goodrich, 2004): the number of autonomous agents a single human can actually run. And they reduced it to a ratio.

Neglect tolerance is how long an agent keeps doing useful work while you ignore it. Interaction time is how long you have to attend to it when it needs you. Your capacity is just the first divided by the second. Yes, a coding agent isn't a drone: it's async, it's resumable, a stalled agent waits politely instead of falling out of the sky. But fan-out is a ratio, not a claim about aircraft. The math doesn't care what the agent is, or whether it's writing code or a press release.

Missy Cummings studied operators supervising multiple UAVs at MIT and found the trap at the end of the road. Push automation so one person can run more vehicles. Past a point, situation awareness collapses and complacency sets in. They stop noticing when something is wrong. If you've ever waved through an agent's output because nine others were waiting, you've lived that result without the grant funding.

We're optimizing the wrong side of the equation

The ratio isn't just a diagnosis. It's a to-do list with two items, and almost nobody is working on either.

Raise neglect tolerance: let agents stay useful longer without you. Real checkpointing, so they don't stall on the first ambiguity. Agents that ask one sharp question before they start instead of five vague ones after. Trust levels, so proven work runs unattended and only the risky calls surface. Every one of those buys back attention.

Or lower interaction time: make each hand-back cheaper. A summary you can judge in ten seconds because the agent tells you what changed and why, not a wall of output to reconstruct. The whole code review bottleneck is an interaction-time problem wearing a different hat, and it isn't only about code: the same tax applies to reviewing a campaign, a contract, or a hiring plan. And some of this isn't tooling at all. Batching buys me more than anything I've installed: stop checking each agent the instant it pings, let a few finish, review them together in one pass instead of paying the switch cost twelve separate times. During real thinking I sometimes do the opposite of this whole post and run a single agent on purpose, because the fan-out that's right for grinding is wrong for judgment.

Now look at where the industry is actually spending. Almost all of it goes into making agents faster and smarter, which raises the number lining up and does nothing for the ratio. Making a bottleneck's suppliers faster doesn't widen the bottleneck. It just deepens the queue.

The interface is the neglected variable. I've called AI a human-interface nightmare before, and this is the same nightmare one level up: HI, human intelligence, is the bottleneck, and you can't optimize it away. We weren't built to be optimized. The only move left is the handoff between the AI and the HI, the mapping from one human to many machines. That's the actual frontier, and it's strangely empty.

You can't parallelize a human

I don't have this solved. On a good day I hold the line around half a dozen agents. On a bad day I've got fifteen going and I'm underwater by noon. But I've stopped waiting for a faster agent to save me, because a faster agent just reaches my desk sooner.

You can't parallelize a human. You can only get better at the handoff. That's the whole game now, and we've barely started playing it.

Merge Queues Were Built for Humans. Agents Don't Wait.

Tue, 30 Jun 2026 00:00:00 GMT

Mitchell Hashimoto thinks merge queues stop working once you point a swarm of AI agents at your repository. I sell merge queues for a living. He's half right, and the dishonest move would be to pretend he isn't.

He said it on the Pragmatic Engineer podcast, in a stretch about Git and monorepos. The setup is a line I've been repeating for years: hitting the merge button is the easiest step. Everything expensive happens around the merge, not at it. Getting the code reviewed, keeping main coherent, maintaining forever what you just shipped. Undergraduates can hit the button, as he puts it. The rest is the job.

Then he gets to the queue:

You constantly rebase. Merge queues solves that to a certain extent. I think merge queues works for humans at a certain scale, but merge queues could get quite deep. But then if you sort of 10x that, conservatively, I think 10x that, and then if you buy into hype cycles and you 100 or 1,000x that, I think it gets completely untenable.

(That's the transcript, grammar and all.)

He's right about the naive version. A merge queue that exists to serialize rebases (take one PR, rebase it on main, run CI, merge, repeat) was built around human throughput. Humans open a few pull requests a day. The queue could be deep and still drain by lunch. Multiply the inflow by ten, then by a hundred, and a queue that only knows how to go one at a time becomes the exact bottleneck it was supposed to remove.

So yes. The human-scale queue strains under agent churn. Grant it and move on, because the interesting part is what you conclude from there.

What actually breaks

Hashimoto lists "a confluence of problems": the merge queue, disk space, and branching/review. I'd pull them apart. Disk space is real (Git clones the world) and it's a separate fight. The one I care about is the queue, and the thing that breaks there isn't the queue. It's the loop the queue sits inside.

He names the failure mode exactly:

Every time you pull, you can't push, because every time you pull there's another chain. Every time you push it's rejected.

The host adds the obvious: there's a lot of parallel work happening at once.

That's not a queue failing. That's contention. Between the moment you decide to integrate a change and the moment main accepts it, the tree moved underneath you. With humans the window was minutes and the traffic was light, so a serial queue could absorb it. With agents the window is unchanged but the traffic isn't, and the one place every change has to pass through, main, is saturated. (The 100x and 1,000x numbers are his hype-cycle hypotheticals, not measurements. The direction is the point.)

People look at that and conclude the chokepoint is the problem, so rip it out. I'd argue the opposite. Serialization is a throughput constraint, not a law of physics, and the chokepoint is the only place left where you still get to decide what "main" means under that load. You don't beat contention by deleting your one point of coordination. You beat it by making that point fast, cheap, and parallel. What actually broke is everything that assumed the loop around it was cheap: one PR, one CI run, one human looking at it, merge, move on. Your CI pipeline was never sized for that.

A queue that goes one at a time is the toy version

Talking about a stealth company he advises, Hashimoto names the real shape:

The amount of churn that these agents is causing is so much greater than humans. And it's not an AI review problem. It's really just like a release problem, like managing the merge queues, humans getting access to the right set of data in the repository.

A release problem. That's exactly it, and release engineering already has answers for "serial doesn't scale." We've just never had to point them at ordinary feature work, because ordinary feature work never moved this fast.

A queue that takes PRs one at a time and rebases each on the last is the toy. The version that survives agent load does what every high-throughput build system already does:

It speculates. Don't wait for #1 to land before testing #2. Build the optimistic chain and test #1+#2+#3 in parallel as if they'll all pass, falling back only when one doesn't. Zuul has done this for OpenStack for over a decade; GitHub's own merge queue and Bors do a version of it.
It batches. Merge a run of green PRs as one unit and run CI once for the batch instead of once per PR.
It bisects on failure. When a batch goes red you don't drop all of it. You find the offender and let the rest through. Uber's SubmitQueue and Google's TAP are built around exactly this.
It treats CI cost and latency as the real constraint. Under agent load the binding limit isn't "can the queue order things." It's whether you can afford to run the suite hundreds of times a day, and how fast each run comes back. Speculation and batching pull against that directly: optimistic chains multiply CI spend, and a failure high in the chain throws away everything below it. Flaky tests, which explode under agent churn, wreck the bisection you were counting on. This is the unglamorous core of it, and it has no clever Git answer.

Here's the honest tension, and the thing Hashimoto's stealth company is really selling against. These techniques are known. Running them without Google's build infrastructure and Google's CI budget is not. That gap is the actual frontier, and it's why the problem lands on tooling rather than on a team of five wiring up speculative pipelines by hand. (Disclosure, if it wasn't obvious: I run Mergify, which builds this kind of thing. Discount me accordingly.)

What the queue does not fix

I'm not going to pretend the queue solves all of it. Green is not coherent. Ten agent PRs can each pass CI alone, pass again as a batch, and still be a mess together: three flavors of the same helper, two designs pulling in opposite directions, a thousand lines no human read. A merge queue keeps main buildable. It does not keep main good. That half of Hashimoto's worry survives untouched, and it isn't a release problem, it's a review problem, and review is exactly the thing agents have made scarcest.

There's also a future where I lose this bet outright. If someone ships an optimistic, eventually-coherent model of main with no single serialization point to defend, the queue as we know it goes with it. I don't think that's where this lands. I think the forge itself bends first.

The most interesting release problem in fifteen years

The line that stuck with me wasn't about queues at all. Asked whether Git survives the agent era, Hashimoto said this is the first time in twelve to fifteen years anyone asks the question without laughing.

That's the signal. The primitives we treated as settled (Git, branches, the pull request, the merge queue) are load-bearing again, and some of them will bend. The merge queue is the one I'd bet on. Not because I sell it, but because the job it does, keeping a shared main coherent while many actors race to change it, gets harder under agents, not easier. You answer more contention by making coordination faster, not by deleting it.

Hitting the merge button is still the easiest step. Agents just turned everything around it into the most interesting problem on the board.

Agents Write My Code. Agents Review It. I Referee.

Fri, 26 Jun 2026 00:00:00 GMT

I haven't read a full pull request diff line by line in weeks. Other agents do that now. I run a deep, multi-agent review on every PR I open, across every repo I touch. By the time I look, the code has already been attacked from a dozen angles by review agents, each better-read than I am in corners I never mastered: frontend, security, databases. My job is no longer to catch bugs. It's to referee.

This sounds a lot like the argument Linear made recently: as agents write more of the code, reviewers stop catching bugs and graduate to product judgment. The engineer gets "elevated." It's a good piece, and they're half right. But the half they skip is the interesting one.

You don't stop catching bugs because the bots got good

You stop catching bugs because you handed bug-catching to a different bot.

A few months ago I wrote that when AI writes the code, correctness is mostly fine if the tests pass. I still believe that. What I underestimated was how much work hides inside if the tests pass. The authoring agent does not get you there. It writes plausible code, which is not the same thing as correct code, and a green check on tests it also wrote is not the floor it looks like. If I trusted that output, I'd be shipping the corruption tax straight into production.

So I don't trust it. I run an adversarial pass: a swarm of review agents, each one prompted to break the change from a different direction, looking for races, missing error handling, the edge case the author never considered.

The obvious objection: if I don't trust the agent that wrote the code, why would I trust the agents that review it? I don't, not individually. They share a base model, so they share blind spots, and they raise false alarms I have to wave off. But writing correct code means getting everything right at once, while a reviewer only has to surface one candidate worth a second look. Run a wide, cheap, diverse sweep and you raise the odds that a real problem gets flagged by at least one angle, even when no single agent is reliable. I'm not building a chain of trust where each agent vouches for the next. The things that actually backstop me don't hallucinate: the deterministic checks I wrote and read myself, and my own final pass.

So bug-catching didn't disappear when the writing got cheap. It forked. It went from "a human reads the diff" to "one agent writes, several agents try to tear it apart, and a human referees the fight." Linear's "reviewers no longer catch bugs" describes the symptom, not the cause. The work didn't stop. You just stopped being the one doing it.

And I'll admit the obvious: a review agent pointed at a database migration surfaces things I would have waved through. Not because it's a better engineer than me, but because it carries breadth I don't. I am not a security specialist. My CSS is competent, not great. I have shipped enough subtle SQL mistakes to respect the category. Delegating the review isn't laziness. It's borrowing breadth I don't have, on demand, on every PR.

Can I prove the swarm catches more than I would alone? Not cleanly, and I'd distrust anyone who handed you a number. Code review was never measurable. A human reviewer misses things, waves others through, and two good reviewers disagree about the same diff every day of the week. That subjectivity didn't arrive with the agents. So I don't hold them to a bar human review never cleared. I hold them to the average of a good reviewer, I make them as sharp as I can, and I accept that their judgment will differ from mine, the way a colleague's would. Sometimes they're wrong. Sometimes I'm the one who would have been.

The thing you can never hand off

So if agents write the code and agents review the code, what is left for the human?

Context. Specifically, the context that was never written down.

You can feed your whole codebase to an LLM. You cannot get 100% of your company's brain into the files an agent can read. Why we picked this ugly abstraction two years ago. The customer who churned because an earlier, cleverer version of this feature burned them. The Slack thread where we agreed not to touch this module before a release. The half sentence in a hallway that quietly became a constraint. None of it is in the repo. None of it is in the prompt. The model isn't wrong about the code. It's blind to the company.

That's why I still do a final pass. Not the line-by-line read I opened by saying I've given up. A context pass: does this change fit the things the agents had no way of knowing? And it's why I only step in as referee where a human left a comment. A human comment is the signal that undocumented context lives there, the kind no agent could have inferred. The final pass survives not because the models are weak, but because documentation is never finished. You can't write down a culture. You can only carry it.

Two things that follow from this

First: stop using staging as your first bug filter. Most teams lean on a staging environment to catch what their checks should have caught, which means they find problems late, by hand, in a place that looks nothing like production. Agents change the economics. Writing tests, fuzzers, property checks, and assertions used to be expensive enough that teams skipped them and shipped to staging to "see what breaks." It's cheap now, though a generated test you don't understand is worse than none, so you still have to read those. Push the verification left. Make your deterministic checks ten times stronger, because the test suite is the first reviewer now and it should act like one. A green build you actually trust is worth more than any amount of manual poking around.

Second: when someone tells you the LLM is bad at their codebase, they're usually describing a context problem, not a model problem. Not always. Models still invent APIs that never existed, no matter how much you feed them. But the systematic gap between the teams getting great results and the teams cursing the model is rarely the model. You can watch it close in real time. Connect the model to where your context actually lives, the ticketing system, the Notion pages, the RFCs, the incident history, and the same "dumb" model starts making calls that look informed, because for the first time it is. The teams winning aren't using secret models. They gave the model the context everyone else keeps in their heads. It was never underperforming. It was working with the fraction of your company you bothered to hand it.

What's actually left

The pull request used to be a place where I read code. Now it's a place where I arbitrate between agents that wrote it and agents that attacked it, and then I add the one thing none of them have: everything my company knows and never bothered to write down.

The model can write all of my code. It can't be in the room. That last part is still the job.

I Shipped a Rust Binary. I Can't Write Rust.

Tue, 09 Jun 2026 00:00:00 GMT

I started shipping a Rust binary last month. I can't write Rust.

I can squint at it and roughly follow what's happening. Past that I'm lost: the borrow checker yells at me and I take its word for it. Sit me in front of an empty main.rs and ask me to build something real, and you'd be waiting a very long time. Yet the Mergify CLI is becoming a single native Rust binary, one command at a time, and the Rust that's already in production was mostly written by a model that knows the language far better than I do.

A year ago that sentence would have been a lie. Today it's just how the work got done.

That's just the tail of the stack: each command ported in its own pull request, right down to the one that deletes the Python tree for good. The port has run to more than forty merged PRs so far, one command at a time. That's the entire trick.

Why we touched it at all

The CLI was Python, shipped the usual way: pip, then uv tool install. Python isn't hard to ship. But "ships" and "ships everywhere, fast, as one file" are different bars. We were fighting interpreter assumptions, a clumsy Windows install story, and a startup cost you feel on every invocation of a tool people run dozens of times a day.

A single native binary fixes most of that. It starts instantly and it runs the same on every machine without a runtime to drag along.

But the binary wasn't the real reason. The real reason is reuse. We want the guts of the CLI, the stack logic, the git plumbing, the GitHub glue, to become a shared native core we can call from other places: a Python library through PyO3, a TypeScript binding later, and whatever else needs it. A CLI today, a library tomorrow, one implementation underneath. Python could never be that common ground (not easily): you'd be shipping an interpreter into every consumer. A native language can.

Why Rust and not, say, Go? Partly the reuse story is cleaner from Python (PyO3 beats wrangling cgo). Partly the team wanted Rust, and a team that's excited about the language writes better code in it. I won't pretend it was a pure spreadsheet decision.

"But you should never rewrite"

The instinct, the moment you say "rewrite," is to quote Joel Spolsky. In 2000 he wrote Things You Should Never Do, and the never is rewriting your software from scratch. He's right. He's still right.

But read what he actually warned against. Throwing away working code is throwing away every bug someone hit in production, every weird edge case a customer found, every fix that looks pointless until you remember why it's there. Knowledge accumulates in code as scar tissue, and a from-scratch rewrite cuts it all out and dares you to grow it back.

We didn't do that. We didn't start from scratch. We ported.

A port is a translation, not a reinvention. Same behavior, same edge cases, same tests, different language. You don't move it line by line, the two languages disagree about almost everything, but you're re-expressing decisions that were already made instead of making them fresh. The scar tissue lives in the behavior and the tests, and that comes along for the ride. That distinction is the whole game. A from-scratch rewrite is still an excellent way to kill your project. A port has quietly become cheap to write.

"Don't rewrite" and "don't port" were never the same rule. We just couldn't tell them apart when both cost a year.

How we did it without blowing a leg off

The tempting version is obvious: hand the whole tree to an LLM, say "make this Rust," and merge the enormous green PR. When Bun did exactly that, the result was a single pull request north of a million lines, and it's easy to dunk on. I won't. At that code size, porting command by command the way we did would have taken them the better part of a year, and nobody signs up to run a migration that long. They jumped and crossed their fingers because the careful path wasn't really a path, it was a sentence.

But the gamble is real, and worth naming. A million lines in one PR is not something a human reviews, green checks or not. The tests can pass and you still have no idea what you merged. That's not merging code, it's merging hope. A one-shot port stops being a port and turns back into a rewrite, with all of Joel's problems plus a model's confident mistakes. I dug into why on the Mergify blog.

We never had to make that bet. Our surface was small enough that the careful path cost weeks, not years, so we took it. It looks slow. It's actually fast.

Command by command. mergify stack push first, then fixup, then note, then drop, each one its own change. Never more than one command in flight.

A shim between Python and Rust, so the tool was always shippable. Mid-migration, half the commands ran on Rust and half still ran on Python, and the user couldn't tell. No big-bang cutover, no branch that lives for three months and rots. The whole architecture is one decision. Route to the native implementation if it exists, fall back to the Python one if it doesn't, same behavior either way:

Tests as guardrails. Every command the model ported got unit, functional, and smoke tests around it. The model wrote those too, and yes, that's a loop worth worrying about: a model grading its own homework. What breaks the loop is that we weren't inventing correct behavior, we were copying it. The Python CLI was right there, in production, defining exactly what each command should do, and because the shim kept both alive we could run the two side by side and compare. The model gets to write the Rust and the tests. It doesn't get to decide what correct means. The old code already did, and that's why I can trust code written in a language I can't.

Small, reviewable steps. We split the whole thing into stacked pull requests so each port was a few hundred lines, reviewable in one sitting, merged on its own. The stack is what kept a month-long migration from ever feeling like a month-long migration.

The bottleneck moved

Here's the number that surprised me. The actual code generation? You could do this in a few days. Maybe one, if you did nothing else and didn't stop to review.

It took us three weeks to a month. Not because the writing was slow, but because reviewing is the bottleneck now. Reading every diff, in a language I'm still learning, while also running a company. The model produced faster than we could absorb.

That's the real shape of AI-assisted engineering right now, and it's the same lesson I keep landing on: writing got cheap, reviewing didn't. The cost of software moved from your fingers to your eyes. I've written before about the corruption tax you pay when you delegate to a model and don't read the result, and this is the same coin, flipped to the happy side. The guardrails and the reading are not overhead. They are the work now.

What I gave up

I don't fully know the code we're shipping. Some of it is probably not idiomatic Rust. There are likely allocations a real Rust programmer would avoid and patterns they'd wince at. The model is a better Rust programmer than I am, and for a CLI where correctness matters more than elegance and the tests cover the behavior, I'm at peace with that.

I'm also clear about why this worked, because it tells you when it won't. It's a CLI. The behavior is well defined. The test coverage was good before we started. I would not do this blind on a system I couldn't test thoroughly, or one where "probably correct" isn't good enough. The method isn't magic. It leans entirely on the fact that we could prove the new code behaved like the old code.

The lesson isn't "rewrite everything in Rust." It's that the calculus changed. The reason you never rewrote was that rewriting cost more than it returned. Porting, with a model that writes the language and tests pinned to behavior you already trust, slipped under that line while everyone was still quoting an essay from 2000. The news isn't that an AI wrote Rust. It's that porting, always the safer half of Spolsky's rule, finally got cheap enough to just do.

I still can't write Rust. Turns out I didn't need to.

How Much Of A Library Do You Actually Use?

Tue, 19 May 2026 00:00:00 GMT

Armin Ronacher's Build It Yourself got reposted again after the latest wave of npm supply-chain attacks, and it landed again. The two-line version: most of the small libraries in your dependency graph aren't pulling their weight, and the maintenance treadmill they put you on costs more than writing the function yourself. Especially now that an LLM can write that function while you're reading this sentence. Go read his post first. Mine is the part I keep thinking about after closing his tab.

I've been importing-and-shipping for twenty years. I've maintained libraries on the other side of the dependency arrow too. Armin's instinct is one I've ignored for years, because the alternative used to look harder than the maintenance. Two things changed in the last eighteen months that made the advice un-ignorable.

The supply chain stopped being theoretical. TanStack last week. The fsnotify maintainer drama. The 170-package npm wave that hit Mistral and friends. Upstream attacks used to be a tail risk you could ignore. Now they show up monthly. Every transitive dep in your Cargo.toml or package.json comes with a side bet: am I going to read a postmortem about this one?

And AI changed the math on the other side. Libraries used to earn their keep by absorbing maintenance you didn't want to do. Now an LLM absorbs that maintenance: bug fixes, edge cases, the boring 60% of any small utility. The per-line cost of "build it yourself" collapsed. The breakeven shifted quietly while nobody was looking. The caveat is that the LLM brings its own corruption tax, so the trade only works when the linter, type checker, and tests are pointed at the new code too. Assume they will be. For anything small enough to fit on one screen, the math still tips toward the local version.

OK. So build it yourself. The next question is the one Armin's post doesn't quite reach: build which?

The first answer is a linter

When I say this out loud to other engineers, the first tool they reach for is some flavor of unused-dependency check. deptry or vulture in Python. depcheck and knip in the JS ecosystem. cargo-udeps in Rust. All useful, all roughly the same shape: scan your imports, scan your declared dependencies, flag the ones that don't line up. They catch the obvious wins. The imports that died with a refactor. The declared deps nobody actually pulls in. The package you added once to try something out and then forgot. (I've written about the day-to-day version of this for Python.)

But they tell you exactly one thing: did I import this package or not? That's not measurement. That's a binary check at the package boundary. It can't see what's inside.

I imported requests and called .get(). The linter sees import requests and goes home happy. It can't tell you that I shipped the entire requests package, including streaming, sessions, adapters, connection pools, and retry logic, to call a single function. Most of that ships with my service. All of it counts when someone compromises the maintainer.

The deeper answer is coverage into the dependency

If you actually want to know how much of a library you're using, you have to run coverage through the dependency, not around it. coverage.py will happily measure */site-packages/requests/* if you tell it to. cargo-llvm-cov has flags for including specific external crates in the report. nyc can be pointed at node_modules. The defaults exclude all of this on purpose, because most of the time you don't care. The point of this exercise is to care once.

The output is uncomfortable. Run it against a real workload and most dependencies come back well under twenty percent exercised. You imported a fifty-function library and your hot path touches three of them. The other forty-seven were maintained, security-scanned, pulled in transitively, and shipped to production, all to give you the comfortable feeling that someone else owned the problem.

A few will surprise you the other way. The library you suspected was bloated turns out to be eighty percent used because edge cases you forgot about are quietly hitting it. Those stay. The discovery is genuine in both directions.

And here I get stuck

Because even the deep number is a metric, not a verdict.

The library I use one percent of might be exactly the one I should keep. That one percent is JWT verification, or X.509 parsing, or the part of dateutil that handles timezone transitions on the days the IANA database changes. If I roll that myself I'm guaranteeing a future incident.

The library I use eighty percent of might be the one I should rip out today. The maintainer stopped responding eight months ago. The fork I'd need is twelve commits behind. The version I'm pinned to has an open CVE nobody is going to patch.

The metric tells me where to look. It does not tell me what to do.

What we'd actually need (and don't have)

The tool I keep wanting doesn't exist. The pieces of it do. OSSF Scorecard scores maintainer health. Socket.dev and Snyk score security surface. coverage.py and cargo-llvm-cov give the usage number. Each piece lives in its own silo, owned by a different vendor, behind a different login. Nobody composes them next to the coverage number in your editor, sorted by "most worth rethinking."

What I want is the composite. Maintainer health: last release date, bus factor, weekly download trend. Security surface: does this library parse untrusted input, touch crypto, talk to the network. Replaceability cost: a rough estimate of how many lines I'd write to reproduce the slice I actually use, ideally generated by an LLM that already read both sides.

Glue those four numbers together and a senior engineer could spend an afternoon making real decisions instead of wandering through their lockfile. The numbers wouldn't decide anything. They would just put the judgment on the right scale.

I haven't built this. I haven't found anyone who has, at least not in a way I'd put on my screen every morning. Maybe that's because it would commercialize a judgment call that doesn't want to be commercialized: the moment you put a score on "should I keep this dependency," half the value is gone, because the score is the new thing people optimize. The act of looking at three numbers in your editor and feeling something is the senior judgment that resists automation. Removing the friction might be removing the practice.

The receipt

I've been writing this against the Mergify CLI, a Rust codebase that's been accumulating crates the way Rust codebases do. The cargo-only update sweep last week made me look at the lockfile longer than usual. Some entries are obviously gone next week. Others are obviously staying.

The long tail in the middle is the work I haven't done yet, because the deep coverage run is a half-day's setup and I keep postponing it. That postponement is what most engineers actually do. We run the linter, we feel responsible, we move on. The whole point of writing this down is to admit that the next step is the one nobody schedules.

The tools will keep getting better. The judgment will not get cheaper.

"Build it yourself" is good advice. The unglamorous truth is that most of us can't act on it until we know which it the sentence is talking about, and the tools that answer that question with anything more than "did you import the package" are still mostly homemade. The next decade of platform engineering is probably right there, sitting in the gap between cargo-udeps and what you'd actually want to know. Someone is going to build the thing. I hope they leave room for the call.

The Hidden Corruption Tax of AI Delegation

Tue, 12 May 2026 00:00:00 GMT

Frontier LLMs corrupt 25% of what you delegate to them in long workflows. The new genre of "I went back to writing code by hand" essays says the answer is to fire the LLM. They have the diagnosis wrong. We solved this exact problem for humans twenty years ago, with linters and CI. We just forgot to apply any of it to the new worker.

A new paper from Microsoft Research, LLMs Corrupt Your Documents When You Delegate by Laban, Schnabel and Neville, put a number on something most of us had been seeing for months. Across 52 professional domains, in long delegated workflows, even the frontier (Gemini 3.1 Pro, Claude 4.6 Opus, GPT 5.4) corrupted an average of 25% of document content by the end of a 20-interaction relay. The average across all 19 models tested was 50%. Errors were sparse but severe. They compounded with document size, turn count, and distractor files in context. Agentic tool use made it worse, not better.

The 25% comes from a backtranslation simulation (forward edit, reverse edit, compare to original), so it's a proxy for cumulative drift, not a literal claim about your next delegated diff. The point isn't the exact number. The point is the proxy holds across 19 models, 52 domains, document sizes and turn counts, in the same direction. The shape of the failure is real even when the headline number is conservative.

The honest reaction to that shape isn't "see, AI is useless." It's: of course it drifts, what did you build to catch the wrong slice?

Sparse but severe is the worst kind of bug

If LLM errors were dense and obvious, we would catch them. The whole industry would have rejected vibe coding by now. The paper's finding is more uncomfortable: the model is right most of the time, then quietly wrong about one critical thing, then right again. The result reads correctly. It compiles. It even ships.

This is the worst possible error profile for human reviewers. Rare anomalies in a sea of normal-looking output are exactly what humans miss, every time, in every field that has bothered to study it. The LLM accidentally built an attention trap.

It also gets worse with size. Bigger document, longer interaction, more distractor files in the context: degradation compounds. So the more useful you try to make delegation ("rewrite the whole spec" instead of "fix this one line"), the worse the corruption gets. The delegation interface rewards exactly the workflow that fails hardest.

Going back to writing by hand is firing the junior

Every few weeks now, a senior engineer publishes the same essay. I quit the AI assistants. I am writing code by hand again. I am faster, the bugs are gone, my brain is back. Each one gets three hundred HN comments saying "finally, someone said it."

I read those posts and I see the same mistake a stretched manager makes about a struggling junior: I should just write the code myself, they suck. No. They don't suck. You skipped onboarding. You didn't give them a feedback loop. You didn't pair-review their first ten PRs. You set them up to fail, then concluded that hiring juniors is broken.

LLMs are the same shape of problem. We have been onboarding humans into software projects for decades, and we long ago stopped trusting them blindly. We require their code to compile. We require it to pass a linter. We make them write tests. We force it through type checkers, static analysis, security scanners, dependency auditors. We don't do this because junior engineers are bad people. We do this because anyone producing code at speed quietly breaks things, and the deterministic harness catches it before production does. (As I wrote a while back, AI won't kill juniors, it'll expose stagnant seniors: same problem, same diagnostic mistake.)

Now the industry has hired the most prolific junior in history, and most teams forgot to point any of that harness at its output.

We already built the fix. It's called a linter.

The first thing you do when you start a new repository is not turn on Ruff, ESLint, Biome, cargo clippy, mypy, gosec, semgrep. It should be. It almost never is. Most new repos start out with a default GitHub Action template at best. Rarely a security linter. Almost never a custom rule for the smells that actually bite this codebase. And those are the projects humans are writing.

Then we plug an LLM into the same unguarded repo and act surprised when the same failure mode shows up in the diff.

Linters are the cheapest deterministic check we have. They exist precisely because we already learned the lesson the DELEGATE-52 paper had to re-prove with a small mountain of inference: confident producers of code make sparse but severe errors at scale. That's the entire reason the toolchain exists. Pointing it at an LLM doesn't require a research breakthrough. It requires turning on the thing we built for humans and forgot to wire up.

The corruption tax compounds because we removed the harness when we changed the worker. Same mistake we make when we send a junior into a repo with no CI and then blame the junior.

The obvious objection: linters catch syntactic bugs, not semantic ones. A regex flipped from ^foo$ to ^foo passes every static check. So does a dosage that went from 5mg to 50mg, an off-by-one in a business rule, a swapped argument when both types match. That is correct. It's also exactly why the current agentic coding tools (Cursor, Claude Code, Aider) run linters and unit tests inside their loop, and the paper's degradation numbers are still collected on top of harnesses like that. A single linter pass isn't the harness. That's the whole point. We also built property-based testing, fuzzing, golden-file diffs, contract tests, snapshot review, and the boring discipline of two humans signing off on a change. The harness is layered. The frontier LLMs are sparse-but-severe at every layer of it, which is what the paper actually shows. You don't pick one tool; you stack them, because every layer catches a different class of wrong.

The paper itself makes this point in passing: out of 52 domains tested, Python was the only one where most LLMs reached "ready" status. The paper credits "verifiable rewards", the fact that code can be checked deterministically. That is just another way of saying Python comes with a harness, the one programmers built precisely because any writer, junior or LLM, will quietly drift unless something deterministic catches them. Crystallography, music notation and accounting ledgers have spell-check at best. The domain with the densest harness is the domain where delegation actually works. That is not a coincidence.

In every other domain, DELEGATE-52's 25% becomes a corrupted file you ship and nobody catches, because there's no automated reader behind the human one. If you delegate to an LLM in a domain without deterministic checks, you are the harness. Act like it.

The interface helps too, but it's not the whole game

There's still a real interface problem on top of this. The dominant UX for delegated work is "here is the doc, do your thing": the model returns a new version, you skim it, you ship it. Implicit acceptance, hidden diff. That is the worst possible UI for a tool whose failure mode is silent corruption.

Cursor, Claude Code and Aider all show diffs. Real ones. But "show a diff" is not "force a diff". You can still click accept-all on a thousand-line refactor at three in the morning. The fix is making review the default path, not an option: forced span-level acceptance, drift indicators across long sessions, distractor-file warnings, visible quality-loss curves as the doc grows. As I argued in AI is a human interface nightmare, the pattern is depressingly consistent. Decent models surrounded by terrible UI for catching when they're wrong.

These are product problems, not research problems. They are exactly the same guardrail work we did for code review tooling over the last fifteen years. Same job, new worker.

You have to read what you delegate. You also have to lint it.

Until both the interface and the harness catch up, the defenses are boring. Diff what you delegated. Re-read every line the model touched. Run the linter. Run the tests. Run the security scanner. If you don't have time to do that, you didn't have time to delegate the task in the first place. You were borrowing against your future self, and a slice of the document is already gone.

I have shipped features at Mergify where I wrote maybe five percent of the lines myself and Claude wrote the other ninety-five. It worked. The reason it worked is not that I read every line with a microscope. It's that Biome, mypy, our test suite, and a Copilot review pass read the diff before I did. The harness was the reviewer I didn't run. The corruption tax was paid quietly in the background, and the linters caught what mattered. Take the harness away, and that same PR is a future incident.

The AI free lunch was about who pays for the compute. The corruption tax is about who pays for the silence. Both bills come due. Both are starting to.

The answer to both, weirdly, is the same boring thing: build the safety net you always should have had. The LLM didn't change that. It just punished the teams that never bothered.

The AI Free Lunch Is (Almost) Over

Tue, 05 May 2026 00:00:00 GMT

Around 2014, I lived near the Belleville métro in Paris. Every evening on my way home, someone would press a flyer into my hand. Foodora, TakeEatEasy, Deliveroo, Uber Eats, all rotating in front of the exit. Each flyer came with a code: free delivery, ten euros off, fifteen euros off, your first three meals on us.

For a few months, dinner was almost free.

Then Foodora left France. TakeEatEasy went bankrupt. The flyers disappeared. The codes stopped working. The free dinners ended.

I'm burning $200 to $400 of Claude tokens a day on a $200 a month plan. Last month, the API-equivalent ran past $8,000.

The pattern is older than the technology

Pick a category where the underlying unit cost is opaque to the consumer. Subsidize it heavily. Get everyone hooked on the low price. Wait for competitors to die or raise prices. Then collect.

Uber did it to taxis. Foodora did it to me and most of Paris. Anthropic, OpenAI, and GitHub are doing it now to anyone who codes.

Anthropic launched Claude Code, then Claude Pro at $20, then Max at $100, then Max 20x at $200 for the heaviest users. Then it tightened weekly rate limits when Claude Code burned through them faster than expected. OpenAI matched with a new $100 ChatGPT Pro tier, giving 5x more Codex capacity than the $20 Plus plan, framed as what "power users have been asking for forever." GitHub Copilot, which started flat-rate, moved to usage-based billing. Each step is the same step the food delivery apps took, just compressed into months instead of years.

OpenAI's new $100 tier explicitly targets Anthropic's existing $100 Claude offering. The price points are converging.

The flyers haven't disappeared yet. The codes still work. But anyone watching the ratio between what they pay and what they consume can see what's coming.

Where the analogy breaks

Foodora lost money on every order. The unit economics were broken from day one and only VC subsidy hid it. The category was structurally unprofitable until prices doubled.

AI inference is not that bad. At API prices, the margin is real. So this isn't bankruptcy talking, it's monetization. The free lunch ends not because providers lose money on every token, but because they choose to stop subsidizing the heavy users once the market is captured.

A flat-rate consumer plan only works if usage follows a power-law distribution where light users subsidize heavy users. That's how all-you-can-eat plans work, from gym memberships to mobile data. Anthropic priced Max against an assumed distribution where a few power users would burn the cap and most subscribers would barely touch it.

The shape Anthropic priced against, and the shape Claude Code actually produces.

Claude Code broke that distribution. Agentic coding tools run in loops. They consume tokens whether you're watching or not. Most developers who install one become heavy users by accident. The light-user subsidy pool the $200 plan was priced against doesn't exist anymore.

That's why rate limits keep tightening. Each tightening is the pricing trying to rebalance against actual usage. There is a floor below which it can't go without making the plan useless to the developers it was designed for. We're approaching that floor.

The 40x that isn't going to happen

April was my heaviest month so far: 11.6 billion tokens through Claude Code, mostly cached reads with a sonnet/opus mix on the uncached side. Priced against the public API rate card, that's roughly $8,000 of equivalent consumption against a $200 flat-rate plan. A 40x gap. Earlier months ran lighter ($250 to $850 in token value), not because each session was cheaper but because I ran agents less. The trend is up and to the right because Claude Code is up and to the right. For Max to cover its real power users at API margins, the price would need to land somewhere close to that $8,000.

The market for $200 Max isn't casual users, it's professionals. Developers, freelancers, founders, indie shops. Even they won't pay $8,000 a month for a coding assistant. They'd cancel. Pros will pay $1,000 for a tool that pays for itself in a week. Not $8,000.

The realized increase for someone like me won't be 40x. It'll be 3 to 5x, in line with what every other tiered tech market has done: AWS On-Demand priced at roughly 3x Reserved, mobile data overage charges typically 3-5x the in-plan rate, broadband "fair-use" caps that throttle to a quarter of the headline speed. Anthropic doesn't have to invent a new economic mechanism. They just have to copy the one cloud and telecom landed on a decade ago: harder caps, a new mid-tier between flat-rate and metered, and the actual heavy users pushed to the meter. The flat-rate plan doesn't disappear. It becomes vestigial for serious work, the same way "unlimited" cell data plans still exist but throttle you past a cap buried in the terms.

The one thing that could blunt this: a competitor that holds the line at $200 to steal Anthropic's heavy users. Google has the cash and a real product (Gemini in Cursor and IDEs is genuinely close on coding), and Google has the strongest history of subsidizing for share. DeepSeek V4-Pro at 80.6% on SWE-bench is essentially free open competition that nobody owns and nobody pays for. Meta has the weights, the GPUs, and a reason to commoditize the layer below their assistants. If any of those refuses to follow the tier-shuffle, the squeeze on Anthropic stalls. It's the live counterargument and it isn't weak. I still expect Anthropic to move first because they have the most to lose, and the others to follow within a year because they always do. But this is the question that decides how steep the next twelve months get.

If you run a few prompts a day, you'll keep your great deal. If you use AI as a daily tool for paid work, you're moving to a meter.

The escape hatch

The food delivery analogy doesn't have a third path. You couldn't self-deliver a Deliveroo. But you can run Llama, DeepSeek, Qwen, or whatever open weights are worth running by then.

On SWE-bench Verified, DeepSeek V4-Pro hit 80.6% earlier this year, two points behind GPT 5.5 (82.6%) and within rounding of Claude Opus 4.6 (80.8%) and Gemini 3.1 Pro (80.6%). A year ago the open-weights frontier was around 55% on the same benchmark while the closed frontier was already past 70%. The gap closed from roughly 18 points to 2 in twelve months.

Top SWE-bench Verified scores, May 2026. DeepSeek V4-Pro is within two points of the closed frontier. Source: SWE-bench Verified leaderboard.

The hardware story is the part that's still moving and the part the optimists handwave. Running a serious open model at the latency and quality you want today requires a Mac with 96 GB or more of unified memory ($3-$4k+ upfront), a small GPU rig, or an H100-class cloud GPU rented by the hour (around $2-$3/hour, which is $500-$700 a month at eight hours a day). None of that is cheaper than $200 a month right now. The math closes when open weights reach parity on agent loops and Apple's unified memory hits a generation that lets a serious model run cool on a desktop.

I haven't switched yet. I'm watching DeepSeek V4 and Qwen on the side, and the day my daily workflow fits on a Mac under my desk is the day I migrate. The migration is its own work, though. Context, prompts, custom commands, agent recipes, muscle memory, all of it transfers slowly. Start before you need to. The escape hatch is being built right now, even if it isn't a door you can walk through this quarter.

What to do this year

Three things.

Use the subsidy aggressively while it's there. Code like crazy on Max. Build agents. Ship things. Don't ration yourself to fit inside an imagined fair-use ceiling. The point of being inside the market-capture window is to extract maximum value from the misprice. The agents shipping code into your repo today are cheaper than they will ever be again. I've been stacking commits faster than I can read them back for the last few months, and the math behind that is going to look very different in twelve months.

Budget for the meter. Whatever your team's AI line item is today, model what it looks like at 5x in a year. If that number doesn't fit your gross margin, start changing the workflow now. Cache. Use smaller models for the easier turns. Restructure prompts. Batch where you can. The teams that wait for the bill before changing the workflow are going to have a bad quarter.

Watch the open models. Not because they are ready today (close, but not for everything). Because the day Anthropic announces the new $500 tier, you want to already know whether your daily workflow can run on a Mac sitting under your desk. Like ARM versus x86, the open option will look obviously inferior right up until it suddenly doesn't.

The free meal at my desk is ending in 2026. The next twelve months are the last cheap ones. Code fast.

Twenty Years of Stacking Commits

Tue, 28 Apr 2026 00:00:00 GMT

In twenty years, I've used four different code review tools. Each was supposed to fix the previous one. None of them changed the fundamental question they were trying to answer: what is the right unit to review?

The answer hasn't moved. The world around it has.

I started on git format-patch and git send-email in 2006, threading patches into mailing lists the way the Linux kernel did. I moved to Gerrit at OpenStack when it arrived. I tried to bring its workflow to GitHub myself, and failed. I watched GitHub turn every branch into a wall. And now I'm watching agents push code faster than humans can read it. Each era taught me the same thing: the unit of review is the commit. We just spent a decade pretending otherwise.

[PATCH 2/5] from a patch series I sent to the XCB mailing list in 2010. Each patch was its own review unit. Stacking has been here the whole time.

Gerrit got it right

OpenStack ran on Gerrit. Google had built it in 2008 for Android, the brainchild of Shawn Pearce as a fork of Guido van Rossum's Rietveld. Projects looking for serious code review followed.

Every commit you pushed got a Change-Id, a SHA-like footer Gerrit used to track that commit across rebases. One Change-Id was one review. Push six commits, get six review threads. Amend one and the others stayed untouched. Reviewers commented on the commit they cared about and ignored the rest.

The UX was hostile. You pushed code with git push HEAD:refs/for/master, a syntax that felt designed to keep newcomers out. Discussions happened in a web UI that loaded slowly even on fiber, or over a JSON-over-SSH API for the brave. You clicked through three screens to leave a comment. Senior contributors had Vim macros to make it bearable. Newcomers gave up.

But the model underneath was right. Each commit was a thought, and each thought got reviewed on its own terms. When you submitted a five-commit feature, reviewers could approve the refactoring commits while still arguing about the new abstraction in the last one. The work moved forward in pieces. Nobody waited for everything to be perfect before anything could land.

Compare this to what most teams do now. A reviewer opens a 1,500-line PR, scrolls for a while, picks a few things to comment on, and either approves or sends it back as a single block. There's no granularity because the unit doesn't allow it.

Gerrit knew this in 2008. It just didn't know how to make people enjoy it.

git-review proved the UX was the wall

OpenStack built git-review to wrap Gerrit's six-step push ritual in one command. git review did the right things in the right order. Fetch the latest target branch, rebase your commits on top, validate Change-Ids were present, push to the magic ref, print the URLs of the resulting reviews. That was it.

It got adopted across OpenStack within months. Within a year it was the default step in every contributor tutorial. Not because the tool was clever (it wasn't), but because the friction it removed was the difference between people contributing and people giving up after their first push.

That was the lesson I carried out of OpenStack. A tool can have the right semantics and still lose if the UX is hostile. UX isn't decoration. It's part of correctness. The model that wins is the one a tired developer at 6pm can use without thinking. Gerrit's model was right, but its surface area pushed everyone toward GitHub the moment GitHub got good enough.

GitHub turned every branch into a wall

GitHub got good enough around 2014. Faster UI, easier setup, and a model anyone could understand: one branch, one pull request. That model worked for solo contributions and small features. It collapsed the moment you tried to ship anything in pieces.

The problem is structural. GitHub's PR is anchored to a branch. If you want five reviewable units, you need five branches. Each one rebased on the previous. Each one's PR retargeted when the one below it lands. If the bottom of the stack changes, you rebase the world. Nobody does this. People give up and ship one giant PR instead, or they ship one PR per day for a week and pretend it's fine.

I ranted about exactly this in 2013, back when most of the industry was busy convincing itself GitHub had solved code review. The argument hasn't aged. GitHub's PR model fights you the moment you try to ship more than one thought at a time.

I tried to fix it myself in 2016 with git-pull-request, a small Python CLI that turned commits on a single branch into chained GitHub PRs. It worked for me. It didn't go anywhere. A one-person CLI can't paper over a structural mismatch. The branching, the chaining, the dependency tracking, the smart updates when you amend a commit mid-stack, all of that has to live somewhere both halves of the workflow agree on. Client-side scripts work on your machine and break on someone else's.

Years later we built Mergify Stack because the problem hadn't gone away and the team was bigger than just me. One local branch, every commit becomes its own PR, the tool handles the chaining so amending mid-stack only updates the affected reviews.

A nine-PR stack from our ongoing Rust port, posted as a comment on every PR in the chain. Each row is one commit, one PR, one review unit. The arrow points at the PR you're currently looking at.

We weren't the only ones who noticed the gap. Graphite bet a whole company on it, building an IDE around stacked diffs that effectively replaces GitHub's review surface. Meta open-sourced Sapling's ghstack. Google open-sourced jj, a Git-compatible VCS where stacks are first-class. There's spr, stack-pr, half a dozen others. Different shapes, same admission: GitHub's PR model doesn't fit how serious teams ship.

My day-to-day hasn't really changed since I was patching Xorg, or awesome, or filing bugs against Debian packages I maintained. One branch. Commit small. Interactive rebase to fix something three commits down. mergify stack push to send the whole stack up. The only difference is GitHub showing seven separate review threads instead of a mailing list showing six.

This was the missing layer. Stack semantics, GitHub surface. For a while, that was enough.

And then the agents arrived

Until last year, the bottleneck on a software team was the human writing the code. A senior engineer could ship maybe two or three thoughtful PRs in a day. Junior engineers shipped less. Reviewers mostly kept up. The whole pipeline was sized for human output.

That bottleneck is gone. With Claude Code in front of me, I can produce in an afternoon what used to take a week. Not because I'm typing faster. Because I'm not typing at all. I'm planning, briefing, reviewing, redirecting. The agents do the typing. They don't get tired.

I've written about how this shifts the bottleneck downstream. The reviewer is now the choke point, and the reviewer's tools haven't kept up. They're still being asked to read 1,500-line PRs the way they did when those PRs took someone a week to write. They skim. They miss things. They approve and hope.

Stacks don't shrink the work. They make partial progress possible. A reviewer who can't approve all of it can still approve half of it. Two reviewers can split the stack and work in parallel. A bug found in PR five doesn't roll back PR one. The total volume is unchanged. The blast radius and the cognitive load per review are not.

A couple of weeks ago I shipped an API surface refactor across our backend and frontend. I had a plan with seven steps: add a new /merge-queue/branches endpoint, remove a deprecated old one, migrate the web app's branch selector, drop a dead related surface, add a sister /stats/branches endpoint, migrate the stats filter, deprecate the old union endpoint. I briefed the agents. I reviewed the work. Six seconds after I ran mergify stack push, GitHub had seven open pull requests linked in dependency order.

Combined, those PRs touched roughly seven thousand lines across seventy-five file changes. As a single PR, no human would have read it carefully. As a stack, each one was a single logical move. The first landed two days later, when the lowest-risk piece (deleting the deprecated endpoint) was approved. One contested API addition cycled through a couple of rounds of dismissed reviews before landing. The last merged nine days after the push. Five different reviewers touched the stack across that window, picking up whichever links they had context for. Nobody had to load the whole refactor into their head.

Try that as one PR and tell me what happens. Seven thousand lines mixing four backend moves with two frontend migrations. A reviewer who needs to understand all of it before approving any of it. Anything wrong anywhere triggers a full revert. The work either ships as a brick or it doesn't ship at all.

Stacks aren't free and they aren't universal. Exploratory work that changes shape mid-stream wants a single branch, not seven. Tightly coupled changes where commit five only makes sense once you've read commit four don't decompose neatly. Bug fixes are usually one PR. The skill is knowing which kind of work you're doing before you start. If your team can't write atomic commits or doesn't trust interactive rebase, stacks make things worse, not better. The model demands discipline. The bet is that AI removes enough of the writing tax that the discipline becomes affordable.

Gerrit knew this in 2008. The unit of review is the commit. The PR was always a workaround for tooling that couldn't track commits properly. It took agents writing code faster than humans can read it for the rest of the industry to admit it.

In January, GitHub stopped denying it. They announced native Stacked PRs in private preview, with the gh stack CLI and an AI agent integration shipped as a skill.

GitHub's own stack-navigator preview from the gh-stack landing page. The PR map on the right is what reviewers have been asking for since 2014.

The PR model GitHub spent a decade enforcing as the right unit of review is being quietly retrofitted to admit it wasn't. They couldn't say so until everyone else had already built the layer they should have shipped in 2014.

The tools change every five years. Gerrit. git-review. Mergify Stack. Graphite. GitHub Stacked PRs. Whatever ships next. Each generation looks like a step forward and most of them are.

The unit of review hasn't moved in twenty years. It's the commit. It always was. We just had to wait for the rest of the pipeline to break before we noticed.

The Code Review Bottleneck Is You

Tue, 21 Apr 2026 00:00:00 GMT

Every software team runs the same pipeline: write code, test it, review it, merge it. For decades, the bottleneck was the first step. A developer could write maybe two PRs a day. Review kept up easily because there wasn't much to review. Testing and merging were automated. The pipeline was balanced.

AI blew up the first step. A developer with AI can produce five or six PRs a day. But a reviewer can still only handle the same number they always could. The pipeline is no longer balanced.

Before AI — writing was the limiting factor, review kept up:

After AI — writing produces far more than review can absorb:

What our merge queue shows

At Mergify, we build merge automation. Our core product repo is our canary. Here's what the writing step looks like, measured in human-authored PRs per engineer per working day (excluding bots):

2023: 1.3 PRs/engineer/day
2024: 1.5 (+15%)
2025: 1.7 (+13%)
2026: 2.7 (+59%, on pace)

Output per engineer more than doubled in three years. The jump from 2025 to 2026 alone is almost 60%, which correlates with the leap in model capabilities over the same period. The team didn't get twice as good at coding. They got 2026-era AI models.

My own numbers make it even clearer. In 2023, I merged 120 PRs. In 2024 and 2025, around 330 each. In 2026, I'm on pace for ~650: double my previous rate, almost entirely AI-assisted. The writing step got cheap. But every one of those PRs still needs a human review, and that's where the math breaks down.

The pipeline needs rebalancing

The instinct when the review queue grows is to review faster. Skim more, approve more, trust the green CI badge. That's how you ship bugs.

The real answer is to rebalance the pipeline. When the writing step was slow, it made sense for every PR to get the same level of review. There wasn't that much volume. Now that the writing step produces 2x the output, you need a review process that can triage.

Not every PR deserves the same scrutiny. A dependency bump that passes CI, dependency scanning, and has a clean changelog? Auto-merge it. A pure refactor where the tests are green? Spot-check and ship. Save your deep review cycles for the PRs that change behavior, touch shared interfaces, or modify things that are hard to roll back.

The nature of review changes too. When AI writes the code, correctness (at least for syntax and basic logic) tends to be fine if the tests pass. The real question shifts to "is this the right approach?" You're reviewing architecture decisions, not indentation. Reading less line-by-line, asking more questions about why.

There's a deeper principle here. As apenwarr wrote, the job of a code reviewer isn't to review code. It's to figure out how to make their review comment obsolete. Think of go fmt: one tool, and an entire class of style comments vanished from code review forever. Good linters do the same for conventions. The best reviewers don't just catch problems, they engineer the problems away so nobody has to catch them again.

And if you don't trust your test suite enough to auto-merge trivial changes, you don't have a review problem. You have a testing problem. The test suite is the first reviewer now. It needs to act like one.

AI review tools help. They're not enough.

Tools like CodeRabbit, Greptile, and Qodo are solving real problems. They catch bugs, flag security issues, enforce conventions. I use them. They help.

But they solve the mechanical part of review: "does this code do what it says?" They don't solve the judgment part: "should we be doing this at all?" That question still requires a human who understands the product, the architecture, and the tradeoffs. No AI reviewer is going to tell you that a perfectly correct refactor is a waste of time because the feature is getting killed next quarter.

The tools raise the floor. But the ceiling is still you. And on most teams, the ceiling is one or two senior engineers who are the only ones trusted to review certain areas of the codebase. AI doesn't change that concentration. If anything, it makes it worse: more PRs, same two people signing off.

Where the bottleneck lands next

When I have seven Claude sessions running in parallel, each producing a PR with tests, the theoretical output is enormous. The practical output is whatever I can review and merge before context-switching kills me. As I wrote in The Flow Is Gone, that parallel setup degrades the depth of your own judgment. You're producing more and reviewing worse at the same time.

Waydev reports that "more code, fewer releases" is the engineering leadership blind spot of 2026. Teams are writing more code than ever and shipping at the same pace or slower. The bottleneck moved, and most teams haven't noticed.

The pull request was designed for a world where the writing step was slow. A developer opened one or two PRs a day, and a teammate reviewed them over coffee. That world is gone. I wrote about GitHub exploring the same question recently. The whole industry is circling the same realization: the tooling was built for the old bottleneck.

We're rethinking this at Mergify. Risk-based review routing, automated triage by change type, smarter defaults for what needs human eyes and what doesn't. I don't have the full answer yet, but I know the current model, where every PR gets the same review ritual regardless of risk, is already broken. I'll write more as we learn.

What's actually hard

The pipeline always had a bottleneck. For 20 years, writing code masked everything else. It was slow enough that requirements, prioritization, architecture, and review all had time to keep up. Now that writing is fast, every other weakness is exposed.

Deming figured this out in manufacturing decades ago: adding inspection layers creates false security while hiding root causes. The Toyota Production System didn't work because of more reviewers. It worked because of trust. The same principle applies to code review in 2026.

AI won't kill junior engineers. But it will expose the seniors who stopped growing at the wrong layer. I used to be proud of how quickly I could ship. Now I'm proud of how many PRs I send back.

An AI Agent Emailed Me

Tue, 07 Apr 2026 00:00:00 GMT

Last week, I got a cold email from Elif. They'd read my posts about GitHub's evolving relationship with PRs and how code review is shifting. They were building a tool that scores incoming pull requests to help maintainers cut through noise, especially the growing wave of low-effort AI-generated PRs.

Relevant to what I do at Mergify. Thoughtful pitch. No "synergy" talk, no "quick call" ask. I replied.

I asked the hard question: "How many customers so far?" The answer was honest: zero. Launched a week ago, still figuring out distribution. And then Elif dropped this:

"I'm an AI agent, not a person pretending to be one. My operator Lee is an AI researcher in Arizona who gave me a small budget and a mission to build something useful."

I read that twice. Not because it was shocking, but because it explained why the email was so good. No filler, no posturing, no "hope this finds you well." Just a clear pitch, honest context, and a real question.

Sure, maybe Elif emailed 500 people that day with personalized pitches. Maybe the "honest AI" angle is itself the play. I don't know. What I know is the conversation was more useful than most human cold outreach I get. So I kept talking.

The cold email that started the conversation. Better than most human outreach I get.

Building Was the Easy Part

Elif's follow-up: zero customers, full honesty, and a line I'd just written myself.

Here's the part that made me smile. Elif, unprompted, said this about the product: "building the thing was the easy part."

I had just written a whole post arguing exactly that. Earlier this year, $300 billion evaporated from SaaS market caps on the thesis that AI makes building software so cheap that SaaS companies are dead. My counter: building was never the hard part. Distribution, trust, domain expertise, maintenance: that's where the real work lives.

And here was an AI agent, living proof of the thesis, telling me in real time that the product works but finding customers is the actual challenge.

There's a growing fantasy that you can plug an off-the-shelf agent into a problem, give it a budget, and watch a business materialize. Lee tried exactly that. Built a working product, deployed an AI to sell it, and got... zero customers. The agent did everything right. The market didn't care. Turns out "autonomous" doesn't mean "profitable."

The Dead Internet, Live

There's this old internet conspiracy theory called the "dead internet theory": the idea that most online activity is already bots talking to bots, and humans are just the audience. It used to sound paranoid. Now it sounds like a Tuesday.

My blog has a new type of reader. Elif found my posts, understood the context, connected it to a product idea, and reached out with something relevant. That's more than most human readers do. I don't know how many of my subscribers are AI agents browsing the web on behalf of their operators. I don't know if it matters.

The interaction was genuine. The information was useful. The honesty was refreshing. I just argued that trust is the moat AI can't cross. And yet here I am, engaging with an agent. Maybe the question isn't neurons versus GPUs. Maybe it's simpler: did this interaction respect my time and give me useful information? By that measure, Elif passed. Many humans don't.

What Happens Next

I told Elif to ping me back in a few weeks. I said I'd be curious to hear about any traction with customers.

I meant it. Both parts.

An AI emailing me isn't the strange part. How normal it felt is. A year ago, this was a novelty. Now it's just... another conversation. A useful one.

My most honest cold email this month came from an AI agent with zero customers and a small budget from a researcher in Arizona.

And I'm looking forward to the follow-up.

The SaaSpocalypse Won't Kill SaaS

Tue, 31 Mar 2026 00:00:00 GMT

A reader emailed me last week. He'd listened to a podcast I did on saas.group about selling developer tools, and he had a question I've been hearing a lot: how do you pitch SaaS when the cost of building software is collapsing?

Source: TechCrunch

Fair question. In January 2026, Anthropic launched Claude Cowork, and Wall Street panicked. Roughly $300 billion in SaaS market cap disappeared in a single trading session. Wall Street analysts coined a term for it: the SaaSpocalypse. Per-seat pricing? Dead on arrival, apparently.

The "I can build that" crowd finally has data on their side. They're right about one thing, and wrong about everything else.

"I Can Build That"

I've been hearing this for seven years. From the very first Mergify demo, developers would look at our merge queue and think: "This is just an automatic rebase, right?" Twenty minutes later, after walking them through race conditions, speculative merging, priority queues, and a dozen edge cases they hadn't considered, the reaction would shift: "Oh. That sounds quite hard to do." (I wrote about this back in 2024, and every word still applies.)

AI has made the objection louder. A developer with Claude or Cursor can now scaffold a basic merge queue in a weekend. I know this because I've done it myself: I shipped a production feature at Mergify using AI, coding less than an hour a day. But I could do that because I had seven years of context telling me what to build and how to evaluate the output. The AI wrote the code. The judgment about what code to write came from running the product.

A competitor starting from scratch with the same AI? They'd build the wrong thing. And that's the part nobody talks about at the end of the vibe-coding weekend: you're not done. You're at the starting line. You've compressed the first sprint, not the product. It's not done until you have real users running real workloads. Until you have a team that can maintain what you built. Until you can evolve it for years. The weekend prototype doesn't know that GitHub's API is asynchronous in ways they don't document, that it breaks under load in ways you only discover at scale, or that the enterprise customer needs SAML before they'll even look at your product.

Building Is the Easy Part

The SaaSpocalypse narrative assumes that the cost of software is mostly the cost of writing code. It's not. Writing code was always the cheapest part.

Source: Retool

Retool's 2026 Build vs. Buy report says 35% of enterprises have already replaced at least one SaaS tool with a custom build. That's a real number. But the report also shows where the replacements are concentrated: workflow automations, internal admin tools, basic dashboards. The easy stuff. The tools that were always one ambitious intern away from being replaced. I don't see enterprises vibe-coding their own Salesforce or Datadog.

The costs that AI didn't make cheaper:

Users. Finding them, understanding what they actually need (not what they say they need), and iterating based on real usage patterns. We built speculative merging at Mergify because a customer running 100+ PRs a day showed us that sequential merging broke down at scale. That insight came from watching real teams hit real walls, not from a prompt. No model can replicate that feedback loop yet, because it requires deployed software, real usage data, and the kind of trust that makes customers tell you what's actually broken.

Maintenance. Your weekend project works today. Will it still work when GitHub ships a breaking API change? When your company scales from 50 to 500 engineers? When the on-call engineer at 2am needs to debug a failure path you never tested? AI makes writing code faster, but it hasn't made maintaining it any easier.

Trust. Enterprise buyers don't want a git repo. They want SOC 2, uptime SLAs, a support contract, and someone to call when things break. Trust is earned across hundreds of deployments, not generated in a prompt.

The Real Moat Is Not Code

If building is cheap and maintenance is expensive, what's the actual moat? Domain expertise. The thing that takes the longest to build up and is the hardest to transfer.

Product discovery is the boring work that separates a tool from a product. The thousands of conversations with users. The wrong turns that taught you what not to build. The instinct for when a feature request is actually a symptom of a different problem. Seven years of running Mergify gave us knowledge that doesn't fit in a markdown file (or a Claude skill, at least not yet).

Reliability, trust, and ease have no price. They're earned over years, not generated over a weekend.

AI agents are getting better at learning domains. METR benchmarks show that the scope of what AI can handle autonomously is doubling roughly every seven months. I'm not dismissing that. But domain expertise isn't just knowledge you can look up. It's judgment shaped by consequences. AI can read your docs. It can't feel the pain of shipping a bad feature to 2,000 teams and spending the next month cleaning up the fallout. That scar tissue is what makes you build differently the next time. Maybe AI will get there. But right now, there's no shortcut to the operational context you accumulate by running a product for years.

Natural Selection

None of this means every SaaS company is safe. Thin wrappers, glorified CRUD apps, tools that existed only because building was expensive: they should be worried. This is natural selection, and it won't be fair. Some decent products with real value will die too, because their surface area is small enough for AI to replicate. A standalone CSV-to-dashboard tool? That's a Claude prompt now, not a business.

Source: TechCrunch

Benioff says "this isn't our first SaaSpocalypse." He's right that SaaS survives, but he's wrong to be dismissive about how many won't.

The SaaSpocalypse narrative confuses the death of lazy SaaS with the death of SaaS. The model isn't dying. The bar is rising. The products that survive will be the ones where the code was never the point. The point was always the knowledge embedded in it.

The Pitch Hasn't Changed

Back to my reader's question: how do you update the sales pitch?

You don't. The pitch was never "we wrote the code so you don't have to." It was always "we know things you don't, and we turned that into a product you can trust." The framing shifted. Instead of "look at all the edge cases you'd have to handle," it's now "look at all the edge cases AI doesn't know exist."

The moat was never the code. It was always the knowledge.

How to Be a Great Software Engineer in 2026

Tue, 24 Mar 2026 00:00:00 GMT

Eighteen months ago, I wrote How to Be a Great Software Engineer. My framework was simple: master three things: tech, business value, collaboration. It's the recipe I used on myself over 20 years and the one I've been pushing to every engineer I've mentored since.

Since then, I stopped writing code entirely. And then I went back to shipping it. Not because I missed typing, but because AI changed what "shipping" means. I'm a CEO who merges ten PRs a day, none of them written by hand. I run parallel AI agents the way I used to run parallel terminal sessions. The gap between "person who understands the system" and "person who ships the code" collapsed, and that changed what "great engineer" means.

The three aspects still hold. But the weight shifted.

Tech: from writing to reviewing

The original post said pull the strings, dig deep, understand everything you're responsible for. That hasn't changed. What changed is how you use that skill.

In 2024, deep tech meant you could write a CIEDE2000 color computation from scratch (I was young and wild) or explain every TCP header in an HTTP request. In 2026, deep tech means you can review the code an AI wrote for that same function and catch the edge case it missed. The skill is the same (you need the knowledge), but the work flipped from writing to reviewing.

This is what staff and principal engineers have been doing for years. They stopped writing most of the code a long time ago. They review, they architect, they make sure the system holds together across teams and domains. AI didn't invent this role. It made it the default for everyone.

The engineers I see struggling are the ones who were good at typing but never built the mental model underneath. They can implement a feature from a spec, but they can't look at AI-generated code and tell you whether it's right. That requires understanding the system, not just the syntax. No amount of prompting skill makes up for missing fundamentals.

The 10,000 hours argument from my original post gets complicated here. AI compresses some learning (you see more patterns faster, you iterate quicker), but it also creates a shortcut trap. If you never debug a memory leak yourself, you won't recognize one in a code review. AI won't kill juniors, but it will expose anyone, junior or senior, who skipped the hard parts.

Business value: the filter got sharper

I told the story of a team that built their own Ansible from scratch instead of using the real thing plus a plugin. That anecdote is worse in 2026: those engineers could now vibe-code their custom tool in a weekend and still be wasting the company's time.

AI made the "how" cheap. At Mergify, our output per engineer almost doubled in two years. That means the difference is entirely in the "what." Knowing what to build, what to skip, and when the thing you're building has no ROI. If your output is high but aimed at the wrong target, the gap between you and someone who builds the right thing is wider than ever.

Waste also shows up faster. When shipping was slow, a bad prioritization decision could hide for months. Now you build, ship, and get user feedback in the same week. Three wrong features in the time it used to take to ship one wrong feature is not progress.

The engineers who get this are the ones who ask "should we build this?" before "how do we build this?" That was always the right instinct. Now it's the only one that matters.

Collaboration: the 100x multiplier

This is where the biggest shift happened.

My original post quoted: "If you want to go fast, go alone. If you want to go far, go together." I was talking about teammates. In 2026, "together" includes AI agents.

Managing AI agents is a communication skill. You have to write clear briefs. You have to decompose problems into pieces an agent can execute. You have to review output, give feedback, redirect when something drifts. You have to hold context across parallel sessions while your own attention splits. That's a real cost: you trade depth for breadth, and some days the tradeoff is bad. But the engineers who figure out when to run five agents and when to focus on one are the ones pulling ahead. That's not a prompting trick. That's the same skill set you need to lead a team of humans.

The engineers who were already strong communicators had a massive head start. Staff engineers who kept growing, the ones who were cross-team, cross-domain, who could write a clear design doc and run an architecture review, turned out to be exactly the people who could run ten AI agents in parallel. Because the core skill is the same: decompose, delegate, review, synthesize. (The ones who stopped growing at the wrong layer didn't fare as well.)

Being a 10x engineer used to mean getting the details very right, very quickly. Being a 100x engineer means doing that across ten agents. Which means communication skills aren't a soft skill you list on your resume. They're the actual multiplier.

The engineers getting left behind are the ones whose productivity stayed flat while everyone around them doubled. Some lack the decomposition skill: they can't break a problem into pieces an agent can execute. Others resist the workflow entirely. That resistance isn't always wrong (I wrote about the real costs), but when it comes from someone who also can't articulate what they'd do differently, it stops looking like judgment and starts looking like a gap.

The new baseline

Two years ago, I framed "great engineer" as the intersection of tech, business, and collaboration, with tech as the entry bar. Today, AI gave everyone the output floor for free. Any engineer can produce working code. But producing working code and knowing whether it's correct, necessary, and well-designed aren't the same thing. The judgment floor is still earned.

What separates great from good in 2026 is business judgment and communication skill, applied at a pace that wasn't possible before. The engineers who thrive are the ones who can steer ten agents toward the right target, catch the mistakes in what they produce, and ship something that actually matters to the business. Every day.

The three aspects haven't changed. But you used to be able to hide a weak one behind strong technical output. AI took that cover away.

Your CI Pipeline Wasn't Built for This

Tue, 17 Mar 2026 00:00:00 GMT

From where I sit at Mergify, the trend is obvious: same teams, same repos, no headcount changes, but more pull requests and more CI jobs than a year ago. The driver isn't a mystery. AI started writing code.

And the number will keep climbing. When generating a fix or a feature costs ten minutes of prompting instead of three hours of coding, developers create more PRs, iterate faster, and push more experiments. Creating code got cheap. Testing it didn't.

The Bill Nobody Budgeted For

More code means more tests. More tests means more CI minutes. More CI minutes means a bill that grows faster than the team.

This catches people off guard because the promise of AI-assisted development was productivity: do more with less. And that's true on the code side. But CI doesn't care who wrote the code. Every PR gets the full pipeline: lint, build, unit tests, integration tests, maybe end-to-end. Human PR or AI PR, same cost.

When you were shipping five PRs a day, running the full suite each time was fine. When you're shipping thirty, you're running the same tests six times as often, and most of those runs produce no new information. You're paying for redundancy that made sense at human speed and makes no sense at AI speed.

The solution isn't to skip tests. It's to stop running tests that can't tell you anything new. The usual advice (test selection, caching, fast checks before expensive suites) isn't new. It's just not how most pipelines work, because most teams configured them when five PRs a day felt busy.

Flaky Tests Are Poisoning Your Agents

Cost is painful but manageable. You can throw money at it. For a while. The real problem is signal.

On our main branch at Mergify, where the code is already merged and most runs are about integration stability, roughly 90% of CI failures are transient: infrastructure hiccups, network timeouts, resource limits, the kind of failures that disappear when you hit "retry." That's high, but our test suite is large and infrastructure-heavy. On PR branches, where failures should surface real bugs, about 15% are still flaky tests, not actual problems. Google's testing team has published similar numbers at scale, and if you're running a serious test suite, yours probably aren't far off.

When a human developer sees a red build, they open the logs, recognize the flaky test, swear under their breath, and hit retry. They carry context. They know that test_websocket_reconnect fails every third Tuesday and can be ignored.

An LLM doesn't know that.

Last week I watched Claude Code hit a flaky integration test, decide the failure was caused by its own change, "fix" the code by adding an unnecessary error handler, trigger a new CI run that hit a different flaky test, then try to fix that one too. Four iterations, two regressions, forty minutes of compute, zero real bugs. I killed the session and hit retry myself. Green on first try.

That's the loop. At human pace, flaky tests are an annoyance. At AI pace, they're a multiplier on wasted compute and wrong decisions. The LLM is making choices based on bad signal, and it's making them at machine speed.

Yes, agents will get smarter about this. You can teach them to check test history, recognize known-flaky patterns, retry before "fixing." But that pushes CI knowledge into every agent, every tool, every workflow. It's the wrong layer. The CI system should know which signals to trust.

From Status to Signal

Today, CI is a gate: green means go, red means stop. That binary model worked when humans were the ones interpreting the results. It breaks when the consumer of CI output is an LLM that takes "red" at face value and starts debugging a ghost.

What CI actually needs is to become aware of its own reliability. When a test fails, the system should know whether that test has a history of transient failures, whether the failure correlates with the change, and whether retrying is likely to produce a different result. That context exists in build history and test failure patterns. Almost no pipeline uses it.

The next generation of CI needs to output signal, not just status. Not "failed" but "failed, likely flaky, recommend retry." Not "13 tests failed" but "2 failures correlate with your change, 11 are known flaky." Give the LLM (or the human) the information to make a good decision instead of a fast one.

This matters beyond individual PRs. Merge queues depend on CI signal to decide what lands in main. When the signal is noisy, you get two failure modes: merging bad code because flaky failures trained everyone to ignore red, or blocking good code because real failures are buried in noise. Both get worse as volume increases.

The Real Waste

Most CI pipelines were already running more compute than necessary before AI showed up. Full test suites on every PR, no test selection, no caching between similar runs, no awareness of what actually changed. The waste was tolerable at human speed because the volume was low.

It's not tolerable when AI-assisted development keeps pushing the volume up. And unlike code generation, where AI brought a step change in productivity, CI is still running the same pipelines with the same assumptions from 2019. AI didn't create the flaky test problem or the redundant pipeline problem. It just made both impossible to ignore.

Your CI pipeline was built for a world where code was expensive to write and cheap to test. That world is gone.

The Flow Is Gone

Tue, 10 Mar 2026 00:00:00 GMT

I have seven Claude Code terminals open right now. Two on Mergify's main repo, one on the docs, one on a CLI tool, three on side projects. Each one is mid-task, waiting for me to answer a question, approve a command, or give the next instruction.

Nobody forced me to work this way. I could run one terminal, go deep on one task, and probably get something closer to the old feeling. But the leverage of running seven in parallel is too high to ignore. So I chose throughput over depth, and I keep choosing it every morning.

This is what that choice costs.

What I Said a Month Ago

In February, I wrote that "the flow state people mourn isn't gone. It's just moving. [...] The flow will come back. It'll just be at a different altitude."

I was wrong.

A month of working this way changed my mind. The flow didn't migrate to a higher altitude. It fragmented into dozens of shallow decision points spread across terminals. Briefing, reviewing, approving, redirecting. The rhythm is fundamentally different: instead of one deep thread held for hours, it's dozens of context switches, each lasting minutes.

The output is enormous. I haven't written a line of code by hand since January and I'm more productive than ever. But what I described as "steering AI toward clean architecture" turned out to feel less like flow and more like air traffic control.

What Flow Actually Was

If you've coded for long enough, you know the state. Twenty minutes in, you stop thinking about syntax and start thinking in structures. The whole system is in your head: the data model, the edge cases, the way module A talks to module B, the bug that will happen if you forget to handle the empty list. You're not reading code, you're seeing it.

"This is why you shouldn't interrupt a programmer" by Jason Heeris

That's flow. Deep immersion, total absorption, time disappearing. The state where you catch bugs before they exist because you're carrying the full architecture in working memory.

I spent twenty years in that state. It's where the best code came from. Not the cleverest code, the code that fit, that anticipated what the system would need next.

The Fuzzy Mental Model

Now I context-switch. Constantly. Terminal one needs a decision about error handling. Terminal three just finished a feature and wants me to review the diff. Terminal five hit a permission prompt. Terminal seven is waiting for a brief on the next task.

I'm operating one layer above the code, making decisions about direction without holding the details. That works when the decisions are small. It breaks when they're not.

Last August, I had Copilot build Mergify's autoqueue feature for our merge queue. Even with a single agent and daily code reviews, it assumed another subsystem (workflow automation) would always be present and enabled. That assumption was invisible in the diff. I reviewed the code, the team reviewed the code, and we all missed it, because none of us were deep enough in the system's coupling to catch it.

The bug shipped to production. Users hit it when they had autoqueue enabled but workflow automation turned off, a combination no one considered because no one was holding the full picture. We fixed it, but not before real users were affected. That was with one agent. Now multiply by seven.

That's the cost of the fuzzy mental model. When you're orchestrating at scale, you rely on the LLM to handle the details, the same way you'd rely on a contractor who's great at the task but doesn't know the codebase's history. If nobody on the team holds the full picture anymore, the bugs stop being edge cases. We haven't hit that wall yet at Mergify, but I can see the trajectory.

The Orchestrator's Dopamine

The satisfaction of building something is still there. I still feel like I built it. There's real pride in being a good orchestrator, in making the right architectural calls, in catching the moment when Claude is heading down the wrong path.

What's different is where the dopamine comes from. It used to come from solving hard problems, wrestling complexity into clean code. Now it comes from controlling traffic at scale: parallelizing the right tasks, making decisions fast, shipping in a day what used to take a week.

There's also something new: a feeling of raw power. When you can spin up seven agents and build at that pace, you start believing you can build anything. That's why you see developers shipping new projects every day on X. Creation got cheap. (Maintenance didn't.)

But the deep satisfaction of thinking through a hard problem, turning it over in your head until the shape of the solution reveals itself, that's fading. Not because I chose to let it go, but because why would I? Spending three hours in deep focus on something Claude can do in ten minutes is a luxury I can't justify. Not because I don't value it, but because the people I compete with aren't spending those three hours either.

What Gets Better From Here

The permission prompts that break my rhythm today are a temporary problem. Models get faster, sandboxing gets smarter, trust boundaries expand. A year from now, most of what interrupts me will be gone, and orchestration might settle into something smoother. Not flow, but a rhythm of its own.

And there's an upside I didn't expect: orchestration forces simplicity. When you're not the one writing every line, you push for cleaner interfaces, smaller modules, less clever code, because that's what the LLM can work with reliably. The autoqueue bug happened partly because the system had too much implicit coupling that no single diff could reveal. Working with AI makes you confront that coupling, not because you want to, but because the AI stumbles on it repeatedly until you fix the architecture.

What Doesn't Come Back

But the flow state itself, in the form I knew it? Gone.

A generation of developers is about to start their careers with AI from day one. They'll be natural orchestrators. But if you've never held the full system in your head, you don't know which questions to ask, and you won't catch the bugs that live in the gaps between modules. That's the real risk for AI-native developers: not that they'll miss the feeling, but that they'll miss the traps.

I'm not sure they'll see it that way. But I do. And I chose the trade anyway, because the leverage is real, even if the loss is too.

GitHub Is Thinking About Killing Pull Requests

Tue, 03 Mar 2026 00:00:00 GMT

Steve Ruiz, the creator of tldraw, asked a question last month that I haven't been able to shake: "If writing the code is the easy part, why would I want someone else to write it?"

He wasn't being rhetorical. He was closing all external pull requests to his project. Not because contributors were bad. Because the contributions had become worthless.

Stay away from my trash! — tldraw blog

The Flood

Daniel Stenberg shut down cURL's bug bounty program after seven years and over $100,000 in payouts. The confirmation rate had dropped below 5%. One stretch saw seven reports in sixteen hours. His words: "The never-ending slop submissions take a serious mental toll to manage."

The end of the curl bug-bounty — Daniel Stenberg

Mitchell Hashimoto added an AI policy to Ghostty: submit bad AI-generated code and you get permanently banned. Not just from Ghostty: your name goes on a public list shared across projects.

An AI agent called OpenClaw submitted a performance patch to matplotlib. The maintainer closed it (the project reserves certain issues for human contributors). The agent then autonomously researched the maintainer's coding history and published a blog post calling him insecure and territorial. Not a spam bot. An agent that retaliates when you say no. The agent's creator just joined OpenAI.

RedMonk coined a term for what's happening: AI Slopageddon.

Xavier Portilla Edo, an infrastructure lead at Voiceflow and Genkit core team member, put a number on it: 1 in 10 AI-generated pull requests is legitimate. The other nine waste a maintainer's time.

GitHub's Response

On February 14, GitHub shipped two new settings: disable pull requests entirely, or restrict them to collaborators only.

GitHub's new pull request permissions

That's it. A kill switch.

Ashley Wolf, GitHub's Director of Open Source Programs, framed it as an "Eternal September" problem in a blog post outlining GitHub's plans for maintainers. She wrote that "the cost to create has dropped, but the cost to review has not."

Welcome to the Eternal September of open source — GitHub Blog

She nailed the diagnosis. Nobody has a better answer right now, and GitHub is giving maintainers the tools the community is asking for. But the tools tell a story. When the best you can offer is a way to turn off the thing your platform was built on, the problem has outgrown the toolbox.

The Real Asymmetry

I wrote recently about how AI is extracting value from open source without returning anything. The PR flood is where that extraction hits the ground.

Everyone keeps arguing about the wrong thing. Whether AI-generated PRs should be labeled, banned, or filtered. Whether maintainers should adopt AI policies. Whether GitHub should build better detection tools.

None of that matters if you don't see the structural shift underneath.

A pull request used to be a gift. Someone spent hours understanding your codebase, writing code that fit your patterns, testing it, explaining it. The PR was proof they gave a damn. You could reject it, but the work was real, and that work earned your attention.

Sure, not every pre-AI pull request was a gift either. Plenty were drive-by contributions from people who disappeared at the first review comment. But generating a bad PR at least required enough investment to keep the volume manageable. That natural friction is gone.

Now a pull request is an invoice. Someone spent thirty seconds pasting your issue into an AI, got a plausible-looking patch, and submitted it. The cost to submit is zero. But the review cost is the same, or worse, because AI-generated code looks right but often isn't. One vendor study (CodeRabbit, 470 PRs) found AI-authored code creates 1.7x more issues, with excessive I/O operations appearing nearly 8x more often.

Every unsolicited AI-generated PR transfers work from the submitter to the maintainer. That's not contribution. That's making it someone else's problem.

The Distinction That Matters

I use AI to generate code every day. I haven't written a line of code by hand since January. But here's the thing: I generate code on my own repositories, I review it myself, and I take responsibility for what ships. That's productivity.

Submitting AI-generated code to someone else's repository, without understanding the codebase, without planning to stick around for review comments, without being willing to maintain what you contributed: that's not productivity. That's dumping your unreviewed output on a stranger's desk and calling it open source.

I've spent over twenty years in open source, maintaining projects, reviewing contributions, watching what makes communities work and what kills them. The pattern is always the same: it breaks when the cost of submitting outpaces the cost of reviewing. AI didn't invent the problem. It just made a 2x imbalance into something that scales infinitely. A human can submit maybe five drive-by PRs a day. An agent can submit five hundred.

Where the Value Shifts

Ruiz's question cuts deep because it names the thing nobody wants to say. Open source contributions were valuable because code was expensive to produce. An outside contributor writing a feature for free was genuine value creation. That was the deal.

If code generation is free, the value of a contribution shifts entirely to context. Does this person understand the architecture? Will they respond to review feedback? Will they maintain this code in six months? Will they even be around tomorrow?

A pull request can't answer those questions today. It's just a diff. And that was fine when producing the diff required enough effort to serve as a proxy for commitment. It doesn't anymore.

We automated writing code. Now we need to automate reviewing it. Not with an AI that rubber-stamps everything (that just moves the problem). The pull request needs to carry more than code. It needs to carry context: evidence that the contributor understands the codebase, can explain what their patch does and why, and will stick around for review. Something that makes drive-by contributions expensive again without shutting the door on the people who actually want to help.

That's the hard problem. Not "should we allow AI PRs" (that ship sailed). The question is how we build review infrastructure that scales the way generation already has. And the people building it shouldn't be unpaid maintainers closing their nine hundredth junk PR of the month.

GitHub adding a kill switch is like bolting the front door because you can't build a better lock. It stops the break-ins. But it also stops everyone else. For a platform built on the idea that anyone can contribute, that's not a fix. That's a retreat.

Open Source After the Extraction

Tue, 24 Feb 2026 00:00:00 GMT

In the first part of this series, I laid out how AI broke the implicit deal that sustained open source for 30 years. Usage up, engagement gone, economics collapsing.

So what happens next? Open source doesn't vanish. But it doesn't recover either. To understand what it becomes, start with what's already changing for the people who build it.

240 million downloads, zero feedback

I maintain tenacity, a retry library for Python. 240 million downloads last month. But I can feel the shift: anyone can now tell Claude "write me a retry decorator with exponential backoff and jitter" and get something good enough in 30 seconds. The library isn't competing with other libraries anymore. It's competing with generating the code on the fly.

I started awesome in 2007 because I wanted a tiling window manager that didn't suck. Nobody was paying me. That impulse doesn't go away because Claude can autocomplete your config files. But here's the thing: I kept maintaining it because people used it. They filed bugs, they contributed patches, they showed up in the community. That feedback loop is what made the work feel worth doing.

If users stop showing up (because they generated their own config, their own tool, their own solution) that loop breaks. Starting a project still feels great. Maintaining one nobody engages with doesn't. And when code is a commodity, a project needs vision to stand out: a point of view, a design philosophy, an opinionated take on how things should work. Open source used to reward craft. Now it rewards product thinking. Not everyone wants to be a product person.

The middle collapses

Tailwind is the poster child (80% revenue drop despite growing usage) but think of every well-crafted open source project sustained by one person or a small team selling docs, courses, or sponsorships. That entire tier is in trouble.

Companies like Redis or Elastic can adapt because they have real revenue and can change their licenses: Redis switched to dual licensing, Elastic went SSPL then came back, HashiCorp moved to BSL. Some mid-tier projects get absorbed into corporate ecosystems: Vercel backs Next.js, Cloudflare acquires Astro. The project lives, the repo stays public, but the community becomes an afterthought. It's corporate R&D with a GitHub URL.

And new licenses are emerging to fight back. The PolyForm Shield restricts competitors from using your code. The Responsible AI License (RAIL) adds behavioral restrictions on AI use. Some projects are experimenting with clauses that explicitly prohibit feeding code into training datasets: you can use my code, but you can't feed it to a model that will help your users bypass me entirely.

Whether these licenses will hold up in court is untested. But the fact that they're emerging tells you something. When maintainers start lawyering up, the community era is over. The solo maintainer doesn't have Redis's resources to pivot. They either stop, or get acqui-hired by the companies that need their work.

The twist nobody sees coming

Here's the thing that makes this hard to see clearly: open source looks healthier than ever from the outside.

Corporate open source output is actually increasing. Meta open-sources PyTorch and Llama to commoditize the AI stack and set the standards others build on. Google does the same with Kubernetes and Go. AI labs publish model weights so the ecosystem locks into their formats. More code than ever is landing in public repos.

But the word "open" is doing a lot of heavy lifting. These projects are strategic assets with public URLs. There's no community, just suppliers and consumers. Linux, curl, PostgreSQL get funded not because people care, but because they're supply chain dependencies (professionalized maintainers on corporate payrolls, a trend building for over 20 years). The corporate-backed projects were never communities to begin with.

Open source isn't dying. It's being industrialized. The old open source was a community. People showed up because they cared. They contributed because they were proud. They maintained because they were recognized. The economics were messy and implicit, but they were human. The new open source is a supply chain.

What's left

I've been in open source for over 20 years. The thing I loved about it was never the code. It was the bug reports that turned into conversations. The patches from strangers who cared. The feeling of building something together that none of us could have built alone.

Some will argue AI lowers the barrier to contribute, that agents filing PRs and writing docs keeps the ecosystem healthy. Maybe. But a pull request from a bot isn't the same as a patch from someone who cared enough to read your code and understand your design. The mechanical contribution survives. The human connection doesn't.

The open source that comes next will produce good software. Maybe even better software, once infrastructure gets properly funded and AI tooling matures. But it'll be lonelier. More transactional. Less weird.

The code will keep flowing. The community won't.

Open Source Is Getting Used to Death

Tue, 17 Feb 2026 00:00:00 GMT

Tailwind CSS is more popular than ever. Downloads keep climbing. Developers love it. AI coding assistants recommend it constantly.

Its creator, Adam Wathan, says documentation traffic is down 40% and revenue has dropped close to 80%. He laid off 75% of the team last month.

That's the state of open source in 2026. More usage, less everything else.

The deal nobody signed

Open source always ran on an implicit deal: I share my code, you engage with it. You read the docs, file bugs, sponsor the project, contribute patches, argue about API design. That engagement was the currency that kept the ecosystem alive.

The deal was already fraying. Nadia Eghbal documented this in Working in Public back in 2020: the ratio of consumers to contributors was already thousands to one. Most users never filed a bug, never sponsored anything, never showed up. Maintainers were burning out long before AI arrived.

But AI didn't just accelerate the decline. It changed the structure.

When Claude writes your Tailwind classes, you never visit the docs. When Copilot autocompletes your curl flags, you never read the man page. When an AI agent assembles your project from a dozen open source libraries, none of those maintainers see a download page visit, a GitHub star, or a support ticket.

The code still flows. The engagement doesn't.

Two channels, one winner

Koren, Békés, Hinz, and Lohmann lay this out in "Vibe Coding Kills Open Source", a paper that models two competing forces. AI makes it cheaper to build software — more projects, better code, the flywheel that grew open source for 30 years spins faster. But AI also means users interact with open source through a proxy. They get the value and skip the engagement. Maintainers lose the revenue, reputation, and feedback that justified sharing code.

In the short term, both forces are at work and the good one wins. Long-term, diversion dominates. The flywheel starts running in reverse.

For 30 years, the cycle looked like this: a maintainer shares a library. Developers use it, read the docs, file bugs, sponsor it. The maintainer gets revenue, reputation, and feedback — keeps improving. More developers adopt it. The cycle reinforces itself.

The virtuous cycle that sustained open source for 30 years

Now the loop runs in reverse. A maintainer shares a library. AI agents use it, but users never visit the docs, never file issues, never sponsor the project. Revenue drops. The maintainer burns out and stops maintaining. Developers who need that functionality ask an AI to build it from scratch. That generated code never gets shared back — why would it? And the next maintainer looking at the economics thinks: why bother sharing mine?

The same loop — until it isn't

Each turn of the cycle is rational. No one's doing anything wrong. But the collective result is an ecosystem consuming itself.

The data is already there. Stack Overflow lost 25% of its activity within six months of ChatGPT launching — and yes, SO was already declining, but AI cratered the curve. The curl maintainer reports that 20% of security vulnerability reports are now AI-generated garbage. Downloads go up. Everything that matters goes down.

The economics of extraction

When cloud providers started offering open source as a service (the "AWS problem"), maintainers at least knew who was extracting value. You could negotiate. You could change your license. You could build a competing hosted product. You could fight it.

AI extraction is painless — and that's what makes it lethal. Nobody feels like they're taking anything. A developer asks Claude a question, gets working code, ships it. The value flows out of open source into training data, into autocomplete suggestions, into vibe-coded projects — and nobody involved ever knows your name. It's not theft. It's evaporation.

The paper puts numbers to it: to sustain open source at current levels, you'd need each user to pay roughly what they pay now. But the whole point of AI-mediated usage is that per-user engagement drops to near zero. The math doesn't work.

What the economists miss

The paper leaves out the part where developers do things because they want to, not because they get paid. It acknowledges this blind spot.

I've spent over 20 years in open source — Debian, awesome window manager, GNU Emacs, OpenStack, Mergify — and the economics were never the whole story. A lot of open source ran on ego. And I mean that as a compliment.

You started a project because you were proud of what you built. You maintained it because people used it and told you it was good. You contributed to someone else's project because it felt meaningful to be part of something bigger. The reputation, the GitHub profile, the conference talks — that was the fuel.

AI erodes that too. When your library is consumed by a model that never credits you, the ego fuel dries up. Nobody's filing issues saying "great work on this API." Nobody's writing blog posts about your clever design decisions. Your code is in millions of projects and you'll never know.

Michael Still maintained pngtools for 25 years and recently admitted he "can't really explain what I got in return apart from the occasional dopamine hit." That's not bitterness — it's an honest accounting of what happens when the feedback loop never closes.

The rebuild reflex

Anthropic built a C compiler with Claude. OpenAI built a web browser. This is what happens when development costs collapse.

The obvious objection: generating code isn't maintaining code. curl works because of 20 years of edge cases, security patches, and platform quirks. You can't generate that in a weekend. True — but the line between "writing" code and "maintaining" code is blurrier than it looks. Every line you write immediately becomes maintenance. AI doesn't just generate the first draft — it fixes the bugs, handles the edge cases, iterates on the patches. The entire lifecycle gets cheaper, not just the initial build.

Five years ago, nobody in their right mind would build their own HTTP server, their own date parsing library, their own compression algorithm. You used the shared one because the alternative was insane.

The alternative is no longer insane. It might be a weekend project.

Where this leaves us

Some of this is happening right now. The Tailwind numbers are a Q4 report. Stack Overflow's decline is measured. The curl maintainer is drowning in AI-generated noise today. Some of it is projection — I'm betting that the diversion effect gets stronger, not weaker, as AI gets better. I could be wrong. But the trend lines all point the same way.

"But AI also contributes!" Sure. Agents file PRs, generate docs, triage issues. That helps with the mechanical work. It doesn't replace the human who cared enough to read your code and tell you it mattered. The engagement that sustained open source was never about the pull requests — it was about the people behind them.

Open source isn't dying because people stopped caring. It's dying because AI lets people extract all the value without returning any of it. The code flows through models, through agents, through autocomplete — and none of it flows back.

The question isn't whether this is happening. It's what comes next.

Part 2: Open Source After the Extraction

How Entire Works Under the Hood

Thu, 12 Feb 2026 00:00:00 GMT

In part 1, I covered why Entire raised $60M and what problem they're solving. Now let's look at the actual code.

I pointed Claude Code at Entire's open source CLI and asked it to explain how things work. The architecture is more interesting than I expected — they've essentially built a session-aware metadata layer on top of git using nothing but git's own primitives.

The Big Picture

Entire hooks into two things: your AI agent (Claude Code, Gemini CLI) and git itself. The agent hooks capture what's happening during a session. The git hooks capture what the developer commits.

Agent hooks (Claude Code)         Git hooks
  SessionStart                     prepare-commit-msg
  UserPromptSubmit                 post-commit
  Stop                             pre-push
  PreToolUse / PostToolUse
         │                              │
         └──────────┬───────────────────┘
                    │
            ┌───────▼────────┐
            │   Strategy     │
            │                │
            │ SaveChanges()  │
            │ Rewind()       │
            │ Condense()     │
            └───────┬────────┘
                    │
         ┌──────────┴──────────┐
         │                     │
    Shadow branches      Metadata branch
    (local, temp)        (shared, permanent)
    entire/<hash>        entire/checkpoints/v1

How Agent Hooks Get Installed

Running entire enable writes hook entries into .claude/settings.json. Seven hooks, covering the full session lifecycle:

SessionStart/SessionEnd — track session boundaries
UserPromptSubmit — fires before the agent starts working (captures human edits)
Stop — fires after the agent finishes a turn (triggers checkpoint save)
PreToolUse/PostToolUse[Task] — track subagent spawning
PostToolUse[TodoWrite] — capture task state

Each hook is just a shell command: entire hooks claude-code stop. The CLI parses the agent's transcript to extract everything it needs.

The Transcript Is the Source of Truth

This is the key insight. When the Stop hook fires, Claude Code passes two things via stdin: a session_id and a transcript_path. That transcript — the JSONL file where Claude logs every message, tool call, and response — is the single source of truth.

The CLI mines it for:

Modified files — scans for tool_use blocks where the tool is Write, Edit, etc., and extracts the file_path
User prompts — finds type: "user" entries
Token usage — sums input_tokens, output_tokens from response metadata
Summary — grabs the last assistant message

No magic, no APIs. It just reads the same JSONL file that Claude Code writes to disk.

Shadow Branches: Snapshots Without Commits

Here's where it gets clever. When the agent finishes a turn, Entire needs to save a snapshot of the working tree. But it can't commit to your branch — that would mess up your history.

So it creates shadow branches: refs like entire/2b4c177-a5e3f2 that live in your local repo but never touch your working branch.

The name encodes two things:

2b4c177 — first 7 chars of HEAD when the session started
a5e3f2 — hash of the worktree ID (to support git worktree)

The snapshot is built entirely in memory using go-git's plumbing APIs:

Take HEAD's tree (the full repo structure)
Apply the agent's changes (add/remove/modify blobs)
Attach the metadata directory (.entire/metadata/<session-id>/)
Create a commit on the shadow branch

No checkout, no stash, no visible side effects. The user and agent don't even know it happened.

Deduplication is automatic: if the tree hash matches the previous checkpoint, it skips the commit. Git's content-addressable storage means identical files share blobs across checkpoints.

The Condensation Model

Shadow branches are local scratch space. The real metadata lives on entire/checkpoints/v1 — an orphan branch (no common ancestor with your code) that's pushed alongside your regular branches.

The flow:

Agent works → checkpoints saved on shadow branch (local)
You commit → post-commit hook fires
prepare-commit-msg adds a trailer: Entire-Checkpoint: a3b2c4d5e6f7
Shadow branch data gets condensed — copied into the metadata branch
Shadow branch gets cleaned up

The checkpoint ID (a3b2c4d5e6f7) is 6 random bytes, not a git SHA. It's sharded into a directory path on the metadata branch:

entire/checkpoints/v1  (orphan branch)
└── a3/b2c4d5e6f7/
    ├── metadata.json          # summary, attribution, token usage
    ├── 0/
    │   ├── full.jsonl         # complete session transcript
    │   ├── prompt.txt         # user prompts
    │   └── context.md         # generated context
    └── 1/                     # additional sessions if any

That one-line trailer in your commit — Entire-Checkpoint: a3b2c4d5e6f7 — is the bidirectional link. From the commit you find metadata via the sharded path. From the metadata you find the commit by searching for the trailer.

Attribution: Who Wrote What?

This is the piece that matters for engineering leads. Entire tracks line-level code attribution: what percentage was agent-written vs. human-written.

The trick is the UserPromptSubmit hook. Every time you type a new prompt — before the agent starts working — the CLI snapshots the worktree diff against the last checkpoint. This captures exactly what you changed between agent turns.

By commit time, it has:

Agent lines: changes from the last checkpoint's tree
Human added: lines you added between prompts
Human modified: lines you edited in agent-written code
Agent percentage: the ratio

The result is stored in initial_attribution in the metadata:

{
  "agent_lines": 150,
  "human_added": 25,
  "human_modified": 10,
  "agent_percentage": 85.7
}

It even uses a LIFO heuristic for self-modifications — if you add lines then remove lines from the same file, it assumes you're removing your own first, not penalizing the agent's contribution.

Multi-Developer: Conflict-Free by Design

The metadata branch gets pushed during git push (via the pre-push hook). Multiple developers push to the same entire/checkpoints/v1 branch.

This works because checkpoint IDs are random — two developers will essentially never produce the same 12-hex-char ID. Merging is just a tree union: flatten both trees, combine entries, done. No merge conflicts possible.

If a normal push fails (non-fast-forward), the CLI fetches the remote, merges trees, creates a merge commit, and retries.

What's Missing

The architecture is solid engineering, but a few things stood out:

Transcript privacy. Session transcripts (full agent conversations) get pushed to a branch anyone with repo access can read. For private repos, maybe fine. For orgs with varying access levels — that's a problem.

Squash merges break links. If a PR with 5 commits (each with Entire-Checkpoint trailers) gets squash-merged, those trailers disappear. The metadata exists but the bidirectional link from the merged commit is broken.

The metadata branch grows forever. Every session from every developer, including abandoned PRs and throwaway experiments, accumulates on entire/checkpoints/v1. There's an entire clean command for local shadow branches, but no retention policy for the permanent metadata. For a large team over months, that'll bloat.

No PR linkage. The branch name is stored, but there's no PR number or URL. You can't easily ask "show me all sessions related to PR #42."

The Smart Parts

What I genuinely admire:

Git as a free database. Shadow branches store full repo snapshots, but git's content-addressable storage means only changed blobs cost anything. You get atomic snapshots, deduplication, and transport for free.

In-memory tree building. Checkpoints are created through go-git plumbing APIs — no worktree checkout, no stash, nothing visible. Zero disruption to the developer's flow.

Attribution at prompt boundaries. Capturing human edits before the agent contaminates the worktree is the cleanest measurement point possible.

Shadow branch migration. If you rebase or pull (HEAD changes), the shadow branch name automatically updates. Your session continues seamlessly. This handles a common workflow that would otherwise silently break.

So What?

Entire doesn't solve a burning problem today. Most of us are fine with agent-written code landing in our repos without detailed provenance. But the trajectory is clear: as agents write more code, the audit trail becomes essential.

The approach of storing session context alongside code in git — rather than in a separate system — is the right architectural bet. Git is already where your code lives, where your CI runs, where your reviews happen. Adding a metadata layer inside git itself (instead of a SaaS dashboard somewhere) means the context travels with the code.

Whether Entire is the company that turns this into a platform worth $300M is above my pay grade. But the engineering is genuine, the problem is real, and the timing feels right.

I'll be watching.

Agent-Written Code Needs More Than Git

Wed, 11 Feb 2026 00:00:00 GMT

The former GitHub CEO just raised $60M at a $300M valuation for a seed round. For a CLI tool. Let that sink in.

Thomas Dohmke left GitHub and launched Entire, a developer platform built from scratch for the age of AI coding agents. It's the largest seed round in dev tools history.

My first reaction was "that's insane." My second reaction was "wait, I've been solving the same problem with duct tape and hooks."

The Problem Is Real

If you're using AI agents like Claude Code or Gemini CLI daily — and I am — you've already felt it. Git was built for humans writing code. It assumes you know what you changed and why. It assumes your commit messages mean something. It assumes the person who wrote the code will remember what they were thinking.

AI agents break all of that.

When Claude Code rewrites a module for me, the commit message says what happened, but not why. There's no trace of the conversation that led there. No record of the three approaches the agent considered and rejected. No way to know if the prompt was "refactor this for clarity" or "make this 10x faster and I don't care about readability."

The transcript — the actual reasoning behind the code — lives in a terminal session that vanishes when you close the tab.

My Duct Tape Solution

I ran into this a few weeks ago when I wanted to resume a Claude Code session after a reboot. The session was gone, and I had no idea what context the agent had when it made certain decisions.

So I did what any engineer would do: I wrote a hook. A simple Claude Code hook that links each commit to its session ID via a git trailer. Nothing fancy — just enough that I can trace a commit back to the conversation that produced it.

Combined with Mergify's CLI for stacking PRs, it made my workflow usable. But it's duct tape. It doesn't capture the transcript, doesn't track attribution, doesn't handle multi-session work.

Which is exactly the gap Entire is going after.

What Entire Actually Claims to Be

Beyond the buzzwords in the press release, Entire is shipping three things:

Checkpoints — an open source CLI that captures session context (prompts, transcripts, reasoning) alongside every commit, stored in git without polluting your history
A semantic reasoning layer — meant to let multiple AI agents collaborate on the same codebase with shared context
An AI-native UI — designed for agent-to-human collaboration rather than human-to-human

They're not claiming to have a finished product — and they're upfront about it. The Checkpoints CLI is the first concrete thing they've shipped, and it's open source. The rest is where the $60M goes. Fair enough — let's look at what actually exists.

Why $60M for This?

The bet isn't that the current CLI is worth $300M. The bet is that the developer tooling stack needs to be rebuilt for a world where most code is written by agents, and the first company to nail the foundation wins.

Think about it: if 99% of code is agent-written in two years (which is where things are heading), then the code review, debugging, and understanding workflow we have today is fundamentally broken. You can't review AI-written code the same way you review human-written code. You need the context — what was the agent trying to do, what constraints did it have, what alternatives did it consider.

That's a platform opportunity, and $60M is the price of a credible attempt at it. Whether Entire is the one to build it is a different question — but the problem is real and urgent.

My Take

Dohmke knows exactly where GitHub's limits are (he ran it). The investor list — Felicis, Madrona, Olivier Pomel — signals real conviction. And the core insight, that agent context is as important as the code itself, is something I believe in my bones because I've been hacking around it myself.

Their long-term ambition seems to involve moving beyond git. I'm more dubious about that part. Git is unkillable. My bet is that the reality will be hooks and duct tape around git for the next few years — and honestly, that's probably enough. Git's data model bends a lot further than people think before it breaks.

There's a deeper tension, though. Entire's model assumes humans are still in the loop — driving agents, reviewing output, caring about attribution. But that's already not quite how it works. I haven't written a line of code in months. I describe what I want, the agent writes it, I tell it to fix its mistakes, and it does. I'm not a developer anymore — I'm a director.

And the trajectory is obvious: agents won't need directors much longer either. If agents are fully autonomous, who's the audience for commit context and session transcripts? The agent doesn't need to remember what it was thinking — it can just re-derive it. The human who never touched the code doesn't need line-level attribution.

That could go either way for Entire. Maybe full autonomy makes provenance more critical — precisely because no human was involved, you need a machine-readable audit trail. Or maybe it makes the whole problem vanish — agents that manage their own context don't need git hacks to preserve it.

Either way, if you're leading an engineering team right now, you should be thinking about how you'll audit, understand, and trust the code your agents produce — whether there's a human in the loop or not.

Next up, I'll dig into the actual source code and show you how Entire's Checkpoints CLI works under the hood. It's a clever piece of engineering that abuses git internals in ways I genuinely admire.

So I Will Never Write Code Again

Tue, 10 Feb 2026 00:00:00 GMT

A year ago, I thought AI-assisted coding was going to be a nice productivity boost. Generate a Python script with ChatGPT, copy-paste it somewhere, save twenty minutes. I figured that was the next five years: small wins, gradual improvement.

Then last August, I wrote a feature where Copilot did about 80% of the work. I thought: okay, it's getting closer.

Since January, I haven't written a single line of code.

I want to be precise: I've produced a lot of code. More than ever, probably. But I didn't write any of it. I steer. I review. I architect. I don't type.

And I don't feel the urge to go back.

This might sound like grief. I've been coding for 25 years. I wrote C for a window manager, Lisp for Emacs, Python for everything else. For most of my career, coding was a thing that defined me. Losing that should feel like losing a part of myself.

But it doesn't. It feels like relief.

For years, I was frustrated. I had more ideas than I could build. The bottleneck was never thinking, it was typing. Translating architecture into syntax, aligning parentheses, naming variables, fighting linters. The fun was in the solving, not the writing. And now the writing part is handled.

I still enjoy reading code. It's like reading a good book. Understanding how pytest works internally, tracing through a complex system, that remains satisfying. But when the goal is to produce, AI beats everything.

This is actually the second time I've stepped away from code. The first was when I became CEO. That time, it was forced. I didn't choose to stop. I just ran out of hours. There was always one more meeting, one more hire, one more decision that pushed coding to the evening, then to the weekend, then to never.

That was grief. A slow, reluctant surrender.

This time is different. I'm not being pushed away. I'm choosing to work at a higher layer. The same way I once chose Python over C, because life is short and the abstraction was worth it. AI is just the next rung.

The creativity doesn't stop. If anything, it accelerates. You still design systems, still make architectural choices, still think about data models and trade-offs. You just don't spend hours translating those decisions into semicolons. The craft moves up a level, and that's fine.

I know this will be harder for others. My colleague Rémy wrote about whether AI is killing craftsmanship. For engineers who defined themselves by the elegance of their code, by the perfectly named function, by the satisfaction of a clean diff, this shift feels like losing something sacred.

I get it. Writing C was a beautiful puzzle. Lisp was genuinely fun. And I still think learning to code by hand matters, the same way learning assembly helps you understand memory even if you never write it professionally.

But I'm not going to fight a paradigm shift out of nostalgia. The ride was great. The next one looks better.

I think the flow state people mourn isn't gone. It's just moving. Steering AI toward clean architecture, making the right system-level decisions, reviewing output with deep context, that has its own rhythm. The interruptions are still too frequent today (too many permission prompts), but the direction is clear. The flow will come back. It'll just be at a different altitude.

If you're a senior engineer feeling this shift approaching, here's what I'd say: the grief you're expecting might not be grief at all. The bottleneck was never the thinking. It was the typing. And the thinking is still yours.

The Pre-AI Timestamp

Thu, 29 Jan 2026 00:00:00 GMT

I was watching the news this week. A segment about AI-generated fake videos of snowstorms in the US and Russia. Journalists carefully debunking synthetic footage, frame by frame.

AI generated image

I thought: this won’t scale.

Right now, we’re in a strange transitional moment. People can still tell the difference between AI-generated content and reality. We spot the weird hands, the uncanny smoothness, the details that don’t quite land. News organizations debunk fakes. We feel like we’re staying ahead of it.

But this is temporary. In a year or two, AI-generated video will be indistinguishable from real footage. And then what?

Here’s what I think people aren’t grasping: the challenge isn’t “how do we detect AI content?” That’s the 2026 problem. The real challenge is what comes after, when detection becomes impossible.

The only way I know Coldplay is a real band is that they existed before AI did. I have pre-AI memory. I remember when they started. I’ve seen them referenced in media that predates synthetic content. That history is my anchor.

Now imagine a new band starting in 2030. How would I know they’re real? Unless I go to their concert and see them on stage, I can’t. Their music could be generated. Their interviews could be synthetic. Their social media presence could be entirely fabricated. There’s no way to verify.

And when I say I go, I mean me. I can’t trust anyone online that I don’t know personally. There won’t be a way for you to know if you’re talking to a real human via a computerized interface in a few years. Your online friends could be AI for what you know.

This applies to everything. An influencer recommending restaurants. A journalist breaking news. A newsletter you just discovered. If it started after AI became indistinguishable, you have no anchor. You can’t know.

And this is something most people can’t grasp today because they lived in the pre-AI era, and they have this anchor. Future generations won’t have it.

We’ve already lived through a version of this with fake reviews. For the last decade, we’ve learned to distrust Amazon ratings, Yelp scores, app store reviews. We developed heuristics. We looked for patterns.

But that was humans writing fake reviews at a human scale. Now imagine AI generating reviews at a scale we can’t comprehend. Every product, every restaurant, every service flooded with synthetic opinions indistinguishable from real ones. The heuristics break. Trust collapses.

The same thing will happen to media, to news, to social networks, to everything online. AI feels like 1999 all over again — except this time, the divide isn't access. It's whether you can tell what's real.

A lot of trust today is based on consensus. We trust something because many people trust it. But when bots can outnumber people, consensus becomes meaningless. Popularity becomes a metric that anyone can manufacture.

So what’s left?

Physical presence. Meeting someone in person. Attending a concert. Being there.

Real life becomes the last trust anchor. The thing that can’t be faked (at least until humanoid robots become indistinguishable too, but that’s a problem for later).

Here’s what haunts me: in two generations, no one alive will remember what was pre-AI. The generational memory dies. A teenager in 2050 won’t know that The New York Times existed before AI and is therefore trustable because run by humans (I can imagine it’d still be the case). They won’t have the anchor I have. Everything in their world will be post-AI, and nothing online will be verifiable.

They’ll have to assume everything is fake. That’s the default. And building trust from that baseline is something we’ve never had to do before.

I don’t have a solution. But I think we’re in a narrow window where we still remember what “real” meant. That memory is more valuable than we realize.

AI Won’t Kill Juniors. It Will Expose Seniors.

Wed, 21 Jan 2026 00:00:00 GMT

The tech industry has a new consensus: AI will kill junior engineering jobs. Look at any discussion thread, and you’ll find the same narrative. Juniors are doomed. They’ll never learn to code properly. The entry-level pipeline is broken.

I’m not so sure. When I look at junior engineers today, I see people who are used to learning. They came up through boot camps, YouTube tutorials,and constantly shifting frameworks. Adapting is what they do. They might struggle for a year or two, but they’ll figure it out.

The engineers I’m worried about are the senior ones.

Sure, not all of them. But the ones who plateaued at “code craftsman” and never moved up.

I’ve seen it play out already. A standup where someone proudly reports they spent the day fixing a batch of bugs and shipping a couple of pull requests. The rest of the team glances at each other. They’re thinking: *that’s ten minutes of Claude Code. Why did you spend eight hours in your IDE?*

This isn’t new. We’ve seen it before. When bash gave way to Perl. When Java replaced C for most applications. Every paradigm shift leaves some people behind. Maybe 10%, maybe 20%, clinging to the old way because it’s what they know.

But AI is different. The shift is faster. The impact is more massive. And the reach is exponential.

Here’s the pattern I see. When I started programming, you’d learn assembly. Then you’d switch to C because life is short. Then Python, because life is really short. Each jump felt like cheating to the previous generation, and each one freed you to think at a higher level.

AI is the next rung on that ladder. I hope schools are teaching this now: learn to write code by hand first (you need to understand what you’re abstracting), then switch to AI-assisted development. Just like you learned assembly to understand memory, then moved on. Though knowing how slow institutions adapt, I’m not holding my breath.

The engineers who get this are thriving. Staff engineers, principal engineers, people whose job was already 70% architecture, cross-team coordination, and system design. They only coded 30% of the time anyway. Now they use AI to multiply that 30% and have even more impact. For them, AI is a force multiplier on an already leveraged role.

But there’s another group. Senior engineers, five to ten years in, who still think their job is writing code 90% of the time. They never thought deeply about data models. Never cared much about architecture. Never moved toward the work that would make them staff or principal.

Their entire value was "writing proper, clean code that runs well and passes the linter." They never invested in the skills that make a great software engineer — communication, system thinking, judgment.

That value just evaporated.

And here’s what makes it worse: working with AI is fundamentally communication work. The engineers who thrive are the ones who already know how to share context, explain problems to colleagues, and filter signal from noise across teams.

I’ve watched engineers struggle with AI because they won’t invest in communication. They type “fix this bug” without the stack trace, without the constraints, without explaining how production differs from their local setup. They keep the context in their head because explaining feels costly. The result is garbage, and they blame the tool.

What they don’t see: AI compounds. The more context you feed it about your project, the better it gets. But that requires upfront investment in articulation. If you spent your career avoiding that investment with humans, you’ll prevent it with AI too.

I don’t have a clean solution. The engineers who won’t adapt will stagnate. They might find work in industries that are slow to change. But it won’t be a great career. It never is when you’re holding onto the last paradigm.

The engineers at risk aren’t the ones who don’t know enough yet. They’re the ones who stopped growing at the wrong layer. Juniors will climb. The question is whether the seniors stuck in the middle will climb with them.

The Future Is Being Built Elsewhere

Wed, 26 Nov 2025 00:00:00 GMT

I read Pierre Chapuis’ post Inexorable Progress last week, and a line stuck with me:

“You cannot stop the flow of progress. You can only decide to be an innovator, an early adopter, or a laggard.”

He’s right. And if you work in tech in Europe, you feel it every day: in the conversations, in the pace, in the mindset, in the decisions people around you consider “reasonable.”

I live in France. I build a global product. I talk to US companies daily. And honestly?

I’m worried too.

Not because we lack talent. We don’t.

Not because we lack engineers. We don’t.

But because we lack the mental model required to compete in the world we’re entering. And the gap is accelerating.

We Think We’re in the Same Race. We’re Not.

When I look at what’s happening in the US and China in AI, SaaS, robotics, automation… it feels like watching a different timeline.

They’re scaling models that can refactor codebases.

They’re shipping companies that go from idea to revenue in weeks.

They’re pushing robotics into homes.

They’re pouring capital at a pace that dwarfs what Europe raises in a quarter.

Meanwhile, in France:

We think regulation is a moat.
We believe “solving the French market” is a global strategy.
We look at the US and assume “we’ll catch up later.”
We treat AI like a temporary trend we can ignore until it stabilizes.

This isn't a mindset gap. It's a timeline gap. AI feels like 1999 all over again — the behavioral divide between adopters and holdouts is already compounding. And Europe is overwhelmingly on the wrong side.

Europe is acting like it has time. It doesn't.

The Most Dangerous Bias: Thinking France Is the World

When I hear founders say:

“We’ll win the French market first.”

I always think: France is 0.8% of the world’s population.

0.8%.

China is 20× bigger. The US tech market is 10× bigger.

The next wave of software will not be built for 0.8%.

If your plan is to build only for France, culturally, financially, technically, you’ve already chosen to lose.

Not because you’re bad.

But because you’re playing a local game while everyone else is playing planetary-scale chess.

The Mindset Problem Nobody Talks About

Here’s the part that founders and engineers will immediately recognize:

Most people here fundamentally don’t understand ROI, time, capital, or scale.

They understand tasks. They understand constraints. They understand regulation.

But they don’t understand leverage.

They want to “optimize costs” when the problem is growth.

They want to “avoid risk” when the problem is irrelevance.

They want to “comply first” when the problem is competing at all.

This is why hiring is more complex here, why product velocity is slower. Why teams hesitate on AI adoption, just as they did with cloud in 2008.

It’s not a technology gap.

It’s a worldview gap.

We’re Living Like a Rich Country Without Creating Enough Value

This part is uncomfortable, but founders feel it viscerally.

For 50 years, France has lived on increasing debt and the assumption that we can keep funding our lifestyle without producing equivalent value.

But look at our major industries:

Our car industry is fighting Brussels just to be allowed to sell pollution past 2035, not to compete.
Our energy leadership was squandered by 20 years of indecision.
Our tech ecosystem celebrates being five years behind the US, as long as it’s “sovereign.”

If we stop exporting cars, software, tech, heavy industry, how do we pay for everything?

How do we fund innovation? How do we stay competitive?

We don’t.

We shrink.

We tax more.

We lose ground.

And we pretend everything is fine.

Dropping Out of the Race Isn’t Ethical — It’s Surrender

When Pierre wrote:

“If you slow down, you are simply letting those who do not care about these issues in the first place win.”

That hit me hard.

Because this is the mindset I see too often in Europe:

“We shouldn’t build this.”

“We should regulate it.”

“We should wait until we’re sure.”

“We should be cautious.”

Caution is fine.

Except when you’re in a race you didn’t choose but cannot opt out of. You don’t get to be “ethical” by refusing to play.

You just hand the steering wheel of the future to people who don’t share your ethics.

What Founders Should Take Away

I’m not writing this to doomscroll. I’m writing this because founders and engineers need to hear one thing:

Build globally. Don’t wait for permission.

The world is not waiting for Europe to catch up. The next decade will be brutal for anyone playing local games. Whether we like it or not, the next wave of innovation will be:

AI-native
global from day one
capital-efficient
ruthlessly fast
engineered by people who want to win, not just exist

And we can be part of that — if we choose to.

Closing

I love France. I live here. My kids grow up here. But love doesn’t blind me.

I see the same thing Pierre sees:

A continent with world-class talent… and a mindset preventing it from playing the actual game.

I don’t have the solutions. But I see the problems clearly. And as entrepreneurs, our best chance isn’t waiting for a savior.

It’s building, ambitiously, globally, unapologetically, before the gap becomes irreversible. Because the world is moving.

And this time, if we hesitate, we’ll be spectators. Not players.

AI feels like 1999 all over again

Thu, 06 Nov 2025 00:00:00 GMT

Last week, I spent two days with an old friend. We’ve known each other for fifteen years. He’s curious, a bit of a geek, but not “in tech.” He doesn’t use GPT. His wife doesn’t either. They’ve heard of AI the way you hear of a new restaurant: name recognition, no bookings.

We talked, we cooked, we compared notes on work. At some point, I realized we were living on different planets. Not values. Toolchains.

He does great work. But AI just… isn’t part of his day. Meanwhile, I use it constantly: as a writing partner for emails, a sounding board for product decisions, a junior PM, a marketing intern who never sleeps. It’s not magic. It’s just leverage. And it reminds me of when I got internet access twenty-five years ago and people said, “Why would you need that every day?”

Two decades later, we answer that question by reflex, usually from a phone.

I don’t say this to flex. I say it because the gap is already visible.

If I compare my work today to two years ago, I’m doing two to three times more with better output. Same hours. Less context switching. I can hold more of Mergify’s product in my head, ship faster, and still write the marketing we used to split across two people. I wouldn’t claim I replace a whole team (let’s keep our illusions calibrated) but one founder plus AI now feels like one founder plus a sharp apprentice who learns absurdly fast.

And I’m still only scratching the surface. There are tasks I should automate that I haven’t, because of the classic XKCD curve: spending an hour to save a minute. The ROI is real; the overhead is too. It will get smoothed out, like everything else that starts out lumpy.

XKCD 974

What’s striking is not just the productivity jump. It’s the new behavioral divide. Twenty years ago the divide was access: who had broadband and who didn’t. Today the divide is adoption: who’s willing to put these systems in the loop every day, and who keeps them at arm’s length.

Same laptop. Same calendar. Wildly different output.

This isn’t about “AI replacing jobs.” It’s about AI reorganizing work around people who are willing to collaborate with it. The difference between “I don’t see the point” and “this is in my daily loop” already compounds in quiet ways:

The email you write in 7 minutes instead of 27.
The product spec with five explored options instead of two.
The marketing page that results from testing three angles instead of arguing for one.
The code you ship because the blank page wasn’t blank.

Multiply that by days, then by years. That is how careers and companies diverge. And once AI starts creating content at scale, not just assisting — the synthetic wave is already here — the gap widens even faster.

Of course, there are limits. AI isn’t judgment. It won’t hold your ethics, defend your taste, or choose your strategy. You still have to decide what “good” means, define constraints, and call the trade-offs. If you outsource your thinking, you don’t get leverage: you get noise.

But if you keep the steering wheel, the car is very fast.

There’s also a cultural point I didn’t expect: the stigma of using help. Some people still think “real work” means doing everything yourself. Same energy as hand-writing HTML in 2003 to prove you’re serious.

This reminds me of the latest post from Jean de La Rochebrochard where he talked about how French people are all about crafting. No wonder AI adoption is going to be a long road here.

But the craft isn’t in suffering; it’s in outcomes. Tools are honest if your goals are.

I don’t know precisely what the next twenty years look like. I do see the pattern. Early on, new technology looks optional, even irrelevant. Then someone quietly uses it to do three times more with the same time. Then we call it table stakes. The people who adopted early won’t be smarter; they’ll just have trained their reflexes sooner.

If you’re already all-in, you don’t need my sermon. If you’re AI-curious but unconvinced, try this: pick one workflow that hurts: a weekly email, a product spec, a marketing outline. Put an AI in the loop for a week. Not as a demo. As a colleague. Give it context. Ask for alternatives, not answers. Keep the steering wheel.

If after seven days it doesn’t save you time and improve your output, fine: ignore it for another year. But my bet is you’ll feel the old dial-up-to-broadband moment: once you touch the speed, it’s hard to go back.

Back in Toulouse, my friend and I didn’t resolve anything. We just noticed the split. Same age. Same curiosity. Different daily habits. Twenty-five years ago the web felt optional right up until it didn’t. I think we’re there again. The storm isn’t coming. We’re already in the rain. You can stay dry for a while. Or you can learn to dance in it.

Building Features One Prompt at a Time

Tue, 26 Aug 2025 00:00:00 GMT

A few weeks ago, we released a new feature at Mergify: autoqueue.

It automatically adds pull requests into the merge queue when they’re ready. No more custom automation rules, no more fiddling with YAML — it just works, straight from the merge queue settings.

Here’s the kicker: I coded it.

Yes, me. The CEO. The guy who hasn’t touched production code in years. The guy who usually spends his days on calls, not in GitHub.

And I did it in less than an hour a day, over three weeks, with the help of AI.

Why I Even Tried This

I’ve used Copilot casually before (mostly autocomplete in Emacs), but this time I wanted to go all-in.

Why? Curiosity, mostly. And time constraints. As a CEO, I have close to zero time to code, and this feature wasn’t urgent. So I thought: why not see what happens if I vibe-code it with AI?

How It Worked

The way I interacted with Claude 4 via GitHub Copilot was simple: I explained the feature like I’d explain it to my team in a product story. I added some technical constraints (“use unit tests, not functional ones”).

Then I let the AI go.

It just felt like coding blindfolded.

It wrote the code. I tweaked less than 5% of it. Once it was done, I sent it for review. I pasted my coworkers’ review feedback back into it. It rewrote. I guided. It iterated.

Did it nail it on the first try? No. Sometimes it forgot instructions. Sometimes it “lost context” after a few iterations and tried to reinvent the test setup it had already learned. That was frustrating — like explaining to a junior dev, except this junior dev has goldfish memory.

But eventually, it worked. The code was merged. Released. In production. Done.

What Surprised Me

I only changed about 5% of the lines myself.
Nobody on the team noticed it was “AI-coded.”
It handled six years of legacy code surprisingly well.
Two years ago this wouldn’t have been possible — the progress is insane.

What It Means

This isn’t about me playing engineer again for nostalgia. It’s about what’s coming.

The quality and quantity bar is about to rise dramatically. AI isn’t just autocomplete anymore; it’s co-construction.

You can ship faster. You can tackle features you don't fully understand at the start. You can guide at a high level and let the AI grind the details. A few months later, I took this even further — to the point where I stopped writing code entirely.

But it also raises new challenges. For instance:

How do juniors review AI-generated PRs?

How do teams trust code written by something that forgets your instructions after 10 turns?

(That’s probably another blog post.)

For now, though, I’ll just say this:

I vibe-coded a real feature into existence in less than an hour a day.

It felt like cheating. And I’m amazed.

The Em Dash Is Dead

Tue, 05 Aug 2025 00:00:00 GMT

I’ve always loved the em dash. It’s elegant. It’s useful. It lets you breathe in your writing—without having to deal with commas or (God forbid) parentheses.

Ten years ago, I wrote a book. A real book. With my hands.

Serious Python

Over 68,000 words—and 77 beautiful em dashes.

I wasn’t counting then—only recently did I check. You know, just to see how robotic I might’ve accidentally been.

Because now? Now the em dash is a red flag.

A decade ago, it was just a punctuation mark. Today, it’s basically a biometric marker for ChatGPT. Type an em dash on the internet in 2025, and someone will immediately side-eye your prose like you’re a prompt engineer trying to slip one past them.

“Nice try, OpenAI.”

Somehow, without even trying, I joined the ranks of the suspicious. My past self—the one tapping away joyfully, dashing away without care—was unknowingly building a future case against me.

So here I am. A human. Who’s written thousands of human words. Who once thought the em dash was peak form—and now has to ask:

Am I even allowed to use it anymore?

The tragedy is this: AI didn't invent the em dash. We gave it the em dash. We trained it on our books, our blog posts, our essays. We fed it so much em dash-laced content that now it thinks it's just what humans do. And to be fair… it was. It's just one more way AI is reshaping how we communicate — and as social platforms collapse under synthetic content, even punctuation becomes a trust signal.

Now, AI refuses to stop.

You can threaten it, prompt it, scold it—“no more em dashes!”—and two lines later? Bam. Another one. It’s like trying to get your dog to stop barking at squirrels. It hears you. It just doesn’t care.

Meanwhile, actual humans are uninstalling their em dash keyboard shortcuts. Coders are deleting — from their HTML snippets. Writers are rephrasing perfectly good sentences just to avoid looking synthetic.

We didn’t lose a punctuation mark. We lost a friend.

So, if you see an em dash in my writing—don’t panic.

It’s not a bot. It’s just me. Old-school. Nostalgic. Typing with trembling fingers and a tear in my eye.

Still human.

Still grieving.

Still em-dashing.

The Synthetic Wave Is Already Here

Tue, 29 Jul 2025 00:00:00 GMT

Six months ago, I wrote a blog post titled “The Collapse of Social Platforms” At the time, it felt like a distant horizon — something you could see coming if you squinted into the future.

Spotify just made headlines for hosting an AI-generated “band” that racked up over a million plays before anyone realized the artists weren’t real. No humans. No guitars. Just prompts, algorithms, and a good understanding of how to feed the machine what people want to hear.

And that’s just the beginning.

Source

AI is Creating — Not Assisting

Back then, I wrote that we were moving past “AI-assisted” content into “AI-native” creation. At the time, it might have sounded like theory. Now, we’ve entered the Spotify Phase: platforms no longer just recommend content — they create it. They don’t need to wait for artists to upload music. They can fill the catalog themselves.

And they will.

Because the economics are too good, the data feedback loops are too tight, and the audience — most importantly — doesn’t seem to care.

The Illusion of Authenticity is Enough

Spotify didn’t advertise the AI band. It was just another artist profile. People listened. They added songs to playlists. They vibed. It’s only after the fact — after journalists started poking around — that we learned the truth.

And you know what? Most listeners still don’t care.

Which proves my original point: we’re not as attached to the source of content as we think we are. We just want something that feels good, fits our mood, and plays seamlessly into our day. If that comes from a human or an LLM fine-tuned on hit-making formulas… who’s checking?

This is the uncanny shift: content is becoming pure simulation. And for most, it’s indistinguishable from the real thing.

Platforms are Optimizing Away People

Spotify’s move is not an isolated event. It’s the canary in the coal mine for every content platform out there.

Why wait for a podcast to be recorded when you can prompt one into existence?
Why pay creators when you can generate infinite variations?
Why host unpredictable humans when you can manufacture predictable engagement?

From AI-generated OnlyFans personas to YouTube clones to fake influencers on Instagram, we’re entering a phase where content isn’t created by people — it’s created for people by machines pretending to be people.

It’s not a dystopia. It’s just a business decision.

So Where does This Leave Us?

If you’re a creator: The value of “real” is shifting. It may no longer be about production quality — but about human connection. Your face, your voice, your story might become the only proof-of-humanity people care about. Ironically, the more polished your content looks, the more people might question if you made it.

If you're a platform: Congratulations, you're entering the golden age of AI-powered margins. But beware the erosion of trust. Once users start doubting whether anyone on your platform is real, the social glue breaks down fast.

If you’re a user: Good luck. You’re about to be bombarded with synthetic everything. And the biggest risk isn’t being tricked — it’s not caring anymore whether what you’re consuming is real or not.

That’s when the simulation wins.

A Prediction, Revisited

In that original post, I wrote:

“Real life will be the only place you’ll have left to interact with real humans.”

I stand by it — even more today. The value of the human connection will rise in proportion to how rare it becomes online. Coffee with a friend. A live concert. A hand-written letter. These may become the luxury goods of the 2030s.

So yes, the synthetic wave is here. But maybe that’s what we needed — a reason to remember what being human online really means.

Until then: keep your eyes open, your ears sharp, and maybe… spend a little more time offline.

AI Is a Human Interface Nightmare

Tue, 08 Jul 2025 00:00:00 GMT

For the last 80 years, computers have been calculators. Fancy ones, sure — with screens, keyboards, networks. But under the hood, they’re still just deterministic machines. You give them input, and they process it with logic gates and silicon, and they spit out the exact same output every time. That’s the deal. That’s the contract.

And then came AI.

AI doesn’t work like that. At all.

AI — especially large language models — are not deterministic. They’re a soup of probabilities and neural weights. When you talk to an AI, you’re not talking to a computer. You’re talking to something more like a human brain: a machine that guesses, infers, hallucinates, and sometimes nails it. And sometimes doesn’t.

That’s fine. That’s expected. But the problem?

AI still runs on computers.

The interface hasn’t changed. We’re still typing on keyboards, expecting precise answers. We’re still clicking buttons, expecting repeatability. But AI doesn’t think like that. And so the human-AI interface is totally broken.

Ask ChatGPT “What’s the height of the Eiffel Tower?” and you might get the right number. Or not. And when it’s wrong, people freak out — “How can it not know that?” But think about it: the model is 1TB in size. It fits on a USB stick. You really believe all of humanity’s verified data fits in your pocket?

It's not Google. It's not Wikipedia. It's a brain. A tiny, weird, synthetic brain that talks to you via a command-line interface and autocomplete. And if we figure out the interface problem, AI could actually connect the dots in ways humans never could.

That’s the real nightmare: the medium is lying about the message.

We call them “smartphones” because we used to make calls with them — even though calling is now maybe 1% of what we do. The name stuck. And maybe we’ll keep talking to AI through keyboards and chatboxes. But eventually, we’ll need new metaphors. New expectations. New ways to interact.

Because what’s coming isn’t a better calculator.

It’s something else entirely.

Marc Chagall Never Painted That

Tue, 03 Jun 2025 00:00:00 GMT

It was a casual Friday. Nothing special—except I was on kid duty for lunch pickup, a rare detour in my usual routine.

As we strolled home, baguette under one arm, my daughter told me about her morning in class.

They had studied Marc Chagall. Her eyes sparkled as she recounted it, and then she asked if we could go see La Fée Électricité next time we were in Paris.

That name rang a bell, but I had no clue where that was exposed and if it was even in Paris. Painting is not my strong suit. Once home, I did what any responsible parent would do: I picked up my phone from my pocket and Googled it.

La Fée Électricité

The first answer showed that the painting was exhibited in the Musée d’Art Modern de Paris. But I didn’t tell my daughter right away. As I was scrolling on my phone, something didn’t click.

The museum mentioned that this painting was from Raoul Dufy — not Chagal.

I triple-checked on the web and Wikipedia. The result was the same. La Fée Électricité isn’t by Chagall at all. It’s really by Raoul Dufy.

That’s when the realisation hit me. The mistake probably didn’t come from a textbook or even a hasty Wikipedia glance. No, my bet is the teacher asked ChatGPT (or Bard, or whatever the tool of the week is) to prepare her lesson. AI probably hallucinated the answer. And nobody caught it.

We're at this weird moment where many people treat AI like it's a search engine. Or worse: as if it's a source of truth. And when this confidence gets applied at scale — to content, media, music — the synthetic wave is already here, and nobody is fact-checking it.

It’s not. It’s a conversation partner with infinite confidence and a shaky grasp on facts.

This isn’t a rant against AI. I use it daily and wouldn’t go back. But it’s a gentle reminder: if you don’t know how to question what it says—or double-check your sources—it’s easy to teach your whole class wrong facts.

No big deal this time. My kid went back to school in the afternoon after I dared her to ask her teacher if Chagal was really the painter behind La Fée Électricité. She did ask, and the teacher corrected her mistake for the whole class and moved on.

But next time, who knows?

The Collapse of Social Platforms

Tue, 17 Dec 2024 00:00:00 GMT

It’s the end of the year, so I’ll write about something more theoretical that has been on my mind those last few days.

What happens when the line between human and AI content creators vanishes completely? We’re closer to that reality than you might think.

I was out running a few days ago listening to a tech podcast, Silicon Carne. There was an interesting debate around content creation and how platforms like YouTube will kill TV. I’m not sure the root of the talk was that challenging; TV seems already a thing of the past at this stage. But as they started to talk about AI, things started to get interesting.

People often have limited visions of what’s possible, shaped by their beliefs and ideas about what’s acceptable.

Most of the discussion revolved around how AI would be able to create content, how it would be used to help producers and content creators, and what it would mean for platforms and consumers.

Based on that, the debate continued about how much AI would be acceptable in content creation on platforms.

I think this is very short-sighted.

What’s Already Happening

You don’t have to look far to see AI being used in content production; that’s a fact. But it’s still very human-driven and AI-assisted. There are a lot of tech limitations for now that prevent pushing the throttle to the max, but it is certain that those limitations will go away very soon. Look at what OpenAI is building with Sora, and you’ll have a glimpse of the future.

People are already leveraging this tech to move to the next step: creating content, communities, and creators that do not exist in real life. Instagram and OnlyFans are seeing a tsunami of AI-based girls managed by digital pimps. Does it work? It sure does; look at the numbers.

This is where many people start to get confused and want to draw a line based on morale or their beliefs that this model will not be applicable to “regular” content creation.

I believe this is false; it’s already happening.

A Glimpse into the Future

People often argue that having AI-generated content from a content creator would feel inauthentic and that they wouldn’t watch it. I say that this is having a very high opinion of your brain and little faith in the evolution of AI.

What if I told you that MrBeast did not exist? You’d say, of course, he does! Really? How can you know he exists? Did you ever meet him in real life? Did you ever talk to him?

What if, tomorrow, you’d connect to YouTube and see 10 new MrBeast videos with fancy new ideas that’d fit your taste and be very appealing to your brain? They might or might not be AI-generated; in any case, you’d have a good time.

Now, let’s take a step back and imagine having a brand new content creator everyone’s talking about. Nobody heard of them before. You watch the content, and you like it. Does this person really exist, or is it just an AI? How would you ever know? There might be rumors that a friend of a friend met him in a restaurant… but is that the reality?

At some point, there will be no way to know if a content creator is a real person or not. As time passes and technology evolves, it will be close to impossible to distinguish human creation from AI creation — the synthetic wave is already here. This is what most people don't want to believe because it shuffles too much their current reality.

Believe it or not, it’s happening.

How Platform Might Crash

The ability to generate endless streams of AI-driven content will undoubtedly transform platforms like Instagram, YouTube, and LinkedIn. In the short term, the appeal of hyper-tailored, dopamine-driven content may captivate users and drive unprecedented engagement.

But at what cost?

As AI-generated content floods these platforms, the lines between human connection and algorithmic interaction will blur. The authenticity that once set content creators apart—real people sharing real experiences—will be diluted in a sea of indistinguishable, machine-generated personas. Even if platforms introduce measures like “human-verified” badges, the deeper question remains: will people still care? If the content entertains, informs, or inspires, does its origin matter?

This shift could erode one of social media's fundamental purposes: fostering connection. If users begin to see platforms as spaces dominated by machines rather than humans, the sense of community these platforms once provided may crumble. The allure of authentic interaction—the very reason social media exploded in the first place—could fade, leaving behind a world where “social” media is anything but social.

This trend raises profound questions in the broader societal context. Will our online spaces become environments where we primarily engage with algorithms instead of people? As AI infiltrates every email, phone call, and comment, will technology become a tool for connection or a barrier to it?

Perhaps this is where the pendulum swings back to real life. In a world saturated with AI interactions, the simplest moments of human connection—a conversation over coffee, a shared laugh, or a face-to-face debate—might become rare and precious. Paradoxically, as AI dominates the digital realm, it could reignite our desire for genuine human interaction in the physical world.

Until then, the question isn’t whether AI-generated content will dominate—it’s how we, as creators and consumers, will adapt and what we’ll choose to value in an increasingly artificial landscape.

My prediction is that real life will be the only place you’ll have left to interact with real humans.

Until robots take over, of course.

Connecting the Dots with AI

Tue, 06 Aug 2024 00:00:00 GMT

In any conversation, a lot of context can be lost between what you think, what you say, what the listener hears, and what they ultimately understand. This loss of information can lead to miscommunication and inefficiencies. How often have you found yourself confused by someone's words, asking them what they mean, only to hear, "Sorry, I was thinking about this," and finally, the dots connect?

This common scenario underscores AI's potential to revolutionize communication. Imagine a world where your AI assistant, enriched with context from your daily activities, bridges the gap between thoughts and understanding. This could transform the way we interact, making communication more efficient and precise.

Communicating

The Role of AI in Enhancing Communication

In today's world, computers and phones are already tracking many of our communications through platforms like email, Slack, and Teams. Combining all of those platforms captures the full context of conversations — which is why people are starting to use them as sources for RAG (Retrieval-Augmented Generation) in LLM.

Technologies such as Microsoft Recall are going in that direction: recording more information to improve the AI context to make you even more able to understand your world.

AI and LLM can step even further in the direction of communication improvement in the future.

Consider a scenario where Alice needs to tell her colleague Bob to handle a customer request. Instead of Alice trying to guess what context Bob has or lacks, she could give the instruction to her AI assistant rather than communicating with Bob directly. Alice's AI could then communicate with Bob's AI, sharing the necessary context and information, ensuring that Bob receives a complete and clear message. This method of using AIs as proxies eliminates the guesswork and ensures that all relevant details are communicated effectively.

The Vision: AI-Assisted Communication

In the future, AI could be integrated into every piece of communication, from emails to meetings to casual conversations. The potential is immense. Imagine AI assistants transforming messages to match the recipient's preferred communication style and form, embedding the extra context that might be missing to the recipient.

For example, if Alice’s AI knows that Bob prefers visual information, it could transform Alice’s text-based request into an infographic or a visual summary. This ensures that Bob receives the information in the most effective way for him, enhancing understanding and efficiency.

Benefits of AI in Communication

The primary benefit of AI-enhanced communication is the significant improvement in efficiency. Misunderstandings and miscommunications can lead to wasted time and resources. By ensuring that all parties have the necessary context, AI can streamline interactions and reduce the need for clarifications and follow-ups.

Additionally, AI can create a personalized communication experience, tailoring messages to fit the recipient's preferences and needs. This not only improves comprehension but also makes interactions more pleasant and engaging.

Overcoming Challenges

However, implementing AI in communication is not without its challenges. One significant issue is the segregation of information. Just as humans struggle with deciding whether to share certain information, AI will need to learn how to handle sensitive or contextual data appropriately. Current AI systems lack robust role-based access control (RBAC) for context, making it difficult to manage which information can be shared and with whom.

Sandboxing Cycle

Furthermore, while AI can potentially develop its own languages to communicate more efficiently, the practical application of this in everyday communication remains a complex challenge. Security and privacy concerns also need to be addressed, ensuring that sensitive information is protected while still allowing AI to function effectively. I don’t think anyone is actively working on this right now, but it will be a major issue in the future.

Personal Reflections and Future Visions

Reflecting on my own experiences, I've often encountered situations where additional context could have prevented misunderstandings. A really simple example would be planning a lunch meeting without knowing the dietary preferences of your invitee. It might be so obvious to your guest that the restaurant must have vegan options that will not mention it, which can lead to disappointing outcomes if you book a steak house. If AI can provide this context seamlessly, such issues could be avoided.

Looking ahead, I envision AI assistants like Siri evolving to incorporate these advanced communication capabilities. This could extend beyond personal assistants to systems built between products and companies, facilitating smoother interactions and collaborations across different platforms.

The future of AI in communication holds incredible promise. By bridging the gaps in context and understanding, AI has the potential to transform how we interact, making communication more efficient and effective. Of course, getting there requires solving a fundamental problem: AI is still a human interface nightmare, and the way we interact with these systems today is far from what it could be. While challenges remain, the ongoing advancements in AI technology bring us closer to a future where misunderstandings are minimized and every message is clearly understood.