Agentic development
Take with cautionSpeculation from one seat in one company. Your line may sit somewhere else.
Engineers got five times faster and the company didn't. Both are true, and the reason is a line nobody moved.
A VP said it in a room full of engineers, not unkindly:
With all the AI enhancement, it doesn't seem like we're doing more. Maybe we're even slower than when we were thirty people.We are about five hundred now.
I answered for my side. I have never been more productive. I work fewer hours than I did at thirty people, agents run for me around the clock, and I ship more than I have ever shipped.
Both of us were telling the truth. This note is about the gap between the two.
A normal week
I can run six agents in parallel and keep all of them honest. Product work fills four. Not because product is slow at writing, but because only four things are decided enough to start, and the fifth is blocked on the fourth.
That is burned capacity. Not idle, just unaccounted. From the top it looks like the engineers are busy and the roadmap isn't moving any faster, and that is exactly what is happening.
Notice the instinct behind the two spare agents. An engineer now prefers to start before the feature is locked, because an update costs minutes and waiting costs more than guessing. Product's instinct is still to lock before starting. Both instincts were correct when a feature took a week to build. Only one of them still is.
Why thirty felt faster
At thirty people, the person who decided what to build was usually the person who built it, or sat next to them. There was no queue between a decision and the work.
At five hundred there is one: a spec, an alignment meeting, a review, a sign-off, a "let's lock this before we start." None of that was the slow part when the build itself took a week. The queue was shorter than the build, so it hid inside it.
Then the build collapsed and the queue didn't. Now the queue is the whole wait. The company is as fast as its decisions, and decisions are still made the way they were made at thirty people: in rooms, one at a time, expected to be final.
The line
Take any product decision and split it. Above: what problem, for whom, what outcome, by when. Below: which flow, which fields, what the empty state says, what happens on the edge case, how it looks on a phone. The top half is short and hard. The bottom half is endless and, item by item, easy.
Today product owns both halves, and the meetings are almost all about the bottom half, because that is where the volume is and every item needs someone to say yes. The line between "product decides" and "engineering builds" sits very low.
Move it up. Product keeps the top half and stops pretending the bottom half can be settled in a room. The bottom half goes to people who resolve specifics the way engineers already resolve technical specifics: build it, look at it, change it if it's wrong. An agent makes a wrong specific cost twenty minutes. A meeting about the same specific costs six people an hour, and still produces a guess.
At thirty people the line was already high. Nobody drew it; the builder simply owned the specifics. Growth pushed it down, one process at a time, and each push was reasonable. Agents are the reason to push it back.
Who takes the bottom half
Not product managers who learn to prompt. Watching six agents and knowing which one is quietly going wrong is engineering judgment, and it doesn't arrive with a tool.
It's engineers with good enough product judgment, named, and given the bottom half explicitly. Most teams already have them. They're the ones whose two spare agents produce things people later ask for. The change is that those two agents become a budget instead of a leak: counted, pointed at the specifics of decisions the roadmap already made, visible from the top.
Product management doesn't go away. The top half of the line is a whole job, and with the bottom half gone it is a harder one: fewer decisions, each of them load-bearing, none of them hidden behind forty smaller ones.
Back to the room
The VP wasn't wrong about the output. The org isn't slower because engineers got worse, and it isn't slower despite the agents. It is slower relative to its engineers, who now wait on a structure built for the week-long feature. The structure prices specifics as expensive. They aren't anymore. Move the line.
Comments