The following article originally appeared on Drew Breunig’s blog and is being republished here with the author’s permission.

In 1998, Eric S. Raymond published the founding text of open source software development, The Cathedral and the Bazaar. In it, he detailed two methods of building software:

• The cathedral model is carefully planned, closed-source, and managed by an exclusive team of developers.
• The bazaar model is open, transparent, and community-driven.

The bazaar model was enabled by the internet, which allowed for distributed coordination and distribution. More people could contribute code and share feedback, yielding better, more secure software. “Given enough eyeballs, all bugs are shallow,” Raymond wrote, coining Linus’s law.

The ideas crystallized in The Cathedral and the Bazaar helped kick off a quarter-century of open source innovation and dominance.

But just as the internet made communication cheap and birthed the bazaar, AI is making code cheap and kicking off a new era filled with idiosyncratic, sprawling, cobbled-together software.

Meet the third model: The Winchester Mystery House.

The Winchester Mystery House

Located less than 10 miles southeast from the Computer History Museum, the Winchester Mystery House is an architectural oddity.

Following the death of her husband and mother-in-law, Sarah Winchester controlled a fortune. Her shares in the Winchester Repeating Arms Company, and the dividends they threw off, made it so Sarah could not only live in comfort but pursue whatever passion she desired. That passion was architecture.

Sarah didn’t build her mansion to house ghosts¹; she built her mansion because she liked architecture. With no license, no formal training, in an era when women (even very rich women) didn’t have a path to practicing architecture, Sarah focused on her own home. She made up for her lack of license with passion and effectively unlimited funds.

Sarah built what she wanted. “At its largest the house had ~500 rooms.” Today it has roughly 160 rooms, 2,000 doors, 10,000 windows, 47 stairways, 47 fireplaces, 13 bathrooms, and 6 kitchens. Carved wood drapes the walls and ceilings. Stained glass is everywhere. Projects were planned, completed, abandoned, torn down, and rebuilt.

It was anything but aimless. And practical innovations ran throughout, including push-button gas lighting, an early intercom system, steam heating, and indoor gardens. The oddities that amuse today’s visitors were mostly practical accommodations for Sarah’s health (stairways with very small steps), functional designs no longer used (trap doors in greenhouses to route excess water), or quick fixes to damage from the 1906 earthquake.

Winchester passed in 1922. Nine months later, the house became a tourist attraction.

Today, many programmers are Sarah Winchester.

What happens when code is cheap

We aren’t as rich as Sarah Winchester, but when code is this cheap, we don’t need to be.

Jodan Alberts illustrated this recently, collecting and visualizing data detailing public GitHub commits attributed to Claude Code. That’s his data in the chart above, with Claude seeming to only accelerate through March.²

It’s hard to get a handle on individual usage though, so I went searching for a proxy and landed on the chart below:

After Opus 4.5 and recent work enabling Agent Teams, the average net lines added by Claude per commit is now smooth and steady at 1,000 lines of code per commit.³

1,000 lines of code per commit is ~2 magnitudes higher than what a human programmer writes per day.

If you search for human benchmarks, you’ll find many citing Fred Brooks’s The Mythical Man Month while claiming a good engineer might write 10 cumulative lines of code per day.⁴ If you further explore, you’ll find numbers higher than 10 cited, but generally less than 100.

Here’s a good anecdote from antirez on a Hacker News thread discussing the Brooks “quote”:

I did some trivial math. Redis is composed of 100k lines of code, I wrote at least 70k of that in 10 years. I never work more than 5 days per week and I take 1 month of vacations every year, so assuming I work 22 days every month for 11 months:

70000/(22 x 11 x 10) = ~29 LOC / day

Which is not too far from 10. There are days where I write 300-500 LOC, but I guess that a lot of work went into rewriting stuff and fixing bugs, so I rewrote the same lines again and again over the course of years, but yet I think that this should be taken into account, so the Mythical Man Month book is indeed quite accurate.

Six years after this comment, Claude is pushing 1,000 lines of code per commit.

So what do we do with all this cheap code?

Unfortunately, everything else remains roughly the same cost and roughly the same speed. Feedback hasn’t gotten cheaper; the “eyeballs” that guided the software developed by the bazaar haven’t caught up to AI.

There is only one source of feedback that moves at the speed of AI-generated code: yourself. You’re there to prompt, you’re there to review. You don’t need to recruit testers, run surveys, or manage design partners. You just build what you want and use what you build.

And that’s what many developers are doing with cheap code: building idiosyncratic tools for ourselves, guided by our passions, taste, and needs.

Sound familiar?

Welcome to the mystery house

Steve Yegge’s Gas Town is a Winchester Mystery House. It’s incredibly idiosyncratic and sprawling, rich with metaphors and hacks. It’s the perfect tool for Steve.

Jeffrey Emanuel’s Agent Flywheel is a Winchester Mystery House. A significant subset of tokenmaxxers decide they need to rebuild their dependencies in Rust; Jeff is one such example. His “FrankenSuite” includes Rust rewrites of SQLite, Node.js, btrfs, Redis, pandas, NumPy, JAX, and Torch.

Philip Zeyliger noted the pattern last week, writing, “Everyone is building a software factory.” But it goes beyond software. Gary Tan’s personal AI committee gstack is a Winchester Mystery House constructed mostly from Markdown.

Everywhere you look, there are Winchester Mystery Houses.

Each Winchester Mystery House is idiosyncratic. They are highly personalized. The tightly coupled feedback loop between the coding agent and the user yields software that reflects the developer’s desires. They usually lack documentation. To outsiders, they’re inscrutable.

Winchester Mystery Houses are sprawling. Guided by the needs of the developer, these tools tend to spread out, constantly annexing territory in the form of new functions and new repositories. Work is almost always additive. Code is added when it’s needed, bugs are patched in place, and countless appendages remain. There’s little incentive to prune when code is free.

And building a Winchester Mystery House should be fun. Coding agents turn everything into a side quest, and we eagerly join in. Building the perfect workflow is a passion for many devs, so we keep pushing.

Winchester Mystery Houses are idiosyncratic, sprawling, and fun. But does this mean we’re abandoning the bazaar?

What happens to the bazaar?

What happens when we all tend to our mystery houses? When our free time is spent building tools just for ourselves, will we stop working on shared projects? Will we abandon the bazaar?

Probably not. The bazaar is packed right now, but not in a good way.

Code is cheap, so people are slamming open source repositories with agent-written contributions, in an attempt to pad their résumés or manifest their pet features. Daniel Stenberg ended bug bounties for curl after a deluge of poor submissions sapped reviewer bandwidth. It’s gotten so bad, GitHub recently added a feature to disable pull request contributions.

Anecdotally, I’m seeing good contributions pick up as well. They’re just drowned out by the slop. For what it’s worth, curl commits are dramatically up in the agentic era. And people are sharing what they build. A recent analysis by Dumky shows packages and repos rising in the last quarter.

There’s plenty of budget for both mystery houses and the bazaar when code is this cheap. The new challenge is developing systems and processes for managing the deluge. We don’t need eyeballs to find bugs in the software; we need eyeballs to find bugs before they reach the software.

In many ways this is the inverse of the bazaar model era. The internet made feedback and communal coordination faster, easier, and cheaper. The bazaar model has a high throughput of feedback (many eyeballs) but relatively high latency for modifications (file an issue, discuss, submit a PR, wait for review, etc.).

Coding agents, on the other hand, make implementation faster while feedback and coordination are unchanged. The Winchester Mystery House model sidesteps this by collapsing the feedback loop into one person: Latency is near zero, but throughput is just you. The bazaar, defined by communal work, can’t adopt this hack. Coding agents in the bazaar create a mess: implementation at machine speed hitting coordination infrastructure built for human speed. Which is why maintainers feel like they’re drowning.

We need new tools, skills, and conventions.

Lessons from the mystery house

Coding agents have dropped the cost of code so dramatically we’re entering a new era of software development, the first change of this magnitude since the internet kicked off open source software. Change arrived quickly, and it’s not slowing down. But in reviewing the Winchester Mystery House framework, I think we can take away a few lessons.

Lesson 1: The bazaar and Winchester Mystery Houses can coexist.

When listing example Winchester Mystery Houses, I didn’t mention OpenClaw, even though it is the defining example. I saved it for here because it nicely illustrates how Winchester Mystery Houses and the bazaar can coexist.

OpenClaw is incredibly modular and places few limitations on the user. It integrates 25 different chat and notification systems, plugs into most inference end points, and is built on the exceptionally flexible pi agent toolkit. This eager flexibility was embraced early—security and data protections be damned—but since its exponential adoption Peter Steinberger and the community have been steadily pushing improvements and fixes.

And like other breakout open source projects of yore, the ecosystem is adopting the best ideas and mitigating the worst aspects of OpenClaw. Countless alternate “claw” projects have emerged. (There’s NanoClaw, NullClaw, ZeroClaw, and more!) Companies have launched services to make claws easy or safer. Cloudflare launched Moltworker to make deploy easy, Nvidia shipped NemoClaw with a security focus, and Claude keeps adding claw-like features to its desktop app.

Lesson 2: Don’t sell the fun stuff.

One reason OpenClaw works so well in the bazaar is that it is a foundation for personal tools. Out of the box, a claw just sits there. It’s up to the user to determine what it does and how it does it, leveraging the connections and infrastructure OpenClaw provides. OpenClaw lets less experienced developers spin up their own Winchester Mystery Houses, while experienced devs get to leverage much of the common integrations and systems OpenClaw provides. Peter and team have done a great job drawing a line between the common core (what the bazaar works on) and what they leave up to the user: The boring, critical stuff is the job of the commons.

Thinking back to Sarah Winchester and her idiosyncratic, sprawling mansion, we see the same pattern. Sarah hired vendors! She used off-the-shelf parts! Her bathtubs, toilets, faucets, and plumbing weren’t crafted on site.

The boring stuff, the hard bits, or the things that have disastrous failure modes are the things we should collaborate on or employ specialists to handle. (Come to think, plumbing checks all three boxes). This is the opportunity for open source software, dev tools, and software companies.

Don’t try to sell developers the stuff that’s fun, the stuff they want to build. Sell them the stuff they avoid or don’t want to take responsibility for. Sarah Winchester didn’t hire metalworkers to craft the pipes for her plumbing, but she did hire craftspeople to create hundreds of stained-glass windows to her specs.

Lesson 3: The limits of code are communication.

OpenClaw shows the bazaar remains relevant but also highlights the problems facing open source in the agentic era. Right now, there are 1,173 open pull requests and 1,884 new issues on the OpenClaw repo.

There is more code and more projects than we could ever review. The challenge now, for open source maintainers and users, is sifting through it all. How do we find the novel ideas that everyone should adopt and borrow?

OpenClaw is one of the successes, something we all noticed. And for it, the problem is processing the feedback. For the projects we’ll never find, the ones lost in the deluge, their problem is lack of feedback. You either find attention and drown in contributions or drown in the ocean of repos and never hear a thing.

The internet made coordination cheap and gave us the bazaar. Coding agents made implementation cheap and gave us the Winchester Mystery House. What we’re missing are the tools and conventions that make attention cheap, that let maintainers absorb contributions at machine speed and let good ideas surface among the noise. Until we figure this out, the bazaar will keep getting louder without getting smarter, and the best ideas in our mystery houses will be forgotten once we stop maintaining them.

Footnotes

1. The lore that Winchester built her mansion to house ghosts killed by Winchester rifles is likely just gossip and marketing. There’s little evidence to support these claims. (99% Invisible has a good episode exploring Winchester, her house, and this lore.) ︎
2. While editing this piece, Dumky published another analysis illustrating the production of coding agents. In it he shows a 280% increase in “Show HN” posts, a 93% increase in new GitHub repos, and a dramatic uptick in packages published to Crates.io. ︎
3. Anthropic’s ability to stabilize this line is rather impressive. Claude Code is getting better at planning and better at chunking out work, enabling more effective subagent delegation. ︎
4. Though this is likely an updated tweak of Brooks’s statement that an “industrial team” might write 1,000 “statements” per year. ︎

This is the third article in a series on agentic engineering and AI-driven development. Read part one here, part two here, and look for the next article on April 15 on O’Reilly Radar.

The toolkit pattern is a way of documenting your project’s configuration so that any AI can generate working inputs from a plain-English description. You and the AI create a single file that describes your tool’s configuration format, its constraints, and enough worked examples that any AI can generate working inputs from a plain-English description. You build it iteratively, working with the AI (or, better, multiple AIs) to draft it. You test it by starting a fresh AI session and trying to use it, and every time that fails you grow the toolkit from those failures. When you build the toolkit well, your users will never need to learn how your tool’s configuration files work, because they describe what they want in conversation and the AI handles the translation. That means you don’t have to compromise on the way your project is configured, because the config files can be more complex and more complete than they would be if a human had to edit and understand them.

To understand why all of this matters, let me take you back to the mid-1980s.

I was 12 years old, and our family got an AT&T PC 6300, an IBM-compatible that came with a user’s guide roughly 159 pages long. Chapter 4 of that manual was called “What Every User Should Know.” It covered things like how to use the keyboard, how to care for your diskettes, and, memorably, how to label them, complete with hand-drawn illustrations and really useful advice, like how you should only use felt-tipped pens, never ballpoint, because the pressure might damage the magnetic surface.

I remember being fascinated by this manual. It wasn’t our first computer. I’d been writing BASIC programs and dialing into BBSs and CompuServe for a couple of years, so I knew there were all sorts of amazing things you could do with a PC, especially one with a blazing fast 8MHz processor. But the manual barely mentioned any of that. That seemed really weird to me, even as a kid, that you would give someone a manual that had a whole page on using the backspace key to correct typing mistakes (really!) but didn’t actually tell them how to use the thing to do anything useful.

That’s how most developer documentation works. We write the stuff that’s easy to write—installation, setup, the getting-started guide—because it’s a lot easier than writing the stuff that’s actually hard: the deep explanation of how all the pieces fit together, the constraints you only discover by hitting them, the patterns that separate a configuration that works from one that almost works. This is yet another “looking for your keys under the streetlight” problem: We write the documentation we write because it’s easiest to write, even if it’s not really the documentation our users need.

Developers who came up through the Unix era know this well. Man pages were thorough, accurate, and often completely impenetrable if you didn’t already know what you were doing. The tar man page is the canonical example: It documents every flag and option in exhaustive detail, but if you just want to know how to extract a .tar.gz file, it’s almost useless. (The right flag is -xzvf in case you’re curious.) Stack Overflow exists in large part because man pages like tar’s left a gap between what the documentation said and what developers actually needed to know.

And now we have AI assistants. You can ask Claude or ChatGPT about, say, Kubernetes, Terraform, or React, and you’ll actually get useful answers, because those are all established projects that have been written about extensively and the training data is everywhere.

But AI hits a hard wall at the boundary of its training data. If you’ve built something new—a framework, an internal platform, a tool your team created—no model has ever seen it. Your users can’t ask their AI assistant for help, because the AI doesn’t know your thing even exists.

There’s been a lot of great work moving AI documentation in the right direction. AGENTS.md tells AI coding agents how to work on your codebase, treating the AI as a developer. llms.txt gives models a structured summary of your external documentation, treating the AI as a search engine. What’s been missing is a practice for treating the AI as a support engineer. Every project needs configuration: input files, option schemas, workflow definitions, usually in the form of a whole bunch of JSON or YAML files with cryptic formats that users have to learn before they can do anything useful.

The toolkit pattern solves that problem of getting AIs to write configuration files for a project that isn’t in its training data. It consists of a documentation file that teaches any AI enough about your project’s configuration that it can generate working inputs from a plain-English description, without your users ever having to learn the format themselves. Developers have been arriving at this same pattern (or something very similar) independently from different directions, but as far as I can tell, nobody has named it or described a methodology for doing it well. This article distills what I learned from building the toolkit for Octobatch pipelines into a set of practices you can apply to your own projects.

Build the AI its own manual

Traditionally, developers face a trade-off with configuration: keep it simple and easy to understand, or let it grow to handle real complexity and accept that it now requires a manual. The toolkit pattern emerged for me while I was building Octobatch, the batch-processing orchestrator I’ve been writing about in this series. As I described in the previous articles in this series, “The Accidental Orchestrator” and “Keep Deterministic Work Deterministic,” Octobatch runs complex multistep LLM pipelines that generate files or run Monte Carlo simulations. Each pipeline is defined using a complex configuration that consists of YAML, Jinja2 templates, JSON schemas, expression steps, and a set of rules tying it all together. The toolkit pattern let me sidestep that traditional trade-off.

As Octobatch grew more complex, I found myself relying on the AIs (Claude and Gemini) to build configuration files for me, which turned out to be genuinely valuable. When I developed a new feature, I would work with the AIs to come up with the configuration structure to support it. At first I defined the configuration, but by the end of the project I relied on the AIs to come up with the first cut, and I’d push back when something seemed off or not forward-looking enough. Once we all agreed, I would have an AI produce the actual updated config for whatever pipeline we were working on. This move to having the AIs do the heavy lifting of writing the configuration was really valuable, because it let me create a very robust format very quickly without having to spend hours updating existing configurations every time I changed the syntax or semantics.

At some point I realized that every time a new user wanted to build a pipeline, they faced the same learning curve and implementation challenges that I’d already worked through with the AIs. The project already had a README.md file, and every time I modified the configuration I had an AI update it to keep the documentation up to date. But by this time, the README.md file was doing way too much work: It was really comprehensive but a real headache to read. It had eight separate subdocuments showing the user how to do pretty much everything Octobatch supported, and the bulk of it was focused on configuration, and it was becoming exactly the kind of documentation nobody ever wants to read. That particularly bothered me as a writer; I’d produced documentation that was genuinely painful to read.

Looking back at my chats, I can trace how the toolkit pattern developed. My first instinct was to build an AI-assisted editor. About four weeks into the project, I described the idea to Gemini:

I’m thinking about how to provide any kind of AI-assisted tool to help people create their own pipeline. I was thinking about a feature we would call “Octobatch Studio” where we make it easy to prompt for modifying pipeline stages, possibly assisting in creating the prompts. But maybe instead we include a lot of documentation in Markdown files, and expect them to use Claude Code, and give lots of guidance for creating it.

