About This Report

One research agent per brainstorm item: each agent received one line of a handwritten brainstorm page, quoted word for word with its heading, and nothing else: no thesis, no task list, no suggested sources. Each agent chose its own questions and did its own web research. No agent saw another agent’s work, and no one rewrote the sections to agree. The sections may overlap or disagree; that is deliberate.

The Brainstorm Page

0.0.0.1 True statements

• people like to feel like they are coding

• people like to feel like they are doing something

• like their ideas matter

• like they’re learning

• people like to understand the code

0.0.0.2 What does a human add to an AI?

• you buy a guarantee of completion

• you buy a guarantee of quality

• you get a contract that the thing will be actually solved

0.0.0.3 AI aside

• AI learn mode?

• AI copilot while you code

• Some projects no AI?

• Some days no AI?

• Sometimes what makes code valuable is that it is written by a human, is simple, and easy to read

• Codeberg solution

• AI usage tax for (negative externality)

• AI bottler tax. (Author’s later gloss: “If you use AI and using AI causes costs like code repo management or CIs, then you pay for it when you pay for your AI. See Codeberg.”)

• AI small parts and tedium solution: code helper.

• pair programming AI edition

0.0.0.4 Business

“Forward deployed engineer.” How to start a this business that maximizes the above added value.

The contract is the product. All good features are secret.

0.0.0.5 Added later

The human has to pay “some” attention to the AI, so it actually comes out like a pizza and not like a calzone. This is really taxing for a human because he wants to do something that feels more productive than babysitting an AI.

1 The Feeling of Coding Is Not the Same as Coding

The brainstorm lists “people like to feel like they are coding” as a true statement. The line makes a claim about experience, not output. People value the sense of writing software: the flow, the authorship, the visible progress. The research below supports the claim. It also shows why the claim matters for an essay on learning versus production: the feeling is a poor gauge of both. It overstates how much people produce, and it overstates how much they learn.

This section asks three questions:

1. Is the feeling real, and do tools that supply it win users?

2. Does the feeling track actual production?

3. Does the feeling track actual learning?

1.1 The feeling is real, and it sells

GitHub’s 2022 Copilot research measured feelings directly. It surveyed more than 2,000 developers. Between 60% and 75% said they felt more fulfilled in their job, felt less frustrated when coding, and could focus on more satisfying work. 73% said Copilot helped them stay in the flow, and 87% said it preserved mental effort on repetitive tasks (Kalliamvakou 2022b). One developer in the study said the tool meant they had to think less, and that when they did think, it was “the fun stuff” (Kalliamvakou 2022b).

These numbers measure perception. GitHub also ran a controlled test with 95 professional developers. The Copilot group finished one task 55% faster (1 hour 11 minutes against 2 hours 41 minutes) (Kalliamvakou 2022b). That test used a single, well-defined task. It shows that the tool can speed up a narrow job. It does not show that the good feeling and the speed are the same thing.

Adoption follows the feeling more than trust does. In the 2025 Stack Overflow Developer Survey, 84% of respondents used or planned to use AI tools, up from 76% the year before. Yet 46% actively distrusted the accuracy of those tools, against 33% who trusted it. Only 3% “highly trust” the output. The top complaint, cited by 66%, was AI answers that are “almost right, but not quite” (“2025 Stack Overflow Developer Survey” 2025). People keep using a tool they do not trust. One plausible reason is that the work still feels like coding, and feels faster.

A related effect comes from consumer psychology. Norton, Mochon, and Ariely named it the IKEA effect: people value things more when they helped build them. In their studies, people rated their amateur origami and Lego builds close to expert work. The effect vanished when people failed to finish or when their work was destroyed (Norton et al. 2012a). The study did not test software. The parallel is an inference: a developer who steers an AI and sees code appear may feel the authorship that drives the IKEA effect, even when the machine did most of the labor.

1.2 The feeling overstates production

The strongest evidence comes from METR. In early 2025, METR ran a randomized trial with 16 experienced open-source developers on 246 real issues from their own mature repositories. Each issue took about two hours. When AI tools were allowed, developers took 19% longer. Before the study, they forecast a 24% speedup. After it, they still believed AI had sped them up by 20% (Becker et al. 2025b).

That is a gap of about 39 percentage points between felt speed and measured speed. The authors note that developers may find AI-assisted work more pleasant or enjoyable, even when it is slower (Becker et al. 2025b). In other words, the developers liked how the work felt, and that liking shaped their estimate.

Two limits apply. The sample was small, and the tools were early-2025 models. METR itself now says these historical results “no longer reflect” the current impact of AI models, and it published updated findings in February 2026 (Becker et al. 2025b). This section did not open the 2026 update, so its numbers are unverified here. The core lesson stands on the 2025 data alone: self-reports of speed were wrong in sign, not just in size.

1.3 The feeling overstates learning

Learning research predicted this gap long before AI tools. Elizabeth and Robert Bjork separate performance during practice from learning that lasts. Conditions that make practice feel smooth often teach less. Conditions that feel slow and error-prone, which they call desirable difficulties, often teach more. Learners judge their progress by how fluent the work feels right now, so they tend to prefer the weaker method (Elizabeth L. Bjork and Bjork 2011).

Anthropic tested this with AI coding in a randomized trial published in January 2026. Judy Hanwen Shen and Alex Tamkin had 52 mostly junior engineers learn Trio, a Python library none of them knew. One group could use an AI assistant; the other coded by hand. Both groups then took a quiz on the concepts they had just used (Shen and Tamkin 2026a).

The AI group did not finish meaningfully faster. Some participants spent up to 11 minutes, about 30% of the time allotted, composing up to 15 queries. They learned less, and the biggest loss was in debugging: the skill needed to tell when code is wrong (Shen and Tamkin 2026a).

The details matter more than the average. Participants who handed the task to the AI, or who slid from writing code to full delegation, scored below 40%. Participants who asked only conceptual questions, or who asked for explanations alongside generated code, scored 65% or higher (Shen and Tamkin 2026a). The tool did not decide the outcome. The way people used it did.

1.4 What this means for the essay

The line names a real human preference. People want to feel like they are coding, and AI tools now supply that feeling cheaply. The evidence splits the feeling from two things it is often mistaken for:

• Production. In METR’s trial, developers felt 20% faster while running 19% slower (Becker et al. 2025b).

• Learning. In Anthropic’s trial, AI users scored 17 points lower on concepts they had just used, with no significant time saved (Shen and Tamkin 2026a).

For production work, the feeling is mostly harmless if output is measured by something other than self-report: merged changes, defects, cycle time. For learning, the feeling is a trap. Smooth, delegated work produces the fluency that the Bjorks warn against (Elizabeth L. Bjork and Bjork 2011). A learner who feels like they are coding may not be building the skill.

The practical rule follows from the Anthropic data. When the goal is learning, use the AI to explain, not to write. Keep the struggle that builds skill, especially debugging. When the goal is production, let the AI write, but measure the result instead of trusting the feeling. Vibe coding, in Andrej Karpathy’s phrase, means you “forget that the code even exists” (Karpathy 2025). That works for a throwaway prototype. It fails as a way to learn, because the code you forget is the code you never understood.

2 The Need to Feel Busy

The line “people like to feel like they are doing something” makes a claim about a feeling, not about output. It says people want the sensation of activity. That sensation and real progress are two different things. In an essay on learning versus production, the line points at a trap: the work that feels most productive is often not the work that teaches the most.

This section asks four questions:

1. Is the claim true? Do people prefer activity to idleness?

2. Do people prefer action even when doing nothing gives a better result?

3. In learning, does the feeling of progress track real progress?

4. Why does visible busyness persist in work culture?

2.1 People dread idleness, but need an excuse to act

Hsee, Yang, and Wang tested the claim directly (Hsee et al. 2010). They found that people choose to stay idle when they have no reason to act. Yet even a weak, specious reason was enough to make them choose busyness. And the busy participants reported more happiness than the idle ones. The authors turn the usual story around. We assume people get busy to reach goals. They suggest people may also pursue goals in order to stay busy (Hsee et al. 2010).

Wilson and colleagues pushed the point further (Wilson et al. 2014). They left participants alone in a room to think for a short period, with no phone and no book. Most found it unpleasant. Participants could press a button to give themselves a mild electric shock. In one study, 67% of men and 25% of women shocked themselves at least once rather than sit with their thoughts (Wilson et al. 2014). For many people, doing something unpleasant beat doing nothing.

So the line holds up. But Hsee’s result adds a condition: people want activity they can justify. The justification does not need to be good. It only needs to exist.

2.2 Action bias: moving when standing still wins

The urge to act can override the best choice. Bar-Eli and colleagues studied 286 penalty kicks in top leagues (Bar-Eli et al. 2007). Given where kickers aim, the best strategy for a goalkeeper was to stay in the center. Yet goalkeepers stayed in the center for only 6.3% of kicks. They dove right 44.4% of the time and left 49.3% (Bar-Eli et al. 2007).

The authors explain the gap with regret. A goal scored while the keeper stood still feels worse than a goal scored after a dive. The dive looks like effort, so it protects the keeper from blame. The researchers call this “action bias.” Note that a later comment on the paper disputes how optimal staying in the center really is (Berger 2010). The core pattern, keepers diving far more than the data justify, is the paper’s main claim.

The lesson carries over. When an outcome is uncertain, people pick the option that looks busy, because visible effort feels defensible.

2.3 In learning, the feeling of progress misleads

This is where the line matters most for the essay. Study methods that feel productive are often weak. Methods that feel hard are often strong.

Students choose the easy-feeling methods. Karpicke, Butler, and Roediger surveyed college students on how they study (Karpicke, Butler, and Henry L. Roediger 2009). The most common answer was rereading notes or the textbook. After reading a chapter, 57% said they would reread it. Only 18% said they would practice retrieval, such as testing themselves. The authors trace this choice to “illusions of competence”. Rereading makes the material feel familiar, and familiarity feels like knowledge (Karpicke, Butler, and Henry L. Roediger 2009).

The evidence says those popular methods are weak. Dunlosky and colleagues reviewed ten common study techniques (Dunlosky et al. 2013). They rated five as low utility: summarization, highlighting, the keyword mnemonic, imagery for text, and rereading. They rated practice testing and distributed practice as high utility (Dunlosky et al. 2013). Highlighting and rereading share a trait: both produce visible activity. A page turns yellow. A chapter gets read twice. The student did something, and can see it.

The strongest evidence comes from a classroom experiment. Deslauriers and colleagues randomly split an introductory physics class at Harvard (Deslauriers et al. 2019a). Half got a polished lecture. Half got active learning with the same content and handouts. Then the groups swapped. Students in active sessions scored higher on the test. But they felt they had learned less. In the researchers’ words, actual learning and feeling of learning “were strongly anticorrelated” (“More Learning in ‘Active Learning’ Classrooms, but Students Don’t Know It” 2019). The authors blame the effort itself. Active learning is harder, and students read that strain as a sign of failure (“More Learning in ‘Active Learning’ Classrooms, but Students Don’t Know It” 2019).

This flips a naive reading of the line. In learning, people do not simply want to be active. They want to feel a smooth, satisfying kind of activity. Passive lectures and rereading supply that smooth feeling. Real learning often feels like struggle, so it gets avoided.

2.4 Busyness as a status signal

Culture rewards the look of activity too. Bellezza, Paharia, and Keinan found that in the United States a busy, overworked life now signals high status (Bellezza et al. 2017). Observers infer that a busy person is competent, ambitious, and in demand. In Italy the effect reversed: a leisurely life still signaled high status. The authors link the difference to beliefs about social mobility (Bellezza et al. 2017). If busyness earns respect, people have one more reason to perform it, whether or not it produces anything.

2.5 What this means for learning versus production

Table 1 lines up the findings.

Three points follow for the essay.

• Production satisfies the urge directly. Producing something, such as code, pages, or a finished task, gives a visible result. It scratches the itch to feel busy. Learning often gives no visible result for a long time. That asymmetry may push people toward production even when they need to learn first.

• Fake learning also satisfies the urge. Rereading, highlighting, and watching tutorials feel like learning and leave a visible trace. They let a person feel they are learning without the strain that real learning requires.

• Discomfort is a signal, not a failure. The Harvard result suggests a practical rule: if study feels easy and smooth, check whether you are learning at all. Effort that feels unproductive may be the most productive part.

The line is true, but incomplete. People do like to feel they are doing something. The research adds the catch: the feeling of doing something and the fact of getting something done often point in opposite directions.

3 People Like to Feel That Their Ideas Matter

The brainstorm lists this line as a “true statement” about people. Read in full, it says: people like to feel like their ideas matter. The claim has two parts. First, people want their ideas heard. Second, and more important, they want those ideas to change something. A suggestion that disappears into a box does not satisfy the need. A suggestion that ships does.

For an essay on learning versus production, the line raises three questions:

1. Is the claim actually true, and how strong is the evidence?

2. Does the need differ between a setting built for learning and a setting built for output?

3. What does it cost to honor the need, and what goes wrong when people only feel that their ideas matter?

3.1 The evidence that the need is real

Psychologists have a name for the broader need: mattering. Rosenberg and McCullough defined it in 1981 as the feeling that others depend on us, are interested in us, and are concerned with our fate (Rosenberg and McCullough 1981). In four samples of adolescents, feeling that one mattered to one’s parents predicted lower depression even after controlling for self-esteem, and it also predicted lower anxiety in the one sample that measured anxiety (Flett 2022). Later reviews treat mattering as an essential construct and a basic psychological need, not a preference (Flett 2022).

Workplace research narrows the need to ideas. Gallup’s Q12 engagement survey includes the item “At work, my opinions seem to count” as item 7 of 12 (“Gallup’s Q12 Employee Engagement Survey” 2026). Gallup says the 12 items are the dimensions that consistently correlated with four workplace outcomes: retention, customer metrics, productivity, and profitability (“Item 7” 1999). Gallup calls item 7 the employee’s “internal stock price” (“Item 7” 1999). The item page itself gives no effect sizes, so this report does not claim any.

Schools show the same pattern. A 2024 review of student voice reports that students who felt they had a voice in school decisions were eight times more likely to be engaged (Conner et al. 2024). That figure comes from a 2016 Quaglia Institute report, which this report did not open; treat the number as secondhand. Self-determination research reaches a similar conclusion: autonomy-supportive teachers, who offer real choices and explain why tasks matter, see higher student engagement over time (Yang et al. 2022).

3.2 Feeling heard is not enough: the futility problem

The strongest evidence says the need is not met by asking for ideas. It is met by acting on them, or by explaining why not.

Detert and Burris studied why employees stay silent (Detert and Burris 2016). They found two causes: fear of consequences and a sense of futility, the belief that speaking up “won’t make a difference.” At one Fortune 100 high-tech company, employees cited futility almost twice as often as fear. Their numbers show the role of follow-up:

• In surveys of more than 3,500 employees, bosses who failed to close the loop raised their staff’s belief that speaking up was futile by 30%.

• Staff whose managers had closed the loop in the past spoke up 19% more often.

• In a separate survey of more than 10,000 restaurant employees, staff whose supervisors frequently took their problems and suggestions to the general manager shared concerns and ideas 10% more often.

So the brainstorm’s word “feel” needs care. People can tell the difference between a forum and a decision. An idea program that collects ideas but never responds teaches people that their ideas do not matter. That is worse than no program.

3.3 A production system built on the need

