Inverting the Developer and AI Relationship
Because there are more tokens than human-hours in the day
Originally posted on LinkedIn.
When a ticket is created on our team, an AI agent picks it up by default. A human only gets pulled in if the agent escalates.
How did we get here? In the beginning, there were engineers. Then engineers got AI assistants, and the assistant sat next to the human: you’d pick up a ticket, figure out what was worth delegating, and hand pieces of it to the model. The human was the one actually working the ticket. AI was optimizing the developer’s throughput.
The key shift that we made 3 weeks ago was that by default AI does the work. Engineers spend their time unblocking them: giving them context, shaping the environment, deciding what should trigger an escalation, fixing the cases where they get stuck. Our biggest bottleneck now is code review.
The job of the engineer stops being “do tickets” and starts being “design the conditions under which tickets get done.”
The results so far: 5 engineers running this system ship roughly as much as the other 50 on our engineering team combined.
And this is V1. It’s the dumbest the system will ever be. V2 is already underway. We are building a machine that turns tokens into product delivery capacity. Now the developer is optimizing the AI’s throughput.
If you’re trying to get more out of AI in engineering, the question probably isn’t “how do I delegate better.” It’s “what would it take for the agent to pick up the work by default.”
