OpenAI libera Symphony: spec open-source pra orquestrar exércitos de Codex via Linear

A OpenAI anunciou o Symphony, um spec open-source que transforma ferramentas de gestão de tarefas (tipo Linear) em painel de controle pra agentes de código. A ideia: toda issue aberta ganha um agente dedicado, que roda continuamente até a tarefa terminar. Humano só revisa o resultado.

Escrito por Alex Kotliarskyi, Victor Zhu e Zach Brock, o post conta que o time da OpenAI passou seis meses construindo um repositório interno onde NENHUMA linha foi escrita por humano. Tudo gerado pelo Codex. Funcionou, só que esbarrou num gargalo novo: troca de contexto.

O problema que o Symphony ataca

Mesmo com agentes de código mais fáceis de usar, eles continuam sendo ferramentas interativas. Cada engenheiro abria 3-5 sessões do Codex em paralelo, distribuía tarefas, revisava output, corrigia rota, repetia. Acima disso, produtividade despencava.

"Os agentes eram rápidos, mas a gente tinha um gargalo de sistema: atenção humana. Tínhamos efetivamente montado um time de juniores extremamente capazes, e botado nossos engenheiros sêniores pra microgerenciar eles."

A virada de chave: parar de orientar o sistema em torno de sessões e PRs (pull requests), e passar a orientar em torno de deliverables (issues, tasks, tickets, milestones). Ou seja, deixa o agente puxar trabalho direto do task tracker.

Como funciona na prática

Cada issue aberta no Linear mapeia pra um workspace dedicado. O Symphony fica observando o board e garante que toda task ativa tem um agente rodando até concluir. Se o agente trava ou crasha, Symphony reinicia. Se aparece tarefa nova, Symphony pega.

O workflow usa os status do ticket como state machine, com Linear servindo de fonte da verdade. Isso desacopla trabalho de sessões e de PRs. Algumas issues geram múltiplos PRs em repos diferentes; outras são pura investigação que nem toca no código.

Um exemplo concreto que o time cita: pediram pro agente analisar codebase, Slack e Notion e produzir um plano de implementação. Quando aprovaram o plano, o agente gerou uma árvore de tasks com dependências. Marcaram o upgrade de React como bloqueado por uma migração pra Vite. Os agentes só começaram a mexer no React depois que a migração do Vite terminou.

Agentes também criam trabalho sozinhos. Durante implementação, identificam melhorias fora do escopo (problema de performance, oportunidade de refactor) e abrem nova issue, que o time avalia e agenda depois. Muitas dessas tarefas-filhote também são pegas por agentes.

Os números

Em alguns times da OpenAI, o número de PRs mesclados subiu 500% nas primeiras três semanas. Karri Saarinen, fundador do Linear, destacou um pico de workspaces criados na época do release.

Aqui vale o filtro de sempre: "alguns times" não é "toda a OpenAI". O ganho real depende muito de quão bem o repositório já está preparado pra agente, com testes automatizados, guardrails e documentação de workflow. Sem essa base, Symphony vira gerador de PRs ruins em escala.

O design: spec, não framework

A parte mais interessante: ao abrir o repositório, você descobre que o Symphony é tecnicamente só um arquivo SPEC.md. Em vez de construir sistema de supervisão complexo, eles definiram o problema e a solução desejada, e deixaram o agente fazer o resto.

A implementação de referência foi escrita em Elixir (escolha pelas primitivas de concorrência da BEAM). Mas o time pediu pro Codex implementar o mesmo spec em TypeScript, Go, Rust, Java e Python pra identificar ambiguidades. Funcionou em todas.

Principais componentes definidos no spec:

• Workflow Loader: lê WORKFLOW.md, parseia YAML front matter e prompt body.
• Issue Tracker Client: busca issues candidatas, normaliza payload do Linear.
• Orchestrator: dono do tick de polling e do estado em memória.
• Workspace Manager: mapeia identifier de issue pra path de workspace.
• Agent Runner: cria workspace, monta prompt, dispara o Codex via app-server.

O Codex roda em app server mode, um modo headless com API JSON-RPC documentada. Mais escalável que tentar conversar com Codex via CLI ou tmux. Pra evitar expor token do Linear pros sub-agentes, usaram dynamic tool calls expondo uma função linear_graphql que executa requests arbitrários contra o Linear sem MCP no meio.

A mudança de comportamento

Quando engenheiro para de supervisionar sessão Codex, a economia da mudança de código muda completamente. O custo percebido de cada change cai, porque ninguém investe esforço humano dirigindo a implementação.

Isso virou trivial: subir tarefa especulativa no Symphony. Testar uma ideia, explorar refactor, validar hipótese, e descartar o que não presta. Também ampliou quem pode iniciar trabalho. PM (Product Manager) e designer abrem feature request direto no Symphony. Não precisam clonar repo nem gerenciar sessão Codex.

Esse é o ponto que a OpenAI tá vendendo de verdade: não é só "agentes geram código", é "qualquer pessoa do time pode encomendar código sem passar por engenheiro". Pra estrutura tradicional de eng, é uma reorganização de poder não trivial.

Onde NÃO usa

O próprio time admite: nem toda task encaixa no estilo Symphony. Problemas ambíguos, ou trabalho que exige julgamento e expertise forte, ainda pedem engenheiro em sessão Codex interativa. Esses, na prática, são geralmente os mais interessantes.

E eles também aprenderam que tratar agente como nó rígido em state machine não funciona bem. Modelos ficam mais espertos e resolvem problemas maiores que a caixa que você tenta meter eles. Migraram pra dar objetivos ao agente, em vez de transições estritas. Tipo o que um bom gerente faz com subordinado: define meta, dá ferramentas e contexto, e deixa cozinhar.

Disponibilidade

O Symphony é open-source e tá no GitHub (mais de 15 mil stars até 23 de abril). A OpenAI deixa claro: não vão manter como produto standalone. É uma reference implementation, e o convite é pra apontar seu agente de código favorito pro spec e construir a sua versão.