The End of the Traditional Coder
Why 2026 is the New “QA Shift-Left”
Today’s conversation around AI is entirely focused on the wrong question: “Will AI replace software engineers?”
The reality is far more nuanced. AI is not replacing the engineer; it is fundamentally redefining the baseline leverage of the role. We have reached a point where coding is no longer the bottleneck. Output is cheap, and syntax generation is nearly instantaneous.
For decades, we operated under the illusion that the hardest part of software development was writing the code. But as AI removes that barrier, it is exposing an uncomfortable truth: the real bottleneck was never the engineers.
It was discovering a solution actually worth building.
Today, we see AI simultaneously expose and accelerate the fundamental flaw in how most tech companies operate. If your organization is still running a traditional project model—where product managers hand down unquestioned requirements for engineers to simply execute—AI hasn’t made you a better product company. It has turned you into a turbo-charged feature factory, fully capable of producing bad products faster than ever before.
To understand what happens next, we need to look at what happened to QA testers a decade ago.
In my essay, Do You Need More Testers or Better Tests?, I explored this a bit. When you disrupt the assembly line where devs blindly hand off features to separate QA team, the initial reaction is almost always resistance: engineers are surprised they are expected to test, and product managers struggle to define explicit acceptance criteria.
But the historical data makes the necessity of this transformation clear. The World Economic Forum’s Future of Jobs Report 2023 predicted a 15% global decline in traditional software tester jobs precisely because manual gatekeeping cannot scale. Tech giants like Microsoft recognized this mismatch over a decade ago, eliminating the systemic waste of handoffs, context switching, and divisive “us vs. them” dynamics.
Read more: Ten Types of Software Engineering Waste
When CI/CD pipelines, automated testing, and DevOps culture took hold, the “traditional manual tester” faded away. Quality didn’t disappear; it became an embedded engineering responsibility.
You could no longer build a career solely on clicking through test scripts.
Read more on Leading QA Shift Left Transformation
Today, we are witnessing the exact same structural collapse, but this time, it is happening to the “traditional coder.”
Generating boilerplate, writing standard CRUD endpoints, and translating Jira tickets into basic syntax is becoming the new manual testing. It is a commodity.
The Bimodal Engineering Profile
If you look at the most advanced AI-native engineering orgs today, they are no longer indexing on raw coding throughput. They are hiring for two distinct, heavily specialized profiles
1. The Product-Minded Builder
When the cost of building prototypes drops to near zero, the gap between “product discovery” and “product delivery” vanishes.
The Product-Minded Builder doesn’t wait for a perfectly groomed backlog. They rapidly prototype hypotheses, spinning up working applications in hours to test with real users. Their primary skill is not knowing the intricacies of a specific frontend framework; it is immense customer empathy and sharp business context.
They are product creators who use code as their medium. Their value lies in defining the right problem to solve, knowing that the AI will handle the heavy lifting of the syntax.
This archetype is the living embodiment of what I advocated for in The Product Engineering Manifesto. The Product-Minded Builder completely rejects the outdated operating model that begins with: “Here’s what we need built”, replacing it with a demand for a true partnership in product strategy and clarity on “Here’s the problem we need solved”.
Because AI has commoditized the actual typing of syntax, these engineers can finally realize the manifesto’s core values:
Prioritizing discovery collaboration over delivery execution.
Valuing customer outcomes over mere feature output.
Measuring success by user impact rather than story points completed.
They understand that requirements are merely hypotheses, not facts.
By stepping out of the Jira backlog and participating directly in the discovery process, they operate as true product creators—utilizing code simply as their medium.
2. The Deep Systems Expert
If AI is generating millions of lines of code, the new organizational nightmare is not creation—it is verification, security, and architectural integrity.
This is where the Deep Systems Expert steps in. These are the engineers who understand distributed systems, database scaling, and complex infrastructure at a molecular level. An LLM cannot wake up at 3 AM to debug a cascading failure across a hybrid cloud architecture, nor can it elegantly untangle years of technical debt to improve system resilience.
The Systems Expert provides the guardrails, platform stability, and “trust but verify” pipelines that enable the Product Builders to move at light speed.
For over a year now, I’ve been running a Platform Engineering organization. What I learned from our experience and the industry’s is that in the majority of successful cases, AI is just a thin layer of orchestration sitting atop years of rigorous, foundational engineering practices.
LLMs are not sentient problem solvers; they are highly advanced pattern matchers and text generators that require structured data, rich context, and extensive, immediate feedback to function effectively. If you drop an LLM into a messy, fragmented architecture with outdated documentation and flaky CI/CD pipelines, the result is not magic, but confident hallucinations and a scaling disaster.
The Systems Expert is the engineer building the unglamorous foundation of “AI Readiness”. They are responsible for architecting the environment that speaks a language the LLM can understand by mastering these basics:
Maintaining a consistent tech stack, which is an absolute necessity for an AI agent navigating multiple repositories without breaking things.
Treating documentation as code, ensuring OpenAPI specs and Architecture Decision Records (ADRs) provide the exact context windows LLMs need to generate accurate code.
Engineering immediate CI/CD feedback loops, because AI needs deterministic feedback within minutes to correct its own mistakes.
The Systems Expert understands that AI is the ultimate force multiplier, but multiplying a low-quality platform by zero still gets you zero.
Read more: The AI Illusion: Your Next Big Breakthrough is Actually Just Good Engineering
Build to Learn vs. Build to Earn
Historically, engineers were almost exclusively hired to build to earn (Delivery). The goal was to build a commercial-quality product that scales, is fault-tolerant, secure, and ready for market. “Testing” in this phase meant ensuring the software didn’t crash.
Product Managers and Designers were supposed to handle the building-to-learn (Discovery)—prototyping in Figma to test for value, usability, and viability before handing it off to the engineers.
AI has collapsed the wall between these two worlds. Today, Product Builders don’t wait for a perfectly groomed backlog to start coding. Thanks to AI-assisted development tools, creating a few functional, live-data prototypes a week is entirely feasible. The Builder uses code not just to deliver a final product, but as their primary tool for discovery. This fundamentally changes how they operate on a daily basis:
Live-Data Prototyping Over Abstract Specs: The Product Builder leverages AI to spin up functional, live-data prototypes in hours, testing for market value, not just syntax errors.
Parallel Hypotheses Over Sequential Delivery: The speed of AI allows the Product Builder to test multiple architectural or functional approaches simultaneously, discarding the losers instantly.
Product Sense is the New Seniority: Knowing the intricacies of a specific framework is no longer a moat; the LLM already knows it. The distinguishing skill is evaluating learnings from rapid prototypes, possessing deep customer empathy, and guiding the technical direction.
When the friction of execution vanishes, we are left with a dangerous reality: it has never been easier to perfectly execute the wrong idea. This is why a disciplined approach to defining the problem becomes the single most important phase of software development.
Read more on SVPG blog: Build to Learn vs Build to Earn
The initial solution is rarely optimal, and jumping immediately into code—even AI-generated code—means the problem is defined by hidden assumptions and biases rather than facts.
By utilizing my structured, 8-step Problem-Solving Framework, builders must articulate what the problem actually is, who it affects, and whether it is even worth solving before a single prompt is written.
Speed without rigorous discovery is useless; AI is merely a tool to rapidly prototype and learn what the right thing to build actually is.
The End of the “Feature Team”
For engineering leaders managing broad, cross-functional groups, the rise of the bimodal profile requires a fundamental shift in how we structure our teams.
We can no longer afford to isolate engineers from the customer context. If we treat developers merely as the “delivery mechanism” at the end of a long discovery process, we are wasting their newly unlocked AI leverage. The builders must partner directly with Product and Design in the discovery phase.
They are no longer there just to estimate tickets; they are there to ask, “How will we know this is working?”
As I explored in The Role of Engineering in Product Model Transformation, we must stop treating “requirements” as undeniable facts; in a complex and dynamic system, they are most likely just hypotheses that require fast validation. Empowered product teams shouldn’t be handed a predetermined list of features to build, but rather problems to solve with desired outcomes.
This structural shift demands a radical change in management. When engineers transition from ticket-takers into intent-driven outcome owners, leadership must abandon the traditional, permission-seeking model. It requires embracing “Center-Out Leadership,” which focuses on giving teams enough autonomy and context to solve problems independently.
You cannot micromanage discovery. To survive the AI transition, leaders must decentralize authority, building a high-accountability environment where engineers are trusted to discover the right solutions, not just type the syntax for someone else’s guesses.
The era of the “ticket-taking coder” is fading. But for those who embrace the builder mindset—those who realize that code is merely a medium for solving human problems—we are entering a golden era.
When you no longer have to spend all your time worrying about how to type the syntax, you are finally free to focus on what actually matters: what are we going to build, and why?