Is AI writing all code now?

A year ago, saying "I vibe coded this" would get you laughed out of most engineering circles. The term carried a whiff of recklessness, the implication that you were shipping code you didn't understand and didn't care to. Experienced developers dismissed it as a toy for hobbyists. Hiring managers saw it as a red flag. Fast forward to March 2026, and the conversation has shifted dramatically. AI is not just assisting with code anymore. It is writing most of it. GitHub Copilot crossed 20 million users in mid-2025. Around 41% of all code written in 2025 was AI-generated, and projections for 2026 put that number well above 50% in high-adoption organizations. A study from the Complexity Science Hub found that AI-assisted coding in the US jumped from roughly 5% in 2022 to nearly 30% by the end of 2024, and the trajectory has only steepened since. The question is no longer whether AI should write code. It already does. The question is what happens when humans have to make sense of what it wrote.

The mainstream moment

I have written before about how the paradigm has changed, how the cost of turning an idea into working software has collapsed to nearly zero. I have also covered the rise of vibe coding and why experienced developers benefit most from these tools. The throughline across all of it is the same: AI-assisted coding went from fringe to default faster than almost anyone predicted. The 2025 Stack Overflow Developer Survey found that 84% of developers use or plan to use AI coding tools. Companies are setting explicit targets. One SaaS company publicly shared its 2026 goal: 80% of code AI-generated, with frontend reaching 100%. Google reported that 25% of their code is now AI-assisted. Anthropic's CEO predicted AI would write 90% of code within months. The stigma is gone. Using AI to write code is no longer a confession. It is the expected default. If you told a team in 2024 that you were manually writing every line, some people would have called you principled. In 2026, they would call you slow.

The acceptance curve

What changed? Partly the tools got better. Models like Claude, GPT-4, and a wave of open-source alternatives improved dramatically in their ability to produce working, idiomatic code. As I explored in Vibe code 101, the practical tips for effective AI-assisted coding have matured alongside the tools. Developers learned how to steer, review, and iterate rather than blindly accept. But the bigger shift was cultural. Once enough senior engineers started openly using AI tools, the permission structure changed. When Google's own engineering teams adopt it, when respected voices like Addy Osmani write detailed guides on LLM coding workflows, when The Pragmatic Engineer newsletter opens 2026 by asking "when AI writes almost all code, what happens to software engineering?", the conversation moves from "should we?" to "how do we?" Sonar's 2025 State of Code report captured the tension perfectly: 42% of code is now AI-assisted, and that number is expected to reach 65% within two years. Yet 96% of developers say they don't fully trust AI-generated code. We are using these tools constantly while remaining deeply uneasy about what they produce. That unease is not irrational. It points to a real problem that the industry has barely begun to address.

The code review problem

Here is the part nobody talks about enough. When AI writes a few functions here and there, code review is straightforward. You read the output, check the logic, verify edge cases, and move on. That workflow made sense when AI was generating 10% or 20% of a codebase. But what happens when AI generates thousands of lines in a single session? What happens when a pull request lands with 10,000 lines of changes, all coherent, all syntactically correct, all passing tests, and you have no idea why any particular decision was made? This is the new reality. AI-generated code is not wrong in the way human code is wrong. It does not have typos or forgotten semicolons. It fails in subtler ways: architectural choices that seem reasonable in isolation but create problems at scale, implicit assumptions about data flow that were never discussed, security patterns that are technically correct but inappropriate for your specific threat model. The Pragmatic Engineer newsletter framed this as a fundamental shift in what software engineering means. When AI writes most of the code, the developer's job becomes less about writing and more about understanding. And understanding code you did not write, code that has no commit history of incremental human decisions, code that was generated wholesale from a prompt, is genuinely hard. I touched on this in Code has become too fast, where I noted that building is no longer the constraint. The METR study I referenced there found that experienced open-source developers actually took 19% longer to complete tasks when using AI tools, even though they believed AI had sped them up. Part of that gap is the hidden cost of review: the time spent reading, evaluating, and sometimes rewriting AI output that looks right but is not quite right.

Why the "yuck" factor has faded (mostly)

