For enterprises, the most important consequence of AI writing code is not cheaper software.

It’s the incoming dispersion of AI talent, and what that enables for non-tech businesses.

Before AI could write good code, the economics of software development forced engineering to exist as a separate discipline. The people who needed software were the operators; they had process knowledge, relationships, domain understanding, and a thousand small reasons that made them valuable in their messy domain. The engineers who delivered the software were far removed, in their own working conditions.

Whatever the operators could successfully communicate to the engineers was what got made. The requirements flowed through budgets, procurement and leadership, sales, product managers, designers, and finally reached the developer as a list of features.

The separation was practical.

Good software was expensive to build. Every iteration cost enough that organizations had to decide what was worth building before they really knew whether it would work. Custom software was supposed to solve the problem by fitting the organization more closely. But it had the same economic constraint.

Most companies could afford to commission a project, or procure a SaaS platform. They could not afford an indefinite process of iterating to improve the software outcomes.

This is exactly why digital transformation projects were enormously unsuccessful and large amounts of enterprise software went to waste.

Consumer software has always had a brutal consequence: if people don’t use it, it dies. Enterprise software had more room to be bad.

The buyer often wasn’t the user. The software rarely had iterations. When it did, the feedback loops for SaaS were dominated by the vocal players in the market, i.e. not most people. The adoption and waste problems were bad enough, and large enough that they spawned their own industries. Companies that would provide digital transformation, training, and upskilling services.

This isn’t because the software was inherently bad. It’s because users are complicated. Even ChatGPT and the like, as powerful as they are, rarely get used to their full potential. People use it as an emotional crutch more than they do for productivity.

So the changing software economics should be an incentive for people to right the wrongs of the past, not simply own the problems or add to them. And the highest leverage decision you can make is where you allow software engineering judgement to develop. Not ship the fastest, cheapest software. Ship the software that actually works for you.

The obvious response to cheaper software is to ask your existing engineering team to produce more of it. I think that misses the larger opportunity.

Move the engineers.

Put software engineers into operating roles. Make them responsible for procurement, logistics, sales operations, project delivery, finance, wherever there is complicated work being done by people.

And importantly, make them do the actual job.

Let them inherit the ugly spreadsheet. Let them deal with the supplier who never responds on time. Let them discover why the team ignores one field in the CRM, why an approval that should take a day takes a week, and why the official process bears only a passing resemblance to how good operators actually get things done.

Then let them build.

Every ugly interface becomes personal. Every inefficient process becomes annoying. Every fragile AI workflow becomes something they have to live with themselves. The engineer is no longer trying to understand someone else’s problem well enough to encode it. They are developing the judgement required to decide what should exist in the first place.

And the software gets something enterprise software has historically struggled enormously to acquire: an extremely tight feedback loop with reality.

There’s an old observation in software called Conway’s Law: organizations tend to build systems that reflect their own communication structures. Imagine a system built when the communication loop shrinks and is entirely internal to one person, or a very small team.

The operator does the work, encounters the problem, builds something, uses it, and improves it.

There is less translation of ideas. Less to misunderstand. Less bureaucracy to go through before changes are approved.

The software becomes narrower, more personal and more specific to the reality of the job.

You can see the same changing economics being interpreted very differently in Silicon Valley.

YC is increasingly interested in companies that use AI to deliver the service itself. Sequoia has argued that enormous technology companies could emerge disguised as services businesses. Across accounting, legal, healthcare, logistics and other traditionally human-heavy industries, the ambition is moving beyond selling software to the people doing the work.

Instead of selling an accounting firm better software, become the accounting firm. Instead of providing another system of record to a service business, use AI and software to deliver what its customers were buying in the first place.

Poppycock. Nay, I say.

There is another way this could go.

Incumbents already possess much of what these new companies need to spend years acquiring.

They have customers. Relationships. Distribution. Domain knowledge. Operating history. Employees with judgement. Thousands of edge cases discovered through actually doing the work.

Most importantly, they already have a process that produces something valuable.

It may be inefficient. It may involve too many people, spreadsheets, emails, meetings and pieces of software. But somewhere inside that mess is an organization capable of repeatedly producing an outcome somebody is willing to pay for.

That is enormously valuable raw material.

If software companies can grow outward into services, there is no reason service and industrial companies cannot grow inward toward technology.

I suspect this creates a particularly valuable kind of employee over the next few years.

Someone capable of becoming genuinely good at the work, while possessing enough engineering judgement to continuously reshape the environment in which that work happens.

They understand what software can do, and can decide what minimal solution they need to meet their goals. And when those solutions are built, they know how to shape the underlying infrastructure to make sure the solutions compound. That could mean, for example with agents, knowing which data to capture to ensure reliable, cost-effective execution.

That is a very different conception of being “AI-native” from giving every employee a copilot.

Eventually, I suspect even this distinction starts disappearing.

Small, self-directed pieces of software will become part of a high performer’s toolkit in much the same way spreadsheets, presentations and search became part of knowledge work. People will bring their own software with them.

A great procurement operator might arrive with sourcing workflows they have built and refined over years. A salesperson might have their own research and account-planning systems. A project manager might have small applications built around how they personally track dependencies and risk.

Their portfolio will contain not only things they have done, but tools they have made themselves better at doing.

“The future is already here, it’s just not very evenly distributed.”

We can see some of that future today. But the talent capable of working this way is still scarce enough to be unusually valuable.

Which makes the opportunity right now fairly simple.

Don’t just ask how quickly your engineering team can ship software. Ask where inside your organization you want software engineering judgement to develop. Then put builders inside the work.