Bob

Bob is a tool that autonomously builds non-slop software. You describe what you want; Bob builds it. Here's how.

Software engineering used to have a guy named Bob. Bob's job was to look at what you were doing, ask why, and tell you to slow the hell down. Bob read the spec before the code. Bob read the code before the commit. Bob read the commit before the deploy. Bob was annoying. Bob was correct. I miss Bob.

Vibe coding does not have Bob.

This is the part that makes Bob different from every coding agent you have been sold, so it gets said plainly.

A language model is a slot machine that talks. Every call is one sample: confident, fluent, and wrong often enough to matter. No prompt fixes this, because it is a property of sampling, not of skill. The fashionable response is to hand that slot machine more control. Let the agent decide what to do next, manage its own memory, steer its own loop. Bob thinks that is exactly backwards. You do not put the unreliable thing in charge of deciding what happens next.

So here is Bob's one rule, the one everything else falls out of:

The stochastic actor never holds the control flow. The framework is deterministic. The model is sealed inside a replaceable cell with a decidable check on the door. Nothing the model produces is trusted until something that is not a model has checked it.

What that buys you, and what nobody shipping a single-agent IDE has:

• The design is the program. Plan quality is causally and unfakeably linked to output quality, because the agent interprets a plan instead of inventing one. A bad plan fails loudly; it cannot be charmed into looking good.
• The repo is the only state. No hidden conversational memory. The process is replayable and crash-proof because there is nothing to corrupt that git does not already hold.
• Disagreement is a primitive, not a product. Drafting, critique, and reconciliation are configuration. Substitutability (a council is a responder, a pair is a judge) is a first-class property, not an afterthought bolted on later.
• The audit runs on evidence. A typed, deterministic, append-only ledger lets a plan be re-derived from execution history. The drift detector fires on explicit events, never a hunch, because in a drift detector a false positive just trains you to ignore it.

And the part that is easy to miss: Bob is not a better agent. Bob is not an agent at all. Claude Code, Cursor, and the rest of the autonomous-IDE pack are instances of the exact thing Bob refuses to do. They let the model drive. They are point tools. Bob is a process with a position, assembled end to end. There is no peer to line it up against feature by feature, because the comparison is a category error: you do not benchmark a seatbelt against a faster car.

None of the individual mechanisms is new, and Bob will be the first to say so. Acceptance gates are old. Replayable state is old. Ensembling and adjudication are an active research line. Careful human teams have always worked this way. A senior reviews the junior's PR, a design doc gets read before it is committed to, one person finds the bug and another verifies the fix. The mistake-catching long predates LLMs. What Bob contributes is the synthesis: those four things, combined under the single rule that the model never steers, applied across the whole loop. No piece survives a "show me the prior art" challenge alone. The combination, end to end, is the contribution, and Bob would rather state that honestly than oversell it.

The sophistication here is not a clever algorithm. It is the choice of what to hold fixed: repo-as-only-state, text-file contracts with a typed marker grammar, design and execution separated by making the design executable, exactly one mutating step per attempt, a deterministic projector over an append-only log. A less disciplined design meets the same requirements with a database, a session manager, and an orchestration framework, and then cannot survive being killed mid-run. The restraint is the point.

Most readers arrive fluent in a vocabulary Bob does not use. Agents, skills, hosted schedulers, and managed sandboxes all have obvious places in other stacks. Three of them are positions Bob took on purpose. One is a question it has not answered.

Agents. In the vendor sense, an agent is the model holding the control flow. It picks the next action, it decides when to delegate, and it decides when to stop. Bob's one rule forbids exactly that, so the absence is a position and not a gap waiting to be closed. Bob does fan out. Orchestra runs parallel actors in parallel_thinking and council_four, but at the workflow level, where every invocation crosses the executor and lands in the log as a checkable, resumable event. A subagent spawned inside a single CLI session does model work that never crosses that chokepoint. It is unlogged and unresumable, and nothing outside the model has checked it.

Skills. A skill is static text loaded on demand. It takes no control flow, so nothing in the thesis rules it out, and Bob still does not use one. Conventions live in CLAUDE.md instead, which is the always-loaded version of the same idea. The tradeoff is real and unresolved. A manifest is paid on every task whether or not it is relevant, where a skill is paid only when the model reaches for it. Turning skills on means adding one entry to the allowed-tools lists that McLoop and Orchestra's agent adapter deliberately keep mirrored. Nobody has measured whether it helps. The question is open, and it is written down here so its absence does not read as an oversight.

