Everyone at Ship 26 Was Shipping Agents. The Slide That Stuck With Me Was a Flat Line.
I spent last afternoon/evening at Vercel's Ship 26 in Berlin. A dark room, a few hundred developers, and one message repeated from every angle: software is agentic now. Agents deploy, agents build agents, agents watch production.
And the numbers back it up. Over half of Vercel's deploys now come from coding agents — up 17x in six months. One talk put it differently: ~60% of enterprise commits are now written by agents. Building is, more or less, solved.
The slide that stuck with me wasn't about agents at all.
In one of the engineering talks, a team put up their own internal data on rolling out AI tools. The capability line went straight up — exactly what you'd expect. The results line didn't. It rose a little, then flattened and stalled around a 40% productivity gain. They'd labeled it themselves, in big letters: "THE PLATEAU." A dotted line showed where they'd be if it had scaled linearly — way up and to the right. The gap between those two lines is the entire thing I'm building.
It's the same shape as the METR study last year: experienced devs were given AI tools, expected to go faster, and measured themselves 19% slower. More capability did not become more shipped.
Here's the part nobody on stage said out loud, because it doesn't sell infrastructure. When agents write half your code, building stops being the hard part — and the bottleneck doesn't disappear, it moves up a layer. To the part agents can't do for you: finishing. Owning it. Showing up on Day 4 when the novelty's gone and nobody's watching.
The most advanced agent stack in the room is architected around a human gate — production changes wait for a human to approve them. Vercel keeps a human in the loop on production. Almost nobody keeps one on themselves.
A dashboard doesn't fix this. It shows you activity; it doesn't notice your absence. AI tracks. A human reads.
If your projects keep dying at the same point — and it's usually the same point, your point — more agents won't fix it. I built a free 7-question diagnostic that names where you stop: mvpbuilder.io/ship-readiness?utm_source=indiehackers&utm_medium=social&utm_campaign=ship-readiness&utm_content=ship26&lang=en
Building in public. Day 139.
The idea that stuck with me wasn't the productivity numbers—it was that removing one bottleneck doesn't eliminate constraints, it just exposes the next one.
That's an easy thing to miss when a technology suddenly makes one part of the workflow dramatically faster.
This is exactly the thread I was pulling on, but you tied it off cleaner — that's Goldratt's Theory of Constraints, basically. Worth being precise about the move, though: "building" was a real bottleneck — a capacity constraint, limited by dev time and skill. AI didn't just speed that up, it more or less removed the ceiling. But the thing it exposed underneath isn't a bottleneck at all — no resource is maxed out, models and tooling and time are all suddenly abundant.
What's left limiting the system is follow-through, and that's a behavioral constraint, not a capacity one. That's why the curve plateaus around 40% even as capability goes vertical, and why it squares with the METR finding: the constraint moved from "can I build this" to "do I actually carry it across the line" — and you can't add capacity to fix that. A faster model is solving a bottleneck that no longer exists. The machine can track that something slipped; noticing it and caring is still a human job. Which is where the real question sits for me: is that next constraint even a tooling problem, or is it structurally a people thing?
That's exactly what I was getting at.
Reading your reply, I found myself thinking about one implication of that distinction that I don't think is obvious at first glance.
It's probably too much to unpack properly in a thread.
Happy to explain what I mean if it's useful. What's the best email to reach you on?
Honestly, I'd keep it right here — half-formed is fine. Whatever the implication is, it's probably more useful to the next person reading this thread than it is to me in private, and you clearly write well enough in a comment box to land it. Throw it out, even rough — I'd rather think it through in the open.
I think the implication is that if the next constraint is genuinely behavioral rather than computational, then AI companies may eventually discover they're no longer primarily competing in intelligence.
They're competing in behavior change.
Those sound similar, but I don't think they lead to the same product decisions over time.
That's the part I've been thinking about.
Exactly — and I think the divergence is even sharper than "different product decisions." It's almost opposite directions.
If you're competing in intelligence, every roadmap arrow points the same way: more capability, more autonomy, do more of the work for the user. Success looks like the user doing less.
But you can't change behavior by doing the work for someone. Behavior change runs on the person actually doing the reps — showing up on day 9, day 14, day 22. So a product genuinely competing in behavior change sometimes has to do the un-AI-like thing: keep friction in, keep a human in the loop, make you show up instead of doing it for you.
Which is why I don't think the intelligence-first companies can just pivot once they notice. Their whole optimization target points away from it. A lab shipping "the model does even more" is, at the strategy level, the same move as an agentic coder generating a bigger pile of half-built repos — it widens the exact gap they'd need to close.
Behavior change isn't a weaker form of intelligence. It's a different discipline — closer to what works in health and habit products than in a model lab. That's the part I keep circling too.
I think we're circling the same question from different angles.
The interesting part, to me, isn't whether AI can change behavior. It's how a company decides whether it's actually building an intelligence product or a behavior-change product before its roadmap quietly commits it to one.
I don't think I can do that justice in a thread.
If you're interested, what's the best email to reach you on? I think it'd make for a much more useful discussion there.