# If AI takes the starter tickets, who learns to debug? **Summary:** hrih.si compares AI coding with FORTRAN's removal of manual work. I would use agents while preserving supervised debugging and ownership for junior developers, rather than assume review skills will follow. - Canonical: https://markhuang.ai/news/ai-starter-tickets-debugging-apprenticeship - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-10-21 - Section: News - Tags: AI Coding, Coding Agents, Junior Developers, Software Engineering, Developer Training, FORTRAN - Source: [hrih.si](https://hrih.si/articles/the-compiler-was-supposed-to-end-programming/) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![A robotic arm builds the glass upper steps of a staircase whose entry steps are missing](https://cdn.markhuang.ai/news/ai-starter-tickets-debugging-apprenticeship/hero.webp) *Conceptual artwork: automating the work above still leaves a question about how someone gets started.* hrih.si's October 21 essay, ["The compiler was supposed to end programming too,"](https://hrih.si/articles/the-compiler-was-supposed-to-end-programming/) argues that coding agents can move developers toward specifying and checking software, much as earlier tools removed manual work. Its opening workday in 2031 is explicitly imagined: agents finish implementations overnight, while a person resolves an ambiguous refund rule. I find that plausible as a direction. I am less comfortable assuming teams will keep producing people qualified to make those decisions. My concern is the apprenticeship. If agents take the small, well-defined tickets, I would deliberately preserve work through which a new developer can learn to investigate failures and own a result. Asking someone to review generated code does not, by itself, teach them how. The history offers encouragement. [IBM dates FORTRAN's commercial release to 1957](https://www.ibm.com/history/fortran) and describes how it let scientists and engineers express problems without relying on someone to translate them into machine code. That made programming more accessible. It does not establish that every later form of automation will leave an equally useful way into the profession. ## The compiler comparison has a limit The essay distinguishes between a task disappearing and a profession disappearing. I agree with that distinction. Its more ambitious prediction is that specifications and tests could become the main things developers maintain, with code treated more like compiler output. I would keep that prediction separate from the historical analogy. In ["I still care about the code,"](https://martinfowler.com/articles/exploring-gen-ai/i-still-care-about-the-code.html) Birgitta Böckeler distinguishes language-model inference from a compiler's translation of structured input. Her practical concern is whether someone can detect a mistake, especially when its consequences are serious. That objection matters to the imagined refund task. The agent stops when it encounters an expired card. Good. But a learning assignment should also prepare a developer for a version in which the agent invents a plausible rule and implements it confidently. The reviewer has to recognize that a business decision has been smuggled into the code. I want the apprentice to find that boundary, explain who must decide, and check that the implementation follows the decision. Handing them a polished pull request does not automatically teach any of this. ## Reviewing is also a skill to learn [Stack Overflow's 2025 survey](https://survey.stackoverflow.co/2025/ai) gives this concern some practical weight: 66% of respondents to its AI-frustrations question selected solutions that are "almost right, but not quite." That is a reported frustration, not a measured defect rate. Still, it describes the sort of output a reviewer must be able to challenge. The [Hacker News discussion of the essay](https://news.ycombinator.com/item?id=50185045) contains both the "next layer of abstraction" argument and objections to equating natural-language instructions with a programming language. I find the second argument more useful for training. It makes me ask what knowledge a person still needs to notice when the implementation makes an unwarranted choice. The source itself proposes a different apprenticeship, including reviewing alongside a senior and owning a small system. I would make that proposal a condition of adopting its optimistic future. Assigning all implementation to agents and all approval to existing experts leaves the beginner's role unresolved. ## Keep the problem, shorten the drudgery The strongest objection to my concern is that an agent could help someone learn faster. I see no reason to preserve repetitive typing as a rite of passage. Let a junior use AI for explanations and alternative implementations, then check their understanding through work the first answer did not settle. For the essay's hypothetical refund ticket, I would ask the developer to trace the relevant path before generation, write down the unresolved policy question, and agree on acceptance criteria with a senior. After the agent's implementation, the developer would investigate an additional failure case and explain why the behavior is correct. The senior would review that reasoning as well as the patch. These are proposed training practices, not results from an experiment. Their purpose is to keep the learner responsible for understanding the system while allowing the agent to remove work that adds little educational value. I would also separate delivery speed from learning. [METR's February 2026 update](https://metr.org/blog/2026-02-24-uplift-update/) says selection effects and time-measurement problems made its later developer experiment an unreliable signal of current productivity. Some developers avoided participation or withheld tasks because they did not want to work without AI. Even measuring speed proved difficult. A faster completed ticket would tell me still less about what a beginner learned. ## A ticket can have two kinds of value In [my earlier post about the cost of proving a patch](https://markhuang.ai/news/coding-agents-patch-proof-cost), I argued for delegating according to how expensive mistakes are to detect and reverse. Training adds another consideration: the cheapest way to finish a ticket may differ from the best way to prepare someone for the next one. I would reserve bounded tasks where a learner has to diagnose the problem and explain the eventual fix, with an experienced developer available to challenge their reasoning. Over time, I would look for greater independence on unfamiliar failures. Accepted patches alone would not convince me. The essay ends with developers spending more time deciding what should exist and checking what came back. I would welcome that change. But I would budget for teaching those abilities now, inside real work, rather than assume that moving everyone into review will produce reviewers.