Toyota offers the best long-run test. Its Creative Idea Suggestion System has run for more than 70 years and has collected about 50 million suggestions (“Making Work More Fun and Fruitful” 2024). In 2023, employees submitted 810,000 ideas, an average of 14.4 per plant technical employee. Cash rewards are small, from 500 yen to 200,000 yen. A Toyota supervisor said nothing pleased him more than hearing colleagues praise an idea that made their work easier (“Making Work More Fun and Fruitful” 2024). A 1992 review of Yuzo Yasuda’s book on the system reports an adoption rate near 96% in the late 1980s (Lee 1992); this report saw that figure only in a search summary, so it is unverified.

Toyota shows that the need can serve production directly. Most of these ideas are small. Their value is that people closest to the work keep improving it, and they keep doing so because their ideas are used.

3.4 The cost: ownership inflates value

The need has a downside. People who make something value it more than it is worth. Norton, Mochon, and Ariely called this the “IKEA effect” (Norton et al. 2012b). People who assembled IKEA boxes, folded origami, or built Lego sets valued their own work more than items they did not build, and rated their amateur creations close to experts’ creations. They also expected others to share that view. The effect held only when people finished the task; when they failed or saw their work destroyed, it vanished (Norton et al. 2012b).

Ideas likely behave the same way. A person who owns an idea will overrate it and expect others to agree. That bias is harmless, even useful, in learning. It becomes a cost in production, where a team must drop weak ideas fast.

3.5 What this means for learning versus production

Table 2 summarizes how the need plays out in each setting.

In a learning setting, an idea matters because testing it teaches the person something. A wrong idea, tried and examined, still pays off. The learner’s ownership drives effort, and the IKEA effect costs little.

In a production setting, an idea matters only if it improves the product. Not every idea can ship. The research gives a practical answer to this tension: close the loop. Detert and Burris found that telling people what happened to their input, and what to expect next, reduces the futility that silences people (Detert and Burris 2016); whether this holds for an explained “no” specifically could not be confirmed. Gallup ties item 7 to managers who consult staff and explain their reasoning (“Item 7” 1999).

The line is true, with one correction. People do not just like to feel that their ideas matter. They watch whether their ideas actually change anything, and they adjust their effort to what they see.

4 The Feeling of Learning Is Not Learning

The brainstorm lists this line as a true statement: people like to feel like they are learning. The key word is feel. The line does not claim that people like to learn. It claims they like a sensation. That sensation and real learning often point in opposite directions. This section asks four questions:

1. Is the feeling of learning a reliable sign that learning happened?

2. Which activities give the feeling without the learning?

3. Why do people choose those activities anyway?

4. What does this mean for the choice between learning and production?

4.1 The feeling and the result run in opposite directions

The clearest evidence comes from a Harvard physics study published in PNAS in 2019 (Deslauriers et al. 2019b). Louis Deslauriers and colleagues taught the same material in an introductory physics course two ways. One group got polished lectures from experienced, highly rated instructors. The other group got active instruction, where students worked problems in class. The groups then swapped. After each class, students took a 12-question multiple-choice test and rated how much they felt they had learned (“More Learning in ’Active Learning’ Classrooms, but Students Don’t Know It” 2019).

Students scored higher after the active sessions. Yet they said they learned more from the lectures. Deslauriers summed it up: “Actual learning and feeling of learning were strongly anticorrelated” (“More Learning in ’Active Learning’ Classrooms, but Students Don’t Know It” 2019). The authors read the effort of active work as the cause. Students took the strain of thinking as a sign that they were learning poorly. A smooth lecturer made them feel they understood more than they did (Deslauriers et al. 2019b).

Lab studies show the same gap. Kornell and Bjork (2008) had people learn the styles of painters. Some saw each artist’s paintings in a block (massed). Others saw the artists mixed together (spaced). In their first experiment (1a), 78% of participants did better with spacing, but 78% said massing was as good as or better (Kornell and Bjork 2008). A 2014 replication by Verkoeijen and Bouwmeester found the same belief: 71% of its participants said massing produced the most learning (Verkoeijen and Bouwmeester 2014).

The illusion also covers understanding, not only memory. Rozenblit and Keil (2002) asked Yale students to rate how well they understood everyday devices such as zippers. Then the students wrote out how each device works and rated themselves again. Their ratings dropped once they had to produce the explanation (Rozenblit and Keil 2002). The feeling of knowing survived until the first attempt to use the knowledge.

4.2 Which activities sell the feeling

Bjork’s work names the mechanism. When material is easy to process, the brain takes that ease, or fluency, as evidence of mastery (Soderstrom and Bjork 2015). Soderstrom and Bjork (2015) review decades of research on the gap between performance during study and learning that lasts. They report that “considerable learning can occur in the absence of any performance gains” and that big performance gains often fail to become learning (Soderstrom and Bjork 2015). Conditions that feel easy, such as massed practice and rereading, raise performance in the moment but leave little behind.

Students pick the easy conditions. Karpicke, Butler, and Roediger (2009) surveyed 177 college students. Rereading was the most common strategy: 84% listed it, and 55% named it their number-one method. Only 11% said they practised retrieval, and only 1% (2 of 177) ranked it first (Karpicke, Butler, and Henry L. Roediger III 2009). When asked what they would do after reading a chapter, 57% chose to reread it. Only 18% chose to test themselves (Karpicke, Butler, and Henry L. Roediger III 2009). Retrieval practice beats rereading for long-term memory, yet students avoid it because it feels harder.

Outside school, the same pattern has a name among programmers: “tutorial hell.” Learners watch course after course but cannot build anything alone. Writers on the topic describe it as recognition mistaken for recall: the learner recognises each step as the tutor types it, and that familiarity feels like skill (Ogu 2026). This is practitioner commentary, not a controlled study. It matches the lab findings above.

Table 3 sums up the evidence.

4.3 Why people choose the feeling

Three reasons stand out in the sources.

• Effort reads as failure. The Harvard authors found that students treat cognitive strain as a sign of poor learning (Deslauriers et al. 2019b). The very signal of real learning gets misread.

• Fluency is immediate; learning is delayed. The reward for rereading arrives now, as ease. The reward for retrieval arrives a week later, on a test (Soderstrom and Bjork 2015).

• People rarely check. The illusion of explanatory depth broke only when students had to write an explanation (Rozenblit and Keil 2002). Without a test, the feeling goes unchallenged.

The feeling is also pleasant in its own right. Low completion in open online courses hints at this. Reich and Ruipérez-Valiente (2019) analysed 5.63 million learners in the HarvardX and MITx courses on edX. They found that most never returned after their first year and that low completion rates did not improve over six years (Reich and Ruipérez-Valiente 2019). That data does not prove why people enrol. It is consistent with the idea that signing up and sampling content delivers the feeling of learning, and many stop there. Treat this link as an inference, not a finding.

4.4 What this means for learning versus production

For an essay on learning versus production, this line carries the central warning. Consumption feels like progress. Production exposes what is missing. Every study in Table 3 has the same shape: the activity that felt better was passive or easy, and the activity that worked forced the learner to produce something, such as a solved problem, a recalled answer, or a written explanation.

Two practical points follow.

1. Do not trust the feeling as a gauge. The Harvard team warned that judging teaching by how much students feel they learned “could inadvertently promote inferior pedagogical methods” (Deslauriers et al. 2019b). The same holds for self-judged study.

2. Use production as the test. Writing code without the tutorial, answering from memory, or explaining a device on paper all reveal the gap. They feel worse. That discomfort is the evidence that learning is happening.

The line is true, then, but in a double-edged way. People do like to feel like they are learning. That preference pulls them toward the activities that teach them least. Production, which feels less like learning, is often where the learning happens.

5 People Like to Understand the Code

The brainstorm lists “people like to understand the code” as a true statement. I read it as a claim about motive, not only about method. Programmers want to know how and why their code works, and they feel uneasy when they ship code they cannot explain. In an essay on learning versus production, this line matters because understanding is the product of learning, while production often rewards output that no one fully understands.

This section asks four questions:

1. Is the statement true? What evidence shows that programmers seek understanding?

2. Is understanding just a preference, or does it pay off in the work?

3. What happens to understanding when an AI tool writes the code?

4. What does this mean for the split between learning and production?

5.1 Evidence that the statement is true

The strongest evidence is how programmers spend their day. Xia and colleagues tracked 78 professional developers across seven real projects for 3,148 working hours. On average, the developers spent 58 percent of their time on program comprehension (Xia et al. 2018b). Writing new code took far less time than reading and making sense of existing code. Junior developers spent significantly more time on comprehension than senior developers. Teams in the maintenance phase spent more than teams in the development phase (Xia et al. 2018b).

This number does not prove that people like to understand code. It proves that they must. But survey data shows the preference too. In the 2025 Stack Overflow Developer Survey, 75.3 percent of developers said that even in a future where AI can do most coding, they would still ask a person “when I don’t trust AI’s answers” (Stack Overflow 2025b). Asked whether “vibe coding,” which the survey defines as generating software from LLM prompts, is part of their professional work, about 15 percent answered some form of yes (11.9 percent a plain “yes”), and 77.5 percent answered no (72.2 percent “no,” 5.3 percent “no, emphatically”) (Stack Overflow 2025b). Among developers who reported frustrations with AI tools, 16.3 percent said it is hard to understand how or why the AI’s code works (Stack Overflow 2025b).

A broader finding from psychology may also apply. Norton, Mochon, and Ariely found that people value things more when they build them themselves, which they call the “IKEA effect.” The effect held only when people completed the task; it vanished when they failed or destroyed the result (Norton et al. 2012c). Their studies used furniture, origami, and Lego, not software. The link to code is my inference, not a tested result: programmers may value code they understand partly because the effort of understanding makes it feel like their own.

5.2 Understanding pays off

Peter Naur gave the classic argument for why understanding is not a luxury. In “Programming as Theory Building” (1985), he argued that a program is not its source text. The real program is a theory that lives in the minds of the programmers who built it (Naur 1985a). The text is a lossy record of that theory. Naur held that a new programmer cannot gain the theory by reading the code and documents alone; the newcomer needs close contact with the people who already hold it (Naur 1985a). On this view, code that nobody understands is a program that nobody owns. It still runs, but no one can safely change it.

The 2025 survey points to the same cost from the other side. Sixty-six percent of developers named “AI solutions that are almost right, but not quite” as their top frustration, and 45.2 percent said debugging AI-generated code takes more time (Stack Overflow 2025b). “Almost right” code is cheap to produce and expensive to fix, because fixing it requires the understanding that its author skipped.

5.3 What AI assistance does to understanding

A 2026 randomized trial at Anthropic tested the trade-off directly. Shen and Tamkin asked 52 mostly junior software engineers to learn Trio, an unfamiliar asynchronous library, and build two features. Half could use an AI assistant. Afterward, all took a quiz on the concepts they had just used (Shen and Tamkin 2026b).

The AI group finished only about two minutes faster, and that gap was not statistically significant (Shen and Tamkin 2026b). So the AI group gave up 17 points of understanding for almost no gain in speed. The largest gap appeared on debugging questions (Shen and Tamkin 2026b).

The detail inside the AI group matters most for this essay. Participants who handed the work to the AI, or who leaned on it more and more as the task went on, scored under 40 percent. Participants who asked the AI conceptual questions, or asked it to explain the code it wrote, scored 65 percent or higher, close to the hand-coding group (Shen and Tamkin 2026b). The tool did not decide the outcome. The goal of the user did. People who used the AI to understand kept their understanding.

Speed gains are also less certain than they feel. A 2025 METR trial gave 16 experienced open-source developers 246 tasks in their own mature repositories. With AI tools allowed, they took 19 percent longer. Yet they believed AI had made them about 20 percent faster (Becker et al. 2025a). METR now marks this result as out of date and points to newer early-2026 results (Becker et al. 2025a). Still, it shows that the feeling of progress and real progress can diverge when the developer is not doing the thinking.

Writers now use the term “comprehension debt” for the gap between how much code a team has and how much of it anyone understands (Osmani 2026). Osmani argues that, unlike technical debt, it gives no early signal of friction: it grows quietly and comes due during an incident, a rewrite, or the onboarding of a new hire.

5.4 What this means for learning versus production

The statement holds up, with one refinement. People like to understand code, and they also need to: comprehension takes most of a developer’s time, and code without a human theory behind it is hard to change. But production pressure and AI tools make it easy to skip understanding for a short-term gain that, in the studies above, turned out small or absent.

This suggests the learning-versus-production split is not a choice between two activities. It is a choice of goal for each task. The same developer, with the same AI tool, can work in a learning mode (ask why, read the output, debug by hand) or in a production mode (delegate and accept). The Anthropic trial shows that learning mode costs little speed and keeps most of the skill (Shen and Tamkin 2026b). The open question for the essay is when production mode is worth the debt: perhaps for throwaway scripts, but rarely for code that a team must maintain for years.

Limits of this evidence. The Anthropic trial is small (52 people, one library, one quiz right after the task). The METR trial had 16 developers and used early-2025 tools. The Stack Overflow figures are self-reports. The IKEA-effect link to programming is an inference.

6 You Buy a Guarantee of Completion

The note makes a claim about what a buyer pays for. When you hire a person, you do not only buy their output. You buy a promise that the job will end in a finished state, and a party who answers if it does not. An AI tool sells attempts. A human contractor sells an outcome. This section tests that claim against three questions:

1. How often do AI agents actually finish real work on their own?

2. What do AI vendors promise, compared with what human contractors promise?

3. Is the human guarantee real, or is it a legal and financial structure that sits on top of an unreliable worker?

6.1 AI agents finish some tasks, not all

The best evidence says AI agents complete short tasks reliably and long tasks rarely. METR measured how long a task takes a human professional and then asked how often a model finishes it alone. Models succeed almost every time on tasks that take a human under four minutes. They succeed less than 10% of the time on tasks that take a human more than about four hours (Kwa et al. 2025). METR defines a “50% time horizon”: the task length at which a model succeeds half the time. For Claude 3.7 Sonnet, that horizon was about one hour. The horizon has doubled about every seven months since 2019 (Kwa et al. 2025).

A 50% success rate is not a guarantee. It is a coin flip. METR says it directly: the best models can do some tasks that take experts hours, but can only reliably complete tasks of a few minutes (Kwa et al. 2025).

TheAgentCompany benchmark shows the same gap in office work. Researchers at Carnegie Mellon built a simulated software company with 175 tasks across roles such as engineering, HR, and finance. The best model in the published paper, Gemini 2.5 Pro, completed 30.3% of tasks fully. With partial credit, it scored 39.3% (Xu et al. 2025). The best open-weight model, Llama 3.1 405B, completed 7.4% (Xu et al. 2025). So an agent left alone on a realistic workload leaves most of it unfinished.

The trend line matters for the essay. If the horizon keeps doubling, the set of tasks an AI can “guarantee” will grow. But the guarantee always ends at some task length. Past that point, a human must still close the loop.

6.2 What the seller promises

The contracts make the difference plain. Anthropic’s consumer terms provide services, outputs, and actions “as is” and “as available.” They tell users not to rely on outputs without checking them. They cap Anthropic’s total liability at the greater of what the user paid in the prior six months or $100 (“Consumer Terms of Service” 2026). (I could not open OpenAI’s terms; the page returned an error. I do not describe them here.)

Compare a federal construction job. The Miller Act requires a prime contractor on a federal construction contract to post a performance bond; the statute sets the threshold at $100,000, and federal acquisition rules raise it to $150,000 (“Miller Act” 2026). The bond guarantees the contractor will finish the work to the contract’s terms. Federal rules set the bond at 100% of the original contract price (“FAR Subpart 28.1” 2026). If the contractor fails, the owner can claim against the bond and recover its losses up to the bond amount (“Performance Bond” 2026).

The table shows the point of the note. The AI vendor shifts the risk of an unfinished or wrong result to the buyer. The bonded contractor carries it.

6.3 The law already assigns completion to a human

