I open-sourced voice-tunnel last week, a local CLI that gives your coding agent a two-way voice channel to your phone browser. No app, no account, no cloud speech API, no GPU.

I wanted my own Jarvis, driving my own coding agents by voice while I’m out of the house. Every route to that was somebody else’s service: an app from the store, an account to create, a subscription to pay, and my speech leaving my machine to come back as text from someone else’s servers. I didn’t want to install or pay for any of that.

This has been sitting in my inbox since June 18th:

I want to be able to talk to my claude from my phone. Like I talk on the phone, say stuff and claude says stuff back, but talks fast like a real person […] I should be able to interrupt. I wonder if something like this exists, I bet it does

It did exist, in pieces. Every ingredient was shipping somewhere, and none of the assemblies were the shape I wanted, so I built the one I wanted.

Speech got good enough on a CPU

The reason to accept somebody else’s service used to be a real one. Recognition wanted a GPU or a datacenter, decent synthesis wanted the same, so sending your voice off the machine was the only route that worked at conversation speed.

Recognition runs on Parakeet TDT 0.6B v2, a 600-million-parameter model that sherpa-onnx ships as an int8 ONNX build. On my 20-core desktop CPU that’s a real-time factor of 0.114, so 7.4 seconds of speech comes back transcribed in 0.85 seconds. Synthesis is Piper (GPL-3.0, pip install piper-tts), loaded in-process and warmed when the server starts instead of spawned per reply, which made synthesis 7 to 26 times faster depending on the length of the line.

Neither number came from tuning. The first live session did recognition in 2.64 seconds and spoke in the robotic system voice your OS ships with, so the good numbers came from replacing both.

All of it fits in 219 MB at minimum and about 1.0 GB with the better models loaded, and there’s no GPU path at all, the word CUDA does not appear anywhere in the source. So the speech half runs on the same machine as the agent, on hardware I already own, and it costs nothing per minute of talking.

The intelligence is the agent you already run

The tool holds no model and makes no decisions. It turns your speech into lines in a log and text into speech, and the agent that started it does all of the thinking. What answers you is a coding agent with real reasoning, on your own harness, with your tools and your repo already in front of it.

If your AI agent can run Bash, it can use this and it can talk to you.

Claude Code, Codex and Grok have each driven it unchanged, and I wrote an integration for none of them. Driving this is running a command and reading what comes back, which is the one capability all of them already have, so the set of agents that work isn’t a list I maintain and it grows without me.

The conversation is three commands. serve opens the tunnel, watch blocks until you say something and returns every turn after the cursor it was handed, say speaks a line back. voice-tunnel describe returns all of it as JSON, so onboarding is one call, with no MCP server to configure and no documentation to keep in sync.

The cursor is what makes the split safe. Your agent can spend thirty seconds thinking about the last thing you said and every word you spoke in the meantime is still waiting when it comes back to watch.

I’m not claiming nobody else does local voice to a phone. Paseo has 13k stars and runs the same local Parakeet and Kokoro models on CPU over your own Claude Code and Codex sessions. The shape I wanted was smaller: a CLI tool that any AI agent which can run Bash can use, and that’s it. I didn’t want to create another cloud. Paseo is a daemon, native apps and a pairing flow. This is three verbs and a log file. I’ve written about why I keep picking that side in Stop Building Another Claude.

Shipping a release while running errands

The video at the top is one real session with the phone in my hand, “can you hear me”, then shipping a release end to end. The skipped Ns badges are the agent thinking, and I left that time visible instead of cutting it out. Fifteen to thirty seconds a turn is normal, that’s a reasoning agent running commands on your machine and it’s the trade I took deliberately, the tunnel’s own half of the round trip is about two seconds.

I’ve done the same thing on a Saturday morning away from my desk, phone in hand and nothing else, which is where it stopped being a demo for me.

Two pieces do most of the work of making it feel like a conversation. Turns end when you sound finished rather than when a fixed silence timer runs out, so a finished question closes early and a trailing “I was thinking that maybe we could…” gets room. And you can interrupt it mid-sentence, but only you can, a voiceprint has to agree before a reply stops, so the television and the agent’s own voice leaking back through the speakers both leave it talking. The gate is a similarity score against my enrolled voiceprint, and one second of audio is enough to run it.

I sent agents to read the prior art for me

Reading code that isn’t yours used to cost a week, so mostly you skip it and rebuild what someone already solved. Before writing anything I sent agents into VoiceMode and HuggingFace’s speech-to-speech with instructions to come back with what was worth taking, and that’s the part of this build I’d repeat on anything else.

It paid for itself in an afternoon. VoiceMode had built a browser transport and then deleted all of it, which told me local-to-phone was the hard part before I’d written a line. And I’d been hand-tuning a silence timer to decide when you’d stopped speaking, always wrong in one direction or the other, when the HuggingFace repo turned out to run an 8 MB model that decides it by listening to how the sentence lands. It’s in the tool now, and that’s Smart Turn above.

Two commands

npm install -g @juanjofuchs/voice-tunnel

Then paste this to your coding agent:

Run voice-tunnel describe and follow it end to end: install anything missing, start the tunnel under your own name, give me the URL to open on my phone, and then stay in watch so you can hear me.

That’s the whole handoff. Your agent installs the engines and downloads the models, then starts the server and hands you back a URL. Open it on your phone, tap once, say “hey Claude, can you hear me?”

The one thing your agent can’t do for you is HTTPS. A phone only hands a web page a microphone in a secure context, and getUserMedia is HTTPS or localhost only, so a plain LAN address like http://192.168.1.20:8765 gives you no microphone at all rather than a broken one. Run tailscale serve --bg 8765 and use the address it prints, and your agent will tell you when this applies.

This post was interviewed through it

The interview that produced this post was held over the tunnel, from my phone, the agent asking me the questions and reading my answers back to me off the turn log. If your AI agent can run Bash, it can use this and it can talk to you.

Repo: github.com/JuanjoFuchs/voice-tunnel, MIT licensed, published on PyPI, npm and WinGet. Issues and PRs welcome.

A few days ago I couldn’t remember what made me add a Prompt field to my commit messages.

It’s my own rule, written in my own guide, and it’s the format every substantive commit has used since. I knew what the field does and why it’s there. What I’d lost was the incident behind it, the specific problem that made me stop and change the format.

So I asked the log:

git log --oneline -S "Prompt:" -- "Git Commit Guide.md"

45944fd Rule that dictated prompts get annotated, never rewritten
4b4e72f Add Prompt field to commit format to preserve user intent verbatim

4b4e72f is from May 12th, 81 days before the day I ran that query, and it answered me in the sentences I typed at the time. Part 5 of this series ended on the line that the git history is a knowledge layer of its own, every decision I made about every idea queryable, and that it deserved a post. This is that post.

It could only answer that way because of what’s sitting in it. Strip the Prompt field out and the same query still finds the same commit, and what comes back is Claude’s account of what I meant that morning, written by Claude, approved by me, and by then the only version anyone has. That’s what a git history holds by default. Mine held exactly that for its first 450-odd commits, and I’d bet yours is holding it now.

The Log Holds a Different Record Than the Notes

