There is an uncomfortable truth about most non-tech enterprises: a lot of their software is insanely shit.
I don't mean that the engineers are shit. In many cases, the opposite is true. I've worked with plenty of smart engineers who were perfectly capable of building good software. The problem is that good software is expensive, and for a long time the economics of building it simply didn't make sense.
Think about the incentives inside a large enterprise. You have an internal system that employees have to use every day. The interface is confusing, the workflows are clunky, the codebase is a mess, and everyone knows it needs a serious refactor. Maybe there are thousands of lines of code that should be deleted. Maybe the architecture was designed ten years ago around assumptions that haven't been true for years. Maybe adding a simple feature now takes three weeks because nobody really understands how the thing works anymore.
The engineers know this. The users know this. Everyone complains about it.
And then someone proposes spending three months fixing it.
Why?
What exactly does the business get at the end of those three months?
There probably isn't a new customer. There isn't a new revenue stream. There isn't a shiny feature that can go into a quarterly presentation. Nobody in sales can put the refactor into a demo. The business has simply spent three months making something that already worked—technically speaking—less shit.
From the perspective of an executive looking at a roadmap, that's a difficult proposition to approve.
And in many enterprises, the incentives are even worse than that. The users aren't going anywhere. If you work for a bank, an airline, a government department, an insurance company, or some giant industrial company, you don't get to decide that you're going to use a competitor's internal software instead. You're using whatever system your employer gives you.
So why obsess over UX?
If your customers can leave, product quality matters enormously. If your customers are employees who have no choice, the incentive is very different.
This is one of the reasons I think a lot of terrible enterprise software actually makes sense.
Not to me, necessarily. But within the incentive structure of the organization, it can make perfect sense.
The company needs feature X by September. The team has four engineers. The existing system technically works. There is a giant backlog. Nobody has allocated time for a rewrite. The person responsible for the budget doesn't personally use the software. The person who understands the architecture is worried about hitting the deadline. And the consequences of making the code slightly worse won't show up on anyone's quarterly report.
So you ship it.
Then you ship the next thing.
Then the next thing.
And eventually you have a system that everyone hates.
The hidden cost of software everyone hates
The problem is that "the software technically works" is an incredibly low bar.
A piece of software can work perfectly well and still make thousands of people's lives slightly worse every single day.
A workflow that should take two minutes takes ten. A page that should load instantly takes thirty seconds. An employee has to enter the same information into three different systems. An error message tells them absolutely nothing. A form resets itself for no apparent reason. A button is hidden behind some bizarre legacy navigation. Nobody knows why the process works this way, but changing it feels too risky.
Each individual annoyance is tiny.
The problem is that these tiny annoyances compound.
If 5,000 employees waste ten minutes a day fighting with internal software, that's more than 200,000 hours of human time every year. And even that calculation misses something important: the psychological cost.
People don't just lose ten minutes.
They become frustrated.
They lose momentum. They have to remember workarounds. They start distrusting the systems around them. They learn that doing their job means fighting with the tools provided to them.
And eventually, they start hating the job itself.
We talk endlessly about employee engagement and morale. Companies spend fortunes on offsites, leadership programmes, wellness initiatives and motivational speakers. But there is something deeply absurd about trying to improve employee morale while forcing people to spend eight hours a day using software they hate.
Everyone knows that teams with low morale don't win championships.
We understand this intuitively in sports. Nobody looks at a dysfunctional football team and says, "It's fine, the players are still technically capable of running around."
We care about the environment in which people perform.
Software is part of that environment.
And yet, in many companies, the quality of the software employees use every day is treated as an engineering concern rather than a business concern.
The dinosaur problem
There is also a generational problem here.
A lot of people making technology decisions in large organizations didn't grow up thinking of software as a product. They grew up thinking of it as infrastructure: something the IT department provides so that the business can function.
You don't ask whether the electricity in the office has a delightful user experience.
You don't care whether the database has beautiful onboarding.
You just need it to work.
That mentality made a lot more sense when software was something employees occasionally interacted with. It makes considerably less sense when software is effectively the workplace itself.
But organizational thinking moves slowly.
Companies are enormous machines with long memories. The incentives, processes and mental models that made sense twenty years ago can survive long after the world that created them has disappeared.
And this is where I think something genuinely exciting is happening.
Coding agents are changing the economics of software quality.
The three-month refactor
Imagine that you have a horrible codebase.
For years, the engineering team has known that it should be cleaned up. Everyone has a list of things they would change if they had the time. But the time never comes.
The reason is not necessarily that management doesn't care. The reason is that the opportunity cost is enormous.
A traditional refactor might require one or two engineers to spend weeks or months understanding the existing system, designing the changes, implementing them, testing everything, fixing regressions and gradually migrating the code.
Three months is a long time.
And three months of engineering time is expensive.
Now imagine that instead of taking three months, an extremely capable coding agent can do a large part of the work in a day.
Not every refactor, obviously. Not every codebase. And certainly not without human oversight, testing and engineering judgement.
But the economic threshold has changed.
Something that previously required a three-month business case might now require an afternoon.
That is a completely different proposition.
AI makes quality economically viable
This is the part of AI-assisted programming that excites me much more than the promise of simply writing code faster.
I don't think the most interesting consequence of coding agents is that developers can produce more lines of code.
Frankly, the world already has enough lines of code.
The interesting consequence is that code quality itself can become economically viable in places where it wasn't before.
For a long time, software engineering involved an uncomfortable tradeoff. You could build the right thing, properly, but it would take longer. Or you could ship something that was good enough and move on.
There were always engineers arguing for the former, and there were always business pressures pushing toward the latter.
Sometimes the business won for perfectly rational reasons.
But what happens when the cost of doing the right thing falls by an order of magnitude?
Suddenly, the argument changes.
The refactor doesn't have to compete with the feature roadmap in the same way. The cleanup doesn't necessarily require taking a team off delivery for a quarter. The ugly piece of legacy code doesn't have to remain ugly simply because nobody can justify spending six weeks fixing it.
And perhaps most importantly, engineers don't have to spend as much time convincing people that quality matters.
This is a subtle but profound shift.
In the old world, if I wanted to spend three months improving a codebase, I had to convince someone that three months of engineering time was worth spending on something that users might not immediately notice.
I needed a business case.
I needed projections about future productivity.
I needed to explain how technical debt compounds.
I needed to convince someone to spend money today to avoid costs that might appear six months or two years from now.
That's hard.
But if the same improvement can be done in eight hours with an agent, the conversation becomes very different.
Maybe I don't need a business case.
Maybe I can just do it.
The software we already have
This is why I think the biggest impact of coding agents might not be that they allow us to build more software.
We already build an enormous amount of software.
It might be that they finally allow us to make the software we already have good.
There are millions of applications sitting inside organizations that are not fundamentally broken. They are just mediocre. They are slow, awkward, overcomplicated, badly structured and unpleasant to maintain.
And for years, that was the equilibrium.
The software was bad, but fixing it was too expensive.
So everyone learned to live with it.
Engineers learned the workarounds. Employees learned the weird workflows. Managers learned to accept the complaints. Executives learned that the system "worked."
The organization adapted itself around the limitations of its software.
That is a very strange thing when you step back and look at it.
We built computers to make people more productive, and then spent decades making people adapt their behaviour to accommodate the computers.
Coding agents could start reversing that relationship.
If an engineer can take a horrible codebase and dramatically improve it without blowing up the delivery schedule, the default assumption no longer has to be that technical debt is permanent.
Maybe the ugly code doesn't have to stay.
Maybe the terrible internal tool can actually become pleasant.
Maybe the three-month refactor becomes an afternoon.
And if that happens at scale, the consequences aren't just technical.
They are organizational.
Because when the software gets better, the people using it get better tools. When people have better tools, they waste less time. They get less frustrated. They can move faster. They spend less mental energy fighting the system and more energy doing the thing the system was supposed to help them do.
Good software isn't just a technical luxury.
It is part of the working environment.
And for the first time, we may be entering a world where making it good is cheap enough that even enterprises have less of an excuse not to.
Maybe the future of coding agents isn't that we'll write ten times as much code.
Maybe it's that we finally get to stop writing quite so much shit code.
Top comments (1)
The incentive reading is what makes this different from the usual "enterprise software is bad" post: nobody is paid to make something less bad for people who can't leave. And the number you put on it is the honest one — the refactor doesn't compete on quality, it competes on the quarter.
Where I'd push slightly: an agent made the writing cheap, but the expensive half of a refactor was never typing the new version, it was owning the regression surface afterwards. Three months to a day on the diff still leaves someone accountable for the behaviour that changed at 2am. My own experience is that the constraint moved from "can we afford to do it" to "can we afford to review it", which is a better problem to have but still a problem. Does that match what you see at the places you've worked?