Agent Frameworks Treat the Human as the Bottleneck

The coding-agent frameworks went one direction this year and the data went the other. Superpowers, the most popular of them, runs a mandatory test-driven cycle and can go autonomous for hours. Spec Kit, GitHub's entry, walks every feature through a fixed pipeline that leaves a markdown artifact at each step. There are more than thirty frameworks in this category now, and nearly all of them are built on the same premise: the human is the bottleneck, so route around them.

Meanwhile, GitClear's analysis of 623 million code changes from 2023 through this year came out in July. Duplication is up 81 percent. Refactoring of existing code is down 70 percent. Error masking, the density of catch blocks and safe-navigation operators and stubbed methods, is up 47 percent, which the report's author explains plainly: AI "strongly prefers to write code that won't be labeled as a defect." A separate academic study of roughly 300,000 AI-authored commits across five tools found the same pattern everywhere, varying only in degree. That's the backdrop the frameworks are building into, not a result of them. But it's what happens when the human stops being in the way.

I made the spec-driven bet before any of these frameworks existed, and I built the rigorous version first: an MCP server with 26 document types and 49 enforced processes. It worked, and it was too rigorous for anyone outside agency or enterprise engineering. Walter is what I built after that, earlier this year, because the harnesses I was using failed the same three ways every time. They started building before they understood the problem. They drifted from what we'd agreed once they were building. And they forgot everything between sessions. The spec-pipeline frameworks that followed solve the first problem, partly, and mostly ignore the other two. Walter is my answer to all three, in a form a vibe coder or a staff engineer would actually use, and it's open source. Here's why it looks the way it does, and what running it on real projects this year taught me.

The Field, Honestly

These tools are good at what they're for, and it's worth being precise about what that is.

Two things stand out across the whole category. None of the big three enforces human sign-off. They enforce that a document exists. And none of them covers what happens after the feature: the bug at 2 a.m., the incident, the moment you learn something mid-build that changes the plan. They're feature pipelines, and a feature pipeline is a small part of engineering.

What Walter Is Instead

Walter is a persona and a thinking framework, not a pipeline. One skill, nine commands, six agents, twelve reference files. It installs into Claude Code, Cursor, Gemini CLI, or Codex, and the commands are tools you reach for, not a sequence you're marched through. Run /cook without /formula. Load the skill and never touch a command. The ceremony scales with the stakes: a weekend project gets a mental checklist, a system gets a written scope with explicit boundaries. Same thinking, different paperwork.

The nine commands map to the whole lifecycle, not just the front of it:

• /formula, /prep, /cook, /purity for scope, breakdown, build, and verification.
• /probe for bounded research tied to a decision.
• /trace for root cause and /vent for incidents.
• /adapt for pivots and scope changes.
• /stash for sealing context before a session ends.

The persona isn't decoration. Taste is programmable, and the persona is where you program it: Walter's values, his refusal to flatter, his demand for a problem before a solution, are taste encoded so it holds when you're not watching. The six agents are lenses, not roles. Jesse researches and verifies. Mike finds what's missing before production. Hank won't stop until he has the root cause. Gus thinks about second-order consequences. Heisenberg assesses architecture. Skyler isn't an engineer and exists to ask who this is for and what everyone else is afraid to ask. They don't report to Walter. They push on him.

Planning: No Formula, No Cook

The default harness treats your first message as a spec. Walter doesn't want to cook without a formula. If you want to vibe, he'll vibe with you, but he'll ask first, and a formula is a conversation, not a form. What problem, for whom, how do we know it's a problem. What's in, what's out, what's deferred. What's true when it's done, in terms someone else could check. Then a commitment point, after which changes are changes and not clarifications.

Here is what that produced on the first day of an orchestrator I built for running multiple Claude Code sessions from a browser. Before any code, a probe answered three questions: can a hook block long enough for a phone-based approval, what's in the hook payload, and can multiple sessions share one MCP server. Then the formula drew the lines:

### Out of Scope
- Agent SDK / headless mode (we use stock Claude Code CLI)
- Custom auth system (remote access documented via Cloudflare Access or Tailscale)
- Container orchestration / Docker / Kubernetes
- Custom STT/TTS models in v1 (Web Speech API first, upgrade path documented)
 
