You're Not a 10x Engineer, You're an AI Middle Manager

Everyone with a Gemini, Codex or Claude Code subscription is taking the liberty of considering themselves a 10x engineer. They feel empowered to do so because their raw output has increased tremendously. More code, more commits, more pull requests - surely that means more value.

Ironically, for years the software world gawked at the idea of measuring an engineer's worth by lines of code. Yet overnight, high token spend has become a badge of pride, and the sheer volume of generated code a fashionable indicator of productivity. People are churning out ten times the output, some of which even compiles into working software - in many cases, as much as ten percent. Do the math.

That said, I've been noticing a very interesting divide forming. It isn't between those who use AI and those who don't. It's between two entirely different ways of using it: as an extraordinarily capable individual, or as an AI middle manager.

---

To understand this divide, we have to get the language right. It is dangerously easy to slip into the generic framing that enables the problem in the first place - specifically, the habit of calling an AI-assisted developer a "team of one."

Think of it in terms of superhuman strength. A person who can lift a car is not a "team of one" in terms of physical power; they are simply one extremely strong person. AI coding tools don't create a team. They take a capable individual and make them extraordinarily capable, amplifying the speed at which they can drive implementations and exercise their own thinking.

These individuals steer AI at a senior engineering level. They make sharp architectural decisions. They think in high-level abstractions while remaining strict and diligent about the quality and thoughtfulness of the code being written. They are building software the way they always have - with the same rigor and thoughtfulness - but in timeframes that used to be unimaginable. And the burnout that would have accompanied this pace simply doesn't arrive, because the mechanical cost of sustaining that intensity is what the tools eliminate.

They force the tools to follow conventions to the letter. They don't shy away from extra research, and they generate the comprehensive documentation that used to be such a burden. This is what it actually looks like to be hyper-productive. Not a team. A single, highly leveraged mind.

---

The flip side of this dynamic is the AI middle manager.

This archetype is the one who actually fits the "team" framing - except they aren't a team of one. They are running a team of three, five, eight, or ten, where most of the members happen to be LLMs. And without proper steering, guidance, and close collaboration, LLMs produce the results of a junior contributor - regardless of how many you have.

The AI middle manager ships that mediocrity. It isn't that they are completely hands-off or blindly accepting whatever the AI spits out. They might review some code. They might make a decision or two. But their posture is fundamentally managerial.

They are trying to manage the team instead of being the engineer.

They think in terms of product requirements, passing off the core decisions on implementation, design, and code quality to the AI. They operate like a technical project manager, allocating tasks and waiting for delivery. When the feature is finally built, they exercise a bit of discretion or tweaking on the final output - usually in the form of, "This doesn't look right," or "Can you just tweak that?" or "Great, now go write comprehensive tests."

But because they didn't critically steer the tools during the building process, or collaborate on the architecture before it was generated, their final tweaks are just cosmetic adjustments to a deeply flawed and unthought-out foundation. They expect a fleet of LLMs to act as the senior engineer, while they simply review the results.

This is not a 10x engineer. This is someone managing a workflow that delivers average, and often unreliable, engineering results. The telltale sign is what happens when things go wrong. The middle manager doesn't say, "I made a bad call." They say, "I need to tweak this with Codex," or "Claude didn't follow that convention," or "There really should be an agent skill for this so next time it gets it right." The tools are always the subject of their sentences. Never themselves.

---

This distinction matters because it should inform a very practical business decision: which archetype do you actually need?

If you are a startup making foundational decisions about your systems - the kind of decisions on top of which scale, growth, and compounding value get realized - you need the 10x engineer. You need someone who can lay that foundation with the rigor and architectural thinking that makes everything built on top of it durable. The tools let that person operate at a pace that used to require a team, but the thinking is still theirs, and at this stage the thinking is everything.

If you are a more mature product where those decisions have already been well made, where good guardrails are in place, and where certain parts of the system just need a bit of attention with the occasional tweak or support request - then maybe the AI middle manager is a perfectly reasonable hire. They can address the need while significantly reducing payroll spend.

The point is not that one is always right and the other always wrong. The point is that they are fundamentally different, and confusing the two is where things go sideways.