On July 16th I recorded a ten-second screen capture of a scroll bug that had escaped to production. Our chat transcript renders interactive cards: a portfolio card you can drill into, tap a ticker, get the detail view. Tapping a ticker made the whole transcript lurch. I handed the video to Codex running GPT-5.6 Sol at extra-high reasoning, a model that had been the state of the art for exactly one week.

It worked for fourteen minutes and the diagnosis was genuinely good: browser scroll anchoring during the table-to-detail DOM replacement, with the exact jump measured and the card-height animation we’d been suspecting ruled out. Then it recommended the fix: capture the nearest scrollable ancestor’s position before every view switch, restore it before the browser paints, and do it generically so it works across every surface.

A hand-built scroll watcher, living in our codebase forever. It looked weird to me: too much machinery for a problem this old. So I pushed back, verbatim:

I really don’t understand your recommendation. It sounds like you’re basically inventing something when either this should be built directly into the browser or someone else has fixed this problem before. Do more research and advise me.

Eleven minutes later: “You’re right. I’m revising my recommendation: we should not build custom scroll-position bookkeeping first.” Scroll anchoring is the browser independently adjusting a scroll container when visible DOM gets replaced, and the CSS Scroll Anchoring spec defines an escape hatch for exactly this situation. The entire fix:

.portfolio-table[data-ticker-drilldown-enabled="true"] {
  overflow-anchor: none;
}

One scoped, browser-native CSS rule, tested in Chromium to prove the placement mattered. It even checked how mature libraries draw this boundary: React Aria hand-rolls scroll bookkeeping only as a fallback for browsers without native support. The thing it originally proposed building is the thing the ecosystem keeps as a legacy fallback.

The first answer already knew scroll anchoring existed. It warned me not to disable it globally, by name, in a bullet point, and still recommended building the machinery by hand. The knowledge was in the weights; what was missing was the question every good engineer I’ve worked with asks by reflex: what are the priors? Who has hit this before? What did they do?

Coding agents are invention machines. Point one at a problem and its default move is to generate something new, because generation is the one thing a model can always do. And invention is the riskiest move in problem-solving: a bet with no track record, placed at the moment you know the least. The odds that your first idea beats the accumulated attempts of everyone who hit this problem before you are close to zero. If I’m going to take a bet, I want to load up on priors and calibrate it as much as I can.

You could object that the model isn’t inventing anything: it’s remixing patterns frozen into its weights, the opposite of invention. Technically, sure. From the perspective of your problem, the distinction doesn’t matter. A solution with no provenance, no competing alternatives, and no argument for why it fits your context is an invention, wherever the tokens came from. The scroll-watcher recommendation was a hand-rolled re-implementation of a browser feature that shipped years ago. A solution is grounded when you can trace why it should work here.

The same failure at architecture altitude

The day before, I’d made the same mistake myself. I’m moving our automation system from schedule-based to event-based, and we don’t have a centralized event bus: no Schelling point where domain lifecycle events get published and automations can listen. I sketched the architecture with Sol at ultra reasoning, on my phone, across a couple of repos. It proposed Google Pub/Sub. We do run Pub/Sub in one on-prem optimization flow. We have a much deeper prior: Celery, in the Django service that owns most of our domain objects, where we’d already decided this service should live. The agent picked the shallower prior and never compared the two. Neither did I, because grilling an agent from a phone is exactly as rigorous as it sounds.

I do have one habit that survives my own laziness: before building infrastructure, post the sketch and ask the team whether we already have this and whether someone else wants to own it. Five minutes after I posted, Kevin asked the obvious question: is there something missing in Celery that means we need Pub/Sub? He was fine with Pub/Sub on its merits; he wanted the reasoning I didn’t have.

So I went back and did the research I’d skipped. Split the must-haves from the nice-to-haves. Celery covers the near-term needs on infrastructure we already operate. The conditions where Pub/Sub genuinely wins are real but not current, so I called YAGNI and moved them to the later horizon. The design got simpler and better. Kevin never proposed an answer; his question forced the comparison the agent and I had both skipped.

Same failure, two altitudes: a bug fix and an architecture decision. In both cases the priors existed, were findable in minutes, and were only consulted because a human happened to ask.

Why agents default to invention

I used to read this as a personality quirk of the tools. I don’t anymore. I’m sure smarter people than me have asked this question properly; what follows is a working model from the outside.

Training data is finished work: the accepted answer, the merged diff, the published post. What happened before the answer never got written down: the open browser tabs, the maintainer pointing at an old fix, the approaches that got abandoned. All of that lived in heads and meeting rooms, so none of it made it into training. The model learned problem → solution. Nobody showed it problem → “hasn’t someone solved this?” → solution.

The headline coding benchmarks run in sealed Docker containers with no network. The agent can read the repo it’s dropped into and nothing else: no checking how upstream fixed the same bug, no maintainer threads, no looking for a library that already solved it (all things real coders do in practice). High scores come from solving with what’s in the box. I wrote in March that autoresearch is reward function design. Benchmarks are reward functions too, and these pay for invention.

And these inventions arrive with extreme confidence (scroll back to that first screenshot), which plays havoc on human cognition. High confidence is supposed to signal “I did my research and this plan is worth investing in.” From an agent it can mean “I am extremely intelligent, I can fix this, and I did exactly zero external research.” That’s the signal I expect from enthusiastic, brilliant, naive interns.

