The adoption numbers finally got boring, and boring is the news. In surveys from this summer, 90% of professional developers report using AI coding agents at least weekly, and 68% use them daily. Separate data puts organizational adoption at 96.4%. We can stop writing the "are AI coding tools catching on" post. They caught on. Almost everyone uses them, most people every day.
Once something is near-universal, the arguments about whether to adopt it stop mattering and the second-order effects start. Those are more interesting, and less settled.
Review is now the bottleneck, not writing
When one developer in ten used an agent, generated code was a small fraction of what landed. When nine in ten do, and most do it daily, a large and rising share of the code entering your repository was written by a model and lightly checked by a human. The scarce, load-bearing skill quietly shifted from writing code to reviewing it well, and most teams have not adjusted their process to match.
This is worth naming plainly because it is easy to miss. Generation got cheap and fast. Verification did not. A developer can now produce more code than they can carefully review, which means the honest constraint on quality is no longer typing speed, it is review attention. Teams that still measure output by volume are optimizing the part that got easy while ignoring the part that got critical. The highest-value investment now is anything that makes review faster and more trustworthy: tests the agent must pass, tight diffs, machine checks before a human ever looks.
The junior-developer path got weird
Here is the effect I have not seen a good answer to. The traditional way people learned to code was by doing the small, tedious, well-defined tasks: the CRUD endpoint, the form validation, the obvious bug. Those are exactly the tasks agents now do best and fastest. The bottom rung of the ladder is the rung the agent is standing on.
That is still unresolved. If juniors no longer cut their teeth on the simple stuff because the agent handles it, how do they build the judgment to review the agent's work later? You cannot skip straight to senior. The skill of knowing when generated code is subtly wrong is built by having written that code wrong yourself, many times. A world where nobody does the beginner tasks is a world with a gap where the next generation of reviewers was supposed to come from. I do not think the industry has priced this in yet.
What I would actually do about it
Two things, neither dramatic. First, treat review as a first-class skill and process, not an afterthought. If most of your code is now generated, your competitive edge is how well and how fast you can vet it, so invest there like it is the main event, because it is. Automated checks that catch the obvious problems free up human review for the subtle ones that actually need a person.
Second, if you are early in your career, resist the temptation to let the agent do all the basic work. Do enough of it by hand to build the instinct for when something is off, because that instinct is the thing that stays valuable when the generation is free. The developers who will be worth the most in a few years are the ones who can look at a screen of plausible generated code and feel which line is lying. That feeling is earned, and the agent will happily rob you of the chance to earn it if you let it.
Universal adoption is not the story anymore. What universal adoption does to review and to learning is, and it is still being written.
If you have changed how your team reviews code now that most of it is generated, I would like to hear what actually moved the needle.
Top comments (0)