My vault is a folder of markdown notes in a git repo. The phone pushes it, my agent commits to it, and I review the diffs before anything lands. So the history exists. The question is what’s in it.

Git stores the files, and the commit message stores an account of why they changed. In an agent workflow that account gets written by the agent. I read it, approve it, and move on. Six months later it’s the only record of the decision, and every sentence in it is Claude’s version of what I said.

That’s memory rot, and it’s quiet while it’s happening. Each commit body is a reasonable summary. Nothing is wrong on the day. The loss shows up when a future agent reads the log to understand a decision and gets an interpretation of an interpretation.

Dylan Zhang measured what that costs. In his paper Useful Memories Become Faulty When Continuously Updated by LLMs, GPT-5.4 solves problems from the ARC-AGI reasoning benchmark at 100%, then consolidates what it learned into memory using the ground-truth solutions to those exact problems, and drops to 54%. Every input was correct. The rewriting is what corrupted it. His design rule is the one I care about: “Raw episodes are first-class evidence, not material to be compressed away.”

The fix is one field. Put the verbatim prompt in the commit body, above the reasoning, so my words sit on top and the agent’s account sits underneath and both survive. The notes hold the content, the log holds why the content changed and the words that changed it.

What Goes in the Commit

The format:

Short summary of the change (imperative mood)

Prompt: "Verbatim prompt(s) that initiated this work."

Motivation: What was wrong, missing, or insufficient.
Decision: What we chose to do about it.
Why: The reasoning behind that choice.

Prompt goes first because it’s the only tier-1 record. Motivation, Decision and Why are useful and they’re an interpretation, so they sit below the thing they’re interpreting. When the two seem to diverge, the Prompt wins.

The label drifts depending on how the words arrived, my last few commits say Prompt (spoken, live over the voice tunnel, across three rounds): and Prompt (spoken, live from the car):, which is provenance I want and didn’t plan for. The position is the part that’s fixed.

I quote the prompts that carried a judgment, where I set a criterion, made a trade-off, or picked a direction. I skip the “ok do it” and “looks good” turns, there’s no judgment in them. Two or three prompts usually cover a session.

I dictate most of my prompts and the transcription mangles names. “clot code” for Claude Code, “dash dash bear” for --bare. Those get a bracketed gloss and the original stays put:

Prompt: "help me document how to invoke clot code [Claude Code]
        programmatically from outside of clot code, like from Codex"

The gloss never replaces the original. A dictation error is mechanical and visibly wrong, nobody is fooled by “dash dash bear”. An LLM’s correction is fluent and invisible and it reads as authoritative, so the evidence of a misunderstanding is exactly what gets polished away. Clean up the field and it becomes Claude’s output, which kills the only reason it’s there.

I don’t commit every change. I commit at the end of a session, in logical units, one coherent change per commit. If I’d write two different Motivation paragraphs for two sets of edits, that’s two commits. When I forget to commit at all, I use sb, a small CLI in the vault that wraps git and the Claude Code session logs behind one command. sb sessions and sb prompts read those logs back and return what I actually typed, so the commit can still carry the real words.

Why the Commit and Not the Session Log

Claude Code keeps session logs, and they hold prompts verbatim, so the raw words already exist somewhere. Those files belong to Claude Code. They live in its directory, under its retention policy, with a default I didn’t choose and a setting I can change but don’t own. The vault and its git log are mine.

That’s why the prompt goes in the commit body instead of staying a pointer to a session file. The record has to live in the thing I own, in a format I chose, next to the change it explains, and it has to still be there when the tool that produced it isn’t the tool I use anymore.

The May 12th commit, trimmed:

Add Prompt field to commit format to preserve user intent verbatim

Prompt: "When I use the term 'raw fallback,' I am referring to the
        prompts that I am sending to the AI agent with my judgment and
        my criteria... The only things that are truly raw are my prompts."
        "I think we need to keep some sort of verbatim copy of my prompt,
        regardless of how long the session is or how many terms we do
        before committing..."

Motivation: ...every paragraph in the body is Claude's distillation of
what I asked for, even when I approve it...

Why: This is the Faulty Memory paper applied to my vault...

The two quoted fragments are what I actually said. The Motivation and the Why underneath are Claude’s account of the same conversation, useful and one interpretive layer removed from it. The second fragment is the rule in one sentence, keep a verbatim copy regardless of how long the session is.

You Don’t Have to Learn Git

My agents write every commit message in the vault, and they’re expert git users. bisect, blame and the pickaxe are arcane enough that most of the people who’d get value out of a queryable history never learned them, and that barrier is gone. You describe what you’re looking for and the agent runs the plumbing.

So the history was already there. Every change to every note, with a message explaining it, and several ways to query it. What was missing was that the message held the agent’s account of my thinking, and the Prompt field is what closed that.

The commands, for anyone who wants to run them by hand:

git log --oneline -i --grep "memory rot"            # commits whose message mentioned it
git log --oneline -S "Prompt:" -- "Git Commit Guide.md"  # where that exact text was added or removed
git blame "Git Commit Guide.md"                     # which commit put this line here
git log --oneline --follow -- "Git Commit Guide.md"  # the file's history, across renames

--grep searches commit messages, and the -i matters more than you’d think, without it you miss every commit that capitalised the thing differently. -S is the pickaxe, it finds commits where the number of occurrences of a string changed, so it lands on the moment text was written or deleted. blame gives you a hash per line and git show <hash> turns that hash back into the Prompt and the reasoning.

What I actually run is a wrapper:

sb log "memory rot"

# Read the Prompt field first — it's JJ's words (ground truth); Motivation/Decision/Why is the agent's interpretation.

2000c9b Capture the Part 6 interview: the spine, one agent's error, and the hero concept
2700627 Add SkillOpt + Algorithmic Monocultures articles and linguistic relativity concept
bcc6dac Add self-improving-agents-without-memory-rot synthesis note + second-brain seed

sb log wraps git log --grep. It finds the commits and it also tells whatever is reading them which part of the message is mine and which part is Claude’s, so the ordering rule from the guide travels with the results.

That’s what makes keeping the history worth anything. A log I can’t interrogate is an archive I never open, and that’s what git was for anyone who never learned the plumbing. Now I ask in English and get an answer.

What It Costs

Storing the prompt costs one field in a commit message, plus the discipline to paste in what I typed instead of what we agreed it meant afterwards. Everything else was already there, the vault was already a git repo, my agent was already writing the commit messages, I was already reviewing the diffs before anything landed.

Eighty-some days isn’t long. I’ve got commits in there from February and I’ll be reading them next year, and by then I’ll have forgotten a lot more than one commit rule.

Two Claude Code add-ons blew up this summer. caveman is a skill that makes your agent narrate in pidgin so it writes fewer words, and the repo description calls it a “Claude Code skill that cuts 65% of tokens by talking like caveman.” rtk is a “CLI proxy that reduces LLM token consumption by 60-90% on common dev commands,” which compresses shell output before your agent reads it. Between them they have more than 167,000 stars.

