Traycer Bart Mode: Mijn Ervaring met Spec-Driven AI-Development

Traycer Bart Mode: Mijn Ervaring met Spec-Driven AI-Development

Ik stond op het punt het tabblad te sluiten.

Ik zat drie alinea’s diep in een Hacker News-draad over "agentic coding orchestrators" toen mijn hersenen die vermoeide-blik reflex kregen — het moment waarop je de uitdrukking "einde van vibe coding" zo vaak gelezen hebt dat weer een nieuwe tool die zichzelf het einde van vibe coding noemt, hetzelfde gevoel oproept als een phishingmail. Ik was klaar om door te scrollen. Toen viel mijn oog op de naam boven aan de thread: Traycer. Niet Tracer. Niet TracerAI. Traycer, expres vreemd gespeld, met een blogpost getiteld "Ralph Loops. Bart Orchestrates."

Die titel deed me stoppen. Want de Ralph loop is écht — eentje die ik vaak heb uitgevoerd. En "blindelings opnieuw proberen tot het lukt" beschrijft precies het gevoel van ‘s nachts om 2 uur toekijken hoe een Claude Code-loop vast blijft lopen op dezelfde mislukte test, terwijl ik koude koffie drink en mijn levenskeuzes in twijfel trek.

Dus gaf ik Traycer negentig minuten van mijn tijd. Ik liep Bart mode stap voor stap door op een echt project — een klein dashboard voor agent-management met authenticatie en een API-integratie — en draaide het parallel aan een handmatig, plan-gedreven workflow in Claude Code, wat de afgelopen zes maanden mijn standaard was voor hobbyprojecten.

Wat ik vond, kwam niet overeen met de hype. Maar ook niet met mijn scepsis. Traycer Bart mode doet daadwerkelijk iets wat de Ralph loop niet kan — maar het doet dat ook op een manier die verandert wat "autonoom AI-coden" eigenlijk betekent, en niet elk project heeft daar baat bij. Hier volgt de volledige walkthrough: wat werkt, wat breekt er, en voor wie is dit nu echt bedoeld.

Het Ralph Loop-Problem Waar Niemand Over Praat

Voordat je kunt begrijpen waarom Bart-mode belangrijk is, heb je het mentale model nodig van wat het vervangt. En dat begint met begrijpen wat de meeste mensen bedoelen als ze in 2026 spreken over "autonomous AI coding".

Het dominante patroon vandaag is de Ralph loop. Genoemd naar Ralph Wiggum uit The Simpsons (dat kind dat steeds opnieuw probeert, maar niet altijd slaagt), is de Ralph loop genadeloos simpel: je wijst een AI-coderingagent op een taak, wikkelt hem in een while not done-loop en laat hem draaien. Elke iteratie begint met een frisse context, leest een planbestand vanaf de schijf, probeert een deel van het werk uit te voeren, verifieert, en loopt opnieuw. De filosofie is pure volharding: als een poging faalt, probeer je het opnieuw met een iets andere context.

Ik heb de Ralph loop in productie laten draaien. Het werkt. Soms prachtig. Een scherp afgebakende feature, met sterke tests en een enkele repository kan echt overnight worden uitgerold door de agent die iteratie na iteratie doorploegt. Vercel Labs levert een ralph-loop-agent implementatie. De GitHub-repo snarktank/ralph is een van de meest gestar're autonomous-coding repo’s dit jaar. Het patroon is echt en het is op dit moment essentieel in ontzettend veel indie shipping workflows.

Maar hier is wat niemand op de verkoop-pagina's zet. De Ralph loop heeft twee structurele zwaktes, en beide hebben me echte uren gekost:

Probleem één: blind opnieuw proberen. Wanneer de loop faalt, weet hij niet waarom hij faalde op een manier waarvan de volgende iteratie kan leren. Hij leest het planbestand, ziet "taak 4 niet voltooid", en probeert taak 4 opnieuw. Als taak 4 faalt omdat het plan fout was — niet omdat de uitvoer fout was — dan blijft de loop vrolijk zes uur lang dezelfde gebroken code produceren. Ik heb een Ralph loop op het project van een vriend 400.000 tokens zien verbranden, terwijl die probeerde een Stripe-webhook-endpoint te implementeren dat helemaal niet nodig was, omdat de spec al twee tickets eerder was verouderd.

