Turn your developers into engineers

You keep engineers learning while an agent writes the code by teaching them the reasoning behind the changes that ship, at the moment they touch that code, and by measuring which parts of the system the team can actually explain. Not by slowing the agent down, and not by sending anyone to a course. Anthropic's own randomised trial shows what is at stake; the mechanism below shows what to do about it.

That is what Backthread is for: it captures the decisions behind every merged change from the agent sessions and pull-request discussion, then teaches that reasoning back inside the coding agent, so the people who did not make a decision still come to understand the codebase they are shipping. This page is about why the gap opens, what the evidence says, and what closes it without a mandate.

What the evidence says about AI assistance and skill formation

In January 2026 Anthropic published a randomised controlled trial on exactly this question. Fifty-two engineers, all comfortable in Python, none familiar with the Trio async library, were split in two. One group built two features with an AI assistant that could generate correct code on request; the other built the same features by hand. Then both sat a comprehension quiz.

The AI-assisted group scored 50 percent. The hand-coding group scored 67 percent. The AI group finished about two minutes faster, a difference the authors report as not statistically significant. The widest gap was on debugging questions, which is the part of the job where holding a model of the code matters most.

Two things in the paper matter more than the headline number.

First, the authors' caveat. The assessment "measured comprehension shortly after the coding task," and the study does not settle "whether immediate quiz performance predicts longer-term skill development." Treat the 17 points as a measurement of what a person holds the day they ship, not as a life sentence.

Second, the usage patterns. The AI-assisted participants who scored well did not use the tool less. They asked follow-up questions, requested explanations, posed conceptual questions while writing code themselves, and composed hybrid prompts that asked for code and the reasoning together. The ones who scored badly delegated the task and moved on. The variable was not the presence of the agent. It was whether the reasoning passed through a person on its way to the repository.

That is the whole page in one finding, so it is worth stating plainly: the agent does not stop people learning. Delegation without explanation does.

Vibe coding vs software engineering, on a team

The phrase most people reach for is Addy Osmani's. In August 2025 he drew the line between vibe coding, where the agent is handed control and its output is accepted as it comes, and AI-assisted engineering, where the human stays in control of design, review and tests. His warning about the first mode is the one that applies to teams: it produces systems where "no one truly owns the code's logic," and a senior engineer later has to reverse-engineer what the agent did.

For a single hobby project that is a cost you can choose to pay. For a 10–100-engineer team it compounds in a specific way. Each merged change arrives with correct code and no model, and the next change is built on top of it by a different person, with a different agent, who also does not hold the model. Six months in, the system is held by the two or three people who designed the original shape, and the rest of the team is shipping features into a codebase they can navigate but cannot explain. Nothing in your tooling reports this, because everything reports authorship, and a merged pull request is not evidence that anyone understood it.

Osmani's answer is discipline: design documents, rigorous review of every line, test-driven development. It is the right answer and it has the same failure mode as every process answer under agents. It asks engineers to go slower on purpose, every day, indefinitely, and the agent is right there offering to go faster. Discipline that has to be re-chosen on every task loses to a tool that never has to be chosen at all.

How do you keep engineers learning while AI writes the code?

The honest constraints first, because most proposals fail one of them.

1. You cannot slow the agent down. A team that adopted agents for throughput will not accept a learning programme that costs throughput. Any fix that reads as a brake gets routed around.
2. You cannot ask engineers to opt in to self-improvement. A side-of-desk learning tool reads to an engineer as a test, a brake, or a surveillance instrument. The engineering leaders we have put periodic questions to have said, unprompted, that their teams would not answer them.
3. You cannot teach what was never recorded. On our own repository, 62 percent of decisions captured from agent sessions carried no alternative and no trade-off; the reasoning was never formed, not merely lost. Any teaching has to start from what is actually on record, and say so where nothing is.
4. You cannot measure it with a merge count. Authorship-based metrics were "invalidated as a class" by agents, in the words of a June 2026 position paper. If the scoreboard counts merges, it will report a team that holds the system while the model quietly narrows.

Within those constraints there is one shape that works, and Anthropic's high scorers were already doing it by hand: put the reasoning in front of the person at the moment they are touching the code, in the tool they are already in, and let the act of reading it be the learning.

Capture the why when it exists

The agent session is where a decision is made, if it is made at all. The transcript holds the alternative that was rejected and the constraint that forced the choice, for the minority of changes that had one. Pull-request discussion holds the rest: a reviewer naming a trade-off, an author explaining an assumption. Capture from both, hold each decision until the work merges so the record is of what shipped, and refuse to fabricate deliberation for the changes that had none.

Teach it back inside the agent

The teaching arrives in the coding agent, not in a separate app. When an engineer's agent starts working in an area, the recorded decisions for that area, the assumptions the code rests on and the risks that were accepted are surfaced while the agent is thinking, and on demand for the file being touched. The engineer reads three sentences about why the retry lives where it does before their agent changes it. That is the "hybrid query" from Anthropic's high scorers, made automatic: code and reasoning arrive together, without anyone having to remember to ask.

Measure per area, and cap what git tells you

The leader's view is a map of the system with knowledge coverage per area. The first picture is inferred from git and PR history, capped at 50 percent and labelled an estimate, because having touched an area is not understanding it. Above that line, coverage is earned by an engineer explaining a decision in the course of real work. Areas with nothing on record say "nothing on record here," never zero, because zero is a measurement and blank is the truth.

What a developer becomes when the reasoning reaches them

The difference between a developer and an engineer was never typing speed. It is whether the person holds a model of the system good enough to predict what a change will do two modules away, and to say why the current shape is the current shape. Agents made the typing free and left the model where it was. The table is what changes when the recorded reasoning is put back in the loop.

Nothing in the right-hand column requires the engineer to do a new kind of work. It requires the reasoning to be present at the moment the old kind of work happens.

Where a course or a tutor is the better choice

Two cases where in-flow teaching is not the answer.

If the gap is in fundamentals, not in your system, a structured course closes it and this does not. An engineer who does not yet understand async runtimes will not learn them from a decision record about your ingest pipeline. CodeTrain is built for exactly that: a Socratic tutor on your own repository, where the lesson only advances when the engineer's code passes, and the assessment cannot be faked. We compare the two mechanisms honestly in Backthread vs CodeTrain; the short version is that it teaches from the code, step by step, and we teach from the recorded reasoning, in the flow. Both can be true of the same team.

And if your engineers do not use coding agents, there are no sessions to capture from. The pull-request prose still yields something, but the mechanism is built for teams where the agent is where the decisions get made.

What this looks like in the first fortnight

Connect a repository and the coverage map is built from git and PR history the same day, estimates capped and labelled. Capture starts on the next agent session and the next pull request; the first decisions appear when that work merges. Engineers see nothing new to do, because the teaching arrives inside the agent they already use, through the same plugin that captures. The leader sees which areas are held by one name, which have merges without any recorded model behind them, and, over the following weeks, which areas the team is starting to be able to explain. The how-it-works page has the mechanism in more detail.

What you will not get is a number that goes up because people merged more. That is the number every other tool already gives you, and it is the number Anthropic's trial says to distrust.

Connect one repo and the per-area map is there the same day, with capture running from the next session. The trial is fourteen days with everything on, and if the reasoning your agents leave behind turns out to be thin, the map will say so rather than flatter you.