Where Do All the Software Engineers Go?

I’ve been thinking quite a bit lately about what happens to software engineers as AI continues to get better at writing code. Most of the conversation seems to revolve around how many of them are going to lose their jobs, and I certainly understand why. When you see what these tools are already capable of doing, it’s hard to imagine that we’re going to need the same number of people writing code five or ten years from now.

But I’ve been developing a slightly different theory. What if a significant portion of those engineers don’t actually disappear from the workforce? What if they end up working for organizations that would have never considered hiring a software engineer before?

According to the Bureau of Labor Statistics, there were approximately 1.7 million software developers employed in the United States in 2025. When you include related occupations like programmers and testers, we’re talking about well over two million people whose careers revolve around creating software.

And if you look at where those people work, there’s a pretty interesting pattern. About 29% of software developers are employed in computer systems design and related services, with another 10% working for software publishers. There are plenty of engineers working in other industries, but the profession has historically been concentrated in organizations that either develop software as a core part of their business or are large enough to justify employing their own development teams.

That makes sense. Software development has traditionally been expensive, and most businesses simply couldn’t justify that kind of investment.

I think AI is about to change that equation considerably, and it could have some pretty significant implications for where software engineers end up working.

Think about a school district for a minute. It’s probably running dozens of different software applications for everything from student records and scheduling to transportation, payroll, facilities, and communication. Some of those systems probably work pretty well. Others are probably a complete pain in the ass.

And I can almost guarantee there are employees who spend a ridiculous amount of time moving information between systems, maintaining spreadsheets, and working around limitations in software that was never designed specifically for how their organization operates.

But what are they supposed to do about it?

They can buy another subscription, hire a consultant to build an integration, try to convince a vendor to make changes, or just continue dealing with the problem. What they probably can’t justify is hiring a team of developers to build software specifically for them.

Now imagine that same school district employing someone whose job is to manage its software needs. Someone who understands how the organization operates, knows which systems are being used, and has the ability to build custom applications or integrations when the existing software isn’t getting the job done.

Ten years ago, that probably wouldn’t have made much financial sense. Today, I’m beginning to think it could.

In the first issue of this newsletter, I wrote about how AI is fundamentally changing the economics of software development. For decades, businesses have been forced to adapt their processes to fit whatever software they could afford. As the cost of building software continues to fall, we’re approaching a point where businesses can increasingly have software built specifically around the way they operate.

I’ve been calling this hyper-bespoke software, and I think it’s going to become a much bigger part of how businesses use technology.

But somebody still needs to build it. And perhaps more importantly, somebody needs to manage it, maintain it, and take responsibility for it when things go wrong.

That’s where I think the next evolution of software engineering comes into play.

For lack of a better term, I’m going to call this emerging role a software manager.

I realize the title isn’t particularly original. We already have software managers, IT managers, systems analysts, and product managers doing portions of this work. What I think is changing is the scope of what a single person can realistically accomplish, and the types of organizations that can afford to employ them.

I envision a role that’s part software engineer, part product manager, part project manager, and part systems architect. Someone who can look at an organization’s operations, identify opportunities to improve them, and actually implement the technology necessary to make those improvements happen.

Sometimes that might mean buying an existing product. Sometimes it might mean replacing a subscription with something custom-built. Other times it could involve integrating several systems or automating a process that employees have been handling manually for years.

The important distinction is that this person isn’t necessarily spending most of their day writing code.

That’s already pretty close to how I operate when developing software for my own businesses. I’ve spent more than 3,000 hours over the past couple of years building with AI, and the way I work today is dramatically different from how I worked as a developer twenty years ago.

I spend considerably more time thinking through what needs to be built, how it should work, and whether the solution actually makes sense for the business. AI handles an increasing portion of the implementation, while I focus on directing the work, evaluating what gets produced, and making sure the pieces fit together.

And I think that’s a pretty good indication of where the profession is heading.

Now, I don’t want to suggest that technical knowledge is suddenly irrelevant. Understanding software architecture, databases, security, and how these systems actually work is still incredibly important. If anything, having that foundation makes someone considerably more effective when using AI development tools.

But I think we’re beginning to see a shift in the value that software professionals provide. Rather than being measured primarily by their ability to write code, they’ll increasingly be valued for their ability to solve business problems using technology.