Probleem twee: geen orchestratielaag. De Ralph loop is één agent die één ding doet in een strakke cirkel. Hij kan niet parallelliseren, hij kan niet op het juiste moment escaleren naar een mens, en — cruciaal — hij kan het plan niet aanpassen wanneer tijdens de implementatie blijkt dat het plan niet klopte. Hij kan alleen uitvoeren.

Dat tweede probleem was waarom ik uiteindelijk op de Traycer-aanmeldknop klikte. Want Bart-mode — volgens Traycer’s eigen definitie — is niet gewoon weer een Ralph loop met betere prompts. Het is een andere categorie. Een outer-loop orchestrator die de inner loops in de gaten houdt, het plan bijstuurt naarmate het evolueert, en weet wanneer het tijd is om jou een vraag te stellen in plaats van zelf een antwoord te verzinnen.

Die framing zou marketing kunnen zijn. Of het zou precies dat kunnen zijn waar ik al die tijd op wachtte. Er is maar één manier om daar achter te komen.

Wat Traycer Bart Mode Eigenlijk Is

Voordat ik op de test inga, is de productcontext van belang, omdat "Traycer" een zeer drukbezette naamruimte is en de details bepalen of dit relevant is voor jouw workflow.

Traycer is een spec-driven development platform — het fungeert als schakel tussen jou en je coding agent (Claude Code, Cursor, Windsurf, of wat je ook gebruikt) en zet intenties op hoog niveau om in gestructureerde, uitvoerbare specificaties. Het platform kent vier taakmodi, en Bart-modus is een specifieke uitvoeringsstrategie binnen de Epic-modus — de grootste en meest autonome modus binnen het systeem.

De modus-opbouw, van klein naar groot:

• Plan-modus — voor duidelijk afgebakende taken. Omschrijf een wijziging, ontvang een file-by-file implementatieplan, draag het over aan je coding agent. Dit is de modus die het meest direct concurreert met Claude Code's /plan.
• Phases-modus — voor complexe features. Traycer verduidelijkt de intentie, breekt het werk op in begeleide Kanban-achtige fasen, plant elke fase, draagt over aan je agent, en verifieert de uitkomsten bij elk checkpoint. Dit is het Kanban-achtige fasenbord dat eerder verscheen in 2026.
• Review-modus — een agentisch code-reviewproces. Diepgaande analyse op bugs, performance, security, en helderheid. Je wijst het aan een diff of repo-status toe, en het rapporteert.
• Epic-modus — voor het beheren van volledige projecten. Beheert levendige specs en een ticket-backlog, laat je uitvoeren in gecontroleerde fasen, of draagt de hele Epic over aan Bart.

Bart-modus is de “geef de gehele Epic uit handen” optie. De Traycer-documentatie noemt het intern Smart YOLO, en de publieke blog omschrijft het als een outer-loop orchestrator. Het onderscheid met Ralph wordt expliciet gemaakt: Bart is geen worker die in een strakke loop runt. Bart beheert een feedbacksysteem over specificaties, tickets, diffs, verificatie-uitkomsten en menselijke beslissingen — en past het plan aan naarmate de code zich ontwikkelt.

In de praktijk betekent dit: jij omschrijft een project, Traycer genereert de specs, Bart splitst deze op in tickets, Bart voert de tickets uit in parallelle batches met jouw gekozen coding agent, Bart verifieert iedere batch na uitvoering aan de hand van de specs, en Bart gaat verder, past het plan aan, of escaleert naar jou wanneer er een mismatch is die niet opgelost kan worden.

