The useful test is not how much code the developer typed. It is whether they can explain, test and maintain what they ship.
A pull request can hide the real question
A junior developer submits a working feature. An AI coding tool produced much of the first draft. The tests pass, but the manager wonders: did the developer learn anything, and is the code safe to merge?
Those are two different questions. One is about the developer’s growth. The other is about the software’s readiness. Combining them leads to poor decisions, such as banning useful tools or accepting code simply because it works in a demo.
AI-assisted coding counts as learning when the developer actively understands and improves the output. It does not count as learning when generated code replaces investigation, reasoning and feedback.
Typing was never the same as learning
Developers have always used abstractions, frameworks, documentation, search engines and copied examples. We do not judge their ability by whether they typed every character. We judge whether they can solve a problem responsibly.
AI changes the scale of assistance. It can produce a complete-looking solution before the developer understands the problem. That makes weak understanding harder to see. A plausible answer can pass a simple test while still mishandling errors, security boundaries, concurrency or the conventions of the codebase.
The right question is not, “Did AI write this?” It is, “Can the developer take responsibility for this?”
A learning loop that keeps the developer in control
The loop matters more than the percentage of generated code. A developer may type very little and still learn deeply by tracing behaviour, comparing alternatives and fixing failures. Another may type everything manually and learn little by repeating a pattern they do not understand.
Separate learning evidence from release evidence
Managers need evidence for both development and delivery.
| Question | Useful evidence | Weak evidence |
|---|---|---|
| Does the developer understand the change? | Explains the data flow, trade-offs and failure paths | Says the tool recommended it |
| Can they debug it? | Reproduces a failure and traces it to a cause | Regenerates code until tests pass |
| Is the code ready? | Focused tests, review, security checks and observable behaviour | It compiles or looks familiar |
| Are they becoming more independent? | Solves related tasks with less guidance over time | Produces more lines of code |
This also avoids a common mistake: treating tool use as misconduct while leaving ordinary code quality controls weak. Code should earn trust through review and evidence, regardless of who or what drafted it.
What AI is good at—and where juniors need care
AI tools can be useful for repetitive code, test scaffolding, unfamiliar syntax, documentation and exploring possible approaches. They can help a developer move past a blank page.
They are less reliable when the task depends on hidden business rules, local architecture, security assumptions or incomplete context. They may invent APIs, overlook failure modes or produce code that passes a narrow test but does not fit the system.
Research also warns against simple productivity stories. In a 2025 randomized study, METR found that experienced open-source developers took longer on the measured tasks when using early-2025 AI tools, even though participants expected to be faster. METR later said that wider adoption and selection effects made its follow-up data difficult to interpret. The lesson is not that AI always slows developers down. It is that confidence, code volume and benchmark scores are poor substitutes for measuring real work.
What managers should change
Review reasoning, not prompt history. Ask the developer to explain why the change is designed this way, what could fail and which alternative they rejected. The goal is to test understanding, not to stage an interrogation.
Require normal engineering evidence. Generated code needs tests, review, security checks and operational thinking. It should not receive a lower standard or a magical higher one.
Create tasks that expose understanding. Ask the developer to modify the solution, diagnose a planted failure or explain the request path. These exercises reveal whether knowledge transfers beyond the generated answer.
Protect time for fundamentals. Juniors still need practice reading code, debugging, using documentation, modelling data and reasoning without an assistant. A tool should shorten low-value work, not remove every productive struggle.
What junior developers should do
Before opening a pull request for AI-assisted code, be able to answer:
- What problem does this change solve?
- What data enters and leaves each important function?
- Which assumption is most likely to be wrong?
- What happens when a dependency fails?
- Which tests prove the behaviour rather than merely execute the code?
- Could I maintain this change after the conversation with the tool is gone?
If you cannot answer one of these questions, that is not a reason for shame. It is a sign that the work is not finished.
Know, use or master?
Know: Every developer should understand that generated code can look complete before it is understood.
Use: Junior developers and reviewers should practise the inspect–test–explain loop on everyday work.
Master: Engineering managers and technical leads should design review, mentoring and evaluation systems that measure judgement and growth rather than typing speed.
The practical answer
Yes, AI-assisted coding can count as learning. The proof is not that the feature works once. The proof is that the developer can explain it, test it, change it and respond when it fails.
Organizations should hold code to an evidence-based release standard and developers to a visible learning standard. That is fairer—and safer—than measuring how many lines came from a human keyboard.
Go deeper
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — METR, 10 July 2025. A randomized study showing why perceived speed and measured task time can differ. Reviewed September 2026.
- We Are Changing Our Developer Productivity Experiment Design — METR, 24 February 2026. Explains the selection and measurement problems in its follow-up work. Reviewed September 2026.
- Google Engineering Practices: How to Do a Code Review — Google. Practical review guidance that applies to human- and AI-assisted code. Reviewed September 2026.
- 2025 Stack Overflow Developer Survey: AI — Stack Overflow, 2025. Survey evidence on developer use, trust and frustration with AI tools. Reviewed September 2026.