Courts and tribunals do not accept the AI as the responsible party. In Moffatt v. Air Canada (2024), the airline’s chatbot gave a customer wrong information about bereavement fares. Air Canada argued the chatbot was a separate legal entity responsible for its own actions. The British Columbia Civil Resolution Tribunal rejected that argument. It held the airline responsible for everything on its website, chatbot included, and ordered it to pay about CA$812 (“Moffatt v. Air Canada” 2026a; Lifshitz and Hung 2024a).

In Mata v. Avianca (2023), lawyers filed a brief that cited court decisions ChatGPT had invented. A federal judge fined the plaintiff’s attorneys $5,000 (“Mata v. Avianca, Inc.” 2026a). The court did not blame the tool. It blamed the people who signed the brief.

Both cases point the same way. When AI work fails, the law looks for a human or a firm to hold. Part of what a human adds is a name to hold.

6.4 Is the human guarantee real?

The human guarantee is weaker than it sounds. Humans also fail to finish. The Standish Group’s CHAOS surveys track IT projects. A secondary summary of its 2020 figures reports 31% of projects successful, 50% “challenged” (late, over budget, or cut in scope), and 19% failed outright (“CHAOS Report on IT Project Outcomes” 2026). In 1994, only 16.2% of software projects arrived on time and on budget, and 31.1% were canceled (“CHAOS Report on IT Project Outcomes” 2026). (I saw these figures only in a secondary source, not in a Standish report.)

So a human team’s raw completion rate is not far from 100%, but it is not 100% either. The guarantee does not come from the worker’s skill alone. It comes from the structure around the worker: a contract, a bond, a license, a court that can enforce damages. The buyer pays for that structure. The performance bond exists because contractors fail.

6.5 AI vendors have started to sell outcomes

The gap is closing from the vendor side. Intercom charges $0.99 for each conversation its Fin agent resolves. The buyer pays nothing when Fin fails to help (“Intercom Pricing” 2026b). This is a small guarantee of completion: the vendor eats the cost of failed attempts. It does not cover harm from a wrong answer, and it applies only to narrow, short tasks, which fits METR’s finding that short tasks are where AI is reliable.

6.6 What this means for the essay

The line holds, with a correction. A human adds a guarantee of completion, but the guarantee belongs to the contract, not to the human brain. Three points follow:

• For short tasks, AI already gives near-certain completion, and some vendors now price by outcome. The human premium there is small.

• For long tasks, AI finishes less than half the time. A human, or a firm, must own the last mile. That ownership is what the buyer pays for.

• For accountability, the law already treats the human or firm as responsible, whatever tool did the work. No court has yet let an AI carry the risk.

This links to the page’s theme of learning versus production. In production, the buyer wants a finished result and someone to answer for it. A person who uses AI but signs for the result sells that guarantee. A person who only passes AI output along sells nothing the tool did not already provide.

7 Buying a Guarantee: Why the Human Signature Still Has a Price

The brainstorm line reads: “you buy a guarantee of quality.” I read it as a claim about markets, not about skill. When a client pays a human professional instead of prompting an AI, the client does not only buy the words or the code. The client buys a promise that someone will answer for the result. AI output can be cheap and often good. But no one stands behind it by default. A human adds a name, a license, a liability, and an insurance policy.

This section tests that claim with four questions:

1. Do AI vendors guarantee the quality of their output?

2. When AI output is wrong, who pays?

3. Does the human guarantee hold up in practice?

4. Can the guarantee be bought without the human?

7.1 AI vendors sell output, not assurance

The standard consumer contract for a general-purpose AI tool disclaims quality outright. OpenAI’s Terms of Use provide the service “as is” and disclaim warranties of merchantability, fitness for purpose, and satisfactory quality (“Terms of Use” 2026a). Summaries of those terms report that OpenAI makes no promise that output will be accurate or error-free, and that users rely on output at their own risk (“OpenAI (ChatGPT) Terms of Service Review 2026” 2026a). The same terms cap OpenAI’s total liability at the greater of what the user paid in the prior 12 months or $100 (“OpenAI (ChatGPT) Terms of Service Review 2026” 2026a). For a free user, the most the vendor will ever owe is $100. (The OpenAI page returned HTTP 403; the wording above comes from search-result excerpts of the terms effective 1 January 2026 and a third-party review.)

So a model’s output arrives with no warranty attached. The buyer of AI output carries the full risk of an error. That is the gap the brainstorm line points at.

7.2 The deployer pays, not the model

Courts have answered the second question plainly: whoever uses the AI owns its mistakes. In Moffatt v. Air Canada (2024), the airline’s website chatbot told a grieving customer he could claim a bereavement fare after travel. That was false. Air Canada argued that the chatbot was “a separate legal entity” responsible for its own actions. The British Columbia Civil Resolution Tribunal rejected that argument and found the airline liable for negligent misrepresentation. It awarded about CA$812 in damages (“Moffatt v. Air Canada” 2024; Lifshitz and Hung 2024b). The sum was small. The principle was not: a company cannot hand responsibility to software.

Lawyers learned the same lesson. In Mata v. Avianca (2023), two New York attorneys filed a brief with six court cases that ChatGPT had invented. When challenged, they asked ChatGPT to confirm its own citations. A federal judge fined the lawyers and their firm $5,000 in total (“Mata v. Avianca, Inc.” 2023). The court did not sanction the software. It sanctioned the humans who signed the brief.

These failures are not rare. Damien Charlotin’s public database tracks court decisions that deal with AI-hallucinated content. It held 116 cases from 12 countries in May 2025 (Willison 2025). By October 2026, the database listed more than 2,000 cases (Charlotin 2026a).

The pattern shows what the human signature means. A signature turns “the AI said so” into “I say so, and you can hold me to it.”

7.3 The human guarantee is only as good as the human check

The guarantee does not come from the human alone. It comes from the human doing the work of checking. The 2025 Deloitte Australia case shows what happens when that work is skipped. Australia’s Department of Employment and Workplace Relations paid about A$440,000 for a review of its welfare compliance system. A University of Sydney academic found fabricated quotes from a court judgment and references to research papers that did not exist. Deloitte admitted that it had used generative AI and agreed to a partial refund of the contract fee (Croft 2025; “Incident 1193” 2025).

The case cuts two ways. First, the client got some money back, which an AI vendor’s $100 cap would never have provided. The brand and the contract carried real recourse. Second, the client paid a premium for human assurance and received unchecked machine output. A guarantee is a promise. It does not remove the error; it only assigns who pays for it.

7.4 Can the guarantee be bought without the human?

If the human mainly adds accountability, a market could try to sell accountability on its own. Two such markets have appeared.

Vendor indemnity. In September 2023, Microsoft announced its Copilot Copyright Commitment. If a third party sues a paying commercial customer for copyright infringement over Copilot output, Microsoft will defend the customer and pay any adverse judgment or settlement. The customer must use the guardrails and content filters built into the product (Smith and Nowbar 2023). This guarantee is narrow. It covers copyright claims, not whether the output is correct.

AI performance insurance. In May 2025, the startup Armilla launched a policy underwritten by insurers at Lloyd’s of London. It covers court claims and legal costs when an AI tool underperforms and harms a customer (“Insurers Launch Cover for Losses Caused by AI Chatbot Errors” 2025). Reports say coverage turns on a measurable drop in performance, for example accuracy falling from 95% to 85% (“Insurers Launch Cover for Losses Caused by AI Chatbot Errors” 2025).

Other insurers moved the other way. AIG, Great American, and WR Berkley asked U.S. regulators to approve exclusions for AI-related claims in corporate policies. WR Berkley’s proposed exclusion reportedly covers any claim from the use of AI “in any form.” An Aon executive explained the fear: the industry could absorb one $400 million loss, but not thousands of correlated claims caused by one provider’s error (Schreiner 2025).

That last point sharpens the brainstorm line. A human professional’s errors are mostly independent. One accountant’s mistake does not repeat in every other accountant’s work. A widely used model can make the same mistake for millions of users at once. Insurers price independent risk easily and correlated risk badly. That is one structural reason the human guarantee is still easier to buy.

7.5 Summary

The line holds, with one correction. A human does not guarantee quality in the sense of zero errors. Humans signed the Avianca brief and the Deloitte report. What a human adds is a party who can be sued, fined, disbarred, or refunded, and who therefore has a reason to check. AI makes the production cheap. It does not make the promise cheap. Until vendors or insurers carry broad, uncapped responsibility for output, the price gap between human and AI work is largely the price of that promise.

8 The Human as the Party Who Signs: A Contract That the Problem Gets Solved

The brainstorm line says that when you hire a human, “you get a contract that the thing will be actually solved.” I read it as a claim about accountability, not skill. An AI model can produce an answer. It cannot promise that the answer is right, and it cannot pay when it is wrong. A human contractor, lawyer, or employee can. The human adds a party who owns the outcome.

This reading raises four questions:

1. What do AI vendors actually promise about their output?

2. When AI output fails, who pays?

3. Are AI vendors starting to sell the outcome itself, and so compete with the human’s contract?

4. What does the law require a human to do, and why?

8.1 What the AI vendor promises: almost nothing

The standard AI contract is the opposite of a promise that the problem will be solved. OpenAI’s consumer Terms of Use provide the service “as is.” They disclaim warranties of merchantability and fitness for a particular purpose. They state that OpenAI does not warrant that the service will be accurate or error free. They also tell the user that any use of output is at the user’s sole risk, and that output is not a substitute for professional advice (“Terms of Use” 2026b). The same terms cap OpenAI’s total liability at the greater of what the user paid in the prior 12 months or $100 (“OpenAI (ChatGPT) Terms of Service Review 2026” 2026b). Business customers get one narrow warranty: the service will conform to its documentation. Everything else stays “as is” (“OpenAI Services Agreement” 2026).

So, as a worked example, a user who pays a hypothetical $20 a month for a chatbot holds, at most, a $240 claim, and no claim at all that the answer was correct. The vendor sells a capability. It does not sell a result.

8.2 When AI output fails, a human or a firm pays

The risk does not vanish. It lands on whoever put the output into the world.

Air Canada (2024). Air Canada’s website chatbot told a passenger, Moffatt, that he could book a full-fare flight and claim a bereavement discount within 90 days. The real policy did not allow this. Air Canada argued that the chatbot was “a separate legal entity that is responsible for its own actions.” The British Columbia Civil Resolution Tribunal rejected that argument and called it remarkable. It held Air Canada liable for negligent misrepresentation and ordered it to pay CA$812 in total: about CA$650 in damages plus interest and fees (“Moffatt v. Air Canada” 2026b; Lifshitz and Hung 2024c). The machine could not be the defendant. The company was.

Mata v. Avianca (2023). A New York lawyer filed a brief with six court cases that ChatGPT had invented, including fake parties and holdings. When challenged, he produced fake “opinions” that ChatGPT also generated. The federal court fined the lawyers $5,000 and ordered them to notify their client and each judge falsely named as the author of a fake opinion (“Mata v. Avianca, Inc.” 2026b; “Mata v. Avianca” 2026). The tool faced no penalty. The lawyer who signed the brief did.

The pattern at scale. Damien Charlotin’s public database of court decisions that involve AI-hallucinated material listed 2,137 cases when I opened it (Charlotin 2026b). In each case, a human who signed a filing answered for the machine’s error.

These cases show what the brainstorm line means in practice. A lawyer’s signature on a brief is a contract with the court that the citations are real. A company’s website is a contract with its customers that its statements are true. The AI cannot sign either one.

8.3 AI vendors begin to sell the outcome

Some AI vendors now price by result, which is a partial version of the human’s contract. Sierra, the customer-service agent company led by Bret Taylor, charges when its agent resolves a conversation. Unresolved conversations and handoffs to human staff typically do not trigger a charge (“Sierra AI Pricing Explained” 2026). One third-party analysis puts the rate at about $1.50 per resolved interaction; Sierra does not publish its prices, so I could not verify this figure (“How Does Sierra AI Make Money” 2026). Intercom’s Fin agent lists a public price of $0.99 per resolution (“Intercom Pricing” 2026c).

This looks like “a contract that the thing will be actually solved.” It differs from a human’s contract in two ways:

• Weak definition of “solved.” Intercom counts a resolution when the customer confirms the answer helped or leaves without asking for more help. One critic notes that a customer who simply gives up still costs $0.99 (“Intercom Fin Pricing” 2026).

• No liability for harm. Outcome pricing means the vendor forgoes a fee when it fails. It does not mean the vendor pays for damage that a wrong answer causes. Air Canada still carried that risk.

Table 4 compares the three kinds of promise.

8.4 The law asks for a human who can say no

The idea is old. A 1979 IBM training slide, widely shared online, reads: “A computer can never be held accountable. Therefore a computer must never make a management decision” (“A Computer Can Never Be Held Accountable” 2026). Its exact origin is hard to confirm; the earliest online trace found so far is a 2017 tweet by a former IBM employee.

The EU AI Act turns this idea into a rule for high-risk systems. Article 14 requires that natural persons can effectively oversee such systems. The overseer must stay aware of “automation bias,” the tendency to over-rely on output. The overseer must be able to “disregard, override or reverse the output,” and to halt the system with a “stop” button (“Article 14” 2024). The law does not ask the human to do the work. It asks the human to be the person who can refuse it and answer for it.

8.5 What this means for learning versus production

The line points to a cost that pure production metrics miss. A human contract is only worth something if the human can check the work. The lawyer in Mata had the signature but not the knowledge to see that the cases were fake. His contract failed because he could not verify.

That links accountability to learning. A person who has learned a field can stand behind AI output, because the person can detect when it is wrong. A person who has only produced with AI holds a signature they cannot back. So the human adds two things, and they come as a pair: someone who carries the liability, and the skill that makes carrying it safe. Outcome-priced AI agents may take over low-stakes, easily checked work, such as support chats at $1 each. For work where one error costs more than the whole contract, buyers will still want a person who signs.

Unverified items. Sierra’s per-resolution price comes from a third-party blog. The 1979 IBM slide’s origin is not confirmed by IBM.

9 AI Learn Modes: Can One Tool Serve Both Learning and Production?

The margin note “AI learn mode?” asks a sharp question for an essay about learning versus production. An AI assistant built for production hands over the finished answer. That saves time, but the user skips the effort that builds skill. Since 2025, the major AI vendors have shipped a second setting, a “learn mode,” that withholds answers and makes the user do part of the work. The note asks whether such a switch resolves the tension, or only relabels it.

This section asks four questions:

1. What do current learn modes actually do?

2. Does unguarded AI use harm learning?

3. Do learn-mode designs protect or improve learning?

4. What limits remain?

9.1 What learn modes are

Three vendors launched learn modes within five months in 2025.

• Anthropic, Claude “Learning” style. Anthropic introduced learning mode in April 2025 for Claude for Education users only. On 14 August 2025 it opened the mode to all Claude.ai users and added it to Claude Code (Bonifacic 2025). In chat, Claude answers with guiding questions instead of solutions (Bonifacic 2025). In Claude Code, the “Learning” output style pauses at decision points and asks the user to write 5 to 10 lines of meaningful code, such as business logic or error handling (“Learning Output Style Plugin README” 2025). A separate “Explanatory” style keeps Claude writing the code but adds summaries of its reasoning (Bonifacic 2025).

• OpenAI, ChatGPT Study Mode. OpenAI launched Study Mode on 29 July 2025 for Free, Plus, Pro, and Team users. It uses Socratic questions, quizzes, and step-by-step guidance. OpenAI says it consulted pedagogy experts from more than 40 institutions (Nuñez 2025).

• Google, Gemini Guided Learning. Google launched Guided Learning on 6 August 2025. It breaks topics into steps and adds diagrams, videos, quizzes, and flashcards (Malik 2025).

