The Babel Fish, Built

Drafted with Claude as a writing partner, using a version of the methodology this article describes. More on how I use AI to write in the next piece.

Two years ago I wrote about the Babel fish as fiction becoming reality. A small yellow creature you slip in your ear that translates any language into your native tongue, on demand, in real time. Hitchhiker’s Guide to the Galaxy, 1979.

In the 2024 piece I argued the Babel fish was almost here. AI plus noise-canceling headphones, give it a year or two.

Two years later I have a Babel Fish. It runs on my desktop. It speaks to Claude, GPT, OpenRouter, and a bundled local model. It connects to Telegram. It exposes itself as an MCP server so Claude Code, Cursor, and Zed can use it. It is a Tauri 2 shell over a nine-crate Rust workspace and a SvelteKit frontend.

I built it with three skills. The skills did about 90% of the work.

The remaining 10% is the interesting part.

Generic tools assume one shape

Generic AI coding tools assume one shape of work. You open a chat. You describe what you want. The model writes code. You review, paste, iterate.

This works for snippets. It collapses on anything larger than a feature.

Real coding has at least three phases. Greenfield planning is one shape: research the landscape, evaluate the stack, document the decisions, produce an implementation roadmap. Feature work is another shape: take a working system, design a new piece that fits inside it, ship a coherent change. Implementation is a third shape: take a plan, build every piece, wire it together, prove the build passes and nothing got faked.

Each phase asks different things of the assistant. Each phase has different failure modes. A generic chat treats them all as the same kind of conversation. That is the failure.

I built three skills. One for each phase.

Kickoff

The kickoff skill runs greenfield project planning. Ten phases, from Seed through Crystallize. It is the heaviest of the three.

The flow: capture the initial idea. Discovery questions on goals, users, constraints. A research sprint that spawns multiple parallel agents to cover competitive landscape, tech stack options, architecture patterns, security, infrastructure. Each agent does at least five web searches, cites every source, and self-scores its research depth from 1 to 10. The skill refuses to advance past Research Sprint if any topic scores below 6.

Then requirements, workflows, UI design, technical design, expansion, implementation planning, crystallize. The output is a directory of artifacts: project plan, tech spec, implementation roadmap, ADRs, risk register, research report, project scaffolding. Implementation-ready.

Babel Fish was kicked off through this exact process. The README still references the 10-phase kickoff and the ADRs it produced. ADR 0001 documents the decision to defer SQLCipher at-rest encryption to a Phase 1 follow-up. ADR 0006 documents the decision to defer the auto-updater and signing pipelines to Phase 2. Both decisions came out of the kickoff with explicit rationale and alternatives logged. Both are visible. Both are still tracked.

A kickoff that produces a working ADR is doing something most planning sessions never do.

Brainstorm

Brainstorm is the lighter version. Five phases instead of ten. The output is a plan document. Use it when you have a working system and you want to think through a new feature before implementing it.

I wrote about the brainstorm skill in detail back in April. The short version: it runs Seed, Discovery, Exploration, Expansion, Crystallize. Every interaction goes through structured multiple-choice questions, with the option to add custom input. The skill maintains a verbatim transcript of every exchange. At the end, a reviewer agent compares the finished plan against the transcript and loops until the plan covers everything the conversation surfaced.

That last detail is the load-bearing one. Plans drift from conversations. Things get dropped, simplified, lost in translation. The reviewer-vs-transcript check catches it.

Brainstorm runs on Babel Fish whenever a new feature lands in scope. The Phase 2 deferrals in the README, Discord and Slack adapters, the bundled local model runtime, the onboarding wizard, each had a brainstorm session attached. Each produced a plan. Each plan went into the implementation queue.

Build-to-complete

Build-to-complete is the showstopper. It is the skill that solves the four canonical failures of AI implementation.

Most AI coding sessions fail in one of four ways. First, shallow implementation. The model writes a function signature with a TODO comment and declares the task done. Second, missing integration. The model writes a real component that nothing imports, a real route that nothing registers, a real endpoint with no client caller. Orphan code. Third, stopping early. A ten-phase plan gets two phases of implementation and an apology. Fourth, self-graded review. The same context that wrote the code is biased toward declaring it complete. Fresh eyes find what the author cannot see.

Build-to-complete catches all four. The skill takes a plan document as input. For each phase in the plan, it runs a loop: implement every task, self-check for stub patterns (TODO comments, empty returns, placeholder JSX, mock identifiers in production code), run the build, verify each artifact is imported and wired and reachable. Then it self-validates the phase against acceptance criteria. Then it spawns an adversarial subagent with zero inherited context, hands it the plan and the diff, and tells it to find every reason the phase is incomplete. The subagent reports BLOCKER, MAJOR, and MINOR findings with file:line evidence.

If the adversarial reviewer finds anything, the skill goes into a fix loop. Read the evidence. Read the previous attempt. Generate a targeted fix that takes a different approach if the last one failed. Implement it. Rebuild. Re-validate. Re-spawn a fresh reviewer. Repeat until the phase is clean or the safety limits hit. Four fix cycles maximum per phase before the skill marks remaining items unresolved and continues.

