OpenAI publiserte den nye versjonen av Symphony på GitHub 28. april. Repoet har samlet rundt 19 000 stjerner og leveres som en spesifikasjon pluss en Elixir-referanseimplementasjon. Ideen er enkel: hver åpne oppgave i Linear blir et isolert agent-arbeidsområde, Symphony spawner en agent per oppgave, overvåker fremdrift og restarter agenter som setter seg fast.
Agentene leverer fra seg «proof of work» når de er ferdige: CI-status, PR-review-tilbakemeldinger, kompleksitetsanalyse og en gjennomgangsvideo. Du som ingeniør ser ikke individuelle agenter klore seg gjennom oppgavene, du godkjenner ferdig arbeid på prosjektnivå.
«Symphony moves teams from managing coding agents to managing the work that needs to get done.» — OpenAI, Symphony README
Hva betyr det for deg
Symphony løser et reelt problem mange har truffet på allerede: Codex, Claude Code og Cursor agenter klarer å fullføre én oppgave, men holder du tjue av dem i lufta samtidig på samme kodebase, mister du oversikten. Symphony bytter ut menneskelig overvåking med en orkestrator som kobler issue-tracker og kjøremiljø.
Spesifikasjonen er åpen, så ingenting hindrer deg i å implementere den selv mot din egen agent-stack. Referanseimplementasjonen er skrevet i Elixir, av alle ting, fordi BEAM-runtimen håndterer mange parallelle, langlevde prosesser bedre enn Node eller Python når noen av dem henger.
OpenAI selv merker prosjektet som «low-key engineering preview» og advarer om at du bør kjøre det i miljøer du stoler på. Det er en høflig måte å si at agentene har skrive-tilgang til kodebasen din.
Hva bør du gjøre?
- Les SPEC.md før du installerer noe. Spesifikasjonen er kort og avgjør om Symphony passer din arbeidsflyt.
- Test på en throwaway-fork først. Symphony spawner agenter som lander PR-er; ikke pek den mot main i et produksjonsrepo.
- Vurder alternativene. Sweep, GitHub Copilot Workspace og Devin løser deler av samme problem. Symphony er først og fremst en spesifikasjon, ikke en SaaS, så låsingsrisikoen er lav.