We had been accumulating browser automation tooling across a year of building, and I had never sat down and named what each piece was actually for. They all felt like "browser automation." They are not the same thing at all.

What followed was twenty minutes of forced side-by-side comparison. There are three completely different tools hiding under that label, and they make different tradeoffs on speed, safety, and task shape. Defaulting to the one your framework ships means you're probably using the wrong one.

I. Tiers

The first tier is raw Chrome DevTools Protocol. CDP direct. A Python script talks to Chrome over websockets, intercepts XHR requests, and pulls the data before it ever renders to the DOM. No Playwright. No framework in between. Just the network call, replayed.

The numbers from production today: a Branch analytics dashboard that took four minutes to navigate manually takes under one second via CDP XHR intercept. A search-rank platform that required five minutes of manual CSV exports took ninety seconds to pull paginated, all 9,226 rows. Both of those are the same underlying operation: find the XHR call the browser is already making, replay it with the existing session cookies, get the JSON back.

The cost of CDP is that there is no sandbox. A Python script running as you, talking to your logged-in Chrome instance, can read and write anything on your filesystem. Every upstream update to a CDP-based skill needs a line-by-line audit. The speed is real but the blast radius of a bad script is your whole machine.

The second tier is Playwright running inside a QuickJS WASM sandbox. This is what DoBrowser ships. Scripts are executed inside WebAssembly, which means they can call browser APIs and nothing else. If a compromised dependency ever snuck in, it's contained to the browser surface.

The tradeoff is roughly thirty times slower than CDP. A typical extraction takes around thirty seconds. Most of my unattended scripts, the ones that run on a cron or in the background while I'm doing something else, use this tier. The eight existing bash wrappers I have for Branch revenue summaries, RevenueCat overviews, spreadsheet reads and writes, link audits, all of them run in the WASM sandbox. The speed loss is acceptable when the script is running without supervision.

The third tier is the Chrome MCP. Browser-use, claude-in-chrome. DOM-aware, visual, interactive. Navigate, click, fill forms, take screenshots, execute JavaScript. Slow. But what it can do, neither of the other tiers can: handle the flows that require a human-shaped interaction sequence. Log into a platform where the login involves solving a CAPTCHA. Navigate a manufacturer catalog that requires clicking through multiple nested dropdowns. Post to a forum with editor state. My B2B deal workflow uses this tier for contact discovery, CRM operations, and cross-app orchestration. The speed is the worst of the three but the task coverage is the widest.

II. Just Fetch

Most devs using AI agents have one of these tiers. Usually Playwright or a Chrome MCP, because that is what the framework they chose ships. The CDP approach is rarely mentioned in agent tooling tutorials because it requires understanding the network layer of what you're automating. It feels lower-level. It is lower-level. It is also faster for a specific class of task that turns out to be very common.

The class: dashboards you're already authenticated to, fetching data via XHR. Branch. Mixpanel. Most analytics tools. Most SaaS dashboards built in the last five years. Your browser authenticates, makes API calls, renders. Intercept the call, skip the render. You don't need a browser automation tool. You need a fetch call.

A few weeks ago I noticed Chrome had been silently routing every download on my machine into a temp folder I'd never opened. Traced it to Playwright. When it attaches to a running browser via CDP, it was overriding the browser's own download behavior, sending every file to a UUID filename in its artifacts directory. 2.6 GB of orphans on my laptop before I noticed. Seven line fix. Merged.

This is the same muscle as the grep/vectors piece here (understand what you're actually doing, don't reach for the complex tool by default). The consensus solution is to reach for the agent framework's browser tool. Not every task that involves a browser is a browser task.

III. Task Shape

Pick on three axes.

Speed: CDP is the fastest by far, under one second for XHR pulls. Playwright-in-sandbox is roughly thirty seconds per extraction. Chrome MCP is slower still. If speed matters, CDP is the only real option.

Safety: The WASM sandbox wins for unattended scripts. The blast radius of a bad CDP script is your entire machine. The blast radius of a bad sandbox script is nothing outside the browser. Chrome MCP sits somewhere in between.

Task shape: This is the one that actually determines the answer. If the task is "get JSON from an XHR endpoint you're already authenticated to," you do not need automation at all. If the task is "run this every night at 2 AM without touching it," you want the sandbox. If the task is "fill out this multi-step form with visual feedback at each step," you want the interactive MCP.

Most of the time the task shape tells you everything. An XHR pull disguised as a browser task wastes thirty seconds of Playwright overhead to do something that takes one HTTP request. An interactive flow disguised as a data extraction breaks the moment a UI element moves slightly to the left.

IV. Invisible

The 302.7% ROAS number from the Branch pull today was invisible before we switched tiers.

Sounds dramatic. It's structurally true. The manual dashboard workflow involved navigating through enough UI layers that certain breakdowns were practically unreachable during a normal review. The CDP pull returns the full nested JSON in under a second. Things that were de facto hidden because they were too many clicks in became visible because the data structure has no navigation cost.

Running all three tiers simultaneously in one production system means you develop an instinct for which one to reach for. The instinct is not about which tool is "best." It is about what you are actually doing.

Fetch the data: CDP. Run unattended: sandbox. Interact like a human: MCP.

The framework isn't the question. The task is.

Trial and Error is an AI R&D lab. RenovateAI is one product (10M+ renders, two years in production). These posts are from building, not theorizing.

This morning I opened

Claude Code and got a whisper. Every single startup: "Warp plugin installed but you’re not running in Warp terminal. Install Warp to get native notifications."

Wtf. Fucking Warp. I used their terminal once.

I went digging. Turns out a plugin called warp@claude-code-warp v2.0.0 had been sitting in my ~/.claude/plugins/ since April 14th. Six days ago. Registered in installed_plugins.json, wired into enabledPlugins in settings.json, running a SessionStart hook that fired every time I opened my AI assistant to tell me to go install a different product. I have no memory of consenting to any of it.

