Your AI Wrote the Docs. Your Agent Believed Them.

For founders, solo and small-team operators, and dev-tool builders who ship AI features or AI coding agents — and who own the codebase those agents read. Especially for anyone about to point an AI at a repo and call documentation done.

---

The first screen: the fix that ships the problem

You had no docs. That was the problem everyone agreed on, so you did the obvious thing: you pointed an AI generator at the repo, and in twenty minutes you had an API reference, a set of usage examples, and an architecture diagram. The repo went from silent to fluent. It looked like the documentation problem, solved.

Then a coding agent reads those docs to change a function. The prose is confident. The examples compile. The agent edits the code against a claim that was true when the docs were generated and is not true now, and it does not check, because the doc told it the answer. The pull request looks reasonable and is wrong. (The pre-registered surface-bench study is the clean statement of the mechanism: when the drifted dependency is hidden — the realistic large-codebase case — "a stale doc made every tested model wrong on 100% of tasks" and confidently misled on 100% of them, and "capability does not rescue this: the strongest models are among the worst affected.")

Here is the claim this piece makes, and it is an argument drawn from the evidence below, not a sourced fact in itself: documentation was never an authoring problem. It is a truth-maintenance problem. The generator solved authoring — the half that was never hard — and industrialized the rot in the half that was. In the agent era a stale doc is not an annoyance you file for later. It is a correctness bug, because an authoritative document is exactly the signal that makes an agent stop verifying and act on a fact that is no longer true.

By the end of this piece you will have two things you can use this week:

• The docs-as-claims contract** — five clauses that turn documentation from prose you accept into claims you can check.
• The drift gate** — the one CI check that fails the build when a claim stops matching the code, the way a broken test does.

Here is where we are going:

• The mistake, named precisely** — when docs are missing, operators reach for a generator and accept the output as truth.
• Why the generator makes the invisible half worse** — drift is a property of the corpus, and generation industrializes it.
• Why the agent doesn't save you** — an authoritative doc suppresses verification, and a better model does not help.
• Why the obvious fixes don't hold** — "regenerate it" moves the drift; "review each page" cannot see a contradiction that lives between two pages.
• The smaller fix that actually holds** — the docs-as-claims contract and the drift gate.
• A worked example** — the same stale claim, before and after, in a build you can reproduce.
• Where you will get stuck** — the three objections, answered.
• What to do first** — one afternoon, one check, before your next docs PR.

---

1. The mistake, named precisely

It is not "people write bad docs." It is this: when documentation is missing, an operator's first move is now to generate it — and then to accept the generated prose as true because it is fluent, complete-looking, and cheap to produce.

The twin briefs that surfaced this piece are the evidence that the move is now the default. Two near-duplicate ideas have cycled through the archive in the same month — ai-powered-project-documentation-generator (read a repo, emit API references, usage examples, architecture diagrams) and automated-code-documentation-generator (same, plus IDE and version-control integration). (AI-Powered Project Documentation Generator, archived; the second is a sibling brief.) The archive keeps producing "AI writes your docs" because the demand looks obvious and large. That recurrence is the signal: a whole market is being built on the premise that generation is the deliverable.

Two honest notes before we go further, because the briefs are the topic and not the evidence. First, the briefs' own cited anchors — public-apis/public-apis — say nothing about documentation; they are generic placeholders, so the argument has to stand on independent sources, which is where it stands. Second, the generator is not the villain of this piece. DORA's 2024 report found that a 25% increase in AI adoption was associated with a 7.5% increase in documentation quality — real, measured, and inconvenient for anyone who wants to say "AI makes docs worse." Hold that number; it is the tension this whole piece has to reconcile, and we will reconcile it rather than hide it.

The reconciliation is the point. DORA measures the quality a human reports at a point in time. Drift is cumulative and invisible at any point in time. A document can be high-quality on the day it is generated and wrong six months later — and here is the line to remember: "The AI was accurate at the time of generation. The drift happened in the gap between runs." The generator genuinely improves the artifact. It does nothing for the interval.

2. Drift is a property of the corpus, not of the document

This is the part most writeups skip, and it is the reason the mistake survives review.