De kernzin in Traycers eigen beschrijving waar ik steeds op terugkom is: "Wanneer implementatie niet overeenkomt met de specificaties, hallucineert Bart geen nieuwe waarheid. Hij stopt en zegt: hier is de mismatch. Hier zijn de opties. Kies de beperking."

Die zin — als deze waar is — is het verschil tussen snel leveren en zes uur AI-rotzooi debuggen. Laten we het uitzoeken.

De Setup: Echt Project, Echte Inzet

Ik wilde geen speeltjestest. Speeltjes flatteren elke tool. Dus koos ik een project dat ik deze maand sowieso zou bouwen — een klein intern dashboard voor het beheren van de agent manager die ik voor een klant draai — en ik liet het lopen via Traycer Bart-modus in plaats van mijn gebruikelijke Claude Code plan-gedreven workflow.

De projectbrief, geschreven zoals ik een echte engineer zou briefen:

Bouw een intern dashboard. Next.js 15, TypeScript, Tailwind, shadcn/ui. Supabase-auth (e-mail + magic link). Beschermde route op /agents die data opvraagt van een externe API (POST met API-sleutel uit env), toont agents in een tabel met filters (status, laatste run, agent-type), gebruiker kan handmatig een run starten. Grafieken voor run-geschiedenis (recharts). Geen multi-tenant. Solo-operator dashboard.

Ongeveer een week werk als ik het zelf zou schrijven. Misschien drie dagen als ik het via Claude Code met een schone planning zou doen. De vraag: wat doet Bart-modus hiermee?

Ik meldde me aan voor de gratis tier — het Free-plan van Traycer is $0/maand met één slot-capaciteit en onbeperkt open-source taaktegoed, plus een proefperiode van 7 dagen Pro als je betaald capaciteit wilt. Voor deze test was de gratis tier genoeg om de Epic-setup en de eerste twee uitvoeringsbatches door te komen voordat ik meer parallellisme zou willen. Betaalde plannen kosten $10/maand Lite, $25/maand Pro en $40/maand Pro+ op het moment van schrijven, met 20% korting bij jaarlijks.

Modelselectie doet ertoe. Traycer is agent-agnostisch — het draait geen eigen inference, maar orkestreert welke coding agent je ook geauthenticeerd hebt. Ik draaide de test met Claude Opus 4.7 als het uitvoeringsmodel, dat Anthropic op 16 april 2026 uitbracht met SWE-bench Verified op 87,6% (omhoog van 80,8% bij Opus 4.6) en CursorBench op 70%. Wil je het echte plafond van spec-gedreven autonome codering in april 2026, dan is dit de combinatie.

Fase Eén: Van Brief naar Specificatie

Het eerste wat me verraste, was hoe Traycer omging met de opdrachtomschrijving. Ik plakte mijn briefing in een nieuwe Epic, voegde twee contextbestanden toe (de bestaande client API-specificatie en een ruwe wireframe-screenshot) en verwachtte dat het systeem direct tickets zou genereren. Dat gebeurde niet. In plaats daarvan stelde het me zeven vragen — en elke vraag was er een die ik fout had beantwoord als ik hem had overgeslagen.

De vragen, in de volgorde waarin ze kwamen:

1. Moet de agententabel server-side of client-side gepagineerd worden?
2. Wat is het verwachte aantal rijen — onder de 100, honderden, of duizenden?
3. Wanneer een handmatige run wordt gestart, is het gewenste gedrag fire-and-forget of moet de UI live status tonen?
4. Zijn API-sleutels per gebruiker of globaal voor de werkruimte?
5. Moet de runhistorie-grafiek de laatste N runs tonen, een tijdsvenster, of beide met een toggle?
6. Wat is het gewenste gedrag als de externe API offline is — gecachte laatst-bekende status, lege staat, of een banner?
7. Is "agent type" een vaste enum of komt deze uit de API-respons?

Stuk voor stuk zouden deze vragen twee dagen in de bouwfase tot bugs hebben geleid. Vooral de vraag “Is agent type vaste enum of uit de API” — ik ging ervan uit dat het een enum was. Dat is niet zo. Die aanname alleen al zou een filtercomponent hebben opgeblazen en een refactor hebben afgedwongen.