When every phase is clean, one more adversarial subagent runs against the whole codebase. Fresh context, full plan in hand. Cross-phase issues, types redefined between phases, routes registered in one phase and broken in another, integration assumptions between phases that never actually held. The whole-project reviewer catches what phase-local review misses.

The final report has three confidence levels. HIGH means the build passes, every phase passed adversarial review, and the whole-project review came back clean. MEDIUM means most phases clean with unresolved minor items. LOW means the build is broken or a phase was advanced with unresolved BLOCKER findings. Honest reporting is mandatory. If three of ten items work, the report says 30%. No euphemism, no rounding up.

Babel Fish hit HIGH on v0.1.0. Build passes. Every phase clean. Whole-project review clean. The remaining work is the signing pipeline, which is infrastructure rather than implementation. The skill produced a working desktop AI agent.

Adversarial review at every layer

The three skills do different work. They share one posture. The AI never grades its own work.

Kickoff scores its own research and refuses to advance past a research-heavy phase below a 6 of 10. The score is internal. The gate is real. Brainstorm runs a reviewer agent against the verbatim transcript before declaring the plan complete. Build-to-complete spawns a fresh subagent per phase and another against the whole codebase, with zero inherited context, instructed to assume the code is wrong until proven right.

This is the adversarial audit pattern operationalized at every layer of the workflow. Same pattern, three different surfaces. Research depth gets a score and a gate. Plans get checked against transcripts. Implementations get torn apart by a fresh-eyed agent that did not write the code.

Generic AI coding tools do none of this. They let the model declare its own work complete. They let plans drift. They let stubs ship. The methodology is built around the single principle that an AI cannot be trusted to validate its own output, and every phase of work needs a second pair of fresh eyes.

No war stories

This is where I am supposed to give you the war story. The fix cycle that took four attempts. The whole-project adversarial pass that caught a Phase 1 bug Phase 5 silently introduced. The reviewer agent that flagged a deferral I had forgotten. Standard engineering-essay material.

I don’t have one.

Full disclosure: I drafted this article with Claude. When we got to this section, Claude asked me for war stories. The same examples I just listed, almost word for word. I told Claude the workflow runs clean. I offered Claude the option of inventing some. Claude pushed back: senior practitioners smell invented drama, the absence is the receipt. Claude was right.

Read that exchange again. The AI helping me write this article had the same bias every AI engineering essay leans on. The same bias the methodology in the article is built to catch. The human is the adversarial reviewer of last resort. The same principle that closes the article opens this section.

Phases pass their adversarial reviews on the first or second cycle. The build-to-complete loop terminates without me touching it. The whole-project review comes back clean. There is no dramatic save story because the methodology does not produce dramatic save stories. It produces clean pipelines.

That is the receipt.

The 10%: taste is the gap

I said the skills do about 90% of the work. The remaining 10% is the interesting part.

The 10% is user acceptance testing.

The AI plans. The AI implements. The AI reviews its own output adversarially. A human still has to use the thing.

I have been working on this. Playwright browser automation plus a model that drives the UI and reports back can verify functionality. It can confirm buttons click, forms submit, flows complete. It can hit the happy path and a reasonable share of the unhappy paths. What it cannot do is tell me whether the cost-alert UX feels punitive, whether the dropdown sits in the wrong place psychologically, whether the permission-mode language sounds threatening when it should sound informative.

Functionality is one problem. Taste is a different problem. The AI verifies functionality cleanly. Taste is the gap.

This is the same line I drew in my piece on AI doing the 80% that looks like the job. The 80% is the executable part, the verifiable part. The 20% is judgment. UAT lives inside that 20%. UAT requires being a user. AI verifies. AI does not yet use.

I spend real time on this. Hours per release. I click through every flow. I read every screen as a person who has never seen the product before. I notice the buttons that say the wrong thing, the modals that interrupt the wrong moment, the empty states that feel dead. Nothing in my three skills surfaces that work. It is taste work, and taste is what the methodology does not handle.

A future version of these skills may close some of this gap. I have ideas about how AI-driven UAT could go further: simulated user personas, expectations from comparable products, anomaly detection on visual flows. I am skeptical it closes all of it. The last mile of taste is what humans are still good at, and the methodology I have built is honest about where it stops.

The Babel Fish is built. The methodology produced it. The methodology stops at the threshold where I have to be a user, and at that threshold I am still required.

That is the 90% and the 10%. The skills do the work. I do the part the skills cannot.

Take the skills

You might have noticed I haven’t shared the skill files themselves. That was deliberate. I don’t need to.

Hand this article to your AI coding agent. Ask it to build the three skills described here: kickoff, brainstorm, build-to-complete. The agent has everything it needs.

The methodology is in the description. Adversarial review at every layer. Forced-choice questioning. Reviewer-vs-transcript validation. The four canonical implementation failures and the loop that catches them. Phase-level fix cycles with safety limits. A whole-project pass at the end. The 6-of-10 research-score gate. The honest reporting rule.

Read it back to your AI. Ask for three skill files. You will have a working methodology by morning.

That might be the strongest receipt in this article. The methodology is small enough to fit on a blog post and complete enough that an AI agent can rebuild it from the description. The kickoff skill in your hands tomorrow will look different from mine in the details. The shape will be the same. The pattern transfers.

Take it. Use it. Tell me what you change.

First published May 18, 2026 on 42 Insights.