The Meta paper states the asymmetry directly: "Developer documentation is easy to generate but hard to keep correct. API references become stale as code evolves, tutorials accumulate subtle mistakes, and documentation can drift away from the internal codebase that serves as the source of truth for system behavior." The failure shape is named just as cleanly: "The generated documentation can be locally plausible, yet globally wrong." A claim can be fluent and defensible inside its own file and still be false, because its truth depends on a cross-file dependency chain that ordinary file-read and keyword-search tools never surface. In the paper's case study, adding a retrieval layer surfaced 2 cross-file factual errors and 2 underspecified API comments that the baseline agent missed.

Sit with that for a second, because it is not a documentation nit. The claim was wrong relative to a file the reader was not looking at. Per-document review is structurally blind to it.

And generation makes it worse at the corpus level, in a way that is invisible to the same review. tianpan.co names three independent factors that make the same prompt return different output over time even at temperature 0: continuous model updates, infrastructure non-determinism (GPU floating-point, MoE routing), and prompt drift as teams refine their generation prompts. The result is that your documentation is a corpus that quietly changes as a whole while every page still passes a read-through. The editorial tell is brutal and exact: "users notice before editors do." Two pages can give opposite advice on the same setting — one written against the January model checkpoint, one against the June one — and nobody catches it, because nobody reviews the set.

The HackerNoon teardown gives the generated-doc failure patterns names worth keeping: the repeater, which restates the same information across sections and manufactures contradictions; and the false completeness trap, which documents every obvious parameter while saying nothing about the edge case that trips up every new user — "the shape of complete documentation without the judgment to know where depth is actually needed." That last phrase is the whole problem in one line. Generation produces the shape of completeness. Judgment about where depth matters is the thing it cannot supply and the thing nobody reviews for.

3. Why the agent doesn't save you

The instinct is that AI fixes the AI problem: a coding agent reads the code anyway, so it will catch the stale doc. The evidence says the opposite, and the reason is uncomfortable.

surface-bench isolates it. The single-shot pilot found the obvious result — with the drifted dependency hidden, the doc is the only source of truth, so a stale doc misleads every model. The author concedes that part is partly tautological. The confirmatory multi-turn run is the load-bearing result and it is not tautological: 5 models across 3 providers, 3,250 graded completions, and a stale doc drove the "misled" rate to 68–100% — with verification available, the agent still deferred. Then the mechanism: "a fresh doc suppressed the agent's verification just as much as a stale one, so the operative variable is the doc's authority, not its staleness."

Read that again, because it changes the fix. It is not the staleness of the doc that stops the agent checking. It is the presence of an authoritative doc. A correct doc and a stale doc both tell the agent "you already know this, don't look." The harm of a stale doc is that the thing it stopped the agent checking was false.

This is why a better model is not the answer. In the hidden-dependency condition, "capability does not rescue this: the strongest models are among the worst affected." The failure is not a capability gap. It is a deference the capability makes more confident.

And it matches what practitioners report. Qodo's 2025 State of AI Code Quality survey (609 developers) found 65% say AI misses relevant context during refactoring and ~60% during test generation and review — and that context gaps, not hallucinations, are cited more often as the cause of poor quality. The top developer request was not "fewer hallucinations." It was improved contextual understanding. The complaint was never that the model invents things. It is that the model trusts what it was handed.

4. Why the obvious fixes don't hold

Three fixes look right and each fails for a specific, nameable reason.

"Regenerate the docs more often." This is the regeneration trap. Regenerating a stale doc does not restore truth; it resamples the corpus. Because the same prompt returns different output over time (model updates, infra non-determinism, prompt drift), a regeneration shifts the document's voice and terminology relative to its neighbors and can plant new contradictions — the exact failure tianpan.co describes, where two pages disagree because one was generated against a different checkpoint. You have moved the drift and paid for it. And you still cannot see the result, because the contradiction lives between pages, not in one.

"Review each page." Per-document review cannot see a corpus-level contradiction by construction. Editors read one page at a time; users walk the multi-page workflow. That asymmetry is the bug, and tianpan.co names the consequence out loud: "users notice before editors do." You do not have a review process that is slow. You have a review process whose unit of review is the wrong size.

"Add a 'may be outdated' banner." This is the most tempting and the most disprovable, because it was tested. In the confirmatory run, handing the agent the specific corrected-code drift report recovered nearly all the loss a stale doc had caused. A bare "this may be outdated" warning did not — it does not tell the agent which fact to distrust, so it either ignores the warning or distrusts everything, and neither restores correctness. The fix is not a softer signal. It is surfacing the specific claim that drifted. (surface-bench.)