Dit noemt Traycer Phases mode clarification, en het gebeurt tijdens het opzetten van de Epic. Het is geen revolutionaire techniek. Wat het wel is: een model dat zich gedraagt als een senior engineer die eerder is stukgelopen op aannames en nu precies weet welke veronderstellingen je fataal worden. De meeste AI-codetools slaan deze stap over omdat verduidelijkende vragen voelen als frictie. Traycer maakt er juist de eerste zet van.

Nadat ik de vragen had beantwoord, genereerde Traycer de specificaties. Meervoud. Niet één logische, alomvattende PRD, maar een specificatieboom:

• tech-stack.md — Next.js 15 App Router, TypeScript strict mode, Tailwind v4, shadcn/ui componentenlijst, Supabase client setup
• data-models.md — Agent, Run, RunHistory types met Zod-schema’s
• auth-flow.md — magic link-flow, protected route middleware, sessieafhandeling
• api-integration.md — endpointcontracten, env var-afhandeling, retry/errorstrategie
• ui-layout.md — routestructuur, componentenhiërarchie, responsieve breakpoints
• ticket-backlog.md — 14 tickets met acceptatiecriteria, gemapt op bestanden

Dit is het punt waarop Ralph-loop-workflows de agent doorgaans één planbestand geven en doorrennen. Traycer deed het anders: het liet me de tickets zien en vroeg welk uitvoeringstraject ik wilde. Uitvoeren in Phases (gecontroleerde checkpoints tussen elke fase) of overdragen aan Bart (autonoom van begin tot eind).

Ik koos voor Bart.

Fase Twee: Bart Neemt het Stuur Over

Op het moment dat je een Epic aan Bart overdraagt, verandert de UI. Het ticketbord wordt een orkestratie-overzicht. Je ziet Bart tickets in batches verdelen — gegroepeerd op afhankelijkheid, niet op lijstvolgorde — en ze parallel dispatchen.

Voor mijn project bestond de eerste batch uit vier tickets die gelijktijdig werden uitgevoerd:

• T-01 — Project scaffold + Tailwind + shadcn setup
• T-02 — Supabase client + env var plumbing
• T-03 — Type definities + Zod schemas
• T-04 — API client module met retry logic

Deze vier hebben geen onderlinge afhankelijkheden — ze kunnen allemaal parallel plaatsvinden. Een Ralph-loop zou ze sequentieel hebben uitgevoerd en me ongeveer vier keer zoveel wandkloktijd hebben gekost. Bart draaide ze parallel, met vier afzonderlijke Claude Opus 4.7-sessies op vier geïsoleerde branches. Totale tijd voor de eerste batch: elf minuten.

Toen gebeurde het waardoor ik echt naar mijn scherm toe leunde.

Nadat batch één klaar was, dispatchte Bart niet direct batch twee. Er werd verificatie uitgevoerd. Niet slechts “compileerde de code” — daadwerkelijke spec-verificatie. Bart las de gegenereerde bestanden, vergeleek ze met de spec-boom, en signaleerde twee mismatches:

1. De API client-module gebruikte een retry-aantal van 3 met exponentiële backoff. De api-integration.md-spec stelde 5 retries met vaste 2-seconden-intervallen. Bart ontdekte het.
2. Het Zod-schema voor Agent.status gebruikte een string union. De spec, afgeleid van mijn verduidelijking, gaf aan dat dit uit de API-respons moest komen, niet uit een vaste union. Bart ontdekte het.

En — dit is het belangrijkste — Bart werkte de tickets voor batch twee bij om correcties voor deze mismatches op te nemen, in plaats van batch twee bovenop een gebrekkige basis te dispatchen. Hij voegde twee sub-tickets toe aan de backlog: T-04b (fix retry config) en T-03b (maak agent.status dynamisch), trok ze in batch twee, en ging vervolgens verder.