Hosted schedulers. That role is Vroom's, the layer above McLoop that owns the backlog, dispatches work, and reads the result. Designed and partly built. It is not yet closed, and the Status section says where it stands. The boundary holds either way, because it is an architectural claim and not a status one. Deciding when to run belongs to the caller. A managed cron does not invoke McLoop at all. It fires sessions into a vendor's container, solving the problem from outside the stack and billing per token against the subscription the fallover chain exists to protect.

Hosted sandboxes. Bob's acceptance gate is your test suite, run on your working tree, with the diff's own lines proven executed against a pre-edit baseline. Moving execution into a managed container moves the gate away from the thing being gated.

The same pattern runs through the rest of this file. Bob is not missing these primitives. It declined most of them deliberately, and it says out loud which one it did not.

Each is the rule above applied at a different scale. They interact: McLoop runs against plans Duplo authored, Orchestra wraps McLoop's per-task edits, and McLoop calls Duplo back to re-author the plan when the ledger says the current approach is not working.

Duplo is Bob creating the spec. Tell Duplo what you want, point it at a product URL, drop in screenshots, PDFs, or a demo video, whatever you have. Duplo produces a phased build plan. The quality of the output is a direct function of the quality of the plan, and that is on purpose. The plan is not notes for the agent. The plan is the program; the agent is just the thing that runs it. Write a vague plan and you get vague code, plainly, with nowhere for the model to hide it. That is the incentive to design carefully, which the field has been busy losing.

McLoop is Bob running, testing, and debugging the build while you sleep or binge Netflix. Autonomous coding sessions for hours or days: fresh context per task, tests and lint after every change, only clean code committed, automatic audit when the queue is done. Fresh context per task is not a performance trick. It is the whole game. The state is the repository and its git history, nothing else. There is no private conversation only the model has seen, which is why a kill -9 is a shrug instead of a catastrophe. McLoop builds what Duplo designed, and it never lets the model decide what happens next.

Orchestra is grumpy Bob fighting LLM slop. Any single LLM can fail spectacularly and sound delighted doing it. Bob doesn't like that. Orchestra hands different models different jobs and makes them argue, interact, and sing harmonies before anything touches the workspace. And the argument is not hardcoded: a council can be collapsed to a single responder, a pair promoted to a judge, a one-model edit swapped for a five-model brawl, by changing configuration, not by rewriting anything. Multi-model disagreement is a dial Bob can turn, not a feature someone soldered on.

Vroom is Bob reading what shipped and asking what he should have done differently. Vroom runs parallel auditors over the work, coalesces what they find, and proposes a corrected or expanded plan, and it does it from the evidence, not from vibes. Every run leaves a typed, append-only ledger, so the plan can be re-derived from what actually happened instead of hand-patched into looking fine. Eventually Vroom is Bob running the whole loop himself: proposing changes on branches, gating them on verification, merging what survives. You sleep through that too. (How done that actually is: see Status, below. Bob does not lie about status.)

Bring the kind of skepticism the field used to have before it fired Bob.

reference material
  -> Duplo: spec and phased plan        (the design becomes the program)
  -> McLoop: implementation, tests, commits   (sealed cells, gated)
  -> Orchestra: multi-model review and judgment  (composed, configurable)
  -> Vroom: audit, reflection, correction    (re-derived from the ledger)
  -> next plan

Every arrow crosses a check. Nothing stochastic gets across without passing something deterministic.

AI coding tools are powerful, but a single model acting alone is not a software engineering process. It can skip design, miss edge cases, hallucinate APIs, repeat bad approaches, and commit plausible nonsense, cheerfully. The problem is not that the model is weak. It is that nothing deterministic stands between the model's output and your repository.

Bob is the missing process layer:

• design before execution, the plan is the program
• fresh context per task, state is the repo, not a chat log
• tests and lint after every change, a real check on every boundary
• review before trust, independent draws where one gate is not enough
• audit after shipping, the ledger decides whether to re-plan, not the model
• explicit recovery when something breaks, because the only state is on disk and in git, there is always a defined state to recover to