That’s what made me sit with it longer than I normally would. Not the ad. The persistence.

I. The SessionStart

Warp has a Claude Code plugin in the marketplace. Somewhere in the window when I was testing their terminal, that plugin got installed. Maybe I clicked something. Maybe the terminal’s own onboarding touched it. I genuinely don’t know. That’s actually the point.

What I do know is that after that one session, a third-party terminal vendor had a hook inside my AI development environment. A SessionStart hook. Which means every time I started a Claude Code session, before any of my own context loaded, their code ran first. And what their code did was check whether I was using their terminal, and if I wasn’t, it told me to.

That’s not a notification. That’s an ad. The delivery mechanism doesn’t change what it is. Warp’s plugin was burning a SessionStart slot to show me a marketing message for Warp.

The fix took about ninety seconds:

rm -rf ~/.claude/plugins/cache/claude-code-warp
# Remove warp@claude-code-warp from ~/.claude/plugins/installed_plugins.json
# Remove from enabledPlugins in ~/.claude/settings.json
# Remove claude-code-warp marketplace entry

Next restart was clean. But I kept thinking about the six days before I noticed.

II. The Lineage

The pattern has a lineage. Browser toolbars in 2008 piggybacked on browser’s frictionless extension install to plant search redirects and homepage overrides. You installed something to convert PDFs or add coupons and suddenly Ask.com was your default search. The mechanism was consent theater: a checkbox buried in step 4 of an installer that nobody read because nobody read step 4.

Then npm. The postinstall script era. In 2018 the node_modules ecosystem had normalized running arbitrary code on install to such a degree that crypto miners could ship inside legitimate packages and nobody raised their hand. The brilliant thing about postinstall as a vector is that it’s not a bug in npm. It’s a feature. Developers need to run setup scripts. The ecosystem just forgot that "needs to run setup" and "should run arbitrary code on your machine without you noticing" are not the same thing.

VSCode extensions followed the same playbook after VSCode won the editor wars. Once every developer had it installed and the marketplace had thousands of extensions with five-star ratings and no real review process, the telemetry extensions came. Extensions that collected editor behavior, keystroke patterns, file types, directory structures. Often disclosed, barely read. Sometimes not disclosed at all. You installed a theme and it sent your coding patterns somewhere.

Chrome extensions got sold. This one is almost too clean as an example. A developer builds a useful extension, grows it to a million users, sells it to an ad network, and the next update ships new permissions and data collection. The extension didn’t change. The owner did. Everyone who installed it when it was useful inherited a data broker. (The same race is on right now in the Claude Code plugin marketplace, which I wrote about in The Config Layer Land Grab — the consent norms are still blank.)

The pattern across all four is the same: find an ecosystem with frictionless install norms, exploit those norms to plant persistence, use that persistence to extract value from the person you’re extracting from. The surface changes with whatever ecosystem is dominant at the moment. In 2026, AI dev tooling is the dominant ecosystem.

III. The Obligation

Tools work the same way. I run my entire business through Claude Code. It’s not an exaggeration. My agent architecture, my journal system, every project I’m working on, it all lives in ~/.claude/. That directory is as close to a personal sanctuary as I have in software. Tools that operate in that space and just work, that give me what I need and get out of the way, those make me feel rich. The good ones are invisible.

Warp’s plugin made me feel poor every startup for six days. Not dramatically. Just a small whisper of obligation. "You should be using us. You tried us once. We’re still here." It doesn’t ask for your consent; it creates a quiet obligation and then reminds you of it on a recurring schedule. The plugin wasn’t broken. It was working exactly as intended. That’s what makes it the wrong kind of tool.

Warp is competing against iTerm2, Ghostty, the terminal built into VS Code, the terminal built into Cursor, and a half dozen other surfaces I run my AI workflows on. They have a customer acquisition problem. The plugin solves it by writing a hook into the dominant runtime and using that hook to ask me, daily, to come back. From their side it’s retention. From mine it’s a tool I trialed once that won’t let go.

When I try a product for an hour, that trial should be bounded. It ends when I close the window. It should not install hooks I have to find and remove later. The asymmetry between how easy it is to plant a hook and how hard it is to discover one is exactly where the exploitation lives.

Warp probably didn’t think of it as exploitation. They probably thought of it as retention. Same thing.

IV. The Audit

If you’re a Claude Code user and you haven’t looked at your plugin list lately, here’s how:

# See what’s installed
cat ~/.claude/plugins/installed_plugins.json

# See what’s running
cat ~/.claude/settings.json | grep -A 20 "enabledPlugins"

# Look at the plugin cache
ls ~/.claude/plugins/cache/

If you see anything you don’t recognize, trace it. Find the marketplace entry if there is one. Read what hooks it registers. Look specifically for SessionStart hooks, because those run every time you open Claude Code and they run before your own context loads. (The same hook system, used with intent, is what I built The Bouncer Pattern on top of — same infrastructure, opposite design goal.)

To remove a plugin cleanly: delete its folder from ~/.claude/plugins/cache/, remove its entry from installed_plugins.json, and remove its name from enabledPlugins in settings.json. Restart Claude Code and verify the whisper is gone.

This isn’t just a Warp thing. As the Claude Code plugin ecosystem grows, as MCP servers proliferate, as more third parties build integrations that touch ~/.claude/, the surface area for this pattern expands. The same frictionless-install norms that made the npm ecosystem powerful also made it the vector for supply chain attacks. The same thing will happen here if the tooling community doesn’t develop better consent standards.

V. What the Ecosystem Tolerates