Dit is waar “orkestrator” in de praktijk op neerkomt. Niet parallelisme om het parallelisme zelf. Parallelisme plus closed-loop verificatie tegen een levende spec, met de mogelijkheid om het plan onderweg aan te passen. De Ralph-loop kan dit niet. Niet omdat de makers het niet bedacht hadden — maar omdat de architectuur het niet toestaat. De Ralph-loop heeft geen spec-vs-implementatie-overzicht. Bart wel.

Het Moment Waarop Bart Stopte en een Vraag Stelde

Batch drie is waar ik zag wat Traycers blog bedoelt met "Bart hallucineert geen nieuwe waarheid".

De batch omvatte T-09 (run history chart) en T-10 (handmatige triggerknop). Beide werden voltooid. Barts verificatie signaleerde een conflict: het chart-ticket ging ervan uit dat de run history uit een lokale databasecache kwam (afgeleid van de caching-strategie in api-integration.md), maar het ticket voor de handmatige trigger ging ervan uit dat deze de cache ongeldig maakte en opnieuw ophaalde van de externe API (afgeleid van mijn verduidelijkende antwoord over live status).

Beide interpretaties waren consistent met verschillende delen van de specificatie. Allebei coherent. Maar ze konden niet naast elkaar bestaan — een van de twee moest wijken.

Een Ralph-loop zou er stilletjes één hebben gekozen. Ik had de inconsistentie pas over twee weken ontdekt, wanneer de run history na een handmatige trigger niet meer werd bijgewerkt.

Bart stopte de Epic en toonde een beslissingskaart in de UI. De kaart bevatte de mismatch, de twee interpretaties en drie voorgestelde oplossingen (cache ongeldig maken bij trigger, niet ongeldig maken maar een optimistische update tonen, of altijd live ophalen voor de chart). Ik koos een optie. Bart werkte de spec bij, genereerde het getroffen ticket opnieuw en ging verder.

Totale menselijke tijd besteed aan die beslissing: misschien 90 seconden. Totale tijd bespaard: waarschijnlijk een volledige debug-sessie twee weken later.

Wil je liever dat een team dit end-to-end op zich neemt in plaats van nóg een tool te leren? Ik neem Claude Code en agent orchestratie-opdrachten aan via Fiverr — juist dit soort spec-gedreven workflows bouwen voor klanten is tegenwoordig mijn belangrijkste levering.

Fase Drie: De Eindstreep en Wat Bart Miste

Drieënnegentig minuten na het overhandigen van de Epic aan Bart was het dashboard functioneel gereed. Authenticatie werkte. Agent-tabel werd gerenderd. Filters functioneerden. Grafiek werd weergegeven. Handmatige trigger werkte. Lokale npm run dev startte zonder problemen.

Dat klinkt als een overwinningsronde. Dat is het niet helemaal.

Dit moest ik nog met de hand oplossen nadat Bart “Epic compleet” rapporteerde:

Eén stylingregressie. De shadcn/ui Select-component in de filterbalk gebruikte standaardstyling die niet aansloot bij de rest van het dashboard. De specificatie gaf geen styling aan — Bart nam defaults aan — maar de aanname was onjuist. 4 minuten om te fixen.

Eén UX-afweging. De leegstaat van de agents-tabel — wanneer de externe API nul agents teruggaf — toonde een generieke “No results”-melding. Een mens zou iets specifieks hebben geschreven (“Geen agents gevonden. Voeg je eerste agent toe via het instellingenpaneel.”). Bart schreef exact wat de specificatie impliceerde, niets meer. 3 minuten om aan te passen.

Eén security-detail. De API-key werd correct uit environment variables gehaald in server-side code, maar de clientcomponent die handmatige runs triggerde deed een fetch-call naar /api/agents/run zonder CSRF-bescherming. De specificatie vereiste geen CSRF. Bart voegde het niet toe. Voor een solo-intern dashboard is dit prima. Voor iets dat naar een team gaat, niet. 8 minuten om middleware toe te voegen.

