kodyw.com

Own the Engine

On October 26, 2026

Back in August I wrote The Personless Harness. The picture was simple: Copilot is the carriage, you are the horse, and the Brainstem is the engine. Swap the horse for the engine and the same carriage runs at a pace no stable could feed.

This week two videos landed that push on that picture from opposite sides. I want to walk through both, because together they change how I’d tell the story.

Same carriage. Different thing pulling it. The horse gets to watch.

You are the next horse

David Shapiro’s You Are The Next Horse is a ten-minute history lesson with a sharp ending. In 1918, American farms had about 26.7 million horses and mules doing almost all the pulling. Within a few decades, tractors outnumbered them. The machines won for the oldest reason there is: better, faster, cheaper, safer. You couldn’t save the horse by feeding it less.

Economists have said for years that people are not horses, because we can always move up to newer, harder work. Shapiro’s answer is that the newer, harder work of the last century was thinking work, and thinking work is exactly what AI is learning to do.

Then he takes apart the line everyone repeats: “AI won’t take your job, someone using AI will.” His version of the meme is a farmer telling his horse it won’t lose its job to a tractor, but to a horse that learns to drive one. It’s absurd on purpose. The tractor never needed the horse. The teamsters really did learn to drive trucks, and that worked for a century, and now the trucks are learning to drive themselves.

His way out isn’t a skill. It’s ownership. Horses could never own a share of the tractor. People can.

Which layer are you standing on?

The second video, from DevLogic, walks through Andrej Karpathy’s funnel, and it explains why most people will hear Shapiro and shrug.

A funnel: 6 billion people have barely touched AI, 1 to 2 billion use free chatbots, 20 million use frontier models for code and math, 5,000 work inside the labs. — Karpathy’s funnel: every layer sees a different AI.

Pour the whole planet in at the top. About six billion people have barely touched these systems. One to two billion use a free chatbot now and then and see a slightly clumsy assistant. About twenty million use frontier models every day for code and math, and they watch projects that used to take weeks get done from a single prompt. At the very bottom, about five thousand people inside the labs watch swarms of agents work for weeks.

Karpathy names three things that decide where you land: how ambitious the problems you hand it are, which kinds of work it happens to be great at (digital, checkable, valuable), and which door you have access to. Each layer doesn’t see a better version of AI. It sees a different one. That’s why arguments about AI go nowhere. Both people are describing what they saw. They’re just standing at different depths.

Where my horse story was right, and where it was too soft

Reading these side by side, the Personless Harness post is a field report from the twenty-million layer. An AI agent with a real browser and a checklist ran thirty-three checks in about nineteen seconds, work that takes a person twenty minutes of full attention every single pass. That isn’t a forecast. I ran it four times in one evening.

It also lines up with Karpathy’s point about where these models are strongest. The rules I wrote for a trustworthy helper (use the real thing, check that what should be gone is gone, never fake a pass) are really rules for making work checkable. Checkable work is exactly where AI is sharpest. If you want the engine to take a job, make the job checkable first.

But my ending was too comfortable. I said the person moves from pulling to steering. Shapiro’s teamsters are that ending, and the trucks are now driving themselves. “Learn to steer” is the horse learning to drive the tractor. It buys time. It isn’t a destination.

And yet Karpathy’s funnel says the time it buys is real. Right now only about one in five hundred people can actually steer these systems. Steering is worth a lot today. It just isn’t forever.

Own the engine

A person relaxing at a kitchen table at night while a glowing engine in their home workshop keeps working on several jobs. — The engine lives at your house, and it works for you.

So here is the version of the story I believe now.

Steering is the near-term skill. Ownership is the long-term answer. The Brainstem is where those two meet. It isn’t a smarter chat window you rent by the month. It’s a tireless second version of you that runs on your own machines, knows your tools, remembers how you like things done, and keeps working after you clock out. It’s the engine, and it’s yours.

That also answers Karpathy’s funnel, at least for one person. Most people will never climb down to the twenty-million layer by learning prompts, picking models, and wiring tools together. They shouldn’t have to. A Brainstem brings that layer to them: you talk to it, it does the work, and it shows you the proof. You get the depth without the descent.