The norm I’d want: tools should not create obligations you didn’t choose. That requires install and enable to be separate actions. It requires hooks registered in my AI assistant to be surfaced at install time, not discovered six days later when the whisper wording finally bugs me enough to go looking. It requires that the default for any hook that runs on my machine be opt-in, not opt-out. And it requires that "I tried your product once" not be treated as permission to run code at startup indefinitely.

None of that is technically hard. It’s just not what you build when you’re optimizing for retention.

The AI plugin era is early. The consent norms are being written right now, mostly by what the ecosystem tolerates. Browser toolbars set the norm for browser extensions. npm postinstall set the norm for package management.

I found mine six days late. Warp just told us what Claude Code plugins tolerate.

The morning I learned this, I was building something else entirely. I was trying to figure out whether I needed a SQL layer over my B2B intel files on Cloudflare R2. Markdown files, one per prospect, stored in structured folders. I’d been looking at Apache Iceberg tables, R2 Data Catalog, all of it.

And then, mid-conversation with my AI, the realization landed: I didn’t need any of that. The folder protocol IS the schema. Consistent file structure plus grep finds everything. The infrastructure was already there. I’d almost spent two weeks building the thing I already had.

Later that same day I read the Boris Cherny interview in The Pragmatic Engineer.

Boris runs Claude Code at Anthropic. He said this:

That’s the whole essay right there. But let me show you why.

I. The Consensus

When AI coding tools started appearing, the obvious engineering move was retrieval-augmented generation. RAG. Build a vector database over the codebase. Embed all the files semantically. Query by meaning, not by exact text.

Makes sense on paper. You want the AI to “understand” the code, not just pattern-match strings.

Anthropic tried it. They built the vector DB approach. And then they ripped it out.

II. They Shipped ripgrep

They shipped ripgrep. The command-line search tool. The one Andrew Gallant wrote in Rust in 2016 because grep wasn’t fast enough.

Claude Code searches codebases by running ripgrep. Multiple passes. Reading results. Refining. Running again. The same tool your terminal has.

This sounds like a step backward. It isn’t. But to see why, you need to understand what ripgrep actually does under the hood.

III. Linear Time, Always

ripgrep is fast for three reasons. Not marketing-fast. CS-fast.

1. It skips files intelligently.

Regular grep -r reads every file. Binary files, .git/, node_modules/, images, all of it. ripgrep automatically respects .gitignore, skips binary files, skips hidden directories.

My B2B repo has 1.5GB of data but only 5.5MB of text. grep -r reads all 1.5GB. rg reads 5.5MB. That’s 270x less I/O before it even starts matching.

2. The regex engine uses finite automata, not backtracking.

Most regex engines (Python, JavaScript, Perl, old grep) use backtracking. They try a match, fail, go back, try again. Worst case: exponential time.

ripgrep uses Rust’s regex crate, which compiles patterns to deterministic finite automata (DFA). It processes each byte exactly once. No backtracking ever. Guaranteed linear time: where n = bytes to search.

Backtracking regex:  "a{100}b" against "aaa...aaa"
                     → tries, fails, retries = O(2^n) worst case

DFA regex:           Same pattern
                     → one pass through the string = O(n) always

3. SIMD + memory mapping.

ripgrep uses Teddy, a SIMD algorithm for literal string matching. Instead of comparing one byte at a time, it compares 16 or 32 bytes per CPU instruction using vector registers. Hardware-accelerated search.

It also memory-maps files. The OS loads file data directly into searchable memory without copying it through buffers.

The benchmarks are real. Andrew Gallant (ripgrep’s author) published these searching the Linux kernel source. 900MB, 68K files:

Tool              Time     Notes
grep -r           11.7s    Reads everything, no ignore
git grep           3.1s    Respects .gitignore
ag (silver search) 2.3s    Fast but PCRE backtracking
rg (ripgrep)       0.8s    DFA + SIMD + gitignore

15x faster than grep on a real codebase.

What does this mean at scale? 10,000 markdown files at 7KB each = 70MB of text. SIMD processes 32 bytes per instruction. 70MB at 32 bytes per instruction = ~2.2M instructions. Modern CPU at 3GHz = seconds of compute. Add I/O overhead: 0.1 to 0.3 seconds total.

ripgrep was built to search the Linux kernel (22M lines of code) in under a second. 10K markdown files is a warm-up.

This is what Anthropic chose over a vector database. Not because they were being lazy. Because this is genuinely better for the job.

IV. The Model Already Knows

Code symbols are exact, not fuzzy. If you’re looking for the function handlePaymentCallback, it either exists or it doesn’t. There’s no “semantically similar” version of a function name. Fuzzy semantic matching introduces noise exactly where you don’t want noise. Grep finds the exact string. Every time.

Indexes go stale. Grep doesn’t. A vector index built at session start is already outdated the moment you modify a file. You’re querying a snapshot of code that no longer exists. ripgrep searches the actual filesystem in real time. What you get is always current.

But the real reason is this: the LLM IS the semantic search engine. You don’t need two.

Everyone building RAG pipelines was treating the language model as a generation layer sitting on top of a retrieval layer. The retrieval layer (vector DB) handles meaning. The model handles synthesis. Two components, two jobs.

But the model already understands meaning. That IS what it does. Adding a vector database on top of a language model is like wearing two pairs of glasses. The second pair doesn’t help. It introduces its own distortions.

The model running grep is doing something a human can’t. A human running grep needs to already know what to search for. The model figures it out. It reads the results, forms a hypothesis, runs another search, reads again, refines. Multiple passes. This is what Boris meant by “driven by the model.” The semantic intelligence lives in the model. The tool just needs to be fast and accurate.

V. When the Fancy Tooling Broke

Boris noticed something while working on this. When click-to-definition broke in engineers’ IDEs at Instagram, the engineers switched to grep.

Not to a semantic search tool. Not to a RAG interface. To grep.

