Coding with AI: delegating without losing control

Coding agents speed up some tasks, but supervising them depends on skills that need to be practised. What studies and engineers actually allow us to say.

A coding agent can write code, run commands and carry out several steps in a row without waiting for an instruction each time. The developer’s work then shifts: less typing, more framing and checking. But there is a less visible question than the time saved: if we practise certain tasks less, how do we retain the skills needed to spot an error or take back control?

This risk is discussed by engineers who use these tools every day, but it should not be confused with a proven, lasting loss of skill among all developers. The available evidence mainly describes uses, perceptions and experiences relating to specific tasks. It nevertheless helps us understand where delegation can become fragile, and how to make oversight more tangible.

Delegating code does not mean delegating responsibility

In a piece about the use of coding agents, Addy Osmani, an engineer at Anthropic and a member of the Claude Code team, distinguishes between three degrees of delegation. At the first, the agent produces a proposal for the person to examine. At the second, that proposal becomes the starting point for the work. At the third, it is adopted without any real scrutiny. Wharton researchers describe this attitude as « cognitive surrender ».

The difference lies less in the tool than in the role the user retains. A developer can let an agent write a function while remaining responsible for understanding what it does, checking that it meets the need and deciding whether it can be integrated. Conversely, a technically plausible answer may be accepted because it is well presented or because the first test passes.

A successful test only demonstrates what it checks. If the test repeats an erroneous assumption from the function it is supposed to check, both can fail to detect the problem. Useful verification therefore also means examining the test’s scope: which cases does it cover, which does it leave out, and what assumptions must be accepted for the result to be reliable?

Usage gains do not measure learning

A study published by Anthropic in 2025 provides a snapshot of the changes observed within the company. It draws on a survey of 132 engineers and researchers, 53 interviews and an analysis of 200,000 internal Claude Code transcripts collected in February and August 2025. In the survey, employees estimated that they used Claude for 59% of their work and attributed an average productivity gain of 50% to it. These figures are self-reported: they describe employees’ perceptions, not an independent measurement of the time actually saved.

The analysis of the transcripts, meanwhile, shows a shift in the distribution of uses. Between February and August, the proportion of transcripts classified as relating to the implementation of new features rose from 14.3% to 36.9%, and the proportion classified as relating to code design or planning rose from 1% to 9.9%. The tool also carried out more actions before the next human intervention. These findings indicate that teams were entrusting Claude Code with more complex or more autonomous tasks. On their own, they do not measure an increase in total workload or the skill level of each individual.

The interviews reveal a possible downside to this change. Some participants say they are becoming more comfortable in areas they knew little about, because AI makes it easier to create a first version or explore unfamiliar code. Others worry that they are learning less by solving problems themselves: reading documentation, examining how a tool works or tracing an error can impart knowledge that is not essential to an immediate fix, but later helps them understand the system as a whole.

Anthropic points out that its participants are employees of a company that develops these tools and have access to them in a particular context. Responses may also be influenced by the selection of interviewees and the self-reported nature of some measures. This work sheds light on trade-offs observed in that organisation; it does not allow us to conclude that developers in general permanently lose their skills when they use AI.

Supervision requires knowing what you are checking

This is the practical paradox of supervision: to evaluate an agent’s code, you need enough knowledge to spot what is dangerous, incomplete or ill-suited. Yet the participants interviewed by Anthropic express concerns precisely about retaining the skills used both to write code and to critique it. A few therefore say they set aside time to programme without AI, so they can continue practising this expertise.

This choice does not answer every question. In particular, it remains to be determined which skills are essential in work where tools are changing the tasks entrusted to engineers. Some employees interviewed envisage a shift towards design, review or agent coordination. Others regret losing direct coding practice or wonder about training beginners. The study reports these views; it does not settle the future of the profession.

The findings of another study, discussed by its authors in Wharton Magazine, draw attention to the acceptance of generated answers. Participants could consult ChatGPT to solve logic and reasoning questions. Steven Shaw explains that, in the experiments, people who consulted the tool frequently adopted its answer, including when it was incorrect. These exercises shed light on behaviour in an experimental setting; they measure neither the quality of a developer’s work in a company nor a lasting erosion of their abilities.

Oversight proportionate to the stakes

Addy Osmani does not recommend checking every task with the same degree of rigour. A low-risk task that is easy to correct does not necessarily require the same scrutiny as a change that could affect security, data or deployment. Before an important task, he suggests formulating your own hypothesis, then looking for what might make the agent’s answer wrong. He also advises asking it to explain its choices and the default values it used.

For a software change, these steps can be translated into concrete questions: what behaviour should change? Which parts of the system will be affected? Which cases does the test actually cover? Has the agent introduced a dependency or an assumption that the team has not examined? A useful review is not simply a matter of rereading the result; it compares that result with criteria defined before it is accepted.

The question, then, is not whether to write every line yourself or leave everything to an agent. It is about deciding which operations can be delegated, retaining enough understanding to supervise important decisions, and checking that working habits continue to develop the skills needed. The speed of execution is visible as soon as code is generated. The ability to take it back, meanwhile, is measured when it has to be explained, corrected or developed further.