All three share one idea: the tool should make the learner think, not just deliver output. Anthropic’s education lead, Drew Bent, gave the reason plainly: copying and pasting from a chatbot is “not good for their long-term learning” (Bonifacic 2025).

9.2 Evidence that production-style AI harms learning

Two controlled experiments show the cost of the default, answer-giving mode.

High school mathematics. Bastani and colleagues ran a field experiment with nearly 1,000 high school students in Turkey (Bastani et al. 2025c; Basiouny 2024). One group used “GPT Base,” a plain ChatGPT-style interface. A second used “GPT Tutor,” which gave hints, not answers, and drew on teacher input. A control group used only standard resources. During practice, GPT Base raised scores by 48% and GPT Tutor by 127%. On the later exam without AI, the GPT Base group scored 17% worse than the control group (Basiouny 2024). Students used the tool as a crutch. They also overrated how much they had learned (Basiouny 2024). PNAS later published a correction to the paper (“Correction for Bastani Et Al., Generative AI Without Guardrails Can Harm Learning” 2025). Indexed summaries describe it as a fix to one author’s affiliation, not to the results; I could not open the full notice to confirm this.

Software engineering. Anthropic ran a randomized trial with 52 mostly junior engineers learning Trio, an unfamiliar Python library for asynchronous code (Shen and Tamkin 2026c). The AI group averaged about 50% on a follow-up quiz. The hand-coding group averaged about 67% (Cohen’s $d = 0.738$, $p = 0.01$). The AI group finished about two minutes faster, but that gain was not statistically significant (Shen and Tamkin 2026c). In this study, the production benefit was small and the learning cost was large.

The Anthropic study also found that how people used AI mattered. Participants who asked conceptual questions, or who asked for explanations alongside code, scored higher. The conceptual-inquiry group (7 people) was also the second-fastest group overall (Shen and Tamkin 2026c). Those subgroups are very small, so treat the pattern as a hint, not a result.

9.3 Evidence that learn-mode designs help

The same experiments suggest that guardrails work.

In the Bastani study, GPT Tutor removed most of the harm: its group scored about the same as the control group on the exam (Basiouny 2024). Note what this means. The guardrails prevented a loss. They did not produce a gain.

A stronger positive result comes from Harvard. Kestin and colleagues ran a randomized crossover trial with 194 students in an introductory physics course (Kestin et al. 2025). A custom AI tutor, built on the same teaching practices as the class, beat an in-class active-learning lesson. Students learned more, in less time, and reported more engagement (Kestin et al. 2025). Secondary reports say median learning gains more than doubled, in 49 minutes instead of 60 (Barrientos 2026). I saw those two figures only in search-result summaries, not in the paper itself.

The difference matters for the essay. The Harvard tutor was a purpose-built lesson. A vendor learn mode is a general-purpose prompt style. No study I found tests ChatGPT Study Mode, Claude’s Learning style, or Gemini Guided Learning directly against plain use.

9.4 Limits

• It is opt-in, and opting out takes one click. TechCrunch reported that students can easily switch back to regular ChatGPT when they just want an answer. OpenAI offered no parental or administrator lock at launch (Zeff 2025). A learn mode works only when the user already chooses learning over output.

• Learners misjudge their own learning. The Bastani students overrated their learning (Basiouny 2024). That makes the opt-in problem worse. The people who most need the mode may least believe they need it.

• Deadlines favor production. The Anthropic trial suggests the time saved by full delegation can be small (Shen and Tamkin 2026c). But under a deadline, even a small saving can win over learning that pays off later.

• No direct evidence yet. The supporting studies tested custom tutors, not the shipped vendor modes.

9.5 Implications for the essay

A learn mode does not end the learning-versus-production tradeoff. It makes the tradeoff a visible, per-session choice. That is useful. Before 2025, the choice was hidden inside each prompt. Now a learner can pick a mode on purpose, and a developer can let Claude Code leave the key 5 to 10 lines for them to write.

The evidence supports a narrow claim: AI that withholds answers avoids the learning loss caused by AI that gives answers, and a well-designed tutor can beat a good classroom. The evidence does not yet show that the one-click vendor modes deliver those gains, or that learners keep them switched on. The honest answer to “AI learn mode?” is: promising design, unproven product, and only as strong as the user’s decision to use it.

10 The AI Copilot: A Production Tool Placed Inside a Learning Task

The margin note “AI copilot while you code” names the sharpest modern case of the essay’s tension. A copilot is an assistant, such as GitHub Copilot, Cursor, or a chat model, that suggests or writes code as you type. It is built for production: it aims to get working code on the screen faster. But a person who codes is often also learning. The note asks a simple question with a hard answer: when the same tool sits in both activities, does the speed it buys in production cost something in learning?

This section looks at three questions:

1. Does a copilot actually make coding faster?

2. Does it reduce what the coder learns?

3. Does the way you use it change the trade?

10.1 How common the copilot has become

The question is not hypothetical. In the 2025 Stack Overflow Developer Survey, 84% of respondents said they use or plan to use AI tools in development, up from 76% the year before, and 51% of professional developers use them daily (“2025 Stack Overflow Developer Survey” 2025a). Trust lags adoption: more respondents distrusted the accuracy of AI output (46%) than trusted it (33%) (“2025 Stack Overflow Developer Survey” 2025a). So most coders now work, and learn, with a copilot beside them, while many doubt what it tells them.

10.2 Question 1: Is it faster?

The evidence on speed is mixed, and it depends on who codes and on what task.

The case for speed. In a 2023 controlled experiment, Peng and colleagues asked recruited developers to build an HTTP server in JavaScript. The group with GitHub Copilot finished 55.8% faster than the control group, about 71 minutes against 161 minutes (Peng et al. 2023a). The 95% confidence interval ran from 21% to 89%. Less experienced developers gained the most (Peng et al. 2023a). That last detail matters for this essay: the people who gain the most speed are the people with the most left to learn.

The case against. METR ran a randomized trial with 16 experienced open-source developers on 246 real issues in large projects they already knew. With early-2025 AI tools, they took 19% longer to finish (“Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” 2025a). Before the study they forecast a 24% speedup. After it, they still believed AI had made them 20% faster (“Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” 2025a). The gap between felt speed and real speed is a warning: a coder’s sense of being productive is not reliable evidence.

The picture moves. In February 2026, METR reported that its early result no longer reflects current tools. A follow-up suggested a speedup for returning developers (an estimated 18% reduction in task time, with a wide interval that includes no effect). METR itself called the new data unreliable, partly because many developers refused to work without AI for the study (“We Are Changing Our Developer Productivity Experiment Design” 2026a). The honest summary: copilots often speed up production, especially on fresh, well-defined tasks, but the size of the gain is uncertain and shifts with each tool generation.

10.3 Question 2: Does it cost learning?

Here the evidence is more consistent, and it points one way.

Coding. In January 2026, Anthropic researchers Judy Hanwen Shen and Alex Tamkin ran a randomized trial with 52 mostly junior engineers. Each learned Trio, a Python library for asynchronous programming they had not used before (Shen and Tamkin 2026d). Half had AI help. Afterward, all took a quiz on the library. The AI group averaged 50%; the hand-coding group averaged 67%, a gap the authors call nearly two letter grades (Cohen’s $d$ = 0.738, $p$ = 0.01). The AI group finished only about 2 minutes faster, and that difference was not statistically significant (Shen and Tamkin 2026d). The largest gap appeared on debugging questions. So in this study the learners gave up a large share of understanding and got almost no speed in return.

Outside coding. A field experiment in a Turkish high school, with about 1,000 students, points the same way. Bastani and colleagues gave some students a plain GPT-4 chat interface (“GPT Base”) during math practice (Bastani et al. 2025a). Those students scored 48% better on practice problems than the control group. But on a later exam taken without AI, they scored 17% worse than students who never had it. They also did not notice that they had learned less (Bastani et al. 2025a). The cited paper, published in PNAS in 2025, reports these figures.

Both studies show the same pattern. Assisted performance rises. Unassisted skill falls. The learner cannot feel the loss.

10.4 Question 3: Does how you use it matter?

Yes, and this is the most useful finding for the essay. The tool is not the whole story; the habit is.

In the Anthropic study, the researchers sorted participants by how they used the assistant (Shen and Tamkin 2026d). Low scorers delegated: they let the AI write the code, leaned on it more over time, or pasted errors back to it to fix. High scorers used AI to understand: they generated code and then studied it, asked for explanations alongside code, or asked only conceptual questions and wrote the code themselves. The high-scoring patterns averaged 65% or higher on the quiz, and the low-scoring patterns averaged below 40% (Shen and Tamkin 2026d; Wiggers 2026).

The math study found a parallel effect from design. A second arm, “GPT Tutor,” used prompts that gave hints instead of answers. It raised practice scores by 127% and largely removed the exam penalty, though it produced no clear gain over the control group either (Bastani et al. 2025a).

10.5 What this means for the essay

The copilot makes the essay’s split concrete. Production asks, “Is the code done?” Learning asks, “Can I do this without help next time?” A copilot answers the first question well and can quietly fail the second.

Three points follow:

• Decide the mode first. If the goal is to ship known work, delegation is fine. If the goal is a new skill, delegation is the pattern most linked to low scores.

• Do not trust the feeling. METR’s developers felt faster while slower. Bastani’s students felt they learned while they learned less. Test yourself without the tool.

• Use the copilot as a tutor, not a ghostwriter. Ask why. Read what it writes. Write the hard part yourself.

The Anthropic authors close with the same point: organizations that deploy these tools at scale should design for engineers to keep learning as they work (Shen and Tamkin 2026d). A copilot does not decide whether you learn or produce. Your habits decide.

11 Some Projects, No AI? Choosing Where to Switch the Assistant Off

The margin note asks a narrow question. If an essay contrasts learning with production, should some projects be done with no AI at all? The note does not say "never use AI". It asks whether a deliberate share of work should stay unassisted, and which share.

This section reads the line as a design rule for a learner who also ships work. Production rewards output. Learning rewards the effort that builds skill. AI tools collapse that effort. So the question becomes: when does removing the tool pay for itself?

Four questions guide the research:

1. Does AI help measurably reduce what people learn while they work?

2. Does the harm come from AI itself, or from how people use it?

3. Does AI at least make skilled people faster, so the trade is worth it in production?

4. How do teachers already put the rule “some projects, no AI” into practice?

11.1 Evidence that unassisted work builds more skill

The strongest recent evidence comes from a randomized trial run by Anthropic researchers Judy Hanwen Shen and Alex Tamkin, published in January 2026 (Shen and Tamkin 2026e). They gave 52 mostly junior engineers two tasks in Trio, a Python library for asynchronous programming that none of them knew. Half could use an AI assistant. Half coded by hand. A quiz followed on the concepts they had just used.

The AI group averaged 50%. The hand-coding group averaged 67%. The authors call that gap “nearly two letter grades” (Cohen’s $d = 0.738$, $p = 0.01$). The AI group finished about two minutes faster, but that speed gain was not statistically significant. The widest gap appeared on debugging questions. That matters: debugging is the skill a person needs most when they later supervise AI-written code.

A second trial points the same way in a different field. Bastani and colleagues gave high school math students GPT-4 access during practice, then took it away for the exam (Bastani et al. 2025e). Students who had an unrestricted assistant (“GPT Base”) did worse on new problems once the tool was gone than students who never had it. Students who had a version with tutoring guardrails (“GPT Tutor”) did not suffer that loss (Bastani et al. 2025e).

A third source is weaker but often cited. An MIT Media Lab team recorded EEG from 54 adults who wrote essays with ChatGPT, with a search engine, or with no tool, across several sessions (Kosmyna et al. 2025a). The no-tool group showed the strongest brain connectivity. The ChatGPT group showed the weakest and had more trouble quoting their own essays. The authors call this “cognitive debt”. Treat this result with care. It is a preprint with a small sample, and brain connectivity is not the same as learning. As of its December 2025 arXiv revision, it listed no peer-reviewed venue.

These findings fit older learning science. Elizabeth and Robert Bjork’s “desirable difficulties” research shows that effortful conditions, such as generating an answer before seeing it, lower performance during practice but raise long-term retention (“Research” 2026; Elizabeth Ligon Bjork and Bjork 2011). An AI assistant removes exactly that generation step. A learner then feels fluent without having built the memory.

11.2 The harm depends on how the tool is used

The same studies show that “AI or no AI” is too coarse. In the Anthropic trial, the authors sorted AI users by behavior (Shen and Tamkin 2026e). Table 5 summarizes their groups. The subgroups are tiny (2 to 7 people each), so read them as hints, not proof.

People who used AI as a tutor scored about as well as people with no AI. People who used it as a ghostwriter scored worst. Bastani’s guardrail result says the same thing from the tool side: a tutor that withholds answers protects learning (Bastani et al. 2025e).

This suggests a sharper rule than the margin note. The line between learning and production may not be “AI or no AI”. It may be “who writes the answer”. In a learning project, the person writes the code or the argument, and AI may only explain. In a production project, AI may write, and the person reviews.

11.3 Production gains are smaller than they feel

The case for AI in production assumes it saves time. For experienced people on familiar code, that is not certain. In a July 2025 randomized trial, METR had 16 experienced open-source developers work on 246 real issues in their own repositories (“Developers Thought AI Made Them Faster. The Data Said Otherwise” 2026). With AI tools allowed, they took 19% longer. Afterward they believed AI had made them about 20% faster (“Developers Thought AI Made Them Faster. The Data Said Otherwise” 2026; “A Randomized Trial by METR Found That Experienced Developers Completed Real Coding Tasks 19% Slower When Allowed to Use AI Tools” 2026).

Two points follow. First, perceived speed is a poor guide; a person should measure before deciding a project “needs” AI. Second, the production benefit is uneven, so giving up AI on a learning project may cost less than it seems. Later tools and later studies may show different numbers. One 2025 trial does not settle the question.

11.4 How teachers already apply “no AI” to some work

Harvard’s CS50 offers a working model (“Artificial Intelligence - CS50x 2026” 2026; Liu et al. 2024). The course bans general tools such as ChatGPT and GitHub Copilot that complete answers or lines of code. It allows its own “rubber duck” assistant, which acts like a tutor and avoids handing over solutions. The course offered its AI tools to about 70 summer students in 2023, then with thousands online and about 500 on campus (Liu et al. 2024). This is the Anthropic and Bastani finding turned into policy: block the ghostwriter, keep the tutor.

11.5 Answer to the margin note

Yes, some projects should be AI-free, or close to it. The evidence supports three working rules:

• No AI when the skill itself is the goal. Use a first project in a new language, library, or field to build the skill. Expect slower output. That slowness is the learning.

• Tutor mode, not ghostwriter mode, in between. Ask AI to explain concepts. Write and debug the work yourself.

• Full AI only where you can already check the output. Debugging skill was the first casualty in the Anthropic trial. A person cannot safely review AI code they could not have written.

Open questions remain. The cited trials are small (16 to 54 people for the coding and EEG studies) and short. None measured skill months later. The essay should present these as early signals, not settled law.

12 Some Days No AI? Scheduled Abstinence as a Learning Tool

The margin note “Some days no AI?” proposes a rule: set aside whole days on which the writer does the work without AI help. In an essay about learning versus production, the note reads as a hedge. AI speeds up production. The writer suspects it may slow down learning. An AI-free day is one cheap way to keep both.

The question mark matters. The note is a proposal, not a decision. This section tests it with three questions:

1. Does steady AI use erode a skill that a person already has, or stop a new skill from forming?

2. Does taking the AI away reveal a gap that stays hidden while the tool is on?

