The end of Software Development and the rise of Product Engineering
It is finally time to admit that software development (as we know it) is a thing of the past. If you’ve used one of the major agentic platforms like Google Antigravity, Claude Code, OpenAI Codex or OpenCode, you are fully aware of their staggering speed, breadth, and generative capability. Architectural designs, implementation plans, and functional feature sets are produced at a pace that was unimaginable even for a team of top-end engineers just a few years ago. I’ve seen complex frontend interfaces that used to take months to build replicated by agents in minutes. There’s no denial: humans have lost their monopoly on the creation of code. This shift marks the definitive transition from manual craftsmanship to a new era of high-level product engineering governed by intent rather than syntax.
Mark Zuckerberg was right
I hate to admit it, but Mark Zuckerberg was right. Back in January 2025, I recorded a video reacting to Joe Rogan’s podcast, where Mark claimed that Meta would likely have AI capable of performing as a mid-level software engineer by the end of the year. At the time, I dismissed his claim. I argued that tools like GitHub Copilot were still far from replacing a human engineer and encouraged my audience to keep mastering the "old school" craft of manual coding. While I acknowledged he might have access to proprietary tech I hadn't seen, I felt confident in my skepticism. Today, I have to eat my words 😢.
While I’m confident my experience remains a vital asset to any organization, I can no longer, in good conscience, advise anyone to focus on learning a programming language as their primary career path. As you can imagine, this realization triggered an internal personal crisis: Did the skills I honed in twenty-five years become obsolete overnight? What is my place in a world where the responsibility of writing code shifted to artificial intelligence?
Luckily, I was always an early adopter of new ideas and I never let fear drive my decisions, so I decided to lean into the tools rather than resist them. The more I used agentic platforms, the more it became clear what my new role was. My input wasn't gone; it had just moved up the stack. My role shifted from writing code in an IDE to guiding an Agentic Platform to form a product in short iterations. My expertise is now channeled into ensuring code produced by the agents is lean, fits the product requirements precisely, and remains free of the subtle hallucinations or architectural bloat that AI can still produce. I am no longer a developer of code; I am an architect of intent.
I have to admit that my experience in Product Governance as Lead Architect and Platform Owner, helped me adapt to this shift quickly. Let me explain why.
The Rise of the Product Engineer
One thing that hit me pretty quickly while playing with these agentic platforms is how they completely flip the script on the traditional software development lifecycle (SDLC). When an AI can handle design, implementation, and testing in a few minutes instead of weeks, the old barriers between roles just start to melt away. All that back-and-forth between architecture, engineering, and QA? It kind of disappears when agents can handle the bulk of it. In this new world, keeping those roles in separate silos just doesn’t make sense anymore.
Despite my general aversion to buzzwords, clear labels are necessary to describe a fundamental shift in paradigm. When I first started mapping out this new way of working, the title that naturally came to mind was Product Engineer. I soon realized the term already exists across the software landscape, typically describing full-stack developers focused on user outcomes over deep backend infrastructure. However, as agentic tools fundamentally rewrite how software gets built, I believe the definition must evolve to fit this new reality.
Think of it this way: once the product requirements are set, you just need someone to act as the bridge between the vision and the AI platform. This is the Product Engineer.
In formal terms, the Product Engineer is responsible for translating product requirements into a product. It does this by coordinating and supervising the work of a team of agents, the same way a traditional tech leader coordinates and supervises the work of a team of humans.

