The Catcher in the AI

0/ The Edge

In Chapter 22 of J. D. Salinger’s The Catcher in the Rye, Holden Caulfield imagines children playing in a field near the edge of a cliff. He wants to stand where they might fall and catch them before they disappear over the edge. There is something deeply human in that image: the desire to recognize a danger that someone else has not yet learned to see, and to be there when they need you. That scene has been on my mind as I think about the next generation of software engineers.

Holden’s wish also carries a question about how much protection allows a person to grow. In Chapter 25, watching Phoebe reach for a gold ring on a carousel, he accepts that she must be allowed to try even though she might fall. I want to keep that tension in view. Engineers need room to experiment, encounter failures, and develop their own judgment, alongside support at the moments when their decisions carry consequences for others.

Imagine a new graduate completing a feature with an AI agent. Files change, tests pass, and the application starts doing what was requested. The engineer submits the work, receives approval, and moves to the next task. Everything visible suggests progress, but one question remains unanswered: how much of that progress happened inside the person who will now be responsible for the code?

That is the edge I am concerned about. We can create an environment in which a person’s output grows much faster than their understanding, and then reward the output so consistently that nobody has a reason to examine the distance between them. By the time an unfamiliar failure exposes that distance, we may have already entrusted the person with a system they cannot confidently explain or repair.

0.0/ The Tri-Nature of the Developer

I approach this through the theory that guides what I build, write, and teach: tri-nature. In The Standard, I describe every system through its dependencies, purpose, and exposer. A dependency is what the system needs to survive, evolve, and fulfill itself and its purpose. Purpose is what the system exists to fulfill. Its exposer is how it introduces its capabilities to other systems so that they can depend on it.

A user interface depends on a backend API through that API’s exposer. The API, in turn, has its own purpose, dependencies, and exposer, just as the interface does. The relationship continues through the larger system. Each part has something it needs, something it exists to accomplish, and something it makes available to others.

Dependency, purpose, and exposer describe the system and its relationships. Physical, intellectual, and emotional describe the dimensions through which I will examine the effects of a dependency on the person. A single dependency can affect all three, changing what someone can do, what they understand, and how they experience their work. Those effects can influence both the purpose they fulfill and the capabilities others depend on them to provide.

An AI agent becomes one of the developer’s dependencies. The developer still has a purpose to fulfill and capabilities that teammates, organizations, and users depend on. The question is whether this new dependency helps the developer grow into that responsibility. If the system produces more while the person understands less, we have a relationship that deserves immediate attention.

0.1/ What the Research Shows

There is already evidence that this can happen. In a January 2026 randomized study from Anthropic, 52 mostly junior software engineers learned an unfamiliar Python library. Those with AI assistance averaged 50 percent on a subsequent comprehension quiz, compared with 67 percent among those without it. That was a 17 percentage point difference, and the largest gap concerned debugging. The AI group finished slightly faster, but the speed difference was not statistically significant. The difference appeared in what participants understood after completing the work.

The broader research prevents us from turning that finding into a blanket judgment about junior engineers. Three workplace experiments involving 4,867 developers estimated a 26.08 percent increase in completed tasks with AI assistance, with larger gains among less experienced developers. Meanwhile, a study of 275 introductory programming students found higher exercise scores with AI but no corresponding advantage in knowledge gains or code comprehension. These findings make the distinction between delivery and development impossible to ignore. Measuring one does not establish the other.

The evidence discussed here combines short learning experiments, observations of novice programmers, and workplace surveys and interviews. Experiments support causal conclusions within the tasks tested; observations and self-reports help identify patterns and experiences. Together they justify concern about learning and oversight, while leaving the long-term effects on careers unresolved. The scenarios that follow about helplessness, detachment, and costly failures describe risks to investigate, rather than measured outcomes for an entire generation of engineers.

0.2/ The Physical Impact

The first consequence I want to examine is physical in the practical sense of being able to act upon the system in front of you. Can you investigate the failure, inspect the relevant state, and make an informed change? What happens when the agent becomes unavailable, repeats the same unsuccessful approach, or confidently recommends something that makes the problem worse?