3. Is a whole day without AI the right unit, or does the way a person uses AI matter more?

12.1 Learning and performance are different things

Learning research gives the note its logic. Robert Bjork’s work on “desirable difficulties,” first set out in 1994, separates performance from learning (Main 2026). Performance is what a person can do during or right after practice. Learning is the lasting change that remains later and transfers to new problems. The two can move in opposite directions. Spacing, mixing problem types, and testing yourself all make practice feel harder. They also make knowledge last longer (Main 2026).

AI is the strongest tool yet for smooth, fast practice. By Bjork’s logic, that smoothness is a warning sign. If the tool removes the struggle, it may also remove the learning. An AI-free day puts the struggle back.

12.2 Evidence that AI use can erode skill

Four recent studies bear on the first question. Table 6 summarizes them.

Students. Bastani and colleagues ran a field experiment with nearly 1,000 high school students in Turkey (Bastani et al. 2025d; Ramirez 2026). Students who practiced with a plain GPT-4 interface (“GPT Base”) solved 48% more practice problems than a control group. On a later closed-book exam without AI, the same students scored 17% lower than students who never had AI (Ramirez 2026). A second version, “GPT Tutor,” gave hints instead of answers. It raised practice scores by 127% and removed most of the exam penalty (Ramirez 2026). This is the learning-versus-performance split in one experiment: the tool lifted performance and cut learning.

New programmers. Anthropic ran a randomized trial with 52 mostly junior engineers who learned Trio, a Python library new to them (Shen and Tamkin 2026f). On a quiz about concepts they had just used, the AI group averaged 50% and the hand-coding group 67%. The largest gap was in debugging. Participants who asked the AI for explanations and follow-up answers kept more than those who asked only for code (Shen and Tamkin 2026f).

Experts. Skill loss is not limited to beginners. A study in The Lancet Gastroenterology & Hepatology followed 19 experienced endoscopists, each with more than 2,000 prior colonoscopies, at four centres in Poland (“The Lancet Gastroenterology & Hepatology” 2025). Before the clinics adopted AI polyp detection, the doctors found adenomas in 28.4% of colonoscopies done without AI. Three months after adoption, their unaided rate fell to 22.4%: a 6-point absolute and 20% relative drop (“The Lancet Gastroenterology & Hepatology” 2025). The study is observational, so it cannot prove cause. It is still the closest real-world parallel to the essay’s worry, because the skill lost was the one the AI did for them.

Knowledge workers. A Microsoft Research and Carnegie Mellon survey of 319 knowledge workers found that higher confidence in AI went with less critical thinking. Higher confidence in one’s own ability went with more (Lee et al. 2025b). Workers said AI shifted their effort from solving problems to checking and stitching together AI output. These data are self-reported.

12.3 What an AI-free day measures

The second question has a clear answer. In both the Bastani and Lancet studies, the damage showed up only when the AI was removed. With the tool on, GPT Base students looked better than the control group. The endoscopists’ AI-assisted detection rate, 25.3%, hid the drop in their own unaided skill (“The Lancet Gastroenterology & Hepatology” 2025). A person who always works with AI never sees this number.

An AI-free day works as a recurring test. It shows what the person can do alone. In Bjork’s terms, it is retrieval practice: hard, slow, and the step that makes knowledge stick (Main 2026).

Practitioners already do this. Addy Osmani describes a developer who keeps “No-AI Days”: one day a week of coding from scratch, reading error messages in full, and using real documentation (Osmani 2025). The developer reported feeling “slower, dumber” at first and compared it to a hard workout that rebuilt confidence. This is one anecdote, not a study.

12.4 Is a whole day the right unit?

The third question complicates the note. The strongest finding across the studies is that how people use AI matters as much as whether they use it. GPT Tutor students kept most of their learning. Anthropic participants who asked conceptual questions kept more than those who delegated (Ramirez 2026; Shen and Tamkin 2026f). A rule based on the calendar ignores this.

Three refinements follow from the evidence:

• Split by task, not by date. Use AI freely for production work whose skill you do not need to own. Go AI-free on tasks you are trying to learn. This maps the note directly onto the essay’s learning-versus-production theme.

• Change the mode, not only the switch. On learning tasks, ask the AI for hints and explanations, never finished answers. The GPT Tutor result supports this.

• Keep a periodic unaided check. Even skilled experts lost ground in three months. A regular AI-free session, daily or weekly, keeps the hidden number visible.

12.5 Limits of the evidence

No study found here tests a schedule of AI-free days directly. Nobody has compared “one AI-free day a week” against constant use or against task-based rules. The evidence supports the mechanism: AI raises performance, can lower unaided skill, and hides the loss. It does not yet support a specific dose. The studies are also short. The Bastani trial ran four 90-minute sessions, and the Anthropic quiz came minutes after the task. Long-term effects remain unknown.

12.6 Verdict

The answer to “Some days no AI?” is a qualified yes. AI-free time protects learning and exposes skill loss that steady AI use hides. But the calendar is a blunt tool. The sharper rule, and the one that fits the essay, is: no AI on the work you are trying to learn, AI as a tutor rather than an answer engine, and a regular unaided check on the skills you cannot afford to lose.

13 Human-Written, Simple, Readable: When Authorship Is the Value

The margin note claims that some code is valuable because a human wrote it, and because it is simple and easy to read. The note sits in an aside about AI, so it reads as a counterweight: AI makes code cheap to produce, but output volume is not the only measure of worth. I read the line as three linked claims. First, readability is where most of the value of code lies. Second, AI-generated code may tend to be less simple. Third, human authorship has value of its own, apart from what the text of the code says. This section tests each claim and then marks where the evidence runs out.

13.1 Code is mostly read, not written

The idea is old. In the 1985 preface to Structure and Interpretation of Computer Programs, Abelson and Sussman wrote that programs “must be written for people to read, and only incidentally for machines to execute” (Abelson and Sussman 1985). Field data backs this up. Xia and colleagues logged 3,148 working hours from 78 professional developers on 7 real projects. On average, the developers spent 58% of their time on program comprehension (Xia et al. 2018a). If more than half of a developer’s day goes to understanding code, then code that is quick to understand saves the largest share of cost. Simple code is not a style preference. It is the cheapest code to own.

13.2 Does AI output trade simplicity for volume?

Two large data sets suggest that AI-assisted code tends toward volume and duplication.

• GitClear studied 211 million changed lines from 2020 to 2024. Lines classed as copy/pasted rose from 8.3% to 12.3%. Moved (refactored) lines fell from 25% of changed lines in 2021 to under 10% in 2024. In 2024, copy/paste exceeded moved code for the first time in its data (GitClear 2025). Duplication is the opposite of simplicity: each clone is one more place to read and fix.

• DORA 2024 estimated that a 25% rise in AI adoption goes with a 7.2% fall in delivery stability. DORA’s reading is that AI makes it easy to write more code, which inflates change size, and larger batches carry more risk (The New Stack 2024).

Both findings are correlations. GitClear sells code-analysis tools, and it infers the role of AI from the timing of the trend, not from tagging each line as AI-written. DORA is a survey model. Neither proves that any single AI-written function is worse than a human one. Together they show a direction: when code becomes cheap to generate, teams generate more of it and simplify less.

13.3 Why human authorship can matter in itself

13.3.0.1 The author holds the theory.

Peter Naur argued in 1985 that a program is a theory in the minds of its programmers, and that the source text is a lossy record of it. A new programmer cannot rebuild the theory from the text alone; they need contact with people who hold it (Naur 1985b). Under this view, human-written code is valuable because a person exists who knows why it is shaped that way. Code generated and accepted without that understanding has no such person behind it.

13.3.0.2 Writing the code builds the skill.

Anthropic ran a randomized trial with 52 mostly junior software engineers on a Python coding task. The AI-assisted group scored 50% on a follow-up quiz; the hand-coding group scored 67%. The largest gap was on debugging questions. The AI group was not significantly faster. Participants who only delegated to the AI averaged under 40%, while those who asked the AI for explanations kept more of the skill (Shen and Tamkin 2026g). This ties the margin note to the essay’s theme: in a learning setting, the human act of writing is the product.

13.3.0.3 The law and the projects ask for a human author.

The U.S. Copyright Office’s January 2025 report holds that copyright protects only human authorship, not output wholly generated by AI. AI used as an assistive tool does not void protection (U.S. Copyright Office 2025). Several open-source projects go further. NetBSD presumes LLM-generated code to be “tainted” and bars it without written approval from core (The NetBSD Foundation 2024). Gentoo banned AI-generated contributions in April 2024, citing copyright, quality, and ethics (Tom’s Hardware 2024). QEMU declines patches believed to derive from AI output, because contributors cannot certify the license status that its Developer Certificate of Origin requires (QEMU Project 2025). For these projects, “a human wrote this” is a legal precondition, not a sentiment.

13.4 Limits and counterpoints

The note says “sometimes,” and the hedge is earned.

1. Human code is not automatically simple. Nothing in the evidence shows that people write simpler code than AI by default. Legacy human code is often the hardest code to read. Readability comes from discipline and review, whoever types.

2. AI can produce simple code on request. The GitClear and DORA trends describe how teams use the tools, not a hard limit of the tools.

3. Productivity evidence is mixed and dated. METR’s 2025 trial found 16 experienced open-source developers took 19% longer with AI tools, though they believed AI had sped them up by 20%. METR now labels that result as out of date, so it may not hold for current tools (METR 2025).

4. The copyright line is about control, not purity. The Copyright Office protects human-directed work made with AI assistance (U.S. Copyright Office 2025). The project bans are stricter than the law requires.

13.5 What this means for learning versus production

The line separates two kinds of value. In production, the value of code is what it costs to read, change, and defend. Simple code wins on cost; a human author who understands it wins on maintenance and, for some projects, on legal standing. In learning, the value is the change in the learner, and the evidence suggests that handing the writing to AI reduces it. In both settings, the case for human-written, simple code is not nostalgia. It rests on comprehension time, retained skill, and provenance. The fair version of the claim is narrow: when someone must understand, maintain, own, or learn from the code, a simple human-written version can be worth more than a larger generated one.

14 The “Codeberg Solution”: A Forge That Draws a Line on AI Code

The margin note says only “Codeberg solution.” It sits in an “AI aside” on a page about learning versus production. Codeberg is a nonprofit code-hosting site run by Codeberg e.V. in Berlin. It runs on Forgejo, a fork of Gitea, and as of November 2025 hosted over 300,000 repositories for more than 200,000 accounts (“Codeberg” 2026). The note most likely points to one decision. In July 2026, Codeberg’s members voted to ban projects made mostly of AI-generated code (Greshake Tzovaras et al. 2026a). This section asks three questions. What did Codeberg decide? Why? Does the rule work, and what does it offer an essay on learning versus production?

14.1 Possible readings of the note

The note is two words, so more than one reading is possible.

1. The AI-code ban (most likely). Codeberg’s July 2026 rule is the best-known “solution” the site has offered to the AI question. It is also the most recent, and it fits an aside about AI.

2. The crawler defense. Before the ban, Codeberg fought AI scraper bots with proof-of-work gates such as Anubis. A note-taker could call that a “solution” to AI load on servers.

3. The exit from GitHub. Some projects moved from GitHub to Codeberg in 2025–2026 over Microsoft’s AI focus (“Codeberg” 2026). “Codeberg solution” could mean “move your code where it will not train a model.”

This section treats reading 1 as primary and uses readings 2 and 3 as context. All three share one idea: a community chose a rule to keep human work separate from machine output.

14.2 What Codeberg decided

Codeberg’s general assembly passed two motions, announced on 23 July 2026 (Greshake Tzovaras et al. 2026a).

• No training on hosted data. Codeberg will not use the code or data of projects and users to train AI tools such as large language models (Greshake Tzovaras et al. 2026a).

• No mostly-AI projects. The Terms of Use now say, in § 2 (1) 7: “You must not share projects that mostly consist of code written by ‘generative AI’-tools (including services such as Claude, OpenAI Codex).” (“Codeberg Terms of Use” 2026)

The second motion passed 358 to 144, with 14 abstentions. About half the members voted (Greshake Tzovaras et al. 2026a; Sneddon 2026). That is roughly 71 percent in favor of those who cast a yes or no vote.

14.3 Why Codeberg did it

Codeberg’s blog post gives three reasons (Greshake Tzovaras et al. 2026a).

1. Cost. The post says one-person projects that lean on LLMs can use as many resources as some of the largest community projects. Hardware prices also rose: a drive that cost about EUR 700 a few years ago now costs about EUR 3,700 (Greshake Tzovaras et al. 2026a; Sneddon 2026).

2. Crawlers. AI web crawlers trigger costly database queries. The post says these slow the service for everyone and force admins to build defenses instead of features (Greshake Tzovaras et al. 2026a).

3. Trust. The post calls mass LLM use an attack on trust between contributors. It names low-quality submissions, license laundering, and the loss of the human collaboration that defines free software (Greshake Tzovaras et al. 2026a).

The Terms add two more grounds. Mostly-AI projects have unclear copyright status, and they lack safeguards against harmful code (“Codeberg Terms of Use” 2026).

The crawler problem predates the vote. Many open-source sites adopted Anubis, a proxy that makes each browser solve a hash puzzle before it reaches the server. LWN reports that the Linux kernel mailing list archive, Sourcehut, FFmpeg, and GNOME used it. In a Duke University pilot, it blocked over 4 million unwanted requests a day (Brockmeier 2025). In August 2025, Codeberg staff reported that AI crawlers “learned how to solve the Anubis challenges,” which caused a period of extreme slowness (Claburn 2025a; Mercer 2025). This shows why a technical gate alone did not settle the problem, and why Codeberg turned to a policy rule.

14.4 Does the rule work?

The rule turns on one word: “mostly.” Codeberg has not defined it. Critics ask whether it means 51 percent or 80 percent, and whether to count lines, commits, or how well the author understands the code (“Codeberg Says No More AI Slop, but Can Anyone Actually Prove It?” 2026). Codeberg will not scan repositories. Moderators will act case by case on reports (Greshake Tzovaras et al. 2026a; “Codeberg Says No More AI Slop, but Can Anyone Actually Prove It?” 2026). Critics note a paradox: reliable detection of AI code would likely need another AI tool (“Codeberg Says No More AI Slop, but Can Anyone Actually Prove It?” 2026). Some developers said they would move to self-hosted Forgejo or Gitea instead (“Codeberg Says No More AI Slop, but Can Anyone Actually Prove It?” 2026).

Codeberg’s answer is to target behavior, not percentages. Moderators will focus on projects “created by LLM ‘agents’ in autonomous ways” and on heavy LLM use that eats resources (Greshake Tzovaras et al. 2026a). Projects with an active community or a significant pre-LLM history stay welcome, even if they accept some LLM help. Small side experiments are discouraged but tolerated. No mass deletion is planned (Greshake Tzovaras et al. 2026a).

14.5 What this offers the essay

For an essay on learning versus production, the “Codeberg solution” is a working example of a line drawn on a gradient. Codeberg does not ban AI. It bans projects where the machine did most of the work and no human community stands behind the code. That maps onto the learning question. A student who uses AI for a small assist still writes, reads, and owns the code. A student who ships a project “mostly” written by AI has produced output but may have learned little.

The case also shows the cost of such a line. It needs a fuzzy word, human judgment, and trust. It cannot be measured by a tool. Any classroom or workplace rule on AI use will likely face the same three problems: where to set the threshold, how to detect a breach, and who decides.

Finally, Codeberg ties its rule to mission, not only cost. Its post frames free software as human collaboration (Greshake Tzovaras et al. 2026a). In that frame, code is not just a product. It is a record of people working and learning together. That is the strongest link between this margin note and the essay’s main theme.

