“A computer language is not just a way of getting a computer to perform operations, but rather a novel formal medium for expressing ideas about methodology.”
— Structure and Interpretation of Computer Programs
We hope AI can accelerate productivity and free our hands. But on the other hand, at the current stage, AI/LLMs still cannot reliably complete all coding requirements.
For example, the Defects4C study evaluated the automatic repair capabilities of 24 mainstream LLMs using real C/C++ bugs and vulnerabilities, and concluded that current LLM-based APR methods still have obvious limitations.1
You can still see how poorly AI performs on compilers, runtime internals, OS kernels, driver development, embedded systems, and database/storage systems.
The Live-kBench evaluation from February 2026 showed that, when using mini-SWE-agent with Claude Opus 4.5, the kernel crash resolution rate reached 74.16%, but the equivalent patch rate was only 19.85%.
In the long run, our dependence on AI may wear down our coding ability, ultimately weakening our ability to review a codebase, debug it, and start an entire project from scratch.
Some people suggest that all programmers should become product managers. Others say that in the future there will no longer be such a role as “programmer.”
If AI can eventually handle all code, is improving coding ability now just a form of self-entertainment?
This is a reasonable concern.
Coding skills with low verification costs, fast feedback loops, and errors that can be corrected cheaply, such as boilerplate code, CRUD, and application-layer logic with complete test coverage, will continue to decline in market value and may even approach zero.
But coding skills with high verification costs, slow feedback loops, and irreversible or highly costly error consequences, such as system-level work, safety-critical work, and architectural decisions that cannot be exhaustively verified with unit tests, will not decline in market value at the same rate just because AI generation improves. On the contrary, because the question of “who ultimately takes responsibility for high-risk code generated by AI” will always require humans, their unit value may be preserved or even increased.
Research on the Negative Effects of LLMs on Coding Ability
Anthropic’s RCT study asked 52 junior engineers to learn Trio, a Python async library, and divided participants into an AI-assisted group and a hand-written group.2
The engineers had to complete multiple coding tasks and then take a test. The AI group’s average test score was 17% lower than the hand-written group’s. AI made task completion slightly faster, but the improvement was not statistically significant.2
The largest gap appeared in debugging questions: the ability to identify why code is wrong and where it is wrong.2 The common pattern among high scorers was that they actively asked conceptual questions and used AI to verify their own understanding, instead of directly asking for answers. Low scorers either outsourced everything or treated AI as a debugging crutch.
The numbers in parentheses below are the test pass rates for each interaction pattern.
Low-score interaction groups:
- AI Delegation (39%): Participants in this group relied completely on AI to write code and complete the tasks.
- Progressive AI Reliance (24%): Participants in this group initially asked one or two questions, but eventually delegated all code writing to the AI assistant.
- Iterative AI Debugging (24%): Participants in this group relied on AI to debug or verify their own code. They asked more questions, but depended on the AI assistant to solve the problems.
High-score interaction groups:
- Generation-then-Comprehension (86%): Participants in this group first generated code, then manually copied or pasted the code into their own work. After the code was generated, they asked the AI assistant follow-up questions to deepen their understanding.
- Code-Explanation Hybrid (68%): Participants in this group asked hybrid questions, requesting both code generation and explanations of the generated code. Reading and understanding the explanations they requested took more time, but helped their understanding.
- Conceptual Inquiry (65%): Participants in this group asked only conceptual questions and relied on their improved understanding to complete the tasks. Although this group encountered many errors, they also solved those errors independently.2
Another observational study from Anthropic estimated task duration based on real Claude.ai conversations and argued that AI can save roughly 80% of time on some tasks. But the study also explicitly acknowledged that it could not calculate the time users spent outside the conversation continuing to verify, modify, and integrate the output.3 Therefore, what it measured was “how much time people who already know how to do the relevant tasks may save in real use,” not “whether beginners can use AI to learn new skills better.”
In 2025, METR conducted an RCT on experienced open-source developers: 16 developers completed 246 real tasks in mature open-source projects they were familiar with. When allowed to use AI tools, the developers actually completed tasks 19% more slowly.4
Even more absurd was the perception bias: before the tasks, they predicted AI would make them 24% faster; after completing the tasks, even though they were actually slower, they still believed AI had made them about 20% faster.4 This shows that the self-report “I feel AI helped me” is itself unreliable, and it also weakens the persuasiveness of some high-speedup data.
However, this METR result must be used with qualifications: in a 2026 update, METR explained that the early-2025 result was a historical snapshot. As tools and usage habits changed, new experiments became affected by selection bias, making it difficult to estimate the true current speedup of AI tools using the original design.5
A controlled experiment by Peng et al. found that developers using GitHub Copilot to complete a JavaScript HTTP server task were 55.8% faster than the control group, and less experienced developers benefited more.6 This appears to conflict with METR’s conclusion.
The difference most likely comes from task type and developer experience level: small, self-contained tasks with clear specifications and low context burden are easier for Copilot to accelerate; maintenance tasks in real million-line codebases require large amounts of context, review, and integration judgment.
In 2024, the University of Maribor conducted a 10-week experiment on 32 undergraduates learning React and found that using LLMs for code generation and debugging was significantly negatively correlated with final grades, while using LLMs for explanatory purposes had no significant negative effect.7 This pattern is almost identical to Anthropic’s result: two independent teams, different languages/frameworks, yet the same direction was observed.
Therefore, the framework “using AI for explanations = relatively safe; using AI for answers = skill erosion” is not a post-hoc explanation cobbled together after the fact, but a pattern that repeatedly appears across different research settings.
How Some Groups View AI-Assisted Programming
Programming is understanding. If you don’t understand what you are doing, you are not programming. You are generating text.
In June 2026, the Godot Foundation said that AI-generated contributions increased the number of PRs because the cost of submitting decreased, but review work and the number of reviewers did not decrease correspondingly, and it banned code that was entirely AI-assisted.
The Linus-style view is not “AI will not change programming,” but rather “AI will change the operational layer of programming, but not the responsibility structure of programming.”
The Stack Overflow 2025 survey showed that 84% of respondents were using or planned to use AI tools, but 46% of developers did not trust the accuracy of AI output, a higher share than those who trusted it; 66% of developers said their biggest frustration was that AI solutions were “almost right, but not quite right.”
Redis author antirez called AI-assisted software writing “Automatic Programming” and said that, in the right scenarios and in the right hands, it can greatly accelerate development.
In “AI crap,” Drew DeVault said that the machine learning bubble will remain, but the world will probably become worse; he believes Copilot will be used by mediocre programmers to write trivial code and boilerplate.
In its 2026 AGENTS.md commit, SQLite strengthened “SQLite does not currently accept agentic code” into “SQLite does not accept agentic code.”
In his 2024 article “They all use it,” Thorsten Ball said he understands people who think AI is overhyped, cannot reason, and generates garbage, but he does not understand programmers having no curiosity about a technology that is said to change the future of programming.
Will Coding Ability Still Be Needed in the Future?
First challenge the structure of this argument itself, then answer the substantive question.
This argument has a self-consuming flaw. [INFERRED, HIGH]
If AI can eventually handle all code, then improving coding ability now is self-entertainment.
If this logic holds, it can be applied to almost any skill: if AI can eventually write all novels, then writing practice is self-entertainment; if AI can eventually perform all diagnoses, then studying medicine is self-entertainment; if AI can eventually make all decisions, then studying management is self-entertainment.
This is an argument that proves too much. The problem is not that its conclusion is necessarily wrong, but that it does not explain what is special about programming that makes it more vulnerable than other fields to being defeated by this logic. The question we need to ask is not “will AI eventually replace programming,” but “after automation, will the residual value of programming as a skill fall to zero relative to other skills?”
How confident are we in the premise itself?
“AI will eventually be able to handle all code, from low-level OS code to application-layer code” — this is an unresolved prediction.
[GUESS/INFERRED, LOW-MED] The structure of reward signals and hardware-dependent feedback loops may be a natural friction point for the automation of system-level code. RL training requires verifiable, dense, and fast feedback signals. Application-layer CRUD code, if it has tests and clear specifications, fits this condition relatively well. But the correctness feedback for low-level system code often requires running real hardware, observing timing, and reproducing race conditions. This feedback loop currently cannot be provided at millisecond scale the way compiler errors can.
[INFERRED, MED] This means the timeline for automating “all code” will most likely not be synchronized across layers. Instead, it will probably advance from areas with dense and fast feedback signals, such as frontend, scripts, and glue code, toward areas with sparse and slow feedback signals, such as kernels, drivers, compiler backends, and distributed system consistency. There is currently no reliable estimate for the automation timeline of the latter.
The core question: even if AI can generate code, who verifies it?
This is more fundamental than “can AI write it?” [INFERRED, MED-HIGH] Verifying whether a piece of code is correct, safe, and maintainable is not necessarily easier than generating it, especially in scenarios without formal specifications and where understanding emergent system behavior is required, such as concurrency bugs, memory safety, and supply-chain attack surfaces.
If humans completely lose the ability to verify independently, then human “trust” in AI-generated code essentially becomes faith in the AI black box itself, rather than inspection of the specific code. This may be an unacceptable risk exposure in safety-critical systems.
(But it is also possible that we humans never needed reliable code.)
So even if AI can write 99% of code, the marginal value of being able to read code and identify errors will not decline linearly as generation capability improves. On the contrary, because generated volume may explode and review pressure may become concentrated on a small number of people, its unit value may increase.
This is also one of the reasons why Anthropic’s study saw the largest score gap in debugging: debugging is one of the skills that is hardest for AI assistance to “steal away,” yet also one of the easiest to degrade without deliberate practice.2
The frame of “self-entertainment” itself deserves to be dismantled.
You are equating “skill improvement” with “economic utility,” with the hidden premise that a skill only matters if it can be converted into irreplaceable productivity.
This premise itself is [FRAME]. It treats programming as a pure production tool, rather than something that can also be part of cognitive ability, aesthetic judgment, and agency.
Analogy: if you now learn C to write a text editor or learn Verilog, even if AI eventually writes better editors and better RTL, the “first-hand intuition for how systems work” that you gain will not lose value simply because “the result can be replicated by AI.” Unless you believe that “value” can only come from “irreplaceability,” and not from “understanding itself.”
This is a form of consolation, but it also points out an unproven value-theory assumption smuggled into this kind of question.
If we must give an actionable conclusion:
Given the uncertainty of the automation timeline, the rational strategy is not to ask “should I improve my coding ability,” but “in which direction should I invest?”
Bet on skills with the longest automation timelines, the slowest feedback loops, and the highest verification value: system-level understanding, architectural judgment, and the ability to debug low-level bugs. Do not bet on skills with the shortest automation timelines: memorizing API details and writing CRUD boilerplate.
Whether “coding has meaning” depends on whether we are pursuing market value, or the value of “coding” to the self.
What Should We Do?
These suggestions are for all ambitious programmers.
The human learning process and the model training process are essentially the same.
Both repeatedly go through the same loop:
learning -> feedback -> growthWe believe the core of coding ability can be broken down into the following five abilities:
- Writing from a blank file: Organizing code structure from an empty file without being pushed forward by generative suggestions.
- Debugging patience: Reading stack traces, narrowing the scope of hypotheses, and reliably reproducing bugs.
- Code review judgment: Identifying subtle correctness, security, maintainability, and integration issues.
- API and language fluency: Remembering common idioms, constraints, failure modes, and tradeoffs.
- Architectural taste: Because agents can generate code that looks locally reasonable but is globally chaotic.
1. Write the Design Yourself First, Then Ask AI
Before writing code, first write a short technical plan yourself:
Goal:
Input:
Output:
Core data structures:
Main functions:
Possible edge cases:
Areas I am unsure about:Then send this to AI and ask it to criticize your design. Do not let it start writing directly.
We can ask like this:
Please review this design. Point out incorrect assumptions, missing edge cases, complexity issues, and simpler implementation approaches. Do not write code directly.This way, what we practice is architectural thinking, not prompt engineering.
2. Write the Core Logic Yourself for the First 30 Minutes
For every feature, give yourself an AI-free period first, such as 30 minutes.
During this time, do only three things: write pseudocode, write interfaces, and implement the core path.
After getting stuck, then ask AI, and make the question specific:
I am stuck here. This is my code. This is the expected behavior. This is the actual behavior. Please first explain where the problem might be, then provide a fix.3. Before Accepting AI Code, Ask Three Questions
1. What is the responsibility of each function in this code?
2. What inputs will make it fail?
3. Is there a simpler implementation?This strengthens our code review ability.
If you cannot answer, do not merge it. Any code you do not understand that enters the project will become future technical debt.
We can also ask AI:
Please review this diff like a strict senior engineer. Focus on correctness, edge cases, security, and maintainability. Do not only comment on style issues.4. Make AI Quiz You in Reverse
After writing a feature, ask AI to generate questions based on your code:
Please ask me 10 questions based on this code to test whether I truly understand it. Include control flow, edge cases, complexity, potential bugs, and refactoring directions. Do not give the answers. Wait for my answers and then grade them.5. Ask AI to Explain “Why,” Not Just “How”
Why is this solution better than the alternatives?
What are the drawbacks of this solution?
When should this solution not be used?
Is there a lower-level principle behind it?6. Build One Small Project Without AI Every Week
At least once a week, complete a small task entirely without AI. The task can be very small:
Write a CLI todo app
Write a subset of a JSON parser
Write debounce/throttle
Write an LRU cache
Write a mini router
Write a file search tool
Write a toy markdown-to-html converterThe goal is not to reinvent the wheel, but to preserve the ability to start from a blank file.
An Optimal AI Workflow
Step 1: Write the requirements and technical design yourself
Step 2: Ask AI to criticize the design
Step 3: Write the core interfaces and main flow yourself
Step 4: Ask AI to help supplement tests and edge cases
Step 5: Implement the core logic yourself
Step 6: Let AI help you debug, but first ask it to explain the cause
Step 7: Review the diff yourself
Step 8: Let AI perform a second round of code review
Step 9: Write a summary: what you learned today, and where you are still shakyHow to Test Yourself
Ask yourself:
Without AI, can I write the core version from scratch?
Can I explain every piece of code AI wrote?
Can I find bugs in AI-generated code?
Can I write tests to prove it is correct?
Can I refactor it without breaking behavior?
Can I explain this design clearly to someone else?The more you let AI write, the more deeply you must read.
The faster you let AI help, the slower you must review.
Any code you cannot explain is not truly code you own.
“The purpose of computing is insight, not numbers.” — Richard W. Hamming
References
Footnotes
-
Jian Wang, Xiaofei Xie, Qiang Hu, Shangqing Liu, Jiongchi Yu, Jiaolong Kong, Yi Li, “Defects4C: Benchmarking Large Language Model Repair Capability with C/C++ Bugs,” arXiv:2510.11059, submitted 2025-10-13, revised 2025-12-02. DOI: https://doi.org/10.48550/arXiv.2510.11059. URL: https://arxiv.org/abs/2510.11059. Accessed: 2026-07-07. ↩
-
Judy Hanwen Shen and Alex Tamkin, “How AI Impacts Skill Formation,” Anthropic Research / arXiv:2601.20245, 2026-01-29. URL: https://www.anthropic.com/research/AI-assistance-coding-skills. Accessed: 2026-07-07. ↩ ↩2 ↩3 ↩4 ↩5
-
Anthropic, “Estimating AI Productivity Gains from Claude Conversations,” Anthropic Economic Research, 2025-11-25. URL: https://www.anthropic.com/research/estimating-productivity-gains. Accessed: 2026-07-07. ↩
-
Joel Becker, Nate Rush, Elizabeth Barnes, David Rein, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity,” METR / arXiv:2507.09089, 2025-07-10. DOI: https://doi.org/10.48550/arXiv.2507.09089. URL: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/. Accessed: 2026-07-07. ↩ ↩2
-
Joel Becker, Nate Rush, Tom Cunningham, David Rein, Khalid Mahamud, “We Are Changing Our Developer Productivity Experiment Design,” METR, 2026-02-24. URL: https://metr.org/blog/2026-02-24-uplift-update/. Accessed: 2026-07-07. ↩
-
Sida Peng, Eirini Kalliamvakou, Peter Cihon, Mert Demirer, “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot,” arXiv:2302.06590, 2023-02-13. DOI: https://doi.org/10.48550/arXiv.2302.06590. URL: https://arxiv.org/abs/2302.06590. Accessed: 2026-07-07. ↩
-
Gregor Jošt, Viktor Taneski, Sašo Karakatič, “The Impact of Large Language Models on Programming Education and Student Learning Outcomes,” Applied Sciences, 14(10), 4115, 2024. DOI: https://doi.org/10.3390/app14104115. URL: https://www.mdpi.com/2076-3417/14/10/4115. Accessed: 2026-07-07. ↩