There is a live context that makes all three failures cost more every quarter. Qodo's 2026 report reframes the problem as a verification bottleneck: reviewing and validating AI-generated code is now the single top delivery constraint for both developers and engineering leaders (26% each), and 89% of organizations reported at least one AI-related production incident. That 89% is about AI-assisted development broadly — do not read it as "docs cause outages," because no such field data exists. But it tells you where the scarce resource is. If verification is the bottleneck, and an authoritative doc is what suppresses verification, then the doc you accepted as an accelerant is spending the one resource you cannot afford.

5. The smaller fix that actually holds: docs as claims

Everything above points at one reframe. Stop treating the doc as prose to accept. Treat it as a set of claims to check. A claim is a sentence with a referent in the code — a default value, a signature, a parameter, a behavior — and a claim can be verified, run, and made to fail a build. Prose cannot.

Here is the reusable object. Five clauses you can write down before your next docs PR, and one gate you run on every commit.

The docs-as-claims contract

Clause 1 — Every consequential claim is anchored to the code it describes.

A consequential claim is one an agent or a human will act on: a default, a signature, a boundary, an error condition, a behavior. Each one points at a specific location in the code — a symbol, a line, an identifier — not at "the codebase." Claims you cannot anchor are marked as narrative, not as fact. This is the clause the Meta paper's retrieval layer implements: surfacing the cross-file dependency chain is what turns a globally-wrong claim into a locally-checkable one.

Clause 2 — Examples run as tests, so a stale example fails the suite.

Every usage example in the docs executes in CI against the current code. An example that no longer runs is not a typo; it is a documented claim that has drifted, and it should fail the build the way a broken unit test does. This is the cheapest clause and the one that catches the most, because examples are where docs and code are forced to agree.

Clause 3 — A CI drift gate fails the build on a stale claim.

This is the centerpiece. Given anchored claims (clause 1) and the code they point at, the gate reports when a claim no longer matches. surface-bench tests exactly this intervention — the companion Surface tool is a deterministic drift gate — and the result is the whole reason to ship it: surfacing the specific corrected fact recovered nearly all the loss, where a vague warning recovered none. The gate turns "a doc quietly went stale" from an invisible corpus property into a red build any teammate can see.

Clause 4 — Each generated doc carries provenance: the model version and the prompt version that produced it.

tianpan.co's finding is explicit here: drift is made fixable, not merely detectable, by provenance. Recording which model checkpoint and which prompt produced each doc tells you which claim to trust when two pages disagree — and it tells you, at review time, which pages were generated in the same run and should be consistent with each other. Provenance is what makes the corpus auditable instead of merely suspect.

Clause 5 — Run the consistency pass at the corpus level, at generation or commit time — not as an ad-hoc audit.

Consistency has to be checked where the contradiction actually lives: across the set, not inside the page. Whether you do it with embeddings, terminology canonicalization, or a diff against the previous run is an implementation choice; the requirement is that it runs on a cadence attached to the change, not as a heroic quarterly read. (Sibling corpus-consistency techniques are one approach among several and are not independently benchmarked in this packet — treat the mechanism as the requirement and the technique as yours to pick.)

The decision rule

A doc you cannot check is a doc you cannot trust. If a claim matters enough for you or an agent to act on it, it needs an anchor, and something needs to fail when the anchor breaks.

The gate is a mechanism, not a vendor. surface-bench's author sells a drift gate (Surface), so read the evidence as evidence for the mechanism, and implement the gate however you like — a script that resolves each anchored claim against its symbol is enough to start. You are free to build it yourself; that is the point of framing it as a mechanism.

6. A worked example

Here is the failure and the fix in the smallest form that is still real. No vendor, no platform — one claim, one drift, one gate.

The claim. Your docs say, in a usage example and in a reference paragraph:

`

max_retries defaults to 3 for production workloads.

`

The drift. In January, a PR changed the default from 3 to 0. <= became < somewhere nearby; a page size moved. The code is now correct. The docs are now wrong in two places — the reference paragraph and the example — and both still read as authoritative.