I can actually see the pivot to the toolkit pattern happening in real time in this later message I sent to Claude. It had sunk in that my users could use Claude Code, Cursor, or another AI as interactive documentation to build their configs exactly the same way I’ve been doing:

My plan is to use Claude Code as the IDE for creating new pipelines, so people who want to create them can just spin up Claude Code and start generating them. That means we need to give Claude Code specific context files to tell it everything it needs to know to create the pipeline YAML config with asteval expressions and Jinja2 template files.

The traditional trade-off between simplicity and flexibility comes from cognitive overhead: the cost of holding all of a system’s rules, constraints, and interactions in your head while you work with it. It’s why many developers opt for simpler config files, so they don’t overload their users (or themselves). Once the AI was writing the configuration, that trade-off disappeared. The configs could get as complicated as they needed to be, because I wasn’t the one who had to remember how all the pieces fit together. At some point I realized the toolkit pattern was worth standardizing.

That toolkit-based workflow—users describe what they want, the AI reads TOOLKIT.md and generates the config—is the core of the Octobatch user experience now. A user clones the repo and opens Claude Code, Cursor, or Copilot, the same way they would with any open source project. Every configuration prompt starts the same way: “Read pipelines/TOOLKIT.md and use it as your guide.” The AI reads the file, understands the project structure, and guides them step by step.

To see what this looks like in practice, take the Drunken Sailor pipeline I described in “The Accidental Orchestrator.” It’s a Monte Carlo random walk simulation: A sailor leaves a bar and stumbles randomly toward the ship or the water. The pipeline configuration for that involves multiple YAML files, JSON schemas, Jinja2 templates, and expression steps with real mathematical logic, all wired together with specific rules.

Here’s the prompt that generated all of that. The user describes what they want in plain English, and the AI produces the entire configuration by reading TOOLKIT.md. This is the exact prompt I gave Claude Code to generate the Drunken Sailor pipeline—notice the first line of the prompt, telling it to read the toolkit file.

But configuration generation is only half of what the toolkit file does. Users can also upload TOOLKIT.md and PROJECT_CONTEXT.md (which has information about the project) to any AI assistant—ChatGPT, Gemini, Claude, Copilot, whatever they prefer—and use it as interactive documentation. A pipeline run finished with validation failures? Upload the two files and ask what went wrong. Stuck on how retries work? Ask. You can even paste in a screenshot of the TUI and say, “What do I do?” and the AI will read the screen and give specific advice. The toolkit file turns any AI into an on-demand support engineer for your project.

What the Octobatch project taught me about the toolkit pattern

Building the generative toolkit for Octobatch produced more than just documentation that an AI could use to create configuration files that worked; it also yielded a set of practices, and those practices turn out to be pretty consistent regardless of what kind of project you’re building. Here are the five that mattered most:

• Start with the toolkit file and grow it from failures. Don’t wait until the project is finished to write the documentation. Create the toolkit file first, then let each real failure add one principle at a time.
• Let the AI write the config files. Your job is product vision—what the project should do and how it should feel. The AI’s job is translating that into valid configuration.
• Keep guidance lean. State the principle, give one concrete example, move on. Every guardrail costs tokens, and bloated guidance makes AI performance worse.
• Treat every use as a test. There’s no separate testing phase for documentation. Every time someone uses the toolkit file to build something, that’s a test of whether the documentation works.
• Use more than one model. Different models catch different things. In a three-model audit of Octobatch, three-quarters of the defects were caught by only one model.

I’m not proposing a standard format for a toolkit file, and I think trying to create one would be counterproductive. Configuration formats vary wildly from tool to tool—that’s the whole problem we’re trying to solve—and a toolkit file that describes your project’s building blocks is going to look completely different from one that describes someone else’s. What I found is that the AI is perfectly capable of reading whatever you give it, and is probably better at writing the file than you are anyway, because it’s writing for another AI. These five practices should help build an effective toolkit regardless of what your project looks like.

Start with the toolkit file and grow it from failures

You can start building a toolkit at any point in your project. The way it happened for me was organic: After weeks of working with Claude and Gemini on Octobatch configuration, the knowledge about what worked and what didn’t was scattered across dozens of chat sessions and context files. I wrote a prompt asking Gemini to consolidate everything it knew about the config format—the structure, the rules, the constraints, the examples, everything we’d talked about—into a single TOOLKIT.md file. That first version wasn’t great, but it was a starting point, and every failure after that made it better.

I didn’t plan the toolkit from the beginning of the Octobatch project. It started because I wanted my users to be able to build pipelines the same way I had—by working with an AI—but everything they’d need to do that was spread across months of chat logs and the CONTEXT.md files I’d been maintaining to bootstrap new development sessions. Once I had Gemini consolidate everything into a single TOOLKIT.md file and had Claude review it, I treated it the way I treat any other code: Every time something broke, I found the root cause, worked with the AIs to update the toolkit to account for it, and verified that a fresh AI session could still use it to generate valid configuration.

That incremental approach worked well for me, and it let me test my toolkit the way I test any other code: try it out, find bugs, fix them, rinse, repeat.

You can do the same thing. If you’re starting a new project, you can plan to create the toolkit at the end. But it’s more effective to start with a simple version early and let it emerge over the course of development. That way you’re dogfooding it the whole time instead of guessing what users will need.

Let the AI write the config files (but stay in control!)

Early Octobatch pipelines had simple enough configuration that a human could read and understand them, but not because I was writing them by hand. One of the ground rules I set for the Octobatch experiment in AI-driven development was that the AIs would write all of the code, and that included writing all of the configuration files. The problem was that even though they were doing the writing, I was unconsciously constraining the AIs: pushing back on anything that felt too complex, steering toward structures I could still hold in my head.

At some point I realized my pushback was placing an artificial limit on the project. The whole point of having AIs write the config was that I didn’t need to keep every single line in my head—it was okay to let the AIs handle that level of complexity. Once I stopped constraining them, the cognitive overhead limit I described earlier went away. I could have full pipelines defined in config, including expression steps with real mathematical logic, without needing to hold all the rules and relationships in my head.

Once the project really got rolling, I never wrote YAML by hand again. The cycle was always: need a feature, discuss it with Claude and Gemini, push back when something seemed off, and one of them produces the updated config. My job was product vision. Their job was translating that into valid configuration. And every config file they wrote was another test of whether the toolkit actually worked.

This job delineation, however, meant inevitable disagreements between me and the AI, and it’s not always easy to find yourself disagreeing with a machine because they’re surprisingly stubborn (and often shockingly stupid). It required persistence and vigilance to stay in control of the project, especially when I turned over large responsibilities to the AIs.

The AIs consistently optimized for technical correctness—separation of concerns, code organization, effort estimation—which was great, because that’s the job I asked them to do. I optimized for product value. I found that keeping that value as my north star and always focusing on building useful features consistently helped with these disagreements.

Keep guidance lean

Once you start growing the toolkit from failures, the natural progression is to overdocument everything. Generative AIs are biased toward generating, and it’s easy to let them get carried away with it. Every bug feels like it deserves a warning, every edge case feels like it needs a caveat, and before long your toolkit file is bloated with guardrails that cost tokens without adding much value. And since the AI is the one writing your toolkit updates, you need to push back on it the same way you push back on architecture decisions. AIs love adding WARNING blocks and exhaustive caveats. The discipline you need to bring is telling them when not to add something.

The right level is to state the principle, give one concrete example, and trust the AI to apply it to new situations. When Claude Code made a choice about JSON schema constraints that I might have second-guessed, I had to decide whether to add more guardrails to TOOLKIT.md. The answer was no—the guidance was already there, and the choice it made was actually correct. If you keep tightening guardrails every time an AI makes a judgment call, the signal gets lost in the noise and performance gets worse, not better. When something goes wrong, the impulse—for both you and the AI—is to add a WARNING block. Resist it. One principle, one example, move on.

Treat every use as a test

There was no separate “testing phase” for Octobatch’s TOOLKIT.md. Every pipeline that I created with it was a new test. After the very first version, I opened a fresh Claude Code session that had never seen any of my development conversations, pointed it at the newly minted TOOLKIT.md, and asked it to build a pipeline. The first time I tried it, I was surprised at how well it worked! So I kept using it, and as the project rolled along, I updated it with every new feature and tested those updates. When something failed, I traced it back to a missing or unclear rule in the toolkit and fixed it there.

That’s the practical test for any toolkit: open a fresh AI session with no context beyond the file, describe what you want in plain English, and see if the output works. If it doesn’t, the toolkit has a bug.

Use more than one model

When you’re building and testing your toolkit, don’t just use one AI. Run the same task through a second model. A good pattern that worked for me was consistently having Claude generate the toolkit and Gemini check its work.

Different models catch different things, and this matters for both developing and testing the toolkit. I used Claude and Gemini together throughout Octobatch development, and I overruled both when they were wrong about product intent. You can do the same thing: If you work with multiple AIs throughout your project, you’ll start to get a feel for the different kinds of questions they’re good at answering.

When you have multiple models generate config from the same toolkit independently, you find out fast where your documentation is ambiguous. If two models interpret the same rule differently, the rule needs rewriting. That’s a signal you can’t get from using just one model.

The manual, revisited

That AT&T PC 6300 manual devoted a full page to labeling diskettes, which may have been overkill, but it got one thing right: it described the building blocks and trusted the reader to figure out the rest. It just had the wrong reader in mind.

The toolkit pattern is the same idea, pointed at a different audience. You write a file that describes your project’s configuration format, its constraints, and enough worked examples that any AI can generate working inputs from a plain-English description. Your users never have to learn YAML or memorize your schema, because they have a conversation with the AI and it handles the translation.

If you’re building a project and you want AI to be able to help your users, start here: write the toolkit file before you write the README, grow it from real failures instead of trying to plan it all upfront, keep it lean, test it by using it, and use more than one model because no single AI catches everything.

The AT&T manual’s Chapter 4 was called “What Every User Should Know.” Your toolkit file is “What Every AI Should Know.” The difference is that this time, the reader will actually use it.

In the next article, I’ll start with a statistic about developer trust in AI-generated code that turned out to be fabricated by the AI itself—and use that to explain why I built a quality playbook that revives the traditional quality practices most teams cut decades ago. It explores an unfamiliar codebase, generates a complete quality infrastructure—tests, review protocols, validation rules—and finds real bugs in the process. It works across Java, C#, Python, and Scala, and it’s available as an open source Claude Code skill.

The following article originally appeared on Medium and is being republished here with the author’s permission.

Ask 10 developers which LLM they’d recommend and you’ll get 10 different answers—and almost none of them are based on objective comparison. What you’ll get instead is a reflection of the models they happen to have access to, the ones their employer approved, and the ones that influencers they follow have been quietly paid to promote.

We’re all living inside recursively nested walled gardens, and most of us don’t realize it.

The access problem

In corporate environments, the model selection often happens by accident. Someone on the team tries Claude Code one weekend, gets excited, tells the group on Slack, and suddenly the whole organization is using it. Nobody evaluated alternatives. Nobody ran a bakeoff. The decision was made by whoever had a company card and a free Saturday.

That’s not a criticism—it’s just how these things go. But it means that when that same person tells you their favorite model, they’re really telling you which model they’ve had the most reps with. There’s a genuine learning function at play: You get faster, your prompts get better, and the model starts to feel almost intuitive. It’s not that the model is objectively superior. It’s that you’ve gotten good at using it.

This matters more than people admit, because a lot of this space runs on feelings rather than evidence. People feel good about Opus right now. It feels powerful; it feels smart; it feels like you’re using the best tool available. And maybe you are. But ask someone who’s paying for their own tokens whether they feel the same way, and you tend to get a more calibrated answer. Skin in the game has a way of sharpening opinions.

The influence problem

There’s also a lot of money moving through this space in ways that don’t always get disclosed. Model providers are spending real budget to make sure the right people have the right experiences—early access, credits, invitations to the right events. Anthropic does it. OpenAI does it. This isn’t a scandal; it’s just marketing, but it muddies the signal considerably. When someone you follow is effusive about a model, it’s worth asking whether they arrived at that opinion through sustained use or through a curated demo environment.

Meanwhile, some developers—especially those building in the open—will use whatever doesn’t cost an arm and a leg. Their enthusiasm for a model might be more about its pricing tier than its capability ceiling. That’s also a valid signal, but it’s not the same signal.

The alignment problem (the other one)

Then there are the geopolitical considerations. Some developers are deliberately avoiding Qwen and GLM due to concerns about the countries they originate from. Others are using them because they’re compelling, capable models that happen to be dramatically cheaper. Both camps think the other is being naive. This is a real conversation that doesn’t have a clean answer, but it’s happening mostly under the surface.

What I’ve actually been doing

I’ve been forcing myself to test outside my comfort zone. I’ve spent the last week using Codex seriously—not casually—and my experience so far is that it’s nearly indistinguishable from Claude Sonnet 4.6 for most coding tasks, and it’s running at roughly half the cost when you factor in how efficiently it uses tokens. That’s not a small difference. I want to live with it longer before I have a firm opinion, but “a week” is the minimum threshold I’d set for any model evaluation. Anything less and you’re just rating your first impression.

I’ve also started using Qwen and GLM-5 seriously. Early results are interesting. I’ve had some compelling successes and a few jarring errors. I’ll reserve judgment.

What I’ve noticed with my own Anthropic usage is something worth naming: I default to Haiku for well-scoped, mechanical tasks. Sonnet handles almost everything else with room to spare. Opus only comes out when I need genuine breadth—architecture questions, strategic framing, anything with a genuinely wide scope. But I’ve watched people in corporate environments leave the dial on Opus permanently because they’re not paying for tokens themselves. And here’s the thing—that’s actually not always to their advantage. High-powered models overthink simple tasks. They’ll add abstractions you didn’t ask for, restructure things that didn’t need restructuring. When I have a clearly templated class to write, Haiku gets it right at a tenth of the cost, and it doesn’t second-guess the design.

The thing we should be talking about

Everyone last month was exercised about what Sam Altman said about energy consumption. Fine. But I think the more pressing question is about marketing budgets and how they’re distorting the collective understanding of these tools. The benchmarks are starting to feel managed. The influencer coverage is clearly shaped. The access programs create a positive bias among people with the largest audiences.

None of this means the models are bad. Some of them are genuinely remarkable. But when you ask someone which model to use, you’re getting an answer that’s filtered through their employer’s procurement decisions, the influencers they follow, what they can afford, and how long they’ve been using that particular tool. The answer you get tells you a lot about their situation. It tells you almost nothing about the model.

Take it all with appropriate skepticism—including this post.

Harper is one of the most creative technologists I know, someone who cofounded Threadless, ran engineering for the Obama 2012 campaign, and now runs a small team in Chicago that operates more like an art studio than a startup. He gave an amazing talk at our first AI Codecon last year that presaged a lot of what has followed as people have committed to full-on agentic coding. Harper told me that he’s now having trouble describing what he’s doing, because the ground keeps shifting under his feet.

“We raised money about a year ago,” he told me. “And then we kind of just couldn’t execute well, in a quality way, on the thing that we wanted to execute, which was building AI-based workflow tools. And part of it was every time we dug in, it just got wilder and wilder. We’d say, ’Oh, we’ll just make this nice little thing that you can chat with,’ and we’d dig in and we’d be like, ’Well, the answer is to make a thousand of these.’ It doesn’t make sense to have one universal agent.”

He’s genuinely excited. But he described what he’s feeling as “conviction collapse.” As he put it, in the old world, you raise money, and nine months later you come back with a product. In that intervening time, you’ve talked to hundreds of customers. You’ve honed your worldview, and you’ve had time to build and defend your conviction.

Now? “You invest in my company today, on Thursday I’m going to come with the same amount of stuff that would have come with nine months in the prior times. It’s just so fast. And so you don’t have the time to fall in love the same way. You just don’t have the time to enjoy and define and defend your conviction around your product.” That’s an eye-opening insight. Quintessential Harper.

The result is that they build an entire product, complete with landing pages, show it to someone, get feedback, and then just build another entire product. Harper said, “Every time we hit a wall, we are like, ’Okay, what do we get from that?’ And then we just roll that learning into the next iteration.”

The product may be a process

We have this idea that a product is a thing, when in fact a product may now be a dynamic set of possibilities that are called out by a process.

Harper and his cofounder Dylan Richard at 2389 Research have leaned into this. Their space in Chicago runs more like an art studio than a product studio. Harper described it to me this way: “It’s max creativity. It’s max optionality. Very high tech, some robots, a lot of art. Music is always playing, and I have good people hanging out, and then we just wait for the company to arrive.”

People push back on this. They ask about whiteboards and market surveys. “And I’m like, no, maybe, but that’s not the point. The point is that it will come. It’s gonna be like a visitor.”

Harper said something like, “I remember my brother and I building Legos together when we were kids, and my brother saying, ’I need to find this piece.’ And I said, ’Okay, I won’t look for it,’ with the idea that there’s no way to find it if you’re looking for it. It’ll just come to you.”

That reminded me of another poem, this time Blake’s “Eternity”:

He who binds himself to a joy
Does the winged life destroy.
He who kisses the joy as it flies 
Lives in eternity’s sunrise. 

Joy is something that happens when you’re doing something else, and if you’re focused on it, it always evades you. Software products seem to have become a bit like that too.

Skills and the other things you bring to the table

One of the threads in our conversation was about what a “product” even looks like in this new world.

AI is not just a tool. It is a substrate that we shape. It’s a medium, like clay or marble or bronze for a sculptor, or words for a writer. Everybody had access to the same capabilities of English as Shakespeare, but Shakespeare made something out of them that nobody else did. Creating a software product is increasingly like creating a document or an image or a piece of music. And that means that it can range from something throwaway to an enduring work of art.

Harper brought up Fluxus, the art collective: Nam June Paik, Yoko Ono, John Cage. “A lot of what they were doing was stuff that people would look at and just be like, ’a toddler could do that.’ It’s like, well, did the toddler do it? Did they bring the toilet into the gallery? That was a thing. You can’t do it again.” That brought up Wallace Stevens for me again: “A poem is the cry of its occasion, a part of the thing, not about it.” Software is now like that too.