And that starts to look an awful lot like a combination of software engineering and product management.

There’s another part of this conversation that I think we’re getting a little wrong.

We’re seeing this enormous push to teach everyone how to use AI, and increasingly, how to build software with it. As someone who teaches AI, I’m obviously a big believer in helping people understand what these tools are capable of doing.

But I’m not convinced that teaching everyone to vibe code is necessarily the right goal.

If you’re an accountant, I want you to understand how AI can make you a better accountant. If you’re a teacher, I want you to understand how it can help you become a better teacher. And if you’re running a business, I definitely want you to understand what’s possible so you can make better decisions about how to operate that business.

But does that mean I want my accountant spending half their day building and debugging software? Probably not.

Just because someone can do something doesn’t mean it’s the best use of their time.

I think we’re eventually going to reach a point where building software becomes as commonplace as creating a spreadsheet or writing a document. But we’re not there yet, and I don’t think we’re going to be there for quite some time.

There’s still an enormous difference between getting an application to work and being responsible for software that an organization depends on every day. Security, reliability, data management, maintenance, and all the other headaches that come with operating software don’t magically disappear because AI made the initial development easier.

And I’d argue that many organizations would be better served by having one person who is really good at managing those responsibilities than expecting fifty employees to become amateur software developers.

Of course, there’s an obvious problem with my theory. Software engineers aren’t cheap.

The median annual salary for a software developer in the United States is roughly $136,000, and that’s before you account for benefits and other employment costs. You’re not going to justify that expense by eliminating a handful of $30 subscriptions.

But I think there’s a bigger calculation to consider.

Businesses already spend an enormous amount of money on software, consultants, integrations, and the labor required to compensate for systems that don’t work particularly well together. And there are probably even more opportunities to improve operations that never get considered because the cost of developing the necessary software has historically been too high.

A software manager could begin to change that equation. Not only by reducing what an organization spends on existing software, but by building things that make the business more efficient or create value that wasn’t previously possible.

I’m not suggesting that every small business is suddenly going to hire a full-time software engineer. Plenty won’t be able to justify it, and others will continue buying commercial software because that’s still the better option.

But I can imagine a growing number of midsized organizations crossing that financial threshold. And for smaller businesses, I think there’s going to be an interesting opportunity for independent software managers who support multiple clients.

In either case, some of the money that businesses currently spend purchasing software could begin shifting toward paying people who create and manage software specifically for them.

And that’s where the implications for employment start getting interesting.

I’m not suggesting that AI won’t eliminate software development jobs. I think it absolutely will, particularly as organizations discover they can accomplish more with smaller engineering teams.

But I also think we’re going to see new opportunities emerge as the cost of building software continues to decline.

Some engineers who might have traditionally worked for a large software company or consulting firm could end up working directly for the businesses those organizations used to serve. And rather than building one feature of a product used by thousands of customers, they might be responsible for managing the entire software operation of a business with a few hundred employees.

That requires a different set of skills. They’ll need to understand business operations, communicate with nontechnical people, evaluate return on investment, and make decisions about which problems are actually worth solving.

Not every engineer is going to be particularly good at that, and I suspect some will have little interest in doing it. But I think those who can make that transition are going to find themselves with opportunities that simply didn’t exist before.

I also don’t know whether this redistribution will be large enough to offset the jobs AI eliminates. It’s entirely possible that the total number of software engineers declines even as the profession becomes more widely distributed throughout the economy.

But I think we’re making a mistake if we assume that the only consequence of AI making software development cheaper is that we’ll need fewer people doing it.

For years, we’ve heard that every company is becoming a technology company. I’ve always thought that was a bit of an exaggeration. A school district doesn’t want to become a technology company. Neither does a construction company or a dental practice. They want to be good at whatever it is they actually do.

But what if every company eventually has the ability to build and manage software specifically for its own needs, without having to become a software company?

I think that’s a much more interesting possibility.

And if I’m right, some of the most interesting opportunities for tomorrow’s software engineers might be at organizations that wouldn’t have even considered hiring one today.

Maybe the future of software engineering isn’t simply fewer engineers. Maybe it’s engineers working in places we’ve never seen them before.