TL;DR
As agents write more code, engineers review more and write less, and the working model of the system can move out of their heads into a chat history. Keep the standard that you can explain every accepted change without the chat. Review plans rather than every line, keep changes small, record decisions in the repository, and test yourself with teach-backs and debugging drills. These are practices to try, not measured cures; they show where your understanding has gaps.
Six-thousand-line diffs and a sense of lost control
In September 2026 a developer asked on Lobsters how to survive code review when coworkers rely heavily on AI and pull requests arrive averaging around six thousand lines of diff. They still believed that people should understand how the systems they build work, and they asked for organizational or personal strategies.
In July 2025, after using Cursor intensively for most of a year, someone asked on Hacker News whether AI coding had gone too far, because they felt they were losing control of their own projects. They asked how others balance the power of these tools with remaining in charge of their own codebase.
One is about a team's reviews, the other about one person's grasp of their own code; both ask whether the humans can still explain the system.
What the evidence does and does not say
The most directly relevant study is a randomized trial by Anthropic researchers, published as a preprint in January 2026 (Anthropic research summary, paper). Fifty-two mostly junior developers learned an unfamiliar Python library, Trio, with or without a chat assistant, then took a quiz. The assisted group averaged 50% against 67% for those who coded by hand, the largest gap was on debugging questions, and the time saved was not statistically significant. Participants who used the assistant to ask conceptual questions or request explanations tended to score better, though the authors state that this analysis does not establish a causal link. The limits matter: a small sample, a quiz straight after the task, a new library rather than a familiar codebase, a chat assistant rather than an agent, and mostly junior participants.
A second study looked at the question from the other direction: whether code written with AI assistance is harder for other developers to change later (Echoes of AI). In a registered experiment with 151 participants, most of them professional developers, people who later modified AI-assisted solutions without AI showed no significant difference in time or code quality. It did not measure the original author's understanding.
A widely cited METR study of early-2025 AI tools found that experienced open-source developers took 19% longer on tasks with AI while believing it had sped them up (METR, July 2025); METR's February 2026 follow-up on later tools was inconclusive. It measured time, not understanding, so it is not evidence either way on this question, only a reminder that self-assessment and measurement can diverge.
Decide what you must be able to explain before accepting a change
The line to hold is not "I read every line". It is "I can explain this change without the chat". For any change you accept, you should be able to say, in a few sentences of your own:
- Why this approach. What alternative was considered and why this one was chosen.
- How data moves through it. The path from input to storage or output, and which components it now touches.
- What happens when it fails. Errors, retries, timeouts and what the user sees.
- What it changed beyond the obvious place. Shared code, configuration, schemas, other callers.
- How you would know it broke. Which test or signal would catch a regression.
If you cannot answer one of these, ask the agent to explain that part with file and line references, then open those files and confirm the explanation. Codex's prompting guide suggests exactly this kind of check for codebase explanations: ask for a numbered list of steps and the files involved, then verify it (Codex prompting). An explanation you have not checked against the code is just more generated text.
Stay in the design without rereading every line
Most of the understanding that matters is in the design, and the tools let you engage there before code exists. Claude Code's plan mode, Codex's /plan and Cursor's Plan Mode all have the agent research and propose a plan that you review, question and edit before it writes code (Cursor Plan Mode). Reviewing a plan you can argue with is a better use of attention than reviewing six thousand lines you cannot.
Three other habits keep you close to it:
- Ask before it acts. Read-only question sessions, Claude Code's approach of asking the questions you would ask a senior engineer, Codex's codebase-explanation prompts and Cursor's Ask mode, let you build your own model of an area before the agent changes it.
- Keep changes small enough to understand. Replies in the Lobsters thread, community opinion rather than research, argued for smaller pull requests, and one described a hard size limit that applies whether a person or an AI wrote the code.
- Use explanation features deliberately, knowing what they are. Claude Code's Explanatory output style adds short insight notes about its choices, and its Learning style also leaves small pieces marked for you to write yourself (Claude Code output styles). No measured benefit for these styles was found; they are a way to put the explanation-seeking behavior the Anthropic study associated with better scores into your routine. Codex's documentation has no equivalent learning mode.
Build a routine that keeps ownership with the engineer
Understanding erodes through routine, so keep it through routine too:
- Write some changes yourself in areas agents work in regularly, especially the ones you would have to debug at night.
- Describe each accepted change in your own words in the pull request: the approach, the data flow and the risk, not a pasted summary.
- Record decisions in the repository, with the reason, where the next person, and the next session, will find them. What to save for a new AI coding session lists what such a record needs.
- Rotate review of agent-heavy areas so more than one person can explain them.
Paqad supports the parts of this that are about the work rather than the person. Each change moves through reviewable stages, from planning, and specification where the lane requires it, through implementation, review, checks and documentation, with artifacts recorded for each, and project questions are answered from the repository's own sources. That keeps intent and decisions visible in the repository. It is not a teaching or assessment system, and it does not tell you whether an engineer understands the code. If you want those records produced as a matter of course, Paqad's workflow documentation describes the stages and what each one leaves in the repository.
Check whether you still understand it
The only way to know whether you have kept your understanding is to test it, and you can do that without a study:
- Teach-back. Once a week or so, explain a recent agent-written change to a colleague without the chat or the pull request open, then compare what you said with the code.
- Debugging drill. Take a real bug from a recent incident, or a reverted change, and diagnose it without the agent within a fixed time. Note where you got stuck.
- Record the gaps, not a score. Where you could not explain or diagnose something, that area goes on the list for a written change, a design walkthrough or a closer review next time.
If you want evidence for your team, run these for a few months and compare how quickly issues in agent-heavy areas are diagnosed with and without the agent. If your established codebase is a Laravel application, the article on using AI to add features to an existing Laravel application shows how to brief and test a small first feature.
Frequently Asked Questions
How can I use AI coding agents without losing my understanding of the codebase?
Treat "I can explain this without the chat" as an acceptance criterion, like passing tests. If an explanation needs the conversation open, the change is not yet yours, however correct it is.
Which parts of a change must I be able to explain before accepting it?
The five in the checklist above. If one is unclear, ask the agent for that part with file and line references and confirm it in the code; the debugging and failure questions deserve the most care, since debugging showed the largest gap in the one study that measured comprehension.
How can I stay involved in design decisions without rereading every generated line?
Spend your review time where the choices are made: on the plan before code exists, and on interfaces, schemas and shared code in the diff. Lines that follow from an approved plan need less attention than lines that change what other code depends on.
What review and learning routine keeps ownership with the engineer as output increases?
A routine with a fixed cadence: some changes written by hand each sprint, a description in your own words on every pull request, and rotated review of agent-heavy areas. Treat explanation features as aids, not as evidence that understanding is intact.
How could we test whether I can diagnose and change the system later without depending on the original chat?
Use real material: a recent incident or reverted change, a fixed time limit and no agent. The useful output is the list of places you got stuck, which tells you where to write, walk through or review more closely next time; without a comparison over months, treat it as a personal signal rather than a measurement.