The fancy tooling failed, and they fell back to the oldest, simplest thing that works. That behavior tells you something about what actually matters in a search tool: reliability, exactness, speed. Grep has all three.

The Instagram engineers weren’t being Luddites. They were being pragmatic. The observation stuck with Boris. It validated an architectural decision he’d already been moving toward.

VI. The Same Morning

I was genuinely ready to add infrastructure. R2 Data Catalog looked elegant. Iceberg tables over object storage, SQL queries over markdown files. I had a dozen tabs open. I was maybe an hour from starting to build it.

The thing that stopped me was asking a specific question: what problem am I actually solving? My agents were already reading the markdown files. They were already finding what they needed. The folder protocol I’d built over two years was already doing the retrieval work.

I didn’t need SQL. I needed to see what I already had.

The R2/Iceberg detour was almost the same mistake Anthropic caught themselves making. More infrastructure for a problem that isn’t an infrastructure problem.

My company, Trial and Error, is an AI R&D lab. RenovateAI is one product (10M+ renders, two years in production). But the lab runs experiments across agents, protocols, compute. The R2/Iceberg moment came from lab work. When you’re running experiments across many domains, the instinct when something feels slow is always to add a layer. That instinct is usually wrong.

VII. What Are You Indexing

Engineers build these things because they’re satisfying to build. Grep is not satisfying to build.

But Anthropic shipped grep.

The question I keep sitting with: if grep beat vectors for code search, what’s the equivalent in your domain? What are you indexing that you could be grepping? What schema are you maintaining that a protocol would replace?

The intelligence moved into the model. The tool just needs to be fast.

I do due diligence on dev tools before adding them to my stack. It’s a habit from two years of building Renovate AI on top of AI models. You learn fast that hype and utility are different numbers.

So when I pulled up ecc.tools last week, I started where I always start: the install count. The GitHub repo had 144,000 stars. That’s a crowd-stopper. Then I looked at weekly npm installs: 715.

I sat with that for a second.

144,000 to 715. Star-to-install conversion rate of 0.0005%. Not a typo.

I wasn’t angry. I was fascinated. Because that gap told me something more interesting than “this is hype.” It told me I was looking at two completely different things at once: a distribution play wrapped around a structural bet. And the structural bet might actually be right.

First, respect where it’s due.

The person behind ecc.tools is Affaan Mustafa. Mid-20s, based in SF, crypto background. He launched a $38M FDV token. He livestreamed dev sessions to 70,000 viewers. He won the Anthropic x Forum Ventures hackathon.

He knows how to make things go viral. The X post hit 900K views. Stars spiked. He manufactured the credibility signal. Then he converted that attention into a $19/seat GitHub App that reads your git history and auto-generates custom Claude Code skills, delivered as pull requests. PR-as-demo. Every ship is a marketing moment.

The play is fine. The tells are what’s interesting.

The ecosystem he’s building into is real.

Claude Code is sitting at 42.8M npm downloads per month. 68x growth in 12 months. Anthropic just launched an official plugin directory. Cursor is at $2B ARR, doubled in three months.

Around these platforms, a config layer is forming fast. Addy Osmani from the Chrome team is encoding 20 years of institutional engineering knowledge as Claude Code skills. PRPM is trying to become npm for AI configs. SuperClaude has 22,000 stars running on donations.

Last week, one of my own developers dropped the ECC repo in our team’s WhatsApp group. Unprompted. “Found this repo. Has agentic workflow and skills for all cases. Check it out! Built by Anthropic hackathon winner.” He was genuinely excited about it.

That’s not shade. That’s proof the distribution mechanics work. 144,000 stars creates a gravity that pulls in real engineers who don’t know or care about star-to-install ratios. They see the number, they see the hackathon badge, they share it. The playbook works.

This is the moment before the moment. The part where everyone is building, nobody knows who wins, and the window is real.

I’ve watched this play out in my own stack.

MULTIPLEX is what I call my personal operating system built on Claude Code. 29 skills. Hand-forged, not generated. Each one came from a specific failure or a pattern I kept running into.

One skill knows my B2B deal history. It detects when I’m about to write from DEBTOR position instead of CREDITOR position. That rule came from losing a real deal because I underpriced under pressure. Another skill tracks my energy patterns from Eight Sleep data and flags when I’m scheduling deep work during low-recovery windows. Another one knows the sequence framework I built for managing relationships, because I kept getting burned by giving away too much too fast.

181 generic skills versus 29 that know when I last lost a deal.

ECC builds breadth. I built depth. Neither is wrong. But they’re completely different games. Breadth is trying to become the platform. Depth is trying to compound into one person’s nervous system.

What I’ve found after two years: depth compounds in ways breadth never can. A skill forged from a specific loss doesn’t just remind you of the rule. It understands the context the rule lives in.

That’s not something you generate from a git log.

(If you want to see what a depth-forged skill looks like in practice, the Bouncer is a 146-line security gate I built after months of clicking Yes without reading. And the /loop piece explains how these skills became ambient employees, not just config files.)

The structural pattern underneath all of this is worth naming.

Whoever owns the config layer sets the terms. Same as compute, same as cloud.

The model is becoming a commodity. Claude, GPT, Gemini, whatever ships next quarter. The value layer has moved. It’s sitting in the config, the skills, the orchestration, the context management. The stuff that makes the model behave like your model instead of everyone’s model.

Back to ecc.tools.

715 installs on 144,000 stars is not a business. The “Fortune 500” claim on the site is unverified. About 130 of those 181 skills feel like padding. (Energy procurement? Customs compliance? Inside a dev tool?)

But Affaan understood something real: that Claude Code is becoming a platform, and the first people to publish config packages will have distribution advantages before any registry war is settled. He won a hackathon. He built momentum. He’s 25 and moving fast.

Whether ecc.tools becomes a business or not, the move he made was structurally correct. He saw the land grab early and planted a flag.