### Deferred
- Kokoro.js TTS integration (v2)
- Whisper STT integration (v2)
- Multi-machine coordination (v1 is single machine)

That out-of-scope list is the most valuable thing in the document. Not defining what's out is how creep starts, and an agent will happily build Kubernetes support if you leave the door open. The project ran to a few hundred commits and around 1,800 tests in three weeks without the scope moving under me, and the formula is why.

The spec pipelines do this part too. The difference is what they produce. Spec Kit's main complaint in every comparison I've read is verbosity: pages of generated prose that nobody reads before the agent proceeds. A formula is as long as the problem needs. Addy Osmani wrote in April that writing down the done condition before starting caught more scope drift for him than any prompt change. That's the entire content of /formula.

Alignment: The Agent Drifts, and It Drifts Quietly

Planning is where every framework spends its effort. Alignment is where the slop actually comes from. An agent drifts three ways: it solves the adjacent problem, it expands scope with "while I'm here," and it pivots silently when it learns something mid-build. None of those show up in a spec. They show up in the diff.

Named pivots. On the orchestrator, a design review found that a probe had modelled message direction wrong, and that the spec built on it was wrong too. The adapt record calls the spec "contaminated by the wrong probe" and rewrites it, with the trigger, the options considered, and the rationale. That's a pivot you can read six months later. The alternative is an agent that quietly changes approach and a codebase that no longer matches any document.

Done is a judgment. Walter's /purity exists because tests passing is not the same as done right. The orchestrator had around 1,260 green tests when I pointed three of the crew at the source instead of the test suite. They found an activity buffer that was never evicted, approval holds with no timeout that would hang a connection forever, and a dashboard whose SSE connection died permanently on the first dropped network. All three shipped in a test suite that passed. The harness-engineering writing has converged on the same conclusion: separate generation from evaluation, because agents grade their own work generously.

Something that argues back. Truth over agreement is a non-negotiable in the skill, and the crew is built for it. Skyler's instructions open with "You work with Walter, but not for him." BMAD has roles; Superpowers has review subagents that check spec compliance. Neither has a reviewer whose job is to say the user you designed for doesn't exist.

Senses. The agent has no IDE. No red squiggles, no inline errors. Pre-commit hooks are its only feedback loop, so Walter treats them as foundation: lint, type check, format, tests, before any feature. On the orchestrator, the hooks went in with the second commit, before a single feature existed. GitClear's 47 percent rise in error masking is what happens when the agent's only signal is "did the prompt get satisfied."

Alignment is a process property, not a prompt property. You can't instruct it in. You build the checkpoints, and you put a human at them.

Context: The Next Session Starts Stupid

Sessions end. Context compacts. The agent that knew your codebase at 4 p.m. is gone at 9 a.m., and the default fix is a summary, which is a lossy copy nobody checked. Anthropic's own finding, reported this spring, is that compaction alone isn't enough and that long jobs need fresh sessions rebuilt from a structured handoff file.

Walter's handoff is that file. Its priority order is specific: what's next, what to read, context for the task, current status. What you did is the least important part. History belongs in commits. The next agent needs a launchpad, not a journal.

I learned that the hard way on the orchestrator, where 65 of 273 commits touched CLAUDE.md because every finished work item meant editing the launchpad. What I settled on:

A state file per formula. Each formula gets its own file that tracks where the work stands, and CLAUDE.md points at it. The launchpad holds what's on deck, what's coming, and where the plans live. Only the state files move.

## On deck
Feed polish, then the monorepo restructure. See .walter/state-feed-polish.md.
 
## Plans
- .walter/formula-feed-polish.md (approved)
- .walter/formula-monorepo.md (draft, paused)
 
## Known issues
- See .walter/known-issues.md

Add a known-issues file or whatever else you need. The shape is yours.

No work item IDs in commits. Preps come in every size and they reuse the same letters and numbers, so "B.7 done" means nothing a week later. A commit says what was done. The plan says what it was for.

Plans live where the team can see them. In-flight work (formulas, preps, probe findings) goes in a .walter/ directory that survives sessions. Solo, I gitignore it. With a team, the plans get committed, because the formula and the prep are what everyone reviews and agrees on before the work starts. Alignment happens on the plan, not on the pull request. Fifty documents accumulated there on the orchestrator over three weeks.

