I almost closed the tab. Another tool announcing "the end of vibe coding" triggers the same reflex as a phishing email at this point. Then I noticed the title of Traycer's blog post: "Ralph Loops. Bart Orchestrates." That stopped me, because the Ralph loop is a real pattern I have run repeatedly, and "blindly retrying until it works" describes exactly the feeling of watching a Claude Code loop grind against the same failing test at 2 AM. So I gave Traycer's Bart mode a real test: a dashboard project I was going to build anyway, run through Bart in parallel against the manual plan-driven Claude Code workflow I have shipped side projects with for six months. My verdict up front: Bart mode does something the Ralph loop architecturally cannot, and it still left me forty minutes of hand-polish it will not admit to.
The Ralph loop problem nobody puts on a sales page
The dominant autonomous-coding pattern in 2026 is the Ralph loop, named for the Simpsons kid who keeps trying: point an agent at a task, wrap it in a while-not-done loop, and let it grind. Fresh context each iteration, read the plan file, attempt work, verify, repeat. I have run it in production and it genuinely ships cleanly-scoped features overnight. I broke down the whole pattern family in my agent loop engineering explainer, so here I will just name the two structural weaknesses that have cost me real hours.
First, blind retry. When the loop fails, it does not know why in any way the next iteration can use. If task 4 is wrong because the plan is wrong, not the execution, the loop will happily regenerate the same broken code for six hours. I watched a Ralph loop on a friend's project burn roughly 400,000 tokens implementing a Stripe webhook that did not need to exist, because the spec had drifted from reality two tickets earlier.
Second, no orchestration layer. One agent, one tight circle. It cannot parallelize, cannot escalate to a human at the right moment, and critically cannot adapt the plan when implementation reveals something the plan missed. It can only execute.
Traycer's claim is that Bart is not a better Ralph loop but a different category: an outer-loop orchestrator that watches the inner loops, steers the plan as it evolves, and stops to ask you a question instead of hallucinating an answer. That framing could be marketing. I tested it.
What Bart mode actually is
Traycer sits between you and your coding agent (Claude Code, Cursor, Windsurf) and turns intent into structured, executable specs. Four modes compose from small to large: Plan (file-by-file plan for a scoped change), Phases (complex features with checkpointed handoffs), Review (agentic code review), and Epic (whole projects with living specs and a ticket backlog). Bart is Epic mode's hand-off-everything option, internally nicknamed Smart YOLO. The line from Traycer's own framing that I kept returning to: when implementation conflicts with specs, Bart does not invent a new truth; it stops, states the mismatch, and makes you pick the constraint.
Traycer is agent-agnostic and runs no inference of its own, so model choice matters. I ran the test with Claude's Opus-class model as the execution agent. The free tier (one slot, with a Pro trial) got me through Epic setup and the first two batches; paid plans ran $10, $25, and $40 a month at the time of this test.
The test project
No toy demos; toys flatter every tool. The brief, written the way I would brief a real engineer: an internal dashboard in Next.js 15, TypeScript, Tailwind, shadcn/ui. Supabase magic-link auth, a protected /agents route fetching from an external API with a keyed POST, a filterable agents table, a manual-run trigger, and recharts run-history charts. Solo-operator, no multi-tenancy. About a week of manual work, maybe three days through my usual plan-driven Claude Code flow.
Phase one: the questions I would have gotten wrong
I pasted the brief, attached the client API spec and a wireframe screenshot, and expected immediate ticket generation. Instead Traycer asked seven questions, and every one was a bug I would otherwise have met two days in. Server-side or client-side pagination? Expected row count? Is a manual run fire-and-forget or does the UI need live status? Are API keys per-user or global? Chart window: last N runs, time window, or toggle? Behavior when the external API is down? Is "agent type" a fixed enum or does it come from the API?
That last one got me. I had been assuming enum. It is not, and that assumption alone would have blown up a filter component and forced a refactor. None of this is revolutionary engineering; it is a model behaving like a senior engineer who has been burned before. Most tools skip clarification because questions feel like friction. Traycer makes them the opening move, which rhymes with everything I have written about prompting rules that reduce guessing: ambiguity you do not resolve up front becomes code you debug later.
Then it generated not one PRD but a spec tree: tech stack, data models with Zod schemas, auth flow, API integration contracts with retry strategy, UI layout, and a backlog of 14 tickets with acceptance criteria mapped to files. Then it asked: execute in checkpointed phases, or hand the Epic to Bart? I picked Bart.
Phase two: what "orchestrator" means in practice
The ticket board became an orchestration view. Bart grouped tickets into batches by dependency, not list order, and dispatched batch one as four parallel sessions on isolated branches: scaffold, Supabase plumbing, type definitions, API client. No cross-dependencies, so all four ran simultaneously; a Ralph loop would have run them sequentially at roughly four times the wall-clock. Eleven minutes. The isolation pattern will look familiar if you have run parallel agents on git worktrees; Bart automates the branch hygiene.
Then the part that made me lean into the screen. Before dispatching batch two, Bart ran verification, and not "does it compile" verification. It read the generated files against the spec tree and flagged two mismatches: the API client used 3 retries with exponential backoff where the spec said 5 with fixed intervals, and the Agent.status Zod schema used a string union where my clarification answer said the values come from the API. Bart then added two correction sub-tickets to batch two rather than building on broken foundations, and proceeded.
That is the whole thesis in one behavior: parallelism plus closed-loop verification against a living spec, with mid-flight plan adaptation. The Ralph loop cannot do this, not because its authors are careless but because the architecture has no spec-versus-implementation view.
The moment Bart stopped and asked
Batch three exposed a genuine spec contradiction. The run-history chart ticket assumed history came from a local cache (consistent with the caching strategy spec), while the manual-trigger ticket assumed triggering invalidated the cache and re-fetched live (consistent with my clarification answer). Both interpretations were coherent readings of different spec sections. They could not coexist.
A Ralph loop would have silently picked one, and I would have discovered the inconsistency in two weeks when the chart stopped updating after manual runs. Bart stopped the Epic and surfaced a decision card: the mismatch, both interpretations, three proposed resolutions. I picked one in about ninety seconds. Bart updated the spec, regenerated the affected ticket, resumed. Ninety seconds of my time against a probable future debugging session is the best trade this tool offers.
The finish line, and the forty minutes Bart does not report
Ninety-three minutes after handoff, the dashboard was functionally complete: auth working, table rendering, filters live, chart drawing, trigger firing, dev server booting clean. Here is what I still fixed by hand.
A styling regression: the filter bar's Select component used defaults that did not match the dashboard, because the spec was silent and Bart's inference was wrong. Four minutes. A UX judgment call: the empty state said "No results" where a human writes "No agents found. Add your first agent from settings." Bart wrote the literal spec and nothing more. Three minutes. A security nit: the client-side trigger called /api/agents/run without CSRF protection because the spec did not require it; fine for a solo internal tool, not fine for anything shipping to a team. Eight minutes of middleware. And no tests, because my spec did not ask for tests; twenty-two minutes for the critical ones.
Roughly forty minutes of craft on top of the orchestration. Brief to client-ready in about two and a half hours total, most of which I spent doing other work. My comparable manual Claude Code project last month took four focused hours plus two more the next morning. That is the honest size of the win: large, and not the "zero human effort" of the demos.
What three weeks of spec-driven development taught me
Specs are harder to write than code. The opposite of the pitch, and true. An unambiguous, self-consistent spec demands product clarity most of us do not carry into day one. Traycer's questions help; they do not replace the skill.
The parallelism ceiling drops fast. Batch one: four parallel tickets. Batch two: two. Batch three: one. Dependency graphs flatten toward sequential as an Epic progresses, so the parallel-agents story is real early and fades late.
Spec drift is the new code drift. My API-integration spec went through three mid-flight revisions. The final spec was better than the one I approved, and it was not the one I approved. Review the final spec state, always.
The model matters as much as the orchestrator. I ran the same Epic on two different frontier models. The Claude run produced cleaner component structure and caught more implicit conventions; the other was faster and more literal. Bart is only as good as the agent it dispatches.
Pausing is first-class. Twice I paused Bart not because it failed but because watching the ticket flow triggered a product realization I wanted in the spec. In a Ralph loop, pausing means restarting. Here it is a button.
Where Bart fits against Claude Code
Bart does not replace Claude Code; it clarified for me what Claude Code is for. Use Bart when the project has five-plus tickets, parallelizable parts, and a spec you can actually write: greenfield builds, well-scoped migrations. Use Claude Code manually for single-concern tasks, exploratory work where you do not know the end state, and codebases whose implicit conventions a spec would miss; that surgical layer is where the practices in my advanced Claude Code workflow guide live. My current split is both in one week: Bart builds the scaffolding Monday, I take over in Claude Code for polish, tests, and UX writing, and the context-file discipline from the Karpathy-style CLAUDE.md approach is what makes the handoff between the two clean.
The Ralph loop was always an all-or-nothing bet. Bart makes autonomy partial, structured, and reversible: every batch reviewable, every spec edit logged, every ticket reproducible. Whether the tool itself survives the year, that architecture is the direction this category is going.
Run the head-to-head yourself on one real ticket before you adopt anything: your current loop versus a spec-first pass on the same brief. If your agent sessions wander, the spec is the fix, whatever tool enforces it. And if you would rather have someone who has already made these mistakes wire spec-driven development into your team's actual stack, tell me what you are building and I will give you a straight answer on whether it fits.