In the extreme, dependence can leave a developer effectively immobilized at the keyboard. They can request another attempt, but cannot identify a useful next step themselves. Some slowdown without a useful tool is expected. The meaningful question is whether the person retains enough understanding to investigate, verify, and seek appropriate help when the dependency fails.

This is a familiar engineering responsibility applied to a human dependency. When an application relies on an external service, we examine failure behavior. We should bring comparable care to a workflow that relies on an agent. An engineer needs some path forward when that agent stops being useful, particularly when other people depend on the engineer’s judgment.

0.3/ The Intellectual Impact

The intellectual consequence reaches further because it affects how that judgment develops. An experienced engineer may have skills that become less practiced. A new graduate may never have acquired those skills in the first place. If the agent repeatedly performs the investigation, selects the explanation, and chooses the correction, the task can finish without the developer practicing those decisions.

A 2024 observational study of novice programmers makes this concern particularly clear. Twenty of the 21 participants completed the assigned programming problem, yet the researchers observed substantial differences in how they worked. Some used AI to implement an approach they understood and rejected unhelpful suggestions. Others struggled to assess their progress and finished with an inflated sense of their competence. Completion alone would have obscured those differences in how participants approached the work.

Automation bias compounds this risk when an automated recommendation receives more trust than the evidence justifies. In a survey of 319 knowledge workers, greater confidence in generative AI was associated with less reported critical thinking. That association raises a practical question for teams: what encourages someone to challenge a recommendation from a tool they have come to trust?

A clear explanation can make a decision feel understood before the reader has tested it. I want the developer to be able to change a condition, challenge an assumption, and explain why the answer should change. Understanding needs to survive beyond the particular example the agent supplied. Otherwise, familiarity with the explanation may be mistaken for the ability to reason about the system.

Engineers have long relied on compilers, IDEs, search engines, and Stack Overflow. The question is how much reasoning we delegate while expecting the developer to remain responsible for the result. An agent can investigate a failure, propose a diagnosis, implement a correction, and explain why it believes the result is sound. When someone delegates that whole sequence, we need another opportunity for them to practice evaluating the reasoning.

0.4/ The Emotional Impact

The emotional consequence becomes visible in how people describe their changing relationship with the work. In Anthropic’s internal research, which included a survey of 132 engineers and researchers and 53 interviews, some participants described concerns about skill erosion, reduced interaction with colleagues, and changes in the satisfaction they found in programming. Others described excitement, broader capabilities, and better opportunities to learn. Within that workplace, increased capability could coexist with uncertainty about professional identity and satisfaction.

Consider what it might feel like to watch an agent change more of an application than you can follow. You remain responsible for the result, but your understanding of the current state falls behind each new action. You can interrupt the process, yet struggle to decide when an interruption is necessary or what to ask for afterward. Having a stop button offers limited reassurance when you cannot judge the direction of travel.

That is the kind of detachment I want us to recognize early. Within tri-nature, the developer depends on the agent while other people depend on the developer. That position can become difficult to inhabit when responsibility grows without a matching understanding of the work. We should make it possible to admit that difficulty, ask for help, and regain orientation without being treated as an obstacle to delivery.

0.5/ The Cost to the Organization

Those three effects on the person can carry costs for the organization that depends on them. For an engineering leader, the question becomes how those costs affect delivery over the life of a system. Consider a feature completed quickly with an agent that later fails in production. If its owner cannot trace the failure, a senior engineer may have to reconstruct the reasoning while customers wait. The time saved during implementation can reappear as longer diagnosis, more people pulled into an incident, and delayed work elsewhere. The original ticket would capture little of that later cost.

The cost can also accumulate through ordinary changes. A workaround added without understanding a dependency can make the next feature harder to implement. Repeated local fixes can weaken the architecture until a routine change requires extensive investigation and rework. In tri-nature terms, a team can keep expanding what a system exposes while losing its understanding of what that system depends on and which purpose each part serves.

Management should therefore examine delivery speed alongside review effort, rework, recovery time, and the concentration of knowledge in a few people. A comprehension check has a visible cost on today’s schedule. Its business case rests on whether it reduces the larger cost of investigating and changing a system later. Teams can test that case against their own results, including whether more engineers become capable of resolving failures without always depending on the same expert.