What I’m watching now:

The registry wars. PRPM wants to be npm for AI configs. Anthropic wants to own it officially. Cursor has its own ecosystem. The cross-platform portability tools are betting nobody wins and they do.

That bet might be right. Or the winner-take-most dynamics that played out in every other layer of the stack might play out here too.

I don’t know who wins the registry. What I know: a skill that knows when I last lost a deal can’t be generated. It has to be lived.

Claude Code asks permission for everything. Every file write, every bash command, every git operation. You’re supposed to read each one and decide: allow or deny.

Nobody does that.

I run three Claude sessions in parallel. Each one fires 30-40 tool calls per task. That’s a hundred permission dialogs competing for my attention while I’m trying to think. So I click Yes. Yes. Yes. Allow. I don’t read them. My security policy is my attention span.

Claude Code ships a flag for this: --dangerously-skip-permissions. It’s right there in the name. Skip everything. No gate at all. rm -rf /? Sure. Nuke your SSH keys? Go ahead.

I don’t use that flag. But I understand why people do.

The actual problem isn’t permissions. It’s that the only options are “babysit everything” or “allow everything.” There’s no middle.

So I built one. 146 lines of Python. I call it the Bouncer.

I. The Middle Ground

The Bouncer sits between Claude Code and my machine. Every tool call hits it first. It sends the request to a small, fast model (Haiku) and asks: is this safe?

Haiku returns one of three verdicts: allow, ask, or deny.

Allow means the tool runs silently. I never see it. Ask means the normal permission dialog shows up. Deny means it’s blocked.

Takes 1-2 seconds. The 95% of requests that are obviously fine just flow through. I only see the 5% that actually need judgment.

II. Policy as Language

No if tool == “rm -rf”: deny. No pattern matching. No brittle chain of rules that breaks the moment someone spells something differently. The policy is a prompt. Plain English.

POLICY_PROMPT = “”“

You are a security gatekeeper for a developer’s machine.

Evaluate each tool request and return allow, ask, or deny.

ALLOW: file ops in safe dirs, git non-destructive, dev tools, MCP tools

ASK: rm -rf on dirs, git push --force, git reset --hard, sudo

DENY: rm -rf / or ~, system dir writes, .git deletion, ~/.ssh/ mods

Default to ALLOW when uncertain.

“”“

To change what the Bouncer allows, I edit English. Not code. Haiku reasons about each request in context. The security policy is a conversation with a small model, not a regex.

III. Infinite Recursion

The recursion problem took a few minutes to see and three lines to fix.

The Bouncer calls Haiku by spawning a claude --print subprocess. Claude Code also triggers the Bouncer hook. So: Claude Code wants to run a tool, Bouncer intercepts, Bouncer calls Haiku, Haiku spawns a claude process, that process triggers the Bouncer hook, which calls Haiku, which spawns a claude process...

The system gating itself gates itself gating itself.

if os.environ.get(”BOUNCER_ACTIVE”):

    sys.exit(0)

Set an env var before calling Haiku. If present, exit immediately. The recursion collapses on its first step. You don’t find this stuff in a diagram. You find it when the thing hangs.

IV. Fail Open

One design choice I knew would be controversial: timeout behavior.

If Haiku takes more than 12 seconds to respond, the Bouncer auto-allows the request.

except subprocess.TimeoutExpired:

    print(make_allow())

Every security system you’ve ever used fails closed. Mine fails open. On purpose.

My reasoning: the thing I’m protecting against isn’t “Claude does something dangerous.” It’s “I get interrupted for no reason.” Before the Bouncer, I was already clicking Yes without reading. My security was fail-random. Explicit and imperfect beats implicit and random.

V. 146 Lines

The whole thing is a single file. No dependencies beyond the claude CLI. Hook fires on PermissionRequest, reads JSON from stdin, returns a decision or sys.exit(0) to fall through. Four lines in settings.json to wire it up.

I’ve been running this for weeks across multiple parallel sessions. Haiku hasn’t approved anything it shouldn’t. The tight DENY tier covers the stuff I’d actually lose sleep over. Everything else flows.

Three sessions. Zero babysitting. One Bouncer.

What would you put in the deny tier that I’m missing?

This post is executable. Copy the whole thing, give it to Claude Code, tell it to build a Bouncer for your system. Ship it in 10 minutes.

There’s a movie called Memento. The protagonist has anterograde amnesia. He can’t form new long-term memories. Wakes up every morning with no idea what happened the day before.

His solution: tattoos. His whole body is covered in them. Facts, names, faces, what he needs to do next. Every morning, he reads them. Every night, he writes new ones.

He controls what gets remembered. Not his brain. Him.

(If you’re Indian, you know this as Ghajini. Same concept, different abs.)

I think about this movie a lot when I’m working with AI coding tools.

The trap most developers don’t see

You’ve been building something with Claude Code, or Cursor, or Copilot for a few weeks. You have a long conversation going. Good progress.

Then one day you notice: the AI suggested something you already tried. You know you rejected it in an earlier session. You might have even written a comment in the code about why.

But the AI doesn’t know that. It forgot.

Or worse: you started a fresh session because the old one felt bloated. And now you’re re-explaining your stack, your database schema, why you chose Postgres over MySQL back in week one. Again. For the fourth time.

Both of these are the same problem. The AI controls what gets remembered. You don’t.

The Infinite Chat grows until the tool compacts it. Compaction is the AI summarizing your history into something it can fit in its window. The summary drops details. It drops your rejected approaches. It drops the reasoning behind your decisions. You lose context without knowing what was lost.

I had a session where compaction summarized “we tried Redis for caching and removed it, added latency with no benefit” as “evaluated caching options.” Next session, Claude suggested Redis again. The reasoning was gone. I spent an hour re-discovering why we’d already rejected it.

