OpenAI Symphony: O coding agent orchestrator testado
A primeira vez que Symphony pegou um dos meus tickets Linear e enviou uma solicitação pull funcional sem que eu tocasse no teclado, fiquei sentado lá por um minuto inteiro tentando descobrir o que deveria fazer a seguir.
Meu tíquete dizia: * "Adicionar middleware de limitação de taxa aos endpoints públicos API, padrão 60 req/min, permitir substituições por rota." Onze minutos depois existia um rascunho de relações públicas. O agente criou um espaço de trabalho isolado, leu minha base de código, escreveu o middleware, adicionou substituições em nível de rota, escreveu três testes e enviou um branch. A diferença não foi perfeita – rejeitei um teste e restringi um comentário – mas o trabalho foi real. O trabalho estava feito.
Esse ticket foi o momento em que o agente orquestrador OpenAI Symphony deixou de ser uma demonstração para mim e passou a ser uma ferramenta. Isso também me forçou a enfrentar algo desconfortável: a maneira como usei Codex e Claude Code no ano passado – um terminal, um prompt por vez, um humano cuidando de um agente – estava prestes a parecer tão desatualizado quanto usar SSH em um único servidor para implantar um aplicativo da web em 2014.
Esta é a postagem que eu gostaria que alguém tivesse me entregado antes de passar dois fins de semana reestruturando a forma como penso sobre a infraestrutura de agentes. Vou mostrar o que Symphony realmente é (é menor e mais estranho do que os comunicados de imprensa sugerem), como ele se encaixa no padrão mais amplo que as pessoas estão chamando de "harness engineering", o que quebrei quando tentei dobrá-lo em minha própria pilha e a única mudança mental que fez tudo clicar.
Um aviso antes de prosseguirmos: há um número sendo divulgado - a afirmação de OpenAI de que algumas equipes internas viram um aumento de 500% nas solicitações pull recebidas dentro de três semanas após a adoção do Symphony (OpenAI). Voltarei a esse número mais adiante neste post, porque a maneira como você o lê determina se você constrói a coisa certa ou errada.
O que OpenAI Symphony realmente é (e o que não é)
Deixe-me eliminar um equívoco desde o início: Symphony não é um produto. Não é um SaaS. Não é um binário fechado. Não há painel no qual você faça login.
Symphony é um arquivo SPEC.md. Esse é todo o artefato principal. OpenAI abriu o código-fonte no Apache 2.0 em 5 de março de 2026 e, no final de abril de 2026, o repo openai/symphony GitHub ultrapassou 15.000 estrelas (Help Net Security). A especificação descreve – em linguagem simples, com diagramas de estado – como um orquestrador de longa duração deve transformar um rastreador de problemas em um plano de controle para agentes de codificação autônomos.
A implementação de referência vem em Elixir. Sim, Elixir. A mesma linguagem que o Discord e o WhatsApp usam nos bastidores. OpenAI escolheu-o porque o BEAM (tempo de execução do Elixir) oferece árvores de supervisão, processos leves e semântica de recuperação de falhas gratuitamente - exatamente o que você deseja quando está executando dez ou vinte agentes de codificação que podem levar vinte minutos por tarefa cada e qualquer um dos quais pode morrer silenciosamente.
Mas aqui está a parte que me surpreendeu. A equipe OpenAI fez com que Codex gerasse a implementação do Elixir de uma só vez a partir da especificação e, em seguida, pediu a Codex para reimplementar a mesma especificação em TypeScript, Go, Rust, Java e Python - usando cada implementação como uma função forçada para encontrar ambiguidades na própria especificação (InfoWorld). A especificação é o produto. O código Elixir é apenas o exemplo mais sofisticado.
Isso é importante porque informa que tipo de ferramenta você está realmente avaliando. Symphony não é a "estrutura orquestradora do OpenAI". É um vocabulário compartilhado sobre como é uma boa orquestração de agentes de codificação, com uma referência funcional que você pode executar como está ou roubar.
O Core Loop, em um parágrafo
Symphony pesquisa Linear a cada 30 segundos. Quando ele vê um ticket passar para um estado "pronto" configurado, ele reivindica esse ticket, ativa um espaço de trabalho isolado (uma nova árvore de trabalho git em um devbox), inicializa um agente Codex nesse espaço de trabalho com um prompt estruturado que inclui o corpo do ticket, permite que o agente execute continuamente até produzir um PR ou falhar e, em seguida, marca o ticket como "pronto para revisão" ou "bloqueado" com um motivo. A simultaneidade padrão é de 10 agentes. O estado está na memória de um GenServer; ao reiniciar, ele apenas reconstrói a partir de Linear, portanto não há banco de dados para operar (allthings.how).
É isso. Isso é tudo. Leia esse parágrafo novamente, porque a simplicidade é o ponto principal.
Por que o hype me pegou desprevenido
Serei honesto. Quando a postagem do blog OpenAI chegou no início de março, dei uma olhada e segui em frente. “Outro agente orquestrador” foi o pensamento cínico. Eu já tinha tocado com Gas Town de Steve Yegge, estava executando Archon em um projeto paralelo por três semanas e construí meu próprio arnês Claude Code de longa duração para um cliente. Nenhuma dessas ferramentas precisava de um quarto concorrente.
O que perdi – o que a maior parte da cobertura perdeu – é que o Symphony não está realmente competindo com essas ferramentas. Ele está competindo com sua versão que abre um terminal, digita codex ou claude e observa um agente trabalhando em uma tarefa. Está competindo com a própria supervisão manual. Depois que entendi isso, minha semana inteira mudou.
Para explicar o porquê, preciso fazer um desvio para o termo que silenciosamente se tornou o conceito mais importante na entrega de software assistida por AI este ano: harness engineering.
Harness Engineering: O vocabulário que fez tudo clicar
Em abril de 2026, Birgitta Böckeler — líder global da Thoughtworks para entrega de software assistida por AI — publicou um artigo longo e cuidadoso em martinfowler.com intitulado "Engenharia de aproveitamento para usuários de agentes de codificação". É o artigo que nos deu a taxonomia canônica. (O resumo do vídeo em que trabalhei traduziu foneticamente o nome dela como "Vetta Berkeler" - mesma pessoa, mesma estrutura.)
O enquadramento é aparentemente simples:
Agente = Modelo + Arnês
O modelo é o LLM. Todo o resto — os prompts, as ferramentas, a sandbox, o loop, os validadores, o orquestrador — é o equipamento. E assim que você começar a nomear as partes do arnês, poderá começar a projetá-las deliberadamente, em vez de acidentalmente.
Böckeler divide o arnês em duas camadas e o Symphony reside diretamente em uma delas.
Arnês interno — O que há dentro do agente
O arnês interno é o código e os recursos fornecidos dentro do próprio agente. Ao executar o Claude Code, você obtém o equipamento interno gratuitamente: o protocolo de chamada de ferramentas, as ferramentas de leitura de arquivos e execução de shell, os prompts de planejamento, a geração de subagentes, as portas de permissão, o sistema de ganchos, as habilidades que você pode instalar. O mesmo com Codex. O mesmo com Cursor.
Você geralmente não escreve o arnês interno. Você configura isso. Você habilita ganchos. Você instala habilidades. Você escreve um CLAUDE.md ou AGENTS.md. Você define permissões em settings.json. O chicote interno é o que transforma um modelo em um agente de codificação.
Chicote Externo – O que envolve o agente
O arnês externo é tudo fora do agente que controla seu ciclo de vida, gerencia seu contexto, decide quando ele é executado, em que ele é executado, o que conta como "pronto" e o que acontece quando ele falha. É aqui que mora Symphony. É aqui que Gas Town, Archon e Ralph loops também moram.
O chicote externo é o que transforma uma sessão de terminal do Claude Code em uma frota de vinte agentes paralelos nos quais você realmente confia.
Esta é a imagem mental que desenho em um quadro branco quando explico isso aos clientes:
┌──────────────────────────────────────────┐
│ 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. │ │ │
│ │ └────────────────────────┘ │ │
│ └──────────────────────────────────┘ │
└──────────────────────────────────────────┘
Depois de ver as camadas, cada "produto do agente AI" se encaixa em uma posição nesta imagem. E quando isso acontecer, a questão real deixa de ser "qual agente devo usar?" e se torna "o que meu arnês externo precisa fazer que ninguém mais pode?"
Essa é a pergunta que Symphony obriga você a responder.
Guides e Sensors — As duas alavancas em cada chicote
Dentro de ambas as camadas, Böckeler introduz outra distinção na qual penso agora sempre que escrevo um prompt de agente ou configuro uma etapa de CI. Cada peça significativa de um arnês desempenha uma de duas funções.
Guides orienta o agente antes de ele agir. Eles são controle feedforward. Seu CLAUDE.md. As habilidades que você instala. O manual que você cola no prompt. O exemplo confirma sua referência. A decisão da arquitetura registra o que o agente lê antes de escrever o código. Guides aumenta a probabilidade de o agente acertar na primeira tentativa.
Sensors observe o agente depois de agir e decida se o que ele produziu é aceitável. Eles são controle de feedback. Sensors vem em dois sabores:
- Sensores computacionais — determinísticos, rápidos e baratos. Linters. Digite damas. Testes unitários. Validadores de esquema. Crie resultados. Eles são executados em milissegundos a segundos e fornecem uma resposta binária (Martin Fowler).
- Sensores inferenciais — não determinísticos, lentos e caros. Revisões de código LLM como juiz. Verificações de similaridade semântica. Críticas de estilo. Eles são executados em uma GPU, levam de segundos a minutos e fornecem respostas probabilísticas.
Aqui está a parte que demorei muito para internalizar: ** a maioria das equipes com as quais trabalhei subutilizam sensores computacionais e confiam demais nos inferenciais. ** Eles configurarão um "revisor AI" antes de configurarem eslint --max-warnings 0 em um gancho de pré-confirmação. Eles terão uma cobertura de teste de nota LLM como juiz antes de adicionarem um limite de cobertura ao CI.
Sensores computacionais são basicamente gratuitos. Eles estão comprovados. Eles funcionam em pipelines de CI há quinze anos. A razão pela qual eles são ignorados nos fluxos de trabalho dos agentes é que os profissionais esquecem que o agente pode ler seus resultados e se autocorrigir. No momento em que você conecta npm test ao loop do agente e alimenta as falhas como contexto, sua taxa de erro cai em um fator que realmente não consigo estimar sem mentir. É muito.
Voltarei a isso quando mostrar como é um arquivo de fluxo de trabalho Symphony real, porque guias e sensores é todo o vocabulário que você usa para criar um. Por enquanto, observe o seguinte: um chicote é um conjunto cuidadosamente escolhido de guias e sensores dispostos em torno de um modelo. O orquestrador é exatamente o que controla o chicote em uma fila.
Onde Symphony se encaixa na família de chicotes externos
Symphony não é o único equipamento externo disponível e nem sempre é a resposta certa. Deixe-me analisar os quatro que usei no trabalho de produção este ano, porque as compensações são importantes.
1. Symphony — Orquestração nativa do Issue-Tracker
A escolha definidora de Symphony é que o rastreador de problemas é a fila. Os tickets Linear são as unidades de trabalho. Não há UI Symphony separada para gerenciar. Você move um ticket para "Pronto para Codex", Symphony o pega, um agente é executado, um PR aparece vinculado ao ticket e você revisa o ticket como sempre fez. A sobrecarga cognitiva de adotá-la é praticamente zero, porque você não está aprendendo uma nova ferramenta de gerenciamento de projetos.
A desvantagem é que a área de superfície do Symphony é pequena. Ele faz uma coisa – transformar ingressos em corridas – e faz isso bem. Se o seu trabalho não se enquadra em tickets discretos (pesquisa de longa duração, refatorações de várias semanas, picos exploratórios), o Symphony não é sua ferramenta.
2. Gas Town – Colônias multiagentes, estilo Steve Yegge
Gas Town é a estrutura de Steve Yegge para executar 20-30 agentes Claude Code paralelos organizados em funções (prefeitos orquestram, Polecats executam), com estado persistido no Git por meio da pilha MEOW (Cloud Native Now). Onde Symphony assume “um ticket, um agente, um PR”, Gas Town assume enxames coordenados trabalhando em trabalhos relacionados com transferências explícitas.
Abordei o padrão "estilo enxame" com mais detalhes em meu artigo sobre arquitetura de enxame de agente Claude Code - se você estiver construindo algo em que vários agentes precisem coordenar a mesma tarefa em vez de tarefas paralelas, esse é o post a ser lido depois deste.
3. Archon — Fluxos de trabalho determinísticos em torno de qualquer agente de codificação
Archon se autodenomina "o primeiro construtor de chicotes de código aberto" - o enquadramento é exato. Enquanto Symphony codifica o fluxo de trabalho (poll Linear → executar agente → PR), Archon permite criar o fluxo de trabalho como um pipeline YAML com fases explícitas, portas de validação e artefatos. Cada execução obtém sua própria árvore de trabalho git. Você pode executar cinco correções em paralelo sem conflitos (MindStudio).
Procuro Archon quando o trabalho tem fases conhecidas – “investigar, planejar, implementar, testar, documentar” – e quero que cada fase seja uma etapa validada separada, em vez de uma longa execução de agente. Este também é o primo mais próximo das abordagens spec-driven, como aquela sobre a qual escrevi em minha [peça spec-driven AI do modo Traycer BART] (/traycer-bart-mode-spec-driven-ai/).
4. Loops Ralph - O chicote externo mínimo viável
O loop Wiggum Ralph (sim, nomeado em homenagem ao personagem dos Simpsons - "Estou ajudando!") é o equipamento externo mais simples possível: um loop while true que invoca novamente o agente até que uma verificação determinística seja aprovada. Há um plugin Anthropic oficial no repositório Claude Code e Vercel Labs envia ralph-loop-agent para o SDK AI.
A filosofia Ralph: não busque a perfeição na primeira tentativa. Deixe o loop refinar. O agente lê um arquivo de plano, progride, o loop verifica a conclusão em relação aos critérios e, se isso não for feito, o agente executa novamente com o estado mais recente (beuke.org).
Ralph não é competitivo com Symphony — é complementar. Um ticket Symphony pode executar um loop Ralph dentro de seu espaço de trabalho. Symphony lida com a fila e o isolamento. Ralph lida com a iteração até a correção. Conecte-os e você terá algo genuinamente poderoso.
Configurando Symphony em um repositório real
Chega de teoria. Deixe-me mostrar exatamente o que fiz para colocar o Symphony em execução em um projeto paralelo na semana passada. A coisa toda levou cerca de 90 minutos do git clone ao primeiro PR, e a maior parte disso foi a configuração do Linear, não o próprio Symphony.
Etapa 1: Obtenha a chave Linear API
Em Linear, vá para Configurações → Segurança e acesso → Chaves pessoais API e crie uma nova chave. Configure-o como LINEAR_API_KEY em seu ambiente. Symphony usa esse token por meio de sua ferramenta dinâmica linear_graphql — ele não expõe o token bruto a subagentes, o que é uma escolha de segurança pequena, mas cuidadosa (allthings.how).
Etapa 2: clonar o repositório e escolher uma implementação
git clone https://github.com/openai/symphony.git
cd symphony
O repo tem a especificação em SPEC.md e a referência do Elixir em elixir/. Se você tiver o Elixir instalado (brew install elixir no macOS), poderá executá-lo em dois minutos. Caso contrário, a simplicidade da especificação significa reescrever o orquestrador em uma linguagem que você sabe que é genuinamente tratável - esse é o objetivo de distribuir uma especificação em vez de um binário.
No restante deste passo a passo mostrarei o caminho do Elixir porque foi o que usei.
cd elixir
mix deps.get
mix compile
Etapa 3: Configure seu fluxo de trabalho
Copie o modelo WORKFLOW.md no repositório de destino (aquele em que você deseja que os agentes trabalhem, não no próprio repositório Symphony). É aqui que o vocabulário de aproveitamento compensa, porque WORKFLOW.md é essencialmente sua especificação de guia e sensor para cada execução de agente. Uma versão recortada minha ficou assim:
## Antes de começar
- Leia README.md e ARCHITECTURE.md
- Execute `npm install` e `npm test` para confirmar as passagens da linha de base
## Implementação
- Faça a menor alteração que satisfaça o ticket
- Adicione ou atualize testes para qualquer novo comportamento
- Execute `npm test` e `npm run lint` antes de considerar concluído
- Execute `npm run typecheck` — zero erros necessários
## Definição de pronto
- Todos os testes passam localmente
- Lint e typecheck passam sem nenhum aviso
- O título do PR corresponde ao título do ticket
- A descrição do PR faz referência ao ID do ticket Linear
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_sua_chave_aqui
SYMPHONY_TARGET_REPO=/Users/you/code/your-project
SYMPHONY_LINEAR_TEAM_ID=seu_team_id
SYMPHONY_TRIGGER_LABEL = pronto para 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 --no-halt
Essa é a configuração completa. Symphony agora está pesquisando Linear a cada 30 segundos. Marque qualquer ticket com ready-for-codex e um agente irá reivindicá-lo.
A primeira vez que fiz isso, criei um ticket deliberadamente pequeno — "Adicionar um endpoint /health que retorna { status: 'ok', uptime_seconds: <number> }" — e observei. O agente o pegou em 31 segundos. Ele leu a base de código. Ele encontrou meu aplicativo Express. Ele escreveu a rota, escreveu um teste, executou o teste (que passou na segunda tentativa após corrigir um pequeno problema de inferência do TypeScript), abriu um PR e marcou o ticket Linear como “revisão necessária”. Tempo total de parede: 4 minutos e 18 segundos. Eu li a diferença. Eu mesclei.
Eu sentei lá e olhei para a tela.
O que eu errei no caminho
Quero dedicar tempo real a esta seção porque foi onde aprendi mais e porque todos os artigos de "primeira análise" que li sobre Symphony a ignoram. Cometi quatro erros que vale a pena contar a você.
Erro 1: tratei Symphony como Claude Code
Nos primeiros dois dias, continuei abrindo o terminal devbox Symphony esperando falar com os agentes em execução. Symphony não funciona dessa maneira. Os agentes estão sem cabeça. Você se comunica com eles por meio de tickets. Se você quiser dar mais contexto a um agente, edite a descrição do ticket Linear (ou adicione um comentário) e deixe o próximo ciclo de pesquisa receber a alteração. Se você deseja redirecionar um agente no meio do voo, a resposta em 90% dos casos é não – interrompa a execução, edite o ticket e deixe-o começar do zero.
Esta foi uma mudança mental. Levei alguns dias para parar de tratar os agentes como colaboradores com os quais eu estava programando em pares e começar a tratá-los como trabalhadores para os quais eu estava emitindo tickets. A propósito, essa mudança é exatamente o que o design do Symphony está tentando impor a você. Projete seus tickets como especificações de produto, não como mensagens do Slack.
Erro 2: escrevi tickets vagos
Meus primeiros tickets eram o mesmo tipo de frase que eu daria a um colega sênior: "Refatore o middleware de autenticação". Um colega sênior preenche as lacunas com contexto compartilhado. Um agente não. Quando escrevi "Refatorar o middleware de autenticação para extrair a validação JWT em uma função separada, manter o API público existente de requireAuth(req, res, next), adicionar testes para a função extraída e não alterar os registros de rota", o agente enviou um PR limpo na primeira execução.
O princípio: cada ambigüidade em seu ticket se torna um cara ou coroa no comportamento de seu agente. Os ingressos são guias. Quanto mais você carregar o guia antecipadamente, menos precisará dos sensores para rejeitar saídas ruins.
Erro 3: pulei o Sensors computacional
Meu repositório de destino tinha npm test e npm run lint, mas eu não os adicionei à definição WORKFLOW.md de concluído. O agente tecnicamente executou testes quando teve vontade. Cerca de um em cada três PRs teve testes reprovados na chegada, e tive que me recuperar. A correção foram trinta segundos de edição de WORKFLOW.md para tornar os comandos do sensor inegociáveis. A taxa de falhas caiu para aproximadamente uma em quinze, em linha com o que vejo quando executo o Codex manualmente.
Você não vai acreditar quantas vezes a resposta é “adicionar uma verificação determinística ao seu arquivo de fluxo de trabalho”.
Erro 4: tentei executar Symphony sem isolamento de árvore de trabalho
Por preguiça, apontei duas execuções paralelas no mesmo checkout do mesmo repositório. Carnificina previsível. O design do Symphony assume – e a referência do Elixir impõe – o isolamento da árvore de trabalho git por ticket. Não lute contra isso. Cada agente recebe sua própria cópia de trabalho. É assim que cinco agentes que tocam diferentes partes da sua base de código não acabam pisando no WIP um do outro.
É também aqui que o design do Symphony começa a se parecer muito com a abordagem "cada fluxo de trabalho executado tem sua própria árvore de trabalho git" do Archon. A convergência não é um acidente. A árvore de trabalho por corrida está se tornando a convenção de suporte de carga de todos os arneses externos sérios.
Se você preferir entregar esse tipo de configuração a alguém que já fez isso antes, a Ramlit Limited cria e opera exatamente esses pipelines de orquestração para equipes de engenharia que desejam o rendimento sem a curva de aprendizado de oito finais de semana. Mas o caminho é genuinamente percorrido por você mesmo - isso é muito do que estou tentando mostrar aqui.
Como você deve ler o número 500%?
Eu lhe disse antes que voltaria a isso. A principal métrica do OpenAI é que algumas equipes internas viram as solicitações pull recebidas aumentarem em 500% nas primeiras três semanas de uso do Symphony (OpenAI).
Aqui está a leitura honesta.
Esse número é real, no sentido estrito. O rendimento de relações públicas aumentou. Isso é mensurável, repetível e não está em disputa. Mas “RPs conquistados” é uma métrica de geração e, como vários analistas apontaram, a geração aumenta sem esforço. A validação não. (opentools.ai).
Em minha própria (pequena) amostra ao longo de três semanas de trabalho de projeto paralelo com Symphony, minha taxa de transferência de relações públicas aumentou em algo como 3-4x nos tipos de tickets em que Symphony é bom - com bom escopo, recurso único e cobertura de teste. Em tickets ambíguos, o desempenho foi pior do que eu com o código Claude, porque cada lançamento de moeda nas especificações aumentava.
O modelo mental que estabeleci: Symphony move o gargalo de "escrever o código" para "escrever as especificações e revisar o PR". Isso é um ganho real de produtividade se e somente se seu processo de redação e revisão de especificações puder acompanhar. Se a revisão se tornar o gargalo e você começar a carimbar PRs para limpar a fila, você criou uma maneira mais rápida de produzir dívida técnica.
Então, quando você vir “500%”, traduza para: “esta equipe tinha processos de redação e revisão de especificações maduros o suficiente para que 5x mais código pudesse ser realmente entregue”. Essa é a pergunta que você deve fazer antes de adotar o Symphony - e não "posso administrar mais agentes?" mas "posso revisar a produção de mais agentes sem diminuir a qualidade?"
O que isso significa para o modo como estou construindo agora
Na semana seguinte à execução do Symphony, reescrevi a maneira como estruturo o trabalho em meu projeto principal do cliente. Três mudanças concretas.
Um: cada edição que abro agora termina com uma seção "Definição de concluído". Não porque Symphony irá buscá-la (o projeto do cliente ainda não executa Symphony), mas porque escrever tickets nesse formato agora é minha linha de base. A disciplina que um agente de codificação exige é a mesma da qual um engenheiro júnior se beneficia.
Dois: adicionei npm test, npm run lint e npm run typecheck como etapas obrigatórias em meus arquivos de fluxo de trabalho do agente em todos os lugares. Sem exceções. Sensores computacionais são gratuitos. Use-os.
Três – parei de distinguir entre “ferramentas AI que uso” e “infraestrutura AI que executo”. Essa distinção está morta. Codex, Claude Code, Cursor — estes são chicotes internos. Eles sentam dentro de alguma coisa. A questão é como é essa coisa. O meu vai se parecer cada vez mais com Symphony, além de um loop interno estilo Ralph com sensores computacionais. O seu pode parecer diferente. Mas vai ser alguma coisa.
Se você quiser uma leitura mais aprofundada sobre a mudança mais ampla em direção ao agente como infraestrutura, meu artigo sobre o chicote de agente de longa duração da Anthropic cobre o lado do chicote interno de um ângulo Claude, e o estudo de caso de clipe de papel sobre orquestração de empresas AI zero-humanas mostra o que acontece quando você empurra o padrão de arnês externo até sua conclusão lógica. Para o lado prático do Codex, minha comparação do Codex Claude Code como um substituto do Cursor mostra onde o Codex realmente supera outros agentes de codificação em 2026.
Uma palavra sobre o próximo passo
Três previsões, classificadas de “Estou confiante” a “Aposto um café”.
Confiante. Dentro de doze meses, toda organização de engenharia séria terá algo no formato Symphony em produção. Pode ser o próprio Symphony, pode ser Gas Town, pode ser Archon, pode ser um invólucro caseiro. A forma - rastreador de problemas como fila, espaço de trabalho isolado por tarefa, sensores determinísticos no circuito, revisão humana no final - é o futuro. O vocabulário já está convergindo. As implementações virão.
Razoavelmente confiante. O gargalo para a maioria das equipes não será o orquestrador. Será o equipamento dentro do agente – as instruções, as habilidades, os manuais, os comandos do sensor. As equipes que já investem na disciplina do estilo CLAUDE.md adotarão o Symphony mais rapidamente do que as equipes que não o fazem, e a lacuna aumentará. (Se você tem ignorado habilidades do agente, agora é a hora de parar.)
Aposte um café. Dentro de seis meses, o Linear enviará suporte nativo ao estilo Symphony e o OpenAI ou um terceiro lançará um tempo de execução hospedado do Symphony que abstrai a parte do devbox. O padrão atual “alugue seu próprio devbox” é operacionalmente pesado demais para ser a resposta de longo prazo.
Mas aqui está o ponto mais profundo. Symphony não é importante porque é o melhor orquestrador. É importante porque nos deu uma especificação compartilhada — um vocabulário que qualquer um pode implementar, bifurcar ou roubar. Esse é o movimento que transforma uma ferramenta em uma categoria.
Volte ao momento que descrevi na abertura – o ingresso Linear de onze minutos que foi enviado sem mim. Esse momento não é impressionante por causa do que um agente fez. É impressionante por causa do que uma especificação compartilhada, executada como um chicote externo, em torno de qualquer chicote interno, em torno de qualquer modelo torna possível em escala.
Se você leu apenas uma coisa hoje, leia Symphony SPEC.md de capa a capa. São doze páginas. Quando terminar, você verá seu fluxo de trabalho AI atual de forma diferente. E essa - não os 500%, nem as 15.000 estrelas - é a mudança real para a qual vale a pena otimizar.
Agora vá atribuir um ingresso real. Aquele que você está adiando. Escreva como uma especificação. Adicione uma definição de concluído. Imagine que um agente que você nunca conheceu vai lê-lo.
Então pergunte a si mesmo: o trabalho seria feito?
Se a resposta for não, o problema nunca foi o agente.
Perguntas frequentes
O que é OpenAI Symphony e como funciona?
Symphony é uma especificação de código aberto do OpenAI que transforma um rastreador de problemas como o Linear em um plano de controle para agentes de codificação autônomos. Ele pesquisa o rastreador a cada 30 segundos, reivindica tickets que correspondem a um rótulo de gatilho, gera uma árvore de trabalho git isolada por ticket, executa um agente Codex ou Claude Code nesse espaço de trabalho até produzir um PR e vincula o PR de volta ao ticket. A implementação de referência está no Elixir, mas a especificação é independente de linguagem. Consulte Configurando Symphony em um repositório real acima para obter o passo a passo completo.
Qual a diferença entre Symphony e Gas Town, Archon e Ralph loops?
Symphony assume um ticket, um agente, um PR — e o rastreador de problemas é a fila. Gas Town administra colônias coordenadas de 20 a 30 agentes paralelos com funções explícitas. Archon cria fluxos de trabalho YAML determinísticos em torno de qualquer agente de codificação com portas de fase explícitas. Ralph loops é o loop interno mínimo viável - while not done: run agent again with latest state. Eles são complementares: um ticket Symphony pode envolver um loop Ralph dentro de seu espaço de trabalho.
A reivindicação de aumento de PR de 500% do OpenAI Symphony se mantém na prática?
A afirmação é real para tickets com escopo restrito em equipes com processos maduros de redação e revisão de especificações – o rendimento de geração aumenta acentuadamente. Mas “PRs obtidos” é uma métrica de geração e a validação não é escalonada da mesma maneira. Em meus próprios testes, vi 3-4x em tickets com escopo bem definido e pior que a linha de base em tickets ambíguos. A leitura honesta: Symphony move o gargalo da codificação para a redação e revisão de especificações.
O que é harness engineering e por que ele é importante para agentes de codificação?
A engenharia de aproveitamento é a disciplina de projetar tudo em torno do modelo que o transforma em um agente confiável - guias (direção de feedforward: prompts, habilidades, manuais) e sensores (validação de feedback: linters, testes, verificadores de tipo, LLM como juiz). O [artigo de Martin Fowler] de Birgitta Böckeler (https://martinfowler.com/articles/harness-engineering.html) é a referência canônica. A estrutura distingue o chicote interno (dentro do agente) do chicote externo (ao redor do agente), e Symphony é diretamente um chicote externo.
Preciso conhecer o Elixir para usar o Symphony?
Não. A implementação do Elixir é uma referência, não um requisito. A especificação é o artefato real, e OpenAI demonstrou que Codex pode reimplementar a especificação em TypeScript, Go, Rust, Java e Python. Se sua equipe já executa uma dessas linguagens, reimplementar o orquestrador é um projeto tratável de fim de semana. Se você se sente confortável com o Elixir ou deseja aprender o básico, a referência sai da caixa.
Vamos trabalhar juntos
Procurando construir sistemas AI, automatizar fluxos de trabalho ou dimensionar sua infraestrutura tecnológica? Eu adoraria ajudar.
- Fiverr (compilações e integrações personalizadas): fiverr.com/s/EgxYmWD
- Portfólio: mejba.me
- Ramlit Limited (soluções empresariais): ramlit.com
- ColorPark (design e marca): colorpark.io
- xCyberSecurity (serviços de segurança): xcybersecurity.io