1/ Becoming the Catcher

Those of us who lead engineering teams participate in creating these conditions. We choose deadlines, assign unfamiliar work, and decide which accomplishments receive recognition. If comprehension receives no time on the schedule and no attention in review, we should examine our own decisions before expressing disappointment that someone prioritized completion.

Before adding any comprehension check, the team needs to agree on what happens when someone cannot answer a question. There should be time to investigate, someone available to help, and a clear expectation that admitting uncertainty is responsible engineering. Senior engineers should participate in the same practice and make their own gaps visible. The questions should be proportionate to the consequences of the change, so people understand why a particular decision deserves closer attention.

This agreement needs to reach the schedule and the review process. Learning time belongs in the estimate, and a developer who pauses to clarify an assumption should receive support for doing so. Individual comprehension records should remain under the developer’s control, with sharing based on explicit consent. Turning them into rankings would give people a reason to optimize their appearance of understanding. We need a culture in which evidence of uncertainty leads to help.

1.0/ The Comprehension Gate

I have been exploring ways to make understanding part of the workflow itself. One practice I have been trying is the Comprehension Gate: an agentic skill that requires the agent to quiz the developer before committing code or carrying out an irreversible change. A commit provides a useful checkpoint even though it can usually be reversed. For an action that cannot easily be undone, the conversation must happen before the action takes place.

The depth of the check should match the decision. A reversible local commit may need only a brief explanation of what changed and why. An operation that deletes production data requires a much fuller account of consequences and recovery. Between those checkpoints, developers need room to try an approach, discover why it fails, and revise it. A failed experiment in a controlled setting can be part of the learning the gate exists to support.

The questions should connect directly to the responsibility the developer is accepting. If the agent introduces a retry policy, the developer should explain what happens when a request succeeds but its response is lost. If the agent changes a data contract, the developer should identify which consumers depend on it. If a migration discards information, the developer should understand what will disappear and what recovery would require.

Tri-nature gives this examination a consistent foundation. What purpose does the change serve? Which dependencies does it introduce or alter? What does the exposer promise to the systems that consume it? Answering these questions requires the developer to place the change within relationships that already exist, rather than simply describe a new function in isolation.

The gate should reveal where teaching is needed. When an answer exposes a misunderstanding, the agent can explain the concept, work through an example, and then ask a different question that requires applying it. The developer should have an opportunity to become ready to approve the change. A quiz that merely pressures someone to repeat the expected wording would miss the purpose entirely.

This practice also needs honest limits. An agent can generate an incorrect explanation or evaluate an answer too generously. A skill instruction alone does not guarantee that an agent will pause, and passing a quiz cannot certify that code is correct. Where the pause must be dependable, the surrounding workflow needs to enforce it. Human review and independent verification remain necessary, and the learning value of the gate needs to be measured through later performance.

Code review is another place to practice this responsibility. In the opening example, someone approves the completed work. That reviewer can ask the author to explain an altered assumption, identify the consumer affected by a contract change, or describe the evidence that would invalidate the chosen approach. The review then becomes an opportunity to examine the reasoning and help the author strengthen it.

Reviewers also need to understand what they approve. When they use AI to help review a change, they should check consequential findings against the code and requirements and make their own uncertainties visible. Responsibility travels through this relationship: the author depends on meaningful review, and the reviewer depends on an explanation they can interrogate. Both have a part in helping the team develop dependable judgment.

1.1/ Learning as You Go

The second practice is learning as you go. I want the agent to teach while it works, with explanations connected to decisions the developer can inspect. Before changing a component, it can explain the purpose of the change and the dependencies involved. When a test fails, it can ask the developer to interpret the failure before presenting its diagnosis. After a correction, it can show which observation supports the conclusion that the problem was addressed.

This teaching needs restraint and participation. A continuous stream of explanations can become another body of text the developer learns to ignore. The agent should make room for predictions, questions, and small decisions, then adjust its teaching to the answers. The developer can take responsibility for part of the investigation and compare their reasoning with what the agent proposes.