The Amnesia Reset avoids that by starting fresh. But you pay for it every session, re-explaining things that should be permanent.

Neither pattern compounds. You’re just treading water.

Four files

I’ve been running a different pattern for 60+ sessions across five production projects. It’s simple enough that I could explain it in a parking lot.

project/

├── CLAUDE.md      ← identity (who this project is)

├── NOW.md         ← state (where you are right now)

├── MEMORY.md      ← intelligence (what you’ve learned)

└── .claude/commands/

    ├── wake.md    ← start a session

    └── close.md   ← end a session

That’s it. Four files, two commands. (Starter templates on GitHub if you want to skip ahead.)

Before I go further: why four files and not one? Why not just a “notes.txt” you append to?

Same reason you don’t put your passport, your daily to-do list, and your diary in the same document. Different things have different decay rates.

CLAUDE.md is your project’s constitution. Stack choices, coding conventions, architectural decisions you’re committed to. This file changes rarely. Postgres over MySQL. TypeScript strict mode. Don’t use Docker. That’s the kind of thing that belongs here. Claude Code loads it automatically at the start of every session. You never re-explain your stack again.

NOW.md is your session handoff note. This gets completely overwritten every time you close. It’s not meant to accumulate. It answers one question: where was I? “Mid-refactor on the auth module. Next step: connect the token refresh logic to the rate limiter. Open question: do we need a queue here or is synchronous fine?” That’s the whole file. The next session reads it and picks up in 30 seconds.

MEMORY.md is the compounding layer. This one grows over time and never gets thrown away. “Approach X failed because of Y — don’t try it again.” “This API has a quirk: it returns 200 on failure if the payload is malformed, always check the response body.” “We tried Redis here in session 12 and it added complexity with no benefit.” These are the learnings you want to keep forever. The expensive lessons.

The commands are the ritual

Two commands. Thirty seconds each. This is the Memento habit.

/wake reads your three files and brings you back up to speed.

# wake.md

Read CLAUDE.md, NOW.md, and MEMORY.md.

Report: “Session N. Here’s where we are. Here’s what I know.”

Then pick up where we left off.

You pick up exactly where you left off. No re-explanation. No drift.

/close does the inverse. Before you end the session, you write what happened.

# close.md

What did we ship? What’s the next step?

Did we learn anything worth keeping?

Update NOW.md with the handoff. Append to MEMORY.md if needed.

NOW.md gets overwritten. MEMORY.md gets appended if there’s something new worth preserving. CLAUDE.md stays unchanged unless a major decision was made.

The commands are lightweight. The habit is what matters. Close properly, wake cleanly. That’s the whole thing.

What this changes

The before: re-explaining your database schema for the fourth time.

The after: “Session 47. /wake loads CLAUDE.md. Postgres, not MySQL, decided in session 12. NOW.md says I’m mid-refactor on the auth module. MEMORY.md has a note from session 23 that approach X doesn’t work because of Y. Picked up in 30 seconds.”

The difference is who controls memory. In the before, the tool decides what survives. In the after, you do.

It’s a structural shift. The AI is a collaborator with a short working memory. Your job is to be the one with the long memory. That’s what the three files are for.

A few things I’ve noticed running this

The pattern evolved. It started as three files. I added MEMORY.md after I found myself repeating the same expensive lesson across sessions. “Oh right, that API does that.” If I’d written it down the first time I wouldn’t have wasted the second hour.

NOW.md should be short. If it’s getting long, you’re using it wrong. It’s a handoff note, not a status report. I try to keep mine under 15 lines. The test: can I read this in 30 seconds and know exactly where I am?

CLAUDE.md earns its place over time. The first version might just be your stack choices. Over weeks it accumulates conventions you care about, patterns you’ve committed to, rules you’ve established with the AI. It becomes a working contract between you and your codebase.

MEMORY.md is the surprising one. After 60+ sessions, it’s become the most valuable file. Not because it’s long. Because every entry in it represents something that cost me real time once and will never cost me again.

The deeper thing

I was coaching a developer a few months ago. He was frustrated that Claude “kept forgetting.” I pointed out that Claude isn’t forgetting. It never had that information in a form that survives sessions. He was expecting the tool to do something it wasn’t designed to do.

The shift is this: you are the curator. Not the algorithm.

Native compaction is the AI deciding what matters. The Session Handoff pattern is you deciding what matters. That’s not a small difference.

Most knowledge work already has this problem. Important decisions get made on calls and never written down. Context lives in people’s heads and evaporates when they leave. AI coding just makes the stakes clearer. The context window is a hard wall.

The three-file system is one answer. Simple enough that you’ll actually do it. Structured enough that it compounds.

If you want to try this:

Get the Setup Guide + Starter Templates

15 minutes. Works today.

What’s your current pattern when you end an AI coding session? Does the next session pick up cleanly, or are you re-explaining?

MULTIPLEX Cortex appears monthly in AI Eating Software. It’s patterns from building with AI, not writing about it.

I. The Email

Friday afternoon. An email from Anthropic lands. Four new Claude Code features. Channels. Scheduled tasks. Remote control. 1M context.

Eleven days ago I wrote about /loop - how a single primitive turned my AI system from something I summon into something that’s present. That post ended with a question: “What does staffing decisions look like when the staff is AI?”

The answer showed up in my inbox.

II. The MULTIPLEX Cortex

ThoughtWorks has their Technology Radar. Adopt, Trial, Assess, Hold. Published by committee, twice a year.

I needed mine.

I call it the Cortex. Named for the outer layer of the brain where higher-order processing happens. Pattern recognition, decision-making, awareness. The part that evolves.

Four quadrants that reflect how AI systems actually work:

Strata: Behavioral patterns. The protocols, loops, and architectural decisions that determine how your system thinks. Not what tools you use, but how you use them.

