Software Developers Are Replacing Software Engineers
The engineering assembly line is getting replaced
Software developers are going to replace software engineers. That isn’t a typo. It’s what AI is actually doing to our industry, and most people don’t see it because they weren’t around 25 years ago before everything changed.
Even the CTOs panicking on Slack about AI replacing engineers are only half right. AI is replacing a kind of work, but the work it’s replacing is the engineering. What it’s bringing back is something we used to do twenty-five years ago and somewhere along the way forgot how to do
What We Actually Did 25 Years Ago
When I started my career, my job title was software developer. Not engineer. Developer. I have long been confused by the difference as the terms seemed interchangeable. Now, the difference is more obvious than ever. Let me explain why.
Back then, I sat down with customers, asked them what would make their job easier, and tried to build it. Simple, right?
In 2001, that meant going where they actually worked. I sat in a medical lab studying how they checked in lab specimens, flew around the country meeting with ticket brokers, and walked car dealership lots learning how cars actually got sold.
I spent countless hours on the phone with customers learning about their problems.
Avoiding customers wasn’t an option. We had to “develop” the solutions to their problems. That meant listening to them.
Development was the whole job. I’d talk to the customer, write the code, ship it, and rebuild it when I got it wrong. There was no spec sitting in a queue and no PM translating what the customer needed.
The tools were built for that kind of work. We had rapid application development (RAD), and tools like Visual Basic that let you drag a button onto a form, double-click it, and write the logic right there. The whole stack was designed to compress the loop between “I think I know what they need” and “let me show them and find out.” It was definitely RAD!
We weren’t over-engineering anything. We were figuring out what the right answer was by building, showing, learning, and rebuilding. The early agile manifesto came out of this exact world: customer collaboration over contract negotiation, working software over documentation, responding to change over following a plan.
How Engineering Took Over
Then the tech boom happened. Companies got bigger, teams got bigger, compliance showed up, specialization showed up, and the way the industry decided to scale was to break the job apart.
The customer conversation got peeled off and given to product managers, the roadmap went to product owners, project managers ran the schedule, business analysts wrote the specs, QA tested at the end, DevOps ran the infrastructure, UX designers owned the experience, and architects drew diagrams that nobody actually read.
By the time the coding work landed on an engineer’s desk, every interesting decision had already been made by someone else.
That’s an assembly line.
Tickets came in one end, code came out the other, and the person writing the code had no idea who the customer was or why the feature mattered. We renamed it engineering because that’s what it had become, a careful, formal, documented process for converting requirements into code.
None of the supporting roles around the engineer are bad on their own, but the engineer in the middle of that pipeline loses the thing that made the work matter to them.
They stop seeing customers, they stop owning outcomes, and they focus on moving tickets across a kanban board. Most engineering teams I see today are running this exact playbook and wondering why their people don’t act like owners.
They don’t even know who the customer is or how their work impacts them.
What AI Is Actually Doing
AI is the best rapid application development tool ever built. It is really RAD!
It compresses the loop between idea and working software in a way that Visual Basic could only dream about. Claude Code can take a half-formed thought and have a working prototype in front of a customer during the customer call itself! The boring engineering work, the typing and the scaffolding and the wiring between systems, is exactly what AI does well.
This is why the panic about AI replacing developers is misreading the moment.
We aren’t in a moment where developers are getting replaced. We are in a moment where the engineering assembly line is getting replaced. The question every engineering leader has to answer right now is whether they are running an assembly line or a development team.
You do call it the “dev” team, right?!?
The 80/20 Just Flipped
When I started, a software developer spent maybe 20% of their time writing requirements, talking to customers, and validating their work. The other 80% was engineering itself, the typing, searching Stack Overflow, debugging, and wrestling with frameworks. The engineering part was still very time consuming.
That ratio has flipped. As a software developer today, we spend 80% of our time figuring out what to build, writing requirements clear enough for an AI to act on, and validating what comes back. The 20% is engineering, and most of that is reviewing the code that Claude Code wrote.
Reviewing the output of AI is now a massive part of the job.
Claude Code is the software engineer now. I’m managing it. What I’m doing now is a hybrid of product owner, software architect, and QA, three jobs that the industry spent the last twenty years pushing apart and treating as separate functions. AI has collapsed them back into one role, and that role is software developer.
In my opinion, it is also way more fun and you can better see how your work matters to the customers who use it.
The reality of this is much messier than what I’ve described.
Customer-facing work is its own kind of messy and confusing nightmare (at times), and plenty of strong engineers want nothing to do with it. Not every developer on your team is going to thrive on a sales call, and the reality is that not every developer needs to.
The answer is somewhere in the middle. A few people on the team will love being close to customers, and you should let them run with it. The rest are going to need the customer’s voice piped in to them, and that’s where the leader’s job comes in.
If your developers can’t all be on the call, you have to be.
You sit on the customer calls, read the support tickets, watch the demos, and then keep repeating what you heard until the customer’s voice is loud enough in the team’s head that it shapes the work even when no customer is in the room. That isn’t optional anymore. The team can’t navigate the new 80/20 ratio without it.
If we can write code 5x faster, we need product requirements 5x faster.
Or you need software developers who intuitively understand the customers and the business problems.
The Retraining Problem
If any of this resonates, your leadership team is going to be living with these questions:
How do we retrain our engineers to be software developers?
How do we create more product owners on a team that has been organized around tickets for two decades?
Engineers haven’t lost product thinking. Many never had the chance to learn it. We hid them from the customer behind a stack of PMs and BAs for twenty years and never showed them what product thinking even looked like. Now we have to expose them to the customer fast, because the teams that figure this out first are going to ship circles around the ones still defending the line.
Every engineering leader we talk to right now is saying the same thing. They can process the backlog faster than ever, and the real bottleneck is figuring out what to build next. There’s a severe lack of skilled product managers and product owners in the industry to answer that.
The solution is to go back to where we were twenty-five years ago, when we had more software developers who thought like product owners themselves.
That’s the question I wrote Product Driven to answer. The book is built around five pillars: vision, focus, clarity, ownership, and courage. Two of them, Focus and Clarity, are what your team needs most right now. Focus is saying no to work that isn’t connected to a real customer outcome. Clarity is making sure every developer knows why and who, even when they aren’t on the call. Without those, the new role doesn’t work.
I’d rather you read it than not, so I’m giving it away for free on my website. Grab a copy if you want the framework for how to actually do this with your team.
The industry spent two decades turning developers into engineers. Luckily us old timers remember what it was like to be a software developer.
Software development is back, baby!!!