The mistake, live. Your coding agent picks up a task: "make retry behavior configurable." It reads the doc, believes the default is 3, writes a config path that assumes 3, and ships a PR that is plausible and wrong. It did not check the source, because the doc told it not to. If the drifted dependency were visible, it might catch it; hidden behind a cross-file chain — the realistic case — it will not, per surface-bench's hidden-dependency result. The bug ships with a green build.

The inevitable wrong fix. Someone notices at review: "these docs are stale — regenerate them." The new run pulls a different model checkpoint, produces prose with slightly different terminology, and now contradicts a third page written in the January run. The contradiction count went from two to three. (tianpan.co: regeneration shifts voice and terminology against neighbors.) You have paid a tool and made the corpus worse.

The fix, with the contract in place.

• Clause 1:* the claim max_retries defaults to 3 is anchored to the identifier DEFAULT_MAX_RETRIES where the default is actually defined — not to "the retry module."
• Clause 2:* the usage example that sets max_retries=3 and asserts a retry count now runs as a test. It still asserts the old behavior. The suite goes red on the January PR itself — before the docs are ever regenerated.
• Clause 3:* the drift gate resolves each anchored claim against its symbol. The reference paragraph's claim no longer matches DEFAULT_MAX_RETRIES, so the gate fails the build on the January PR. The drift is caught at the moment it is introduced, on the person who introduced it, with the specific claim named — which is exactly the "corrected-code drift report" that surface-bench found recovered nearly all the loss, and exactly what a "may be outdated" banner did not do.
• Clause 4:* when the corpus later disagrees with itself, the provenance record tells you both pages were generated in the same run against the same checkpoint — so the fix is one regeneration, scoped to one run, not a corpus-wide panic.

Compare the two outcomes. Without the contract, the same drift ships green, is discovered by a user, is "fixed" by regeneration, and grows. With the contract, it dies in the build, cost one red test and one failing claim, and never reaches an agent. That is the entire difference between authoring and truth-maintenance, made concrete.

7. Where you will get stuck

"DORA says AI improved documentation quality. Doesn't that mean generation is fine?"

It means generation improved the artifact at a point in time, which is true and which this piece is not disputing. DORA's own 2024 numbers carry the tension in the same breath: the 7.5% documentation-quality gain came with an estimated 1.5% decrease in delivery throughput and a 7.2% reduction in delivery stability under the same AI adoption. (DORA 2024.) And DORA 2025 found the "trust paradox": ~90% of developers use AI at work, more than 80% report productivity gains, yet only 24% report high trust in AI output while 30% trust it "a little" or "not at all." The tools look better while the system gets less stable and nobody trusts the output. That is not a case for accepting generated docs. It is a case for checking them. DORA 2025's own conclusion is the seam this piece sits in: AI amplifies the quality of the engineering system it operates within, and high-quality, accessible internal documentation is what lets it become genuinely useful — which is a statement about truth-maintenance, not authoring.

"This is just prompt engineering; my model is good enough to get the docs right."

Rightness at generation time is not the problem; drift is. Even at temperature 0, tianpan.co documents three independent causes of the same prompt returning different output over time, and the Meta paper names the failure that no model quality fixes: a claim can be locally plausible yet globally wrong. A better model writes a more confident locally-plausible claim. It does not implement a cross-file check, because checking is not what generation does.

"A drift gate sounds like heavy process for a small team."

It is the opposite — it is the lightest thing that works, and smaller teams have the most to gain, because they have no editor in the loop at all. Qodo's profile of active AI users found 51% work in teams of 10 or fewer developers: the teams leaning hardest on AI are the ones with the least review capacity. The gate is one CI step. It runs where your tests already run. It fails on the same red build. The alternative to it is the process you already have by default — a user finding the contradiction, or worse, your agent shipping it.

One honest boundary on the whole argument. The strongest drift-as-correctness evidence — surface-bench — is a working paper by the author of the companion drift-gate tool, so it is not neutral on whether a drift gate is the answer. Its single-shot pilot's hidden-dependency result is partly tautological, and the author concedes it. The load-bearing result is the confirmatory multi-turn run, where verification is available and the agent still defers to the doc. Read the paper as evidence for the mechanism, not as a neutral product review. And no source in this packet quantifies how often drifted documentation — as opposed to hallucinated code — causes real production failures in the wild. That claim is a controlled-task correctness result, not a field-incidence report. Treat it as strong enough to justify a gate, not strong enough to justify panic.

8. What to do first

