Traycer Bart Mode: Mein Test mit spezifikationsgetriebener KI-Entwicklung

Traycer Bart Mode: Mein Test mit spezifikationsgetriebener KI-Entwicklung

Ich war kurz davor, den Tab zu schließen.

Ich war drei Absätze tief in einem Hacker-News-Thread über "agentische Coding-Orchestratoren", als mein Gehirn diesen müden Blick bekam – das Gefühl, wenn man die Wendung "Ende des Vibe Codings" so oft gelesen hat, dass ein weiteres Tool, das sich selbst als das Ende des Vibe Codings bezeichnet, denselben Reflex auslöst wie eine Phishing-Mail. Ich war bereit, weiterzuklicken. Dann fiel mir der Name ganz oben im Thread auf: Traycer. Nicht Tracer. Nicht TracerAI. Traycer, absichtlich merkwürdig geschrieben, mit einem Blogpost mit dem Titel „Ralph Loops. Bart Orchestrates.“

Dieser Titel hat mich gestoppt. Denn die Ralph-Schleife ist ein echter Vorgang, den ich selbst ausgeführt habe. Mehrfach. Und „blindes Wiederholen bis es klappt“ beschreibt genau das Gefühl, mitten in der Nacht eine Claude-Code-Schleife dabei zu beobachten, wie sie immer wieder am selben fehlschlagenden Testfall scheitert, während ich kalten Kaffee trinke und meine Lebensentscheidungen infrage stelle.

Also habe ich Traycer seine 90 Minuten gegeben. Ich bin im Bart-Modus ein echtes Projekt durchgegangen – ein kleines Agenten-Manager-Dashboard mit Authentifizierung und API-Integration – und habe es parallel gegen einen manuellen, plangetriebenen Workflow in Claude Code laufen lassen, so wie ich in den letzten sechs Monaten die meisten meiner Nebenprojekte ausgeliefert habe.

Was ich gefunden habe, entsprach weder dem Hype noch meinem Skeptizismus. Der Bart-Modus von Traycer macht tatsächlich etwas, das die Ralph-Schleife nicht kann – aber er tut das auch auf eine Art, die verändert, was "autonomes KI-Coding" eigentlich bedeutet. Nicht jedes Projekt profitiert davon. Hier kommt die vollständige Schritt-für-Schritt-Analyse: Was funktioniert, was scheitert – und für wen das Ganze tatsächlich gemacht ist.

Das Ralph-Loop-Problem, über das niemand spricht

Bevor klar wird, warum der Bart-Modus entscheidend ist, braucht man das mentale Modell dessen, was er eigentlich ersetzt. Und das beginnt mit dem Verständnis, was die meisten Menschen meinen, wenn sie 2026 von „autonomem AI Coding“ sprechen.

Das dominierende Muster ist derzeit die Ralph-Schleife. Benannt nach Ralph Wiggum aus den Simpsons (dem Jungen, der es immer wieder versucht, aber nicht immer Erfolg hat), ist die Ralph-Schleife gnadenlos einfach: Man setzt einen AI-Coding-Agenten auf eine Aufgabe an, packt ihn in eine while not done-Schleife und lässt ihn laufen. Jede Iteration beginnt mit frischem Kontext, liest eine Plan-Datei von der Festplatte, übernimmt einen Arbeitsabschnitt, verifiziert und startet die Schleife erneut. Die zugrundeliegende Philosophie ist reine Hartnäckigkeit – wenn ein Versuch scheitert, wird es erneut versucht, mit leicht verändertem Kontext.

Ich habe die Ralph-Schleife produktiv eingesetzt. Es funktioniert. Manchmal sogar beeindruckend gut. Ein sauber abgegrenztes Feature mit soliden Tests und einem einzigen Repository kann tatsächlich über Nacht ausgeliefert werden, während der Agent Iteration um Iteration abarbeitet. Vercel Labs liefert eine ralph-loop-agent-Implementierung. Das GitHub-Repository snarktank/ralph gehört in diesem Jahr zu den meist-gestarred autonomen Coding-Repos. Das Pattern ist real, und es trägt aktuell viele Indie-Shipping-Workflows.

Aber es gibt etwas, das auf keiner Sales-Page steht. Die Ralph-Schleife hat zwei strukturelle Schwächen, und beide haben mich Stunden an Produktivzeit gekostet:

Problem eins: Blindes Wiederholen. Wenn die Schleife scheitert, weiß sie nicht warum – jedenfalls nicht so, dass die nächste Iteration das Wissen nutzen könnte. Sie liest die Plan-Datei, sieht „Task 4 nicht erledigt“ und versucht Task 4 erneut. Liegt Task 4 aber falsch, weil schon der Plan falsch war – nicht etwa die Ausführung –, generiert die Schleife stundenlang denselben fehlerhaften Code immer wieder. Ich habe erlebt, wie eine Ralph-Schleife auf einem Projekt eines Freundes 400.000 Tokens verbrannt hat, um ein Stripe-Webhook-Endpoint zu bauen, das gar nicht gebraucht wurde, weil bereits zwei Tickets vorher die Spezifikation nicht mehr zur Realität passte.

