De eerste keer dat Symphony een van mijn Linear-tickets oppakte en een werkend pull-verzoek stuurde zonder dat ik een toetsenbord aanraakte, zat ik daar een hele minuut te proberen erachter te komen wat ik nu moest doen.
Op mijn ticket stond: "Voeg snelheidsbeperkende middleware toe aan de openbare API-eindpunten, standaard 60 req/min, sta overschrijvingen per route toe." Ik had het uit gewoonte naar 'In uitvoering' verplaatst, de Symphony-devbox opgestart en van tabblad gewisseld om een Slack-bericht te beantwoorden. Elf minuten later lag er een concept PR. De agent had een geïsoleerde werkruimte opgezet, mijn codebase gelezen, de middleware geschreven, overschrijvingen op routeniveau toegevoegd, drie tests geschreven en een branch gepusht. Het verschil was niet perfect – ik heb één test afgewezen en een opmerking aangescherpt – maar het werk was echt. Het werk was klaar.
Dat ticket was het moment waarop de OpenAI Symphony agent-orkestrator niet langer een demo voor mij was, maar een hulpmiddel begon te worden. Het dwong me ook om iets ongemakkelijks onder ogen te zien: de manier waarop ik Codex en Claude Code het afgelopen jaar had gebruikt – één terminal, één prompt tegelijk, één mens die op één agent paste – stond op het punt er net zo achterhaald uit te zien als SSH-ing op een enkele server om een webapp te implementeren in 2014.
Dit is de post waarvan ik wenste dat iemand mij deze had gegeven voordat ik twee weekenden bezig was met het herbedraden van mijn manier van denken over de infrastructuur van agenten. Ik zal je laten zien wat Symphony eigenlijk is (het is kleiner en vreemder dan de persberichten suggereren), hoe het past in het bredere patroon dat mensen 'harness engineering' noemen, wat ik brak toen ik probeerde het naar mijn eigen stapel te buigen, en de enige mentale verschuiving die ervoor zorgde dat alles klikte.
Even een waarschuwing voordat we verder gaan: er wordt een aantal doorgegeven: de bewering van OpenAI dat sommige interne teams een 500% toename in binnengekomen pull-aanvragen zagen binnen drie weken na de adoptie van Symphony (OpenAI). Op dat getal kom ik later in dit bericht nog terug, want de manier waarop je het leest bepaalt of je het goede of het verkeerde bouwt.
Wat OpenAI Symphony eigenlijk is (en wat het niet is)
Laat ik eerst een misvatting uit de wereld helpen: Symphony is geen product. Het is geen SaaS. Het is geen gesloten binair getal. Er is geen dashboard waarop u inlogt.
Symphony is een SPEC.md-bestand. Dat is het hele kernartefact. OpenAI heeft het op 5 maart 2026 open source gemaakt onder Apache 2.0, en vanaf eind april 2026 had de openai/symphony GitHub repo 15.000 sterren overschreden (Help Net Security). De specificatie beschrijft – in gewoon Engels, met statusdiagrammen – hoe een al lang bestaande orkestrator een issue-tracker moet veranderen in een controlevlak voor autonome coding agents.
De referentie-implementatie wordt verzonden in Elixir. Ja, Elixer. Dezelfde taal die Discord en WhatsApp gebruiken onder de motorkap. OpenAI heeft ervoor gekozen omdat BEAM (Elixir's runtime) u gratis supervisorstructuren, lichtgewicht processen en crashherstel-semantiek biedt - precies wat u zoekt als u tien of twintig coding agents gebruikt die elk twintig minuten per taak duren en waarvan er één stilletjes kan sterven.
Maar hier is het deel dat mij verraste. Het OpenAI-team liet Codex de Elixir-implementatie in één keer vanuit de specificatie genereren en vroeg Codex vervolgens om dezelfde specificatie opnieuw te implementeren in TypeScript, Go, Rust, Java en Python - waarbij elke implementatie werd gebruikt als een forceerfunctie om dubbelzinnigheden in de specificatie zelf te vinden (InfoWorld). De specificatie is het product. De Elixir-code is slechts het meest gepolijste voorbeeld.
Dat is belangrijk omdat het u vertelt wat voor soort tool u werkelijk evalueert. Symphony is niet "het Orchestrator-framework van OpenAI." Het is een gedeelde woordenschat voor hoe een goede orkestratie van coding agents eruit ziet, met een werkreferentie die je kunt gebruiken zoals hij is, of waarvan je kunt stelen.
De kernlus, in één alinea
Symphony ondervraagt Linear elke 30 seconden. Wanneer het ziet dat een ticket naar de geconfigureerde status "klaar" gaat, claimt het dat ticket, start een geïsoleerde werkruimte op (een nieuwe git-werkboom op een devbox), start een Codex-agent in die werkruimte op met een gestructureerde prompt die de hoofdtekst van het ticket bevat, laat de agent continu draaien totdat hij een PR produceert of mislukt, en markeert vervolgens het ticket "klaar voor beoordeling" of "geblokkeerd" met een reden. De standaardgelijktijdigheid is 10 agenten. De status bevindt zich in het geheugen van een GenServer; bij het opnieuw opstarten wordt het gewoon opnieuw opgebouwd vanaf Linear, dus er is geen database om te bedienen (allthings.how).
Dat is het. Dat is het hele ding. Lees die paragraaf nog eens, want het gaat om de eenvoud.
Waarom de hype me overrompelde
Ik zal eerlijk zijn. Toen de OpenAI-blogpost begin maart verscheen, heb ik hem half doorgenomen en verder gegaan. ‘Nog een agent-orkestrator’ was de cynische gedachte. Ik had al met Steve Yegge's Gas Town gespeeld, ik had Archon drie weken lang in een zijproject uitgevoerd en ik had mijn eigen langlopende Claude Code-harnas voor een klant gebouwd. Geen van deze tools had een vierde concurrent nodig.
Wat ik heb gemist – wat de meeste berichtgeving heeft gemist – is dat Symphony niet echt concurreert met die tools. Het concurreert met de versie van jou die een terminal opent, codex of claude typt en ziet hoe één agent aan één taak werkt. Het concurreert zelf met handmatig toezicht. Toen ik dat eenmaal begreep, veranderde mijn hele week.
Om uit te leggen waarom, moet ik een omweg maken naar de term die dit jaar stilletjes het belangrijkste concept is geworden in de door AI ondersteunde softwarelevering: harness engineering.
Harness Engineering: de woordenschat die ervoor zorgde dat alles klikte
In april 2026 publiceerde Birgitta Böckeler – de wereldwijde leider van Thoughtworks voor AI-Assisted Software Delivery – een lang, zorgvuldig stuk op martinfowler.com met de titel "Harness engineering for coding agent users". Het is het artikel dat ons de canonieke taxonomie gaf. (De video-samenvatting waaruit ik werkte, gaf haar naam fonetisch weer als "Vetta Berkeler" - dezelfde persoon, hetzelfde raamwerk.)
De framing is bedrieglijk eenvoudig:
Agent = Model + Harnas
Het model is de LLM. Al het andere – de aanwijzingen, de tools, de sandbox, de lus, de validators, de orkestrator – is het harnas. En zodra u de onderdelen van het harnas een naam begint te geven, kunt u ze opzettelijk gaan ontwerpen in plaats van per ongeluk.
Böckeler verdeelt het harnas in twee lagen, en Symphony woont precies in een ervan.
Binnenharnas — Wat zit er in de agent
Het innerlijke harnas is de code en mogelijkheden die in de agent zelf worden verzonden. Wanneer u Claude Code uitvoert, krijgt u het innerlijke harnas gratis: het tool-calling-protocol, de tools voor het lezen van bestanden en het uitvoeren van shells, de planningsprompts, het spawnen van de subagent, de permissiepoorten, het hooks-systeem, de vaardigheden die u kunt installeren. Hetzelfde met Codex. Hetzelfde met Cursor.
Normaal gesproken schrijf je niet over het binnenste harnas. Jij configureert het. Je schakelt hooks in. Je installeert vaardigheden. U schrijft een CLAUDE.md of AGENTS.md. U stelt machtigingen in settings.json in. Het binnenste harnas maakt een model überhaupt tot een codeermiddel.
Buitenharnas — Wat de agent omringt
Het buitenste harnas is alles buiten de agent die de levenscyclus ervan controleert, de context ervan beheert, beslist wanneer hij draait, waarop hij draait, wat telt als ‘klaar’ en wat er gebeurt als hij faalt. Dit is waar Symphony woont. Dit is waar Gas Town, Archon en Ralph loops ook wonen.
Het buitenste harnas is wat een terminalsessie van Claude Code verandert in een vloot van twintig parallelle agenten die u daadwerkelijk vertrouwt.
Dit is het mentale beeld dat ik op een whiteboard teken als ik dit aan klanten uitleg:
┌──────────────────────────────────────────┐
│ OUTER HARNESS │
│ Symphony / Gas Town / Archon / Ralph │
│ - lifecycle, queues, isolation, retries │
│ ┌──────────────────────────────────┐ │
│ │ INNER HARNESS │ │
│ │ Claude Code / Codex / Cursor │ │
│ │ - tools, hooks, skills, perms │ │
│ │ ┌────────────────────────┐ │ │
│ │ │ MODEL │ │ │
│ │ │ GPT-5.x / Sonnet / │ │ │
│ │ │ Opus / etc. │ │ │
│ │ └────────────────────────┘ │ │
│ └──────────────────────────────────┘ │
└──────────────────────────────────────────┘
Zodra u de lagen ziet, wordt elk "AI-agentproduct" op een positie op deze foto geplaatst. En zodra dat gebeurt, is de echte vraag niet langer "welke agent moet ik gebruiken?" en wordt "wat moet mijn buitenste harnas doen dat niemand anders kan?"
Dat is de vraag die Symphony je dwingt te beantwoorden.
Guides en Sensors — De twee hendels in elk harnas
Binnen beide lagen introduceert Böckeler nog een onderscheid waar ik nu aan denk elke keer dat ik een agentprompt schrijf of een CI-stap instel. Elk betekenisvol onderdeel van een harnas vervult een van twee taken.
Guides stuur de agent voor dat hij handelt. Het zijn feedforward-controles. Uw CLAUDE.md. De vaardigheden die u installeert. Het speelboek dat u in de prompt plakt. Het voorbeeld verplicht u tot referentie. De architectuurbeslissing registreert de agent die leest voordat code wordt geschreven. Guides vergroot de kans dat de agent het bij de eerste poging goed doet.
Sensors observeer de agent nadat deze handelt en besluit of wat hij produceert acceptabel is. Het zijn feedbackcontroles. Sensors is verkrijgbaar in twee smaken:
- Computationele sensoren — deterministisch, snel, goedkoop. Linters. Typ dammen. Eenheidstests. Schemavalidators. Bouw uitgangen. Ze lopen in milliseconden tot seconden en geven u een binair antwoord (Martin Fowler).
- Inferentiële sensoren — niet-deterministisch, langzaam, duur. LLM-als-judge codebeoordelingen. Semantische gelijkeniscontroles. Stijlkritieken. Ze draaien op een GPU, duren seconden tot minuten en geven u probabilistische antwoorden.
Dit is het deel dat me beschamend lang kostte om het te internaliseren: de meeste teams waarmee ik heb gewerkt, gebruiken te weinig computationele sensoren en vertrouwen te veel op inferentiële sensoren. Ze zullen een "AI reviewer" opzetten voordat ze eslint --max-warnings 0 hebben geconfigureerd in een pre-commit hook. Ze krijgen een LLM-als-judge-testdekking voordat ze een dekkingsdrempel aan CI hebben toegevoegd.
Computationele sensoren zijn in principe gratis. Ze zijn bewezen. Ze draaien al vijftien jaar in CI-pijplijnen. De reden dat ze worden overgeslagen in de workflows van agenten is dat praktijkmensen vergeten dat de agent hun output kan lezen en zichzelf kan corrigeren. Op het moment dat je npm test aansluit op de lus van de agent en fouten terugstuurt als context, daalt je foutenpercentage met een factor die ik echt niet kan inschatten zonder te liegen. Het is veel.
Ik kom hier op terug als ik je laat zien hoe een echt Symphony-workflowbestand eruit ziet, omdat gidsen-en-sensoren de volledige woordenschat is die je gebruikt om er een te schrijven. Voor nu geldt het volgende: een harnas is een zorgvuldig gekozen set geleiders en sensoren die rond een model zijn gerangschikt. De orkestrator is precies datgene dat het harnas in een wachtrij laat draaien.
Waar Symphony past in de buitenste harnasfamilie
Symphony is niet het enige buitenste harnas in het wild, en het is niet altijd het juiste antwoord. Laat me de vier doornemen die ik dit jaar in productiewerk heb gebruikt, omdat de afwegingen ertoe doen.
1. Symphony — Issue-Tracker-native orkestratie
De bepalende keuze van Symphony is dat de issuetracker de wachtrij is. Linear-tickets zijn de werkeenheden. Er is geen aparte Symphony-gebruikersinterface om te beheren. U verplaatst een ticket naar "Klaar voor Codex", Symphony pakt het op, een agent loopt weg, er verschijnt een PR gekoppeld aan het ticket en u bekijkt het ticket zoals u altijd deed. De cognitieve overhead die gepaard gaat met het adopteren ervan is grofweg nul, omdat je geen nieuwe projectmanagementtool leert.
Het nadeel is dat de oppervlakte van Symphony klein is. Het doet één ding: tickets omzetten in runs – en het doet het goed. Als uw werk niet in afzonderlijke tickets past (langlopend onderzoek, refactoren van meerdere weken, verkennende pieken), is Symphony niet uw hulpmiddel.
2. Gas Town — Kolonies met meerdere agenten, Steve Yegge-stijl
Gas Town is het raamwerk van Steve Yegge voor het uitvoeren van 20-30 parallelle Claude Code-agents, georganiseerd in rollen (burgemeesters orkestreren, bunzings voeren uit), waarbij de status in Git wordt bewaard via de MEOW-stack (Cloud Native Now). Waar Symphony uitgaat van ‘één ticket, één agent, één PR’, gaat Gas Town uit van gecoördineerde zwermen die aan gerelateerd werk werken met expliciete overdrachten.
Ik heb het patroon in "zwermstijl" gedetailleerder behandeld in mijn Claude Code agent swarm architecture write-up - als je iets bouwt waarbij meerdere agenten moeten coördineren voor dezelfde dezelfde taak in plaats van voor parallelle taken, dan is dat het bericht dat je hierna moet lezen.
3. Archon — Deterministische workflows rond elke coding agent
Archon profileert zichzelf als "de eerste open-source harnasbouwer" - de formulering is exact. Waar Symphony de werkstroom hardcodeert (peiling Linear → agent uitvoeren → PR), kunt u met Archon de werkstroom schrijven als een YAML-pijplijn met expliciete fasen, validatiepoorten en artefacten. Elke run krijgt zijn eigen git-werkboom. U kunt vijf fixes parallel uitvoeren zonder conflicten (MindStudio).
Ik schakel Archon in als het werk fasen kent – ‘onderzoeken, plannen, implementeren, testen, documenteren’ – en ik wil dat elke fase een afzonderlijke, gevalideerde stap is in plaats van één lange run door agenten. Dit komt ook het dichtst in de buurt van de spec-driven-benaderingen zoals degene waarover ik schreef in mijn [Traycer BART-modus spec-driven AI stuk] (/traycer-bart-mode-spec-driven-ai/).
4. Ralph-lussen — De minimaal haalbare buitenste harnas
De Ralph Wiggum-lus (ja, genoemd naar het Simpsons-personage - "Ik help!") is het eenvoudigst mogelijke buitenste harnas: een while true-lus die de agent opnieuw aanroept totdat een deterministische controle slaagt. Er is een officiële Anthropic-plug-in in de Claude Code-repository en Vercel Labs levert ralph-loop-agent voor de AI SDK.
De Ralph-filosofie: streef niet naar perfectie bij de eerste poging. Laat de lus verfijnen. De agent leest een planbestand, boekt voortgang, de lus controleert de voltooiing aan de hand van criteria en als dit niet gebeurt, wordt de agent opnieuw uitgevoerd met de nieuwste status (beuke.org).
Ralph is niet concurrerend met Symphony — het is complementair. Een Symphony-ticket kan een Ralph-lus uitvoeren binnen zijn werkruimte. Symphony verzorgt de wachtrij en isolatie. Ralph verwerkt de iteratie totdat deze correct is. Verbind ze met elkaar en je hebt iets echt krachtigs.
Symphony instellen op een echte opslagplaats
Genoeg theorie. Ik zal je precies laten zien wat ik vorige week heb gedaan om Symphony in een zijproject te laten draaien. Het kostte me ongeveer 90 minuten van git clone tot eerste PR, en het grootste deel daarvan was de Linear-configuratie, niet Symphony zelf.
Stap 1: Verkrijg de Linear API-sleutel
Ga in Linear naar Instellingen → Beveiliging en toegang → Persoonlijke API-sleutels en maak een nieuwe sleutel. Stel het in uw omgeving in als LINEAR_API_KEY. Symphony gebruikt dit token via zijn dynamische tool linear_graphql - het stelt het onbewerkte token niet bloot aan subagenten, wat een kleine maar doordachte beveiligingskeuze is (allthings.how).
Stap 2: Kloon de opslagplaats en kies een implementatie
git clone https://github.com/openai/symphony.git
cd symphony
De repo heeft de specificatie op SPEC.md en de Elixir-referentie onder elixir/. Als je Elixir hebt geïnstalleerd (brew install elixir op macOS), kun je binnen twee minuten aan de slag. Als je dat niet doet, betekent de eenvoud van de specificatie dat je de orkestrator herschrijft in een taal waarvan je weet dat deze echt handelbaar is - dat is het hele punt van het distribueren van een specificatie in plaats van een binair bestand.
Voor de rest van deze walkthrough zal ik het Elixir-pad laten zien, omdat ik dit heb gebruikt.
cd elixir
mix deps.get
mix compile
Stap 3: Configureer uw workflow
Kopieer de WORKFLOW.md-sjabloon naar de doelopslagplaats (de opslagplaats waaraan u wilt dat agenten werken, niet de Symphony-opslagplaats zelf). Dit is waar de woordenschat van het harnas zijn vruchten afwerpt, omdat WORKFLOW.md in wezen uw gids-en-sensorspecificatie is voor elke agentrun. Een ingekorte versie van de mijne zag er zo uit:
## Voordat je begint
- Lees README.md en ARCHITECTURE.md
- Voer `npm install` en `npm test` uit om de basislijnpassages te bevestigen
## Implementatie
- Breng de kleinste wijziging aan die voldoet aan het ticket
- Tests toevoegen of bijwerken voor nieuw gedrag
- Voer `npm test` en `npm run lint` uit voordat u het als voltooid beschouwt
- Voer `npm run typecheck` uit: geen fouten vereist
## Definitie van gedaan
- Alle tests slagen lokaal
- Lint- en typecheck-pas zonder waarschuwingen
- PR-titel komt overeen met de tickettitel
- PR-beschrijving verwijst naar de Linear-ticket-ID
That document is doing serious work. The "Before you start" section is a guide. The four sensor commands (npm test, npm run lint, npm run typecheck, plus the ticket-link convention) are computational sensors. There's not a single LLM-as-judge in there yet, and the system already works. Don't reach for inferential sensors until your computational ones are saturated.
Step 4: Point Symphony At Linear
In your .env:
LINEAR_API_KEY=lin_api_uw_sleutel_hier
SYMPHONY_TARGET_REPO=/Users/you/code/your-project
SYMPHONY_LINEAR_TEAM_ID=uw_team_id
SYMPHONY_TRIGGER_LABEL=klaar-voor-codex
SYMPHONY_MAX_CONCURRENT=4
I cap concurrency at 4 on my laptop because Codex sessions are not free and I'd rather watch four serious runs than ten degraded ones. On a devbox you'd raise this.
Step 5: Run It
mix run --geen stop
Dat is de volledige opstelling. Symphony peilt nu elke 30 seconden Linear. Tag elk ticket met ready-for-codex en een agent zal het claimen.
De eerste keer dat ik dit deed, maakte ik met opzet een klein ticket — "Voeg een /health-eindpunt toe dat { status: 'ok', uptime_seconds: <number> } retourneert" — en keek. De agent pikte het op in 31 seconden. Het las de codebase. Het heeft mijn Express-app gevonden. Het schreef de route, schreef een test, voerde de test uit (die bij de tweede poging slaagde na het oplossen van een klein probleem met TypeScript-inferentie), opende een PR en tagde het Linear-ticket als 'review nodig'. Totale wandtijd: 4 minuten 18 seconden. Ik heb het verschil gelezen. Ik fuseerde.
Ik zat daar en staarde naar het scherm.
Wat ik onderweg verkeerd heb gedaan
Ik wil echte tijd aan dit gedeelte besteden omdat ik daar het meeste heb geleerd, en omdat elk "eerste blik"-artikel dat ik op Symphony heb gelezen eroverheen gaat. Ik heb vier fouten gemaakt die de moeite waard zijn om je over te vertellen.
Fout 1: ik behandelde Symphony net als Claude Code
De eerste twee dagen bleef ik de Symphony devbox-terminal openen in de verwachting dat ik met de actieve agenten zou praten. Symphony werkt niet op die manier. De agenten hebben geen hoofd. Je communiceert met hen via tickets. Als u een agent meer context wilt geven, bewerkt u de Linear-ticketbeschrijving (of voegt u een opmerking toe) en laat u de volgende pollingcyclus de wijziging overnemen. Als u een agent halverwege de vlucht wilt omleiden, is het antwoord in 90% van de gevallen niet doen: beëindig de run, bewerk het ticket en laat het opnieuw beginnen.
Dit was een mentale verschuiving. Het kostte me een paar dagen om te stoppen met het behandelen van agenten als medewerkers met wie ik aan het programmeren was, en ze te behandelen als werknemers aan wie ik kaartjes uitgaf. Die verschuiving is trouwens precies wat het ontwerp van Symphony je probeert op te dringen. Ontwikkel uw tickets als productspecificaties, niet als Slack-berichten.
Fout 2: Ik heb vage kaartjes geschreven
Mijn vroege tickets waren dezelfde soort oneliners die ik een senior teamgenoot zou geven: "Refactor the auth middleware." Een senior teamgenoot vult de gaten op met gedeelde context. Een agent doet dat niet. Toen ik "Refactor the auth middleware to extraheer de JWT-validatie in een aparte functie, behoud de bestaande openbare API van requireAuth(req, res, next), voeg tests toe voor de uitgepakte functie en verander de routeregistraties niet", stuurde de agent bij de eerste run een schone PR.
Het principe: elke dubbelzinnigheid in uw ticket wordt een muntje in het gedrag van uw agent. Tickets zijn gidsen. Hoe meer u de gids naar voren laadt, hoe minder u de sensoren nodig heeft om slechte uitvoer te onderdrukken.
Fout 3: ik heb computationele Sensors overgeslagen
Mijn doelrepository bevatte npm test en npm run lint, maar ik had ze niet toegevoegd aan de WORKFLOW.md-definitie van klaar. De agent voerde technisch tests uit wanneer hij daar zin in had. Ongeveer één op de drie PR's had bij aankomst mislukte tests, die ik moest terugveren. De oplossing was dertig seconden bewerken van WORKFLOW.md om sensoropdrachten niet-onderhandelbaar te maken. Het percentage mislukkingen daalde tot ongeveer één op de vijftien, in lijn met wat ik zie als ik Codex handmatig uitvoer.
U zult niet geloven hoe vaak het antwoord luidt: "Voeg een deterministische controle toe aan uw workflowbestand."
Fout 4: Ik heb geprobeerd Symphony uit te voeren zonder Worktree-isolatie
Uit luiheid wees ik twee parallelle runs aan bij dezelfde kassa van dezelfde repository. Voorspelbaar bloedbad. Het ontwerp van Symphony gaat uit van – en de Elixir-referentie dwingt dit af – git-werkboomisolatie per ticket. Vecht er niet tegen. Elke agent krijgt zijn eigen werkkopie. Zo hoeven vijf agenten die verschillende delen van uw codebase aanraken, niet op elkaars WIP te stampen.
Dit is ook waar het ontwerp van Symphony veel op Archons "elke workflow-run krijgt zijn eigen git worktree"-benadering begint te lijken. De convergentie is geen toeval. Worktree-per-run wordt de dragende conventie van alle serieuze buitenharnassen.
Als je dit soort instellingen liever overdraagt aan iemand die het al eerder heeft gedaan, bouwt en exploiteert Ramlit Limited precies deze orkestratiepijplijnen voor technische teams die de doorvoer willen zonder de leercurve van acht weekenden. Maar het pad kun je echt zelf bewandelen – dat is het grootste deel van wat ik je hier probeer te laten zien.
Hoe moet je het 500% getal lezen?
Ik zei al eerder dat ik hierop terug zou komen. De belangrijkste statistiek van OpenAI is dat sommige interne teams het aantal binnengekomen pull-aanvragen met 500% zagen stijgen in de eerste drie weken dat ze Symphony (OpenAI) gebruikten.
Hier is de eerlijke lezing.
Dat aantal is reëel, in enge zin. De PR-doorvoer ging omhoog. Dat is meetbaar, herhaalbaar en staat niet ter discussie. Maar 'gelande PR's' zijn een generatie-maatstaf, en zoals verschillende analisten hebben opgemerkt: generatie schaalt moeiteloos. Validatie niet. (opentools.ai).
In mijn eigen (kleine) voorbeeld van drie weken zijprojectwerk met Symphony, ging mijn PR-doorvoer met ongeveer 3-4x omhoog op het soort tickets waar Symphony goed in is: goed opgezet, single-feature, test-coverable. Bij dubbelzinnige tickets waren de prestaties slechter dan bij mij-met-Claude-code, omdat elke muntwisseling in de specificatie groter werd.
Het mentale model waar ik voor gekozen heb: Symphony verplaatst het knelpunt van 'het schrijven van de code' naar 'het schrijven van de specificaties en het beoordelen van de PR'. Dat is een echte productiviteitswinst als en slechts als uw proces voor het schrijven en beoordelen van specificaties dit tempo kan bijhouden. Als beoordeling het knelpunt wordt en u PR's begint af te stempelen om de wachtrij te wissen, heeft u een snellere manier bedacht om technische schulden te genereren.
Dus als je '500%' ziet, vertaal dit dan naar: 'Dit team had de processen voor het schrijven en beoordelen van specificaties zo volwassen dat er daadwerkelijk vijf keer meer code kon worden verzonden.' Dat is de vraag die u uzelf moet stellen voordat u Symphony adopteert - niet "kan ik meer agenten runnen?" maar "kan ik de output van meer agenten bekijken zonder dat de kwaliteit achteruitgaat?"
Wat dit betekent voor hoe ik nu aan het bouwen ben
De week nadat ik Symphony had draaien, herschreef ik de manier waarop ik het werk aan mijn belangrijkste klantproject structureerde. Drie concrete veranderingen.
Eén: elk nummer dat ik nu open, eindigt met een sectie "Definitie van klaar". Niet omdat Symphony het oppakt (het klantproject draait nog niet Symphony), maar omdat het schrijven van tickets in die vorm nu mijn basislijn is. De discipline die een coding agent vereist, is dezelfde discipline waarvan een junior engineer profiteert.
Twee: ik heb npm test, npm run lint en npm run typecheck overal toegevoegd als vereiste stappen in mijn agentworkflowbestanden. Geen uitzonderingen. Computationele sensoren zijn gratis. Gebruik ze.
Drie: ik ben gestopt met het maken van onderscheid tussen "AI-tools die ik gebruik" en "AI-infrastructuur die ik gebruik." Dat onderscheid is dood. Codex, Claude Code, Cursor — dit zijn binnenste harnassen. Ze zitten ergens in. De vraag is hoe dat iets eruit ziet. De mijne gaat steeds meer op Symphony lijken, plus een binnenlus in Ralph-stijl met computationele sensoren. Die van jou ziet er misschien anders uit. Maar het zal iets zijn.
Als je dieper wilt ingaan op de bredere verschuiving naar agent-als-infrastructuur: [mijn stuk over het langlopende agentenharnas van Anthropic] (/anthropic-long-running-agent-harness/) behandelt de kant van het binnenharnas vanuit een Claude-hoek, en de [Paperclip-casestudy over het orkestreren van nul-menselijke AI-bedrijven] (/paperclip-orchestrating-zero-human-ai-companies/) laat zien wat er gebeurt als je het patroon van het buitenste harnas naar zijn logische conclusie. Voor de praktische kant van Codex laat mijn vergelijking van Codex Claude Code als vervanging van de cursor zien waar Codex in 2026 werkelijk andere coding agents verslaat.
Een woord over waar dit naartoe gaat
Drie voorspellingen, gerangschikt van 'Ik heb er vertrouwen in' tot 'Ik durf te wedden op een kopje koffie.'
Zelfverzekerd. Binnen twaalf maanden zal elke serieuze technische organisatie iets Symphony-vormig in productie hebben. Het kan Symphony zelf zijn, het kan Gas Town zijn, het kan Archon zijn, het kan een dekblad van eigen bodem zijn. De vorm – probleem-tracker-als-wachtrij, geïsoleerde werkruimte-per-taak, deterministische-sensoren-in-de-loop, menselijke beoordeling aan het eind – is de toekomst. De woordenschat is al aan het convergeren. De implementaties volgen.
Redelijk zelfverzekerd. Het knelpunt voor de meeste teams zal niet de orkestrator zijn. Het zal het harnas in de agent zijn: de aanwijzingen, de vaardigheden, de draaiboeken, de sensoropdrachten. Teams die al investeren in CLAUDE.md-achtige discipline zullen Symphony sneller adopteren dan teams die dat niet doen, en de kloof zal groter worden. (Als je agentvaardigheden hebt genegeerd, is dit het moment om te stoppen.)
Wed een kopje koffie. Binnen zes maanden zal Linear native ondersteuning in Symphony-stijl leveren en OpenAI of een derde partij zal een gehoste Symphony-runtime uitbrengen die het devbox-gedeelte wegneemt. Het huidige patroon van 'huur je eigen devbox' is operationeel te zwaar om op de lange termijn te kunnen beantwoorden.
Maar hier is het diepere punt. Symphony is niet belangrijk omdat het de beste orkestrator is. Het is belangrijk omdat het ons een gedeelde specificatie gaf: een vocabulaire dat iedereen kan implementeren, afleiden of stelen. Dat is de zet die van een tool een categorie maakt.
Ga terug naar het moment dat ik in de opening beschreef: het elf minuten durende Linear-ticket dat zonder mij werd verzonden. Dat moment is niet indrukwekkend vanwege wat een agent deed. Het is indrukwekkend vanwege wat één gedeelde specificatie, uitgevoerd als een buitenste harnas, rond elk binnenharnas, rond elk model op schaal mogelijk maakt.
Als u vandaag slechts één ding leest, lees dan Symphony SPEC.md van kaft tot kaft. Het zijn twaalf pagina's. Tegen de tijd dat u klaar bent, ziet u uw huidige AI-workflow anders. En dat – niet de 500%, niet de 15.000 sterren – is de daadwerkelijke verschuiving die het waard is om voor te optimaliseren.
Geef uzelf nu een echt kaartje. Degene die je hebt uitgesteld. Schrijf het als een specificatie. Voeg een definitie van klaar toe. Stel je voor dat een agent die je nog nooit hebt ontmoet het gaat lezen.
Vraag jezelf dan af: zou het werk gedaan worden?
Als het antwoord nee is, ligt het probleem nooit bij de agent.
Veelgestelde vragen
Wat is OpenAI Symphony en hoe werkt het?
Symphony is een open-sourcespecificatie van OpenAI die een issue-tracker zoals Linear verandert in een besturingsvlak voor autonome coding agents. Het ondervraagt de tracker elke 30 seconden, claimt tickets die overeenkomen met een triggerlabel, spint een geïsoleerde git-werkboom per ticket, voert een Codex- of Claude Code-agent uit in die werkruimte totdat deze een PR produceert, en koppelt de PR terug aan het ticket. De referentie-implementatie bevindt zich in Elixir, maar de specificatie is taalonafhankelijk. Zie Symphony instellen op een echte opslagplaats hierboven voor de volledige uitleg.
Waarin verschilt Symphony van Gas Town, Archon en Ralph loops?
Symphony gaat uit van één ticket, één agent, één PR – en de issue tracker is de wachtrij. Gas Town beheert gecoördineerde kolonies van 20-30 parallelle agenten met expliciete rollen. Archon schrijft deterministische YAML-workflows rond elke coding agent met expliciete fasepoorten. Ralph loops zijn de minimaal levensvatbare binnenste lus: while not done: run agent again with latest state. Ze zijn complementair: een Symphony-ticket kan een Ralph-lus in zijn werkruimte plaatsen.
Houdt de OpenAI Symphony 500% PR-verhogingsclaim stand in de praktijk?
De claim is reëel voor tickets met een beperkte reikwijdte voor teams met volwassen specificaties voor het schrijven en beoordelen van processen: de generatiedoorvoer neemt sterk toe. Maar 'gelande PR's' zijn een generatiestatistiek, en validatie schaalt niet op dezelfde manier. Tijdens mijn eigen tests zag ik 3-4x op tickets met een goed bereik en slechter dan de basislijn op dubbelzinnige tickets. Eerlijk gezegd: Symphony verplaatst het knelpunt van coderen naar het schrijven en beoordelen van specificaties.
Wat is harness engineering en waarom is dit belangrijk voor coding agents?
Harness engineering is de discipline van het ontwerpen van alles rond het model dat het tot een betrouwbare agent maakt: gidsen (feedforward-sturing: aanwijzingen, vaardigheden, draaiboeken) en sensoren (feedbackvalidatie: linters, tests, typecheckers, LLM-als-rechter). Het Martin Fowler-artikel van Birgitta Böckeler is de canonieke referentie. Het raamwerk onderscheidt het binnenharnas (binnen de agent) van het buitenharnas (rond de agent), en Symphony is regelrecht een buitenharnas.
Moet ik Elixir kennen om Symphony te kunnen gebruiken?
Nee. De Elixir-implementatie is een referentie, geen vereiste. De specificatie is het eigenlijke artefact, en OpenAI heeft aangetoond dat Codex de specificatie opnieuw kan implementeren in TypeScript, Go, Rust, Java en Python. Als uw team al een van deze talen gebruikt, is het opnieuw implementeren van de Orchestrator een gemakkelijk weekendproject. Als je vertrouwd bent met Elixir of bereid bent de basisbeginselen te leren, is de referentie kant-en-klaar.
Laten we samenwerken
Wilt u AI-systemen bouwen, workflows automatiseren of uw technische infrastructuur schalen? Ik help je graag.
- Fiverr (aangepaste builds en integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (ondernemingsoplossingen): ramlit.com
- ColorPark (ontwerp en branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
