Every major shift in software engineering has increased the level of abstraction. AI may be the first one that also changes who does the work.
For several years, “learn to code” was the safest career advice you could give anyone. In 2026, that advice needs a disclaimer. Coding agents now write the majority of new code at some of the world’s largest engineering organizations, and the job of “software engineer” is being rewritten in real time, not by a single breakthrough, but by a compounding series of model releases that quietly crossed a threshold sometime around the turn of the year.
This isn’t hype dressed up as inevitability. It’s showing up in survey data, in enterprise telemetry, and in the words of engineers who are living through it. But the story splits in two directions at once.
As with every major paradigm shift leading up to a new abstraction level in the history of programming, we solve some problems in how software gets built, and simultaneously creating a new set of problems that the industry hasn’t figured out how to manage yet. The introduction of AI into the programming profession is no exception.
What AI is solving
The most straightforward case is engineering productivity. MIT Technology Review’s survey of 300 engineering and technology executives found that agentic AI is already in at least limited use at 51% of software teams, with 45% more planning to adopt it within a year. Respondents expect delivery speed from pilot to production to accelerate by an average of 37% over the next two years, and 41% of organizations aim to have agents managing most or all their product development lifecycle end-to-end within 18 months.
Talking to engineers back this up. Both within my own network of friends and coworkers in the tehc space, but also when searching for verifiable testimonials on the open web. An engineer in South Carolina described how a payment feature that would normally take her two to three days by hand was built by Anthropic’s Claude Code in just over an hour, calling it “the point of no return” for her industry, in an account picked up by Business Insider’s reporting on the coding profession’s disruption.
At Google, a principal engineer described handing Claude Code a spec for a distributed agent orchestrator her team had spent a year building and getting a working version back in an hour, according to reporting from Northeast Times, and the creator of Claude Code has reportedly gone a full month without opening an IDE while shipping around 200 pull requests.
At the enterprise level, Goldman Sachs has deployed agentic AI systems like Cognition’s Devin to scope, write, test, and debug code alongside its roughly 12,000 human engineers. The bank’s CIO has described the tool as functioning like a new employee and expects it to be three to four times more productive than earlier AI tools, with one large enterprise customer reportedly cutting security-fix development time by five to ten percent.
The clearest use case for AI’s problem-solving power is the unglamorous, high-toil work nobody wanted anyway: boilerplate, test scaffolding, refactors, and, increasingly: QA. According to one senior engineer’s account on HackerNoon, the engineering function absorbing AI fastest is quality assurance and test automation, where teams that once needed three to five people now run with one person overseeing AI-generated coverage. That’s a genuine solution to a genuine bottleneck. The kind of repetitive, low-judgment work that burned out junior engineers for a generation.
What AI is breaking
But speed without judgment has a cost, and the data on that cost is now large enough to be unambiguous.
The most rigorous evidence comes from Faros AI’s analysis of two years of telemetry from 22,000 developers across more than 4,000 teams, aptly titled “Acceleration Whiplash.” Teams that lean hardest on AI complete 66% more finished work packages per developer, but production incidents per code batch rise by 243%, code review time stretches by 441%, and code churn (work deleted almost as soon as it’s written) climbs by 861%. Pull requests submitted with no human review or automated checks at all rose by 31%, because reviewers simply cannot keep pace with the volume agents produce.
That gap between output and oversight is the defining tension of agentic software engineering right now. Dice’s reporting on enterprise AI adoption found that while 82% of organizations are testing or running AI-driven IT projects, engineers still cite untrustworthy outputs and poor context as leading obstacles. Because an AI system can produce a confident, plausible-looking answer while missing years of undocumented architectural decisions that only exist in people’s heads, not in the code. Therefore it is still crucial to keep the human in the loop when deploying agents in your engineering pipelines.
The solution comes with a price, a review burden is landing hardest on the industry’s middle. A Menlo Ventures partner described a growing divide between “lazy” engineers who lean on AI with minimal engagement and “craftsmen” who absorb the entire burden of reviewing and fixing the resulting flood of code, warning that most engineers are approaching an identity crisis “bordering on depression,” as reported by outlets covering Business Insider’s ongoing “Great Coding Reset” series.
It is worth mentioning that named laziness is not meant as a derogatory label, but rather an acknowledgment that we humans are inherently lazy by nature. If that is not recognized and dealt with proactively, quality will suffer in the long run.
The underlying research from Business Insider, has also tracked how the same shift is squeezing entry-level hiring. Senior engineers get more out of AI because they have the experience to judge its output, while junior engineers traditionally the ones doing the debugging and small features that built that judgment in the first place are finding fewer entry points into the profession.
Agentic development creates a new kind of technical debt
Most of what’s described above still frames the cost in terms of code quality, more incidents, more churn, more unreviewed pull requests. But there’s a subtler cost that doesn’t show up in a linter or a CI dashboard: debt in understanding.
Traditional technical debt accumulates in code in the shape and form of the shortcuts and workarounds nobody gets around to fixing. Agentic development risks accumulating debt somewhere else entirely: in a team’s collective grasp of what it has actually built. Working with AI-assisted and agentic development ourselves, one pattern has emerged quickly: the more indirectly we interact with a codebase, the harder it becomes to hold onto a shared, deep understanding of what we’re building. We describe this internally as cognitive debt, and the concern isn’t primarily whether the code is good. It’s whether engineers still understand the systems they’re responsible for.
The gradient is intuitive once you name it. An engineer who writes a solution by hand understands every decision behind it. An engineer who reviews an AI-generated solution understands considerably less. They’ve checked the output, not lived the reasoning that produced it. An engineer who accepts AI output without review may understand almost nothing about what just shipped. As systems lean further into agentic workflows, cognitive debt becomes just as important to manage as technical debt.
The fundamentals are back with a vengeance
The response taking shape across the industry isn’t to reject AI, but to re-anchor around the skills AI can’t do. A talk by developer Matt Pocock arguing that software fundamentals matter more than ever. His argument, echoed by engineers at Google and Vercel, is that AI performs best when it’s constrained by clean architecture, a shared vocabulary between developer and model, and disciplined testing. On the other end, it performs worst, or actively compounds bad decisions, in codebases that lack all three.
When code becomes abundant and essentially free, differentiation shifts elsewhere. Engineers who understand distributed systems, networking, security, architecture, databases, product design, and business domains become more valuable because they can evaluate the work generated by machines.
The trade-off
None of these resolves into a clean verdict, and the Guardian’s reporting on engineers adapting to AI captures that ambivalence well: developers are simultaneously reskilling, returning to fundamentals, and in some cases organizing collectively to push back on how aggressively AI is being pushed into their workflows.
AI is solving the boring, repetitive, and previously unscalable parts of software engineering: Testing, boilerplate, and the grunt work of legacy modernization. What it’s introducing in return is a verification bottleneck: more code, produced faster, reviewed less thoroughly, by fewer people who have fewer chances to build the judgment needed to catch what the machine gets wrong.
Leaning into agentic software engineering, in other words, require organizations to redesign their engineering operating models based facts and insights about whether a you are setting the oversight, governance and pipelines that (semi-)autonomy requires, or just enjoys the throughput numbers until the incident count catches up with them. And at the end of the day, always keep in mind that the machine can never be held responsible for it’s own output. The accountability has to be placed on the human in charge of the result.