Problem zwei: Keine Orchestrierungsschicht. Die Ralph-Schleife bedeutet: ein Agent, eine Aufgabe, im engen Kreis. Sie kann nicht parallelisieren, sie kann nicht im richtigen Moment an einen Menschen eskalieren und vor allem kann sie den Plan nicht anpassen, wenn bei der Implementierung etwas Unerwartetes auftaucht. Sie kann nur ausführen.

Dieses zweite Problem brachte mich schließlich dazu, tatsächlich auf den Traycer-Signup-Button zu klicken. Denn der Bart-Modus – laut Traycers eigener Darstellung – ist nicht einfach nur eine Ralph-Schleife mit besseren Prompts. Es ist eine ganz andere Kategorie. Ein Outer-Loop-Orchestrator, der die Inner Loops beobachtet, den Plan mitsteuert, während er sich weiterentwickelt, und weiß, wann man lieber eine Rückfrage stellt, anstatt eine Antwort zu halluzinieren.

Dieses Framing könnte reines Marketing sein. Oder genau das, worauf ich gewartet habe. Es gibt nur einen Weg, das herauszufinden.

Was Traycer Bart Mode eigentlich ist

Bevor ich auf den Test eingehe, ist der Produktkontext entscheidend, denn "Traycer" ist ein häufig genutzter Name und die Details bestimmen, ob das Ganze für Ihren Workflow relevant ist.

Traycer ist eine spec-getriebene Entwicklungsplattform – sie sitzt zwischen Ihnen und Ihrem Coding-Agenten (Claude Code, Cursor, Windsurf, was auch immer Sie nutzen) und wandelt absichtsbasierte Vorgaben in strukturierte, ausführbare Spezifikationen um. Die Plattform bietet vier Task-Modi, und Bart Mode ist eine spezifische Ausführungsstrategie innerhalb des Epic Mode – dem größten und autonomsten Modus im System.

So setzen sich die Modi, vom kleinsten bis zum größten Umfang, zusammen:

• Plan Mode – für klar umrissene Aufgaben. Beschreiben Sie eine Änderung, erhalten Sie einen Implementierungsplan auf Datei-Ebene und übergeben Sie ihn an Ihren Coding-Agenten. Dieser Modus steht in direkter Konkurrenz zu Claude Codes /plan.
• Phases Mode – für komplexe Features. Traycer klärt die Intention, bricht die Arbeit in geführte, Kanban-ähnliche Phasen auf, plant jede Phase, gibt sie an Ihren Agenten weiter und überprüft die Ergebnisse an jedem Checkpoint. Das ist das Kanban-ähnliche Phasen-Board, das Anfang 2026 eingeführt wurde.
• Review Mode – ein agentischer Code-Review-Workflow. Tiefenanalyse auf Bugs, Performance, Sicherheit und Lesbarkeit. Sie zeigen auf ein Diff oder einen Repo-Stand und erhalten einen Bericht.
• Epic Mode – zum Steuern ganzer Projekte. Verwalten lebender Spezifikationen und eines Ticket-Backlogs, Ausführung in kontrollierten Phasen oder Übergabe des gesamten Epics an Bart.

Bart Mode ist die Option „das gesamte Epic übergeben“. In den Traycer-Dokumentationen heißt das intern Smart YOLO, und im öffentlichen Blog wird es als Outer-Loop Orchestrator beschrieben. Die Unterscheidung zu Ralph ist von Traycer klar herausgestellt: Bart ist kein Worker, der in einer engen Schleife läuft. Bart steuert ein Feedback-System quer über Spezifikationen, Tickets, Diffs, Verifikationsergebnisse und menschliche Entscheidungen – und passt den Plan an, während sich der Code weiterentwickelt.

Konkret bedeutet das: Sie beschreiben ein Projekt, Traycer erstellt die Spezifikationen, Bart teilt diese in Tickets auf, Bart führt Tickets in parallelen Batches mit Ihrem gewählten Coding-Agenten aus, Bart überprüft jedes Batch nach der Ausführung gegen die Specs, und Bart setzt entweder fort, passt den Plan an oder eskaliert zu Ihnen, wenn er auf einen nicht lösbaren Widerspruch trifft.

Der Schlüsselsatz in Traycers eigener Beschreibung ist der, zu dem ich immer wieder zurückkomme: „Wenn die Implementierung mit den Specs kollidiert, halluziniert Bart keine neue Wahrheit. Er stoppt und sagt: Hier ist die Abweichung. Hier sind die Optionen. Wählen Sie die Vorgabe.“