A year ago, many developers had an instinctive negative reaction to AI-generated code. It felt sloppy, generic, over-engineered. That reaction has softened for a few reasons. The output quality improved. Modern coding agents handle multi-file refactors, respect project conventions, and produce code that genuinely reads like it was written by a competent human. Repository-level tools like Cursor and Claude Code understand context across entire codebases, not just individual files. Developers got better at prompting. As I wrote in LLMs are smart enough, humans suck, the bottleneck was never the model. It was us. The Carnegie Mellon research on requirement-driven prompting showed that the single biggest improvement in AI output quality comes from humans learning to specify what they actually want. Developers who treat prompting as a skill, not a shortcut, get dramatically better results. The economic pressure won. When intelligence is a commodity and frontier AI models cost fractions of a cent per output, organizations cannot justify paying developers to write boilerplate by hand. The math stopped working. AI-generated code is not just acceptable, it is expected. Tooling caught up. AI code review platforms like CodeRabbit, Qodo, and Greptile now provide context-aware analysis of pull requests. AI reviewing AI-generated code sounds circular, but it works: automated reviewers catch style violations, security issues, and best practice violations that humans might miss in a 10,000-line diff.

The new skill: reading code you didn't write

The identity of a software developer is changing. Business Insider recently reported on what they called an "identity crisis" among coders, as engineering roles evolve from building software to overseeing AI agents that build it. The work becomes "much simpler" in some ways, yet less satisfying. Researchers at the University of Porto found that developers who entered the field because they wanted to build things are struggling as the role shifts toward supervision and review. This is real, and it is uncomfortable. But it is also not entirely new. Senior engineers have always spent more time reading code than writing it. The difference now is that everyone needs to develop that skill, including developers who are early in their careers and may never have the deep, hands-on coding experience that made previous generations effective reviewers. Anthropic's own research on this topic is revealing. In a randomized controlled trial, they found that developers who used AI assistance learned new skills faster but were less likely to deeply understand the code they had written. The productivity gain was real, but so was the comprehension gap. This is the central tension: AI makes you faster at producing code and potentially worse at understanding it. The MIT Technology Review echoed this concern, noting that one of the most pernicious side effects of AI tools may be a shrinking pool of people capable of understanding and maintaining code. A Stanford study found that employment among software developers aged 22 to 25 fell nearly 20% between 2022 and 2025. Fewer junior developers entering the pipeline means fewer people developing the deep skills needed to review the AI-generated code that now dominates production systems.

What actually matters now

The developers who will thrive are not the ones who write the most code or even the ones who prompt AI the best. They are the ones who can read a 5,000-line pull request and identify the three decisions that will cause problems six months from now. This requires a different kind of expertise. Not syntax mastery or framework knowledge, both of which AI handles well, but architectural judgment, security intuition, and a deep understanding of how systems behave under real-world conditions. It requires the ability to ask "why was this decision made?" about code that was generated in seconds and has no decision trail to inspect. Some practical shifts are already emerging: Smaller, more frequent reviews. Instead of letting AI generate massive changesets, teams are learning to break AI-assisted work into smaller, reviewable chunks. The same commit-early, commit-often discipline that served version control well now serves AI-assisted workflows. Mandatory decision documentation. If the AI made an architectural choice, the developer who prompted it needs to document why that approach was chosen over alternatives. The prompt history becomes part of the project record. AI-assisted review of AI-generated code. This is becoming standard. Tools like CodeRabbit and Qodo scan pull requests for patterns that human reviewers might miss, especially in large diffs. It is not a replacement for human judgment, but it is a useful first pass. Intentional skill preservation. Some organizations are experimenting with "AI-free" coding periods, not because they are anti-AI, but because they recognize that the ability to write and reason about code manually is a muscle that atrophies without use.

Where this is all going

We are in an awkward transitional period. AI writes most of the code, but humans are still responsible for everything that code does. The tools for bridging that gap, for helping humans understand and trust AI-generated systems, are still immature. As I discussed in What is ubiquitous AI, intelligence is embedding itself into every layer of our digital environments. Code generation is just one manifestation. The broader pattern is the same everywhere: AI capabilities are racing ahead of our ability to govern, understand, and maintain what they produce. The vibe coding backlash is over. Nobody is debating whether AI should write code anymore. The debate now is whether we can keep up with what it writes, whether we can maintain the judgment and understanding needed to ensure that the code running our systems is actually doing what we think it is doing. That is a harder problem than writing code ever was. And unlike code generation, there is no shortcut for solving it.

References