15 An AI Usage Tax as a Price on Negative Externalities

The margin note reads: “AI usage tax for [crossed out] (negative externality).” The idea is clear even with one word lost. AI use imposes costs on people who do not choose it or pay for it. A tax on that use would make the user pay those costs. Economists call this a Pigouvian tax: a per-unit charge set equal to the harm that a transaction pushes onto third parties (“Pigouvian Tax” 2026). This section asks three questions. What harm might the note mean? Does evidence show that harm is real? And could a tax fix it, given that the essay sets learning against production?

15.1 What the crossed-out word could be

The word is illegible, so the note supports several readings. Each points to a different externality and a different payer.

• A group of users, such as “students.” This reading fits an essay on learning. The tax would discourage students from handing off the work that builds skill.

• A group of firms, such as “companies” or “corporations.” The harm is jobs lost to automation, and the payer is the employer that replaces workers.

• A purpose for the money, such as “schools” or “retraining.” Here “for” means “to fund,” not “on.” The tax pays to repair the harm.

The writer crossed the word out, which suggests doubt about who should pay. That doubt matters. A Pigouvian tax works only when it lands on the party whose choice causes the harm.

15.2 Three candidate externalities

15.2.0.1 Environmental cost.

This harm has the firmest numbers. Data centres used just over 1% of world electricity in 2024. The International Energy Agency’s central case has their use more than doubling to 945 TWh by 2030, a rise of 530 TWh. The IEA names AI as the largest driver, and expects AI to take 35–50% of data-centre power by 2030, up from 5–15% in recent years (Gabbatiss 2025). Water is a second cost. One study estimates that training GPT-3 in Microsoft’s US data centres could consume 5.4 million litres of water. It also estimates that the model “drinks” a 500 ml bottle for every 10–50 responses, depending on where and when it runs (Li et al. 2023). Local communities bear these costs, not the person who types the prompt.

15.2.0.2 Labor displacement.

Some scholars argue that AI layoffs create a demand externality. A firm that cuts workers saves on wages but ignores the lost spending of those workers across the economy. That paper argues for a Pigouvian automation tax to make firms count that loss (Falk and Tsoukalas 2026). Bill Gates first proposed a robot tax in 2017. On 26 August 2026 he revived it and widened it to cover AI tokens. He said a tax would “slow the rush away from human labor a little” and raise money for retraining and a stronger safety net (Owens 2026). The International Federation of Robotics rejected the idea. It said that taxing production tools, not profits, would hurt competitiveness (Owens 2026).

15.2.0.3 Lost learning.

This harm links the note most directly to the essay. Two studies suggest that AI help can raise output now and lower skill later.

• A field experiment with nearly 1,000 high school students tested two GPT-4 tutors. Students with a plain chat interface (“GPT Base”) scored 48% better on practice problems than a control group. Students with a tutor built to protect learning (“GPT Tutor”) scored 127% better. When the researchers removed access, GPT Base students did 17% worse on the exam than students who never had AI. The guardrails in GPT Tutor largely removed that harm (Bastani et al. 2025b).

• An MIT Media Lab study tracked 54 participants who wrote essays with ChatGPT, with a search engine, or with no tools, over four sessions in four months; 18 of them completed the fourth session. Brain connectivity fell as outside help rose. The ChatGPT group showed the weakest engagement and had more trouble quoting from essays they had just written (Kosmyna et al. 2025b). The authors stress that the study is a preprint, uses a small sample, and covers one task (Kosmyna et al. 2025b).

These results describe the learning-versus-production split in numbers. AI raised practice output by 48% and cut tested skill by 17%.

15.3 Is lost learning an externality at all?

This is the weak point of the note. An externality is a cost that falls on someone outside the transaction. A student who uses AI and learns less bears most of that cost personally. Economists usually call a cost to oneself an internality. The textbook tool for it is a nudge, a default, or a rule, not a Pigouvian tax.

A case for a true externality still exists, but it rests on spillovers:

• Employers and the public rely on degrees to signal skill. If AI lets students earn grades without the skill, the signal weakens for every graduate.

• Schools and taxpayers fund education. Lost learning wastes that public money.

• A workforce with weaker skills lowers the productivity of the people who work with it.

The analogy with attention markets helps here. One paper argues for a Pigouvian tax on attention capture by digital platforms. It treats lost focus as a social cost, not only a private one (Belgroun et al. 2025). An argument about AI and learning could follow the same path. No source I found makes that argument for AI in education directly.

15.4 Could a tax work?

A recent survey of AI taxation notes that taxes can do three jobs: correct harmful activity, redistribute costs and gains, and fund regulators (Faivre and Cen 2026). The survey lists corporate, consumption, and excise taxes as options. It also warns that each tax must match a specific harm (Faivre and Cen 2026).

The learning evidence points to a problem for a flat usage tax. In the Bastani study, the same model helped or hurt depending on its design (Bastani et al. 2025b). A tax on every token would charge the student who learns with GPT Tutor as much as the one who copies from GPT Base. A Pigouvian tax should track the harm, and here the harm tracks how AI is used, not how much. Design rules, guardrails, and assessment methods aim at the harm more precisely.

The environmental case fits a tax much better. Energy and water costs rise with each query, so a charge per unit of compute or electricity tracks the harm. Taxing the electricity, not the user, reaches the same cost with less paperwork.

15.5 Summary

The note proposes a sound economic tool. Its fit depends on the lost word. If the target is the energy and water that AI uses, a usage tax is a textbook Pigouvian remedy, backed by IEA forecasts. If the target is jobs, the idea has a prominent backer and organised opposition. If the target is student learning, the evidence of harm is real but early. That harm falls mostly on the learner, and it depends on how the tool is designed. For the essay’s theme, I would argue a different claim: AI usage counts as production, and production priced below its social cost will crowd out learning.

16 The AI Bottler Tax: Who Pays for the Repos and CI That AI Creates?

The margin note “AI bottler tax” proposes a pricing rule. If AI use creates downstream costs, such as extra repositories, storage, and continuous integration (CI) runs, the AI user should pay those costs in the AI bill. The author points to Codeberg as the example. The name borrows from beverage container law, where the seller of a drink pays up front for what happens to the empty bottle.

This section asks four questions:

1. What does the bottle analogy actually mean in policy terms?

2. What costs does AI-assisted development push onto code hosts, and what did Codeberg say about them?

3. Does any vendor already bundle those costs into the AI price?

4. What does the idea mean for the essay’s theme of learning versus production?

16.1 The bottle analogy: deposits and producer responsibility

A bottle bill puts a refundable deposit on each beverage container. The buyer pays the deposit at purchase and gets it back on return (Wikipedia contributors 2026). The broader policy family is extended producer responsibility (EPR), which makes producers responsible for managing their packaging through its life cycle. Bottle bills are a narrow form of EPR that makes beverage distributors responsible for recovering their containers (Recycling Today 2023).

Mapped onto AI, the “bottle” is the code artifact an AI tool produces: a repository, a pull request, a CI job. The “litter” is the cost that lands on someone else, such as a free forge or a volunteer maintainer. The author’s “bottler tax” asks the AI seller, or the AI buyer through the seller, to carry that cost at the point of sale.

16.2 Codeberg: the cost lands on a donation-funded host

Codeberg is a non-profit, donation-funded Git forge run by the association Codeberg e.V. On 23 July 2026 it published the results of two member votes (Greshake Tzovaras et al. 2026b). One commits Codeberg never to use hosted data to train large language models (LLMs). The other changes the Terms of Use to prohibit “vibe-coded” projects. That vote passed 358 to 144, with 14 abstentions and about 50% turnout (Claburn 2026).

Codeberg’s case rests on cost shifting. Its post states that LLMs cost so much that companies “externalize the costs on a massive scale” (Greshake Tzovaras et al. 2026b). It names three channels:

• Hardware prices. Codeberg reports that a type of drive it bought for EUR 700 some years ago now costs EUR 3,700, roughly five times more (Greshake Tzovaras et al. 2026b). The Register converts this to about $800 and $4,200 (Claburn 2026).

• CI and storage. Codeberg targets projects whose storage and CI/CD use is significantly larger than the people involved could have created by hand, and calls them “ghost projects” (Greshake Tzovaras et al. 2026b; Claburn 2026).

• Crawlers. In August 2025 AI crawlers slowed Codeberg badly. They appeared to solve the Anubis proof-of-work challenge that had kept them out (Claburn 2025b).

Codeberg chose a ban, not a fee. It says its moderators will not compile an exhaustive removal list or scan content automatically, and The Register judges enforcement unlikely given Codeberg’s limited resources (Greshake Tzovaras et al. 2026b; Claburn 2026). This is the gap the author’s note targets. A free host cannot bill an AI vendor, so it can only refuse the traffic. The bottler tax would instead make the cost visible and route it back to the party that caused it.

16.3 GitHub: the tax already exists, inside one company

GitHub shows that bundling is possible when the AI vendor and the code host are the same firm. On 27 April 2026 GitHub announced that Copilot would move to usage-based “GitHub AI Credits” on 1 June 2026 (Rodriguez 2026). Plan prices stayed the same: Copilot Pro at $10 per month includes $10 of credits, and Business at $19 per user includes $19. The same post states that Copilot code review will consume both AI credits and GitHub Actions minutes, at the standard per-minute rates (Rodriguez 2026).

A third-party analysis from Tenki puts numbers on this (Wang 2026). Actions minutes on a standard Linux 2-core runner cost $0.006 each beyond the plan allowance. Free accounts include 2,000 minutes a month, and Enterprise Cloud includes 50,000. Tenki’s example of 2,000 reviews at an assumed 4 billed minutes each uses 8,000 minutes, $48 if all of it falls beyond the allowance. On public repositories the Actions minutes stay free, though AI credits are still billed. GitHub’s documentation states that the Copilot coding agent (now called Copilot cloud agent) also uses GitHub Actions minutes as well as AI credits (GitHub 2026); a July 2025 GitHub announcement already said its Actions minutes vary with task length (Akash1134 2025).

GitHub’s model is a partial bottler tax. It charges for CI on GitHub’s own runners. It does not charge for load on other forges, for crawler traffic, or for maintainer time spent reviewing AI pull requests.

16.4 Open questions and limits

The note raises design problems the sources do not solve:

• Attribution. A host must tell AI-made work from human work before it can bill for it. Codeberg says it cannot police this well (Claburn 2026).

• Cross-party billing. A deposit works because state law makes distributors responsible for taking their containers back (Recycling Today 2023). No such scheme links AI vendors to independent forges. Creating one would take contracts or regulation. This is my inference, not a sourced claim.

• Unpriced costs. Reviewer time and energy use have no meter today, so a fee would cover only the measurable part.

16.5 Link to learning versus production

The bottler tax matters for the essay’s main contrast. A learner who uses AI to explore creates many throwaway repos and CI runs. A producer creates fewer, longer-lived ones. Under GitHub’s bundled pricing, the learner sees the cost of each extra run in the AI bill. Under Codeberg’s ban, the learner who leans on AI is simply turned away. My reading is that a priced model keeps learning possible while making waste visible, and a ban protects the commons but closes the door. Both readings are the author’s and my interpretation, not findings of the cited sources.

17 AI as a Code Helper for Small Parts and Tedium

The margin note reads: “AI small parts and tedium solution: code helper.” We read it as a proposed division of labor. The human keeps the hard, central thinking. The AI takes the small, repetitive pieces: boilerplate, a schema migration, a test scaffold, a lookup of an API call. Under the essay’s theme of learning versus production, the note makes a claim about production. It also hides a question about learning. If the AI writes the “small parts,” does the human still learn from them?

This section asks four questions:

1. Does an AI code helper make developers faster?

2. Is the gain largest on small, tedious tasks?

3. What does the helper cost a person who is still learning?

4. Where does the line between “tedium” and “learning” fall?

17.1 The production case: speed on bounded tasks

The best-known evidence supports the note. In a 2023 controlled experiment, Peng and colleagues asked recruited developers to write an HTTP server in JavaScript as fast as they could (Peng et al. 2023b). The group with GitHub Copilot finished 55.8% faster than the control group. The 95% confidence interval ran from 21% to 89%. GitHub’s own report on the same work gives the raw times: about 71 minutes with Copilot against 161 minutes without (Kalliamvakou 2022a). Developers with less experience gained the most (Peng et al. 2023b).

The task matters. An HTTP server in JavaScript is small, well defined, and full of standard patterns. It is close to the “small parts” the note describes.

GitHub’s survey data points the same way. In the same report, 87% of respondents said Copilot helped them preserve mental effort during repetitive tasks, and 73% said it helped them stay in the flow (Kalliamvakou 2022a). Between 60% and 75% said they felt less frustrated and could focus on more satisfying work. These are self-reports from a vendor, so they measure how the tool feels, not what it produces.

17.2 The limit: real codebases and experienced developers

The gain shrinks when the task stops being small. In early 2025, METR ran a randomized trial with 16 experienced open-source developers on 246 real tasks in mature repositories they knew well, about five years each on average (Becker et al. 2025c). With AI tools, mainly Cursor with Claude 3.5 and 3.7 Sonnet, they took 19% longer. Before the study they forecast a 24% speedup. Afterward they still believed AI had made them 20% faster. METR now marks the result as out of date and says it no longer reflects current AI tools (Becker et al. 2025c).

Survey data shows the same friction. In the 2025 Stack Overflow Developer Survey, 84% of developers said they use or plan to use AI tools, but 46% distrust their accuracy and only 33% trust it (Stack Overflow 2025a). The top frustration, named by 66%, was “AI solutions that are almost right, but not quite” (Stack Overflow 2025a).

Together these results support a narrow version of the note. The helper pays off on bounded, familiar, low-stakes pieces. It pays off less on large, context-heavy work, where the human must check every “almost right” answer.

17.3 The learning cost: who does the small parts matters

The note treats tedium as waste. For a learner, some of that tedium is the lesson.

A January 2026 Anthropic study tested this directly (Shen and Tamkin 2026h). Judy Hanwen Shen and Alex Tamkin had 52 mostly junior engineers learn Trio, a Python library for asynchronous programming. One group could use an AI assistant; the other coded by hand. On a later quiz, the AI group averaged 50% and the hand-coding group 67%. The AI group finished only about two minutes faster, a difference that was not statistically significant. The largest score gap was on debugging questions.

The study also found that the way people used the AI mattered more than whether they used it (Shen and Tamkin 2026h):

• Low scorers delegated all code writing, slid into full reliance, or used the AI to fix errors without understanding them.

• High scorers asked conceptual questions and fixed their own errors, or generated code and then asked follow-up questions to understand it.

The subgroups were small, from 2 to 7 people each, so these patterns are suggestive, not firm.

Classroom research agrees. Prather and colleagues observed 21 novice programmers with eye tracking and interviews (Prather et al. 2024). Twenty of 21 finished the problem. Strong students used AI to speed up a plan they already had. Struggling students saw their metacognitive problems grow, and they left with “an illusion of competence,” rating their work above their actual performance. The authors call this a widening gap between the two groups.

17.4 Where tedium ends and learning begins

The evidence suggests one rule for the essay. A task is “tedium” only for someone who has already mastered it. For an expert, a SQL migration is rote, and handing it to a helper frees attention for design. For a student, the same migration is practice in schemas, constraints, and failure modes. Handing it off removes the practice and, per the Anthropic results, weakens debugging most (Shen and Tamkin 2026h).

So the note works as a production rule with two conditions:

1. The human already understands the part. Then the helper saves time and effort, as in the Copilot experiment.

2. The human checks the output. The “almost right” problem and the METR perception gap show that people overrate AI help (Stack Overflow 2025a; Becker et al. 2025c).