Dieser Satz – falls er stimmt – ist der Unterschied zwischen ausliefern und sechs Stunden lang AI-Murks debuggen. Finden wir es heraus.

Das Setup: Reales Projekt, echte Konsequenzen

Ich wollte keinen Spielzeug-Test. Spielzeug-Tests schmeicheln jedem Tool. Also wählte ich ein Projekt, das ich diesen Monat sowieso bauen wollte — ein kleines internes Dashboard zur Verwaltung des Agent Managers, den ich für einen Kunden betreibe — und ließ es durch Traycer im Bart-Modus laufen, statt wie sonst mit meinem üblichen Claude-Code-planbasierten Workflow.

Das Projektbriefing, genauso geschrieben, wie ich es einem echten Entwickler geben würde:

Baue ein internes Dashboard. Next.js 15, TypeScript, Tailwind, shadcn/ui. Supabase-Authentifizierung (E-Mail + Magic Link). Geschützter Pfad unter /agents, der von einer externen API abruft (POST mit API-Key aus der Umgebung), zeigt Agents in einer Tabelle mit Filtern (Status, Letzter Lauf, Agententyp), ermöglicht manuelles Triggern eines Laufs. Diagramme für die Laufhistorie (recharts). Kein Multi-Tenancy. Solo-Operator-Dashboard.

In etwa eine Woche Arbeit, wenn ich es selbst schreiben würde. Vielleicht drei Tage, wenn ich es mit Claude Code und sauberem Plan durchziehe. Die Frage: Was macht Bart-Modus daraus?

Ich habe mich für den Free-Tarif angemeldet — Traycers Free-Plan kostet 0 $/Monat, erlaubt einen Slot und unbegrenztes Open-Source-Task-Guthaben, mit 7-tägiger Pro-Testphase, falls man mehr Kapazität möchte. Für diesen Test reichte der Free-Tarif locker, um das Epic-Setup und die ersten beiden Ausführungs-Batches durchzuziehen, bevor ich nach mehr Parallelität hätte verlangen wollen. Bezahlpläne kosten zum Zeitpunkt dieses Artikels 10 $/Monat (Lite), 25 $/Monat (Pro) und 40 $/Monat (Pro+), jeweils mit 20 % Rabatt bei jährlicher Zahlung.

Die Modellauswahl spielt hier eine entscheidende Rolle. Traycer ist agenten-agnostisch — es führt keine eigene Inferenz durch, sondern orchestriert jeden Coding-Agenten, den du authentifiziert hast. Den Test habe ich mit Claude Opus 4.7 als Ausführungsmodell durchgeführt, das Anthropic am 16. April 2026 veröffentlicht hat: SWE-bench Verified bei 87,6 % (vorher 80,8 % bei Opus 4.6) und 70 % bei CursorBench. Wer im April 2026 die echte Obergrenze für spec-driven autonomes Coding sucht, findet sie in dieser Kombination.

Phase Eins: Vom Briefing zur Spezifikation

Das Erste, was mich überrascht hat, war, wie Traycer mit dem Briefing umging. Ich habe es in ein neues Epic eingefügt, zwei Kontextdateien hinzugefügt (die bestehende Client-API-Spezifikation und einen groben Wireframe-Screenshot) und erwartet, dass sofort Tickets generiert werden. Das passierte jedoch nicht. Stattdessen stellte mir Traycer sieben Fragen – und jede einzelne davon hätte ich falsch beantwortet, wenn ich sie übersprungen hätte.

Die Fragen, in der Reihenfolge ihres Eintreffens:

1. Soll die Agenten-Tabelle serverseitig oder clientseitig paginiert werden?
2. Wie viele Zeilen werden erwartet – unter 100, Hunderte oder Tausende?
3. Wenn ein manueller Durchlauf ausgelöst wird, ist das erwartete Verhalten „fire-and-forget“ oder soll die Benutzeroberfläche einen Live-Status anzeigen?
4. Sind API-Keys nutzerbezogen oder global für den Workspace?
5. Soll das Run-History-Diagramm die letzten N Runs, ein Zeitfenster oder beides mit Umschaltmöglichkeit anzeigen?
6. Welches Verhalten wird gewünscht, wenn die externe API nicht erreichbar ist – letzter bekannter Zustand aus dem Cache, leerer Zustand oder ein Banner?
7. Ist „agent type“ ein festes Enum oder kommt es als Antwort von der API?