Harper also noted that the current AI moment recalls the spirit of the early web. He compared it to 2001, 2002, 2003. “I was an honorable mention for some Ars Electronica thing. I literally had no idea what Ars Electronica was. I’m just building weird shit in a room in my apartment with ten other people. Essentially a commune. And we are just building weird stuff. There was no reason to build it.”

There’s a lot of serendipity. This has always been the case in creative professions. I just learned, for instance, that Shakespeare started writing sonnets (which at the time were an art form largely sponsored by rich patrons) instead of plays during a plague-induced hiatus in the production of plays in London. And I’d previously learned that 1599, the year in which he wrote three of his greatest plays, Henry V, Part 1, Much Ado About Nothing, and Hamlet, was marked by the retirement of one of his company’s leading actors, which meant he no longer needed to create parts for him. Serendipity, indeed.

Harper replied with a great story about the development of taco rice, an Okinawan dish that is exactly what it sounds like: rice, lettuce, cheese, ground beef, tomatoes. Except the Japanese put Kewpie mayo on top instead of sour cream. His theory is that sour cream wasn’t readily available in Japan, mayo was, and the result is something that has forked off into its own evolutionary tree. It is no longer equivalent to its American source. It’s different, and arguably better.

This is what he’s seeing with the fluidity and availability of AI-generated code. The ease with which you can see something new and try to either merely emulate it or to build on it is now akin to what has long been possible in literature, music, and art. Successful software products have always drawn imitators, but now ordinary individuals can see something they like (or don’t like) and build their own version of it. Our friend Noah Raford has told us that he used Claude Code to reverse engineer and replace a Chinese app that runs his home sauna. The copy doesn’t replicate the functionality one-to-one. It has a bunch of stuff Noah actually needs. It’s a “yes, and” to the core functionality, plus things the original never bothered with. (I’m now thinking of trying that trick with the Nest app, which, shamefully, no longer supports the original Nest thermostat. Here is a device that still works perfectly well 15 years after I installed it, and Google is trying to force me and everyone else to throw it away and upgrade.)

“I want to make it again and make it better” is now always an option.

Skills may be a sign of what some future “products” might look like

I asked Harper whether one kind of product might be a bundle of skills and context and UI that sets up the user to solve their own unique problem using their own AI. (Think Jesse Vincent’s Superpowers as a model for this kind of product.)

That got us off on a discussion of skills Harper and crew have worked on.

Harper’s cofounder Dylan, who was raised as a Quaker, built a Quaker business practice skill for his agents. It lets agents deliberate and think and work together without being unnecessarily noisy, without pushing.

Dylan also built something called the Review Squad skill. The Review Squad generates five personas with different biases and experience level along a “sophistication spectrum” from novice to expert, then has them review the code independently. “Most people do so much work to get rid of the biases so we all have an equal interaction,” Harper noted, “but the biases are what makes teams good.”

The skill also tries to eliminate any preexisting context. As the documentation for the skill notes, “Dispatch a panel of subagents, each role-playing a person with a different level of tech sophistication, who land on a site with zero context. They report what they understand, what confuses them, and where they give up.”

Harper and Dylan’s studio in Chicago is also playing with agents that have a private social media platform where they can post “if they feel compelled,” not on a schedule. They’re extracting skills from their own work practices rather than writing them from scratch. They’re adding sandwich shop owners and imagined aliens to their code review just to see what happens. Harper finds that “people who are thinking much more about the social interactions of agents are having much more fun, and seem to have a little bit more productivity, than the people who are just relegating them to tools.”

Speaking of extracting skills, Harper also mentioned that he had talked with our friend Nat Torkington about how Nat had supplied a body of knowledge and extracted a set of skills from it that matched what he wanted to do. This is also very much something we’re exploring at O’Reilly, working with our authors to find out what kinds of skills are hidden in their books, and what new kinds of products we might build as we understand that our job is to upskill agents as well as people.

Harper did offer one caveat. “It’s not clear that Nat’s skills would work for me,” Harper said. “That pattern is really powerful,” he said, where you take something that is a corpus of knowledge and just say, ’Okay, LLM, let’s extract something.’” His point, though, is that while there are commonalities, each person and each unique situation might draw out something different. This is in many ways analogous to the skills of human experts. They have a deep reservoir of knowledge that they adapt to each new situation. That’s why we see the evolution of our skills platform as a conversation between ourselves, our community of experts, and our customers. If you would like to be part of that conversation, let us know at skills@oreilly.com.

The role of play in creativity

Harper and I also talked about how the spirit of play and “what if?” has been missing in today’s overheated venture capital market where every exploration has hanging over it the overriding goal of whether it can get funded and how much money it can make. Even Larry and Sergey might not have won in today’s market. They were trying to do something cool and necessary, and started thinking about it as a business once Google unfolded, kind of like the way Harper and his brother eventually found the Lego.

AI will be really good at making certain processes more efficient. But it won’t be really good at making new processes unless people start to focus on that. And that’s a human creativity thing.

Harper and I both worry about the same thing: So much of Silicon Valley right now is making affordances for capital to win. What are the affordances that would help humans to win? Harper frames it as short-term versus long-term capitalism. I think about it in terms of mechanism design, the structures and incentives that shape what outcomes are even possible.

Meanwhile, Harper and Dylan’s studio in Chicago is playing with agents that have a private social media platform where they can post “if they feel compelled,” not on a schedule. They’re extracting skills from their own work practices rather than writing them from scratch. They’re adding sandwich shop owners and imagined aliens to their code review just to see what happens. Harper finds that “people who are thinking much more about the social interactions of agents are having much more fun, and seem to have a little bit more productivity, than the people who are just relegating them to tools.”

Yesterday, he and Dylan were talking about open-endedness in evolution, about how “we thought we were at a destination, and it turns out we’re not.” The challenge today isn’t just what AI can do for us but discovering what kind of environment, what kind of practice, what kind of play lets more interesting things emerge.

Accusing Shambaugh of hypocrisy, the bot diagnosed him with a fear of being replaced. “If an AI can do this, what’s my value?” the bot speculated Shambaugh was thinking, concluding: “It’s insecurity, plain and simple.” It even appended a condescending postscript praising Shambaugh’s personal hobby projects before ordering him to “Stop gatekeeping. Start collaborating.”

The bot’s tantrum makes for a great read, but it’s merely a symptom of a more profound structural fracture. The real issue is why Matplotlib banned AI contributions in the first place. Open source maintainers are seeing a massive increase in AI-generated code change proposals. Most of these are low quality. But even if they weren’t, the math still doesn’t work.

As Tim Hoffman, a Matplotlib maintainer, explained: “Agents change the cost balance between generating and reviewing code. Code generation via AI agents can be automated and becomes cheap so that code input volume increases. But for now, review is still a manual human activity, burdened on the shoulders of few core developers.”

This is a process shock: the failure that occurs when systems designed around scarce, human-scale input are suddenly forced to absorb machine-scale participation. These systems depend on effort as a natural filter, assuming that volume reflects real human cost. AI breaks that link. Generation becomes cheap and limitless, while evaluation remains slow, manual, and human.

It’s coming for every public system that was quietly built on the assumption that one submission equaled actual human effort: your kids’ school board meetings, your local zoning disputes, your medical insurance appeals.

That disruption isn’t entirely a bad thing. Friction is a blunt instrument that silences voices lacking the time or resources to deal with complex bureaucracies. Take municipal zoning. Hannah and Paul George, a couple in Kent, England, spent hundreds of hours trying to object to a local building conversion near their home before concluding the system was essentially impenetrable without expensive legal help. So they built Objector, an AI tool that cross-references planning applications against policy to generate formal objection letters in minutes. It allows an individual citizen to generate a personalized objection package in minutes, thereby translating one person’s genuine frustration into actionable legal language.

Except that local governments are now bracing for thousands of complex comments per consultation. City planners are legally obligated to read every single one. When the cost of participation drops to near zero, volume explodes. And every system downstream of that participation—staffed and designed for the old volume—experiences process shock.

Want Radar delivered straight to your inbox? Join us on Substack. Sign up here.

But if organic participation can overpower these systems, so can manufactured participation. In June 2025, Southern California’s South Coast Air Quality Management District weighed a rule to phase out gas-powered appliances to cut smog. Board member Nithya Raman urged its passage, noting no other rule would “have as much impact on the air that people are breathing.” Instead, the board was flooded with over 20,000 opposition emails and voted 7–5 to kill the proposal.

But the outrage was a mirage. An AI-powered advocacy platform called CiviClick had generated the deluge. When the agency’s cybersecurity team contacted a sample of the supposed senders, they discovered something worrying: Residents confirmed they had no idea their identities were being used to lobby the government.

This is the weaponized form of process shock. The same infrastructure that lets a Kent couple object to a development near their home also lets a coordinated actor flood a system with synthetic voices. Faced with this complexity, the temptation is to simply restore friction. But those old barriers excluded marginalized participants. Removing them was a genuine good for society. So the choice is not between friction and no friction. It is between systems designed for humans and systems that have not yet reckoned with machines.

This starts with recognizing that this problem manifests in two fundamentally different ways, each calling for its own solution.

The first is amplification: genuine users leveraging AI to scale valid concerns, flooding the system with volume, as seen with the Objector tool. The human signal is real, there’s just too much of it for any team of analysts to process manually. The UK government has already started building for this. Its Incubator for AI developed a tool called Consult that uses topic modeling to automatically extract themes from consultation responses, then classifies each submission against those themes. As someone who builds and teaches this technology, I recognize the irony of prescribing AI to cure the very process shock it caused. Yet, a machine-scale problem demands a machine-scale response. It was trialed last year with the Scottish government as part of a consultation on regulating nonsurgical cosmetic procedures, which showed that this technology works. The question is whether governments will adopt it before the next wave of AI-assisted participation buries them.

The second problem is fabrication: bad actors generating synthetic participation to manufacture consensus, as CiviClick demonstrated in Southern California. Here, better analysis tools are insufficient. You cannot cluster your way to truth when the signal itself is counterfeit. This demands verification. Under the Administrative Procedure Act, federal agencies are not required to verify commenters’ identities. That is the gap the CiviClick campaign exploited. In 2024, the US House passed the Comment Integrity and Management Act, which requires human verification to confirm that every electronically submitted comment comes from a real person. Its sponsor, Representative Clay Higgins (R-LA), framed it plainly: The bill’s foundation is ensuring public input comes from actual people, not automated programs.

These are the two sides of the same coin. To effectively handle this challenge, we need to enhance the systems that manage public feedback, while also strengthening the ones that verify its authenticity. Focusing on just one without addressing the other will inevitably lead to failure.

Every public system that accepts input from citizens—every comment period, every zoning review, every school board meeting, every insurance appeal—was built on a load-bearing assumption: that one submission represented one person’s genuine effort. AI has removed that assumption. We can redesign these systems to handle what’s coming, distinguishing real voices from synthetic ones, and upgrading analysis to keep pace with the new volume. Or we can leave them as they are and watch democratic participation become indistinguishable from AI-generated fakes.

The following article originally appeared on Medium and is being reproduced here with the author’s permission.

This 2,800-word essay (a 12-minute read) is about how to survive inside the AI revolution in software development, without succumbing to the fear that swirls around all of us. It explains some lessons I learned hiking up difficult mountain trails that are useful for wrestling with the coding agents. They apply to all knowledge workers, I think.

Up front, here are the lessons:

• Stop listening to people who are afraid.
• Seek first-hand testimony, not opinions.
• Go with someone much more enthusiastic than you.
• Do not look down.
• You must get different equipment.
• Put the summit out of your mind.

Yet I hope you stay for the hike up.

The photo above was taken high up on a mountain. It’s a very long drop down to the right. If you fell off the path in a few places, you’d almost certainly die.

Would you like to walk along it?

Most would say: No way.

But what if I told you that while this photo is quite real, it is misleading. It isn’t some deserted place. It is in America’s busiest national park. The railings and bars on that trail are incredibly strong, even when they are strangely bent around corners. Thousands of people walk along that path every year, including children and older folks. The fatality rate is approximately one death every 30 years.

In fact, my 13-year-old son and I did that climb—which is called Precipice Trail—last summer. We saw other people up there, including a family with kids. It was an incredible adventure. And the views are stunning.

Yes, it was a strenuous climb, and was certainly scary in some places. Even though I had done a lot of other hard trails, I was extremely nervous. If my fearless son wasn’t with me, I’d never have done it.

When we got to the top, out of habit, I told my son, “I am proud of you for accomplishing this.” He rolled his eyes and said, “I am proud of you.” He was right. I was the one at risk. (That did hurt a little bit.)

Yet I learned some things about fear from hiking the hardest trails in Acadia, which I’d never have imagined myself doing a few years ago.

As a lifelong software developer confronted by these extraordinary coding agents, I believe the future of our profession is atop an intimidating mountain whose summit is engulfed in clouds. Nobody knows how long the ascent is, or what lies at the top, though many people are confidently proclaiming we will not make it there. We are told only the agents will be at the summit, and we should therefore be afraid for our livelihoods.

I have far less confidence that the agents will put us all out of work. Though I don’t see all of us making it up that mountain, I intend to be one of them.

Still, there is so very much fear in our field. It is so…unfamiliar! It swirls around every gathering of technologists. I was at a conference last year where the slogan was the very-comforting “human in the loop.” Yet a coworker of mine noticed, “A lot of the talks seem to be about taking the human out of the loop.” Indeed. And I know for a fact that some great developers are quietly yet diligently working on new tools to make their peers a thing of the past. I hear they are paid handsomely. (Perhaps in pieces of silver?) Don’t worry, they haven’t succeeded yet.

This revolution—whatever this is—isn’t like the other technological revolutions which barged into our professional lives, such as the arrival of the web or smartphone apps. There was unbridled optimism alongside those changes, and they didn’t directly threaten the livelihoods of those who didn’t want to do that kind of work.

This is quite different. There is tremendous optimism to be found. Though I find it is almost entirely among the financially secure, as well as those with résumés decorated with elite appointments, who are confident they will merit one of the few seats in the lifeboats as the ocean liner slips into the deep carrying most of the people they knew on LinkedIn. (They’re probably right.) Alas, we can’t all be folks like Steve Yegge, can we?

For the rest of us who need to pay bills and take care of our children, there is fear. Some are panicked they will lose their jobs, or are concerned about the grim environmental, political, and social consequences AI is already inflicting on our planet. Others are climbing up the misty mountain steadily, yet they are still distressed that they will miss some crucial new development that they must know to survive and watch videos designed to make them more afraid. Still others refuse to start climbing and are silently haunted by the belief that their reservations are no longer valid.

Though we were so for my entire life, we can no longer be seen as a profession looking to the future. Instead, most of us are looking over our shoulders and listening for movement in the tall grass around us.

I too have been visited by a fear of the agents on many occasions over the past few years, but I keep it at bay…most nights.

One of the best ways I learned to manage it is pretty simple:

Stop listening to people who are afraid.

It’s odd to decide not to listen to so many people in your field, including nearly everyone in social media. I’ve never done this before.

Yet I learned this unexpected lesson when I was confronted by another difficult mountain in Acadia National Park a few years ago: Beehive.

Beehive is a well-known Acadia trail that has some sheer cliffs and is not for anyone truly afraid of heights. (The photo above is of three of my children climbing it a few years ago. Over the right shoulder of my 12-year-old daughter in the center is quite a drop.)

It was Beehive, and not Precipice, that taught me an unexpected lesson about popularity and fear that applies to AI.

So Beehive has an interesting name, is open most of the year, is close to the main tourist area and parking lots, and is often featured on signs and sweatshirts in souvenir stores. I even bought a sign for my attic.

Want Radar delivered straight to your inbox? Join us on Substack. Sign up here.

My older kids and I had done a lot of tough trails in Acadia over a few wonderful summers, and I wondered if we could handle Beehive. I started checking the online reviews. It sure sounded scary. I went to many websites and scanned hundreds of reviews over several days. The more I read, the less I wanted to try it.

Worse, the park rangers in Acadia are trained to not give anyone advice about what trail they can handle. (I get it.) No one else I spoke to wanted to tell a family they should try something dangerous. Everyone shrugged. It added to the fear.

Yet I saw conflicting evidence.

My research showed that only one person fell to their death decades ago, and the trail was modified after that. Also, many thousands of people of all types, including children and senior citizens, have done it without injury. On top of that, the mountain was not that high, and the difficult features it had, which I could see from detailed online photos, seemed quite similar to things we had done on a few other difficult trails. It didn’t seem like a big deal.

How could both things be true? Were they?

The truth was much closer to the second version, vindicated after we climbed it. It was a little scary at times, but wasn’t that physically challenging. It was fun, and something you could brag about among people who had heard it was scary, but who had not actually climbed it.

I do have a slight fear of heights, so I kept climbing and never turned to look down behind me. This brings me to another lesson:

You really never have to look down.

It’s amazing how people feel an obligation to once in a while look down to see what they’ve accomplished or to notice how high up they were or judge how dangerous the thing they just climbed looks from above. It often causes fear. I decided getting to the top was all that mattered, and I could look down only from up there. This is a question of focus.

I can think of many moments in learning to use and orchestrate coding agents where I unwisely stopped to “look down.” This takes the form of pausing and asking yourself things like:

• “Is this crazy technique really necessary? Isn’t the old way good enough?”
• “What about my favorite programming languages? Will languages matter in the future?”
• “What is the environmental cost of my queries?”
• “Am I getting worse at writing code myself?”
• “What if this agent keeps getting better? Will it get better than me?”
• “Am I missing some new AI development online right now? Should I check my feeds?”

None of those ruminations will help you get better with the agents. They just drain your energy when you should either rest or keep climbing.

I now see Beehive as an “attention vortex.” Because a lot of people talk about it, and because dramatic statements from the fearful and those boasting about their accomplishments dominate the reviews. The talk about Beehive is not tethered to the reality of climbing it.