Denis Shiryaev at JetBrains ran both through paired A/B benchmarks, same tasks, same model, one arm with the tool and one without. caveman came out at 8.5% fewer output tokens across the 82 SkillsBench tasks where both arms ran cleanly, 592k down to 542k, about 240 billed trials, roughly $106. rtk came out more expensive, “a median +7.6% more expensive per task (p=0.004)” at low reasoning effort and flat at high effort, “+0.1% (p=0.99),” across 86 tasks and 425 trials for about $320. Quality was unchanged in both. Meanwhile rtk’s own dashboard reported 96.2 million tokens saved, 99.8%, while the bill went up.

If you installed either one because the star count said it was worth installing, you bought a number nobody measured on your work. And the star count is what most of us use to decide.

Both authors ran the evals

Neither of these is somebody overselling on purpose.

caveman ships benchmarks/ and evals/ directories with results committed and reproducible, plus a file literally called docs/HONEST-NUMBERS.md covering when the skill wins, when it loses, and how to check for yourself. The README scopes the claim before a critic could: “Caveman only shrinks output tokens.” Input and reasoning tokens go untouched, it discloses the skill’s own overhead of roughly 1,000 to 1,500 input tokens per turn, and it gives the range behind the 65% average, 22% to 87% across ten prompts.

rtk goes further and concedes the criticism inside its own README: “RTK cuts up to 90% of the bash output your agent reads. That is what RTK measures, and it is not the same as cutting your bill by 90%.”

Before I lean any harder on those benchmarks: JetBrains isn’t a neutral referee, they sell their own repository intelligence layer for coding agents, shipped the same month as these two write-ups. The methodology and harness are public, so anyone can check the work. It’s still two tools, one category, one person measuring, and token savings is the category most prone to counterfactual problems.

Shiryaev’s verdicts land where the two READMEs already were. caveman is “safe, honest about style, oversold on savings.” rtk is “Honest engineering, wrong counterfactual,” the counterfactual being the run you’d have had without it.

Why the 65% never reaches your bill

Both gaps come from the same place.

caveman’s 65% is real for what it was measured on, chat-style prose where the narration is the output. Agentic coding output is mostly code, diffs, tool-call payloads and error strings, and the skill preserves all of that byte-exact on purpose. What’s left to compress is the narration between tool calls, a thin slice, so crushing it hard still only moves the number by single digits.

rtk’s counter compares its compressed output against the full raw output, and that raw output was never going to be billed. The Bash hook it works through only ever sees about 20% of what comes back from tools, because Claude Code’s own Read and Grep never pass through it. Those 96.2 million saved tokens are measured against a session that never happened.

The author’s side of this is reasonable and I’d do the same thing. If I have an idea that works on my machine, I want to share it. I’m not going to spend weeks and a pile of tokens proving it holds up in every scenario somebody might throw at it, that stops being sharing an idea and turns into software engineering. The caveman author measured what they had, on ten prompts, and wrote the range down, more than most people do.

The failure is on my side, when I install it because the number looked good. I inherit the distance between their setup and mine, and they never agreed to own that distance. It’s the shape I wrote about last week with vibe coding, one layer down: they decided how far their own effort would go, and installing their work makes everything past that point mine.

A star means somebody liked the idea

Both repo descriptions still carry the naked headline, the 65% and the 60-90% and nothing else. The 22-to-87 range lives in caveman’s README. The scope caveat lives in docs/HONEST-NUMBERS.md. The paragraph where rtk’s author says its metric isn’t your bill sits several screens down.

A star carries none of that. It’s one click, and the click can mean almost anything. Someone thought the idea was good. A few wanted the repo findable again next month. Plenty read “why use many token when few token do trick,” laughed, and hit the button on the way past without installing anything at all. Every one of those is a real signal about an idea, and not one of them is a run on your codebase against a baseline. A star has never been a measurement, least of all one taken on your work.

Philipp Schmid from Google DeepMind opened his AI Engineer World’s Fair talk, Don’t Ship Skills Without Evals, by polling the room. Everyone used skills, and on the show of hands, “no one has evals.” (Quotes from the talk transcript, spoken filler trimmed.)

caveman and rtk are the well-documented ones. If the two with committed benchmark directories don’t transfer to your work, the median one isn’t going to either.

None of this says skills don’t work. In the same talk Schmid puts the average gain from a skill at roughly 15% across about 100 SkillsBench tasks, and the format is fine. A folder with a SKILL.md is a good way to move a practice around.

You can’t debug a skill you never read

Money is the easy cost to see. The expensive one is diagnosis.

When an agent run goes badly you’re already choosing between the model being off and the task being too hard for it. Schmid says as much from the author’s side: “you might not know if your task fails because your skill is bad or if your task fails because it’s way too challenging for the model.” Install something you haven’t read and you add a third suspect you can’t investigate, because you don’t know what it’s telling your agent to do.

Geoffrey Huntley put it plainly: “LLMs are essentially mirrors. They mirror the skill of the operator.” He means your craft there. Copying somebody’s folder into your setup transfers their file, not their craft.

What I do instead of installing

I read them. Point an agent at the repo, have it read everything and explain the actual idea, what’s good in it and what doesn’t apply to how I work. Have it strip the scaffolding, the edge cases, and the productionization for people who aren’t me. What’s left is usually small. Then it interviews me on how I really do that task, and the output is a guide in my vault, in my words, routed from AGENTS.md so I know when it should fire and can tell when it didn’t.

Two sizes of outcome. The big one was John Lindquist’s claude-imps, one natural-language front end per CLI so you never read --help again. I took the idea and dropped the packaging: his runs on Bun and the Claude Agent SDK, and I wanted a deterministic parser handling the common case with no model at all. What came out is a PowerShell version and a guide I own. Installing would have been one command, this took real work, and the result matches how I work.

The small one was Matt Pocock’s grilling skill, which I wrote up in how I write specs with AI. Twelve lines and 136 words including the frontmatter, barely a hundred words of actual instruction. All the value is in the idea, and the idea doesn’t need a folder: make the model interview you down every branch of the design tree. I’ve used it on every spec since.

Most people skip routing, but it decides whether the skill fires at all. Vercel ran evals on Next.js 16 APIs that weren’t in the training data, and in 56% of cases the agent never invoked the available skill at all. Their skills arm passed 79% of the eval tasks, an AGENTS.md docs index passed all of them, against a 53% no-docs baseline.

I’d be refuting my own post if I handed you that 47-point jump as proof. The comparison moved three things at once: whether the knowledge was always in context, what the knowledge actually was, and how it was formatted. It’s a direction, not a clean measurement of routing, and Vercel benefits from AGENTS.md catching on. Lulla and co-authors measured AGENTS.md across 10 repositories and 124 pull requests and got the same direction, a median 28.6% cut in runtime and 16.6% in output tokens. I do it because it’s held up across my own repos and my vault since January.

Skills still fit the explicit one-shot workflows you trigger on purpose, and I said as much launching atref, my tool for pulling vault guides into any agent: a skill is a distribution mechanism, and I don’t have a distribution problem.

The other reason the knowledge lives in my own files is that the agent race isn’t over. I made that argument back in March: the process knowledge is ours, everything else is becoming commodity. If Codex wins next quarter, a vault of guides comes with me, and a folder of installed skills is somebody else’s format in somebody else’s directory.