Jede dieser Fragen hätte zwei Tage nach Baubeginn zu einem Bug geführt. Die Frage „Ist agent type ein festes Enum oder aus der API?“ besonders – ich war davon ausgegangen, dass es sich um ein Enum handelt. Tut es aber nicht. Genau diese Annahme hätte eine Filterkomponente zum Explodieren gebracht und ein Refactoring erzwungen.

Genau das bezeichnet Traycer als Phases mode clarification und es läuft direkt im Epic-Setup ab. Das ist keine revolutionäre Ingenieurskunst. Was es ist: Ein Modell agiert wie ein Senior Engineer, der schon einmal auf die Nase gefallen ist und genau weiß, an welchen Annahmen man scheitert. Die meisten AI-Coding-Tools überspringen diesen Schritt, weil Klärungsfragen wie ein Hindernis wirken. Traycer macht sie zum Einstieg.

Nachdem ich die Fragen beantwortet hatte, generierte Traycer die Spezifikationen. Plural. Kein monolithisches PRD, sondern einen Spezifikationsbaum:

• tech-stack.md — Next.js 15 App Router, TypeScript Strict Mode, Tailwind v4, shadcn/ui-Komponentenliste, Supabase-Client-Setup
• data-models.md — Agent-, Run-, RunHistory-Typen mit Zod-Schemata
• auth-flow.md — Magic-Link-Flow, Middleware für geschützte Routen, Sitzungsverwaltung
• api-integration.md — Endpoint-Verträge, ENV-Variable-Handling, Retry/Error-Strategie
• ui-layout.md — Routenstruktur, Komponenten-Hierarchie, Responsive Breakpoints
• ticket-backlog.md — 14 Tickets mit Akzeptanzkriterien, den Files zugeordnet

Das ist der Punkt, an dem Ralph-loop-Workflows dem Agenten normalerweise eine einzelne Plan-Datei übergeben und fertig. Traycer ging anders vor: Es zeigte mir die Tickets und fragte, welchen Ausführungspfad ich wählen möchte. Ausführen in Phases (kontrollierte Checkpoints zwischen den Phasen) oder Übergabe an Bart (autonomes End-to-End).

Ich entschied mich für Bart.

Phase Two: Bart übernimmt das Steuer

In dem Moment, in dem man Bart ein Epic übergibt, ändert sich die Benutzeroberfläche. Das Ticket-Board verwandelt sich in eine Orchestrierungsansicht. Man sieht, wie Bart Tickets in Batches zusammenstellt – gruppiert nach Abhängigkeiten, nicht nach Listenreihenfolge – und sie parallel abarbeitet.

Für mein Projekt bestand der erste Batch aus vier gleichzeitig laufenden Tickets:

• T-01 — Projekt-Scaffold + Tailwind + shadcn-Setup
• T-02 — Supabase-Client + Env-Var-Verdrahtung
• T-03 — Typdefinitionen + Zod-Schemas
• T-04 — API-Client-Modul mit Retry-Logik

Diese vier Tickets haben keine wechselseitigen Abhängigkeiten – sie können alle parallel bearbeitet werden. Eine Ralph-Loop hätte sie sequenziell abgearbeitet und mich ungefähr die vierfache Echtzeit gekostet. Bart bearbeitete sie parallel, mit vier separaten Claude Opus 4.7 Sessions auf vier isolierten Branches. Gesamtdauer für den ersten Batch: elf Minuten.

Dann passierte etwas, das mich tatsächlich näher an den Bildschirm rücken ließ.

Nachdem der erste Batch abgeschlossen war, hat Bart nicht sofort den zweiten Batch gestartet. Er hat eine Verifikation durchgeführt. Nicht nur „wurde der Code kompiliert“ – echte Spezifikationsverifikation. Er las die generierten Dateien, verglich sie mit dem Spezifikationsbaum und markierte zwei Abweichungen:

1. Das API-Client-Modul nutzte eine Retry-Anzahl von 3 mit exponentiellem Backoff. Die Spezifikation api-integration.md verlangte 5 Retries mit fixen 2-Sekunden-Intervallen. Bart hat es bemerkt.
2. Das Zod-Schema für Agent.status verwendete eine String-Union. Die aus meiner Klarstellungsantwort abgeleitete Spezifikation verlangte, dass es aus der API-Antwort kommt, nicht aus einer festen Union. Bart hat es bemerkt.

Dann – und das ist der entscheidende Punkt – aktualisierte Bart die Tickets des zweiten Batches inklusive Korrekturen für diese Abweichungen, statt den zweiten Batch einfach auf eine fehlerhafte Basis zu setzen. Er fügte zwei Sub-Tickets zum Backlog hinzu: T-04b (Retry-Konfiguration korrigieren) und T-03b (agent.status dynamisch machen), zog sie in den zweiten Batch und fuhr dann fort.

