VibeSlice — Multi-Model Development Harness for Long-Running AI Projects

The Problem

An AI agent is good for an afternoon. Leave it on a complicated project for months and the failures change: it forgets why earlier decisions were made, it approves its own plans, it reports work it didn’t finish, and a session that dies mid-task leaves nobody sure what state the project is in.

VibeSlice is the harness I designed for that. Work moves through it in slices, and every slice follows the same step-governed workflow from direction and spec to a merged, reviewed change. The rule underneath all of it: progress is validated against artifacts on disk, never inferred from the agent’s account of it. It is a Python control plane with a CLI and an MCP server, driven from Claude Code or Codex, and it runs the same way on every project it manages.

My Role

I own the process: what each workflow step has to produce, the rules for what an agent may do unattended, the standard a slice has to meet, and the judgement calls when two reviewers disagree and both have a point. Scope decisions are mine by rule. The pipeline writes the code and takes its own changes through the same harness.

What the Harness Does

• Workflow

  One process, checked by tooling

  Every slice goes through the same steps. A CLI validates the project's state against the artifacts each step requires and refuses to advance on a mismatch. Gates can't be skipped, and some steps stop for a human.

• Continuity

  Direction and state outlive the session

  A standing direction document carries my intent into every session. Workflow state lives on disk, so a session that dies mid-slice resumes from the record, and a fresh session starts from the record rather than from a chat transcript.

• Review

  Critique from rival vendors

  Specs, plans and code are reviewed by models from other vendors until they converge, and the author answers every finding on the record. Disputed technical questions go to a structured debate between reviewers instead of a guess.

• Evidence

  Sealed readbacks

  At the end of a slice the harness renders what was actually done against what was specified, flags drift between the two, and seals the record with a digest so it can't be quietly edited afterwards.

• Autonomy

  Unattended runs with a kill switch

  A director mode runs the workflow overnight inside a signed authorization that bounds what it may touch. It fails closed, keeps a ledger of every action, and cannot promote a feature. That merge stays mine.

• Health

  Diagnostics before work starts

  A doctor command checks the install, the reviewer seats and the project's state at the start of a session, so a dead seat or a stale setup is found before it costs a day.

How Review Works

Author

Draft

A spec, a plan, or a code change

Review round

• Reviewer Seat 1
• Reviewer Seat 2
• Reviewer Seat 3

Each seat is a different vendor's model, drawn from Anthropic, OpenAI, xAI, Google, NVIDIA NIM.

Converged

Reviewers agree

Only then does it come to me

Fix it or argue it, then the next round

Findings go back to the author, who fixes each one or argues against it. Then the next round starts.

An author produces a slice. Reviewers on different vendors’ models raise findings. The author fixes each one or argues against it, on the record. Rounds repeat until they converge, or the loop gives up and hands the decision to me. The hard parts were elsewhere: knowing when a round has actually ended rather than when the text looks conclusive, keeping a reviewer’s memory of the argument across rounds, and telling a vendor outage apart from the end of a review.

What It Caught

All four came out of review on ProjectOmega, on code that compiled, passed a smoke test, and had already been approved by a single model.

• Code review

  The host's call for help never reached the other player

  A multicast on the wrong class only ever reached its own connection. Moved, with a test written to fail first.

• Architecture review

  A weapon that would lock up after one early shot

  Routine server rejections didn't advance the request counter, so every later shot looked out of sequence.

• Code review

  A same-tick crash between two player states

  One player bleeding out while another went down in the same tick crashed the server. Found before sign-off.

• Technical debate

  An ability system that may not exist yet on a joining client

  Settled across several reviewers rather than guessed at, and the resolution is now the project's standing rule.

Where It Doesn’t Help

Review is slower than no review and costs real money per slice. It catches reasoning errors well and runtime behaviour badly: reviewers will argue confidently about code none of them has run. On the game, a misspelled engine console command survived three rounds and was only caught when it executed. One packaged build silently used the wrong map, which no amount of reading would have found. So review is not the bar for done. A packaged two-player run is, and I play every slice myself.

The harness also costs process. Every slice carries its spec, plan, reviews and readback, which is more ceremony than a one-afternoon change deserves. It earns that back on projects long enough to forget their own history, which is what it was designed for.

Tools & Tech

Python, Model Context Protocol, a workflow CLI and MCP server, Codex CLI and Claude Code as drivers, pytest, Git, and reviewer seats across Anthropic, OpenAI, xAI, Google and NVIDIA NIM-hosted open models.