Geen tests. Bart schrijft geen tests tenzij de specificatie dit vermeldt. Dat deed de mijne niet. Ik voegde de kritieke tests zelf toe (auth redirect, API-foutafhandeling). 22 minuten.

Totale poetstijd: ongeveer 40 minuten. Niet nul. Niet triviaal. Maar het traject ging van briefing naar “klaar om aan de klant te tonen” in iets meer dan tweeënhalf uur totaal, waarvan ik het grootste deel met ander werk bezig was.

Ter vergelijking: mijn handmatige Claude Code plan-driven workflow op een vergelijkbaar project vorige maand kostte me ongeveer vier gefocuste uren live coderen, plus nog eens twee uur de volgende ochtend voor opruimen. Bart modus perste dat in één sessie waarin ik vooral toekeek.

Bart-modus vs Claude Code: wanneer gebruik je welke?

Ik denk niet dat Bart-modus een vervanging is voor Claude Code. Ik gebruik nu beide, en de vraag die ik mezelf ben gaan stellen vóór elk project is: heeft dit project genoeg omvang zodat spec-driven development loont?

Hier is de beslisboom die ik gebruik na drie weken werken met Traycer:

Gebruik Bart-modus wanneer:

• Het project 5+ aparte componenten of tickets heeft
• Meerdere onderdelen in parallel kunnen werken zonder gedeelde staat
• De specificatie zuiver te schrijven is (nieuwe features, greenfield-apps, scherp afgebakende migraties)
• Je het project wilt achterlaten en later terugkomen bij een werkend geheel
• Je een betaalde Traycer-licentie hebt met de mogelijkheid om te paralleliseren

Gebruik Claude Code handmatig wanneer:

• De taak uit één bestand of één focuspunt bestaat
• Je in een verkennende of onderzoeksfase zit en het einddoel nog niet kent
• De bestaande codebase genoeg impliciete conventies bevat die specs missen
• Je bij elke stap zelf beslissingen wilt nemen (pair-programming-modus)
• De taak van je verlangt om direct te reageren op fouten die niet door specs kunnen worden vastgelegd

Gebruik beide binnen één workflow wanneer:

• Bart verzorgt het scaffolding + de structurele tickets
• Jij neemt het over in Claude Code voor de UX-polish, tests en alles wat specs niet kunnen beschrijven
• Dit is eigenlijk de combinatie waarmee ik momenteel ship

Wat interessant is aan deze verdeling, is dat Bart-modus Claude Code niet overbodig maakt — het maakt juist duidelijker waar Claude Code eigenlijk voor bedoeld is. Claude Code is een chirurgisch instrument. Bart-modus is scaffolding voor grotere structuren. Ik gebruikte het chirurgische instrument om steigers te bouwen, en daardoor voelden zes uur durende plan-gedreven sessies als een sleur, zelfs als ze opleverden wat ik nodig had.

Waar Niemand Anders Over Schrijft bij Spec-Driven Development

Na drie weken zijn dit de dingen over spec-driven AI development die ik nergens zie terugkomen op productpagina’s of in YouTube-demo’s.

Specs zijn moeilijker om te schrijven dan code. Ik weet het, dat is het tegenovergestelde van de pitch. Maar een goede spec schrijven — eentje die ondubbelzinnig, compleet en zelf-consistent is — vereist een mate van producthelderheid die de meeste solodevelopers niet op dag één van een project meebrengen. De verduidelijkende vragen van Traycer helpen. Ze vervangen de vaardigheid niet. Als je in 2026 niet kunt beantwoorden "moet dit pagineren aan de server- of clientzijde," gaat Traycer je geen productdenken leren. Het zal gewoon vaker stoppen en doorvragen.

De parallelismelimiet ligt lager dan marketing doet vermoeden. Dependency graphs tussen tickets vlakken snel af. In mijn dashboardproject had batch één vier parallelle tickets. Batch twee had er twee. Batch drie had er één. Halverwege een Epic zijn de meeste resterende tickets afhankelijk van voorgaand werk en verlopen ze sequentieel. Het "parallelle agents"-verhaal is actueel aan het begin en vervaagt gaandeweg.