Sure, you could try to plug an AI directly into JIRA, save the Product Engineer wage, and hope for the best, but I’ve found that these platforms work ten times better when a senior engineer or architect is steering the ship and acting as a supervisor and coordinator.
It is important to understand that the scale and speed of code produced is so vast that it is impossible to review every single line of code produced by the team of agents. Instead, like every skilled architect or tech leader does, you need to focus on the big picture: interfaces, domain models, and overall patterns that make an app actually work and that gives us a good level of confidence in its correctness and quality.
This is a huge shift for how we hire and train people. Forget LeetCode and HackerRank, that are pretty much worthless now (at least within the broader software landscape, as certain specialized sectors likely remain insulated). We should be looking for people that, rather than being good at producing code, are excellent at driving and leading others to the creation of complete products and/or features. Here’s what I think the core DNA of a Product Engineer looks like:
- Relentless problem solving
- Killer communication skills
- Solid business acumen (knowing *why* we're building something)
- A massive breadth of experience across different tech stacks and architectures
This profile describes the modern engineer who has spent enough time in the industry to move beyond the syntax and into the strategy. In my experience as a Lead Architect, I’ve found that my role now spans the entire organizational stack. My true value no longer lies in the lines of code I can produce, but in my ability to help the business vet the feasibility of their ideas. I act as the filter and the translator, taking ambitious visions and turning them into lean, viable solutions that enable the organization to reach its goals efficiently, optimizing for both time and cost. The Product Engineer is, essentially, the final safeguard of architectural integrity and business value in an automated world.
The Prompt Engineer, The Accelerator Effect and Pending Challenges
A big misconception currently circulating among business leaders is the belief that producing quality software with these platforms is merely a matter of crafting the perfect prompt. This misunderstanding has birthed the term "Prompt Engineer," a buzzword I hate with a passion. Quite frankly, the entire concept of a prompt engineer is fundamentally flawed.
Just as a championship-caliber team requires a world-class coach to direct their talent, these agents need a conductor to guide them. It is never just about the prompt. Effective orchestration requires a deep understanding of feature phasing, robust system architecture (especially when navigating a complex web of interconnected components) and a relentless focus on safety and security.
As I discussed during a conference with Christopher Powell last year, we must recognize that AI serves solely as an accelerator. Put a professional pilot behind the wheel and you secure a podium finish; put an amateur in the seat and they will likely wreck at the very first corner.

The reality of this new landscape is that the traditional role of the junior developer is evaporating. This is why I can no longer advocate for anyone to pursue manual coding as a primary study path. Yet, we must ask: is this model sustainable? If the entry-level tier becomes obsolete, how do we cultivate the next generation of seniors? Furthermore, how will today’s experts maintain their technical edge when they no longer work in the trenches?
To be clear, this shift isn't all rainbows and unicorns. The Junior Developer Paradox is just the tip of the iceberg, and we are hurtling toward several major challenges that the industry has barely begun to confront:
- Code Review Friction: How do we maintain quality governance when agents generate thousands of lines of context-heavy code in seconds?
- Educational Reform: How must computer science curricula adapt when teaching syntax becomes secondary to architectural orchestration?
- Legal and Intellectual Property Quagmires: Who owns machine-generated production code, and how do we manage latent license compliance risks?
- Infrastructure Dependence: How do we mitigate the threat of agentic pricing models that could feel like a "bait and switch" once organizations are fully locked into vendor platforms?
There is so much to unpack in these issues that they deserve their own dedicated articles. But acknowledging these risks doesn't mean we can afford to pull back.
Conclusion
The era of manual coding as the cornerstone of our industry is drawing to a close, but this shouldn’t be viewed as an ending so much as an evolution. We are moving from the mechanical act of writing code to the higher-order craft of architecting intent and creating products. This transition is inevitable, driven by the sheer efficiency and scale of agentic platforms that have fundamentally redefined what is possible.
While it is natural to feel a sense of loss for the "old school" craft, the rise of the Product Engineer offers a powerful new path. By embracing these tools, we can move beyond the constraints of lines of code and focus on the strategic impact of the products we build. This change isn’t just about the obsolescence of manual labor; it’s an unprecedented opportunity for engineers to grow into true partners of business value and vision. The future belongs to those who lead the agents, not those who compete with them.
As a last thought I want to add that despite the many problems and concerns that remain unaddressed, we cannot afford to stay behind the competition. These challenges are inevitable in such a rapid shift, but I’m sure they’ll be solved by the industry as we continue to move forward and mature our approach to agentic development.
Whether you agree with my take or think manual coding still has a long runway ahead, I’d love to hear your thoughts below!