When AI takes over part of a coding task, decide which parts you still need to understand and practice. You may not need to type all the code yourself, but you still need a way to develop the judgment required to review and maintain it.
A useful starting point is to separate the goals of the task. Sometimes you are applying a familiar approach and want to finish efficiently. Sometimes you are learning a library you will need to support. Those situations call for different levels of delegation.
Research gives reasons to be deliberate about that choice. Anthropic’s coding study found lower immediate quiz scores among developers using AI to learn an unfamiliar library. Separately, METR’s historical 2025 study found that experienced developers took longer on a particular set of real repository tasks when AI tools were allowed. These studies measured different things, so neither result should be used as a general verdict on AI-assisted development.
Decide what you are trying to learn
Suppose you are adding a background job using a queue your team already operates.
If you understand that queue well, generating familiar setup code may leave little new material unexplored. You can focus your review on whether the change follows the team’s conventions.
If this is your first time using the queue, you have more to investigate. You may need to understand when a job is considered complete, how failures are retried, and what happens during a deployment.
For that second task, consider writing down a learning goal before generating the implementation.
I need to understand what prevents a failed job from running indefinitely.
That goal gives you something to verify while working. It also helps you choose which parts of the documentation deserve attention.
Do not rely only on how productive the session felt
In a 2025 randomized study, METR recruited 16 experienced open-source developers to work on 246 tasks in repositories they knew well. Tasks were assigned to allow or disallow AI assistance. With AI allowed, developers took 19% longer on average. Afterward, they still estimated that AI had reduced their completion time by about 20%.
The result applies to those developers, tasks, repositories, and early-2025 tools. METR now labels these results as out of date and says they no longer reflect the current impact of AI models on open-source developer productivity. This example illustrates a historical gap between perceived and measured speed, not a current estimate of AI performance.
It does show why a feeling of speed is not enough to evaluate a workflow. Time spent generating code is only part of the task. You also need to account for reviewing the result and making it fit the project.
For your own work, keep the measurement modest. Compare similar tasks and note where time goes. A few observations will not produce a controlled study, but they may reveal that a workflow needs adjustment.
Keep an independent attempt in the process
When learning something unfamiliar, try forming an answer before requesting one.
For the queue example, read the retry configuration and predict what happens after repeated failures. Then ask the assistant to check your explanation against the relevant code or documentation.
This gives you an answer to compare with the feedback. If the assistant disagrees, investigate the difference rather than replacing your explanation immediately.
Anthropic observed that some participants who stayed engaged through conceptual questions and explanations retained more than those who handed over most of the task. The study supports paying attention to interaction patterns, although it does not establish this exact workflow as a proven intervention.
Ask for review that teaches something specific
“Can you explain this?” can produce a long response without resolving your uncertainty.
A more useful request names the part you are trying to understand.
I think the job stops retrying after this condition becomes true. Check that interpretation and show me the relevant code path. Do not rewrite the implementation yet.
If you are working with a senior engineer, the same question helps them review your reasoning. They can point out a missing condition or show why the system behaves differently in production.
Before moving on, make a small change to the scenario and see whether you can still explain it. For example, ask what happens if the job fails after completing only part of its work.
If your answer remains uncertain, keep that question visible in the review. It is more useful than a broad note saying you have read and understood the code.