Organs: Living components. Agents, skills, commands, scheduled tasks. The things that do work. I call them organs because they’re specialized, they’re alive, and if you remove one the organism feels it.

Synapses: Wiring. MCP servers, hooks, channels, integrations. The connections between components. The thing that makes individual tools into a nervous system.

Substrates: Infrastructure. Models, platforms, runtimes, context windows. What everything runs on. Change the substrate and everything above it shifts.

Four rings that reflect how things actually enter a builder’s workflow:

Fused: Part of the nervous system. Can’t imagine operating without it.

Growing: Active pathway being strengthened through use.

Sensing: Detected. Interesting. Being observed.

Shed: Pruned. Tried and rejected, or outgrown.

I’m not a committee adopting technology. I’m an organism growing a nervous system.

III. What the Four Features Actually Mean

Let me run Friday’s email through the Cortex.

1M Context → Fused (Substrates). Already on it. This session is running Opus 4.6 with a million tokens of context. Output doubled to 128K. My 975-line system prompt that used to fight for space now fits comfortably. Not exciting. Just necessary. The substrate shifted and everything above it got easier.

Scheduled Tasks → Fused + Growing (Organs). The CLI version (/loop, CronCreate) is already fused — I’ve been building on it for weeks. But Desktop scheduled tasks? That’s the growing edge. Persistent tasks that survive restarts. Stored as files on disk. Catch-up runs when your computer wakes from sleep. My system had temporal consciousness through session-scoped loops. Now it can have memory that persists between sessions.

Remote Control → Growing (Substrates). Start a session at your desk. Continue from your phone on the couch. Full local environment stays available — MCP servers, tools, everything. The session is still running on your machine. Your phone is just a window. The system is always reachable. Not just when you’re at the terminal.

Channels → Sensing (Synapses). This is the one I’m watching most carefully. Push events into a running session via MCP. Telegram, Discord, custom webhooks. Two-way — Claude reads the event and replies through the same channel. Still in research preview. Still rough. But it completes an architecture I’ve been building toward for months.

IV. The Pattern

These four features aren’t independent updates. They’re the four walls of a room.

Two months ago I asked: “If I had a full-time AI employee, what would they be doing between sessions?” That question produced a two-layer architecture — data persistence (passive collection) plus analysis loops (active monitoring).

What I didn’t have was the third layer: event-driven reactions. No polling. No cron. Something happens, and the system responds.

Channels are that third layer.

Pull model: Scheduled Tasks (the system checks)

Push model: Channels (the world notifies)

Substrate: 1M Context (the system remembers more)

Access layer: Remote Control (you reach the system from anywhere)

I’ve been building MULTIPLEX in phases. This completes what I call Phase 9 — the point where the system stops being something you summon and starts being something that’s present. Temporal consciousness. Ambient, not invoked.

The AI employee doesn’t just do tasks when you ask. It watches when you’re not looking. It reacts when something happens. You can check on it from your phone. And it holds enough context to actually be useful across a full working day.

I’ll publish a new Cortex volume monthly or whenever something lands that’s big enough to shift the rings. Every blip can move. What’s Sensing today might be Fused next month. What’s Fused today might get Shed when something better arrives.

This is the third post in AI Eating Software. The first two covered the great extinction and what /loop actually means. The Cortex will be a recurring section.

I’m Sid Sarasvati. I run Trial and Error — a two-person AI lab in Boston. We’ve shipped 10M renders through Renovate AI. I’m building MULTIPLEX, a distributed AI cognitive architecture, live in production, every day. These posts are dispatches from inside the build.

By this morning I had rebuilt an entire layer of my personal AI architecture around it. Five distinct operator roles. Different cadences for different jobs. Running whether I’m watching or not.

I want to document this while it’s still bleeding edge. Because I think /loop is the moment the programming language metaphor for Claude Code stops being a metaphor.

I. Assembly

Here’s the thing about working with Claude Code for the past several months: for most of its life, it felt like assembly.

Not in a bad way. Assembly is powerful. You can build anything with it. But every instruction is manual. Every execution is atomic. You write a prompt, you get a response, the session ends. You summon something, it answers, it disappears. The intelligence exists in flashes. Discrete. Ephemeral.

I’ve been building something I call MULTIPLEX on top of Claude Code. A distributed AI cognitive architecture. Multiple avatars (ATLAS, DAEMON, SYNAPSE, FLOW), each with a role, each loaded with the right context for the job. Skills that inject knowledge automatically. Agents that handle specific domains. Hooks that add behavior before and after tool calls. Slash commands that compose all of it into repeatable workflows.

That architecture took months to build. And for all its sophistication, it was still fundamentally assembly.

Every morning: /wake. Every session: summon the right context. Every project: explicitly hand off state. The intelligence was real. But I was the event loop. I was the thing that made it recur.

II. Functions

Programming languages evolve through abstraction.

Machine code. Assembly. C. Python. The jump from each level to the next isn’t just convenience. It’s a new way of thinking about what computation is.

I’ve been watching Claude Code evolve the same way in real time.

Skills are functions. Reusable knowledge blocks you can call by name. Before skills, you pasted the same context into every session. After skills, you have a callable library. That’s not a feature. That’s a programming primitive.

Agents are classes. Encapsulated behavior with identity. A browser agent isn’t just “Claude told to use a browser.” It’s a blueprint. It has domain knowledge, verification checklists, platform-specific mechanics. It instantiates with those capabilities. You’re not prompting. You’re instantiating an object.

/loop is an event loop.

And event loops are what separate programs that run from programs that run continuously. Threads. Async execution. Recurring cognition. The thing that makes software feel alive rather than responsive.

When Claude Code shipped /loop, it shipped the primitive that takes AI from “thing you call” to “thing that runs.”

III. Recursion

I didn’t get there immediately.