Das ist es, was „Orchestrator“ in der Praxis tatsächlich bedeutet. Nicht Parallelismus um des Parallelismus willen. Parallelismus plus Closed-Loop-Verifikation gegen eine lebende Spezifikation, mit der Fähigkeit, den Plan während der Ausführung anzupassen. Der Ralph-Loop kann das nicht. Nicht, weil die Autoren nicht daran gedacht hätten – sondern weil die Architektur es nicht zulässt. Der Ralph-Loop kennt keine Spezifikation-vs.-Implementierungs-Ansicht. Bart schon.

Der Moment, als Bart stoppte und eine Frage stellte

Batch drei war der Punkt, an dem ich verstand, was Traycers Blog mit „Bart halluziniert keine neue Wahrheit“ meint.

Das Batch umfasste T-09 (Verlaufsgrafik der Runs) und T-10 (manueller Trigger-Button). Beide wurden abgeschlossen. Barts Verifizierung meldete jedoch einen Konflikt: Das Chart-Ticket ging davon aus, dass der Verlauf aus einem lokalen Datenbank-Cache bezogen wird (abgeleitet aus der Caching-Strategie von api-integration.md), während das Ticket für den manuellen Trigger annahm, dass beim Triggern der Cache invalidiert und erneut von der externen API geladen wird (basiert auf meiner Klarstellung zur Live-Status-Anfrage).

Beide Interpretationen waren mit unterschiedlichen Teilen der Spezifikation konsistent. Beide waren in sich schlüssig. Doch sie ließen sich nicht miteinander vereinbaren — eine Option musste weichen.

Ein Ralph-Loop hätte eine Lösung einfach gewählt. Still und leise. Und ich hätte die Inkonsistenz erst in zwei Wochen entdeckt, wenn sich der Verlauf nach dem manuellen Trigger nicht mehr aktualisiert hätte.

Bart stoppte das Epic und präsentierte eine Entscheidungskarte in der UI. Die Karte zeigte den Widerspruch, die beiden Interpretationen und drei mögliche Lösungen (Cache beim Trigger ungültig machen, Cache behalten, aber optimistisches Update anzeigen, immer Live-Fetch für das Chart). Ich wählte eine Option. Bart aktualisierte die Spezifikation, generierte das betroffene Ticket neu und setzte den Prozess fort.

Gesamter menschlicher Zeitaufwand für diese Entscheidung: vielleicht 90 Sekunden. Wahrscheinlich gesparte Zeit: mindestens eine vollständige Debugging-Session zwei Wochen später.

Falls du das lieber einem Team vollständig übergeben möchtest, anstatt dir noch ein weiteres Tool draufzuschaffen: Ich biete Claude-Code- und Agent-Orchestrierungs-Projekte auf Fiverr an — genau solche spezifikationsgetriebenen Workflows setze ich aktuell am häufigsten für Kunden um.

Phase Drei: Die Ziellinie und was Bart übersehen hat

Nach dreiundneunzig Minuten Echtzeit, nachdem ich Bart das Epic übergeben hatte, war das Dashboard funktional fertiggestellt. Auth funktionierte. Die Agenten-Tabelle wurde gerendert. Filter waren funktional. Diagramm wurde angezeigt. Manueller Trigger feuerte. Lokaler npm run dev startete sauber.

Das klingt nach einer Ehrenrunde. Ist es aber nicht ganz.

Das musste ich nach Barts Meldung „Epic abgeschlossen“ von Hand korrigieren:

Ein Styling-Regression. Die shadcn/ui Select-Komponente in der Filterleiste nutzte das Standard-Styling, das nicht zum Rest des Dashboards passte. Die Spezifikation hatte nichts festgelegt – Bart leitete die Defaults ab – aber die Schlussfolgerung war falsch. 4 Minuten zum Beheben.

Eine UX-Ermessensfrage. Der Leerstaat der Agenten-Tabelle – wenn die externe API null Agenten zurückgab – zeigte eine generische „Keine Ergebnisse“-Meldung an. Ein echter Mensch hätte etwas Spezifisches geschrieben („Keine Agenten gefunden. Fügen Sie Ihren ersten Agenten im Einstellungsbereich hinzu.“). Bart schrieb exakt das, was die Spezifikation nahelegte und nicht mehr. 3 Minuten zum Anpassen.

Ein Security-Detail. Der API-Key wurde im Server-Code korrekt aus den Umgebungsvariablen gezogen, aber die Client-Komponente, die manuelle Ausführungen auslöste, machte einen Fetch-Call zu /api/agents/run ohne CSRF-Schutz. Die Spezifikation verlangte kein CSRF. Bart fügte es nicht hinzu. Für ein Solo-Dashboard ist das okay. Für ein Team-Produkt wäre das nicht akzeptabel. 8 Minuten, um Middleware hinzuzufügen.

