Komforan
DA
All posts

The grunt work was the curriculum

· Henning Kjær

Almost every conversation about AI and software development is a conversation about speed. Ours included — Komforan exists as a product company partly because AI collapsed the distance between an idea and working software. That part is real, and I am not going to argue with it.

But there is a quieter question underneath, and it is the one I keep coming back to: if AI does the work people used to learn on, where do foundational skills come from now?

Nobody designed the old path — it just worked

The traditional route into software engineering was never designed. It emerged. You got the small tickets, the boring bug fixes, the CRUD screens, the log files nobody else wanted to read. It made economic sense: cheap hands on low-risk work.

And entirely by accident, it functioned as a curriculum. You learned by being stuck, being wrong, and being corrected by someone who had been stuck in the same place five years earlier.

Those are precisely the tasks that AI now does well. Researchers at Seoul National University interviewed developers about this and described the consequence bluntly: as AI absorbs junior tasks, it also removes the opportunities to fail that seniors were made from. The labour market data points the same way — Stanford payroll analysis shows employment for developers aged 22–25 down by roughly a fifth since late 2022, while employment for older developers held steady, and job posting analysis shows the junior-to-senior posting ratio falling by around 16%.

The headline everyone reaches for is "juniors are being replaced." I think that misses it. The real problem is that we removed the curriculum without noticing it was a curriculum, and we have not replaced it with anything.

Fluency is not understanding

There is now direct evidence that this is a learning problem and not only a hiring problem.

In a 2026 randomised study from Anthropic, 52 mostly junior engineers were asked to learn an unfamiliar Python library. Half had AI assistance, half did not. The AI-assisted group worked faster and hit fewer errors during the learning phase — and then scored about 17 points lower on a comprehension quiz taken afterwards without AI. Smoother output, less understanding.

But the detail that matters most is the one that did not make the headlines: AI use did not automatically produce that result. Participants who used AI to build comprehension — asking for explanations, asking conceptual questions, probing why something worked - retained significantly more. It was not whether they used AI. It was how.

That turns this from a fate into a design problem, and design problems have answers.

Foundational skill is what makes AI worth having

The other half of the picture is that foundational skill is not a nostalgic virtue. It is the thing that determines whether AI helps you at all.

METR ran a controlled trial with 16 experienced open-source developers across 246 real tasks in large, mature codebases. Using AI, they were 19% slower. The part that should stop you is not the number — it is that the same developers believed AI had made them about 20% faster. You cannot feel whether AI is helping you.

METR were careful not to over-generalise, and the follow-up work is genuinely contested - greenfield work and unfamiliar codebases do appear to see real speedups. DORA's 2026 research puts numbers on that spread: large gains on simple greenfield tasks, marginal ones on complex legacy code.

Which means the decisive skill is knowing which of those situations you are actually in. That judgement is foundational, it is unevenly distributed, and no tool supplies it.

DORA's summary of its 2025 research is the cleanest framing I have seen: AI is an amplifier. It magnifies the strengths of a strong engineering organisation and the dysfunctions of a weak one. The same holds at the level of a single developer. AI amplifies the judgement you already have. If there is not much there, it amplifies that too - faster, and with more confident prose wrapped around it.

So what is actually foundational now?

Less has changed here than people assume. The weighting has changed enormously.

  • Reading code you did not write - quickly, and with suspicion. This is now the dominant activity of the job, not a side task.
  • Debugging from symptom to cause without being handed the answer. The skill is the search, not the fix.
  • Knowing what "correct" means before you see a solution: the edge cases, the failure modes, the thing the spec forgot.
  • Being able to say "no, that is wrong" to a fluent, confident, well-formatted answer. This is much harder than it sounds and it degrades with disuse.
  • Knowing when not to delegate. Offloading a task you have already mastered costs nothing. Offloading one you were about to learn costs the skill.

None of these are new. What is new is that none of them arrive by accident anymore.

This is a team problem, not an individual one

The standard response is to hand people an individual learning plan and hope. That loses to the next deadline every time - organisations reward output, and deliberately taking the slower path is an unrewarded private cost. Left to individuals, the outcome is predictable.

It works when the team owns it together. Some of what that looks like in practice:

  • Decide out loud, per task, whether this is a delegate-task or a learn-task. Both are legitimate. Drifting between them without noticing is not.
  • Use AI explanation-first for anything unfamiliar. Ask it why before you ask it for code. This is the one intervention the Anthropic study actually supports.
  • Keep some reps AI-free. Small, regular, deliberate. Not purity — calibration. It is the only way to find out what you can still do.
  • Review AI-generated code harder than human code, and treat the review as a teaching conversation rather than a gate.
  • Rotate the hard debugging instead of routing it to whoever is fastest at it. Speed today, single point of failure tomorrow.
  • Ask "who else on this team could do this?" regularly, and do something about the answer when it is "nobody".

That last one is why we build what we build. A team cannot deliberately develop skills it cannot see. Making competence visible — what we have, where we are thin, who is learning what - is the precondition for every other item on that list.

The apprenticeship did not die, it stopped being free

For decades, the industry got skill formation as a by-product of work that had to be done anyway. That subsidy is gone. Nothing is stopping us from building the path deliberately, but it will not rebuild itself, and the feedback loop is brutally slow: a developer whose learning stalls in 2026 will not visibly fail to be a senior until the 2030s.

The teams that come out of this well will not be the ones that adopted AI fastest. They will be the ones that noticed what the grunt work was quietly teaching, and decided to teach it on purpose.

Sources