AI is writing the code. Who is still learning to?

Coding with AI is no longer an experiment. In the 2025 Stack Overflow Developer Survey, 84 percent of developers said they use or plan to use AI tools, up from 76 percent the year before, and 51 percent of professional developers use them every day. Google's CEO told investors in late 2024 that more than a quarter of all new code at Google is now generated by AI. And when Anthropic studied how its own coding tool gets used, 79 percent of conversations were classified as automation, the AI doing the task, rather than collaboration on it. Whatever the norm was, this is the norm now.

Here is the strange part: as usage climbs, trust is falling. Favorable sentiment toward AI tools in that same survey dropped from 77 percent in 2023 to 72 percent in 2024 to 60 percent in 2025, and 46 percent of developers now actively distrust the accuracy of AI output, against 33 percent who trust it. Barely 3 percent trust it highly. Developers are leaning on a tool they believe less each year. That paradox is worth an article on its own, but it points at a quieter problem underneath, one we think matters more for the long run of the field than any single layoff headline: what constant AI assistance does to the drive, and the opportunity, to actually learn the craft. We say this as a studio that builds AI systems and uses these tools daily, not as bystanders. The evidence deserves a straight reading.

The effort really does leave the room

Start with the best-documented effect: when AI helps, people think less hard, and the more they trust it, the less hard they think. Researchers from Microsoft and Carnegie Mellon surveyed 319 knowledge workers about 936 real AI-assisted work tasks and found that a clear majority of those tasks were rated as taking less mental effort across every cognitive activity measured, from recalling facts to evaluating quality. The pattern that should give you pause: higher confidence in the AI was associated with less critical thinking, while higher confidence in one's own skills was associated with more. The tool does not just save effort. Trusting it licenses you to stop checking. It is worth saying plainly that this is self-reported survey data, perceived effort rather than measured behavior, but the direction is consistent and the sample is real working professionals.

A smaller study went looking for the same effect in the brain. In the MIT Media Lab's "Your Brain on ChatGPT" experiment, students wrote essays either unaided, with a search engine, or with an LLM, while wearing EEG caps. The LLM group showed the weakest brain-network connectivity of the three, reported the lowest sense of ownership over what they wrote, and often could not accurately quote their own essays minutes after writing them. The authors call the pattern "cognitive debt." Honest caveats apply: it is a preprint, it involved 54 participants writing essays rather than code, and short-term engagement differences are not proof of lasting harm. But notice what both studies, one large and self-reported, one small and neural, are saying in the same direction: the work still gets done, and less of it happens in you.

Practice that feels productive can quietly stop teaching

For anyone learning to code, the most important experiment so far was not run on programmers at all. Wharton and Penn researchers ran a randomized trial with roughly a thousand high-school math students, published in PNAS as "Generative AI Can Harm Learning." Students practicing with plain GPT-4 access scored 48 percent better on practice problems, then 17 percent worse than the no-AI control group on the exam where the AI was taken away. The practice felt like it was working. The learning was not happening. The students had been getting answers, not building skill, and the improved practice scores actively hid the damage. There is a second half to that finding, and it is hopeful, but it belongs later in this article.

The programming-specific evidence rhymes. At ICER, one of the main computing-education research venues, a lab study of novice programmers working with AI assistants, titled "The Widening Gap," watched 21 students through interviews and eye tracking. Nearly all of them completed the task, which on paper looks like success. But the students who were already struggling developed new and compounded difficulties in judging their own understanding, what the researchers call metacognitive illusions: they believed they understood code they could not explain. The assistant helped everyone ship. It helped the strongest students learn and quietly widened the gap for the weakest.

Meanwhile the public learning loop that trained a generation of developers is drying up. New questions on Stack Overflow were down 60 percent year over year by December 2024, roughly three quarters below their peak. Some of that friction was worth losing, nobody misses being told their question is a duplicate, but something real is lost too: asking in public forced you to narrow the problem, produce a minimal example, and read someone's reasoning back. A private answer machine requires none of that, and the next learner never finds your thread, because there is no thread.

The feeling of speed is not the fact of speed

The productivity evidence is genuinely split, and the split is the lesson. In GitHub's controlled experiment, developers with Copilot finished a self-contained HTTP-server task 55.8 percent faster than the control group, and the less experienced the developer, the bigger the boost. Google ran a randomized trial on 96 of its own engineers and measured about 21 percent less time on an enterprise-grade task. A three-company field experiment covering 4,867 developers at Microsoft, Accenture, and a Fortune 100 firm found Copilot access raised completed tasks by about 26 percent. Those are real numbers from real experiments, and they are why the tools are not going away.

Then METR ran the study that should temper everyone's confidence. In a randomized trial with 16 experienced open-source maintainers working on their own mature codebases, repositories averaging over a million lines of code that they knew deeply, tasks with AI allowed took 19 percent longer. Before the study, the developers forecast AI would make them 24 percent faster. After finishing, having lived it, they still estimated it had made them about 20 percent faster. The measured reality was a slowdown. They accepted fewer than 44 percent of the AI's suggestions and spent a meaningful share of their time reviewing and cleaning its output. Read the three findings together and the shape emerges: AI is fastest on bounded, familiar, greenfield work, weakest where deep context lives in a person, and your own sense of being faster is not evidence. That last part matters for learning most of all, because the feeling of accelerated competence is exactly the signal people use to decide they no longer need to study the thing underneath.