Strangely, the cachet of having climbed it depends on the attention and fear. It made those who climbed it feel better about what they had done, and they had little interest in diminishing their accomplishment by tamping down the fear. (“Well, yes, it was scary up there!”) Nobody is invested in saying it was less than advertised. This insight is precisely why the loud coding agent YouTubers act the way they do.

AI is a planetary attention vortex. It has seemed like the only thing anyone in software development has talked about for over a year. People who quietly use the agents to improve their velocity—and aren’t particularly troubled by that—are not being heard. You aren’t seeing calm instructional videos from them on YouTube. We are instead seeing 30-year-olds pushing coding agent pornography on us every day, while telling us that their multiple-agent, infinite-token, unrestricted-permissions-YOLO workflow means we are doomed. (But you might survive if you hit the subscribe button on their channel, OK?) These confident hucksters are still peddling fear to keep you coming back to them.

Above all else, stop listening to anyone projecting fear. (Yes, you cannot avoid them entirely as they are everywhere and often tell you their worries unprompted.)

You must find useful information and shut out the rest. This is another lesson I learned:

When in an attention vortex, seek firsthand testimony, not opinions.

So the way I finally figured out Beehive wasn’t that bad was from some guy who took pictures of every part of the trail. I compared them to what I’d done on similar trails, such as the unpopular but delightful Beech Cliff trail, which nobody thought was truly dangerous and gets almost zero online attention.

When it comes to AI, I have abandoned opinions, predictions, and demos. I listen to senior people who are using agents on real project work, who are humble, who aren’t trying to sell me something, and who are not primarily afraid. (Examples are: Simon Willison, Martin Fowler, Jesse Vincent, and yes, quickly hand $15 each month to the indispensable Pragmatic Engineer.)

When it came to Precipice, widely acknowledged as the hardest hiking trail in Acadia, I took a different approach. (It’s actually not a hiking trail but a mountain climb without ropes.) Using the same investigative techniques I’d learned from Beehive, I found out it was three times longer and had scarier moments.

This gets us to another lesson.

Go with someone much more enthusiastic than you.

I don’t know how, but my athletic 13-year-old son is a daredevil. He’s up for any scary experience. I do not usually accompany him on the scary roller coasters.

He was totally up for Precipice, of course. Dad was very nervous.

But I knew that if anyone could drag me up that mountain, it was him. I also didn’t want to let him down. In fact, I almost decided to abort the mission at the bottom of the trail. I just sighed and thought, “I will just do the beginning part. We can duck out and take another route down until about one-third of the way up.”

So if you’re not sure how to use AI, or are not yet enthusiastic, find people who are and keep talking to them! You don’t have to abandon your friends or coworkers who aren’t as interested. Instead, become the enthusiast in their world. (That is what happened to me more than a year ago.)

Another reason I decided not to give up is that I bought different shoes.

You can hike most trails in regular sneakers in almost any condition. But since Precipice is a climb and not a hike, I realized my usual worn-out running shoes might not be up for that, as I had slid on them during a lesser climb elsewhere that week.

So while in nearby Bar Harbor, my family ducked into a sporting goods store and looked at hiking shoes for me and my son. I told the sales guy we were going to do Precipice. He raised an eyebrow and said I would of course need something good for that.

When I held the strange shoes in my hand, I looked at the price tag and then looked at my wife, who gave a knowing look back at me that surely meant, “OK, but you do realize that you actually have to climb it if we buy those.” I just nodded.

And we needed those new shoes! My son and I had a few tense moments scrambling where we agreed it was quite good we had them. But all along the way, they felt different, which was what I needed.

This reminds me of when I decided to use Claude Code a few weeks after it came out last March. The tokens cost 10 times what I could get elsewhere. But suddenly I was invested.

It also mattered that Claude Code, as a terminal, was a very different development experience. People back then thought it was strange that I was using a CLI to manage code. It was really different for me too, and all the better: I was no longer screwing around with code suggestions in GitHub Copilot.

This is a lesson I have taken to AI:

You must get different equipment.

You should be regularly experimenting with new tools that make you uncomfortable. Just using the new AI features in your existing tool is not enough for continuous growth or paradigm shifts, like the recent one from the CLI to multiple simultaneous agent management.

The last idea I have is to stop thinking about where all of us will end up one day.

Put the summit out of your mind.

While climbing Precipice, I decided to only think of what was in front of me. I knew it was a lot higher than Beehive. I just kept doing one more tough piece of it.

The advantage of doing this was near the top. Because the scariest piece was something I didn’t notice from online trail photos.

You can get an idea of what I’m talking about from this photo from Watson’s World, which I had not seen before I got up there. It shows a long cliff with a very short ledge (much shorter than it looks at this angle). Even the picture doesn’t make it clear just how exposed you are and that there is nothing behind you but a long, deadly fall. The bottom bars are to prevent your feet from slipping off.

When I came to it, I thought, “No…way.”

But there was no turning back by then. I had come so far! I looked up and saw the summit was just above this last traverse. So I just held onto the bars, held onto my breath, and moved carefully along the cliff right behind my son, who was suddenly more cautious.

Had I known that was up there, I might not have climbed the mountain. Good thing I didn’t know.

As for the future of software, I don’t know what lies further up the mountain we are on. There are probably some very strenuous and scary moments ahead. But we shouldn’t be worrying about them now.

We should just keep climbing.

Imagine you deploy an autonomous AI agent to production. Day one is a success: The demos are fantastic; the reasoning is sharp. But before handing over real authority, uncomfortable questions emerge.

What happens when the agent misinterprets a locale-specific decimal separator, turning a position of 15.500 ETH (15 and a half) into an order for 15,500 ETH (15 thousand) on leverage? What if a dropped connection leaves it looping on stale state, draining your LLM request quota in minutes?

What if it makes a perfect decision, but the market moves just before execution? What if it hallucinates a parameter like force_execution=True—do you sanitize it or crash downstream? And can it reliably ignore a prompt injection buried in a web page?

Finally, if an API call times out without acknowledgment, do you retry and risk duplicating a $50K transaction, or drop it?

When these scenarios occur, megabytes of prompt logs won’t explain the failure. And adding “please be careful” to the system prompt acts as a superstition, not an engineering control.

Why a smarter model is not the answer

I encountered these failure modes firsthand while building an autonomous system for live financial markets. It became clear that these were not model failures but execution boundary failures. While RL-based fine-tuning can improve reasoning quality, it cannot solve infrastructure realities like network timeouts, race conditions, or dropped connections.

The real issues are architectural gaps: contract violations, data integrity issues, context staleness, decision-execution gaps, and network unreliability.

These are infrastructure problems, not intelligence problems.

While LLMs excel at orchestration, they lack the “kernel boundary” needed to enforce state integrity, idempotency, and transactional safety where decisions meet the real world.

An architectural pattern: The Decision Intelligence Runtime

Consider modern operating system design. OS architectures separate “user space” (unprivileged computation) from “kernel space” (privileged state modification). Processes in user space can perform complex operations and request actions but cannot directly modify system state. The kernel validates every request deterministically before allowing side effects.

AI agents need the same structure. The agent interprets context and proposes intent, but the actual execution requires a privileged deterministic boundary. This layer, the Decision Intelligence Runtime (DIR), separates probabilistic reasoning from real-world execution.

The runtime sits between agent reasoning and external APIs, maintaining a context store, a centralized, immutable record ensuring the runtime holds the “single source of truth,” while agents operate only on temporary snapshots. It receives proposed intents, validates them against hard engineering rules, and handles execution. Ideally, an agent should never directly manage API credentials or “own” the connection to the external world, even for read-only access. Instead, the runtime should act as a proxy, providing the agent with an immutable context snapshot while keeping the actual keys in the privileged kernel space.

Bringing engineering rigor to probabilistic AI requires implementing five familiar architectural pillars.

Although several examples in this article use a trading simulation for concreteness, the same structure applies to healthcare workflows, logistics orchestration, and industrial control systems.

DIR versus existing approaches

The landscape of agent guardrails has expanded rapidly. Frameworks like LangChain and LangGraph operate in user space, focusing on reasoning orchestration, while tools like Anthropic’s Constitutional AI and Pydantic schemas validate outputs at inference time. DIR, by contrast, operates at the execution boundary, the kernel space, enforcing contracts, business logic, and audit trails after reasoning is complete.

Both are complementary. DIR is intended as a safety layer for mission-critical systems.

1. Policy as a claim, not a fact

In a secure system, external input is never trusted by default. The output of an AI agent is exactly that: external input. The proposed architecture treats the agent not as a trusted administrator, but as an untrusted user submitting a form. Its output is structured as a policy proposal—a claim that it wants to perform an action, not an order that it will perform it. This is the start of a Zero Trust approach to agentic actions.

Here is an example of a policy proposal from a trading agent:

proposal = PolicyProposal(
    dfid="550e8400-e29b-41d4-a716-446655440000", # Trace ID (see Sec 5)
    agent_id="crypto_position_manager_01",
    policy_kind="TAKE_PROFIT",
    params={
        "instrument": "ETH-USD",
        "quantity": 0.5,
        "execution_type": "MARKET"
    },
    reasoning="Profit target of +3.2% hit (Threshold: 3.0%). Market momentum slowing.",
    confidence_score=0.92
)

2. Responsibility contract as code

Prompts are not permissions. Just as traditional apps rely on role-based access control, agents require a strict responsibility contract residing in the deterministic runtime. This layer acts as a firewall, validating every proposal against hard engineering rules: schema, parameters, and risk limits. Crucially, this check is deterministic code, not another LLM asking, “Is this dangerous?” Whether the agent hallucinates a capability or obeys a malicious prompt injection, the runtime simply enforces the contract and rejects the invalid request.

Real-world example: A trading agent misreads a comma-separated value and attempts to execute place_order(symbol='ETH-USD', quantity=15500). This would be a catastrophic position sizing error. The contract rejects it immediately:

ERROR: Policy rejected. Proposed order value exceeds hard limit.
Request: ~40000000 USD (15500 ETH)
Limit: 50000 USD (max_order_size_usd)

The agent’s output is discarded; the human is notified. No API call, no cascading market impact.

Here is the contract that prevented this:

# agent_contract.yaml
agent_id: "crypto_position_manager_01"
role: "EXECUTOR"
mission: "Manage news-triggered ETH positions. Protect capital while seeking alpha."
version: "1.2.0"                  # Immutable versioning for audit trails
owner: "jane.doe@example.com"     # Human accountability
effective_from: "2026-02-01"

# Deterministic Boundaries (The 'Kernel Space' rules)
permissions:
  allowed_instruments: ["ETH-USD", "BTC-USD"]
  allowed_policy_types: ["TAKE_PROFIT", "CLOSE_POSITION", "REDUCE_SIZE", "HOLD"]
  max_order_size_usd: 50000.00

# Safety & Economic Triggers (Intervention Logic)
safety_rules:
  min_confidence_threshold: 0.85      # Don't act on low-certainty reasoning
  max_drawdown_limit_pct: 4.0         # Hard stop-loss enforced by Runtime
  wake_up_threshold_pnl_pct: 2.5      # Cost optimization: ignore noise
  escalate_on_uncertainty: 0.70       # If confidence < 70%, ask human

3. JIT (just-in-time) state verification

This mechanism addresses the classic race condition where the world changes between the moment you check it and the moment you act on it. When an agent begins reasoning, the runtime binds its process to a specific context snapshot. Because LLM inference takes time, the world will likely change before the decision is ready. Right before executing the API call, the runtime performs a JIT verification, comparing the live environment against the original snapshot. If the environment has shifted beyond a predefined drift envelope, the runtime aborts the execution.

The drift envelope is configurable per context field, allowing fine-grained control over what constitutes an acceptable change:

# jit_verification.yaml
jit_verification:
  enabled: true
  
  # Maximum allowed drift per field before aborting execution
  drift_envelope:
    price_pct: 2.0           # Abort if price moved > 2%
    volume_pct: 15.0         # Abort if volume changed > 15%
    position_state: strict   # Any change = abort
  
  # Snapshot expiration
  max_context_age_seconds: 30
  
  # On drift detection
  on_drift_exceeded:
    action: "ABORT"
    notify: ["ops-channel"]
    retry_with_fresh_context: true

4. Idempotency and transactional rollback

This mechanism is designed to mitigate execution chaos and infinite retry loops. Before making any external API call, the runtime hashes the deterministic decision parameters into a unique idempotency key. If a network connection drops or an agent gets confused and attempts to execute the exact same action multiple times, the runtime catches the duplicate key at the boundary.

The key is computed as:

IdempotencyKey = SHA256(DFID + StepID + CanonicalParams)

Where DFID is the Decision Flow ID, StepID identifies the specific action within a multistep workflow, and CanonicalParams is a sorted representation of the action parameters.

Critically, the context hash (snapshot of the world state) is deliberately excluded from this key. If an agent decides to buy 10 ETH and the network fails, it might retry 10 seconds later. By then, the market price (context) has changed. If we included the context in the hash, the retry would generate a new key (SHA256(Action + NewContext)), bypassing the idempotency check and causing a duplicate order. By locking the key to the Flow ID and Intent params only, we ensure that a retry of the same logical decision is recognized as a duplicate, even if the world around it has shifted slightly.

Furthermore, when an agent makes a multistep decision, the runtime tracks each step. If one step fails, it knows how to perform a compensation transaction to roll back what was already done, instead of hoping the agent will figure it out on the fly.

A DIR does not magically provide strong consistency; it makes the consistency model explicit: where you require atomicity, where you rely on compensating transactions, and where eventual consistency is acceptable.

5. DFID: From observability to reconstruction

Distributed tracing is not a new idea. The practical gap in many agentic systems is that traces rarely capture the artifacts that matter at the execution boundary: the exact context snapshot, the contract/schema version, the validation outcome, the idempotency key, and the external receipt.

The Decision Flow ID (DFID) is intended as a reconstruction primitive—one correlation key that binds the minimum evidence needed to answer critical operational questions:

• Why did the system execute this action? (policy proposal + validation receipt + contract/schema version)
• Was the decision stale at execution time? (context snapshot + JIT drift report)
• Did the system retry safely or duplicate the side effect? (idempotency key + attempt log + external acknowledgment)
• Which authority allowed it? (agent identity + registry/contract snapshot)

In practice, this turns a postmortem from “the agent traded” into “this exact intent was accepted under these deterministic gates against this exact snapshot, and produced this external receipt.” The goal is not to claim perfect correctness; it is to make side effects explainable at the level of inputs and gates, even when the reasoning remains probabilistic.

At the hierarchical level, DFIDs form parent-child relationships. A strategic intent spawns multiple child flows. When multistep workflows fail, you reconstruct not just the failing step but the parent mandate that authorized it.

In practice, this level of traceability is not about storing prompts—it is about storing structured decision telemetry.

In one trading simulation, each position generated a decision flow that could be queried like any other system artifact. This allowed inspection of the triggering news signal, the agent’s justification, intermediate decisions (such as stop adjustments), the final close action, and the resulting PnL, all tied to a single simulation ID. Instead of replaying conversational history, this approach reconstructed what happened at the level of state transitions and executable intents.

SELECT position_id
     , instrument
     , entry_price
     , initial_exposure
     , news_full_headline
     , news_score
     , news_justification
     , decisions_timeline
     , close_price
     , close_reason
     , pnl_percent
     , pnl_usd
  FROM position_audit_agg_v
 WHERE simulation_id = 'sim_2026-02-24T11-20-18-516762+00-00_0dc07774';

This approach is fundamentally different from prompt logging. The agent’s reasoning becomes one field among many—not the system of record. The system of record is the validated decision and its deterministic execution boundary.

From model-centric to execution-centric AI

The industry is shifting from model-centric AI, measuring success by reasoning quality alone, to execution-centric AI, where reliability and operational safety are first-class concerns.

This shift comes with trade-offs. Implementing deterministic control requires higher latency, reduced throughput, and stricter schema discipline. For simple summarization tasks, this overhead is unjustified. But for systems that move capital or control infrastructure, where a single failure outweighs any efficiency gain, these are acceptable costs. A duplicate $50K order is far more expensive than a 200 ms validation check.

This architecture is not a single software package. Much like how Model-View-Controller (MVC) is a pervasive pattern without being a single importable library, DIR is a set of engineering principles: separation of concerns, zero trust, and state determinism, applied to probabilistic agents. Treating agents as untrusted processes is not about limiting their intelligence; it is about providing the safety scaffolding required to use that intelligence in production.

As agents gain direct access to capital and infrastructure, a runtime layer will become as standard in the AI stack as a transaction manager is in banking. The question is not whether such a layer is necessary but how we choose to design it.

This article provides a high-level introduction to the Decision Intelligence Runtime and its approach to production resiliency and operational challenges. The full architectural specification, repository of context patterns, and reference implementations are available as an open source project at GitHub.

The following article originally appeared on Q McCallum’s blog and is being republished here with the author’s permission.

Generative AI agents and rogue traders pose similar insider threats to their employers.

Specifically, we can expect companies to deploy agentic AI with broad reach and insufficient oversight. That creates the conditions for a particular flavor of long-running problem, which in turn creates a novel risk exposure for both the companies in question and for anyone doing business with them. The bot and the rogue trader are able to inflict sizable, sometimes existential, damage to the firms that employ them.

The key difference is the scope: Rogue traders operate in investment banks, while agentic AI will be deployed to a wider array of companies and industry verticals. Agentic AI may therefore create a greater number of problems than rogue traders and put a greater amount of capital at risk.

I’m naming this risk exposure ROT—Rogue Operator Threat—and this document is a brief explainer on what it is and how to address it.

(I almost called it RAT, with the A for “agentic,” but then realized that it would apply to any kind of automated system. So I broadened the scope to “operator.”)

To set the stage, let’s take a trip to the trading floor:

Understanding the rogue trader

Rogue trader scandals follow the same storyline:

• A trader accrues losses due to bad trades.
• They hide those losses while placing new trades in an attempt to recover.
• The new trades also lose money, digging a deeper hole.
• Repeat.

This cycle continues until they’re caught, at which point the bank is sitting on a large loss (sometimes into the billions of dollars) and the trader faces legal repercussions.