Keine Tests. Bart schreibt nur Tests, wenn die Spezifikation es verlangt. Meine tat das nicht. Ich habe die wichtigsten Tests (Auth-Redirect, API-Fehlerbehandlung) manuell hinzugefügt. 22 Minuten.

Gesamte Nachbesserungszeit: ungefähr 40 Minuten. Nicht null. Nicht trivial. Aber das Projekt wurde in etwas mehr als zweieinhalb Stunden vom Auftrag bis zur „bereit zum Kunden zeigen“-Reife gebracht, und ich war währenddessen größtenteils mit anderen Aufgaben beschäftigt.

Zum Vergleich: Mein manueller, auf Claude Code und einem planbasierten Workflow aufbauender Prozess für ein ähnlich großes Projekt hat mich letzten Monat etwa vier fokussierte Stunden Live-Coding gekostet, plus weitere zwei Stunden am nächsten Morgen für den Feinschliff. Bart Mode hat das in eine Session komprimiert, in der ich größtenteils nur zugeschaut habe.

Bart-Modus vs. Claude Code: Wann welches Tool einsetzen

Ich denke nicht, dass der Bart-Modus Claude Code ersetzt. Inzwischen nutze ich beide, und die Frage, die ich mir vor jedem Projekt stelle, ist: Hat dieses Projekt genug Komplexität, damit sich spec-gesteuerte Entwicklung wirklich lohnt?

Hier ist die Entscheidungslogik, die ich nach drei Wochen mit Traycer verwende:

Bart-Modus verwenden, wenn:

• Das Projekt 5+ voneinander unabhängige Komponenten oder Tickets hat
• Mehrere Teile sich parallel entwickeln lassen, ohne sich gegenseitig ins Gehege zu kommen
• Die Spezifikation klar formuliert werden kann (neue Features, grüne Wiese, klar umrissene Migrationsprojekte)
• Du das Projekt unterbrechen und später zu einem funktionierenden Stand zurückkehren möchtest
• Du einen bezahlten Traycer-Account mit entsprechendem Parallelisierungsspielraum hast

Claude Code manuell nutzen, wenn:

• Die Aufgabe eine einzelne Datei oder ein einzelnes Anliegen betrifft
• Du dich noch im explorativen oder Research-Modus befindest und das Ziel noch unklar ist
• Der bestehende Code viele implizite Konventionen enthält, die beim Spezifizieren leicht verloren gingen
• Du jede Entscheidung in Echtzeit treffen möchtest (Pair-Programming-Modus)
• Die Aufgabe erfordert, dass du Fehler im Kontext behebst, was Specs nicht abbilden können

Beides im selben Workflow nutzen, wenn:

• Bart das Grundgerüst und die strukturellen Tickets übernimmt
• Du für UX-Polishing, Tests und alles, was Specs nicht abdecken, zu Claude Code wechselst
• Genau so arbeite ich aktuell sehr produktiv

Das Interessante an dieser Aufteilung ist: Der Bart-Modus macht Claude Code nicht schlechter — er macht klarer, wofür Claude Code eigentlich gedacht ist. Claude Code ist ein chirurgisches Präzisionswerkzeug. Der Bart-Modus ist das Gerüst für größere Strukturen. Ich habe das Präzisionswerkzeug immer genutzt, um Gerüste zu bauen, und deshalb fühlten sich sechsstündige, plangesteuerte Coding-Sessions irgendwann zäh an, selbst wenn sie abgeliefert haben.

Worüber sonst niemand bei spec-getriebener Entwicklung schreibt

Nach drei Wochen hier die Dinge über spec-getriebene AI-Entwicklung, die ich weder auf Produktseiten noch in YouTube-Demos gesehen habe.

Specs sind schwerer zu schreiben als Code. Ich weiß. Das widerspricht dem Verkaufsargument. Aber eine gute Spezifikation zu schreiben – eine, die eindeutig, vollständig und widerspruchsfrei ist – erfordert ein Maß an Produktklarheit, das die meisten Einzelentwickler am ersten Tag eines Projekts nicht mitbringen. Die Klarstellungsfragen von Traycer helfen dabei, ersetzen aber das Können nicht. Wenn du 2026 nicht beantworten kannst, „Soll dies serverseitig oder clientseitig paginieren?“, wird Traycer dir kein Produktdenken beibringen. Es wird dich einfach häufiger stoppen und nachfragen.

Die Parallelitätsgrenze ist niedriger als das Marketing suggeriert. Abhängigkeitsgraphen zwischen Tickets flachen schnell ab. In meinem Dashboard-Projekt gab es im ersten Batch vier parallele Tickets. Im zweiten Batch waren es zwei. Im dritten Batch nur noch eins. Sobald du in einem Epic ungefähr die Hälfte geschafft hast, hängen die meisten Tickets vom vorherigen Fortschritt ab und werden sequentiell abgearbeitet. Die „parallelen Agenten“ gibt es am Anfang wirklich, aber gegen Ende werden sie unwichtiger.