The model can’t tell when it’s guessing. Ask an agent to scope a project and it says six weeks; then it delivers the scope in an hour. Hand it a 2,000-word document and it comes back 4,000 words, no restraint, no external consideration. It answers underspecified questions instead of asking what you meant. The estimation thing was a known unknown for me until I had Claude go check: someone measured it this year, and estimates overshoot by 5–10× in agentic settings, because models know about time from reading human project plans and have never experienced their own speed. Checking priors is what you do when you can feel yourself guessing. A system that can’t feel it never goes looking.

Every discipline institutionalized the check

No human practitioner is naturally good at this either, until an institution beats it into them. Architecture students are drilled on precedent studies before they design a building. Law runs on stare decisis: priors are the operating system. Medicine ranks its evidence in an explicit hierarchy. Every research paper is forced through a related-work section. And you already know what this looks like in software, because Kevin did the job brilliantly.

None of these disciplines trusts individuals to check priors by reflex, because the pull runs the other way: inventing feels good. Building your own thing beats reading about someone else’s, reliably enough that the failure mode earned its own name, not-invented-here syndrome. Sometimes the check gets skipped under pressure, the way I skipped it on my phone. Sometimes it gets skipped because inventing is the fun part. The institutions catch both. Mine caught me in five minutes.

My agent conversations have no Kevin in them. The models got the practitioners’ knowledge with none of the practitioners’ institutions. So the institutions have to be rebuilt where agents work: harnesses, CI gates, review loops, skills.

I encoded the question as a skill

Two hours after the scroll fix, I built ground-in-priors, a skill that forces the protocol I keep supplying by hand. It’s public: npx skills add camwest/skills --skill ground-in-priors.

The first thing I did was make the agent research whether someone had already built it. It would have been embarrassing not to. It found real prior art, a skill called search-first with 5.5K installs. It also pulled one finding that shaped the whole design: feeding a model code that merely looks similar makes its results worse, up to 15% worse. My scroll bug shows why. Search the symptom, “stop the page from scrolling,” and you get a pile of fixes that look right and belong to completely different causes. A skill that stops at “found something similar” serves the agent exactly that pile. So mine demands more. It has to figure out what’s actually breaking before it searches, collect more than one candidate fix, and say why the winner fits your codebase. That’s how I could build a new skill with search-first sitting right there: I read the prior art, and I can point at exactly what it’s missing.

When the evidence isn’t there, it stops instead of guessing: problem-not-understood and insufficient-evidence are acceptable answers. We expect these answers from real professionals. The doctor orders one more test; the engineer won’t ship a fix they can’t reproduce. Refusing to guess is a feature. Agents just don’t ship with it yet. The skill works down a ladder, and it has to explicitly reject each rung before it’s allowed to reach for the next:

And there’s no quick mode. Give an agent a cheap path and it will talk itself into taking it; the whole point is to be expensive right when the agent most wants to be fast.

The first test was the scroll bug again, phrased as vaguely as I’d phrase it on a bad day. It refused to propose a patch and came back with problem-not-understood, plus the evidence it would need to tell the possible causes apart. That’s the behavior I wanted: refusing to answer before the evidence exists. In its first three days I reached for it 47 times; I counted, across my Codex session logs. I’m running it on real work and improving it as I go. If you install it, npx skills update pulls the latest version.

The strongest counterargument I know is Spolsky’s “In Defense of Not-Invented-Here Syndrome”. My working name for this skill was anti-NIH, so his essay argues against it by name. The case: if it’s a core business function, do it yourself, no matter what. His proof is the 1990s Excel team, whose motto was “find the dependencies and eliminate them.” They went as far as writing their own C compiler, and they shipped on time, with quality, depending on nobody.

Except look closer at that example. The Excel team obviously knew the other compilers existed, including the ones Microsoft sold. They ran the process, weighed the tradeoffs against their values, and chose invention with eyes open. That’s everything this post is asking for: the ladder from earlier, walked to the bottom rung. Invention has to be a compensated risk. The Excel team knew what they were paying and what they were buying for it. The agent’s scroll watcher was uncompensated risk, taken without knowing the browser had already solved the problem. All that survives of the counterargument is the “no matter what,” and even the Excel team didn’t do that: they looked first.

The same math runs in the other direction: stuffing your package.json with a thousand dependencies is uncompensated risk too, just the supply-chain flavor. I know that one personally. When left-pad got unpublished in 2016 and builds started failing across the ecosystem, I was the one who stepped in and republished it ten minutes later. Eleven lines of code, wired into everything. The point of the ladder is that you know the price of every rung before you pay it. You refuse to adopt priors all the time. You never refuse to look.

What I can’t offer is a guarantee. Weighing priors is still judgment, which means bias still gets in, just less. And the trigger in the scroll story was nothing more principled than taste: the recommendation looked weird to me, and a couple of decades of looking at weird things is not something I can hand to an agent in a markdown file. The skill can force the evidence to exist. It can’t force anyone, human or model, to weigh it well.

Process note: drafted from my dictated notes and two agent transcripts from this week. Claude helped with research verification, structure, and line edits; the stories, claims, and screenshots are mine. All links verified before publishing; mistakes are mine.