The horse never got a share of the tractor. You can own the engine. Start with the biggest, most annoying, most checkable job on your plate, hand it over, and see how far down the funnel you really are.

Sources: David Shapiro, “You Are The Next Horse“; DevLogic, “Karpathy: The AI Understanding Gap Is Getting Worse, Fast“. Earlier in this series: The Personless Harness and The Buzzsaw.

An endless paper receipt pours out of a laptop screen, across the desk and onto the floor.

The context tax: my AI tools send 30,000 tokens before reading my question

By Kody Wildfeuer

On October 12, 2026

In Uncategorized

I have been telling people for a while that long AI chats are a tax. Every message re-sends the whole conversation, and the harnesses we use every day add their own instructions and tools on top. I had a feeling that my Brainstem cost pennies because it keeps chats short and puts the useful work into
agent.py files, while Claude Code and Copilot CLI kept growing the chat. A feeling is not a number, so I measured it.

What I ran

Five small business tasks with real rules: tiered sales commission with clawbacks, overtime pay, reorder points, late fees, and invoices paid twice. Each task was packaged three ways from one Python implementation: an Agent Skill written in plain words, the same skill with a bundled script, and a RAPP
agent.py. Claude Code, GitHub Copilot CLI and a Brainstem answered the same questions with the same model, Claude Haiku 5.5. Three runs of every setup, every answer graded to the cent.

What held up

The host charges before you ask. To answer “reply with the number 7”, a fresh Claude Code sends the model 15,176 tokens and a fresh Copilot CLI sends 23,014. A Brainstem sends 2,805. My own Claude Code and Copilot, with everything I have installed over the months, send 32,295 and 33,719. My own Brainstem, with 22 agents loaded, sends 8,716.

Every question pays that charge again. The same 15 questions cost 135k tokens in a Brainstem, every answer right. Claude Code’s best setup used 725k, about 5.4 times as many, also with every answer right.

Weight is what makes them slow. This one surprised me. On fresh installs, with the rules in code, all three answered in about four seconds. My own Copilot, with the same agent.py tools and nothing else running, took 56 seconds per answer and 820k tokens for five questions. The Brainstem did the same five in 35k tokens.

A robot strains under an overloaded backpack of folders, cables and tools while a light robot walks easily ahead.

Lock it in, then clear the chat. Once the rules live in code, history is mostly dead weight. A new chat for every question cut the Brainstem’s total from 135k to 90k tokens, still 45 of 45 right.

Call /chat, not a wrapper. Routing the same Brainstem through Copilot CLI and an MCP plugin cost about 7 times as many tokens per answer, and Copilot often skipped the Brainstem altogether. On my own Copilot install it skipped it every time. The MCP plugin is for hosts that cannot make an HTTP call. Everything else should call /chat.

What did not hold up

Spend does not grow exponentially. It grows with the square of the chat’s length. A chat twice as long costs about four times as much. Bad enough, but I was wrong about the word.
agent.py is not magic inside Claude Code. There, a skill with a bundled script was cheaper than agent.py tools, because Claude Code hides MCP tools until the model searches for them. It called my agent tools on 13 of 45 questions and improvised the rest. The same files inside a Brainstem were the cheapest setup of all. The host is what saves the tokens, not the file format.
Plain-word rules were not the accuracy disaster I expected. My first wording of one rule was ambiguous about rounding, and the models filled the gap their own way. Once I fixed the wording, skills written only in words got 116 of 120 answers right. They were still the most expensive setup on both hosts, and their 4 misses were real arithmetic slips. Rules written as code were right every time the code ran.
I did not test the “lobotomy”. Published studies (Chroma’s Context Rot, Lost in the Middle, RULER) report that accuracy drops as context grows. My 15-question chats were too short to show it.

The cost of ownership

Tokens are the sticker price. Keeping a setup working is the rest. In one evening of measuring:

Claude Code silently ignored an MCP config written in Copilot’s format. No error, the tools just were not there, and my first “agent.py in Claude Code” numbers measured nothing.
Claude Code rewrites $0, $1 and friends inside a SKILL.md as skill arguments, so dollar amounts in your rules can turn into file paths.
Copilot’s usage file is a running total for the whole session, which I first read as per-question.
The Brainstem’s only failure was one upstream connection reset in 30 questions.

Driving one question from a script took 13 lines of code for the Brainstem (one HTTP request), 29 lines and 8 flags for Claude Code, and 54 lines and 9 flags for Copilot CLI. And the Claude Code session I used to run all of this is itself a long chat: by the end of the measurements it had made 261 model calls and re-sent 81.7 million tokens of context, about 313k per call.

What I do now

Measure your host’s idle cost with one trivial question. That number is charged on every call.
Put repeated work in code: an agent.py, or a skill with a script.
Keep chats short. Finish a job, keep the answer, start fresh.
Unload what you do not use. Every plugin, server and skill rides along on every call.
Call a Brainstem’s /chat directly. Use MCP only where HTTP is not an option.

The full white paper, with every chart and the mistakes I caught along the way, is
The Context Tax. The bench is open source at
github.com/kody-w/token-bench, and it measures your own setup, as you actually use it, in one command.

When the Power Comes Back, the AI Estate Should Too

By Kody Wildfeuer

On September 6, 2026

In Technology

The power went out overnight, and it took down my whole home AI setup — several computers, each one in the middle of its own task.

Flipping the power back on didn’t actually fix anything. The machines came back, but I had no idea what each one had been doing, how far it had gotten, or what was safe to pick back up. A computer that turns back on isn’t the same as work that picks back up where it left off.

That’s the real problem with AI “helpers” running unattended: when something interrupts them, you can’t just reboot and hope. You need to know what each one was working on, what it had already finished, and what it’s safe to resume — because blindly repeating a step an AI already took (like sending a message or submitting a request) can cause a second problem instead of fixing the first one.

Think of it like coming home after a blackout

Imagine your dishwasher, DVR, and thermostat all lost power at once. The power comes back, but none of them remember what they were doing — the dishwasher doesn’t know if it finished the rinse cycle, the DVR doesn’t know if it recorded your show, and nobody wants to guess.

Now imagine dozens of AI assistants in that same spot at once, each one mid-task. That’s what I woke up to. The fix isn’t “turn it back on.” The fix is giving every task a paper trail — a record of what it was doing, what it had completed, and what it still needed — so recovery means picking up exactly where things left off, not guessing.

What “remembering” actually requires

To recover safely, you need answers to a few plain questions for every task in flight:

Which AI assistant was doing this, and as part of what job?
What had it actually finished, versus what it merely intended to do?
What survived the outage, and what needs to be checked before resuming?

That’s it. It’s less about fancier AI and more about good bookkeeping — a clear, trustworthy record that outlives the outage.

Why “just resume” is risky

If an assistant might have already sent a message or kicked off an action right before the power died, blindly re-running that step isn’t recovery — it’s a second, possibly duplicate action. The safe version of “pick up where you left off” always double-checks whether the last step actually happened before deciding what to do next.

This is the idea behind something I’m building called RAPP Disaster Recovery: a way to give an entire AI household a single, trustworthy view of what survived, what’s uncertain, and what’s safe to resume. It’s not finished — full automatic recovery across every device isn’t something I can promise yet — but it’s the direction I’m building toward.

The takeaway

The most useful thing an AI system can have isn’t more data or a longer memory. It’s a clear, honest record of what it was doing and what actually happened — so that when the power comes back, the work can come back with it.

If the idea of an AI helper that keeps working reliably on its own appeals to you, The Personless Harness goes deeper on what that actually looks like day to day.

This post describes an idea I’m actively building, not a finished product. If you want the deeper technical version of this, it lives on my GitHub.

The Personless Harness: Brainstem + Copilot

By Kody Wildfeuer

On August 4, 2026

In Technology