For learning, the evidence supports a different use. Use the helper as a tutor, not a ghostwriter. Ask it why, not just what. Write the small parts by hand until they truly become tedious. The line between “small part” and “core skill” is not a fixed property of the code. It moves as the person learns.

17.5 Limits of this evidence

The speed studies used tools from 2022 to 2025, and tools change fast. The GitHub figures come from the vendor. The METR sample had 16 developers, and the Anthropic sample had 52. No study here followed learners for months, so the long-term effect of handing off “small parts” remains unmeasured.

18 Pair Programming, AI Edition: Who Learns When the Partner Is a Model?

The margin note “pair programming AI edition” points at a familiar practice with a new partner. In classic pair programming, two people share one keyboard. The driver types. The navigator reviews, questions, and plans ahead. Vendors sell AI coding assistants with the same frame. GitHub announced Copilot in June 2021 as “your AI pair programmer” (Friedman 2021). For an essay on learning versus production, the note raises three questions:

1. What did human pair programming deliver, and to whom?

2. Does an AI partner speed up production?

3. Does an AI partner help or hurt learning?

The short answer: the label fits the production side better than the learning side. An AI partner can type fast. It does not, by default, make the human think.

18.1 What the human version delivered

The best summary of the human evidence is a 2009 meta-analysis by Hannay, Dybå, Arisholm, and Sjøberg. It pooled 18 empirical studies (Hannay et al. 2009). It found a small gain in code quality over solo work, a medium gain in speed (shorter duration), and a medium increase in total effort. The benefit depended on who paired and on what. Pairs did better on quality as tasks grew complex, and were faster on simple tasks. Secondary summaries report that junior developers gained the most; this could not be confirmed from the abstract. These figures come from the abstract and secondary summaries, not from the full text, which sits behind a paywall.

Two points matter here. First, human pairing was never a pure production tool. It costs extra hours, and the payback comes partly as fewer defects and partly as knowledge spread across the team. Second, the people who gained most were novices. Pairing worked as an apprenticeship.

18.2 The production case for the AI partner

The early production numbers were striking. In a 2023 controlled experiment, Peng and colleagues asked developers to build an HTTP server in JavaScript as fast as possible. The group with Copilot finished 55.8% faster than the control group (Peng et al. 2023c). That task was small, greenfield, and well specified: the kind of work where autocomplete shines.

Real work on mature code tells a different story. In early 2025, METR ran a randomized trial with 16 experienced open-source developers on 246 real issues in their own repositories. Each issue took about two hours. The developers mostly used Cursor Pro with Claude 3.5 and 3.7 Sonnet. With AI allowed, they took 19% longer. Before the study, they forecast a 24% speedup. Afterward, they still believed AI had made them 20% faster (“Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” 2025b). METR now labels the result historical. Its page says a February 2026 update reflects current tools and that the 2025 figures no longer describe today’s models. I did not open that update, so its numbers are not reported here.

The gap between felt speed and measured speed is the key lesson for the essay. An AI partner feels productive. Feeling is a poor gauge of output.

18.3 The learning case against the AI partner

The sharpest evidence on learning comes from Anthropic. In a randomized trial published in January 2026, Shen and Tamkin gave 52 mostly junior engineers a task in Trio, a Python library for asynchronous code that none of them knew (Shen and Tamkin 2026i). One group could use an AI assistant. The other coded by hand. Afterward, both took a quiz on the concepts they had just used.

The AI group scored 17 points lower, close to two letter grades. They saved about two minutes, and that saving was not significant. So the AI bought almost no speed and cost a large share of learning.

The study’s most useful finding concerns how people used the assistant. Some high scorers asked only conceptual questions and fixed errors on their own (7 participants). Others generated code and then asked follow-up questions to understand it (2), or asked for code and explanation together (3). These patterns kept learning intact. The low scorers handed the thinking to the model. The subgroups are small, so treat this split as a hint, not a rule.

18.4 Is the analogy sound?

Researchers question the pairing label itself. Ma, Wu, and Koedinger compared human-human pairing with human-AI “pAIr” programming in 2023 (Ma et al. 2023). They found the evidence for both mixed. They also noted that studies of the AI version use thinner measures than the decades of human pairing research. One factor from the human literature carries over: a mismatch in expertise between partners hurts results. An AI that does not adapt to the user’s level repeats that mismatch.

Welter and colleagues at Saarland University and Siemens tested the analogy directly in 2025 (Welter et al. 2025). Human pairs worked without AI. Solo developers worked with Copilot. Both settings showed a similar rate of successful knowledge transfer on overlapping topics. But developers accepted Copilot’s suggestions with less scrutiny than a human partner’s. On the plus side, Copilot sometimes reminded them of code details they would have missed. The sample was small: 19 students, in six human pairs and seven solo Copilot sessions.

That lower scrutiny breaks the core mechanism of pairing. A human navigator pushes back. They ask “why?” and make the driver explain. A model that completes your line does neither unless you ask. In the AI edition, the human often becomes the navigator who has stopped navigating.

18.5 Implications for learning versus production

The evidence supports a split verdict.

• For production, an AI partner can speed up small, well-defined tasks a lot (55.8% in one trial). On complex work in familiar code, the 2025 data showed a slowdown that users did not notice.

• For learning, an AI partner used as a code generator cuts what people retain (50% versus 67%). Used as a tutor that answers conceptual questions, it seems to preserve learning.

• The role decides the outcome. Human pairing reportedly helped juniors most, plausibly because a person forced them to reason. To keep that benefit, the learner must ask the AI for explanations, not answers, and must stay the one who decides.

For an essay on learning versus production, “pair programming AI edition” is a useful foil. The name promises the old apprenticeship. The default behavior delivers autocomplete. Whether a learner gets a partner or a crutch depends on how they use it, not on the tool.

18.6 Unverified items

• The Hannay et al. figures (18 studies, more effort, quality gains on complex tasks) come from the abstract and secondary summaries, not from the full text. The claim that juniors gained most could not be confirmed.

• METR’s February 2026 update was not opened; its findings are not reported.

19 Selling the Guarantee: A Forward-Deployed Engineering Business

19.1 Reading the line

The page asks what a human adds to an AI. It gives three answers: a guarantee of completion, a guarantee of quality, and a contract that the problem gets solved. The next line names a job title, “forward deployed engineer”, and asks how to start a business that maximizes those three things.

I read the line as a business question, not a career question. If a model can write the code, the scarce good is no longer the code. The scarce good is someone who carries the risk that the code works in a real company. A forward-deployed engineering (FDE) firm sells exactly that. This section asks four questions:

1. What is an FDE, and where did the model come from?

2. Is there evidence that buyers pay for completion and quality, not for tools?

3. How do you turn each of the three “added values” into a contract term?

4. What are the economics and the traps?

19.2 What a forward-deployed engineer is

Palantir invented the role. Its early clients were intelligence and defense agencies that struggled to put its software to work, so Palantir “stopped shipping software and started shipping engineers” into those agencies (“What Is a Forward-Deployed Engineer? Definition, Origin and Model” 2026). Gergely Orosz reports that Palantir called the role “Delta” and that, until about 2016, it employed more FDEs than regular software engineers (Orosz 2025). He sums up the difference with Palantir’s own contrast: a product engineer builds one capability for many customers; an FDE builds many capabilities for one customer (Orosz 2025).

The AI boom revived the role. OpenAI started an FDE team in early 2025. Its projects run in three phases: scoping, validation (writing the evaluation criteria), and delivery (Orosz 2025). In June 2025, Joe Schmidt of Andreessen Horowitz called the FDE “the hottest job in startups”. His summary of the buyer is blunt: enterprises buying AI are like a grandma with a new iPhone: they “need you to set it up” (Schmidt 2025). Demand data agrees. Bloomberry, using Revealera data, counted 1,165% year-over-year growth in FDE postings (January–October 2025 against the same months of 2024), from a small base (Agrawal 2026); the recruiting platform Paraform reports 350% growth in FDE postings on its own platform from the first quarter of 2025 to the first quarter of 2026 (Kim 2026). These counts come from secondary blogs and I did not check the underlying datasets.

19.3 Evidence that buyers pay for completion

The strongest evidence is how often AI projects fail without hands-on delivery. MIT’s NANDA initiative reported in August 2025 that about 95% of enterprise generative-AI pilots stalled with little or no measurable business impact (“MIT Report” 2025). The study drew on about 150 leadership interviews, a survey of 350 employees, and 300 public deployments. It blamed integration and workflow fit, not model quality. Purchased tools from specialized vendors succeeded about 67% of the time; internal builds succeeded about one-third as often (“MIT Report” 2025).

That gap is the market for the three added values. A buyer who has watched a pilot stall does not want another model. The buyer wants someone accountable for getting it into production.

Investors frame the same shift as “service as software”. Foundation Capital sizes the pool at $4.6 trillion of salaries and outsourced services, against roughly $200 billion for traditional software (“The $4.6T Services-as-Software Opportunity” 2026). Its 2026 review of the first year makes two points that matter here. First, FDEs have become “one of the most strategic assets” in enterprise AI firms. Second, buyers now expect to see the integration and the outcome before they sign (“The $4.6T Services-as-Software Opportunity” 2026).

19.4 Turning each added value into a contract term

A guarantee is only worth something if it is written down and priced. Table 7 maps each value on the brainstorm page to a mechanism a small firm can offer. The mechanisms are my synthesis; the examples are cited.

Completion. Price the job, not the hours. Hourly billing moves the risk of delay to the client, which is the opposite of a completion guarantee. A fixed price with milestone payments moves that risk back to the firm.

Quality. Write the test before the build. OpenAI’s FDE process puts evaluation criteria in its own phase, before delivery (Orosz 2025). For a small firm, the agreed test suite or evaluation set becomes the legal definition of “done”. That makes quality checkable instead of arguable.

A solved problem. Charge only when the outcome happens. Intercom prices its Fin AI agent at $0.99 per outcome (a confirmed resolution, a completed workflow, or a handoff) and charges nothing for a conversation with no outcome (“Intercom Pricing” 2026a). It backs this with a written promise: high-volume customers (over 250,000 conversations a month) who do not reach a 65% resolution rate can claim $1 million, and new customers get a 90-day satisfaction refund of up to $1 million (“Fin Million Dollar Guarantee” 2026). That is the brainstorm’s “contract that the thing will be actually solved”, turned into a product page.

19.5 How to start: a minimum version

The sources suggest a short path. Each step below cites its basis or is marked as my own recommendation.

1. Pick one workflow in one industry. MIT found the highest returns in back-office automation, not in sales and marketing, where most budgets go (“MIT Report” 2025). (Recommendation: start where returns are proven.)

2. Sell a paid pilot on the client’s real data. Buyers now expect to see the outcome before a full contract (“The $4.6T Services-as-Software Opportunity” 2026). Charge for it, so the pilot filters out buyers who are not serious. (Recommendation.)

3. Write the acceptance test into the contract, then build against it (Orosz 2025).

4. Reuse everything. Schmidt advises building shared libraries, automating data pipelines and integrations, and documenting the work so it scales (Schmidt 2025). Each repeat job should cost less than the last.

5. Move toward outcome pricing once you can predict your success rate. Foundation Capital describes a path from access to usage to workflow to outcome pricing (“The $4.6T Services-as-Software Opportunity” 2026).

19.6 Economics and traps

The model trades margin for a moat. Schmidt’s own example: ServiceNow went public with 63.2% gross margin and Workday with 54.1%; ServiceNow later reached 79% and Workday 75% (Schmidt 2025). Services weigh on margin early. The bet is that the deep integration makes the vendor hard to replace.

A rough per-engineer model shows the bar. KDnuggets reports a median FDE base salary of about $174,000 (Mayo 2026). Estimate: with a 1.3x load for benefits, tools, and travel, one engineer costs about $225,000 a year. To hold a 50% gross margin, each engineer must bill about $450,000 a year, or about $37,500 a month. The load factor and margin target are my assumptions, not sourced figures.

Three traps stand out:

• The consulting trap. Critics call much FDE work “consulting with a better title”. Without a loop that feeds client work back into a product, the firm becomes a body shop that bills hours (Mayo 2026).

• Burnout. The role can mean up to 50% travel and accountability for adoption the engineer cannot fully control (Mayo 2026). Orosz cites 25% on site at Palantir and up to 50% at Commure (Orosz 2025).

• Unbounded guarantees. A guarantee is a liability. Intercom limits its $1 million promise by volume, region, and platform (“Fin Million Dollar Guarantee” 2026). A small firm needs the same limits: a capped refund, a defined test, and a fixed scope. (Recommendation.)

19.7 Answer to the line

The business that maximizes the three added values does not sell engineering time. It sells a written, capped promise: this workflow will pass this test by this date, or you pay less. The FDE is the person who makes that promise safe to sign. The evidence supports demand: most AI pilots fail, and buyers already pay vendors who carry delivery risk. The open question is whether a small firm can price its guarantee above its failure rate before it has enough jobs to know that rate.

20 The Contract Is the Product

The brainstorm line “The contract is the product” makes a claim about what a production team actually ships. A learner writes code to understand something. The code is a means, and the understanding is the result. A production team ships something different: a set of promises that other people build on. Those promises are the contract. The code behind them can change, be rewritten, or be generated by a machine. The contract cannot change without breaking someone.

This section reads “contract” in its software sense: the interface, its documented behavior, and the guarantees a caller may rely on. It asks four questions:

1. Where does the idea come from, and how old is it?

2. Who decides what the contract really is: the author or the users?

3. How do production teams make a contract explicit and testable?

4. Does AI code generation make the claim stronger?

20.1 An old idea: design by contract

Bertrand Meyer gave the idea its name. In Design by Contract, built into his Eiffel language, every routine states a precondition and a postcondition. The precondition is what a caller must satisfy. The postcondition is what the routine promises in return, provided the caller kept its side (Meyer 1992; “Design by Contract” 2026). Invariants add conditions that must always remain true (“Design by Contract” 2026). Eiffel writes these as require and ensure clauses next to the code (Meyer 1992).

Meyer’s framing is a business framing. A contract assigns obligations and benefits to two parties. That framing explains why the contract, and not the code, is what a customer buys. The customer cares that sort returns a sorted list. The customer does not care which algorithm does it.

20.2 A stronger version: the contract defines the release

Semantic Versioning turns the idea into a release rule. Its first requirement is that software “must declare a public API” (Preston-Werner 2013). Version 1.0.0 defines that API. Every later version number then encodes how the contract changed: a patch keeps it, a minor release extends it, and a major release breaks it (Preston-Werner 2013). The version number does not describe the code at all. It describes the contract. Under SemVer, a full rewrite that leaves the API unchanged and backward compatible does not call for a major release.

Amazon applied the same rule to a whole company. Steve Yegge’s 2011 “platforms rant” reports a mandate from Jeff Bezos, issued around 2002 by Yegge’s estimate,: all teams must expose their data and functionality through service interfaces, with no direct links, no shared databases, and no back doors (Yegge 2011). Each team’s product, to the rest of Amazon, became its interface. Yegge presents this as the root of Amazon’s platform business. That causal claim is his account, not a measured result.

20.3 The catch: users write the real contract

The line has a hard edge that the brainstorm may intend. The author does not fully control the contract. Hyrum’s Law states it: “With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody” (Wright 2026). Hyrum Wright made the observation while running large library migrations at Google. Small changes to core libraries broke distant systems that relied on undocumented details (Wright 2026).

Hyrum’s Law makes “the contract is the product” true in a way the author may not like. The real contract is every observable behavior: output order, timing, error text, default values, and even bugs. These examples are illustrative; the cited commentary restates the law but does not list them (“Hyrum’s Law” 2026). So a production team ships more than it documents. A learner never meets this problem, because a learning project has no users who depend on it.

