AI Agents Are the Most Expensive Junior Devs You'll Ever Hire

Give a junior a ticket that says users can be admins, admins see an extra settings page. You get a UserRoleManager with role hierarchy, permission inheritance, an audit log, and four unused extension points. The actual requirement was one if-statement.

Now give the same ticket to an AI agent. You get the same UserRoleManager, in thirty seconds instead of three days. The reflex is identical. The cost structure is worse.

Junior developers grow out of it. Agents do not. They will produce the same over-engineered shape on every PR until somebody adds a review step that catches it.

Why agents default to over-engineering

Models are trained on code that exists. Most public code is not minimal. It is the surviving output of teams that abstracted early, added extension points, and built for requirements that may never arrive. The agent has seen more of that code than the alternative.

So when the agent sees users can be admins, it reaches for the abstraction it has seen a thousand times. It does not ask: is there a current requirement for five roles? Is there a ticket requesting an audit log? Has anyone mentioned permission inheritance in a planning doc?

The agent is not guessing randomly. It is pattern-matching to the median of public code. The median of public code is over-engineered for your actual ticket.

The actual invoice

A junior's UserRoleManager costs two to three days of build, plus code review, plus maintenance for as long as it lives in the codebase.

An agent's UserRoleManager costs you one prompt, plus the same code review, plus the same maintenance. The build cost dropped to near zero. The review cost stayed the same. The maintenance cost stayed the same.

So the leverage flipped. Before AI, you accepted some over-engineering because the alternative was rewriting a junior's three-day investment. With AI, the build cost is gone. The only thing keeping the abstraction in your codebase is that nobody treats agent output like junior output.

What changes in review

The fix is a review checklist that asks the same questions you would ask a junior, but with less patience.

Does this abstraction satisfy a requirement in a current ticket? If the answer is in case we need it later, reject it. Does this generic interface have at least two callers today? If not, collapse it. Does this file have unrelated concerns that change at different rates? If yes, that is the only valid reason to split.

Apply this to every agent PR. The first week, you will reject a lot. By the second week, the rejection pattern leaks back into your prompts. The agent starts producing the simpler version, because the simpler version is the one that gets through review.

When to let agents over-build

There is one exception. In early exploration, when you do not yet know the requirements, letting an agent produce a thick first cut can be useful. You learn faster from concrete code than from a blank file.

The discipline is to delete it. The exploration artifact is not the implementation. If it survives into the real codebase, you have shipped a junior's three-day daydream at agent speed.

The actual decision

You are not deciding whether to use AI agents. You already did. You are deciding whether to review their output the way you review junior output, or to keep shipping abstractions nobody asked for.