Keep the skill if you want it. Just know what’s in it.

Anthropic already ships the harness

The objection to all of this is that reading and distilling every skill you meet is more work than one install command, and running a real A/B is worse. The second half stopped being true.

Anthropic’s own skill-creator, the skill they publish in their open skills repo, already includes the harness. It tells you to “spawn two subagents in the same turn,” one with the skill and one without, then use the time while those runs are in flight to draft the quantitative assertions you’ll grade them against. It captures total_tokens and duration_ms for both arms, grades the outputs, and ships a viewer for the results. The paired method Shiryaev spent about $426 on across two benchmarks is sitting inside the tool people use to write skills.

Schmid’s version is one sentence: “…always try to run evals with and without the skill enabled. And if the model achieves the performance without even triggering the skill, you know you can retire that skill.”

Shiryaev’s closing line from the rtk benchmark is about compression tools, and it holds for anything you’re deciding whether to adopt: “If you evaluate any context-compression tool, measure the paired bill, not the tool’s diff.”

Someone on the business side ships a tool now. Not a mockup, not a spec handed off to engineering, an actual working app that does what they needed, built in an afternoon with an AI writing all the code. A year ago that idea sits in a backlog waiting for engineering priority. That bottleneck is gone, and it’s a real win.

Then a few weeks later the app starts leaking customer data, or it falls over under load, or it needs a change nobody can safely make, and it lands on an engineer’s desk. An engineer who didn’t build it, didn’t choose the stack, wasn’t in the room for a single decision that shaped it. Now they own keeping it alive.

AI gave the person shipping the software a new freedom, and handed the bill for it to somebody else.

Everyone’s a builder now

Andrej Karpathy named the thing in early 2025: vibe coding, where “you fully give in to the vibes” and “forget that the code even exists.” Simon Willison offered the grown-up cousin, vibe engineering, for pros who accelerate with LLMs while “staying proudly and confidently accountable.” Most of the people shipping software now are doing the first one, giving in to the vibes.

And it’s not a niche. The SF Standard reported that “everyone’s a builder now”, with product managers at Meta and LinkedIn adopting the title and Sal Khan predicting everyone will become one. TELUS says team members across all departments have created 13,000+ custom AI solutions. UpGuard found 81% of employees already using AI tools their company never approved. The people building software now mostly aren’t engineers, and they’re not waiting for permission.

This is genuinely good. The old world had the opposite failure, great product ideas dying in a queue because engineering never had time. The domain expert who understands the problem can finally build for it directly.

The open door

The philosopher Isaiah Berlin had a useful split for this, negative and positive liberty: freedom from constraint, and the actual capacity to do something well with it. You can have one without the other. An open door is not the same as the ability to walk through it.

AI gave the vibe coder a huge amount of negative liberty. The bottleneck that used to stop them is gone. It didn’t give them the positive liberty, the skill to build something that holds up once real users hit it. AI opened the door but didn’t teach anyone to walk through it.

Three skills out of four

Ben Werdmuller has the sharpest breakdown of what building software actually takes now. In “Good Vibes, Bad Vendors” he lists four skills that matter once implementation stops being the bottleneck: crafting clear goals, understanding users, being explicit about the experience and value you want, and considering architectural implications.

Look at where those skills live now. The first three, goals, users, value, are exactly what a good product manager or domain expert already has. That’s why they can suddenly ship, they were always closer to the problem than the engineer was. The fourth one, architectural implications, performance, security, maintenance, the part that decides whether it holds up, is the one that stays with the engineer. Werdmuller’s own conclusion is that “an engineer must be involved from the beginning.”

That fourth skill is the one that governs survival, and it’s the one the vibe coder doesn’t have. The numbers say so. Veracode tested over 100 models and found AI-generated code introduced a security flaw in 45% of cases, and the newer, larger models didn’t do any better. Lovable, one of the popular build-an-app tools, had 170 of 1,645 sampled apps exposing user data through a misconfiguration a non-engineer would never think to check.

What failed is the fourth skill, the one nobody consulted.

The maintainer inherits the gap

The engineer who picks it up is now the maintainer of a system they didn’t design and can’t fully see inside.

A developer put it perfectly on the Stack Overflow podcast earlier this year: “I used to be a craftsman whittling away at a piece of wood to make a perfect chair, and now I feel like I am a factory manager of Ikea.” AI does the fun part, and the person is left reviewing thousands of lines of code they didn’t write.

I’ve written before about cognitive debt, the understanding of a system that lives in people’s heads and erodes when nobody holds it. This is a worse version. The vibe coder holds whatever theory the system has, they made the decisions, but they’re not accountable for keeping it running. The maintainer is accountable but never held the theory. It’s cognitive debt that can’t be paid down, because the person who understands the system and the person accountable for it are two different people.

Who owns the gap?

Every company that let non-engineers ship software with AI now has this gap, and almost nobody has named who owns it.

Joe Reis has a good frame for why this stays unanswered. His line is “you ship your org chart”, the seams in your software match the seams in your organization. Ownership of that gap is a hot potato, because owning it means being accountable for it, and nobody volunteers for accountability they can dodge. He cites survey data where 75% of data teams have no owner for their data products, against 85% that have a clear owner for infrastructure. People own the plumbing, almost nobody owns what’s running through it.

We’ve run this movie before, without the AI. The JPMorgan “London Whale” lost about $6.2 billion in 2012, and part of the risk model that hid the danger was a spreadsheet a quantitative modeler built by hand, where one step divided by the sum of two numbers instead of their average and understated the risk. A citizen-built tool doing mission-critical work, updated by manual copy-paste, owned operationally by no one. That was Excel and one desk. Now it’s every department shipping apps, at the speed and scale AI makes possible.

Name the owner

None of this is an argument that non-engineers shouldn’t build. The pre-AI version, where good ideas died waiting for an engineer to have time, was worse, and I don’t want it back. Speed at the front of the process is a real gain and it should stay.

The fix is to stop pretending the gap isn’t there. Positive liberty doesn’t arrive with the tool, it has to be built on purpose, and it’s more an org design problem than a technical one.

Two moves help. Put the engineer and the citizen builder on the same team from the start, what Gartner calls a fusion team, where a business owner and a technical lead share accountability for the outcome. The architectural fourth skill gets into the room while the choices are still open. A review gate after everything ships is too late, the decisions are already locked in.

Better still, have the engineer build the loop instead of the app. Set up the verification the work has to pass, the checks for performance, memory, and security, the guardrails that fail loudly, and let the citizen builder move fast inside them. The engineer builds the system that keeps the built system honest, and the domain expert keeps the speed.

Take this back to your own org. When someone outside engineering ships software, who owns the gap between “works” and “works reliably at scale,” and did that person have any say in the decisions that made the gap? If you can’t name them, you haven’t removed the bottleneck, you’ve just moved the bill downstream and hidden it.

Every post in this series so far assumes you already have an idea worth writing about. The spec has to spec something. The editorial loop has to edit something.

This post is the origin story, where the input comes from.

The Idea Problem