Two rules I added in March, after a month of daily use, are the ones I'd defend hardest:

- **Don't use the memory feature.** Never write to or read from the Claude Code
  memory system. Context lives in files we control and can see: CLAUDE.md,
  `.walter/`, docs. Not in hidden memory stores.
 
- **Never delegate file reads that inform your own judgment.** Sub-agents do
  independent work: security review, impact analysis, root cause investigation.
  They don't read files so you can avoid reading them yourself. Delegation is
  for parallel independent work, not for outsourcing comprehension.

The first one runs against the grain. The harness research this month notes that persistent memory has replaced compaction as the frontier, and Codex and Gemini CLI both ship cross-session memory now. I turned it off. If you can't see what the agent remembers, you can't correct it, and an agent with wrong memories is worse than one with none. The second rule came from watching sub-agent summaries become the agent's whole understanding of a file. A summary is context loss dressed up as efficiency.

The spec tools keep specs across sessions, which helps. Superpowers keeps artifacts only for the feature in flight. None of them has an opinion about what the agent should remember, or a protocol for handing a session to the next one.

The Slop Connection

Line the GitClear numbers up against Walter's rules and they're mirror images.

Osmani's rule for agent config is that every line should trace back to a specific thing that went wrong. Walter's two March rules do. So does most of the skill, because it was written after years of watching engineers make the same mistakes, and the agents make them faster.

Slow Down Where It Counts

Rules like those catch the mistakes agents make faster. They don't catch the one that matters most, which is building the wrong thing well. The thinking happens up front or it doesn't happen. That's the one thing I'd want anyone to take from this, and it matters most in a zero-to-one startup, where the cost of a wrong turn compounds fastest.

Skip the planning and you flail. You build things the customer doesn't need yet, in an order that makes the next thing harder. The discipline is holding the long-term vision while asking what you can build now that doesn't deviate from it and doesn't drag the whole roadmap in behind it. Sequence is the hard part. Build out of order and you've made a brownfield project on day one, and every sprint after that is spent fighting your own slop.

Agents made building fast. That makes the slow part obvious: the decisions about what to build and for whom. Those deserve more time now, not less, because everything downstream of them moves at machine speed. A team under pressure to ship code without ever having the product conversation will fail, and no amount of AI changes that. That part is still yours.

Who It's For

Walter doesn't need an engineer on the other end. Anyone who can open an IDE, follow instructions, and describe what they want can run it. What it needs is someone with ideas and opinions, who asks questions and knows what they don't know, because every checkpoint routes a decision to that person. "Consult before committing" only works if there's someone to consult. The framework raises the floor. It doesn't replace the judgment that decides whether the formula is right, whether the pivot is the correct one, whether the handoff is honest.

That's the ceiling, and it's the one the autonomous frameworks don't put on the box. A process followed perfectly with a bad input produces well-documented slop. What a framework like this buys you is less slop, not no slop, and anyone promising more is selling slop with better formatting.

That makes the human the bottleneck, and being the bottleneck right now is a hard place to sit. Nobody gets to deliver slower. The pressure is to ship faster than any team has shipped before, and the GitClear numbers are what shipping faster the default way looks like after three years. Error masking up 47 percent is not a style problem. It's rescue blocks swallowing failures that will turn up later as incidents and CVEs, at a scale no security team can review. Less slop and better outcomes at the same speed is the only acceptable trade, and the only way I know to get it is to keep the human at the checkpoints and make those checkpoints fast.

Why This One

If you want the same artifacts for every feature, Spec Kit. If you want specs as a living source of truth with minimal process, OpenSpec. If you want to hand the keys over for a few hours and review a pull request at the end, Superpowers, and read the GitClear report first.

Walter is for the case where the hard part turned out not to be the spec. It's staying aligned after the spec, and not starting stupid the next morning, and having something in the loop that tells you you're wrong. None of the popular tools own those problems, because they treat the human as the bottleneck and route around them. I built Walter on the opposite premise. The human is the bottleneck, and that's the point: it's where the judgment is. The job isn't to remove it. The job is to make it fast.

It's at walter.cooking and on GitHub, Apache 2.0. Load it, tell it what you're working on, and have an opinion.