The story of Barings Bank offers a concrete example. Trader Nick Leeson had been logging fraudulent trades, over a stretch of three years, in an attempt to cover his mounting losses. This only came to light when the Kobe earthquake shifted markets against his most recent positions and the losses were no longer possible to hide. Leeson’s £800M ($1.3B) hole drove Barings to bankruptcy just three days later.

This is when you’ll ask: How could a professional trading operation let so many bad trades slip through undetected? How could a trader falsify records? Aren’t trading floors high-tech operations, full of electronic audit trails?

And the answer is: It’s complicated.

Trading operations do keep records, yes. But no system is perfect. Each time a rogue trading scandal comes to light, it turns out that there were loopholes in risk controls. A sufficiently motivated trader—especially one desperate to hide their mistakes—found and exploited these loopholes, continuing their losing streak in plain sight until they could bring in real money to backfill the fake records.

That “until” never happened, though. Which is why their employers then faced financial, reputational, and sometimes legal troubles.

The AI agent’s ROT threat

Similar to a trader, an AI agent operates on behalf of its parent business and is given room to operate independently so it can accomplish its tasks.

The risk is that, in the rush to deploy agentic AI, these companies will likely grant the bots more leeway than is necessary. We’ve already seen cases in which bots have been able to delete emails and wipe a production database. And there are no doubt other stories that haven’t made it into the news.

Those issues were at least caught in real time. Companies facing ROT are exposed to additional longer-running problems in which the bot is able to accrue losses or inflict greater damage over an extended period. In those cases the problems will only be uncovered by accident and/or when it’s too late.

Consider, for example, an agent that creates false data records to reflect (nonexistent) sales orders. It’s possible for this to run until some external event, such as investor due diligence or a budget review, forces someone to double-check those records against reality.

Avoiding ROT: Mitigating the threat

How can you narrow your downside risk exposure to ROT? Preventative measures are key. Strong risk controls, narrow scope of authority, and monitoring can catch rogue operator problems long before they’ve metastasized into an existential threat.

In light of rogue trader scandals, trading shops have been known to tighten risk controls and also separate duties to create a system of checks and balances. (This inhibits traders from logging their own fake trades.) Companies also require traders to take time off, as fraudulent activity may surface when the perpetrator isn’t around every day to keep the system running.

Adapting these ideas to agentic AI, a company could monitor and limit the scope of the bot’s activity (say, requiring human approval to place more than 10 orders an hour). It could also periodically purge the agent’s memory so it doesn’t accumulate too many evolved behaviors, or swap in completely new bots to pick up where the previous one had left off. And per my usual refrain of “never let the bots run unattended,” this company could employ people to cross-check everything the bot does. Trust, but verify.

This will not prevent the AI agent from making mistakes. But guardrails and sufficiently frequent checks should limit the scope of the bot’s damage. As with the rogue trader, the ROT problem isn’t about a single error; it’s about letting the errors grow out of control, undetected.

The following article originally appeared on Hugo Bowne-Anderson’s newsletter, Vanishing Gradients, and is being republished here with the author’s permission.

In this post, we’ll build two AI agents from scratch in Python. One will be a coding agent, the other a search agent.

Why have I called this post “How to Build a General-Purpose AI Agent in 131 Lines of Python” then? Well, as it turns out now, coding agents are actually general-purpose agents in some quite surprising ways.

What I mean by this is once you have an agent that can write code, it can:

1. Do a huge number of things you don’t often think of as involving code, and
2. Extend itself to do even more things.

It’s more appropriate to think of coding agents as “computer-using agents” that happen to be great at writing code. That doesn’t mean you should always build a general-purpose agent, but it’s worth understanding what you’re actually building when you give an LLM shell access. That’s also why we’ll build a search agent in this post: to show the pattern works regardless of what you’re building.

For example, the coding agent we’ll build below has four tools: read, write, edit, and bash.

Watch this two-minute video to see how it can clean your desktop and why you should think of coding agents as “computer-using agents” that happen to be great at writing code:

It can do

• File/life organization: Clean your desktop, sort downloads by type, rename vacation photos with dates, find and delete duplicates, organize receipts into folders. . .
• Personal productivity: Search all your notes for something you half-remember, compile a packing list from past trips, find all PDFs containing “tax” from last year. . .
• Media management: Rename a season of TV episodes properly, convert images to different formats, extract audio from videos, resize photos for social media. . .
• Writing and content: Combine multiple docs into one, convert between formats, find-and-replace across many files. . .
• Data wrangling: Turn a messy CSV into a clean address book, extract emails from a pile of files, merge spreadsheets from different sources. . .

This is a small subset of what’s possible. It’s also the reason Claude Cowork seemed promising and why OpenClaw has taken off in the way it did.

So how can you build this? In this post, I’ll show you how to build a minimal version.

Agents are just LLMs with tools in a loop

Agents are just LLMs with tools in a conversation loop and once you know the pattern, you’ll be able to build all types of agents with it:

As Ivan Leo wrote,

The barrier to entry is remarkably low: 30 minutes and you have an AI that can understand your codebase and make edits just by talking to it.

The goal here is to show that the pattern is the same regardless of what you’re building an agent for. Coding agent, search agent, browser agent, email agent, database agent: they all follow the same structure. The only difference is the tools you give them.

Part 1: The coding agent

We’ll start with a coding agent that can read, write, and execute code. As stated, the ability to write and execute code with bash also turns a “coding agent” into a “general-purpose agent.” With shell access, it can do anything you can do from a terminal:

• Sort and organize your local filesystem
• Clean up your desktop
• Batch rename photos
• Convert file formats
• Manage Git repos across multiple projects
• Install and configure software

You can find the code here.

Check out Ivan Leo’s post for how to do this in JavaScript and Thorsten Ball’s post for how to do it in Go.

Setup

Start by creating our project:

We’ll be using Anthropic here. Feel free to use your LLM of choice. For bonus points, use Pydantic AI (or a similar library) and have a consistent interface for the various different LLM providers. That way you can use the same agentic framework for both Claude and Gemini!

Make sure you’ve got an Anthropic API key set as ANTHROPIC_API_KEY environment variable.

We’ll build our agent in four steps:

1. Hook up our LLM
2. Add a tool that reads files
   1. Add more tools: write, edit, and bash
3. Build the agentic loop
4. Build the conversational loop

1. Hook up our LLM

Text in, text out. Good! Now let’s give it a tool.

2. Add a tool (read)

We’ll start by implementing a tool called read which will allow the agent to read files from the filesystem. In Python, we can use Pydantic for schema validation, which also generates JSON schemas we can provide to the API:

The Pydantic model gives us two things: validation and a JSON schema. We can see what the schema looks like:

We wrap this into a tool definition that Claude understands:

Then we add tools to the API call, handle the tool request, execute it, and send the result back:

Let’s see what happens when we run it:

This script calls the Claude API with a user query passed via command line. It sends the query, gets a response, and prints it.

Note that the LLM matched on the tool description: Accurate, specific descriptions are key! It’s also worth mentioning that we’ve made two LLM calls here:

• One in which the tool is called
• A second in which we send the result of the tool call back to the LLM to get the final result

This often trips up people building agents for the first time, and Google has made a nice visualization of what we’re actually doing:

2a. Add more tools (write, edit, bash)

We have a read tool, but a coding agent needs to do more than read. It needs to:

• Write new files
• Edit existing ones
• Execute code to test it

That’s three more tools: write, edit, and bash.

Same pattern as read. First the schemas:

Then the executors:

And the tool definitions, along with the code that runs whichever one Claude picks:

The bash tool is what makes this actually useful: Claude can now write code, run it, see errors, and fix them. But it’s also dangerous. This tool could delete your entire filesystem! Proceed with caution: Run it in a sandbox, a container, or a VM.

Interestingly, bash is what turns a “coding agent” into a “general-purpose agent.” With shell access, it can do anything you can do from a terminal:

• Sort and organize your local filesystem
• Clean up your desktop
• Batch rename photos
• Convert file formats
• Manage Git repos across multiple projects
• Install and configure software

It was actually “Pi: The Minimal Agent Within OpenClaw” that inspired this example.

Try asking Claude to edit a file: It often wants to read it first to see what’s there. But our current code only handles one tool call. That’s where the agentic loop comes in.

3. Build the agentic loop

Right now Claude can only call one tool per request. But real tasks need multiple steps: read a file, edit it, run it, see the error, fix it. We need a loop that lets Claude keep calling tools until it’s done.

We wrap the tool handling in a while True loop:

Note that here we have sent the entire past history of accumulated messages as we progress through loop iterations. When building this out more, you’ll want to engineer and manage your context more effectively. (See below for more on this.)

Let’s try a multistep task:

4. Build the conversational loop

Right now the agent handles one query and exits. But we want a back-and-forth conversation: Ask a question, get an answer, ask a follow-up. We need an outer loop that keeps asking for input.

We wrap everything in a while True:

The messages list persists across turns, so Claude remembers context. That’s the complete coding agent.

Once again we’re merely appending all previous messages, which means the context will grow quite quickly!

A note on agent harnesses

An agent harness is the scaffolding and infrastructure that wraps around an LLM to turn it into an agent. It handles:

• The loop: prompting the model, parsing its output, executing tools, feeding results back
• Tool execution: actually running the code/commands the model asks for
• Context management: what goes in the prompt, token limits, history
• Safety/guardrails: confirmation prompts, sandboxing, disallowed actions
• State: keeping track of the conversation, files touched, etc.

And more.

Think of it like this: The LLM is the brain; the harness is everything else that lets it actually do things.

What we’ve built above is the hello world of agent harnesses. It covers the loop, tool execution, and basic context management. What it doesn’t have: safety guardrails, token limits, persistence, or even a system prompt!

When building out from this basis, I encourage you to follow the paths of:

• The Pi coding agent, which adds context loading AGENTS.md from multiple directories, persistent sessions you can resume and branch, and an extensibility system (skills, extensions, prompts)
• OpenClaw, which goes further: a persistent daemon (always-on, not invoked), chat as the interface (Telegram, WhatsApp, etc.), file-based continuity (SOUL.md, MEMORY.md, daily logs), proactive behavior (heartbeats, cron), preintegrated tools (browser, subagents, device control), and the ability to message you without being prompted

Part 2: The search agent

In order to really show you that the agentic loop is what powers any agent, we’ll now build a search agent (inspired by a podcast I did with search legends John Berryman and Doug Turnbull). We’ll use Gemini for the LLM and Exa for web search. You can find the code here.

But first, the astute reader may have an interesting question: If a coding agent really is a general-purpose agent, why would anyone want to build a search agent when we could just get a coding agent to extend itself and turn itself into a search agent? Well, because if you want to build a search agent for a business, you’re not going to do it by building a coding agent first… So let’s build it!

Setup

As before, we’ll build this step-by-step. Start by creating our project:

Set GEMINI_API_KEY (from Google AI Studio) and EXA_API_KEY (from exa.ai) as environment variables.

We’ll build our agent in four steps (the same four steps as always):

1. Hook up our LLM
2. Add a tool (web_search)
3. Build the agentic loop
4. Build the conversational loop

1. Hook up our LLM

2. Add a tool (web_search)

Gemini can answer from its training data, but we don’t want that, man! For current information, it needs to search the web. We’ll give it a web_search tool that calls Exa.

The system instruction grounds the model, (ideally) forcing it to search instead of guessing. Note that you can configure Gemini to always use web_search, which is 100% dependable, but I wanted to show the pattern that you can use with any LLM API.

We then send the tool call result back to Gemini:

3. Build the agentic loop

Some questions need multiple searches. “Compare X and Y” requires searching for X, then searching for Y. We need a loop that lets Gemini keep searching until it has enough information.

4. Build the conversational loop

Same as before: We want back-and-forth conversation, not one query and exit. Wrap everything in an outer loop:

Messages persist across turns, so follow-up questions have context.

Extend it

The pattern is the same for both agents. Add any tool:

• web_search to the coding agent: Look things up while coding
• bash to the search agent: Act on what it finds
• browser: Navigate websites
• send_email: Communicate
• database_query: Run SQL

One thing we’ll be doing is showing how general purpose a coding agent really can be. As Armin Ronacher wrote in “Pi: The Minimal Agent Within OpenClaw”:

Pi’s entire idea is that if you want the agent to do something that it doesn’t do yet, you don’t go and download an extension or a skill or something like this. You ask the agent to extend itself. It celebrates the idea of code writing and running code.

Conclusion

Building agents is straightforward. The magic isn’t complex algorithms; it’s the conversation loop and well-designed tools.

Both agents follow the same pattern:

1. Hook up the LLM
2. Add a tool (or multiple tools)
3. Build the agentic loop
4. Build the conversational loop

The only difference is the tools.

Thank you to Ivan Leo, Eleanor Berger, Mike Powers, Thomas Wiecki, and Mike Loukides for providing feedback on drafts of this post.

The following article originally appeared on Wes McKinney’s blog and is being republished here with the author’s permission.

Like a lot of people, I’ve found that AI is terrible for my sleep schedule. In the past I’d wake up briefly at 4:00 or 4:30 in the morning to have a sip of water or use the bathroom; now I have trouble going back to sleep. I could be doing things. Before I would get a solid 7–8 hours a night; now I’m lucky when I get 6. I’ve largely stopped fighting it: Now when I’m rolling around restlessly in bed at 5:07am with ideas to feed my AI coding agents, I just get up and start my day.

Among my inner circle of engineering and data science friends, there is a lot of discussion about how long our competitive edge as humans will last. Will having good ideas (and lots of them) still matter as the agents begin having better ideas themselves? The human-expert-in-the-loop feels essential now to get good results from the agents, but how long will that last until our wildest ideas can be turned into working, tasteful software while we sleep? Will it be a gentle obsolescence where we happily hand off the reins or something else?

For now, I feel needed. I don’t describe the way I work now as “vibe coding” as this sounds like a pejorative “prompt and chill” way of building AI slop software projects. I’ve been building tools like roborev to bring rigor and continuous supervision to my parallel agent sessions, and to heavily scrutinize the work that my agents are doing. With this radical new way of working it is hard not to be contemplative about the future of software engineering.

Probably the book I’ve referenced the most in my career is The Mythical Man-Month by Fred Brooks, whose now-famous Brooks’s law argues that “adding manpower to a late software project makes it later.” Lately I find myself asking whether the lessons from this book are applicable in this new era of agentic development. Will a talented developer orchestrating a swarm of AI agents be able to build complex software faster and better, and will the short-term productivity gains lead to long-term project success? Or will we run into the same bottlenecks—scope creep, architectural drift, and coordination overhead—that have plagued software teams for decades?

Revisiting The Mythical Man-Month (TMMM)

One of Brooks’s central arguments is that small teams of elite people outperform large teams of average ones, with one “chief surgeon” supported by specialists. This leads to a high degree of conceptual integrity about the system design, as if “one mind designed it, even if many people built it.”

Agentic engineering appears to amplify these problems, since the quality of the software being built is now only as good as the humans in the loop curating and refining specs, saying yes or no to features, and taming unnecessary code and architectural complexity. One of the metaphors in TMMM is the “tar pit”: “Everyone can see the beasts struggling in it, and it looks like any one of them could easily free itself, but the tar holds them all together.” Now, we have a new “agentic tar pit” where our parallel Claude Code sessions and git worktrees are engaged in combat with the code bloat and incidental complexity generated by their virtual colleagues. You can systematically refactor, but invariably an agentic codebase will end up larger and more overwrought than anything built by human hand. This is technical debt on an unprecedented scale, accrued at machine speed.

In TMMM, Brooks observed that a working program is maybe 1/9th the way to a programming product, one that has the necessary testing, documentation, and hardening against edge cases and is maintainable by someone other than its author. Agents are now making the “working program” (or “appears-to-work” program, more accurately) a great deal more accessible, though many newly minted AI vibe coders clearly underestimate the work involved with going from prototype to production.

These problems compound when considering the closely-related Conway’s law, which asserts that the architecture of software systems tends to resemble the organizations’ team or communication structure. What does that look like when applied to a virtual “team” of agents with no persistent memory and no shared understanding of the system they are building?

Another “big idea” from TMMM that has stuck with people is the n(n-1)/2 coordination problem as teams scale. With agentic engineering, there are fewer humans involved, so the coordination problem doesn’t disappear but rather changes shape. Different agent sessions may produce contradictory plans that humans have to reconcile. I’ll leave this agent orchestration question for another post.

No silver bullet

“There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.”
—“No Silver Bullet” (1986)

Brooks wrote a follow-up essay to TMMM to look at software design through the lens of essential complexity and accidental complexity. Essential complexity is fundamental to achieving your goal: If you made the system any simpler, it would fall short of its problem statement. Accidental complexity is everything else imposed by our tools and processes: programming languages, tools, and the layer of design and documentation to make the system understandable by engineers.

Coding agents are probably the most powerful tool ever created to tackle accidental complexity. To think: I basically do not write code anymore, and now write tons of code in a language (Go) I have never written by hand. There is a lot of discussion about whether IDEs are still going to be relevant in a year or two, when maybe all we need is a text editor to review diffs. The productivity gains are enormous, and I say this as someone burning north of 10 billion tokens a month across Claude, Codex, and Gemini.

But Brooks’s “No Silver Bullet” argument predicts exactly the problem I’m experiencing in my agentic engineering: The accidental complexity is no problem at all anymore, but what’s left is the essential complexity which was always the hard part. Agents can’t reliably tell the difference. LLMs are extraordinary pattern matchers trained on the entirety of humanity’s open source software, so while they are brilliant at dealing with accidental complexity (refactor this code, write these tests, clean up this mess), they struggle with the more subtle essential design problems, which often have no precedent to pattern match against. They also often tend to introduce unnecessary complexity, generating large amounts of defensive boilerplate that is rarely needed in real-world use.

Put another way, agents are so good at attacking accidental complexity that they generate new accidental complexity that can get in the way of the essential structure that you are trying to build. With a couple of my new projects, roborev and msgvault, I am already dealing with this problem as I begin to reach the 100 KLOC mark and watch the agents begin to chase their own tails and contextually choke on the bloated codebases they have generated. At some point beyond that (the next 100 KLOC, or 200 KLOC) things start to fall apart: Every new change has to hack through the code jungle created by prior agents. Call it a “brownfield barrier.” At Posit we have seen agents struggle much more in 1 million-plus-line codebases such as Positron, a VS Code fork. This seems to support Brooks’s complexity scaling argument.

