The right question before building an agent isn't which model to use. It's how much of the problem you can remove first.
Measuring agent productivity by counting lines of code looks at the wrong side of the problem. Before adding an agent I ask what the system would look like with less, because every agent is one more piece to maintain and one more place things break quietly.
View on LinkedInThis week Simon Willison reignited the debate on how to measure the productivity of agents that write code: whether to count lines or not. That looks at the wrong side of the problem.
Every time I evaluate whether to build a system of agents, the first question isn't technical. It's whether the problem can disappear with less, before I add anything at all.
Every agent is a piece I have to maintain
An extra agent is something I have to keep alive. A model that can change behavior between one version and the next. One more point where something can break without anyone noticing right away.
Lines say nothing about the quality of a system. The question that matters is different: how much complexity did you remove before you added more.
Plain code over agents, more than once
I've learned this repeatedly, picking a few lines of plain code over a system of agents and getting the same result with far less to maintain.
That isn't laziness. It's the same discipline I apply to a design system, to a workflow, to a team. Simplify what's there first, then automate what actually remains.
A complex system isn't a sign of maturity. Often it's just the sign that nobody stopped to ask whether it was needed.
Takeaway
Complexity you don't add costs nothing to maintain. Before reaching for an agent, remove the steps, the handoffs, and the exceptions that made the work look automatable in the first place. What survives that pass is worth automating, and it's usually smaller than what you started with.
The next time you think about building an agent to automate something: how much of that problem can you remove before you even start?