In 1895 you didn’t buy a car. You bought a horseless carriage — the new machine named for the animal it removed. The name is the whole lesson: the carriage didn’t change. The wheels, the seats, the cab — all still there. What changed was what pulled it. The horse went out, the engine went in, and the same carriage could suddenly run at a pace no stable could feed.

Here’s the same swap, happening right now, in software.

Copilot is the carriage. It’s the vehicle everyone already has — the chat window, the buttons, the place work actually happens. A genuinely good carriage.

You are the horse. Today, almost everything an AI assistant does, it does because a person is pulling: typing the prompt, clicking the button, checking the output, deciding what happens next, then pulling again. That works — beautifully, at the pace of one tired human — and it stops the moment that human needs to sleep, eat, or go to a meeting.

The Brainstem is the engine. Think of it as a second, tireless version of you: it knows your tools, remembers how you like things done, and can keep working after you’ve clocked out. It isn’t a smarter chat window — it’s the thing that can sit where you sit and keep going. Same carriage, different thing doing the pulling.

What the swap looks like in practice

This isn’t really a story about software testing. It’s a story about a new way of working — testing just happened to be the first job the engine took from me, because testing is the purest form of “a human clicks through an app after every change to see what broke.”

I had just finished a feature I believed was done. Instead of opening the app myself, clicking the toggle, and watching what happened, I handed the job to an AI agent with a real browser and a checklist, and went to work on something else.

It came back with five problems. One was serious: the page was loading with zero working code behind it, so the whole feature was just a picture of itself. Another: a switch that could be turned on but never back off. A third: a checkbox that had quietly grown too wide and shoved its own label onto three lines. None of that showed up in my usual automated tests, because it all lived in the gap between “the code looks right” and “the thing actually works when a hand touches it.” Until that day, finding it had always meant me sitting there clicking around.

I fixed the five problems, sent the AI agent back in, and it came back clean: thirty-three checks, all passing, no human involved. My status update changed from “try it and tell me what breaks” to “it’s done, and here’s the proof.”

What makes an AI helper trustworthy at this job

A few things separate a helper you can actually trust from one that just looks impressive in a demo:

It uses the real thing. Real clicks, real pop-ups, real downloads — not a shortcut that skips the part a real person would experience.
It expects the annoying stuff. An unexpected confirmation pop-up is a failure to catch, not something to shrug off. And layout gets measured precisely, not eyeballed.
It checks for things that should be missing, too. A feature that’s supposed to stay hidden until turned on, a panel that’s supposed to disappear — humans almost never double-check that something properly vanished. An AI helper can, every time.
It never fakes success. If it couldn’t actually run the check, it says so loudly. A “looks fine” that never really ran is worse than an honest “this failed.”

How much faster, really?

To put a number on it: that 33-check run, done by hand by someone who knows the app well, takes roughly twenty minutes of full attention — and you have to redo the whole pass after every fix. The AI agent finished the same 33 checks in about 19 seconds. That’s roughly sixty times faster on the stopwatch. But the bigger difference is what it costs you: twenty minutes of a person’s full focus, versus zero. I ran it four times in one evening without noticing the cost at all.

The carriage stays; the horse retires

Notice what this swap does not ask of you. You don’t throw out the tools you already use. Copilot, the app, everything you’ve already built — all of it stays. That’s why the horseless carriage caught on so fast: it didn’t ask the world to reinvent the wheel, just to stop feeding the horse.

And notice where the person goes. The engine didn’t remove people from travel — it moved them from pulling to steering. This doesn’t remove you from the work; it moves you to the seat where you decide where things go and read the results. You stop being the horse. You were never at your best there anyway.

Curious how far this can go? The Buzzsaw pushes the same idea further — instead of one AI helper checking the work, I used eight of them, arguing with each other, to catch things a single reviewer never would.

For a while, this will feel like a strange new way to work. Then, like the horseless carriage before it, it’ll just be how work is done — and the idea that a person once had to manually click through every check will sound as old-fashioned as keeping a horse for your commute.

The Ark Pattern

By Kody Wildfeuer

On August 3, 2026

In Technology

Skills drift.