Ideas don’t arrive on schedule. They show up in the shower, in the middle of a meeting, while reading something completely unrelated to what you’re supposed to be doing. And they leave just as fast. By the time you’re back at your desk with a free moment, the idea that felt sharp an hour ago is gone.

Most of my good ideas used to die that way. They weren’t bad, I just had nowhere to put them the second they appeared.

So the first job is catching the idea before it evaporates.

Ubiquitous Capture

My inbox is the daily note. One file per day, named for the date, 2026-07-14.md, sitting in the vault root. Anything that crosses my mind goes into it the moment it happens, half-formed and badly worded. No structure, no folders, no deciding where it belongs. The only rule is zero friction, because friction is what kills capture.

Most of it gets dictated. I use Wispr Flow and just talk, usually while walking, and the text lands in the daily note. The phone runs GitSync, which commits and pushes the whole vault folder on its own, when I close Obsidian or on a schedule, so a thought I dictate on a trail is already waiting in the repo by the time I sit down and pull.

Dump the whole chain of thought, not just the idea. The conclusion on its own is useless three weeks later, because the reasoning that got me there is exactly what I can’t reconstruct. So I ramble. I say why it occurred to me, what it reminded me of, which part I’m unsure about, what it might connect to. It’s embarrassing to read back, and it’s the most valuable thing in the capture, because months later that ramble is the only record of how I was actually thinking.

The reason this works is background thinking. You catch a rough thought, then you go back to living your life, and your brain keeps chewing on it without you. A few hours later a second piece shows up, then a connection to something you read last week. Those go into the same daily note. The idea gets richer while you’re doing the dishes.

This is the one advantage we still have over the models. AI has no shower, no walk, no idle stretch where connections form on their own between unrelated fields. I wrote a post about that. Capture is how you cash in on it, you offload the remembering to a file so your brain is free to keep making the connections it’s actually good at.

By the end of a week the daily notes hold a pile of raw material. Some of it is gold, most of it is noise, and none of it is sorted. That’s where the processing comes in, and it’s where almost every “second brain” setup I’ve seen goes wrong.

The Clarification Standard: What Everyone Else Gets Wrong

I’ve read a lot of the Claude + Obsidian setups going around. Most process the inbox by sorting: read the items, decide which folder each one belongs in, move it there. Some ship it as a skill, some as a prompt, some as a CLAUDE.md workflow, but the shape is the same: sort the notes, empty the inbox. A few go further and run a real clarify step, asking what the item is before it moves.

Almost none of them search what you already wrote before filing it.

That’s the step that changes the outcome, because an idea only means something against what’s already in your head. Route an item without checking the destination and you’ve just relocated the problem. The idea is now sitting in a someday-maybe folder, which in GTD is the incubation list for things you might do but aren’t committing to now, the one you’re supposed to re-read at every weekly review. Skip that review and it’s exactly as dead as it was in the daily note, except now it looks handled.

The fix I use is the GTD two-minute rule, bent for knowledge work. The original is about doing: if a task takes less than two minutes, do it now instead of tracking it. Mine is about understanding first, before an item leaves the inbox I spend up to two minutes working out what it actually is. Then the original rule still applies on top, if whatever falls out of that takes less than two minutes, I do it right there instead of writing it down for later.

Understanding means three questions, in order:

1. Does the destination already cover this? Search the vault first. More of my captures than you’d expect turn out to be a note I already wrote down, sometimes better, months ago. If it’s a duplicate, that’s a finding, not a failure.
2. What is this, really? A next action, a new angle on an existing project, a duplicate, or an open question I can’t resolve yet. Naming the type decides where it goes.
3. Is there a next action to surface? If the idea implies something to do, that action gets written out explicitly so future-me doesn’t have to reconstruct it.

Each type gets a home. A next action goes on the relevant project, a new angle updates the note that already covers it. A duplicate gets merged into the original and deleted, an open question I can’t resolve yet becomes its own note that waits for more captures.

The difference shows up fast. Take a real capture of mine, dictated in June: “cognitive debt, technical debt and also taste debt/rot.” Sorted the folder way, it lands in blog-ideas as a one-liner and sits there forever. Processed with clarification, two minutes of searching turned up something I didn’t expect. The vault had plenty to say about cognitive debt, and plenty to say about taste, but the two bodies of work had never touched each other, they only ever met through index pages. The search didn’t find the note I was looking for. It proved the note didn’t exist, and that the capture was the bridge between two things I’d been circling for months. Those three concept notes got written that same day because the search is what showed they were missing, and the post came out of the gap. The only variable was whether I looked before I filed.

Git as the Safety Net

Clarification lets me be aggressive about deleting.

Once I’ve understood an item and found it’s a duplicate, or already resolved, or just not worth keeping, I delete it. No someday-maybe limbo where ideas go to look busy. I can do that without flinching because the vault is a git repo. Git is the version-control system most engineers use for code: every time you commit, it saves a snapshot of your files, and each commit carries a message where, by convention, you write down why you made the change.

The convention I follow is one idea, one commit. When I process a capture, the commit message records where it went and why, the motivation behind the idea and the decision I made about it. Deleting a duplicate writes down that I found one, with a pointer to the original.

Months later I can ask the history where something went:

git log -i --grep "taste debt"    # commits whose message mentioned it
git log -S "taste debt"           # commits where the text was introduced or removed

The first searches commit messages, and the -i matters more than you’d think, without it you miss every commit that capitalised the thing differently. The second is the pickaxe: it finds commits where the number of occurrences of the text changed, so I can see the exact moment a note’s text was written or deleted, and read the reasoning I left at the time. An idea I killed in March is fully recoverable in July.

Obsidian will keep old versions for you, File recovery is on by default and snapshots every few minutes. What a snapshot can’t tell you is why. It gives you the text back without the thinking, and the thinking is the only part I actually need when I come back months later. The git history is a knowledge layer of its own, every decision I made about every idea is queryable. That’s a post of its own (Part 6).

The Loop Closes

The path, capture to publication:

Capture the rough thought in the daily note → Clarify it against what already exists → Route it to a project, a concept note, or the trash → Spec it when it’s ready to become a post (Part 3) → Draft it → run the Editorial Loop (Part 4) → Publish.

The taste-debt post traced that exact path. It started as one dictated line in a daily note, got clarified into the bridge between two clusters that had never met, and got routed into three concept notes that didn’t exist before the search. It sat there for a few weeks collecting more captures, then became a spec, a draft, and a published post. I can walk back through every step in the git log because each one is a commit.

And then it feeds itself. A published post brings reader replies, a comment that disagrees, a question I didn’t answer, my own second thoughts reading it live. Those are new captures. They go back into the daily note, and the loop starts over.

We have a name for what happens to code when you keep taking shortcuts, technical debt. We’re getting a name for what happens to a team when AI writes faster than anyone can keep up, cognitive debt, the gap between what the system does and what the people understand it to do. There’s a third one, and AI runs it up faster than either.

Call it taste debt. Technical debt is shortcuts in how the code gets built. Taste debt is shortcuts in the judgment you apply to what gets built, the decisions you let the AI make and rubber-stamped because the output looked fine. It piles up in the product itself, one un-examined default at a time, until the product you shipped is a little less good than what you’d have chosen if you’d been looking.

