Tesla wants us to believe that the future of transportation might involve flying cars.
Meanwhile, in software engineering, we're approaching a different kind of takeoff.
AI agents can now build entire features, navigate codebases, write tests, and fix bugs. Tasks that once took days can sometimes be completed in hours, with surprisingly little human intervention.
If machines can do more of the actual building, what happens to the people who spent years learning how to build?
Maybe we're looking at the next industrial shift in software engineering.
1. Every Industrial Revolution Changes the Job
We've been through abstraction shifts before.
We moved from assembly language to higher-level languages, from managing infrastructure manually to cloud services, and from writing everything ourselves to relying on frameworks and libraries.
Each shift moved the developer further away from the underlying machinery and closer to solving the actual problem.
AI agents feel like another step in that direction. Except this time, the abstraction isn't just hiding complexity. It's attempting to do the work for us.
And that's a significant difference.
A framework doesn't decide how to build your entire feature. An AI agent increasingly can. You describe the outcome, provide context, and let it figure out the implementation.
The question is no longer just how much code we can write. It's how much software we can build without writing that code ourselves.
2. When Code Becomes Cheap, What Becomes Valuable?
If an AI agent can implement a feature in hours instead of days, writing the code is no longer the only constraint.
But generating code and delivering reliable software are two very different things.
Someone still needs to define what the feature should do, identify edge cases, make architectural decisions, and verify that the implementation doesn't break existing behavior. In production systems, the consequences of getting these decisions wrong can be far more expensive than the code itself.
Consider a seemingly simple API change. The implementation might work perfectly in isolation, yet introduce a race condition, expose sensitive data, or overload a downstream service under real-world traffic.
These aren't just coding questions. They're engineering questions.
AI can help answer them, too. The point isn't that humans have exclusive access to this knowledge. It's that someone must ensure the answers are correct for the system being built.
As implementation gets cheaper, the ability to define requirements, evaluate trade-offs, and verify outcomes may become a bigger part of the job.
3. The Horse-to-Car Moment for Software
When cars replaced horses as the primary mode of transportation, the change wasn't limited to how people travelled. It created entire industries around manufacturing, maintenance, fuel, roads, and logistics.
Software might be approaching a similar transition.
When building software becomes cheaper, companies may stop asking whether they can afford to build a particular tool and start asking what else they could build. Products that were once too expensive to develop might suddenly become viable. Existing products could gain features that were previously pushed down the roadmap.
That creates opportunities. But it doesn't guarantee that every displaced job will be replaced by a new one.
We could end up with smaller engineering teams building far more software. We could see new roles emerge around AI infrastructure, security, and system oversight. We could also see fewer people needed for routine implementation.
All of these outcomes can happen at the same time.
The automobile didn't preserve every job built around horses. It changed the economics of transportation and created a different ecosystem.
Perhaps the more useful question isn't how many programming jobs AI will create or eliminate. It's which parts of software development will still require human effort—and which ones will no longer justify it.
4. Experience Is an Advantage, Not a Guarantee
Developers who started before AI agents became capable of building entire features have an advantage. They've debugged production failures, dealt with architectural trade-offs, and learned—sometimes the hard way—why seemingly good solutions fail.
“try to be a generalist more than you have in the past” - Boris Cherny · Lenny's Podcast
That experience can help them break down complex problems, anticipate failure modes, and recognize when an implementation needs closer scrutiny.
But here's the uncomfortable part: AI models are improving rapidly. They can draw on patterns from enormous amounts of code and technical knowledge. They can suggest failure scenarios that an individual engineer may never have encountered.
We shouldn't assume that years of experience will always translate into better results.
An experienced engineer might be better at directing an agent today. A less experienced developer with a capable agent and a rigorous validation process might outperform them tomorrow.
Experience still matters, but its value may shift. Knowing how to write the code yourself could become less important than knowing what to ask for, how to evaluate the result, and when not to trust it.
And even those skills might not remain uniquely human.
5. So, What Should Developers Become?
If writing code is no longer the bottleneck, what should developers focus on?
Perhaps defining problems, setting constraints, reviewing system designs, and validating outcomes. Perhaps understanding security risks and knowing when a system needs specialist expertise.
Non-developers may increasingly build products without writing code themselves. That doesn't mean they can safely operate every system they create. A prototype and a payment platform have very different requirements for security, reliability, and data integrity.
AI can help with implementation and testing, but trusting its output without independent verification is a risk. Someone still needs to own the outcome.
For experienced developers, this could mean spending less time producing code and more time deciding what should be built, evaluating whether it meets the requirements, and identifying where things could go wrong.
But I wouldn't rush to call this the future of software engineering. Agent orchestration, code review, and even parts of system design are themselves becoming automated.
The skills that make us valuable today might simply be the next things AI learns to do well.
The Job Is Changing Before We Know What It Becomes
Every major technological shift makes some skills less valuable and creates demand for others. AI agents are doing the same to software engineering, but the transition is far from complete.
Maybe developers will become orchestrators, system designers, or reviewers. Maybe those roles will be automated, too. We don't know yet.
What seems clear is that producing code is becoming cheaper, and the way we build software is changing with it.
The question isn't whether we can adapt to the next abstraction layer.
It's whether we'll recognize when that layer shifts again.
Top comments (0)