20.4 Making the contract explicit

Production teams answer Hyrum’s Law by writing the contract down and testing it. Three practices stand out.

• Contract-first APIs. Teams agree on a machine-readable API description before they write the implementation. The description then generates types, client SDKs, server stubs, mock data, and validation schemas for both sides (Mikhin and Turner 2025).

• Consumer-driven contracts. Ian Robinson’s 2006 pattern, published on Martin Fowler’s site, has each consumer state what it needs from a provider. The provider tests against the union of those needs (Robinson 2006). This turns the hidden contract of Hyrum’s Law into a visible one, at least for known consumers.

• Version policy. SemVer forces the team to decide, at every release, whether the contract changed (Preston-Werner 2013).

Each practice moves effort from the code to the contract. That shift is the practical meaning of the brainstorm line.

20.5 AI code generation sharpens the claim

AI coding tools push the idea further. GitHub’s Spec Kit describes “spec-driven development” with a direct inversion: “Specifications don’t serve code—code serves specifications” (“Specification-Driven Development (Spec-Driven.md, Spec Kit)” 2025). The same document says the specification “becomes the primary artifact” and code becomes “its expression in a particular language and framework” (“Specification-Driven Development (Spec-Driven.md, Spec Kit)” 2025). In this model, an agent can regenerate the code from the specification at any time. The specification and its tests are what the team maintains.

This is the strongest version of the line. If a machine can write the implementation cheaply, the scarce and valuable work is stating the contract precisely and checking that the code meets it. Spec Kit is a young tool, and no source opened for this section measures whether spec-driven teams ship fewer defects. That outcome is unverified.

20.6 What this means for the essay

The line marks a clean boundary between learning and production. In learning, the code is the product, because writing it builds the skill. In production, the code is a cost. The product is the set of guarantees that callers, customers, and other teams build on. Three consequences follow:

1. A production engineer should spend effort on interfaces, tests, and version policy, not only on clever internals.

2. Every observable behavior is part of the product, documented or not, once enough users exist.

3. As AI tools make code cheaper, the contract takes a larger share of the value.

The tension for a learner is direct. Learning rewards writing the implementation yourself. Production rewards defining what the implementation must do and proving that it does it. An essay on learning versus production can treat this line as the point where the two goals separate.

21 “All Good Features Are Secret”

The page ends with a five-word claim: “All good features are secret.” The line carries no context, so this section first names the readings it supports. It then tests each reading against evidence. The short verdict: the line is false as a universal rule, but it points at a real pattern. The features that give the most leverage are often the ones that a beginner cannot see. That gap matters for an essay on learning versus production.

21.1 Three possible readings

The word “secret” can mean three different things here. The page does not say which one the writer meant.

1. Strategic secret. A good feature gives an edge that competitors do not see or do not understand. This is the business reading.

2. Hidden from the user. A good feature sits out of sight, behind a shortcut, a flag, or a menu. Experts find it. Novices never do. This is the interface reading.

3. Hidden from the learner. The most useful parts of a tool or language do not appear in the tutorial. You learn them only by use, by reading other people’s code, or by asking. This is the learning reading, and it fits the page title best.

The questions below follow from these readings. Is secrecy a cause of value, or only a side effect? How often do users miss features that exist? And does hiding power from beginners help or hurt them?

21.2 Reading 1: the secret as competitive edge

Two well-known startup texts support the strategic reading. Paul Graham wrote that he and Robert Morris started Viaweb in the summer of 1995 and wrote its software primarily in Lisp. He never spoke about Lisp in public while they worked on it, because “a startup should give its competitors as little information as possible” (Graham 2001). He argued that a technical advantage that competitors do not understand is the most valuable thing a business can have (Graham 2001). He even read competitors’ job ads: an ad for Lisp hackers would have worried him (Graham 2001).

Peter Thiel makes a broader version of the claim in Zero to One (2014). Quote collections attribute to him the line that every great business is built around a secret that is hidden from the outside (“Zero to One Quotes by Peter Thiel” n.d.). Summaries of the book treat “secrets” as its central idea (Li n.d.).

This reading has a limit. Graham’s secret was a tool, not a feature that customers saw. Viaweb’s customers saw the store builder. The secret was how the team shipped features faster than rivals. So the strategic reading supports a narrower claim: the best production advantages are often invisible to the market. It does not show that good user-facing features must be hidden.

21.3 Reading 2: features users cannot find

The interface reading has the strongest data, and the data cuts against the line. Microsoft found that hiding features made them worthless to most users. Jensen Harris, who led the Office 2007 user interface design, described how Word grew from 2 toolbars in Word 1.0 (1989) to 31 toolbars in Word 2003, and from about 50 menu items to about 300 (Čuhalev 2008). The team added new features, “but hardly anyone found them” (Čuhalev 2008). Microsoft had a large base of evidence: over 3 billion anonymous sessions and about 150 million command clicks in Word each month (Čuhalev 2008). The Ribbon was built to fix the problem of users not knowing that features existed (“Ribbon (Computing)” n.d.). Steven Sinofsky’s account of the project adds a concrete case. When early Excel moved the “Set Print Area” command off the File menu, it jumped to the top of customer support calls (Sinofsky 2022).

Popular claims go further, but they are weak. A widely cited figure says that 64% of features are rarely or never used. Mike Cohn traced it to a Standish Group talk at the XP 2002 conference. He found the data came from a study of only four internal applications, with no commercial products (Cohn n.d.). This section therefore does not use that number as evidence. The Office data alone shows the pattern: a feature that no one can find delivers no value.

Design theory says the same. Don Norman names discoverability, figuring out what actions are possible and how to do them, as one of the two most important properties of good design (Stoneman n.d.). Under this reading, a “secret” feature is a design failure, not a mark of quality.

21.4 Reading 3: secrets that reward expertise

A middle position reconciles the first two readings. Jakob Nielsen’s seventh usability heuristic, “flexibility and efficiency of use,” asks for accelerators such as shortcuts and macros. These are often unseen by novices and speed up experts (“Flexibility and Efficiency of Use (Usability Heuristic #7)” n.d.). The Nielsen Norman Group also says that the trick is to make an accelerator easy to find without getting in the novice’s way, for example by printing the keyboard shortcut next to the menu command (“Flexibility and Efficiency of Use (Usability Heuristic #7)” n.d.). The novice ignores it. Repeated exposure teaches the expert.

This is the learning version of the line. Programming culture has a whole genre built on it. A University of Michigan lab wiki, for example, sends its students to a Stack Overflow thread titled “Hidden features of Python” (“Useful Python Links” n.d.). (The thread’s current status could not be checked; Stack Overflow blocked the fetch.) The genre exists because the features that make experts fast do not appear in the first chapter.

21.5 What this means for learning versus production

Read through the essay’s title, the line makes a useful point. In production, secrecy can be an asset when the secret is your method, as with Viaweb’s Lisp. It is a liability when the secret is a feature your users need. In learning, the “secret” features are the payoff for going past the tutorial. A learner who only follows the official path will miss them. A learner who builds real things, reads other people’s code, and asks “how did they do that?” will find them.

So a more accurate version of the line is: the features that create the most leverage are rarely the ones that are advertised. The word “all” does not survive the evidence. The Office team showed that hiding a feature from everyone kills it.

21.6 Unverified points

• The Thiel quote comes from quote collections and book summaries, not from the book itself.

• The Nielsen Norman Group article returned an access error. Its wording here comes from search-result text, not a full read.

• The current status of the Stack Overflow “Hidden features of Python” thread was not checked.

• Publication years marked “n.d.” in the references were not confirmed.

22 The Babysitting Tax: Why Supervising an AI Is Hard Work

The note makes two claims. First, a human must keep “some” attention on an AI, or the result drifts from what was ordered: the AI delivers a calzone when the customer asked for a pizza. The ingredients are right. The shape is wrong. Second, this partial attention is taxing, because the human wants to do something that feels more productive than watching a machine.

Both claims match a long research record. Human-factors researchers studied the same problem in control rooms and cockpits decades before large language models existed. Recent studies of AI coding tools show the same pattern. This section asks three questions:

1. Why does AI output need a human at all, if it is mostly right?

2. Why is light, intermittent supervision so draining?

3. Does babysitting actually cost time, or does it only feel that way?

22.1 The calzone problem: output that is almost right

The calzone image describes a specific failure. The AI does not produce garbage. It produces something plausible, built from the correct parts, that misses the intent. Only a person who knows what the pizza should look like can catch it.

Developers report exactly this failure. The 2025 Stack Overflow Developer Survey drew more than 49,000 responses from 177 countries (“Stack Overflow’s 2025 Developer Survey Reveals Trust in AI at an All Time Low” 2025). Its top frustration with AI tools, cited by 66% of respondents, was “AI solutions that are almost right, but not quite” (“2025 Stack Overflow Developer Survey” 2025b). The second, at 45%, was that debugging AI-generated code takes more time (“2025 Stack Overflow Developer Survey” 2025b). Trust fell too: 46% said they distrust the accuracy of AI output, up from 31% the year before (“Stack Overflow’s 2025 Developer Survey Reveals Trust in AI at an All Time Low” 2025).

An almost-right answer is more dangerous than a plainly wrong one. A wrong answer fails loudly. An almost-right answer passes a glance. The human cannot skip the check, because the defect hides in the details. That is why the note says “some” attention and not “no” attention.

A survey by Microsoft Research and Carnegie Mellon describes how this changes the job. Lee and colleagues surveyed 319 knowledge workers, who gave 936 examples of AI use at work (Lee et al. 2025a). They found that AI shifts effort from gathering information to verifying it, from solving problems to integrating AI responses, and from doing tasks to supervising them (Lee et al. 2025a). The worker becomes the quality inspector at the end of the line. The study also found that workers with higher confidence in the AI reported less critical thinking (Lee et al. 2025a). People who trust the oven stop checking whether it made a calzone.

22.2 Why light supervision is heavy work

The note calls babysitting “really taxing.” This sounds odd at first. Watching should be easier than doing. Research says the opposite.

The irony of automation. In 1983, cognitive psychologist Lisanne Bainbridge published “Ironies of Automation” in Automatica (Bainbridge 1983). She argued that automating most of a job leaves the human with the parts machines cannot do, plus an exhausting monitoring task (Bainbridge 1983). The operator also loses practice at the skills needed to step in when the machine fails. Her paper reports that even a highly motivated person cannot keep effective attention on a source where little happens for more than about half an hour (Bainbridge 1983). Her conclusion: monitoring for rare faults is not a human job, and an alarm system should do it.

An AI agent that writes code or text for twenty minutes puts the human in Bainbridge’s control room. Most of the output is fine. The calzone appears rarely. The human must still watch for it.

Vigilance is hard mental work. For years, researchers assumed that monitoring tasks were boring but easy. Warm, Parasuraman, and Matthews challenged that view in a 2008 review in Human Factors titled “Vigilance requires hard mental work and is stressful” (Warm et al. 2008). Their summary: vigilance tasks look simple, but subjective reports show their workload is high, and behavioral, neural, and subjective measures all show that vigilance is hard mental work and stressful (Warm et al. 2008). A 2019 study by Dillard and colleagues carries the same message in its title: vigilance tasks are “unpleasant, mentally demanding, and stressful even when time flies” (Dillard et al. 2019). I saw this paper only in search results; the publisher blocked access to the full text.

This explains the note’s tension. Babysitting is low in visible output but high in mental cost. It drains the worker without producing anything they can point to at the end of the day.

Complacency under competing tasks. The obvious fix is to do other work while the AI runs. That creates a new risk. Parasuraman and Manzey reviewed the research on automation complacency and bias in 2010 (Parasuraman and Manzey 2010). They found that complacency appears under multiple-task load, when manual tasks compete with the automated task for attention (Parasuraman and Manzey 2010). In plain terms: the more productive work a person does while supervising, the more likely they are to miss the calzone.

22.3 Does babysitting cost time, or only feel like it?

The note says the human wants to do something that “feels more productive.” Feeling and measurement can diverge sharply here.

The perception gap. METR ran a randomized controlled trial with 16 experienced open-source developers on 246 tasks from their own repositories, between February and June 2025 (Becker et al. 2025d; “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” 2025c). Developers mostly used Cursor Pro with Claude 3.5 and 3.7 Sonnet (Becker et al. 2025d). With AI allowed, they took 19% longer to finish tasks (“Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” 2025c). Before the study, they expected a 24% speedup. Afterward, they still believed AI had made them 20% faster (“Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” 2025c).

The gap matters for the note. Supervising an AI felt productive enough that developers misjudged its cost by roughly 40 percentage points. The “babysitting” felt like work getting done.

The newer result. METR now labels the 2025 result as out of date (“Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” 2025c). A February 2026 update reports a second study with 57 developers, more than 800 tasks, and 143 repositories (“We Are Changing Our Developer Productivity Experiment Design” 2026b). Returning developers showed an estimated 18% speedup, with a confidence interval from 38% faster to 9% slower. New developers showed a 4% speedup, with an interval from 15% faster to 9% slower (“We Are Changing Our Developer Productivity Experiment Design” 2026b). Both intervals include zero. METR also reports that 30–50% of developers avoided submitting tasks they did not want to do without AI, which biases the estimate downward (“We Are Changing Our Developer Productivity Experiment Design” 2026b).

One detail in the update speaks directly to the note. METR found time hard to measure for developers using agentic tools, because they “would often work an unrelated task while waiting for the agent” (“We Are Changing Our Developer Productivity Experiment Design” 2026b). Developers already solve the babysitting problem the way the note predicts: they fill the waiting time with work that feels productive.

The price of switching. Filling the gap has a cost. Leroy’s 2009 experiments showed that attention stays partly stuck on a previous task after a switch, and that this “attention residue” lowers performance on the next task (Leroy 2009). Mark, Gudith, and Klocke found in 2008 that interrupted workers finished tasks faster but reported more stress, frustration, time pressure, and effort (Mark et al. 2008). A person who checks an agent every few minutes pays this switching cost each time, in both directions.

Table 8 sums up the three costs.

22.4 Implications for learning versus production

The essay contrasts learning with production. The research above suggests that babysitting sits awkwardly between the two.

In production, the goal is output. Bainbridge’s advice applies: do not ask a human to watch for rare faults (Bainbridge 1983). Give that job to an alarm. In software, the alarm is an automated test, a type checker, or a written acceptance check. A test that defines “pizza” catches the calzone without a human staring at the oven. The human then reviews at checkpoints, not continuously. This is my inference from the cited work, not a tested result.

In learning, supervision has value of its own. Reading and judging AI output forces the learner to know what the right answer looks like. But Lee and colleagues found that high trust in AI reduces critical thinking (Lee et al. 2025a), and Bainbridge warned that operators lose skills they no longer practice (Bainbridge 1983). A learner who only supervises may stop building the skill that makes supervision possible. Over time, they lose the ability to tell a pizza from a calzone.

The note’s frustration, then, has a sound basis. Babysitting an AI is real work. It is hard, it is stressful, and it is easy to misjudge. The fix is not to stop paying attention. It is to move the attention: put repetitive checks into tools, and keep human judgment for the moments that need it.

22.5 Limits of this evidence

• The Stack Overflow and Lee et al. figures are self-reports, not measurements.

• The METR studies cover experienced open-source developers. Results may differ for novices, other fields, and newer tools.

• The Warm et al. summary and the Dillard et al. and Mark et al. findings come from abstracts and search results. I did not read their full texts.

• The vigilance research studied radar-style signal detection, not AI review. Applying it to AI supervision is an analogy.