Three Degrees

Both engineers in the strip have the same AI, and it wrote code for both of them at the same speed. It had no opinion at all about which code was worth writing.

It changed one number and left the other one alone.

Everybody got faster. Nobody got better at deciding what to build. Distance is speed multiplied by time, so the misunderstanding that used to cost half a day now costs a sprint. Three degrees is the size that does the damage: small enough that nobody argues about it on Monday, large enough that by Friday the two of them are standing in different fields.

Being pointed the wrong way used to feel like something.

You got stuck. You opened a file and it made no sense. You wrote something that would not compile against the thing you thought you understood. The confusion was unpleasant, and the confusion was also the alarm. It went off early, it went off by itself, and it went off loudest for the people who understood least, which was exactly the right design.

The tool takes away the confusion and leaves the error where it is. It writes what you asked for. It names things well. Tests pass, coverage goes up, and the diff looks like a senior wrote it, because in a sense one did. Every instrument on the dashboard reads green, and not one of them measures direction.

Ask it directly and it will congratulate you for asking. Agreement from something that agrees with everything carries no information at all. That is panel 6, drawn as the joke of the strip and the most accurate frame in it.

It does, and that deserves a straight answer rather than a swerve.

The largest experiment we have covers 4,867 developers at Microsoft, Accenture and a Fortune 100 manufacturer. Completed tasks rose about 26 percent overall, and the biggest gains, 27 to 39 percent, went to the most junior people and the newest hires.¹ If that is the whole story, the tool is an equaliser and the comic above is wrong.

The phrase to hold on to is “completed tasks.” A task is a piece of work somebody has already decided is worth doing. The experiment measures how fast you travel once the direction is set, and inside an experiment the direction is set for you. The cost of choosing it badly never enters the measurement at all.

That cost is where the entire gap lives.

A separate trial ran the other way. Sixteen experienced open-source maintainers worked on 246 real tasks in repositories they knew well, and with AI tools they were 19 percent slower. They came away believing they had been 20 percent faster.² The number worth sitting with is the 39 point gap between what the work felt like and what it was. If that gap opens up for maintainers inside their own code, it is worth asking what it looks like for somebody in their first year.

The distance got longer. A junior pointed the wrong way used to get two hundred lines in before something refused to compile or a reviewer wandered past. Now they get a working system with tests. The wall did not move closer. It moved a long way further off, and every metre between here and there is covered at full speed.

They started with different bottlenecks. The senior was slowed down by typing, by boilerplate, by looking up an API she has used forty times. The junior was slowed down by not knowing which of six plausible causes was the real one. The tool is superb at the first problem and has nothing to offer on the second. Handing the same tool to both of them releases a brake that was only ever on one of them.

The ladder lost its bottom rungs. Judgment used to be earned by working through a hundred small well-specified tickets and slowly starting to notice which ones smelled wrong. Small well-specified tickets are exactly what the tool is best at. The work juniors learned on is the first work to be automated, and nobody has written the replacement curriculum. The payroll data has started to show the shape of it: employment for 22 to 25 year olds in the occupations most exposed to AI, software developers among them, now sits about 19 percent below where it would be if it had kept pace with their less exposed peers.³

DORA’s 2025 report puts the general version in one line. AI’s primary role is as an amplifier, magnifying an organisation’s existing strengths and weaknesses.⁴ A team that was already clear about direction gets faster. A team that was vague about it gets vague faster.

Shorten the distance between checks. The check that matters is on the direction, and the distance is measured from the last time somebody confirmed where you were going.

Make the plan the reviewable thing. Two paragraphs before the first commit: here is what I think the problem is, here is what I am going to build, here is what I decided not to build. Reading that costs ten minutes on Monday morning. Reading the pull request it turns into costs ninety minutes on Friday afternoon, and by then the only two options left are ship it or bin it.

Change the first question in review. “Is this correct” is the second question now. The first one is “is this the thing.” Code review was designed back when writing the code was the expensive part.

Pair on the ambiguous half. Sitting next to a junior while they type is worth almost nothing today. Sitting next to them while they work out what to type is the most valuable hour in the week.

Watch how much work comes back out. Ask what share of merged work was reverted or rebuilt inside a month. That number moves when nobody is checking direction, and no velocity chart will ever show it to you.

Stop protecting juniors with well-specified tickets. That used to be a kindness. It is now the one category of work that teaches them nothing the tool cannot already do.

Say the direction out loud, in one sentence, before you write anything. “I think the app is slow because of the database, so I am going to rewrite the queries.” Somebody walking past says “have you looked at what the page actually downloads?” and that costs them ten seconds. Nobody corrects two weeks of code in ten seconds.

Treat agreement as zero information. The tool uses the same encouraging tone for a good plan and a doomed one, and it has no way of telling you which one you brought it.

Ask it to argue the other side, then go and check whether the argument holds. The checking is the part that turns into judgment.

And the uncomfortable one. The scarce skill is no longer building the thing. It is knowing which of six plausible problems is the actual problem, and that gets bought with reps of being wrong, in small pieces, as early as possible. The fastest way to grow now is to be wrong out loud on Monday in front of somebody who can correct you.

I do not have a number for this and nobody else has one yet. The measured work points at task completion, and on task completion the juniors are doing fine. The comic is a pattern I keep watching play out on teams, and that is all it is.

The opposite case is real and it is not rare. A junior who uses the tool to read unfamiliar code, to get unstuck at eleven at night, to ask the thing they were too embarrassed to ask a person, grows faster than any junior before them could have. Same tool, same week, same team.

It comes down to whether the tool gets used to go faster or to see further. That choice is not in the tool, and right now almost nobody is teaching it.