The decisions you didn’t make

You can’t apply judgment to everything, and you shouldn’t try. Plenty of what the AI decides doesn’t matter, the name of some internal variable, which of two equivalent libraries it reached for, the shape of a helper you’ll never read again. Let those go. But some of the decisions do matter, and when you rubber-stamp those the same way, they accumulate. Each one is small, the product still works, it just drifts a little further from what good would have been with every default you wave through.

That drift is why what the AI builds for you can feel a bit off, working but not quite what you pictured, a parallel dimension version of what you had imagined. That’s taste debt, cashed out in the product. And like technical debt it’s recoverable, you can go back, look hard at the decisions you skipped, and pay it down. You just have to notice it first.

Debt vs rot

That’s the debt, and debt is recoverable, it sits in the work and you can go back and fix it. There’s a second thing, and this one you can’t fix by going back. Call it taste rot.

Taste debt piles up in the product. Taste rot happens to your palate. Live on the model’s first draft the way you’d live on fast food, taking whatever it hands you because it goes down easy, and your taste for the real thing fades. You stop being able to tell what’s genuinely good from what only looks good, the exact judgment that keeps the debt from piling up. The two feed each other, a duller palate waves more defaults through, and more defaults pile up more debt. You can pay the debt down, but the palate comes back only the way you’d retrain any palate, by tasting good work on purpose until you can tell the difference again.

The evidence, and what it actually shows

There’s a study everyone reaches for and it doesn’t say quite what people want it to. Anthropic ran a controlled trial, 52 developers working in a software library they’d never used. The group that leaned on AI scored about 17% lower on a follow-up quiz than the group that wrote it by hand, almost two letter grades, and the biggest gap was on debugging. The ones who delegated hardest learned the least.

That’s real, but it measures coding skill, not taste, so I won’t claim it proves your palate rots. What decayed most was debugging, the ability to look at code that runs and tell whether it’s actually right. That’s the seed of taste. Taste is built out of a thousand small judgments about good and bad, and debugging is one of the most concrete. If that’s the first thing to go when you stop doing the work yourself, the rest of your judgment goes the same way.

Put your taste in the evals

The way to keep taste debt from piling up at AI speed is to put your taste into evals, automated checks that grade the AI’s output the way you would, run on everything it produces. OpenAI and Thrive did exactly this with a tax agent: the corrections their human reviewers kept making became the evals, and the agent reached up to 97 percent accuracy, graded against that accumulated judgment. That’s taste, moved out of one person’s head and into a check that runs. It’s the same idea I wrote about in an earlier post, your real job now is putting your taste into the checks.

It works because taste is real and learnable. Paul Graham argued years ago that makers reliably look back and recognize their old tastes were worse, which only makes sense if quality is objective enough to improve at. It’s trainable, and you train it by exercising it.

Paying it down

So the practice is easy to say and annoying to do. Don’t accept the first thing the model gives you. Push back on it, regenerate, pick, say why. Every time you wave a default through without examining it you add a little taste debt to the product and let your palate slip a little, and the rate at which you accept un-examined defaults is about the most honest measure of both I can think of. Argue with the AI and you keep your judgment. Defer to it and you lose it.

There are a lot of tools now that can turn a one-line idea into a full spec. In a handful of commands you get a constitution document, multiple specification files, and task breakdown files. GitHub’s Spec Kit does it, Amazon’s Kiro does its own version, and “spec-driven development” is spreading fast. Everyone’s arriving at the same thing I’ve believed for a while, that the spec matters more than the code.

I should be glad about this. I’m not, entirely.

You type a one-line prompt, the tool generates a polished document, and it looks authoritative. Headings, principles, acceptance criteria, the works. So you skim it, it reads fine, you hit go. The judgment in that document is whatever was in your one line, which is close to nothing. You didn’t make any decisions. The tool made them for you and dressed them up so they read like yours.

A finished-looking spec is the easiest to rubber-stamp

Sean Grove at OpenAI put it well. He says the code is maybe ten to twenty percent of the value, the rest is the structured communication of intent. Generating code from a throwaway prompt is like shredding the source and carefully version-controlling the binary. The prompt was the source. The spec the tool spat out is the binary, the polished output with the thinking compiled out of it. You saved the wrong artifact.

These tools don’t have to be used the shallow way. Spec Kit has a clarify step that scans for ambiguity, an analyze step, review gates. Run all of them and actually argue with the output, and you encode real judgment. The problem is the default path doesn’t make you do any of that, and a document that looks finished is the most rubber-stampable thing in the world. The danger is the one-command version defaults to the path where nobody does the work.

The way that works is to get grilled

I don’t ask the AI to write me a spec. I ask it to interview me.

There’s a tiny skill going around called grill-me, really just a handful of sentences you can paste into your prompt, that does exactly this. It tells the model to interview you relentlessly, walk down each branch of the design tree, resolve dependencies one at a time, and give its own recommended answer for each. You start with a rough idea and the model pushes on it. Why this and not that, what happens at the edge, what did you mean by “fast”. Half the questions I can’t answer right away, which means I didn’t actually know what I wanted yet. So I go research it, I make a call, I write the reason down.

By the time the interview’s done the spec basically writes itself, because the decisions already got made out loud. It’s the protégé effect: teaching the AI forces you to research, get clarity, and surface the unknowns you didn’t know you had.

What goes in the spec, and how I run it

Once we’re clear, I have the model write it down. The spec documents the what, not the how. It records the decisions we made in the conversation, with the reasons behind them. And it encodes my goals as acceptance criteria the model can check its own work against, so it knows objectively when it’s done instead of guessing.

It runs as two phases in two separate context windows, one for the spec and one for the build. Models hold a million tokens now, but I deliberately scope each phase to 200k to 400k, effective attention drops off and Claude Code starts auto-compacting well before that limit, so I keep the work small enough to finish clean. Start to finish:

1. Get grilled into a spec. The interview from before, the model questions me until every decision is made out loud and written down.
2. Compact down to the spec. I /compact to condense the interview into a short summary, so the decisions carry forward without all the back-and-forth, and the spec file stays the source of truth.
3. Switch to plan mode and point it at the spec. In Claude Code that’s shift-tab into plan mode, then I tell it to implement the spec, pointing it at the file we just wrote. Working from the spec and the actual codebase, it reads the existing code and writes a thorough implementation plan. That grounding is the point, the plan comes out of how the code really works, not a guess.
4. Skim, accept, let it run. The plan is mostly for Claude’s benefit, I care about the spec, so I skim it, accept, and switch to auto mode. From there it implements the spec and checks its own work against the acceptance criteria.

Scoped that small, the build runs all the way through before it hits degradation or auto-compaction, so I don’t compact again, I just let it go.

If I don’t know the domain, I run a separate research session before any of this. If the work is visual, I figure out how the agent will verify it, screenshots it can read on its own, before I let it build. It’s the same idea as an earlier post of mine on how LLMs compress your thinking, your judgment does the compression up front and the build just expands it back out.

Where this breaks