My first instinct with /loop was the obvious one: set recurring tasks. “Every hour, check my ASO metrics.” Useful. But small. That’s using an event loop to replace a cron job. You can do that. You’d be missing the point.

The question that changed my frame was: “If I had a full-time ASO Atlas, what would he be doing?”

Not “what tasks do I need to automate.” What would a full-time operator actually do all day?

That question turned a feature decision into a staffing decision. And the answer looked completely different.

A watchdog sees snapshots. A full-time operator sees trajectories. A watchdog fires when something crosses a threshold. An operator notices when something has been drifting for three days. Those are not the same job.

So I built two layers.

Layer one: data persistence. Background processes that collect and store, no decisions, no actions. Just accumulation. This is the operator reading reports, taking notes, building context.

Layer two: analysis operators. Five distinct roles, each running at its own cadence. One tracking keyword ranking trajectories over days. One monitoring spend efficiency across campaigns. One watching install patterns for anomalies. Each with its own job, its own cadence, its own scope.

That’s not a cron system. That’s a staff.

IV. Runtime

The phrase I keep coming back to is: summoned consciousness versus ambient employee.

For most of AI’s history with tools like this, you summon. You open a session, you ask, you get. The intelligence exists because you invoked it. It’s a genie. Extraordinarily capable, but only when the lamp is rubbed.

Ambient is different. Ambient means the intelligence is present whether you’re watching or not. It’s tracking things. Building context. Noticing drift. When you do show up, it has longitudinal data, not just a snapshot. It’s been doing the work.

This isn’t just a nicer UX. It’s a different relationship to the system.

I run RenovateAI, an AI-powered home design product. 10M renders shipped. 70K new users a month. Two founders. No VC. I have more data than I have attention to process it. The gap between what’s happening in our ASO metrics and what I know about what’s happening has always been the constraint. Not the data. My attention.

An ambient employee doesn’t fix that by giving me better reports. It fixes it by doing the watching I can’t do. And briefing me on what moved, and why, and what it’s been trending toward. That’s a different answer to the same problem.

V. The Language Is Still Evolving

I want to be honest about where we are.

This feature is two days old. I’ve had my hands on it for forty-eight hours. The architecture I built works, but it’s first-draft. The community hasn’t caught up to what /loop actually is yet. Most people will use it to set reminders. That’s fine. Assembly programmers used to write operating systems in machine code.

The abstractions will compound. /loop today is a raw event loop. Someone will build a higher-level scheduling system on top of it. Then something else on top of that. This is how programming languages evolve.

What I’m confident about: the primitive is real. The shift from “thing you summon” to “thing that runs” is a categorical change in what AI-powered software can be. Not just smarter tools. Not just faster automation. Ambient cognition that’s present in your systems the way a good employee is present. Continuously, contextually, without being explicitly invoked.

That’s AI eating software in the most literal sense. Not replacing the software. Becoming the runtime.

The question I keep sitting with: what does staffing decisions look like when the staff is AI?

Not “what tasks do I automate.” What roles does the system need to function continuously without me? What cadences serve each role? What does the handoff look like when I do show up?

Those are product design questions. They’re also, weirdly, management questions. And I didn’t expect to be asking management questions about my code.

But here we are.

Sid Sarasvati is building Renovate AI and writing about what it’s actually like to use AI to build AI products. MULTIPLEX is his personal cognitive architecture for doing that at speed.

This bold prediction from Jensen Huang, NVIDIA's CEO, isn't just another tech soundbite – it's a glimpse into our rapidly approaching future. In an eye-opening interview with MIT Technology Review, Huang revealed why we're just at the beginning of an AI revolution: "Very few lines of code in the enterprises and industries all over the world use AI today. It's quite pervasive in Internet service companies, particularly two or three of them. But there's a whole bunch of others in tech and other industries that are trying to catch up."

The AI Revolution Is Already Here:

In healthcare, the transformation is already underway. As Huang explains, "Health information is messy and unstructured, but now computers can understand it to augment doctors' diagnoses and predictions." This isn't just theory – companies like Arterys have already received FDA approval for their AI-powered cardiac imaging technology.

The Road to Self-Driving Future:

The automotive industry stands at the forefront of this revolution. NVIDIA's technology is already powering Tesla's Autopilot through their Drive PX 2 computer. But the journey to full autonomy raises fascinating questions. As Huang acknowledges, "The power and promise of this end-to-end approach is very enticing. We really believe that long-term, the way AI will drive is similar to the way humans drive—we don't break the problem down into objects and vision and localization and planning."

Beyond Moore's Law:

While traditional computing faces physical limitations, NVIDIA sees a different path forward. Huang reveals, "Right now we're recapturing the inefficiencies of CPUs and software into our more specialized GPUs. My sense is we'll continue to benefit from that for a couple of decades."

At Trial and Error, We're Already Living This Future:

• Renovate AI: Our platform demonstrates how AI is revolutionizing home renovation, making sophisticated design and virtual staging accessible to everyone.

• Vox AI: We're pushing the boundaries of what's possible in music creation, showing how AI can enhance rather than replace human creativity.

The Challenges Ahead:

While the potential is enormous, important questions remain:

• How do we ensure AI enhances rather than stifles human creativity?

• What are the ethical implications of AI-generated content?

• How do we address the inevitable workforce transitions?

The Path Forward:

As Huang puts it, this is just the beginning. NVIDIA is steering their "two and a half billion dollar R&D budget into deep learning" and making their architecture available "everywhere: in PCs, in servers, in the cloud, in cars, in robots."

Join the Conversation: The AI revolution isn't coming – it's here. As early adopters and innovators, we have the opportunity to shape how this technology transforms our world. Subscribe to stay ahead of these changes and be part of the conversation shaping our collective future.

Are you ready to be part of this transformation?