Imagine AI didn't exist.
A software company hires a new engineer who turns out to be unbelievably productive.
They generate thousands of lines of code every day. Features that previously took weeks are delivered in hours. Pull requests are flying in. Management has never seen anything like it.
But there's a problem.
Much of the code is poorly structured, duplicates existing functionality, introduces subtle bugs and creates technical debt. The engineer doesn't really understand the wider architecture or the long-term consequences of their decisions.
The senior developers are constantly reviewing, correcting and cleaning up after them.
So here's the question. What would happen to this engineer?
I suspect most experienced engineering teams would want them gone.
Not because they're threatened by their productivity, but because they're creating more work than they're solving. Their output is becoming a liability.
But here's where it gets interesting.
Ask the engineering team about this employee and they'll tell you they're damaging the codebase.
Ask management, HR or the people looking at productivity reports and they'll tell you this is the most productive engineer they've ever hired.
Why?
Because they're measuring completely different things.
Management sees features delivered faster, more tickets closed, more pull requests merged and lower apparent development costs.
The engineers see the bugs, the architectural mistakes, the maintenance burden and the technical debt accumulating beneath the surface.
One group sees unprecedented productivity. The other sees an engineering disaster unfolding.
Now imagine the company has to make redundancies.
Who looks more valuable on paper? The senior engineers taking time to carefully design, review and maintain the software, or the new engineer apparently producing ten times as much?
Now change one detail.
That new engineer isn't human.
It's AI.
And suddenly, this hypothetical situation starts looking remarkably familiar.
The people making the financial decisions aren't necessarily the people who understand the technical consequences.
And the people who do understand those consequences are increasingly being asked to justify their existence against a productivity metric that doesn't measure what they actually do.
We've spent decades explaining that lines of code are not a measure of engineering productivity.
Yet here we are, potentially restructuring an entire industry around the idea that producing more code means producing better software.
The real danger isn't that AI writes code faster than humans. It's that the people making the decisions might not understand the difference between generating code and engineering software.
Or maybe the solution is for developers to truly step aside. Let management enter the prompts and make the decisions, and see how it goes. Who knows?
Because right now, reviewing AI code isn't a manageable task. There's simply too much of it. Maybe a really good automated testing system that proves it all works is enough. That seems to be where the value is moving.