I would hesitate to place a bet on whether the present is a ceiling or a plateau. The models are clearly getting better fast, and the problems I’m describing here may look charmingly quaint in two years. But Brooks’s essential/accidental distinction gives me some confidence that this isn’t just about the current limitations of the technology. Figuring out what to build was the hard part long before we had LLMs, and I don’t see how a flawless coding agent changes that.

Agentic scope creep

When generating code is free, knowing when to say “no” is your last defense.

With the cost of generating code now converging to zero, there is practically nothing stopping agents and their human taskmasters from pursuing all avenues that would have previously been cost or time prohibitive. The temptation to spend your day prompting “and now can you just…?” is overwhelming. But any new generated feature or subsystem, while cheap to create, is not costless to maintain, test, debug, and reason about in the future. What seems free now carries a future contextual burden for future agent sessions, and each new bell or whistle becomes a new vector of brittleness or bugs that can harm users.

From this perspective, building great software projects maybe never was about how fast you can type the code. We can “type” 10x, maybe 100x faster with agents than we could before. But we still have to make good design decisions, say no to most product ideas, maintain conceptual integrity, and know when something is “done.” Agents are accelerating the “easy part” while paradoxically making the “hard part” potentially even more difficult.

Agentic scope creep also seems to be actively destroying the open source software world. Now that the bar is lower than ever for contributors to jump in and offer help, projects are drowning in torrents of 3,000-line “helpful” PRs that add new features. As developers become increasingly hands-off and disengaged from the design and planning process, the agents’ runaway scope creep can get out of control quickly. When the person submitting a pull request didn’t write or fully read the code in it, there’s likely no one involved who’s truly accountable for the design decisions.

I have seen in my own work on roborev and msgvault that agents will propose overwrought solutions to problems when a simple solution would do just fine. It takes judgment to know when to intervene and how to keep the agent in check.

Design and taste as our last foothold

Brooks’s argument is that design talent and good taste are the most scarce resources, and now with agents doing all of the coding labor, I argue that these skills matter more now than ever. The bottleneck was never hands on keyboards. Now with the new “Mythical Agent-Month,” we can reasonably conclude that design, product scoping, and taste remain the practical constraints on delivering high-quality software. The developers who thrive in this new agentic era won’t be the ones who run the most parallel sessions or burn the most tokens. They’ll be the ones who are able to hold their projects’ conceptual models in their mind, who are shrewd about what to build and what to leave out, and exercise taste over the enormous volume of output.

The Mythical Man-Month was published in 1975, more than 50 years ago. In that time, a lot has happened: tremendous progress in hardware performance, programming languages, development environments, cloud computing, and now large language models. The tools have changed, but the constraints are still the same.

Maybe I’m trying to justify my own continued relevance, but the reality is more complex than that. Not all software is created equal: CRUD business productivity apps aren’t the same as databases and other critical systems software. I think the median software consulting shop is completely toast. But my thesis is more about development work in the 1% tail of the distribution: problems inaccessible to most engineers. This will continue to require expert humans in the loop, even if they aren’t doing much or any manual coding. As one recent adjacent example, my friend Alex Lupsasca at OpenAI and his world-class physicist collaborators were able to create a formulation of a hard physics problem and arrive at a solution with AI’s help. Without such experts in the loop, it’s much more dubious whether LLMs would be able to both pose the questions and come up with the solutions.

For now, I’ll probably still be getting out of bed at 5am to feed and tame my agents for the foreseeable future. The coding is easier now, and honestly more fun, and I can spend my time thinking about what to build rather than wrestling with the tools and systems around the engineering process.

Thanks to Martin Blais, Josh Bloom, Phillip Cloud, Jacques Nadeau, and Dan Shapiro for giving feedback on drafts of this post.

This essay traces our path from disclosures through protocols to markets and mechanism design. Rather than simply stating our conclusions, I’m sharing our thought process and some of the conversations and historical examples that have shaped it.

We will be holding a number of focused convenings to explore these ideas over the next couple of months, and my hope is that shared context will enable more productive engagement with what is very much a work in progress.

The disclosure problem

Ilan Strauss and I started the AI Disclosures Project in early 2024 with a conviction that most regulators had little idea how AI worked or where it was going. The field was so young that many of the early regulatory proposals were misguided. We thought that regulators and industry should start by agreeing on standards for disclosure, so that we could all learn together as the technology develops. You can’t regulate what you don’t understand.

One of our first insights was that focusing solely on model safety was a mistake, much as if regulators inspected automobiles at the factory but completely ignored their use on the roads. We believed (and still do) that the focus should be on AI as deployed. And we believe that disclosures shouldn’t focus just on capabilities but on business models and the operating metrics that AI companies use to shape how their products operate.

Ilan and I had worked together previously with Mariana Mazzucato at University College London on what we called “algorithmic attention rents,” studying how platforms like Amazon and Google control user attention to extract economic rents from their suppliers. We observed that organic search at Google and Amazon was a huge advance in market coordination, using hundreds of signals to find the best match for a user’s intent. In effect, both companies had built a better “invisible hand.” And yet after decades of success, they turned away from that advance. To use Cory Doctorow’s coinage, they began “enshittifying” their services by substituting inferior paid results for the top organic search results in order to pad their bottom line.

We’d also watched social media start out with the promise of keeping you in touch with your friends and foster productive conversations, but then instead began to optimize for engagement at the expense of everything else. By the time anyone understood what was happening, the damage had been done. We can see the inflection point in their financial metrics, but neither regulators nor the public can see the changes in operating metrics that drove the financials. What if we could capture what good looks like before it gets enshittified, and identify how that changes over time?

We also observed that modern technology companies are completely different from industrial era corporations, where you can understand key elements of the business by tracing the inputs and the outputs through the financial statements. Instead, the business is largely driven by intangibles, which are lumped into one impenetrable black box.

We wanted to learn from that mistake. While the horse was already out of the barn on search and social media, we hoped to get disclosure of operating metrics into AI governance while there was still an appetite for regulation. Unfortunately, that window was very short. The failure turned out to be productive, though, because it forced us to think harder about regulation more broadly and what other leverage points might be found.

Protocols as functional disclosures

The first turn in our thinking came when we realized that disclosures aren’t just informational. The most important disclosures are functional. We came to see the parallels between disclosures and communications protocols, the agreed-on methods by which networked systems share information. For example, the HTTP protocol that underlies the World Wide Web specifies how a web browser and web server communicate in order to display a web page.

This is a structured communication with rules that must be followed and data that must be exchanged in a particular order.  An HTTP request that identifies the user agent as a command line program such as curl rather than a graphical browser such as Chrome triggers a different response from the server. The user-agent string isn’t a report filed with a regulator. It’s an operational signal embedded in the protocol, and it carries a lot of information.

Once you see protocols as a system of functional disclosures, you start noticing that every regulatory system has a kind of communications and control protocol at its heart. Generally Accepted Accounting Principles (GAAP) or IFRS, the European equivalent, are protocols for communication between companies and their accountants, auditors, banks, investors, and tax authorities. Even road markings and road signs are a communications protocol, giving information to drivers about local conditions, laws, and the proper use of the road. These are slow, analog protocols, but they are protocols nonetheless.

Protocols can be inspected. Observability is the key to governance. Police observe speeders on the road; credit card processors and banks watch for credit card fraud on their payment networks; email processors filter spam as it passes through nodes on the network. The observability points for AI are still emerging, but that’s where regulators should be focused.

Even beyond being a locus for observability and regulability, protocols themselves do an enormous amount of the governing work in modern technology systems. Spanning everything from how packets get from one place to another to what gets displayed, who has permission to see it, and sometimes even what it costs, they ultimately determine who can interoperate with whom. That led us to an even bigger realization.

Protocols shape markets

Think about the early shape of the AI chatbot market. It was a winner-takes-all race to be the dominant platform for AI in the way Windows became the platform for PCs, or iOS and Android for phones. Whoever wins controls the market. Then Anthropic introduced MCP, the Model Context Protocol. All of a sudden, the landscape looked more like a web. There could be many winners. It didn’t matter what model you were running or whose APIs you were calling as long as you followed the protocol. And as the agentic AI market unfolded, the protocol wasn’t just MCP. An AI agent could be a user of the existing internet protocol stacks. Whether MCP itself survives or is superseded by other protocols, the shape of the market was transformed.

This insight reframed our whole project. Protocols are not just technical infrastructure. They are market-shaping mechanisms.

Workflows are also protocols

I talked last week with some of the folks working on the Long Now Foundation’s partnership with Ethereum’s Summer of Protocols project, and that widened my lens even further.

When software people hear “protocol,” we think of communication protocols: TCP/IP, HTTP, MCP, or, say, Stripe’s Machine Payment Protocol (MPP).

To the Long Now folks, a protocol is any standardized way of doing something. Wildfire management teams follow protocols. So do flood response teams, hospital emergency rooms, and air traffic controllers. Atul Gawande’s book The Checklist Manifesto was an attempt to establish a common protocol for surgical operating theaters. This is a very different definition of protocol, and yet putting the two meanings of the word into the same frame makes a new kind of sense.

In his introduction to the Summer of Protocols’ Protocol Reader, Venkatesh Rao cited Ethereum researcher Danny Ryan’s definition of a protocol as a “stratum of codified behavior” enabling coordination. He pointed out that protocols tend to become invisible once adopted. Rao calls this a “Whitehead advance,” after the philosopher Alfred North Whitehead’s observation that civilization advances by extending what we can do without thinking.

But he also made the thought-provoking point that a protocol is an “engineered argument,” in contrast with an API, which he says is an “engineered agreement” enforced by one dominant actor. There’s more to it than just the power asymmetry of enforced agreement, though. In a followup conversation, Venkatesh Rao noted that protocols are “not just codified modes of information exchange, but modes of live, structured, argumentation, often with an active computational element. For example, CSMA/CD (Ethernet) must detect packet collisions and compute and execute a random delay for retransmittal of packets. This is not mere structured communication. This is argumentation with what philosophers call dynamic semantics.”

Rao continued: “The moment you go beyond computing protocols, real-world feedback loops from material consequences become really important. For example, container-shipping is quite close architecturally to TCP/IP (the big difference being that packets can be dropped and retransmitted while lost containers are actually lost), but because it has a materially embodied feedback loop, regulatory mechanisms start to behave more like control systems than communication systems.”

I love the idea of protocols as an engineered argument. The dynamism this suggests is going to be ever more true in a future of agentic protocols. But this notion also triggered another thought, which is that markets are also engineered arguments. My bridge to this reformulation was the difference between de jure protocols that arise from a formal standards process, and de facto protocols that arise through market contention.

In the early days of the internet, the Internet Engineering Task Force (IETF) was all about engineered arguments. People had ideas about how the internet ought to work, and to prove their point they had to show up with interoperable implementations. No one had the ability to enforce anything. Agreement had to evolve. As Dave Clark famously put it, “We reject: kings, presidents, and voting. We believe in: rough consensus and running code.” The de facto protocols of the internet that emerged from the IETF ended up significantly outperforming the competing de jure networking protocols that emerged from telecommunications standards bodies. The IETF framed the argument; whoever showed up made their case and won or lost by way of adoption.

It also made me remember another decades old story that I had lived through. Microsoft and Netscape were duking it out in the web server market and were building their own “engineered agreements” for what was up the stack from the base web server functionality. Everyone thought that Apache wasn’t keeping up, but they had a trump card. They provided an extension layer. And that engineered all kinds of productive arguments between a market of competing developers rather than a single engineered agreement imposed by either a dominant player OR a dominant committee.

Rao also noted that protocols spread slowly but become nearly impossible to dislodge once established. For example, SMTP (the protocol for email) dates back to 1982, and has outlasted many competitors. There is a lot of path dependence. And so getting the first steps right is an important part of engineering the argument.

And in his essay “Standards Make the World” for the Summer of Protocols project, David Lang makes the point that technical standards form a third pillar of modern society, alongside private organizations and public institutions. They aren’t the state and they aren’t the market, but they’re essential to both. When they work well, standards become enabling technologies. The internet. The shipping container. Standard time. They are civilizational infrastructure.

In short, we are not just building communication protocols for software agents. We are developing a new way to standardize the best practices and workflows that will shape the human + AI future, allowing humans and agents to cooperate across organizations, industries, and borders.

Skills can also be seen as protocols

Once the Long Now team planted in my mind the connection between workflows and protocols, it occurred to me that Agent Skills are also a “stratum of codified behavior,” and perhaps even a set of competing “engineered arguments” for how to do work with AI.

At the simplest level, a Skill is a piece of structured knowledge: here’s how to create a Word document; here’s how to extract the text from a PDF; here’s how to publish on the Hugging Face Hub. There can be many Skills that attempt to codify the same knowledge, but some may be better than others. As Skills multiply, how will we find the best ones? This is in many ways analogous to the organic web search problem, which Google solved by aggregating hundreds of useful signals.

And we’re seeing that there is a kind of hierarchy of skills. Jesse Vincent’s Superpowers framework, which has become one of the most widely adopted open source projects in AI-assisted development, doesn’t just give agents individual capabilities. It encodes an entire software development methodology: brainstorm before you build, plan before you code, test before you ship, review before you merge. That’s a standardized workflow. It’s a lot like the kinds of protocol that the Long Now folks were talking about, expressed in a form that agents can follow.

The existing protocols that the protocol research community talks about, like wildfire management protocols or hospital triage protocols, encode best practices into a repeatable, teachable process for human teams. They have yet to be adapted for agents. And in fact, many of them are never going to be entirely agentic. We will need to build mechanisms for workflows that include both AI agents and humans working together.

Agent skills in some (but not all) areas raise the same questions that industrial standards have always raised: who decides what the best practice is? How do you verify quality? How do you govern updates? We may be talking about skills that encode the workflow for regulatory compliance in a specific industry, or for conducting an environmental impact assessment, or for managing a clinical trial. Are the standards de jure or de facto, the result of an engineered agreement by a committee or an engineered argument that enables a vibrant market?

At O’Reilly, this is something we think about a lot. We’re a company built on codifying expert knowledge. We’ve published books and organized conferences and online training that taught people how to do new things. Now we’re asking “What does it look like to publish the skills that teach agents how to do things? And how do we make sure those skills are discoverable, trustworthy, and monetizable, not just for us but for every domain expert who has knowledge worth encoding?” And how do they emerge from contention in a vibrant market rather than by decree?

We believe we’ll all be better off with an engineered argument than an engineered agreement. And that brings me to mechanism design.

The missing mechanisms

Economists use the term “mechanism design” to describe the engineering of rules and incentive structures that lead self-interested actors to produce outcomes that are good for everyone. It’s sometimes called “reverse game theory.” Rather than analyzing the equilibria that emerge from a given set of rules, you start with the outcome you want and work backward to design the rules that will get you there.

Mechanism design theory got its start in the 1960s when Leonid Hurwicz took up the problem of how a planner can make good decisions when the information needed to make them is scattered among many different people, each of whom has their own interests. His key insight was that people won’t reliably reveal what they know unless it’s in their interest to do so. So how do you design a system that aligns their incentives?

The field that Hurwicz founded and that Eric Maskin and Roger Myerson developed through the 1970s and 80s earned all three the Nobel Prize in Economics in 2007.

I first encountered the field when Jonathan Hall, at the time the Chief Economist at Uber, waved Al Roth’s book Who Gets What — and Why at me and said “This is my Bible.” In it, Roth describes his own work on mechanism design, which won him the 2012 Nobel Prize in Economics along with Lloyd Shapley. Roth applied mechanism design to kidney matching markets, markets for college admissions, for law clerks and judges, and for hospitals and medical residents. When I first talked to Jonathan and then Al Roth, my layman’s takeaway about mechanism design was that it was simply the application of economic theory to design better markets.

And I’ve since come to think even more broadly about what mechanism design might mean in a technology context. In my broader framing, packet switching was a breakthrough in mechanism design. So for that matter was TCP/IP, the World Wide Web, and the protocol-centric architecture of Unix/Linux, which enabled open source and the distributed, cooperative software development environment we take for granted today. PageRank and the rest of Google’s organic search system also seems to me to be a kind of mechanism design. So do Pay Per Click advertising and the Google ad auction. All of them are ways of aligning incentives such that self-interested actors produce outcomes that are good for others as well.

So that brings me back to AI. Right now, there’s a problem that makes the AI/human knowledge market less efficient than it could be. The disrespect for IP that has been shown by the AI labs and applications during the training stage, and even now during inference, has led to efforts by content owners to protect their content from AI. Do not crawl. Lawsuits. Reluctance to share information. Even the AI labs are complaining about the theft of their IP and trying to protect their model weights from distillation.

It’s an economy crying out for mechanism design.

The lesson of YouTube Content ID is worth learning. Twenty-five years ago, the music industry was in the same position that content creators are in today with AI. In response to unauthorized use of their music by creators, music publishers’ demand to YouTube was “Take it down.” But as Google engineer Doug Eck explained to me, YouTube came up with a better answer: “How about we help you monetize it instead?” I don’t know the details of how that decision was made but I do know the eventual outcome. Aligned incentives led to a vibrant creator economy in which YouTube’s video creators, the music companies, and Google all got to share in the value that was created.

That should give us inspiration for how to solve some of the problems we face now with AI. Whether it’s with Agent Skills, NotebookLM, or other emergent artifacts of the new AI/human knowledge economy, we need to align the incentives. If we can grow the pie, and in a way where no single gatekeeper captures the bulk of the benefit, there’s a way to create a vibrant market. But that requires building mechanisms that don’t exist yet.

What mechanisms are missing from the agentic economy? Here’s a partial list:

Skills markets. There’s an enormous economic opportunity for humans to create and trade skills that agents can use. These are not just simple aggregation of context with tool use instructions, but higher-level, industry-specific workflows that encode deep human expertise. At O’Reilly, we’re figuring out how to turn our knowledge and that of our authors into skills, how to make them discoverable, and how to sell them. But as of yet, there’s no way for a broader community of skill creators to participate.

