Agents Are Invention Machines | Cameron Westland
Skip to content
Agents Are Invention Machines
Jul 19, 2026
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"] {<br>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...