Do not rewrite your docs today, and do not stop generating them. Do one thing: anchor the consequential claims and put one gate in front of the build, before your next docs PR.

Today:

• Pick the ten claims an agent would act on** — defaults, signatures, boundaries, error conditions. For each, write down the code location it refers to. If you cannot name the location, the claim is narrative; mark it as such and move on. Ten is enough to prove the pattern.
• Make the examples run.** Wire the doc examples into CI as tests, even if only the ten claims' worth. You will likely go red on the first run — that red is the drift you already have, surfaced for the first time.
• Write the gate.** For each anchored claim, one check that resolves it against its symbol and fails the build on a mismatch. Start with a script, not a platform. The requirement is that a stale claim turns the build red; the tool is yours.
• Record provenance on the next generation run** — model version and prompt version, written into the docs' metadata. You will not need it until two pages disagree; when they do, you will be glad it is there.

That is the whole first move: ten anchors, examples as tests, one gate, one provenance field. It fits in an afternoon, needs no vendor, and converts "we generated our docs" — a claim about authoring, which the AI already handled — into "we can prove our docs still match the code," which is the only documentation claim an agent, or a new engineer, can actually trust.

---

The compressed ending

Remember it as four beats:

• Documentation was never an authoring problem — it is a truth-maintenance problem.** The AI generator solves the visible half (writing docs fast) and industrializes the invisible one (keeping them true). DORA's own numbers show the split: documentation quality up 7.5%, delivery stability down 7.2%, in the same report.

• Drift is a property of the corpus, not the document.** A claim can be fluent and locally plausible in its own file and globally wrong, and no per-page review can see a contradiction that lives between two pages. Generation makes it worse every run — model updates, infrastructure non-determinism, prompt drift — all invisible at temperature 0.

• An authoritative doc suppresses verification — fresh or stale.** That is the mechanism, and it is why a better model does not save you: the strongest models are among the worst affected, and a "may be outdated" banner recovers nothing, while the specific corrected fact recovers nearly all the loss.

• The fix is the smaller one: docs as claims.** Anchor each consequential claim to the code; run examples as tests; fail CI on drift; record model and prompt provenance; audit the corpus, not the page. A doc you cannot check is a doc you cannot trust.

The tool that fixes authoring is the tool that industrializes the rot. Ship the check, not just the generator — and let the build go red before your agent believes a fact that is no longer true.

---

Sources