You teach an AI assistant how to do something, it works, you move on. Six months later, that same “skill” gives you a different answer — because someone edited a copy, or a dependency shifted underneath it, or four different people each tweaked their own version and never told each other. The name of the skill stays the same. What it actually does does not.

That’s not hypothetical. I watched one bad instruction produce five separate wrong answers, across different tools and different AI agents, before anyone realized it was the same mistake wearing different clothes each time. Nothing announced it. Every copy looked fine on its own.

The uncomfortable part: if AI assistants everywhere start relying on shared “skills” like this, quiet drift is the real risk — not some sci-fi AI takeover, just a slow loss of agreement about what a given instruction actually does, with no easy way to check.

So I wanted a way to catch it. A backup that works even if everything around it gets messy.

The idea

My approach treats a capability as one portable file with a clear job — drop it in a folder, it runs, no setup required.

This pattern goes one step further: it puts the working code inside the plain-English instructions themselves, so the document explaining what a skill does is also, literally, the thing that does it. It reads like a normal explanation to a person, and it can also run directly as working code. There’s no second, separate copy sitting somewhere else that could quietly drift out of sync — because there’s only one copy, period.

The real benefit isn’t for me. It’s that anyone can pick up that one file, with no special setup on their end, and get the exact same behavior I do.

That’s the claim. A claim is worth nothing until you test it, so I tested it.

Putting it to the test

I built the same capability two ways: the normal way (spread across several files) and the “one file” way described above. Then I ran both versions dozens of times, side by side, and compared the results byte for byte.

Every single time, both versions produced identical output. Not “close enough” — identical.

Then I deliberately broke it: I edited the normal, spread-out version in place, the way an innocent well-meaning edit usually happens. Its output changed, as expected. The single-file version’s output did not change at all — and, importantly, the mismatch between the two was easy to spot immediately, instead of surfacing months later when two AI agents quietly disagree about what a rule says.

That’s the whole value, proven rather than assumed: one copy stayed trustworthy, and when the other one drifted, it was obvious right away.

What it costs

Honestly, some convenience. A single file can get long, and you lose the ability to test small pieces of it separately. Mine landed at a comfortable size — ten times longer would start to hurt.

I also hit a real bug while building this, worth naming because it’s exactly the kind of thing that quietly erodes trust: embedding code inside a plain-text document accidentally mangled a couple of special characters, so two of five commands printed a broken symbol instead of a proper line break. The other three were fine, because they happened to be built slightly differently.

A quick spot-check of just one command would have missed it and shipped it broken. Only checking every single case caught it — which is the same lesson every time: the check itself can be wrong too, and nobody double-checks the checker.

The pattern, stated plainly

Ship a capability as one self-contained, readable document. If the surrounding ecosystem holds up over time, you’ve lost nothing. If it drifts, you have one clearly labeled, trustworthy copy that makes the drift obvious instead of invisible.

It’s a cheap insurance policy against a quiet, slow-moving risk — and so far, it’s the best way I’ve found to share something’s strengths with people who have no interest in adopting my whole system, just the one useful piece.

It’s the same lesson at the heart of The Buzzsaw: the thing meant to keep you honest can quietly become the thing you stop questioning.

Update: it holds up beyond one example

One capability working this way could be a fluke. So I automated the conversion process — turning a normal, spread-out capability into the “one file” version automatically, and refusing to finish if even a single byte comes out different — and tried it on two more capabilities.

All three matched perfectly, every time, without needing anyone to hand-check the conversion. That the conversion itself is automatic matters more than any individual result — if a person had to convert each one by hand, that manual step would become a brand-new place for drift to sneak back in, which defeats the whole point.

One test along the way even reported a false alarm — the two versions looked “different” only because of an unrelated quirk in how I’d named the test files, not because the actual code differed. Worth mentioning honestly: that’s now the eighth time in this stretch of work that a reported failure turned out to be a flaw in the test itself, not the thing being tested. I’ve started treating that as the normal rate, not a fluke — which is exactly why checking your checks matters as much as checking your code.

Every number in this post comes from a script anyone could re-run, and it fails loudly if the equivalence claim doesn’t hold. If it had failed, this post would say so.