The point is not to make coding faster at any cost. It is to make autonomous coding slower where it must be slower and faster where it can be faster, and to put design back at the front of software engineering, where it lived before the field stopped writing specs.

• Duplo, McLoop, Orchestra, in active use and built with each other. Real, used daily, building this.
• The Plan Ledger, shipped, in bob-tools, with its projector and threshold rules. This is the evidence substrate Vroom stands on.
• Vroom as the fully closed loop, Bob proposing changes on branches, gating them, merging what survives, unattended, is the designed end state and is being closed, not yet closed. The scaffolding is real; the last quarter of the loop is still being wired, and that is stated here on purpose, because epistemic discipline is the entire point of the project.

1. Start from a product URL, screenshot, PDF, video, or prose request.
2. Use Duplo to produce a spec and phased PLAN.md.
3. Use McLoop to execute the plan task by task.
4. Show tests, lint, commits, notifications, and crash recovery.
5. Use Orchestra to route a decision through multi-model disagreement.
6. Use Vroom to audit an artifact and propose a corrected version.
7. Close the loop: the corrected output becomes the next plan.

A coding agent is not a software engineering process. A deterministic framework that confines, gates, and composes stochastic actors is, and that framework, not the actors inside it, is where every correctness guarantee in this system lives. Bob is that framework. Also, Bob would have caught that bug in review.

The bob ecosystem lives in this repository as a uv workspace. Each tool is a package under packages/:

• Duplo, design extraction and phased plan generation.
• McLoop, the autonomous execution loop.
• Orchestra, the declarative multi-model workflow runner.
• bob-tools, shared infrastructure; the Plan Ledger and the formal PLAN.md library live here.
• Vroom, post-ship audit and the closing of the loop, part of the ecosystem, not yet public.

Each package carries its own README with the full surface and its own honest status.

Each package also carries its own PLAN.md, the canonical, machine-owned build document that package is developed against. Plans are per-package, not one global plan: McLoop advances each package's own PLAN.md independently. (Orchestra adopted a PLAN.md only late in its development; its earlier design material still lives under packages/orchestra/design/.)

Bob is a uv workspace. Clone the repo and run uv sync:

git clone https://github.com/mhcoen/bob.git
cd bob
uv sync

This installs every package (Duplo, McLoop, Orchestra, bob-tools) in editable mode, with internal cross-package dependencies resolved locally. The CLIs (duplo, mcloop, orchestra, bob, bob-plan) land on PATH.

To add Bob's optional Claude Code hook for token-saving command compression and remote approval of tool calls, run bob install after syncing. See Combined Telegram and RTK hook below.

Subscribe at buttondown.com/bringbackbob for releases, demos, and first invitations to use it. Announcements only.

Bob is built by Michael Coen, a computer scientist and ML researcher whose work spans software agents, self-supervised learning, AI security, and LLM infrastructure. He earned his S.B., S.M., and Ph.D. from MIT, received the Sprowls Award for outstanding dissertation in computer science, was on the faculty at the University of Wisconsin-Madison, and co-founded several fintech startups.

His current work focuses on hardening AI systems and working toward 1,000 useful commits/day on GitHub.

Bob is built with Bob. The system is its own existence proof: a non-trivial multi-package codebase carried through the Duplo → McLoop → Orchestra path is the most direct evidence available that a deterministic framework around stochastic actors produces code good enough to build the framework.

McLoop installs one Claude Code PreToolUse hook that does two jobs.

Approval. In a McLoop session, any tool call you have not whitelisted is sent to Telegram so you can approve or deny it from your phone.

Compression. It rewrites shell commands to run through RTK, a CLI proxy that compresses command output before it reaches the agent and cuts token use by 60-90%.

It is one hook by design. Both jobs have to run as a PreToolUse hook, and Claude Code does not run two of them together correctly, a known bug Anthropic refuses to fix. Folding both into one hook sidesteps it. RTK is optional: when rtk is not on PATH, compression is skipped and the Telegram approval still works.

Install the hook with bob install. It copies the hook into ~/.claude/hooks/, registers it in ~/.claude/settings.json, backs up your existing settings, and is safe to run more than once.

Each package carries its own license. The narrative and coordination material in this workspace, including the abstract, the loop description, and the framing of the Bob toolchain, is copyright 2026 Michael Coen, all rights reserved.