• DORA / Google Cloud — "Announcing the 2024 DORA report" (10th Accelerate State of DevOps Report, 2024) — 25% more AI adoption associated with +7.5% documentation quality and −7.2% delivery stability (and −1.5% throughput): https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report (supporting: https://dora.dev/research/2024/dora-report/)
• DORA / Google — "How are developers using AI? Inside our 2025 DORA report" — ~90% AI use (up 14 pts YoY), >80% report productivity gains, 24% high trust vs 30% little/no trust (the "trust paradox"), and AI amplifying the quality of the surrounding system: https://blog.google/technology/developers/dora-report-2025 (supporting: https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)
• Meta (Context-as-AI-Service) — "Surfacing Cross-File Dependency Chains for LLM-Generated Developer Documentation" (arXiv 2606.04397) — "Developer documentation is easy to generate but hard to keep correct," "locally plausible, yet globally wrong," and the case study's 2 cross-file factual errors + 2 underspecified API comments: https://arxiv.org/html/2606.04397
• surface-bench — "Does documentation accuracy change LLM-agent performance?" (pre-registered working paper, McDonald, Jun 2026) — hidden-dependency stale-doc failure at 100%, confirmatory multi-turn misled rate 68–100% (5 models, 3 providers, 3,250 graded completions), authority-not-staleness suppression, and corrected-fact recovery vs bare warning: https://github.com/Connorrmcd6/surface-bench/blob/main/PAPER.md (companion drift gate: https://github.com/Connorrmcd6/surface)
• tianpan.co — "AI Content Drift: When Your Documentation Corpus Starts Contradicting Itself" (2026-05-04) — corpus-level drift from model updates, infrastructure non-determinism, and prompt drift even at temperature 0; "The AI was accurate at the time of generation. The drift happened in the gap between runs."; "users notice before editors do.": https://tianpan.co/blog/2026/05/04/ai-content-drift-documentation-corpus-consistency
• HackerNoon — "The Problem With Autogenerated Docs" (2026-06-11) — the repeater and the false completeness trap; "the shape of complete documentation without the judgment to know where depth is actually needed": https://hackernoon.com/the-problem-with-autogenerated-docs
• Qodo — "State of AI Code Quality in 2025" (609 developers) — context gaps over hallucinations as the top quality complaint; 65% miss context in refactoring, ~60% in test generation and review; 76% "red zone"; 51% of active AI users in teams of ≤10: https://www.qodo.ai/reports/state-of-ai-code-quality/ (2026 report: verification as the top delivery constraint, 26% each; 89% of orgs reported ≥1 AI-related production incident: https://www.qodo.ai/blog/state-of-ai-code-quality-report-2026/)
• Source signal: IdeaGenius daily briefs "AI-Powered Project Documentation Generator" (https://ideagenius.app/ideas/ai-powered-project-documentation-generator) and "Automated Code Documentation Generator" — both archived in discovery/consumed-briefs.txt; their own cited anchors (public-apis/public-apis) do not evidence the documentation problem, so they are the topic, not the evidence.

Precision notes: (a) The thesis — "documentation was never an authoring problem, it is a truth-maintenance problem" — is this piece's inference from the sources, not a sourced fact. (b) surface-bench is a working paper by the author of the companion drift-gate tool; its single-shot hidden-dependency result is partly tautological (the author concedes this) — the confirmatory multi-turn result is the load-bearing evidence, and the tool choice is framed as a mechanism, not a proven-best fix. (c) Qodo's "89% of organizations reported an AI-related production incident" is about AI-assisted development broadly, not documentation-caused incidents; it is not used here to claim docs cause outages. (d) No source quantifies how often drifted documentation causes production failures in the field; the drift-causes-wrong-work claim is a controlled-task result, not a field-incidence report. (e) DORA 2024's +7.5% documentation-quality association cuts against a plain "AI makes docs worse" framing and is presented as the tension, not hidden. (f) Corpus-consistency techniques (embeddings, terminology canonicalization) are named as one approach among several and are not independently benchmarked in this packet.

---

X entryway list (from the approved angle)

Distribution entryways named in the angle brief. Hooks are not yet written as posts — this names each post's type, the one claim or mechanism it carries, and whether it links.

• Hook type: surprising proof.* DORA's own numbers: more AI adoption is tied to better documentation quality (+7.5%) and worse delivery stability (−7.2%) in the same report*. The docs looked better exactly as the system got less stable. → Links to article (the number earns the read; the article supplies the point-in-time-vs-cumulative reconciliation and the contract that acts on it. The link is the deepening, not the reason the claim stands).

• Hook type: mechanism.** An authoritative doc — fresh or stale — is what stops a coding agent from checking the code it cannot see. The harm is not the staleness; it is the suppressed verification. → Links to article (the mechanism stands alone; the article carries the confirmatory multi-turn result and why a "may be outdated" banner fails).

• Hook type: build sequence.** The docs-as-claims contract in five clauses: anchor each claim to code; run examples as tests; fail CI on drift; record model+prompt provenance; audit the corpus, not the page. → Links to article (the contract is the actionable bit; the article is the why behind each clause and the worked example).

• Hook type: risk.** The regeneration trap: fixing a stale doc by regenerating it shifts its voice and terminology against its neighbors and can plant new contradictions no per-page review will catch. → Links to article (names the trap and why the intuitive fix backfires; the article generalizes it into the corpus-level rule).

• Hook type: result.** In a controlled benchmark, a corrected-code drift report recovered nearly all the loss a stale doc caused — a bare "may be outdated" warning did not. The fix is surfacing the specific claim, not a softer signal. → Links to article (concrete before/after; the article ties it to the CI gate and the full mechanism).

Hook-type map: 1 = surprising proof; 2 = mechanism; 3 = build sequence; 4 = risk; 5 = result. All five link, and each link is a bonus — every post carries a claim that stands on its own. These are the five entryways the angle brief named; no additional entryway was invented, and no entryway repeats another's hook.

Source-fetch note: all six primary anchors above (DORA 2024, DORA 2025, arXiv 2606.04397, surface-bench PAPER.md, tianpan.co, Qodo) were re-fetched during drafting and resolve to the content the packet describes; the HackerNoon page resolved but returned only its shell (headline/site chrome), so its specific phrasings rest on the packet's extract.