Acceptance criteria are great at correctness and useless at taste. You can write a check for “the tests pass” or “the endpoint returns 200.” You can’t write a check for “this reads like me” or “this is the elegant version.” That’s the verifier problem, the reason automated grading works for math and code and falls apart on style and judgment. So the acceptance criteria pin down whether it’s right. The interview is the only place your taste gets in. You can’t hand that part to a slash command.

Keep the thinking in

The spec matters more than the code. The thinking it’s made of matters more than the document. A tool that generates the document without the thinking hands you the packaging with nothing inside.

So use these tools for the parts they’re good at, and keep the part that’s yours. Make the model interview you before it writes a line, push back, decide out loud, write down why. Do that and the spec almost writes itself, you walk away knowing exactly what you want to build, and that’s the part that makes the build come out right.

We no longer have access to Fable 5. For three days we did. It showed up on Max and Pro on June 9, “free” (really just folded into the subscription we already pay for), the most capable model Anthropic had ever shipped, and three days later it was gone, pulled for everyone after a US government export-control order. Anthropic says it’s working to bring it back. Even when it does, the plan was always to move it off the flat-rate plans onto metered API pricing, somewhere around 10 and 50 dollars per million tokens, double Opus, and a single Fable 5 session was already eating through plan limits about twice as fast.

Fable 5’s edge is the horizon. You hand it a goal and it works for hours, planning across stages and checking its own work, then comes back close to done. Opus is great, but Opus I have to steer. I write the spec, I size the work to fit a context window, I set up the verification, then it builds what I wanted. With Opus, more of the work stays mine.

We were told AI would flatten this. Everyone gets a genius assistant, the playing field levels. But the genius you don’t have to babysit, the one that reaches furthest, costs the most, and it’s the first thing to get locked away.

Horizon is the thing you’re buying

There’s a number for this now. METR tracks a model’s “time horizon,” the length of task it can finish on its own, sized by how long the same job would take a human expert. That horizon has been doubling roughly every seven months for years, and it’s sped up to about every three to four months lately, three or four doublings a year. Whether the model can answer a hard question matters less than this. At the top, you pay for how long it’ll run before it needs you again.

The advantage compounds with length. The longer the task, the further the frontier model pulls ahead of the cheap one, because the cheap one hits a point where it needs a human checkpoint and the expensive one keeps going. So the gap is really about who gets to hand the work off and walk away.

The gap is how much you still have to babysit

With a cheaper model the work doesn’t disappear, it moves to you. You supply the clear spec, the tests, the taste for what good looks like. With the expensive long-horizon model, it supplies a lot of that itself, it infers the goal and fills in the judgment.

So the money buys back the hours you’d have spent steering. The person who can afford the frontier model delegates and goes to dinner. The person who can’t runs Opus and spends the evening writing specs and checking output. Getting good at that, building the verification so a cheaper model still lands what you wanted, is the whole subject of Loop Engineering for the Rest of Us.

The Stanford study of a hundred thousand developers found the gains are wildly uneven, near zero on complex work in an existing codebase, up to thirty or forty percent on simple greenfield projects, averaging around twenty. DORA found that teams adding AI without strong testing and version control get more instability, not less. The verification is real labor. It doesn’t vanish when AI shows up. It just sits with whoever can’t pay to make it vanish.

Open models are right behind, and that’s the trap

The obvious objection is that this is temporary. Open-weight models are catching up fast, the gap between the best closed model and the best open one is down to about four months on Epoch’s tracker. Today’s 50-dollar capability is next year’s free download.

But the frontier keeps moving, so the four-month gap doesn’t close, it travels. The people who can pay are always sitting at the newest, longest-horizon, least-babysitting model, and everyone else is running something a season behind that needs more steering. It’s a recency tax, you pay to stay current or you pay in the extra work of running last year’s model.

Paying in hours instead of dollars

The closest picture is In Time, the movie where people pay for everything with hours of their own life. That’s the cost side. Elysium is the other half, and yeah, it’s the obvious reach, the rich up on their orbital station with machines that fix anything while Earth grinds below. Whoever runs the newest, longest-horizon model saves the time and reaches things the rest of us can’t yet.

I don’t think the move is to feel doomed about it, and I don’t have a clean fix. What I do know is where the work goes when you can’t buy your way out of it. It goes into the spec, into the verification, into the taste you encode so a cheaper model can still produce something good. For most of us that work is the job now, and it’s what the next few posts are about.

Have you ever felt that the thing Claude Code just built for you is a bit off? It works but it’s not exactly what you were looking for. It feels as if you’re getting a parallel dimension version of what you had imagined.

Two people I pay attention to said almost the same thing this month. Peter Steinberger: “you shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” Boris Cherny, who built Claude Code, put it more bluntly: “I don’t prompt Claude anymore… My job is to write loops.” A couple days later Addy Osmani gave it a name, loop engineering, and now it’s the phrase in everyone’s feed.

I get the appeal. You stop babysitting one prompt, you kick it off and let it run for a few hours, and something good falls out.

A loop is only as good as the thing checking its work. Get the checker right and the loop lands on what you actually wanted. Get it wrong and you pay for hours of compute to land on something that isn’t quite it.

Now the loop finishes the wrong thing

The old complaint about loops was that they wander. An LLM has no built-in sense of “finished,” so a while-true loop runs until the budget runs out, and the budget is real money: Steinberger admitted to 1.3 million dollars a month in tokens at one point, and Microsoft canceled most of its direct Claude Code licenses once the metered token bills got unsustainable.

That part is mostly fixed. Claude Code shipped a /goal command and Codex shipped its own, and Claude Code’s works like this: after each turn a separate, smaller model checks whether your condition actually holds, and the loop only stops when it does. The checker is exactly the piece that used to be missing, so the loop stops on time now.

What it stops on is the new problem. The checker only knows what you told it to look for, so a vague goal earns a confident “done” on something next to what you meant. Kent Beck calls these models genies, they grant your wish to the letter, not the spirit, ask for “make the tests pass” and the genie might just delete the failing test. The loop didn’t wander, it did exactly what you said, and what you said wasn’t quite what you wanted.

I felt a version of this before the tooling caught up. I spent the last year not letting AI loose, I’d plan, write a tight spec, and the model would mostly one-shot the thing I imagined. The loops looked wasteful next to that. I was half right. The waste came from running a loop with no sharp goal and nothing checking its work.

The loop can’t beat its verifier

The cleanest version of this came out of Anthropic’s experiment building a C compiler with Claude. Nicholas Carlini ran 16 Claudes in parallel, produced around 100,000 lines, and got it compiling the Linux kernel and running Doom. His one big lesson: “it’s important that the task verifier is nearly perfect, otherwise Claude will solve the wrong problem.” They didn’t trust the model to grade itself, they used GCC as a known-good oracle. The loop was only ever as smart as the thing telling it whether it was right.

You can measure this directly. LangChain took a benchmark, changed nothing about the model, and improved the harness around it, the verification and the feedback. The score went from 52.8 percent to 66.5 percent. Same model, better verifier, fourteen points. Anthropic’s own writeup on long-running agents says it from the other side: agents praise their own work even when it’s mediocre, so you need an external deterministic check, not a self-grade.

The verifier decides how good the loop can get. Iterations past that don’t make the output better, they just make it longer.