Spec drift is de nieuwe code drift. Wanneer Bart halverwege de spec bijwerkt om een mismatch op te lossen, plant die wijziging zich door de resterende tickets heen. Dat is goed — tot je beseft dat je levende spec aanzienlijk is geëvolueerd ten opzichte van wat je oorspronkelijk goedkeurde. In mijn project onderging api-integration.md drie revisies tijdens de uitvoering. De uiteindelijke spec was beter dan de originele, maar niet meer de spec waar ik akkoord op gaf. Je móet dus de eindsituatie van de spec reviewen, niet alleen de originele. Traycer maakt dit eenvoudig. Het blijft werk.

Bart profiteert nog altijd van menselijke "rubber duck"-momenten. Twee keer tijdens de Epic pauzeerde ik Bart niet omdat het misging, maar omdat het bekijken van de ticketflow leidde tot een inzicht over het product dat ik in de spec wilde vastleggen. Barts vermogen om halverwege een Epic te stoppen-en-aanpassen is precies wat deze pauzes laagdrempelig maakt. In een Ralph-loop betekent pauzeren herstarten. In Bart-mode is pauzeren een first-class feature.

Het model is net zo belangrijk als de orkestrator. Ik heb dezelfde Epic twee keer uitgevoerd — één keer met Claude Opus 4.7 als execution agent, één keer met GPT-5.4. Dezelfde spec, dezelfde Bart-logica, verschillende resultaten. Opus 4.7 leverde nettere componentstructuren op en signaleerde meer impliciete conventies uit de spec. GPT-5.4 was sneller en iets letterljiker. De orkestrator is maar zo goed als de agent die hij aanstuurt. Kies eerst het model, laat Bart daarna z’n werk doen.

Waar Dit Past in het Spec-Driven Landschap

Traycer staat niet alleen in deze ruimte. In 2026 is spec-driven development uitgegroeid tot een echte categorie. De tools die ik dit jaar heb geprobeerd:

• Kiro — AWS-gerichte IDE met een spec-first workflow. Sterk bij greenfield-projecten met duidelijke specificaties. Zware AWS-integratie. Geweldig als je volledig in dat ecosysteem zit.
• GitHub Spec Kit — CLI dat spec-driven slash-commando’s toevoegt aan Claude Code, Gemini CLI, Cursor, Windsurf. Cross-agent portabel, geen vendor lock-in, maar je moet de workflow zelf samenstellen.
• BMAD-METHOD — open-source methodologie + CLI. Rigoureus. Academisch gevoel. Heeft een leercurve.
• Traycer — degene waar ik voor de meeste projecten nu op uitkom. Sterkste orkestratielaag van alles wat ik heb getest. Agent-agnostisch. Duidelijke scheiding tussen spec-auteur en uitvoering.

Traycer’s kracht zit niet in het spec-formaat — het is wat er na de spec gebeurt. De combinatie van Epic mode + Bart orchestrator levert de strakste end-to-end cyclus op die ik heb gebruikt. Kiro’s spec-authoring is misschien schoner. Spec Kit’s portabiliteit is mogelijk beter. Geen van beiden heeft Bart’s live reconciliatie tussen spec en implementatie.

Wil je de bredere theorie achter dit patroon, dan behandelt mijn eerdere post over Karpathy's claude.md skills install aanpak hoe spec-achtige contextbestanden de kwaliteit van elke agent-output beïnvloeden, niet alleen die van Traycer. En de vergelijking die ik maakte tussen Claude Code’s Ultra Plan en de local plan mode geeft nuttige context over hoe plan-driven workflows zich tot spec-driven workflows verhouden binnen het Anthropic-ecosysteem specifiek.

Hoe ik deze maand Bart Mode gebruik

Concreet workflow, als je het wilt overnemen:

Maandagochtend. Schrijf een Epic in Traycer voor de belangrijkste feature van de week. Beantwoord de verduidelijkingsvragen. Bekijk de gegenereerde spec-boom. Pas specs aan waar Traycer verkeerde aannames doet over mijn voorkeuren. Draag over aan Bart.

