Chapter 2 · A Map Stolen from Paradigm Shifts
Chapter companion
The change you are watching has run the same script at least five times, and the audience's notes are still around. This chapter's job is to steal those notes back and bind them into a map that every later chapter cites. The ladder does not get raised until Chapter 3. This chapter is about seeing which wall to lean it against.
This chapter hands you three things. Five lessons AI coding already paid tuition for, an eleven-row transfer map, one row per pattern the precedents walked, set against research, and five transfer failure conditions.
2.1 The panic of 1979
A headline this morning. Some AI system "wrote a paper on its own," or "did a PhD student's week of literature review in ten minutes." You cannot tell whether to be excited or to sneer, and you certainly cannot tell whether it touches the report you owe next month. This chapter hands you a map. Put that kind of news on it and you see which old pattern it is, which rerun of that pattern, and what half-sentence it left out. The map has to be drawn starting from an earlier panic.
In October 1979 a program called VisiCalc went on sale for the Apple II at around a hundred dollars. Its inventor, Dan Bricklin, was still a student at Harvard Business School. By his own account, half the idea came from his frustration. One wrong number in a case assignment voided every number computed after it. The other half came from a scene in class. A professor worked a financial model on the blackboard, and every change meant rewriting a string of cells by hand.
VisiCalc made "recompute it" cost nothing. Bricklin later described a reaction that kept recurring. Programmers watched the demo and said "nice, so what." People who had actually built the reports trembled, because what took seconds on screen was a full week of their work, and when they were done trembling they pulled out a card on the spot to buy it. The panic followed. Recomputing tables was the daily core of the accounting craft. The core got automated, so what is left of the profession?
Forty-some years later the accounts can be settled. On the US Bureau of Labor Statistics job classification, bookkeeping and accounting clerk jobs are down by about four hundred thousand since 1980, while accountant and auditor jobs are up by about six hundred thousand over the same period (Planet Money, citing US Bureau of Labor Statistics (BLS) data). What got wiped out was the mechanical step of "recompute it." What did not get wiped out was judgment. How this sheet should be built, whether the numbers are right, what they mean. Demand for judgment grew, because modeling got cheap and everyone started modeling.
The story has another half that the inspirational version usually skips. In the same era that democratized modeling, a whole class of unprecedented errors was born in bulk. A formula pointing one cell off, a copy that skips a row, a sum where an average belonged. They hide behind a polished interface without a sound. In 2010 Reinhart and Rogoff published "Growth in a Time of Debt," and policymakers in the US, the UK, and the EU cited it to justify austerity. In 2013 the graduate student Herndon, working with Ash and Pollin, reproduced it and found that the range of the Excel sum formula left out the rows holding five countries. After the correction the negative growth turned positive, and the average growth rate of high-debt countries went from -0.1% to +2.2%.
That is the full shape of a paradigm shift, the kind of change where the old tools and the old standards get replaced wholesale. The old bottleneck disappears, judgment appreciates, a new class of error is born, the panic misses, and it misses in a way nobody expected. You will see this shape five more times. One of them just happened to coding. The other four are earlier precedents, and counted together with the spreadsheet they come to five below. This chapter distills those patterns into a transfer map the whole book keeps citing.
2.2 The main precedent, the tuition AI coding paid first
The precedent closest to research, and the most isomorphic in mechanism, is AI coding. It started two or three years earlier, it ran messy enough, and its tuition bill is itemized enough. You have probably walked this curve yourself. Completion (the 2021 Copilot preview, AI finishing half a line behind your cursor), conversation (pasting whole blocks of code into a chat box after ChatGPT at the end of 2022), agent (from 2024 on, AI editing files, running tests, and opening PRs while you fall back to acceptance). Every new stage renegotiates the division of labor between you and the AI. So the five lessons below do not retell the coding story. Each keeps one sentence you already know and spends its length on the research counterpart, and on where that counterpart takes a discount.
Lesson one, the cost of production collapsed, the cost of review did not, and the bottleneck moved to review. Your team is probably stuck in the review queue already. This is a permanent change in the cost structure. When production is nearly free, your throughput ceiling equals your review bandwidth. The research counterpart is already around you. First drafts, literature summaries, and analysis scripts all got cheap. "Can this conclusion be trusted" got no cheaper at all. Part III of this book is built entirely on this lesson. The discount is in section 2.6, failure condition one. Research review has no compiler underneath it, which makes it more expensive than code review.
Lesson two, the demo dazzles, the merge is a disaster. In 2024 a demo video of a "fully autonomous AI software engineer" caused a sensation. A month later the engineer Carl Brown (YouTube channel Internet of Bugs, April 2024) went through that demo frame by frame, found several exaggerations, and showed that the Upwork task in it was never finished to the client's requirements. The programmer community ended up counting only production-grade numbers, merge rate, rework rate, incident rate. The research counterpart is the same. How a deep research report performs in a demo and how it performs once it enters a decision chain are two different things. You can judge it only on the second, whether the citations hold up under checking, whether the numbers can be traced. On the research side this one bites harder. Section 2.6, failure condition four, says a research question worth doing is by definition not in the corpus, and demos are almost always recorded on problems that are already solved.
Lesson three, self-perception is not trustworthy, calibration has to come from measurement. You may never have measured this one yourself, so the numbers stay in full. In 2025 METR, a research group that evaluates AI capability, ran a randomized controlled trial. It had 16 open-source developers with an average of five years on their projects complete 246 tasks on real projects they knew well, with each task randomly allowed or not allowed to use AI. Before starting, they predicted AI would make them 24% faster. After finishing, they still rated themselves 20% faster. The measurement came out about 19% slower on average (the confidence interval is wide, +2% to +39%, so the real slowdown probably falls in that range and is not nailed down). Prediction beforehand, feeling afterward, measurement itself, three levels of contrast with the first two wrong in the same direction. Fluent interaction systematically manufactures the illusion of speed and of mastery, and veterans fall for it too. For research this is a doubled warning, because objective acceptance is harder for research output than for code. Between "I feel like AI helped me master this field" and actually mastering it sits a whole process (Chapter 4 expands).
Lesson four, trust calibration moves from two poles to graded delegation. The trust-it-all camp paid in incidents, the trust-nothing camp paid in speed, and what survived was delegation graded by the risk and the verifiability of the task. Let boilerplate go, watch the core logic, keep it away from architecture decisions. The version you can act on is a question. For this step, for this task, what level do I delegate to? The autonomy ladder that Chapter 3 raises is this lesson institutionalized for research. The discount is in what the grading rests on. In coding the grading rests on verifiability, and in research most steps have low verifiability to begin with, so the whole ladder sits a notch lower.
Lesson five, verification infrastructure sets the radius of letting go. A team with solid test coverage dares to let an agent change core modules on its own. A team with no tests has to watch even an edit to a comment, and no amount of model intelligence moves that ceiling. Transferred to research, this points to an uncomfortable inference. If you want AI to climb high on autonomy inside your research, you first have to write "what counts as right and what counts as wrong" into executable criteria, rules you can follow to rule on right and wrong, and that is one of the hardest parts of research itself. Part II runs into it again and again.
2.3 Five earlier rehearsals
AI coding is only the most recent precedent. Turn back further and there are at least five full performances of "a tool rewriting a craft." One main lesson flashed per case, with the weight spread unevenly on purpose.
Spreadsheets (1979), the same door that democratized capability also let in a whole class of new errors. Both sides were covered in section 2.1, so here is one addition, a sense of the scale. A coarse audit method applied to 367 spreadsheets in corporate use found 24% contained errors. A stricter audit method put the share containing errors above 86% (Panko, 2000). The gap between the two numbers comes from how tight the audit was, not from a trend over time. Errors did not stop spreadsheets from taking over the world, and "the spreadsheet is right" never became the default. "The AI output is right" works the same way.
Statistical software in the 1970s-80s turned a significance test from hours of hand computation into one click. The bar to operate dropped, and the bar to abuse dropped with it. Serious people tested their hypotheses faster, and opportunists found their way to p<0.05 faster too. In 2011 a famous paper demonstrated the power of those degrees of freedom on the spot, degrees of freedom meaning the room to switch analysis methods however you like. Using only flexibility that stayed inside the rules, it "proved" that listening to the Beatles' "When I'm Sixty-Four" made people almost a year and a half younger, p=.040, statistically significant (Simmons et al.). A few years later a large replication effort took 100 studies from three leading psychology journals and reproduced statistical significance in only 36%, against 97% in the original papers (Open Science Collaboration, 2015). What got industrialized was "looking rigorous," not fraud. Chapter 11 takes this warning head on. AI pushes the unit price of "looking rigorous" lower still.
From 1998 on, search engines devalued "remembering a fact" and raised the value of "knowing what to look up and judging whether what you found can be trusted." "Found" is not "understood." That boundary applies unchanged to the new version. Swap "found" for "AI can answer it," and swap "understood" for "you have mastered it."
Open-source collaboration (from the 1990s), output from strangers gets trusted through mechanism, not through goodwill. Code written by tens of thousands of people who never met each other runs inside your bank's systems, and it holds up because of a whole trust machine. Review, continuous integration, version control, a maintainer hierarchy, a traceable origin for every changed line. The famous line "given enough eyeballs, all bugs are shallow" holds only while the mechanism is running. When Heartbleed broke in 2014, everyone saw that the crypto library the whole internet depended on had a core team of about four volunteers for years, only one of them full time. The 2024 xz backdoor was nastier. It went around the code and attacked the chain of trust itself, with the attacker spending more than two years cultivating a trusted maintainer identity. Trust can be engineered, and the trust mechanism itself becomes an attack surface. Chapter 12 builds the answer to "how does AI research output get trusted" out of the same thinking.
After AutoCAD arrived in 1982, the drafter's occupation shrank and the designer's did not. The US Bureau of Labor Statistics Occupational Outlook Handbook lists CAD as the main cause of the decline in drafter jobs, while design jobs grew over the same period. What disappeared was the transcription work of copying design intent onto the drawing. The people who decide what to draw got a faster iteration loop instead. This is the most informative historical answer to "will researchers be replaced." Do not argue yet, split the account first. In your daily work, which parts are transcription and which are decisions. Chapter 14 expands.
2.4 Three books worth stealing from
Some of the people who lived through a paradigm shift wrote the lessons into books. Three are worth stealing from most, one thing from each.
The most famous law in The Mythical Man-Month (Brooks, 1975) says that adding people to a late project only makes it later, because communication cost grows on the order of the square of the head count. Agents still have to agree on a basis, merge conflicts, and check each other, and coordination cost does not vanish because they draw no salary. "Does adding agents actually add speed" has to be marked "still exploring" on the transfer map, and the small-model army, the team of small open-source models in the spine case, tests exactly one special case of it head on. "No Silver Bullet" adds another cut. Tools only kill "accidental complexity," the part the tools and the process bring, and cannot touch "essential complexity," the part the problem itself brings. The essential complexity of research is roughly "deciding which question is worth asking and what counts as evidence," and whether AI can touch it is the undercurrent running through the whole book.
The Structure of Scientific Revolutions (Kuhn, 1962) gives no operating advice. It gives you a pair of glasses. The chaos of a paradigm shift, two generations who cannot read each other, old and new standards fighting, all of that is normal, not a malfunction. Put the glasses on and look at the mess of "AI research" in 2026, demos everywhere, standards missing, opinion at two poles, and what you read is the ordinary turbulence of a shift. It also warns you that a regularity seen during turbulence cannot be taken as how things will stay.
The Pragmatic Programmer (Hunt & Thomas, 1999) has two engineering instincts worth stealing. One is the tracer bullet, get a minimal end-to-end path working first and thicken it step by step, which is the road the rough two-hour demo in Start Here took. The other is orthogonality, parts that do not tangle with each other, so an error in one place does not infect another. Transferred to AI research, that means setting "generation" and "verification" as two independent stages, and never letting the same AI both produce the conclusion and judge it. Part II uses this over and over.
2.5 The transfer map
Now distill the precedents into a table. The status column uses the book's three labels, and what it labels is the research side. Verified means enough evidence is already observable in research settings. Still exploring means it makes sense mechanically and the research-side evidence is undecided. Falsified means the research side already has counterevidence. No row currently dares to be marked falsified, and that by itself says the field is young. Read the first three rows first, they fit the work in your hands most closely, and come back to the rest when a concrete situation calls for them.
| # | Pattern | How it happened in the precedent | The counterpart in research | Status |
|---|---|---|---|---|
| 1 | Production cost collapses, review cost does not, the bottleneck moves to review | AI writes code an order of magnitude cheaper, team throughput jams in the review queue | First drafts, summaries, analysis scripts nearly free; "can it be trusted" got no cheaper, verification becomes the throughput ceiling | Verified |
| 2 | The demo dazzles, production is a disaster | An autonomous coding agent demo causes a sensation, production-grade numbers (merge rate, rework rate) expose it | A deep research report dazzles in the demo, then gets exposed on citation checking and number tracing once it enters a decision chain | Verified |
| 3 | Self-perception is not trustworthy, calibration comes from measurement | Developers rated themselves about 20% faster and measured about 19% slower (METR 2025 controlled trial) | Fluent question and answer manufactures a sense of having "already mastered it"; that sense of mastery decouples from mastery itself and needs an outside check | Still exploring (verified on the coding side) |
| 4 | Trust moves from two poles to graded delegation | Both the trust-it-all and the trust-nothing camps lost money, delegation graded by risk and verifiability won | The autonomy ladder, delegation level set on "step × task" (Chapter 3) | Still exploring |
| 5 | Verification infrastructure sets the radius of letting go | Only teams with good test coverage dare let an agent into core modules | Criteria locked in first, evals built first, only then is letting go on the table (Part II, III) | Still exploring |
| 6 | Lowering the bar to operate = lowering the bar to abuse | Statistical software turned significance into one click, p-hacking (switching methods until it comes out significant) got industrialized | AI turns "looking rigorous" into one generation; The Lancet audited 2.5 million biomedical papers in May 2026. The share of papers carrying fabricated citations rose about 12 times in three years, to about 1 in 277 (see the table note) | Verified |
| 7 | New capability manufactures new error types in bulk | Spreadsheet formula errors, invisible, in bulk, hidden behind a polished interface | Hallucination, fabricated citations, spurious significance, equally invisible, in bulk, fluent (Chapter 11) | Verified |
| 8 | "Findable" reshapes "known," judgment does not die | Search engines devalued memory and raised the value of "what to look up and what to trust" | "You can ask it" is not "you have mastered it"; AI being able to answer is not you having judgment | Verified |
| 9 | Output from strangers gets trusted through mechanism, not goodwill | Review, CI, and traceable origin let strangers' code into production; when the mechanism fails you get Heartbleed | A traceable, checkable workflow for AI output (Chapter 12); the mechanism has not settled yet | Still exploring |
| 10 | Adding people does not add speed, communication cost grows as the square | Brooks's law, adding people to a late project makes it later | Adding agents does not necessarily add speed; the literature has started to run the numbers, but nobody has done a full decision-grade comparison with real cost accounting, and the small-model army tests one special case of it head on | Still exploring |
| 11 | What gets eaten is the mechanical part of the craft | Drafters disappeared, designers did not, and iteration got faster instead | Transcription work (formatting, boilerplate literature reviews, copying out) gets eaten; "what to ask and what to trust" appreciates (Chapter 14) | Still exploring |
Table note, row 6 cites Topaz et al., "Fabricated citations: an audit across 2·5 million biomedical papers," The Lancet, 2026, DOI: 10.1016/S0140-6736(26)00603-3.
Three notes on use. First, later chapters cite this table in a fixed format, "row N of the transfer map," so turn back here when you see it. Second, the status column will expire. This table belongs to the book's living book mechanism, and the online edition keeps updating. You should maintain one for your own field too, and the fillable blank template and the guiding question list are in this chapter's templates. Third and most important, this table is a set of hypotheses backed by historical collateral. The historical evidence is a guarantee, not a payout. What that collateral is worth depends on the next section.
Here is one demonstration of how to use it. The example is academic, and for a headline about benchmark scores the checking runs the same way. Suppose tomorrow morning you see a headline. Some tool claims to finish a literature review fully automatically, a PhD student's week of work in ten minutes. Run it against the map. Was the scenario it demonstrated cherry-picked? Row 2, treat it as a demo and wait for production-grade numbers. Whose time do those ten minutes save? The production cost of a review draft collapsed, and whether each citation is real and whether each claim drifted in the restating is still your review. Row 1, the bottleneck did not disappear, it just moved onto your desk. Whose bar did it lower along the way? The serious people and the people padding their output each saved a week, row 6. Three rows in, the headline goes from "unprecedented" to "three old patterns bound into one rerun," and you know where to look.
2.6 Transfer failure conditions
The most dangerous moment for a map is when you forget it is a map. An analogy is a loan, and the interest is that you must inspect the collateral, meaning check whether the mechanisms in the two settings really are the same. Between research and coding there are at least five places where the mechanisms are not isomorphic. Each one discounts several rows of the table above.
Failure condition one, research has no compiler. Code has a string of cheap ground truth sources, ground truth meaning a reliable basis that tells you right from wrong. The compiler tells you in seconds that the syntax is wrong, the tests tell you in minutes that the behavior is wrong. The whole trust mechanism of AI coding, the graded delegation of lesson four and the radius of letting go of lesson five, is all built on the foundation of "verification is cheap." Research takes its ground truth from reality itself. One experiment takes weeks, one round of peer review, meaning having researchers in the same field review the paper, takes months, an independent reproduction runs to years, and for a large share of claims the ground truth never arrives in principle. Every lesson that depends on a cheap verification loop takes a discount in transfer. At the same model capability, the radius of letting go in research is structurally smaller than in coding.
This inference has a falsifiable shape, meaning it can say what observation would overturn it. AI autonomy should climb first on the research steps where cheap ground truth exists, such as rerunnable analysis code and tasks with public data to compare against, and lag on steps like interpretation and judgment where there is no cheap ground truth. If the opposite order is ever observed, this judgment is void and the map gets redrawn. A prediction once made has to be reconciled. In 2026-08 it was rechecked. Every publicly visible climb in autonomy happened on closed tasks where ground truth is cheap, benchmark scores, training time, test pass rates, and no counterexample was observed. The reconciliation record updates with the online edition.
Failure condition two, the feedback loop is one to four orders of magnitude slower. A programmer runs the "write, run, fail, fix" loop dozens of times a day, the AI coding community paid its tuition and worked out its norms within three years, and a high-frequency loop with millions of people in it is an enormous learning machine. The research loop is measured in weeks and years, so that machine turns far more slowly. Two inferences follow. One, bad habits survive longer before they get punished, and hype keeps a longer shelf life. Two, "best practice for AI research" will converge visibly more slowly than in coding. The mess of 2026 (hold up Kuhn's glasses) will last a good while yet.
Failure condition three, the error contaminates knowledge itself, and it is almost impossible to recall. Bad code usually has a bounded blast radius. Roll back, patch, at worst tear it down and rewrite, and the loss is counted in dollars. A bad conclusion has no rollback button. It enters the literature, gets cited, gets written into reviews, gets fed into the training data of the next generation of models, and gets used to support policy. One fraudulent medical paper published in 1998 took twelve years to be retracted. Twenty years after publication its citation count was still rising rather than falling, and among the papers citing it between 2011 and 2018, 28% still did not mention that it had been retracted (JAMA Network Open, 2019).
With AI in the loop, compounding is added. An AI-generated error gets published, then gets retrieved and learned by the next generation of AI. Virtues from coding culture like "fail fast, ship boldly" have to be cut off at the publication step when they transfer to research. Keep the trial and error inside your private loop. What enters the public knowledge base is held to another standard. That is also why this book puts the red team (Chapter 10), the step whose whole job is to get people to pick holes in it, after delivery and before submission.
Failure condition four, there is no corpus at the frontier. AI writes code well partly because it has seen a huge volume of similar code. Your CRUD endpoint has ten thousand relatives in the training data. If a research question is worth doing, that almost by definition means the answer is not in the corpus. The inference is that capability is spread unevenly. AI performs best on the already-solved parts of research, standard methods, boilerplate procedures, and field common sense included, and it is weakest exactly at the novel core where the value is. That gives a rule of suspicion. Any "AI did research" demo recorded on an already-solved problem gets treated as row 2 of the transfer map first, not as a counterexample to row 2.
Failure condition five, the precedents are themselves survivors. You have heard the VisiCalc and CAD stories because those shifts ended well. Nobody writes biographies of the tools that drove an industry into a ditch. This map has survivorship bias built in, and the antidote is to pin the unit of transfer to mechanism. How the cost structure changed, where the bottleneck moved, what the new errors look like, all of that is on the record. History rhymes on mechanism, not on endings.
In practice, run three questions before you rule with the map. How far do the premises this pattern depends on (cheap ground truth, fast feedback, recallable errors) hold in my setting? Am I transferring the mechanism, or transferring the ending? How would this judgment be falsified? The full self-check version of the three questions is in this chapter's templates too.
Want an agent to run it with you? Paste this to your AI assistant or coding agent:
Help me run a transfer analysis for my own field. Walk me through the five steps of Template 2 in docs/appendices/ch02-templates.md,
one question at a time, waiting for my answer before you ask the next. In step 1 I pick the precedent. In step 2 you may list candidate mechanisms for me, but mark each one "your guess"
or "mine." In step 4, the failure condition audit, I score how far each of the five holds, and you do not score. In step 5 I write the falsifiable judgment,
and you only check whether it states "what observation would overturn it." Once the whole map is filled in, ask me the three quick-card questions again.
If any command errors, stop and show me the output.
2.7 The unfair advantage you now hold
The next time a blockbuster "AI does research" headline lands in your feed, do not do what the accountants at the 1979 trade show did and pick between panic and awe. Turn to the transfer map, find which row's pattern it is and which rerun of that pattern, judge whether the status column should change, then run the three failure condition questions and see which one it did not tell you. Settle the accounts before you decide whether to forward it.