The bottom rung is getting thinner

If AI weakens the private drive to learn, the job market is weakening the institutional path at the same time. Stanford's Digital Economy Lab analyzed payroll records covering millions of workers in "Canaries in the Coal Mine?" and found that workers aged 22 to 25 in the most AI-exposed occupations, software development prominently among them, saw a 16 percent relative decline in employment since late 2022, while older workers in the same jobs held steady or grew. For young software developers specifically, employment fell nearly 20 percent from its late-2022 peak. The New York Fed's data on recent graduates puts computer engineering at 7.8 percent unemployment and computer science at 7.0 percent, among the very highest of all majors, against 5.7 percent for recent graduates overall. And venture firm SignalFire's talent report found new graduates made up just 7 percent of Big Tech hires in 2024, down more than half from 2019.

This belongs in an article about learning because the junior job was the second school. Most of what makes a senior engineer senior was absorbed on the job: code review from someone better, production incidents, the slow accumulation of judgment about what breaks. If entry roles keep shrinking, the field is spending down its stock of future seniors. The industry's current bet, that AI plus a few experienced people beats a bench of juniors, only works until the experienced people retire and there is no bench. Someone has to be the senior engineer of 2035, and they have to start somewhere, most likely as the person directing and checking the AI rather than the person typing every line. Which is exactly why the checking skills are the ones to build.

What the new norm actually looks like

The clearest description of the shift comes out of that Microsoft and CMU study: with AI, effort moves from gathering information to verifying it, from solving the problem to integrating the AI's attempt at it, and from executing the task to supervising it, what the authors call task stewardship. In observational work on Copilot use, developers spent about a third of their session time evaluating and editing the AI's suggestions, more time than they spent on anything else. That is the new job description in miniature. The code is increasingly written by the machine. Whether it is right is increasingly the human's entire contribution, the same conclusion we reached from a different direction in our piece on the human in the loop.

The culture has already named the extreme version. Andrej Karpathy, who co-founded OpenAI, coined "vibe coding" in early 2025: "fully give in to the vibes, embrace exponentials, and forget that the code even exists," adding that he accepts all suggestions without reading the diffs. He also said, in the same post, that it is "not too bad for throwaway weekend projects." That qualifier is doing enormous work. For software a business depends on, somebody still has to read the diffs. The codebase data suggests too few people are: GitClear's analysis of 211 million changed lines of code found refactoring collapsed from 24.1 percent of changes in 2020 to 9.5 percent in 2024 while copy-pasted code climbed from 8.3 to 12.3 percent. Codebases are accreting instead of being tended. Universities can see where this lands: Carnegie Mellon now runs a course specifically on AI tools for software development, teaching students to work with the tools critically rather than pretending they do not exist.

So the durable skills are not a secret. Reading code you did not write. Debugging from symptoms to cause. Designing systems and data models the AI can fill in. Writing a specification precise enough to check the output against. And the meta-skill under all of them: noticing when a confident answer is wrong. Every one of those is strengthened by exactly the kind of practice AI makes optional.

How to keep learning when the answer machine is always open

The encouraging half of the evidence is that the harm is not from the AI, it is from how the AI is set up. In that same Wharton study, a second group used a version configured as a tutor, giving hints and guidance rather than answers. Their practice scores rose 127 percent, and the exam harm largely disappeared. Harvard rebuilt CS50 around the same principle: its course AI is deliberately designed to guide students toward solutions rather than hand them over, and students rated it overwhelmingly helpful. And in a Stanford randomized trial with 900 tutors, an AI assistant that coached the humans raised student mastery by 4 percentage points overall and 9 points for the least experienced tutors. Used as a tutor, the machine lifts the people with the most to learn. Used as an answer machine, it quietly takes the learning with it.

For an individual developer, that translates into habits, none of them complicated. Attempt the problem before asking, so the answer lands on a real question. Read every diff you accept, and be suspicious of any tool or workflow that makes not reading the default. When AI writes something you could not have, have it explain the approach, then verify the explanation against the documentation, because a plausible explanation of wrong code is precisely what these systems are best at producing. Re-implement something it built for you, once, by hand. Keep some regular work AI-free the way runners keep easy miles. And own what ships: the accountability never transfers to the model. For teams, the same logic scales: hire juniors deliberately and put them where review happens, treat code review of AI output as the core activity rather than overhead, and measure productivity instead of trusting how fast everyone feels, because METR showed the feeling can be exactly backwards. Our own read on when automation is worth building at all is in a separate piece.

This is how we run it at NavoTech. We use AI every day, and every line that ships from our web development work is read, understood, and owned by a senior person who could have written it, which is the honest-scoping stance applied to our own craft. The new norm of the field is not the end of learning to code. It is the end of learning to code by accident. Shipping used to force the learning; now the learning is a choice you make on purpose, and the people who keep making it are the ones who will be qualified to check the machine's work, which is where the value, and the accountability, now live. If you want a build partner that treats AI that way, tell us about the project.

Sources

External sources are provided for verification. NavoTech is not affiliated with and does not endorse the organizations cited.

Written by the team at NavoTech Digital Solutions. Have a project or counter-example? Get in touch.