This is also the third post in a line I’ve been writing. AI Accelerates Whatever You Have was about how AI amplifies whatever quality state you already have, mess or order. Give Your AI Hills to Climb was about handing the model hard artifacts, tests, types, budgets, so it can grade itself at machine speed. Loop engineering is what you get to do once those hills exist. Without them, the loop has nothing to climb toward.

Brute force is a privilege

All of this, the parallel agents, the run-for-hours, the throw-tokens-at-it, is a privilege. If you have unlimited tokens, letting a loop run loose is cheap, you can afford to throw away ten bad runs to get one good one. Being unclear about what you want gets paid for in tokens you never feel.

For the rest of us that’s the expensive way to be lazy. The Stanford team that studied how agents spend money found agentic tasks use roughly a thousand times the tokens of a chat. Spending more doesn’t buy more accuracy, accuracy peaks at an intermediate cost. Looping past that point is just burning money to land on something you could have specified.

So loop engineering for the rest of us flips the advice. You don’t make the loop longer, you make the verifier sharper. You build the deterministic check first: the tests, a rubric, the eval that encodes what good looks like to you. Then every iteration is provably moving toward the target instead of exploring. Fewer iterations, and they land on the thing you actually wanted. The economics back this up: a study of agentic hardware verification hit the same coverage with four to thirteen times fewer tokens and converged two to four times faster once the verifier was tuned to the domain. The harness isn’t overhead, it’s the compression that makes the loop affordable.

The people who can pay get to be vague and let the machine sort it out. Everyone else has to do the thinking up front, and the verifier is where you put that thinking.

How long this advice lasts

The Bitter Lesson runs against all of this: methods that scale with raw compute tend to beat hand-engineered structure, and as models get cheaper and run longer on their own, brute-force iteration keeps eating into the case for building careful harnesses. Over-build the scaffolding and a stronger model routes around it. Steinberger’s “just talk to it” is the token-rich version of being right about that.

I think that’s true at the frontier and false for the budget you’re actually on. But I don’t think the harness gets outdated, I think it moves up a level. We used to write the tests by hand. Now I write acceptance criteria in a spec and let the model turn them into tests. Next you write the thing that checks whether the agent hit the goal, the mission, the vision, and let it generate the rest. The verifier keeps climbing an abstraction layer, it doesn’t disappear.

You can already see where this is going. Anthropic’s Fable 5, released this month, works autonomously on longer tasks than any Claude before it, and early users say it reflects on and validates its own work before calling it done. That’s the model starting to carry the verifier itself. It also cost twice what Opus 4.8 does, and a US export-control order forced Anthropic to suspend it three days after launch over its cybersecurity capabilities, so for most of us it was a preview, not a plan. The cheaper models, the local ones you can run yourself, will follow it down this path, not as closely, but they will. Until then, for anyone watching their token bill, don’t make the loop longer. Make the verifier sharper.

I’ve been curating my second brain for a few months now. Whenever I find an interesting article or a skill, I read it and write a note. When I catch myself sending Claude the same kind of prompt over and over, I turn it into a guide. I’ve got a guide for how to commit, one for how to write specs, one for how to update agents.md.

They work great inside my vault. The friction shows up when I’m in another repo. I’ll be deep in some project with Claude Code or Codex, I want it to follow my commit guide, and there’s no clean way to hand it over. I tab to VS Code, copy the file path, and paste it back so the agent can read it.

I could turn these guides into skills. Skills are a genuinely smart idea, I’m a fan. They lean on progressive disclosure, the agent reads a short description, decides the skill is relevant, then pulls in the full instructions only when it needs them, so the context stays lean. It’s a real solution to a real problem, getting curated knowledge into agents and sharing it across people and teams, and it’s already helping a lot of people.

My case is just different. A skill is a distribution mechanism, and I don’t have a distribution problem. My commit guide is for me, I’m not shipping it to anyone. If I ever needed to share it, I’d reach for a skill without thinking twice. For my own use though, packaging it up for a distribution I don’t need is more work than the problem deserves, the guide’s already sitting there, I just want to point at it.

There are a couple of practical reasons too. Skills have to be installed where each agent looks for them, so today the same guide ends up duplicated across Claude Code’s folder, Codex’s folder, every machine I use, or I keep them in sync with symlinks. Now that skills are heading into the Agentic AI Foundation, where AWS, Anthropic, Google, Microsoft, and OpenAI are already agreeing on shared standards, I’d bet we get a single folder every harness reads from and the duplication goes away.

Then there’s activation. Even with a skill installed, the agent decides when to pull it in, and sometimes it doesn’t. Vercel ran a nice eval on this, a skill sitting right there got invoked in fewer than half the runs, and a plain routing index in their AGENTS.md scored higher, 100% against 79% for skills with explicit instructions. That’s not a knock on skills, it’s the nature of auto-invocation, and I expect it to climb toward perfect as the models get better at judging relevance. For now though, for something like my commit guide, I’d rather not leave the loading to that judgment, I’d rather point at it and know it’s there.

So even when those rough edges get smoothed out, I’ll still reference my guides instead of packaging them, I don’t have a distribution problem and that part won’t change. The only thing missing was a fast way to drop the reference in wherever I’m typing.

Claude Code already has a great @ picker, you type @, fuzzy-find a file, and it lands in context. The catch is it’s built around the current working directory. I’ve tried /add-dir to pull my second brain in as an extra directory, but the @ UX doesn’t really work with the added dirs, it still only fuzzy-finds cleanly inside the cwd. So from another repo I can’t reach my guides through it.

I also noticed that if I hand Claude Code the full path with an @ in front, it reads the whole guide in one shot, no listing the directory, no grepping, no three-turn detour where it skims the first 20 lines and moves on. The full @-path pulls in the entire document. At least in Claude Code, Codex treats it more like a plain path.

That’s atref. It’s a small tool that puts a Claude-Code-style @ picker in any text field. I hit Ctrl+Space and a fuzzy picker pops up right at my cursor, nothing to go open. I start typing the name of the guide, it fuzzy-matches across the folders I’ve pointed it at, handles CamelHumps so I can type gcg and it finds Git Commit Guide, and does smart-case so I don’t have to think about capitals. Enter drops the full @-path in where I’m typing, and the guide’s in context.

It’s picky about what it indexes. I point it at the folders I want and rank them by priority, so my most-used guides surface first. It’s git-aware, it follows .gitignore and skips the node_modules and target noise. A file-watcher keeps the index live, so new guides show up without a restart. It all runs as a small Rust app in the tray.

It’s early. Right now it’s Windows only, v0.1 is rough, and it does exactly one thing. But it works, I use it every day to pull my guides into Claude Code and Codex from whatever repo I’m in.

If you want to try it, install with Scoop or PowerShell:

# Scoop
scoop bucket add atref https://github.com/JuanjoFuchs/atref
scoop install atref

# or run the installer directly
irm https://raw.githubusercontent.com/JuanjoFuchs/atref/main/install.ps1 | iex

winget support is coming soon. The repo’s open at github.com/JuanjoFuchs/atref, so if something breaks, or there’s a reference format you want it to insert, tell me. I’d also like to hear what you’d @-reference first.