The Job That AI Can't Do (Yet)
What engineering management actually means when code gets cheap.
Here is a number worth sitting with: 75% of engineers are using AI tools, yet most organizations see no measurable improvement in performance.
Not a small improvement. Not a disappointing one. No measurable improvement.
This gap between individual output and organizational outcomes is the most critical management problem of our current moment. And to be clear: it is a management problem, not a tooling one. The tools are working. Something else isn’t.
That something else is the manager’s job.
The floor is moving
For the past two years, the conversation about AI in engineering has been almost entirely about developers. What they can do faster, what they no longer need to do manually, how their role is shifting from writing code to reviewing it, from creating to curating.
That conversation is largely correct. The engineer of today is spending more time orchestrating and less time building foundational pieces from scratch. This is real, it’s accelerating, and it’s not going back.
But here’s what got much less attention: when the nature of technical work changes, the nature of management changes too. Not incrementally or as a side effect, but as a direct consequence.
The manager’s job was always defined in relation to the work the team does. If the work changes shape, the job changes shape. The question is whether the manager notices before the organization does.
The velocity trap
When AI tools land in an engineering team, the first instinct of most managers is to measure more. More deployments, more pull requests, more tickets closed per sprint. The logic seems sound: AI was supposed to make the team faster, so let’s track the speed. This is a trap.
When the cost of generating code drops toward zero, volume of output becomes a misleading signal. A developer with a good prompt and an afternoon can produce more lines of code than they would have written in a week. That doesn’t mean the team is seven times more productive. It might mean the team is seven times more exposed to subtle bugs, architectural drift, and decisions made without context.
The manager who optimizes for throughput in this environment isn’t measuring productivity. They’re measuring noise.
The question that matters is shifting from “how much?” to “how good is the judgment behind this?”. That’s a harder question to operationalize. It requires the manager to be closer to the technical decisions, not further away. It requires understanding not just what was shipped, but why it was shaped the way it was, and whether that shape will hold.
In other words, management by dashboard is finally, definitively, dead
.It probably wasn’t great before either.
The managers who will navigate this well are the ones who redefine what they’re optimizing for before someone else does it for them. Speed is no longer the constraint. Judgment is.
Where will the senior engineers of tomorrow come from?
There is a structural risk building quietly inside engineering organizations, and it has nothing to do with models or compute.
As AI coding assistants take over foundational tasks, the immediate economic justification for hiring junior engineers gets harder to make. Why bring someone in to write boilerplate code that an agent can generate in seconds? The short-term math points toward “senior-only” teams: smaller, more experienced, and exclusively focused on supervising AI output.
The problem is that senior engineers don’t appear fully formed. They were once juniors who learned by writing that exact boilerplate, fixing those mundane bugs, reading messy code, and building context over time. The career ladder exists because each rung prepares you for the next.
Remove the bottom rung, and you don’t get a more efficient organization. You get a talent hollow—an organization that is highly efficient today, but structurally fragile tomorrow.
This is a management problem long before it becomes an HR problem. The manager who sees this early has time to redesign how junior engineers develop in an AI-augmented environment. What replaces “learning by doing” when the “doing” is increasingly handled by an agent?
The answer isn’t obvious, but we need to ask the question now, not when the talent pipeline dries up. Some experiments worth trying:
Reverse the flow: Put junior engineers in charge of evaluating and auditing AI output rather than producing it. This builds critical judgment faster than rote implementation ever did.
Architectural pairing: Pair juniors explicitly with senior engineers on high-level architectural decisions, not just standard code reviews.
Context exposure: Create deliberate exposure to the why behind system design, rather than just the what.
None of this is fully figured out yet. But the manager who ignores it is betting that the pipeline problem will solve itself. It won’t.
The code doesn’t know why it was written that way
Here is something that doesn’t come up enough in AI keynotes: institutional context.
Every non-trivial codebase carries invisible knowledge. Why this table has that specific column. Why the retry logic is capped at three attempts. Why this service was split off from the monolith at that precise point in time. This knowledge lives in a fragile ecosystem—in the heads of senior engineers, in buried Slack threads, or in architecture decision records (ADRs) that may or may not be updated.
When code is written by humans who discussed it, argued about it, and made deliberate trade-offs, some of that context naturally leaks into the codebase—into commit messages, pull request descriptions, and variable naming. It’s imperfect, but it’s there.
When code is generated by an agent responding to a prompt, the context lives in the prompt. Which is usually in someone’s temporary browser tab. Which means, effectively, it doesn’t live anywhere at all.
This is a slow leak, not an explosion. The first generated feature works fine. The fifth works fine. The fifteenth starts to create subtle friction because no one quite remembers why a specific constraint was put there in the first place. By the twenty-fifth feature, you hit a critical incident. The post-mortem eventually reveals that the fatal decision was made informally, in a prompt, six months ago, by an engineer who has since left the company.
The manager’s job here is to act as the institutional memory that the automation process no longer naturally creates. Not by becoming a documentation bureaucrat, but by ensuring context capture is frictionless:
Make “why did we build it this way?” a core question in design reviews.
Treat ADRs not as static artifacts, but as living context documents that agents can eventually ingest to ground their generations.
There is a version of this that becomes a genuine competitive advantage. An organization whose AI agents operate within a rich, explicit context of past decisions will systematically produce better output than one where agents work from scratch every time. You aren’t just preserving knowledge; you’re building operational leverage.
What to develop now
These shifts point toward a different mutation of the engineering manager. Not just a better version of the previous one, but a role redefined.
Here is what that looks like in practice:
Develop judgment about judgment. The new performance metric isn’t “did the team ship?” but “were the decisions behind what shipped sound?” This requires you to be technically engaged enough to distinguish good engineering judgment from fast, automated output. You don’t need to write the code, but you must ask the right questions about it. If your technical depth has atrophied due to a pure focus on process, it’s time to reverse that trend.
Redesign how people grow. Traditional career models assume learning happens through repetitive execution. That world is gone. The manager who figures out how to build systems thinking, context, and judgment in an environment where execution is automated will build a compounding team. The rest will plateau.
Treat context as infrastructure. Institutional knowledge used to be treated as a “nice-to-have” culture item. In an AI-native team, it is a hard constraint on output quality. Building systems to capture and maintain this context—and making it part of your definition of done—is how you build long-term value.
Get comfortable with unresolved ambiguity. AI tools accelerate the rate at which new patterns emerge and old ones become obsolete. If you need absolute certainty before acting, you will perpetually operate from behind. The skill to master now is making sound decisions with incomplete information—and being radically transparent with your team about what is known, what is assumed, and what is genuinely unknown.
None of these concepts are entirely new. Good leaders have always cared about judgment, growth, context, and navigating ambiguity. What is new is the urgency, and the specificity of what these things mean when your team is armed with hyper-powerful automation.
The organizations that win this cycle won’t be the ones that adopted AI tools the fastest. They’ll be the ones whose managers understood exactly what the tools couldn’t do, and built the team around that gap.
The job that AI cannot do is the job of making the team good at using AI well.
That’s your job now.