Spec Drift ist das neue Code Drift. Wenn Bart die Spezifikation während der Ausführung anpasst, um Unstimmigkeiten zu beseitigen, propagiert diese Änderung sofort durch alle verbleibenden Tickets. Das ist großartig – bis du feststellst, dass sich deine laufende Spezifikation deutlich von der Spez unterscheidet, der du ursprünglich zugestimmt hast. In meinem Projekt durchlief api-integration.md während der Ausführung drei Überarbeitungen. Die finale Spec war besser als die ursprüngliche, aber es war nicht die Spec, die ich abgesegnet hatte. Du musst immer den finalen Stand der Spec prüfen, nicht nur die Originalversion. Traycer macht das einfach – es bleibt trotzdem Arbeit.

Auch Bart profitiert von menschlichen „Rubber Duck“-Momenten. Zweimal im Epic habe ich Bart nicht gestoppt, weil etwas schiefging, sondern weil der Ablauf der Tickets mir eine Produkt-Einsicht brachte, die ich sofort in die Spec einfügen wollte. Barts Fähigkeit, mitten im Epic anzuhalten und sich anzupassen, ist genau das Feature, das solche Pausen günstig macht. Im Ralph-Loop bedeutet Pausieren Neustart. Im Bart-Modus ist Pausieren erstklassig unterstützt.

Das Modell ist genauso entscheidend wie der Orchestrator. Ich habe das gleiche Epic zweimal laufen lassen – einmal mit Claude Opus 4.7 als Ausführungsagenten, einmal mit GPT-5.4. Gleiche Spec, gleiche Bart-Logik, verschiedene Ergebnisse. Opus 4.7 lieferte sauberere Komponenten-Strukturen und erfasste implizite Konventionen aus der Spec besser. GPT-5.4 war schneller und etwas wortgetreuer. Der Orchestrator ist nur so gut wie der Agent, den er steuert. Wähle zuerst das Modell und lass dann Bart seine Arbeit machen.

Wo das im spec-getriebenen Umfeld einzuordnen ist

Traycer ist in diesem Bereich nicht allein. 2026 ist spec-getriebene Entwicklung eine echte Kategorie geworden. Die Tools, die ich dieses Jahr getestet habe:

• Kiro — IDE mit AWS-Anbindung und spec-first-Workflow. Besonders stark für Greenfield-Projekte mit klar definierten Specs. Enge AWS-Integration. Optimal, wenn man sich bereits im AWS-Ökosystem bewegt.
• GitHub Spec Kit — CLI, das spec-getriebene Slash-Kommandos zu Claude Code, Gemini CLI, Cursor und Windsurf hinzufügt. Plattformübergreifend portabel, kein Vendor-Lock-in, aber man setzt den Workflow selbst zusammen.
• BMAD-METHOD — Open-Source-Methodik plus CLI. Streng. Akademischer Charakter. Gewisse Lernkurve.
• Traycer — auf das setze ich mittlerweile bei den meisten Projekten. Stärkste Orchestrierungsschicht von allen, die ich getestet habe. Agent-agnostisch. Klare Trennung zwischen Spec-Autorenschaft und Ausführung.

Traycers Vorteil ist nicht das Spec-Format – der Mehrwert entsteht erst nach dem Spec. Die Kombination aus Epic-Mode und Bart-Orchestrator bietet die geschlossenste End-to-End-Schleife, die ich bisher genutzt habe. Kiros Spec-Autorenschaft ist womöglich noch übersichtlicher. Spec Kits Portabilität ist womöglich überlegen. Keiner bietet jedoch Bart’s Live-Abgleich zwischen Spec und Implementierung.

Wer die breitere Theorie hinter diesem Muster sucht: In meinem früheren Beitrag zum Karpathy claude.md skills install approach zeige ich auf, wie spec-ähnliche Kontextdateien die Qualität der Agenten-Ausgabe beeinflussen, nicht nur bei Traycer. Außerdem liefert mein Vergleich zwischen Claude Codes Ultra-Plan und dem Local-Plan-Modus nützlichen Kontext dazu, wie sich plan-getriebene Workflows im Anthropic-Ökosystem im Vergleich zu spec-getriebenen Ansätzen schlagen.

So nutze ich Bart Mode diesen Monat

Konkreter Workflow, falls du ihn kopieren möchtest:

Montagmorgen. Schreibe ein Epic in Traycer für das Hauptfeature der Woche. Beantworte die Rückfragen. Überprüfe den generierten Spezifikationsbaum. Bearbeite Specs, wenn Traycer meine Präferenzen falsch erraten hat. Übergabe an Bart.

