OpenAI har netop delt en detaljeret retrospektiv om Symphony, deres open source-agent-orkestrator, der ifølge virksomheden selv gav visse interne teams en stigning på 500% i landede pull requests på bare tre uger. Resultatet lyder voldsomt og det er det også. Men den egentlige nyhed handler ikke om et nyt værktøj. Den handler om en ny disciplin: harness engineering.
Symphony blev oprindeligt frigivet 5. marts 2026 under Apache 2.0-licens. I et deep dive offentliggjort 27. april har OpenAIs Codex-team nu delt de konkrete resultater, designvalg og begrænsninger bag systemet. Per 23. april har GitHub-repositoriet over 15.000 stjerner.
Før Symphony kunne en typisk OpenAI-ingeniør komfortabelt håndtere tre til fem samtidige Codex-sessioner. Derefter tog kontekstskift over, og produktiviteten faldt. Problemet var ikke modellens kapacitet, men ingeniørens opmærksomhed. Symphony blev bygget til at løse netop den flaskehals.
Konceptet er enkelt: for hver åben opgave i en issue-tracker skal der garanteres, at en AI-agent kører i sit eget workspace, indtil arbejdet er færdigt. Hvis en agent crasher eller staller, genstarter Symphony den automatisk. Hvis nyt arbejde dukker op, plukker systemet det op. Resultatet er, at ingeniøren ikke længere overvåger agenter, men styrer arbejde.
OpenAI formulerer selv paradigmeskiftet som at flytte fra at "overvåge coding agents" til at "styre arbejde". Det er en subtil, men afgørende forskel. Når overvågning forsvinder, falder den oplevede omkostning ved hver enkelt kodeændring. Det ændrer adfærd: det bliver trivielt at igangsætte spekulative opgaver, udforske en refaktor eller teste en hypotese og kun beholde det, der ser lovende ud.
I praksis fungerer det sådan, at Linear-boardet bliver en kontrolflade for agenter. Hver åben opgave mapper til et dedikeret agent-workspace. Symphony poller kontinuerligt og sørger for, at ingen aktiv ticket står uden en kørende agent. Ifølge OpenAIs egen beskrivelse er kerneformlen: "For every open task, guarantee that an agent is running in its own workspace."
Det er her disciplinen harness engineering kommer ind. Begrebet dækker over design af constraints, automatiserede tests, guardrails og repository-strukturer, der gør agenter produktive på kode. Symphony virker bedst i codebases, der allerede har investeret i harness engineering. Uden solid test coverage, klar CI-pipeline og velstrukturerede issues producerer agenterne støj i stedet for værdi.
Linear-grundlægger Karri Saarinen rapporterede en stigning i nye workspaces oprettet i forbindelse med Symphony-releasen. Det tyder på, at udviklingsmiljøer allerede eksperimenterer med at bruge deres issue-tracker som kontrolflade for agentic workflows i stedet for blot som opgavestyring.
For danske virksomheder, der bruger Jira eller Azure DevOps, er det værd at bemærke, at fællesskabet allerede arbejder på integrationer til andre platforme. Princippet bag Symphony er platformuafhængigt: enhver issue-tracker kan blive en kontrolflade, hvis processerne omkring den er modne nok.
En af de mest bemærkelsesværdige detaljer ved Symphony er, hvordan det blev skabt. OpenAI definerede problemet og løsningen i en SPEC.md-fil, altså rent sprogligt, ikke i kode. Derefter bad de Codex om at bygge den første implementering. Codex leverede en fungerende Elixir-version i ét shot.
For at validere specifikationens kvalitet bad OpenAI derefter Codex om at implementere den i TypeScript, Go, Rust, Java og Python. Alle seks implementeringer lykkedes. OpenAIs konklusion: hvis en model kan implementere din specifikation i seks programmeringssprog, er specifikationen ren nok. Det er et konkret eksempel på, hvad agentic engineering ser ud i praksis.
Valget af Elixir som primært sprog er i sig selv en filosofisk pointe. OpenAI forklarer det med, at "when code is effectively free, you can finally pick languages for their strengths". Elixir og BEAM-platformen tilbyder fault-tolerant supervision trees, lette samtidige processer og distribueret afvikling ud af kassen. Det er præcis de egenskaber en agent-orkestrator har brug for.
Hele orkestreringspolicyen ligger i en WORKFLOW.md-fil med YAML-frontmatter og en prompt-body, som versionskontrolleres sammen med koden. Det gør agent-adfærd reproducerbar og transparent. Vil du have, at agenter skal reflektere over færdigt arbejde? Føj det til WORKFLOW.md.
Det er AI-orkestrering gjort til infrastruktur-som-kode.
Konsekvenserne rækker ud over kodning. Når den oplevede omkostning ved kodeændringer falder drastisk, ændrer det også, hvem der kan initiere arbejde. OpenAI rapporterer, at product managers og designere nu kan sende feature requests direkte ind i Symphony og få en reviewpakke tilbage, komplet med en video-walkthrough af den implementerede feature.
Det forskyder magtbalancen i udviklingsorganisationen. Juniorudviklernes rutineopgaver bliver agent-arbejde. Seniorudviklernes review- og arkitekturarbejde bliver det lag, der sikrer kvalitet og retning. Product managers og scrum masters får en ny kernekompetence: at skrive issues, der er præcise nok til, at en agent kan handle på dem. Issue-kvalitet bliver et målbart asset, for vage tickets producerer vag kode.
Det er værd at bemærke, at Symphony officielt kun understøtter Linear og Codex. Men open source-fællesskabet har allerede udvidet rækkevidden. Ifølge Help Net Security har Hoon Choi forket Symphony til Claude Code med GitHub Issues-integration, og Mert Koseoglu har bygget en Claude Code-variant kaldet hatice. Det signalerer, at disciplinen harness engineering ikke er bundet til ét specifikt værktøj, men er en praksis, der kan adopteres uafhængigt af leverandør.
For danske udviklingsorganisationer er Symphony ikke bare en teknisk nyhed. Det er et spejl, der afslører, hvor klar jeres codebase og processer er til agentic engineering. Uanset om I er et team på fem udviklere eller femogtyve, handler de grundlæggende forudsætninger om det samme.
Det første spørgsmål handler om issue-kvalitet. Er jeres tickets specifikke nok til, at en agent kan forstå konteksten, afgrænsningen og succeskriteriet uden menneskelig uddybning? Hvis svaret er nej, er det første skridt ikke at installere Symphony, men at opgradere jeres issue-praksis. Det kræver ingen ny teknologi, kun en ny disciplin.
Det andet spørgsmål handler om reviewkapacitet. Hvis antallet af pull requests stiger med 500%, kan jeres nuværende reviewproces så absorbere det? Uden skalérbare reviewprotokoller ender I med en kø af uanmeldte ændringer, der skaber teknisk gæld hurtigere end agenterne fjerner den. Her bør I overveje automatiserede review-værktøjer og klare AgentOps-principper.
Det tredje spørgsmål handler om governance. Symphony har ikke indbyggede godkendelsesgates. Danske virksomheder med GDPR-krav eller sektorspecifik compliance skal selv bygge dem ind. Agentic coding uden guardrails er ikke en produktivitetsgevinst, det er en risiko. OpenAI understreger selv, at Symphony er en "low-key engineering preview for testing in trusted environments" og ikke planlægger at vedligeholde det som et standalone produkt. Det er en reference-implementering og en skabelon for den disciplin, der skal til for at flytte softwareudvikling fra AI-assisteret kodning til AI-udført arbejde. Forskellen er ikke triviel, og for danske B2B-virksomheder med ambitioner om at skalere udviklingsteams er den værd at forstå nu.