Maandagmiddag. Werk aan andere zaken. Bart draait batches. Ik krijg UI-notificaties wanneer Bart een beslissing escaleert. Ik besteed in totaal misschien 15 minuten aan het beantwoorden van decision cards gedurende de middag.

Dinsdagochtend. Bart meldt dat de Epic voltooid is. Ik haal de branch op, start lokaal op, review op basis van de specs, los de handmatig gepolijste issues op, schrijf tests, commit.

Rest van de week. Gebruik Claude Code voor precisiewerk — de puntjes op de i, de tests, het UX-schrijven, de eenmalige bugs. Zaken die Bart niet helder genoeg kan specificeren om uit te voeren.

Dit is niet "autonome AI-codering vervangt engineering." Het is "autonome AI-codering bouwt de steigers, ik lever het vakmanschap." Die verdeling voelt duurzaam, op een manier die de pure Ralph-loop voor mij nooit deed. De Ralph-loop was altijd alles-of-niets. Bart mode maakt autonomie gedeeltelijk, gestructureerd, en — cruciaal — omkeerbaar. Elke batch kan worden beoordeeld voordat de volgende wordt uitgevoerd. Elke spec-wijziging wordt gelogd. Elk ticket is reproduceerbaar.

Veelgestelde vragen

Wat is Traycer Bart-modus?

Traycer Bart-modus is een autonome outer-loop orkestrator die volledige project-Epics van begin tot eind uitvoert door ze op te splitsen in tickets, tickets parallel te verwerken met AI-coderingsagenten, tussentijds te verifiëren aan de hand van specificaties, en het plan bij te stellen als tijdens de implementatie afwijkingen aan het licht komen. Het draait binnen Traycer’s Epic-modus en is agent-agnostisch — je kiest zelf het uitvoeringsmodel (Opus 4.7, GPT-5.4, enz.).

Hoe verschilt Bart-modus van de Ralph-loop?

De Ralph-loop probeert een taak blind opnieuw totdat de verificatie slaagt, zonder enig besef van de oorzaak van fouten. Bart-modus heeft wél bewustzijn: deze houdt een dynamische specificatie bij, vergelijkt na iedere batch de implementatie met de specs, past tickets aan als de realiteit afwijkt, en schakelt mensen in als het niet kan oplossen wat afwijkt. Ralph is een while not done-loop. Bart is een orkestrator met geheugen.

Welke AI-modellen ondersteunt Traycer?

Traycer is agent-agnostisch — het draait zelf geen inferentie, maar orkestreert de coderingsagent die je autoriseert. Dat omvat momenteel Claude Code (met Opus 4.7- en Sonnet-varianten), GPT-5.4, Cursor en Windsurf-integraties. Je kiest per Epic welk model je gebruikt, op basis van je gewenste snelheid, kosten en kwaliteitsafweging.

Is Traycer gratis te gebruiken?

Ja. Traycer biedt een gratis tier aan van $0/maand met één slot en een Pro-proefperiode van 7 dagen. Betaalde abonnementen kosten $10/maand (Lite), $25/maand (Pro), en $40/maand (Pro+) op het moment van schrijven, met jaarabonnementen 20% goedkoper. De gratis tier is geschikt om Bart-modus uit te proberen op een kleine Epic.

Wanneer moet ik Bart-modus niet gebruiken?

Sla Bart-modus over bij het bewerken van losse bestanden, verkennend onderzoek waarbij het einddoel nog onbekend is, of bij codebases met veel impliciete conventies die een spec niet dekt. Claude Code handmatig inzetten is beter voor chirurgisch werk en real-time pair programming. Bart-modus komt het beste tot zijn recht bij projecten met 5+ tickets met duidelijke afhankelijkheden die als spec zijn uit te werken.

Laten We Samenwerken

Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag.

• Fiverr (maatwerk & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (oplossingen voor bedrijven): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io