Within Anthropic’s skill-formation experiment, the exploratory analysis of interaction patterns offers a useful clue. Participants whose interactions involved explanation seeking and conceptual inquiry had stronger learning outcomes than those whose patterns centered on delegation. That association gives us a direction to test: keep the developer actively reasoning as the work proceeds.

1.2/ The 10,000-Foot View

The third practice is the one I consider essential, and the one I have yet to build: a continuous 10,000-foot view of the work. A developer should be able to step back at any moment and see where the current action belongs. This is where the way I model systems in The Standard becomes particularly useful. Dependencies, purposes, and exposers provide a structure for understanding both an individual component and its place within something larger.

Imagine the agent implementing an order cancellation feature. The developer should be able to see the interface requesting cancellation, the API exposing that capability, the service applying the business rules, and the dependencies involved in storage or payment processing. Each system has its own tri-nature. A change to one exposer may affect another system’s dependency, and the view should make that relationship visible.

As the agent works, that view should distinguish what it intends to change from what it has actually changed and verified. The developer should see which part is active, why it is being changed, which other parts may be affected, and which questions remain unresolved. They should be able to move from the overview to the relevant code or test without losing their place in the larger system.

A visualization has to earn the trust placed in it. It should stay connected to the repository and observed execution, with uncertainty made explicit. If an agent is unsure whether a dependency exists, the view should say so. If the plan changes, that change should be visible. A reassuring diagram that no longer describes the application would create another obstacle to understanding.

1.3/ Witnessing Understanding

Once a team makes room for these conversations, a record can help identify which ideas need further attention. I have built an early reference implementation called Witness that connects decisions to the ideas they depend on and records evidence of the developer’s engagement. Accepting an answer alone provides no evidence of understanding, even when the person privately understood it. The absence of a record cannot establish that someone did not think.

Where an idea came from and whether someone understands it are separate questions. Suppose an agent introduces exponential backoff with jitter, which varies the time clients wait before retrying. If the developer independently predicts that removing the jitter could cause synchronized retries, and a later test confirms that prediction, Witness’s evidence model can credit demonstrated ownership of an idea that originated with AI. A correction or an application in a new context can provide evidence too.

The specification explains how that evidence determines the indicator. Copied explanations receive no credit, and a person’s declaration of understanding remains distinguishable from a demonstration. The developer can inspect and correct the record.

Today, Witness accepts supplied evidence classifications and produces a terminal readout. Live observation, an automated judge, and editor integration remain planned, along with validation of whether its indicators predict understanding on later tasks. It is an experiment that could help a developer choose what to revisit and help a Comprehension Gate ask a more useful question.

These practices and tools should be evaluated by what developers become able to do over time. Their value should appear in stronger explanations, more informed challenges, and the ability to apply knowledge to an unfamiliar task, with reviewers and mentors helping people build that independence.

2/ The Future We Can Build

I am hopeful about what becomes possible if we take that development seriously. A junior engineer could have access to patient explanations while working through a real problem, revisit a concept without embarrassment, and explore alternatives that would once have taken much longer to investigate. Experienced colleagues could use the resulting questions to spend their time on deeper reasoning and the context that comes from knowing the people and systems involved.

That future requires deliberate choices about what we optimize. If every saved minute becomes another assignment, teaching will remain under pressure. If the only celebrated outcome is the amount of work completed, we will keep making it difficult to notice whether the person is growing. We need to examine what developers can understand and take responsibility for over time, including when an agent is mistaken or unavailable.

My hope is that a developer who begins by needing extensive guidance gradually becomes capable of guiding others. Their dependencies should support that evolution, their purpose should remain clear, and the capabilities they expose to the people around them should become more dependable. That is the relationship I want to build between human development and artificial intelligence.

I return to Phoebe reaching for the ring in Chapter 25 because the freedom to try belongs in this future too. A mentor needs judgment about when to offer help, when to require an explanation, and when to leave room for an experiment to fail. Those of us with experience can help establish that room and recognize the decisions whose consequences extend beyond it. The person we support today may eventually become the colleague who offers that same care to someone else.

I want us to build technology that makes that future possible. Every system we deliver becomes part of someone else’s world, and every engineer we help develop becomes someone others can depend on. Both deserve our care.