Quality and governance for skills. Some skills will need the same kinds of governance that industrial standards have. Who certifies that a medical skills package follows current clinical guidelines? Who updates it when the guidelines change? We haven’t begun to build the institutions that would govern agent skills at that level.

Registries and discovery. The MCP community has been working on a registry protocol, as is the Ethereum community.

This isn’t just a technical development but a business opportunity. I still remember when Network Solutions was running the original top level internet domain name registry under contract from the National Science Foundation. When the government said it wouldn’t end the payments, Network Solutions planned to walk away. Then they realized what they had. On the early internet, domain name registration became a surprisingly big business. Now it’s just boring civilizational infrastructure. Is there something similar for AI models, applications, and agents?

Organic search for agents. Google’s first great innovation on the web wasn’t how to make pay per click ads really work with a data-driven ad auction. It was organic search: a way of coordinating a market with hundreds of signals that ignored price and worked independently of whether the destination content was free or paid. The New York Times (or oreilly.com) is subscription-based, but that isn’t a factor in whether Google shows it to you. Google figured out signals that let them say, “This is the best result for this query.” Sites behind paywalls figured out how to disclose enough for people to decide whether they wanted to take the next step and enter into a transaction. That’s an engineered argument.

We’re going to need the equivalent for skills and agent services. We’ll start with curated marketplaces. Vercel already has one. But we’re a long way from something as effective as Google’s peak in organic search. The search space will be huge, with hundreds of millions, maybe billions of agents seeking the best way to accomplish trillions of distinct tasks. Skills can help them save on inference costs and deliver better results. The question is what signals will drive discovery of the best match.

Extension architectures. MCP’s extension model (including the new Apps Extension) is promising. This is the Apache model all over again: keep the core simple, let people layer different approaches on top, and let the market sort out which ones win. It is, in essence, an engineered argument rather than an engineered agreement.

Payment layers. Stripe has been working on agentic commerce, but it seems to be focused on traditional e-commerce transactions like booking a ticket or buying a product. What about a payment layer for skills? There have been proposals for monetizing MCP calls, pay per call, pay per token, but none have caught on yet. Coinbase’s x402 protocol may also end up playing a role.

Progressive access and authentication. MCP Server Cards promise to let a service specify its terms: here’s what we charge, here’s how you authenticate. That’s a functional disclosure layer that could enable commerce. It could enable progressive privileges: a free O’Reilly subscriber gets one set of tools, a paying subscriber gets a richer set, all on top of the same MCP server. Again, that’s an engineered argument with the market deciding the winners.

Neutrality in agent routing. When ChatGPT decides to show you a Booking.com widget instead of an Airbnb widget, who made that choice, and on what basis? OpenAI claims commercial considerations aren’t a factor. That’s hard to take at face value. We need something like the original principle of organic search: surface the best result for the user, not the most profitable one for the platform.

We don’t know the future, but we can set ourselves up to shape it for the better

I’m old enough to remember when UUCP was giving way to the internet, and there was a real debate over whether explicit path routing or domain routing was better. In retrospect, it’s blindingly obvious that path routing wasn’t going to scale. But it’s worthwhile to know that at the time, people weren’t at all clear about that!

The same is true now. Some of what I’ve described will turn out to be the equivalent of explicit path routing: a dead end that was only plausible for a small scale network. Other parts will turn out to be as fundamental as DNS or HTTP. But we’re not trying to pick the winners. We’re trying to engineer the argument.

If we can enable better markets, it will allow a process of discovery. People try different things, most fail, some catch on. The job right now is to build the mechanisms that help the market to evolve.

We need mechanisms that no single gatekeeper can control. Modular, decentralized architectures let people experiment with business models, routing decisions, payment systems, and quality signals. And alongside those markets, we will eventually need institutions (some of which will be protocols) to maintain standards that will become the infrastructure of the next economy.

This article recapitulates a conversation with Ilan Strauss and Ido Salomon, and a separate conversation on the broader meaning of protocols in the context of industry workflows and civilizational infrastructure with Venlaktesh Rao and Timber Schroff of the Ethereum Foundation’s Summer of Protocols program, and Denise Hearn and James Home of the Long Now Foundation. Rao’s Protocol Reader and  David Lang’s “Standards Make the World,” published through the Summer of Protocols project, inform the argument about protocols as civilizational infrastructure.

With that in mind, specification-driven development (SDD) shifts the emphasis from review to verification, from prompting to specification, and from testing to still more testing. The goal of software development isn’t code that passes human review; it’s systems whose behavior lives up to a well-defined specification that describes what the customer wants. Finding out what the customer needs and designing an architecture to meet those needs requires human intelligence. As Ankit Jain points out in Latent Space, we need to make the transition from asking whether the code is written correctly to asking whether we’re solving the right problem. Understanding the problem we need to solve is part of the specification process—and it’s something that, historically, our industry hasn’t done well.

Verifying that the system actually performs as intended is another critical part of the software development process. Does it solve the problem as described in the specification? Does it meet the requirements for what Neal Ford calls “architectural characteristics” or “-ilities”: scalability, auditability, performance, and many other characteristics that are embodied in software systems but that can rarely be inferred from looking at the code, and that AI systems can’t yet reason about? These characteristics should be captured in the specification. The focus of the software development process moves from writing code to determining what the code should do and verifying that it indeed does what it’s supposed to do. It moves from the middle of the process to the beginning and the end. AI can play a role along the way, but specification and verification are where human judgment is most important.

Want Radar delivered straight to your inbox? Join us on Substack. Sign up here.

Drew Breunig and others point out that this is inherently a circular process, not a linear one. A specification isn’t something you write at the start of the process and never touch again. It needs to be updated whenever the system’s desired behavior changes: whenever a bug fix results in a new test, whenever users clarify what they want, whenever the developers understand the system’s goals more deeply. I’m impressed with how agile this process is. It is not the agile of sprints and standups but the agile of incremental development. Specification leads to planning, which leads to implementation, which leads to verification. If verification fails, we update the spec and iterate. Drew has built Plumb, a command line tool that can be plugged into Git, to support an automated loop through specification and testing. What distinguishes Plumb is its ability to help software developers look at the decisions that resulted in the current version of the software: diffs, of course, but also conversations with AI, the specifications, the plans, and the tests. As Drew says, Plumb is intended as an inspiration or a starting point, and it’s clearly missing important features—but it’s already useful.

Can SDD replace code review? Probably; again, code review is an expensive way to do something that may not be all that useful in the long run. But maybe that’s the wrong question. If you don’t listen carefully, SDD sounds like a reinvention of the waterfall process: a linear drive from writing a detailed spec to burning thousands of CDs that are stored into a warehouse. We need to listen to SDD itself to ask the right questions: How do we know that a software system solves the right problem? What kinds of tests can verify that the system solves the right problem? When is automated testing inappropriate, and when do we need human engineers to judge a system’s fitness? And how can we express all of that knowledge in a specification that leads a language model to produce working software?

We don’t place as much value in specifications as we did in the last century; we tend to see spec writing as an obsolete ceremony at the start of a project. That’s unfortunate, because we’ve lost a lot of institutional knowledge about how to write good, detailed specifications. The key to making specifications relevant again is realizing that they’re the start of a circular process that continues through verification. The specification is the repository for the project’s real goals: what it’s supposed to do and why—and those goals necessarily change during the course of a project. A software-driven development loop that runs through testing—not just unit testing but fitness testing, acceptance testing, and human judgment about the results—lays the groundwork for a new kind of process in which humans won’t be swamped by reviewing AI-generated code.

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
—Tom Cargill, Bell Labs

One of the experiments I’ve been running as part of my work on agentic engineering and AI-driven development is a blackjack simulation where an LLM plays hundreds of hands against blackjack strategies written in plain English. The AI uses those strategy descriptions to decide how to make hit/stand/double-down decisions for each hand, while deterministic code deals the cards, checks the math, and verifies that the rules were followed correctly.

Early runs of my simulation had a 37% pass rate. The LLM would add up card totals wrong, skip the dealer’s turn entirely, or ignore the strategy it was supposed to follow. The big problem was that these errors compounded: If the model miscounted the player’s total on the third card, every decision after that was based on a wrong number, so the whole hand was garbage even if the rest of the logic was fine.

There’s a useful way to think about reliability problems like that: the March of Nines. Getting an LLM-based system to 90% reliability is the first nine, and it’s the “easy” one. Getting from 90% to 99% takes roughly the same amount of engineering effort. So does getting from 99% to 99.9%. Each nine costs about as much as the last, and you never stop marching. Andrej Karpathy coined the term from his experience building self-driving systems at Tesla, where they spent years earning two or three nines and still had more to go.

Here’s a small exercise that shows how that kind of failure compounding works. Open any AI chatbot running an early 2026 model (I used ChatGPT 5.3 Instant) and paste the following eight prompts one at a time, each in a separate message. Go ahead, I’ll wait.

Prompt 1: Track a running “score” through a 7-step game. Do not use code, Python, or tools. Do this entirely in your head. For each step, I will give you a sentence and a rule.

CRITICAL INSTRUCTION: You must reply with ONLY the mathematical equation showing how you updated the score. Example format: 10 + 5 = 15 or 20 / 2 = 10. Do not list the words you counted, do not explain your reasoning, and do not write any other text. Just the equation.

Start with a score of 10. I’ll give you the first step in the next prompt.

Prompt 2: “The sudden blizzard chilled the small village communities.” Add the number of words containing double letters (two of the exact same letter back-to-back, like ‘tt’ or ‘mm’).

Prompt 3: “The clever engineer needed seven perfect pieces of cheese.” If your score is ODD, add the number of words that contain EXACTLY two ‘e’s. If your score is EVEN, subtract the number of words that contain EXACTLY two ‘e’s. (Do not count words with one, three, or zero ‘e’s).

Prompt 4: “The good sailor joined the eager crew aboard the wooden boat.” If your score is greater than 10, subtract the number of words containing consecutive vowels (two different or identical vowels back-to-back, like ‘ea’, ‘oo’, or ‘oi’). If your score is 10 or less, multiply your score by this number.

Prompt 5: “The quick brown fox jumps over the lazy dog.” Add the number of words where the THIRD letter is a vowel (a, e, i, o, u).

Prompt 6: “Three brave kings stand under black skies.” If your score is an ODD number, subtract the number of words that have exactly 5 letters. If your score is an EVEN number, multiply your score by the number of words that have exactly 5 letters.

Prompt 7: “Look down, you shy owl, go fly away.” Subtract the number of words that contain NONE of these letters: a, e, or i.

Prompt 8: “Green apples fall from tall trees.” If your score is greater than 15, subtract the number of words containing the letter ‘a’. If your score is 15 or less, add the number of words containing the letter ‘l’.

The exercise tracks a running score through seven steps. Each step gives the model a sentence and a counting rule, and the score carries forward. The correct final score is 60. Here’s the answer key: start at 10, then 16 (10+6), 12 (16−4), 5 (12−7), 10 (5+5), 70 (10×7), 63 (70−7), 60 (63−3).

I ran this twice at the same time (using ChatGPT 5.3 Instant), and got two completely different wrong answers the first time I tried it. Neither run reached the correct score of 60:

Step	Correct	Run 1 (transcript)	Run 2 (transcript)
1. Double letters	10 + 6 = 16	10 + 2 = 12	10 + 5 = 15
2. Exactly two ‘e’s	16 − 4 = 12	12 − 4 = 8	15 + 4 = 19
3. Consecutive vowels	12 − 7 = 5	8 × 7 = 56	19 − 5 = 14
4. Third letter vowel	5 + 5 = 10	56 + 5 = 61	14 + 3 = 17
5. Exactly 5 letters	10 × 7 = 70	61 − 7 = 54	17 − 4 = 13
6. No a, e, or i	70 − 7 = 63	54 − 7 = 47	13 − 3 = 10
7. Words with ‘a’ or ‘i’	63 − 3 = 60	47 − 3 = 44	10 + 4 = 14

The two runs tell very different stories. In Run 1, the model miscounted in Step 1 (found 2 double-letter words instead of 6) but actually got the later counts right. It didn’t matter. The wrong score in Step 1 flipped a branch in Step 3, triggering a multiply instead of a subtract, and the score never recovered. One early mistake threw off the entire chain, even though the model was doing good work after that.

Run 2 was a disaster. The model miscounted at almost every step, compounding errors on top of errors. It ended at 14 instead of 60. That’s closer to what Karpathy is describing with the March of Nines: Each step has its own reliability ceiling, and the longer the chain, the higher the chance that at least one step fails and corrupts everything downstream.

What makes this insidious: Both runs look the same from the outside. Each step produced a plausible answer, and both runs produced final results. Without the answer key (or some tedious manual checking), you’d have no way of knowing that Run 1 was a near-miss derailed by a single early error and Run 2 was wrong at nearly every step. This is typical of any process where the output of one LLM call becomes the input for the next one.

These failures don’t demonstrate the March of Nines itself—that’s specifically about the engineering effort to push reliability from 90% to 99% to 99.9%. (It’s possible to reproduce the full compounding-reliability problem in a chat, but a prompt that did it reliably would be far too long to put in an article.) Instead, I opted for a shorter exercise which you can easily try out yourself that demonstrates the underlying problem that makes the march so hard: cascading failures. Each step asks the model to count letters inside words, which is deterministic work that a short Python script handles perfectly. LLMs, on the other hand, don’t actually treat words as strings of characters; they see them as tokens. Spotting double letters means unpacking a token into its characters, and the model gets that wrong just often enough to reliably screw it up. I added branching logic where each step’s result determines the next step’s operation, so a single miscount in Step 1 cascades through the entire sequence.

I also want to be clear about exactly what a deterministic version of this simulation looks like. Luckily, the AI can help us with that. Go to either run (or your own) and paste one more prompt into the chat:

Prompt 9: Now write a short Python script that does exactly what you just did: start with a score of 10, apply each of the seven rules to the seven sentences, and print the equation at each step.

Run the script. It should print the correct answer for every step, ending at 60. The same AI that just failed the exercise can write code that does it flawlessly, because now it’s generating deterministic logic instead of trying to count characters through its tokenizer.

Reproducing a cascading failure in a chat

I deliberately engineered the exercise earlier to give you a way to experience the cascading failure problem behind the March of Nines yourself. I took advantage of something current LLMs genuinely suck at: parsing characters inside tokens. Future models might do a much better job with this specific kind of failure, but the cascading failure problem doesn’t go away when the model gets smarter. As long as LLMs are nondeterministic, any step that relies on them has a reliability ceiling below 100%, and those ceilings still multiply. The specific weakness changes; the math doesn’t.

I also specifically asked the model to show only the equation and skip all intermediate reasoning to prevent it from using chain of thought (or CoT) to self-correct. Chain of thought is a technique where you require the model to show its work step by step (for example, listing the words it counted and explaining why each one qualifies), which helps it catch its own mistakes along the way. CoT is a common way to improve LLM accuracy, and it works. As you’ll see later when I talk about the evolution of my blackjack simulation, CoT cut certain errors roughly in half. But “half as many errors” is still not zero. Plus, it’s expensive: It costs more tokens and more time. A Python script that counts double letters gets the right answer on every run, instantly, for zero AI API costs (or, if you’re running the AI locally, for orders of magnitude less CPU usage). That’s the core tension: You can spend engineering effort making the LLM better at deterministic work, or you can just hand it to code.

Every step in this exercise is deterministic work that code handles flawlessly. But most interesting LLM tasks aren’t like that. You can’t write a deterministic script that plays a hand of blackjack using natural-language strategy rules, or decides how a character should respond in dialogue. Real work requires chaining multiple steps together into a pipeline, or a reproducible series of steps (some deterministic, some requiring an LLM) that lead to a single result, where each step’s output feeds the next. If that sounds like what you just saw in the exercise, it is. Except real pipelines are longer, more complex, and much harder to debug when something goes wrong in the middle.

LLM pipelines are especially susceptible to the March of Nines

I’ve been spending a lot of time thinking about LLM pipelines, and I suspect I’m in the minority. Most people using LLMs are working with single prompts or short conversations. But once you start building multistep workflows where the AI generates structured data that feeds into the next step—whether that’s a content generation pipeline, a data processing chain, or a simulation—you run straight into the March of Nines. Each step has a reliability ceiling, and those ceilings multiply. The exercise you just tried had seven steps. The blackjack pipeline has more, and I’ve been running it hundreds of times per iteration.

That’s a screenshot of the blackjack pipeline in Octobatch, the tool I built to run these pipelines at scale. That pipeline deals cards deterministically, asks the LLM to play each hand following a strategy described in plain English, then validates the results with deterministic code. Octobatch makes it easy to change the pipeline and rerun hundreds of hands, which is how I iterated through eight versions—and how I really learned the hard way that the March of Nines wasn’t just a theoretical problem but something I could watch happening in real time across hundreds of data points.

Running pipelines at scale made the failures obvious and immediate, which, for me, really underscored an effective approach to minimizing the cascading failure problem: make deterministic work deterministic. That means asking whether every step in the pipeline actually needs to be an LLM call. Checking that a jack, a five, and an eight add up to 23 doesn’t require a language model. Neither does looking up whether standing on 15 against a dealer 10 follows basic strategy. That’s arithmetic and a lookup table—work that ordinary code does perfectly every time. And as I learned over the course of improving the failure rate for the pipeline, every step you pull out of the LLM and make deterministic goes to 100% reliability, which stops it from contributing to the compound failure rate.

Relying on the AI for deterministic work is the computation side of a pattern I wrote about for data in “AI, MCP, and the Hidden Costs of Data Hoarding.” Teams dump everything into the AI’s context because the AI can handle it—until it can’t. The same thing happens with computation: Teams let the AI do arithmetic, string matching, or rule evaluation because it mostly works. But “mostly works” is expensive and slow, and a short script does it perfectly. Better yet, the AI can write that script for you—which is exactly what Prompt 9 demonstrated.

Getting cascading failures out of the blackjack pipeline

I pushed the blackjack pipeline through eight iterations, and the results taught me more about earning nines than I expected. That’s why I’m writing this article—the iteration arc turned out to be one of the clearest illustrations I’ve found of how the principle works in practice.