Montagnachmittag. Arbeite an anderen Dingen. Bart führt Batches aus. Ich erhalte UI-Benachrichtigungen, wenn Bart eine Entscheidung eskaliert. Insgesamt verbringe ich vielleicht 15 Minuten am Nachmittag damit, auf Decision Cards zu antworten.

Dienstagmorgen. Bart meldet das Epic als abgeschlossen. Ich ziehe den Branch, starte das Projekt lokal und prüfe es gegen die Spezifikation, behebe Feinschliff-Probleme, schreibe Tests, committe.

Rest der Woche. Ich nutze Claude Code für gezielte Arbeit — den Feinschliff, die Tests, das UX Writing, einmalige Bugs. Also das, was Bart nicht klar genug spezifizieren kann, um es auszuführen.

Das ist nicht "autonomes AI-Coding ersetzt Engineering". Es ist "autonomes AI-Coding übernimmt das Gerüst, ich kümmere mich um die handwerklichen Details". Diese Aufteilung fühlt sich für mich nachhaltig an — ganz im Gegensatz zu der reinen Ralph-Schleife. Die Ralph-Schleife war immer ein Alles-oder-nichts-Spiel. Bart Mode macht Autonomie teilweise, strukturiert und — entscheidend — umkehrbar. Jeder Batch kann überprüft werden, bevor der nächste startet. Jede Spec-Bearbeitung wird protokolliert. Jeder Task ist reproduzierbar.

Häufig gestellte Fragen

Was ist der Traycer Bart-Modus?

Der Traycer Bart-Modus ist ein autonomer Outer-Loop-Orchestrator, der komplette Projekt-Epics End-to-End ausführt, indem er diese in Tickets aufteilt, Tickets in parallelen Batches mit KI-Coding-Agenten abarbeitet, nach jedem Batch anhand der Spezifikationen verifiziert und bei Abweichungen den Plan während der Ausführung anpasst. Er läuft innerhalb des Traycer Epic-Modus und ist agenten-agnostisch — das Ausführungsmodell (z.B. Opus 4.7, GPT-5.4 etc.) wählen Sie selbst.

Worin unterscheidet sich der Bart-Modus von der Ralph-Schleife?

Die Ralph-Schleife wiederholt eine Aufgabe blind, bis die Verifikation bestanden ist, ohne zu erfassen, warum ein Fehler auftritt. Der Bart-Modus dagegen ist “bewusst”: Er pflegt eine dynamische Spezifikation, vergleicht nach jedem Batch die Umsetzung mit dem Soll, passt Tickets bei Abweichungen an und eskaliert an Menschen, falls er Konflikte nicht selbst lösen kann. Ralph ist eine while not done-Schleife. Bart ist ein Orchestrator mit Gedächtnis.

Welche KI-Modelle unterstützt Traycer?

Traycer ist agenten-agnostisch — es führt keine eigene Inferenz durch, sondern orchestriert den Coding-Agent, den Sie authentifizieren. Momentan werden Claude Code (mit Opus 4.7 und Sonnet Varianten), GPT-5.4, Cursor und Windsurf-Integrationen unterstützt. Sie wählen das Modell pro Epic, je nachdem welches Gleichgewicht aus Geschwindigkeit, Kosten und Qualität Sie bevorzugen.

Ist Traycer kostenlos nutzbar?

Ja. Traycer bietet ein Free-Tier mit einer Kapazität von einem Slot für $0/Monat und einer 7-tägigen Pro-Testphase. Bezahlpläne kosten zum Zeitpunkt dieses Artikels $10/Monat (Lite), $25/Monat (Pro) und $40/Monat (Pro+), mit 20% Rabatt bei jährlicher Zahlung. Das Free-Tier reicht aus, um den Bart-Modus bei einem kleinen Epic zu testen.

Wann sollte ich den Bart-Modus nicht nutzen?

Den Bart-Modus sollten Sie auslassen bei Einzeldatei-Edits, explorativer Recherche mit offenem Endzustand oder Codebasen mit ausgeprägt impliziten Konventionen, die in Spezifikationen nicht abgebildet sind. Claude Code manuell ist besser für chirurgische Eingriffe und Live-Pair-Programming. Der Bart-Modus zeigt seine Stärken, wenn ein Projekt 5+ Tickets mit klaren Abhängigkeiten umfasst, die sich präzise als Spezifikation formulieren lassen.

Lassen Sie uns zusammenarbeiten

Möchten Sie KI-Systeme entwickeln, Workflows automatisieren oder Ihre technische Infrastruktur skalieren? Ich unterstütze Sie gerne dabei.

• Fiverr (maßgeschneiderte Lösungen & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsservices): xcybersecurity.io