The future of software developers is not a theoretical question for me. My son is studying software engineering, and he’ll enter this market directly. So when people ask whether junior developers still have a future, I don’t hear an abstract industry debate.
I hear a family question.
I’ve also spent more than 20 years leading engineering organizations, hiring developers, restructuring teams, dealing with delivery pressure, and cleaning up the consequences of bad technology decisions. I’ve seen what happens when executives believe a tool will save them from operating discipline. It never does.
The easy narrative says junior developers will disappear, business people will build everything themselves, and software engineering will become a prompt-writing hobby.
What I see from the field is more specific. Some engineering work will need fewer people, some will need more, and the definition of a good developer is moving back to something older and stronger.
Too many executive conversations collapse everything into one bucket called AI. That’s how bad portfolio plans get approved, and it’s how good teams get punished for the wrong reasons.
AI employee experience is visible, but it’s not the biggest engineering disruption. Giving employees access to general AI assistants requires governance, permissions, integrations, procurement, and training. Most of that sits close to existing corporate software management. It could disrupt more the overhead transversal roles
Business process optimization is different. Finance, HR, operations, and marketing workflows stayed semi-manual for years because the edge cases were too messy. LLMs move that boundary because they can classify unstructured input, summarize, route, draft, extract, and interact in ways previous automation layers couldn’t. I believe it will creates demand for engineers who can build the self-service platforms, APIs, MCP-style capabilities, guardrails, and integration fabric that make automation safe enough to use. This domain is a huge overhead optimization opportunity but requiering some engineering investment
Product engineering AI is where boards get excited. This is AI inside the actual product, customer journey, risk engine, support model, or operational backbone. It’s also where I see the most underestimation. Production AI needs architecture, observability, security, model evaluation, fallback paths, cost control, privacy, auditability, and release discipline. If a system can plan, call tools, modify state, and interact with users or other systems, you don’t need fewer engineers. You need better engineering. This domain is requiering some serious engineering and expend or transition engineering capabilities, same as what happened in the data world 10 years ago
Digital foundations are the silent constraint. Everyone wants AI use cases, but many companies still treat cloud, IAM, data quality, security, governance, privacy, and FinOps as technical debt rather than strategic infrastructure and then fail their AI investment projects
So where do I expect engineering demand to go down? In the software development operating model supported by Agentic coding.
Agentic coding is the most mature and disruptive AI use case for software engineering jobs today. Not because it magically replaces engineers, but because it changes the unit of work.
A properly set up engineer with coding agents can often move from implementing one user story to delivering something closer to an epic in the same kind of effort window. That’s not a benchmark. It’s the direction I see when teams stop treating the agent as autocomplete and start redesigning delivery.
That’s why the lazy version fails. You don’t hand out Claude Code licenses and hope velocity improves. You redesign the software delivery system.
In organizations that make progress, I see the same pattern appear quickly.
A two-week sprint starts to feel like an old tax on flow. When an engineer can produce and validate much larger chunks of implementation with an agent, batching work into sprint containers becomes less logical.
This is the part that matters most to me as a father.
One of the most counter intuitive patterns I observed during the transformations is that junior developers are often more open to the shift. They have less identity invested in the old coding craft as a status marker. They’re less likely to see the agent as an insult.
With the proper setup, the experience gap required to steer agents is not as large as many senior engineers assume. The gap that still matters is judgment. That judgment can be taught if the team has real engineering leadership.
The better pattern is a smaller squad with a strong business focused senior engineer governing architecture and quality, supported by developers who are comfortable working agentically and can move across business, product, code, testing, and delivery.
In that setup, junior developers shine
The winning junior profile is broader, more curious, and more comfortable with ambiguity and communication.
This is not a weaker developer. It’s a developer one level up.
Agentic coding pushes us back toward the product engineer: someone who can understand the business intent, shape the solution, drive implementation with agents, and own the outcome.
Not alone. Not without governance. But with far fewer handoffs.
My current rule of thumb based on what I observed is simple: in an efficient agentic coding model, the optimal product engineering squad is closer to three or four people than five or six.
The dangerous mistake is taking the same team shape and just asking for more output. I’ve seen that pattern before with offshoring, agile transformations, cloud migrations, and platform programs. It creates noise, not leverage.
They also need a different relationship between product management and engineering.
The classic split between product manager or product owner on one side and developers on the other becomes less efficient. The PM who can work agentically will become more technical in practice and even directly fix issues, I observed this evolution. The developer who can face product and business questions becomes more valuable.
Both paths converge toward the same destination: product engineer.
The agentic-native company won’t be the one with the most AI licenses. It’ll be the one that redesigns work around the new leverage points: smaller product squads, stronger engineering governance, product managers who understand the machine, and developers who understand the business. The winning operating model won’t separate “thinking” and “coding” as cleanly as the last generation of software organizations did.
This is the full circle, one level up. We return to engineers closer to the problem, closer to the user, closer to the economics of the product, but with agents multiplying execution capacity and for that Junior engineers are proven to be great! After two decades in engineering leadership, that’s the part I trust: not the hype, not the panic, but the shift in where real leverage appears.
For investors and executives, the signal is clear. Don’t value a technology organization by how many developers it has, or by how aggressively it claims to replace them. Value it by whether it can convert agentic capability into reliable product velocity, governed systems, and business outcomes.