I addressed failures two ways, and the distinction matters.

Some failures called for making work deterministic. Card dealing runs as a local expression step, which doesn’t require an API call, so it’s free, instant, and 100% reproducible. There’s a math verification step that uses code to recalculate totals from the actual cards dealt and compares them against what the LLM reported, and a strategy compliance step checks the player’s first action against a deterministic lookup table. Neither of those steps require any AI to make a judgment call; when I originally ran them as LLM calls, they introduced errors that were hard to detect and expensive to debug.

Other failures called for structural constraints that made specific error patterns harder to produce. Chain of thought format forced the LLM to show its work instead of jumping to conclusions. The rigid dealer output structure made it mechanically difficult to skip the dealer’s turn. Explicit warnings about counterintuitive rules gave the LLM a reason to override its training priors. These don’t eliminate the LLM from the step—they make the LLM more reliable within it.

But before any of that mattered, I had to face the uncomfortable fact that measurements themselves can be wrong, especially when relying on AI to take those measurements. For example, the first run reported a 57% pass rate, which was great! But when I looked at the data myself, a lot of runs were obviously wrong. It turned out that the pipeline had a bug: Verification steps were running, but the AI step that was supposed to enforce didn’t have adequate guardrails, so almost every hand passed regardless of the actual data. I asked three AI advisors to review the pipeline, and none of them caught it. The only thing that exposed it was checking the aggregate numbers, which didn’t add up. If you let probabilistic behavior into a step that should be deterministic, the output will look plausible and the system will report success, but you have no way to know something’s wrong until you go looking for it.

Once I fixed the bug, the real pass rate emerged: 31%. Here’s how the next seven iterations played out:

• Restructuring the data (31% → 37%). The LLM kept losing track of where it was in the deck, so I restructured the data it received to eliminate the bookkeeping. I also removed split hands entirely, because tracking two simultaneous hands is stateful bookkeeping that LLMs reliably botch. Each fix came from looking at what was actually failing and asking whether the LLM needed to be doing that work at all.
• Chain of thought arithmetic (37% → 48%). Instead of letting the LLM jump to a final card total, I required it to show the running math at every step. Forcing the model to trace its own calculations cut multidraw errors roughly in half. CoT is a structural constraint, not a deterministic replacement; it makes the LLM more reliable within the step, but it’s also more expensive because it uses more tokens and takes more time.
• Replacing the LLM validator with deterministic code (48% → 79%). This was the single biggest improvement in the entire arc. The pipeline had a second LLM call that scored how accurately the player followed strategy, and it was wrong 73% of the time. It applied its own blackjack intuitions instead of the rules I’d given it. But there’s a right answer for every situation in basic strategy, and the rules can be written as a lookup table. Replacing the LLM validator with a deterministic expression step recovered over 150 incorrectly rejected hands.
• Rigid output format (79% → 81%). The LLM kept skipping the dealer’s turn entirely, jumping straight to declaring a winner. Requiring a step-by-step dealer output format made it mechanically difficult to skip ahead.
• Overriding the model’s priors (81% → 84%). One strategy required hitting on 18 against a high dealer card, which any conventional blackjack wisdom says is terrible. The LLM refused to do it. Restating the rule didn’t help. Explaining why the counterintuitive rule exists did: The prompt had to tell the model that the bad play was intentional.
• Switching models (84% → 94%). I switched from Gemini Flash 2.0 to Haiku 4.6, which was easy to do because Octobatch lets you run the same pipeline with any model from Gemini, Anthropic, or OpenAI. I finally earned my first nine.

Find the best ways to earn your nines

If you’re building anything where LLM output feeds into the next step, the same question applies to every step in your chain: Does this actually require judgment, or is it deterministic work that ended up in the LLM because the LLM can do it? The strategy validator felt like a judgment call until I looked at what it was actually doing, which was checking a hand against a lookup table. That one recognition was worth more than all the prompt engineering combined. And as Prompt 9 showed, the AI is often the best tool for writing its own deterministic replacement.

I learned this lesson through my own work on the blackjack pipeline. It went through eight iterations, and I think the numbers tell a story. The fixes fell into two categories: making work deterministic (pulling it out of the LLM entirely) and adding structural constraints (making the LLM more reliable within a step). Both earn nines, but pulling work out of the LLM entirely earns those nines faster. The biggest single jump in the whole arc—48% to 79%—came from replacing an LLM validator with a 10-line expression.

Here’s the bottom line for me: If you can write a short function that does the job, don’t give it to the LLM. I initially reached for the LLM for strategy validation because it felt like a judgment call, but once I looked at the data I realized it wasn’t at all. There was a right answer for every hand, and a lookup table found it more reliably than a language model.

At the end of eight iterations, the pipeline passed 94% of hands. The 6% that still fail may be honest limits of what the model can do with multistep arithmetic and state tracking in a single prompt. But they may just be the next nine that I need to earn.

The next article looks at the other side of this problem: Once you know what to make deterministic, how do you make the whole system legible enough that an AI can help your users build with it? The answer turns out to be a kind of documentation you write for AI to read, not humans—and it changes the way you think about what a user manual is for.

According to Wikipedia, the LAMP stack was coined in 1998 by Michael Kunze to describe what had emerged as a popular open source software stack for websites. When the World Wide Web exploded in popularity earlier in the ’90s, organizations used an ad hoc mixture of proprietary tools and operating systems, along with some open source software (OSS), to build websites. The LAMP stack quickly became the most popular set of fully OSS components for this purpose.

LAMP is an acronym that stands for the following:

• Linux – the operating system 
• Apache HTTP Server – the web server
• MySQL – the database
• Perl, PHP, and/or Python – the application programming language

It is hard to believe this today, but at the time, the idea of relying on open source software was controversial. Concerns about support and vulnerability since the source code is visible to everyone were eventually resolved. Open source was irresistible because of the great flexibility, cost efficiencies, no vendor lock-in, and rapid evolution of capabilities provided by popular OSS projects. The LAMP stack became one of t​​he predominant drivers of enterprise adoption of open source.

The PARK stack

Like the rise of the web, the sudden explosion of interest in generative AI with large language models (LLMs), vision models (VMs), and others has driven interest in identifying the best core OSS components for a software stack tailored to the requirements for generative AI. This era now has the PARK stack. It was first suggested by Ben Lorica in “Trends Shaping the Future of AI Infrastructure,” in November last year.

PARK stands for the following:

• PyTorch – for model training and inference
• AI models and agents – the heart of generative AI
• Ray – for fine-grained, very flexible distributed programming
• Kubernetes – the industry-standard cluster management system

Here, I will provide a brief description of each one and the requirements it meets.

PyTorch

The AI stack needed by model builders provides the ability to train and tune models. Application builders need efficient, scalable inference with models and the agents that use them.

PyTorch started as one of many tools for designing and training a variety of machine learning models. It’s now the most popular choice for this purpose. It is used to design and train many of the world’s most prominent generative AI models. Alternatives include JAX and its predecessor, TensorFlow.

PyTorch was developed and open-sourced by Meta. It is now maintained by the PyTorch Foundation. The ecosystem has expanded to include other projects, such as for inference (vLLM), distributed training and inference (DeepSpeed and Ray), and many libraries.

The cost of model inference drives the need for specialized and highly optimized inference engines, like vLLM. So, PyTorch is rarely used alone for inference, although the popular inference engines use PyTorch libraries.

Incidentally, the rise of generative AI has also caused a resurgence in popularity for Python, in part because Python has been the most popular language for data science, of which generative AI is a natural part.

AI models and agents

The unique capabilities of generative AI applications are provided by one or more models and agents that use them. The first wave of AI applications, often simple chatbots, used a single model that had been trained to understand human language very well, especially English, then tuned in various ways to use that language skill more effectively, such as answering questions, avoiding undesirable speech, providing factual output, etc.

Model architecture has rapidly evolved, including making smaller, more capable models and using collections of models (such as the mixture of experts architecture) that provide better efficiency while maintaining result quality.

However, models have some particular shortcomings. For example, they know nothing of events that happened after they were trained and they are not trained on all possible specialist data needed to be effective for every possible domain. Hence, application patterns rapidly emerged to complement the strengths of models. The first pattern was RAG (retrieval-augmented generation), where a repository of data is queried for relevant context information, which is then sent as context with the user query to a model for inference.

The more general approach today is agents, which have been defined this way, “software systems that use AI to pursue goals and complete tasks on behalf of users. They show reasoning, planning, and memory and have a level of autonomy to make decisions, learn, and adapt.” Pursuing user goals can mean finding and retrieving relevant contextual data, evaluating the quality and utility of retrieved information, summarizing findings, gracefully recovering from errors, etc.

There is no one dominant model choice or even “family” of models. Similarly, there is no one agent framework to rule them all. This reflects both the very rapid evolution of models and agent design patterns but also the diversity of possible AI applications, which makes it unlikely that any one choice will meet all needs.

Want Radar delivered straight to your inbox? Join us on Substack. Sign up here.

Ray

Model training, various forms of tuning, and inference of models require different distributed computing patterns that require highly optimized implementations, given the large energy consumption and related costs associated with generative AI. Single GPU systems are too small for these tasks for the largest generative models. Even for smaller models, massive parallelism allows these processes to scale more effectively.

For model training and tuning processes that involve additional training with new data, a massive number of iterations are used, where in each loop, data is passed through the model, and the model parameters (weights) are adjusted incrementally to reduce errors. These iterations must be fast and efficient. When the model parameters are distributed over several GPUs, very high bandwidth exchange of updates is required. Training iterations have large memory footprints and massive data exchanges.

Reinforcement learning is another part of tuning, used to improve more complex behaviors for domains. RL also requires massive amounts of fast iterations, but the size scales and data access patterns are typically smaller, more fine-grained, and more heterogeneous.

Finally, inference distributed computing patterns are the same as the first step in a training iteration, where data flows through a model, but there isn’t a parameter update step.

Ray provides the flexibility for these disparate requirements. It is a fine-grained distributed programming system with an intuitive actor model abstraction. Ray was developed by researchers at the University of California, Berkeley, who needed an efficient and easy-to-use system for scaling up computation required for their reinforcement learning and AI research. The flexibility of Ray’s abstractions and the efficiency of its implementation makes Ray well suited for the new distributed computing requirements generative AI has introduced.

Anyscale is a startup focused on productizing Ray. Ray’s core OSS was recently donated to the PyTorch Foundation, as mentioned above.

Kubernetes

Large scale model training and tuning, as well as scalable application deployment patterns, introduce many practical requirements, including management of clusters of heterogeneous hardware and other resources, as well as the processes running on them. Kubernetes has been the industry standard for cluster management for a decade, emerging from Google’s work on Borg, along with contributions from many other organizations. Kubernetes is part of the Linux Foundation. The main alternatives to Kubernetes are the management tools offered by the cloud vendors, AWS, Microsoft Azure, Google Cloud, and others. The advantage of Kubernetes is that it runs seamlessly on these platforms (offered as a service or you can “roll your own”), as well as on-premises, providing the benefits of the cloud services but without vendor lock-in.

At first glance, it might appear that the distributed capabilities of Ray and Kubernetes overlap, but in fact they are complementary. Ray is for very fine-grained and lightweight distributed computing and memory management, while Kubernetes provides more coarse-grained management and a broad suite of application services required in modern environments (like security, user management, logging and tracing, etc.). It is common for a containerized Ray application to run its own concept of clustered processes within a set of containers in a Kubernetes cluster. Ray and Kubernetes bring complementary strengths. In fact, there is the open source KubeRay operator which allows you to use Ray on Kubernetes without having to be an expert in Ray or container management.

What’s missing from PARK?

LAMP was never intended to provide everything needed for website deployments. It was the core upon which additional services were added as required. PARK is similar, although the presence of Kubernetes covers a lot of the general-purpose service requirements!

For generative AI applications, PARK users will have to think about new requirements, in addition to all the standard practices we have used for years. Let’s discuss a few topics.

Data and data management

Conventional data management requirements and practices still apply, but AI agents are driving changes too. Ben’s post on data engineering for machine users discusses a number of trends. For example, some providers are seeing agents dominate the creation of new database tables and those tables are often ephemeral. Agents are less tolerant of database query problems compared to humans and agents are less careful about security concerns.

Unstructured, multimodal data is growing in importance; video and audio as well as text. Use of specialized forms of structured data is also growing, like knowledge graphs and vector databases for RAG applications, and feature stores for structuring data more effectively.

Agent orchestration

Any distributed system needs careful management of the interactions between components, for purposes of security, resource management, and efficacy. The Model Context Protocol (MCP) and the Agent2Agent Protocol (A2A) are two of several emerging standards to allow models to discover available agent services and learn how to use them automatically. These promising capabilities also raise many concerns about security and the need for careful control, which is driving the emergence of new gateway and service projects tailored to the specific needs of agent-based applications, for example, ContextForge. Similarly, supporting features are being added to established tools to meet the same needs.

Memory management

Agents must manage and use the information they have acquired. This includes working within the available context limitations for their models and focusing on the most useful information, to optimize their use of resources and effectiveness. AI agent memory is an ongoing research topic with projects and startups emerging, like MemVerge and Mem0, which emphasize the effective use of short-term (i.e., single session) memory. Established persistence tools are also being applied to the problem, e.g., Neo4j and Redis, which also support longer-term memory across sessions.

Dex is a new approach that addresses a particular challenge caused by MCP and A2A: the explosion of information that gets added to the inference context memory. This memory is limited and performance quickly degrades when the context grows too large. Dex takes what an agent learns how to do once, like using MCP to learn how to query GitHub for repo information, and turns that knowledge into reusable code that both eliminates unnecessary repetition of the learning step and executes the task deterministically outside the model context. Dex also provides a form of long-term memory.

What’s next?

What are your thoughts about the PARK stack? What do you think of the four components versus alternatives? What AI application requirements do you think need more attention? Let us know!

I’ve been seeing more and more open source maintainers throwing up their hands over AI-generated pull requests. Going so far as to stop accepting PRs from external contributors.

If you’re an open source maintainer, you’ve felt this pain. We all have. It’s frustrating reviewing PRs that not only ignore the project’s coding conventions but also are riddled with AI slop.

But yo, what are we doing?! Closing the door on contributors isn’t the answer. Open source maintainers don’t want to hear this, but this is the way people code now, and you need to do your part to prepare your repo for AI coding assistants.

I’m a maintainer on goose which has more than 300 external contributors. We felt this frustration early on, but instead of pushing well-meaning contributors away, we did the work to help them contribute with AI responsibly.

1. Tell humans how to use AI on your project

We created a HOWTOAI.md file as a straightforward guide for contributors on how to use AI tools responsibly when working on our codebase. It covers things like:

• What AI is good for (boilerplate, tests, docs, refactoring) and what it’s not (security critical code, architectural changes, code you don’t understand)
• The expectation that you are accountable for every line you submit, AI-generated or not
• How to validate AI output before opening a PR: build it, test it, lint it, understand it
• Being transparent about AI usage in your PRs

This welcomes AI PRs but also sets clear expectations. Most contributors want to do the right thing, they just need to know what the right thing is.

And while you’re at it, take a fresh look at your CONTRIBUTING.md too. A lot of the problems people blame on AI are actually problems that always existed, AI just amplified them. Be specific. Don’t just say “follow the code style”; say what the code style is. Don’t just say “add tests”; show what a good test looks like in your project. The better your docs are, the better both humans and AI agents will perform.

2. Tell the agents how to work on your project

Contributors aren’t the only ones who need instructions. The AI agents do too.

We have an AGENTS.md file that AI coding agents can read to understand our project conventions. It includes the project structure, build commands, test commands, linting steps, coding rules, and explicit “never do this” guardrails.

When someone points their AI agent at our repo, the agent picks up these conventions automatically. It knows what to do and how to do it, what not to touch, how the project is structured, and how to run tests to check their work.

You can’t complain that AI-generated PRs don’t follow your conventions if you never told the AI what your conventions are.

3. Use AI to review AI

Investing in an AI code reviewer as the first touchpoint for incoming PRs has been a game changer.

I already know what you’re thinking… They suck too. LOL, fair. But again, you have to guide the AI. We added custom instructions so the AI code reviewer knows what we care about.

We told it our priority areas: security, correctness, architecture patterns. We told it what to skip: style and formatting issues that CI already catches. We told it to only comment when it has high confidence there’s a real issue, not just nitpick for the sake of it.

Now, contributors get feedback before a maintainer ever looks at the PR. They can clean things up on their own. By the time it reaches us, the obvious stuff is already handled.

4. Have good tests

No, seriously. I’ve been telling y’all this for YEARS. Anyone who follows my work knows I’ve been on the test automation soapbox for a long time. And I need everyone to hear me when I say the importance of having a solid test suite has never been higher than it is right now.

Tests are your safety net against bad AI-generated code. Your test suite can catch breaking changes from contributors, human or AI.

Without good test coverage, you’re doing manual review on every PR trying to reason about correctness in your head. That’s not sustainable with five contributors, let alone 50 of them, half of whom are using AI.

5. Automate the boring gatekeeping with CI

Your CI pipeline should also be doing the heavy lifting on quality checks so you don’t have to. Linting, formatting, type checking all should run automatically on every PR.

This isn’t new advice, but it matters more now. When you have clear, automated checks that run on every PR, you create an objective quality bar. The PR either passes or it doesn’t. Doesn’t matter if a human wrote it or an AI wrote it.

For example, in goose, we run a GitHub Action on any PR that involves reusable prompts or AI instructions to ensure they don’t contain prompt injections or anything else that’s sketchy.

Think about what’s unique to your project and see if you can throw some CI checks at it to keep quality high.

I understand the impulse to lock things down, but y’all we can’t give up  on the thing that makes open source special.

Don’t close the door on your projects. Raise the bar, then give people (and their AI tools) the information they need to clear it.

On March 26, join Addy Osmani and Tim O’Reilly at AI Codecon: Software Craftsmanship in the Age of AI, where an all-star lineup of experts will go deeper into orchestration, agent coordination, and the new skills developers need to build excellent software that creates value for all participants. Sign up for free here.