OpenAI Symphony: El coding agent orchestrator probado
La primera vez que Symphony recogió uno de mis tickets Linear y envió una solicitud de extracción funcional sin que yo tocara un teclado, me senté allí durante un minuto completo tratando de descubrir qué se suponía que debía hacer a continuación.
Mi ticket decía: "Agregar middleware de limitación de velocidad a los puntos finales públicos API, predeterminado 60 req/min, permitir anulaciones por ruta". Lo moví a "En progreso" por costumbre, encendí el devbox Symphony y cambié de pestaña para responder a un mensaje de Slack. Once minutos más tarde existía un borrador de relaciones públicas. El agente creó un espacio de trabajo aislado, leyó mi código base, escribió el middleware, agregó anulaciones a nivel de ruta, escribió tres pruebas e impulsó una rama. La diferencia no fue perfecta (rechacé una prueba y ajusté un comentario), pero el trabajo fue real. El trabajo estaba hecho.
Ese ticket fue el momento en que el agente orquestador OpenAI Symphony dejó de ser una demostración para mí y comenzó a ser una herramienta. También me obligó a enfrentar algo incómodo: la forma en que había estado usando Codex y Claude Code durante el último año (un terminal, un mensaje a la vez, un ser humano cuidando a un agente) estaba a punto de parecer tan obsoleto como SSH en un solo servidor para implementar una aplicación web en 2014.
Esta es la publicación que desearía que alguien me hubiera entregado antes de pasar dos fines de semana reconfigurando mi forma de pensar sobre la infraestructura de los agentes. Te mostraré qué es realmente Symphony (es más pequeño y extraño de lo que implican los comunicados de prensa), cómo encaja en el patrón más amplio que la gente llama "harness engineering", qué rompí cuando intenté doblarlo a mi propia pila y el único cambio mental que hizo que todo encajara.
Un aviso antes de continuar: hay un número que se está transmitiendo: la afirmación de OpenAI de que algunos equipos internos vieron un aumento del 500 % en las solicitudes de extracción realizadas dentro de las tres semanas posteriores a la adopción de Symphony (OpenAI). Volveré a ese número más adelante en esta publicación, porque la forma en que lo leas determina si construyes lo correcto o lo incorrecto.
Qué es realmente OpenAI Symphony (y qué no es)
Permítanme eliminar un concepto erróneo desde el principio: Symphony no es un producto. No es un SaaS. No es un binario cerrado. No hay ningún panel en el que iniciar sesión.
Symphony es un archivo SPEC.md. Ese es todo el artefacto central. OpenAI lo abrió bajo Apache 2.0 el 5 de marzo de 2026 y, a finales de abril de 2026, el repositorio openai/symphony GitHub había superado 15 000 estrellas (Help Net Security). La especificación describe, en lenguaje sencillo, con diagramas de estado, cómo un orquestador de larga duración debería convertir un rastreador de problemas en un plano de control para agentes de codificación autónomos.
La implementación de referencia se envía en Elixir. Sí, Elixir. El mismo idioma que usan Discord y WhatsApp bajo el capó. OpenAI lo eligió porque BEAM (el tiempo de ejecución de Elixir) le brinda árboles de supervisión, procesos livianos y semántica de recuperación de fallas de forma gratuita: exactamente lo que desea cuando ejecuta diez o veinte agentes de codificación que pueden tomar veinte minutos cada uno por tarea y cualquiera de los cuales podría morir silenciosamente.
Pero aquí está la parte que me sorprendió. El equipo de OpenAI hizo que Codex generara la implementación de Elixir de una sola vez a partir de la especificación y luego le pidió a Codex que volviera a implementar la misma especificación en TypeScript, Go, Rust, Java y Python, utilizando cada implementación como una función forzada para encontrar ambigüedades en la especificación misma (InfoWorld). La especificación es el producto. El código de Elixir es sólo el ejemplo más pulido.
Eso es importante porque te dice qué tipo de herramienta estás evaluando realmente. Symphony no es "el marco de orquestación de OpenAI". Es un vocabulario compartido sobre cómo se ve una buena orquestación de agentes de codificación, con una referencia funcional que puede ejecutar tal como está o copiarla.
El bucle central, en un párrafo
Symphony sondea a Linear cada 30 segundos. Cuando ve que un ticket pasa a un estado configurado "listo", reclama ese ticket, activa un espacio de trabajo aislado (un árbol de trabajo git nuevo en un devbox), inicia un agente Codex en ese espacio de trabajo con un mensaje estructurado que incluye el cuerpo del ticket, permite que el agente se ejecute continuamente hasta que produzca un PR o falla, y luego marca el ticket como "listo para revisión" o "bloqueado" con un motivo. La simultaneidad predeterminada es 10 agentes. El estado está en memoria en un GenServer; al reiniciar, simplemente se reconstruye desde Linear, por lo que no hay ninguna base de datos para operar (allthings.how).
Eso es todo. Eso es todo. Lea ese párrafo nuevamente, porque la simplicidad es el punto.
Por qué el revuelo me tomó por sorpresa
Seré honesto. Cuando llegó la publicación del blog OpenAI a principios de marzo, la hojeé a medias y seguí adelante. "Otro agente orquestador", fue el pensamiento cínico. Ya había jugado con Steve Yegge's Gas Town, había estado ejecutando Archon en un proyecto paralelo durante tres semanas y había construido mi propio arnés Claude Code de larga duración para un cliente. Ninguna de esas herramientas necesitaba un cuarto competidor.
Lo que me perdí, lo que la mayoría de la cobertura pasó por alto, es que Symphony realmente no está compitiendo con esas herramientas. Está compitiendo con la versión tuya que abre una terminal, escribe codex o claude y observa a un agente trabajar en una tarea. Está compitiendo con la supervisión manual en sí. Una vez que entendí eso, toda mi semana cambió.
Para explicar por qué, necesito desviarme hacia el término que silenciosamente se ha convertido en el concepto más importante en la entrega de software asistida por AI este año: harness engineering.
Harness Engineering: El vocabulario que hizo que todo hiciera clic
En abril de 2026, Birgitta Böckeler, líder global de Thoughtworks para la entrega de software asistida por AI, publicó un artículo largo y cuidadoso en martinfowler.com titulado "Ingeniería de aprovechamiento para usuarios de agentes de codificación". Es el artículo que nos dio la taxonomía canónica. (El resumen del vídeo con el que trabajé representaba fonéticamente su nombre como "Vetta Berkeler": la misma persona, el mismo marco).
El encuadre es engañosamente simple:
Agente = Modelo + Arnés
El modelo es el LLM. Todo lo demás (las indicaciones, las herramientas, la zona de pruebas, el bucle, los validadores, el orquestador) es el arnés. Y una vez que empieces a nombrar las piezas del arnés, podrás empezar a diseñarlas deliberadamente en lugar de accidentalmente.
Böckeler divide el arnés en dos capas y Symphony vive de lleno en una de ellas.
Arnés interior: qué hay dentro del agente
El arnés interno es el código y las capacidades que se envían dentro del propio agente. Cuando ejecuta Claude Code, obtiene el arnés interno de forma gratuita: el protocolo de llamada de herramientas, las herramientas de lectura de archivos y ejecución de shell, las indicaciones de planificación, la generación de subagentes, las puertas de permiso, el sistema de enlaces, las habilidades que puede instalar. Lo mismo con Codex. Lo mismo con el cursor.
Normalmente no escribes el arnés interior. Tú lo configuras. Habilitas los ganchos. Instalas habilidades. Escribe un CLAUDE.md o AGENTS.md. Usted establece permisos en settings.json. El arnés interior es lo que convierte a un modelo en un agente codificador.
Arnés exterior: lo que rodea al agente
El arnés externo es todo fuera del agente que controla su ciclo de vida, administra su contexto, decide cuándo se ejecuta, en qué se ejecuta, qué se considera "hecho" y qué sucede cuando falla. Aquí es donde vive Symphony. Aquí es donde también viven Gas Town, Archon y Ralph loops.
El arnés externo es lo que convierte una sesión terminal de Claude Code en una flota de veinte agentes paralelos en los que realmente confía.
Esta es la imagen mental que dibujo en una pizarra cuando les explico esto a los 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. │ │ │
│ │ └────────────────────────┘ │ │
│ └──────────────────────────────────┘ │
└──────────────────────────────────────────┘
Una vez que vea las capas, cada "producto del agente AI" encaja en una posición en esta imagen. Y una vez que eso sucede, la pregunta real deja de ser "¿qué agente debo usar?" y se convierte en "¿qué necesita hacer mi arnés exterior que nadie más pueda hacer?"
Esa es la pregunta que Symphony te obliga a responder.
Guides y Sensors: las dos palancas en cada arnés
Dentro de ambas capas, Böckeler introduce otra distinción en la que ahora pienso cada vez que escribo un mensaje de agente o configuro un paso de CI. Cada pieza significativa de un arnés realiza una de dos funciones.
Guides dirige el agente antes de que actúe. Son control anticipado. Tu CLAUDE.md. Las habilidades que instalas. El libro de jugadas que pegas en el mensaje. El ejemplo te compromete a hacer referencia. La decisión de arquitectura registra las lecturas del agente antes de escribir el código. Guides aumenta la probabilidad de que el agente acierte en el primer intento.
Sensors observe al agente después de que actúa y decida si lo que produjo es aceptable. Son control de retroalimentación. Sensors viene en dos versiones:
- Sensores computacionales: deterministas, rápidos y económicos. Linters. Escriba damas. Pruebas unitarias. Validadores de esquemas. Construir resultados. Se ejecutan en milisegundos a segundos y le dan una respuesta binaria (Martin Fowler).
- Sensores inferenciales: no deterministas, lentos y caros. Revisiones del código de LLM como juez. Comprobaciones de similitud semántica. Críticas de estilo. Se ejecutan en una GPU, tardan de segundos a minutos y le brindan respuestas probabilísticas.
Esta es la parte que me llevó vergonzosamente mucho tiempo interiorizar: la mayoría de los equipos con los que he trabajado utilizan sensores computacionales infrautilizados y dependen demasiado de los inferenciales. Configurarán un "revisor AI" antes de configurar eslint --max-warnings 0 en un gancho de confirmación previa. Tendrán una cobertura de prueba de calificación de LLM como juez antes de agregar un umbral de cobertura a CI.
Los sensores computacionales son básicamente gratuitos. Están comprobados. Llevan quince años funcionando en tuberías de CI. La razón por la que se omiten en los flujos de trabajo de los agentes es que los profesionales olvidan que el agente puede leer su salida y autocorregirla. En el momento en que conecta npm test al bucle del agente y alimenta las fallas como contexto, su tasa de error cae en un factor que realmente no puedo estimar sin mentir. Es mucho.
Volveré a esto cuando les muestre cómo se ve un archivo de flujo de trabajo Symphony real, porque guías y sensores es todo el vocabulario que se utiliza para crear uno. Por ahora, quédese con esto: un arnés es un conjunto de guías y sensores cuidadosamente elegidos y dispuestos alrededor de un modelo. El orquestador es justo lo que hace funcionar el arnés en una cola.
Dónde encaja Symphony en la familia de arneses exteriores
Symphony no es el único arnés exterior disponible y no siempre es la respuesta correcta. Permítanme repasar los cuatro que he utilizado en el trabajo de producción este año, porque las compensaciones son importantes.
1. Symphony: Orquestación nativa del seguimiento de problemas
La elección definitoria de Symphony es que el rastreador de problemas es la cola. Los tickets Linear son las unidades de trabajo. No hay una interfaz de usuario Symphony separada para administrar. Mueve un ticket a "Listo para Codex", Symphony lo recoge, un agente lo ejecuta, aparece un PR vinculado al ticket y usted revisa el ticket como siempre lo hizo. La sobrecarga cognitiva de adoptarlo es aproximadamente nula, porque no estás aprendiendo una nueva herramienta de gestión de proyectos.
La desventaja es que la superficie de Symphony es pequeña. Hace una cosa: convertir los billetes en tiradas, y lo hace bien. Si su trabajo no encaja en tickets discretos (investigación de larga duración, refactorizaciones de varias semanas, picos exploratorios), Symphony no es su herramienta.
2. Gas Town: colonias de agentes múltiples, estilo Steve Yegge
Gas Town es el marco de trabajo de Steve Yegge para ejecutar entre 20 y 30 agentes Claude Code paralelos organizados en roles (los alcaldes organizan, los turones ejecutan), con el estado persistido en Git a través de la pila MEOW (Cloud Native Now). Mientras que Symphony supone "un ticket, un agente, un PR", Gas Town supone enjambres coordinados trabajando en trabajos relacionados con transferencias explícitas.
Cubrí el patrón de "estilo enjambre" con más detalle en mi escrito sobre arquitectura de enjambre de agentes Claude Code: si está creando algo en el que varios agentes necesitan coordinarse en la misma tarea en lugar de tareas paralelas, esa es la publicación que debe leer después de esta.
3. Archon: flujos de trabajo deterministas en torno a cualquier agente de codificación
Archon se anuncia a sí mismo como "el primer constructor de arneses de código abierto": el encuadre es exacto. Mientras que Symphony codifica el flujo de trabajo (encuesta Linear → ejecutar agente → PR), Archon le permite crear el flujo de trabajo como una canalización YAML con fases explícitas, puertas de validación y artefactos. Cada ejecución tiene su propio árbol de trabajo de git. Puede ejecutar cinco correcciones en paralelo sin conflictos (MindStudio).
Recurro a Archon cuando el trabajo tiene fases conocidas ("investigar, planificar, implementar, probar, documentar") y quiero que cada fase sea un paso validado por separado en lugar de una ejecución larga del agente. Este también es el primo más cercano a los enfoques spec-driven como el que escribí en mi [pieza spec-driven AI en modo Traycer BART] (/traycer-bart-mode-spec-driven-ai/).
4. Bucles Ralph: el arnés exterior mínimo viable
El bucle Ralph Wiggum (sí, llamado así por el personaje de Los Simpson: "¡Estoy ayudando!") es el arnés externo más simple posible: un bucle while true que vuelve a invocar al agente hasta que pasa una verificación determinista. Hay un complemento Anthropic oficial en el repositorio Claude Code y Vercel Labs envía ralph-loop-agent para el SDK AI.
La filosofía Ralph: no busques la perfección en el primer intento. Deja que el bucle se refine. El agente lee un archivo de plan, avanza, el bucle verifica la finalización según los criterios y, si no se realiza, el agente se ejecuta nuevamente con el estado más reciente (beuke.org).
Ralph no es competitivo con Symphony: es complementario. Un ticket Symphony puede ejecutar un bucle Ralph dentro de su espacio de trabajo. Symphony maneja la cola y el aislamiento. Ralph maneja la iteración hasta que sea correcta. Conéctalos y tendrás algo realmente poderoso.
Configuración de Symphony en un repositorio real
Basta de teoría. Permítanme mostrarles exactamente lo que hice para ejecutar Symphony en un proyecto paralelo la semana pasada. Todo me llevó unos 90 minutos desde git clone hasta el primer PR, y la mayor parte fue la configuración de Linear, no Symphony en sí.
Paso 1: Obtenga la clave Linear API
En Linear, vaya a Configuración → Seguridad y acceso → Claves personales API y cree una nueva clave. Configúrelo como LINEAR_API_KEY en su entorno. Symphony usa este token a través de su herramienta dinámica linear_graphql; no expone el token sin formato a subagentes, lo cual es una opción de seguridad pequeña pero reflexiva (allthings.how).
Paso 2: clonar el repositorio y elegir una implementación
git clone https://github.com/openai/symphony.git
cd symphony
El repositorio tiene la especificación en SPEC.md y la referencia de Elixir en elixir/. Si tiene Elixir instalado (brew install elixir en macOS), podrá ejecutarlo en dos minutos. Si no lo hace, la simplicidad de la especificación significa reescribir el orquestador en un lenguaje que usted sabe que es genuinamente manejable; ese es el objetivo de distribuir una especificación en lugar de un binario.
Durante el resto de este tutorial mostraré la ruta de Elixir porque es la que usé.
cd elixir
mix deps.get
mix compile
Paso 3: Configure su flujo de trabajo
Copie la plantilla WORKFLOW.md en el repositorio de destino (aquel en el que desea que trabajen los agentes, no el repositorio Symphony en sí). Aquí es donde el vocabulario del arnés vale la pena, porque WORKFLOW.md es esencialmente su especificación de guía y sensor para cada ejecución de agente. Una versión recortada mía se veía así:
## Antes de empezar
- Leer README.md y ARQUITECTURA.md
- Ejecute `npm install` y `npm test` para confirmar los pases de referencia
## Implementación
- Realizar el cambio más pequeño que satisfaga el ticket
- Agregar o actualizar pruebas para cualquier comportamiento nuevo.
- Ejecute `npm test` y `npm run lint` antes de dar por hecho.
- Ejecute `npm run typecheck`: no se requieren errores
## Definición de hecho
- Todas las pruebas pasan localmente.
- Pase de pelusa y verificación de tipo sin advertencias
- El título de relaciones públicas coincide con el título del boleto.
- La descripción de PR hace referencia al ID del 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_tu_clave_aquí
SYMPHONY_TARGET_REPO=/Users/you/code/your-project
SYMPHONY_LINEAR_TEAM_ID=tu_id_de_equipo
SYMPHONY_TRIGGER_LABEL=listo para el 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
ejecución de mezcla: sin detener
Esa es la configuración completa. Symphony ahora sondea Linear cada 30 segundos. Etiqueta cualquier ticket con ready-for-codex y un agente lo reclamará.
La primera vez que hice esto, creé un ticket deliberadamente pequeño: "Agregar un punto final /health que devuelva { status: 'ok', uptime_seconds: <number> }" y lo miré. El agente lo recogió en 31 segundos. Leyó el código base. Encontró mi aplicación Express. Escribió la ruta, escribió una prueba, ejecutó la prueba (que pasó en el segundo intento después de solucionar un pequeño problema de inferencia de TypeScript), abrió un PR y etiquetó el ticket Linear como "revisión necesaria". Tiempo total de pared: 4 minutos 18 segundos. Leí la diferencia. Me fusioné.
Me senté allí y miré la pantalla.
En qué me equivoqué en el camino
Quiero dedicar tiempo real a esta sección porque es donde aprendí más y porque cada artículo de "primer vistazo" que he leído en Symphony lo pasa por alto. Cometí cuatro errores que vale la pena contarles.
Error 1: Traté a Symphony como a Claude Code
Durante los primeros dos días seguí abriendo el terminal devbox Symphony esperando hablar con los agentes en ejecución. Symphony no funciona de esa manera. Los agentes están sin cabeza. Te comunicas con ellos a través de tickets. Si desea darle más contexto a un agente, edite la descripción del ticket Linear (o agregue un comentario) y deje que el siguiente ciclo de sondeo recoja el cambio. Si desea redirigir a un agente en pleno vuelo, la respuesta en el 90% de los casos es no: finalice la ejecución, edite el ticket y deje que comience de nuevo.
Este fue un cambio mental. Me tomó un par de días dejar de tratar a los agentes como colaboradores con los que estaba programando y comenzar a tratarlos como trabajadores a los que les estaba emitiendo boletos. Ese cambio, por cierto, es exactamente lo que el diseño de Symphony está tratando de imponerle. Diseñe sus tickets como especificaciones de producto, no como mensajes de Slack.
Error 2: Escribí entradas vagas
Mis primeras entradas eran el mismo tipo de frases ingeniosas que le daría a un compañero de equipo senior: "Refactorice el middleware de autenticación". Un compañero de equipo senior llena los vacíos con un contexto compartido. Un agente no. Cuando escribí "Refactorice el middleware de autenticación para extraer la validación JWT en una función separada, mantenga el API público existente de requireAuth(req, res, next), agregue pruebas para la función extraída y no cambie los registros de ruta", el agente envió un PR limpio en la primera ejecución.
El principio: cada ambigüedad en su ticket se convierte en un lanzamiento de moneda en el comportamiento de su agente. Los boletos son guías. Cuanto más cargue la guía al frente, menos necesitará los sensores para rechazar resultados incorrectos.
Error 3: Me salté el Sensors computacional
Mi repositorio de destino tenía npm test y npm run lint, pero no los había agregado a la definición de WORKFLOW.md de hecho. Técnicamente, el agente realizó pruebas cuando le pareció necesario. Aproximadamente uno de cada tres RP tuvo pruebas fallidas al llegar, de las que tuve que recuperarme. La solución consistió en treinta segundos de edición de WORKFLOW.md para que los comandos del sensor no fueran negociables. La tasa de fallas se redujo a aproximadamente uno de cada quince, en línea con lo que veo cuando ejecuto Codex manualmente.
No creerá la frecuencia con la que la respuesta es "agregue una verificación determinista a su archivo de flujo de trabajo".
Error 4: Intenté ejecutar Symphony sin aislamiento del árbol de trabajo
Por pereza, señalé dos ejecuciones paralelas en la misma caja del mismo repositorio. Masacre predecible. El diseño de Symphony supone (y la referencia de Elixir aplica) el aislamiento del árbol de trabajo de git por ticket. No luches contra eso. Cada agente recibe su propia copia de trabajo. Así es como cinco agentes que tocan diferentes partes de su código base no terminan pisoteando el WIP de cada uno.
Aquí es también donde el diseño de Symphony comienza a parecerse mucho al enfoque de Archon de que "cada ejecución de flujo de trabajo tiene su propio árbol de trabajo git". La convergencia no es un accidente. Worktree-per-run se está convirtiendo en la convención de carga de todos los arneses exteriores serios.
Si prefiere entregar este tipo de configuración a alguien que lo haya hecho antes, Ramlit Limited construye y opera exactamente estos canales de orquestación para equipos de ingeniería que desean el rendimiento sin la curva de aprendizaje de ocho fines de semana. Pero el camino es realmente transitable por uno mismo; eso es la mayor parte de lo que intento mostrarles aquí.
¿Cómo se debe leer el número del 500%?
Te dije antes que volvería a esto. La métrica principal de OpenAI es que algunos equipos internos vieron un aumento del 500 % en las solicitudes de extracción realizadas en las primeras tres semanas de uso de Symphony (OpenAI).
Aquí está la lectura honesta.
Ese número es real, en sentido estricto. El rendimiento de las relaciones públicas aumentó. Esto es mensurable, repetible y no está en discusión. Pero las "RP obtenidas" son una métrica de generación y, como han señalado varios analistas, la generación aumenta sin esfuerzo. La validación no. (opentools.ai).
En mi propia (pequeña) muestra de más de tres semanas de trabajo en proyectos paralelos con Symphony, mi rendimiento de relaciones públicas aumentó entre 3 y 4 veces en los tipos de tickets en los que Symphony es bueno: con buen alcance, de función única y con cobertura de prueba. En tickets ambiguos, el rendimiento fue peor que yo con el código Claude, porque cada lanzamiento de moneda en la especificación se agravaba.
El modelo mental que he elegido: Symphony mueve el cuello de botella de "escribir el código" a "escribir la especificación y revisar el PR". Esto supone un aumento real de la productividad si y sólo si su proceso de redacción y revisión de especificaciones puede mantenerse al día. Si la revisión se convierte en el cuello de botella y usted comienza a aprobar relaciones públicas para despejar la cola, usted mismo ha diseñado una forma más rápida de producir deuda técnica.
Entonces, cuando vea "500%", tradúzcalo a: "este equipo tenía procesos de redacción y revisión de especificaciones lo suficientemente maduros como para que en realidad se pudiera enviar cinco veces más código". Esa es la pregunta que debe hacerse antes de adoptar Symphony, no "¿puedo ejecutar más agentes?" pero "¿puedo revisar la producción de más agentes sin que la calidad colapse?"
Qué significa esto para cómo estoy construyendo ahora
La semana después de ejecutar Symphony, reescribí la forma en que estructuro el trabajo en el proyecto de mi cliente principal. Tres cambios concretos.
Primero: cada número que abro ahora termina con una sección "Definición de hecho". No porque Symphony lo retome (el proyecto del cliente aún no ejecuta Symphony), sino porque escribir tickets en esa forma es ahora mi punto de partida. La disciplina que exige un agente de codificación es la misma disciplina de la que se beneficia un ingeniero junior.
Dos: agregué npm test, npm run lint y npm run typecheck como pasos obligatorios en los archivos de flujo de trabajo de mi agente en todas partes. Sin excepciones. Los sensores computacionales son gratuitos. Úselos.
Tres: dejé de distinguir entre "herramientas AI que uso" e "infraestructura AI que ejecuto". Esa distinción está muerta. Codex, Claude Code, Cursor: estos son arneses internos. Se sientan dentro de algo. La pregunta es cómo se ve ese algo. El mío se parecerá cada vez más a Symphony más un bucle interno estilo Ralph con sensores computacionales. El tuyo podría verse diferente. Pero va a ser algo.
Si desea una lectura más profunda sobre el cambio más amplio hacia el agente como infraestructura, mi artículo sobre el arnés de agentes de larga duración de Anthropic cubre el lado del arnés interno desde un ángulo Claude, y el estudio de caso de Paperclip sobre la orquestación de empresas AI sin humanos muestra lo que sucede cuando lleve el patrón del arnés exterior a su conclusión lógica. Para el lado práctico de Codex, mi comparación de Codex Claude Code como reemplazo del cursor establece dónde Codex realmente supera a otros agentes de codificación en 2026.
Unas palabras sobre hacia dónde va esto a continuación
Tres predicciones, clasificadas desde "Tengo confianza" hasta "Apuesto a un café".
Confiado. Dentro de doce meses, todas las organizaciones de ingeniería serias tendrán algo con forma de Symphony en producción. Podría ser el propio Symphony, podría ser Gas Town, podría ser Archon, podría ser un envoltorio de cosecha propia. La forma (rastreador de problemas como cola, espacio de trabajo aislado por tarea, sensores deterministas en el circuito, revisión humana al final) es el futuro. El vocabulario ya está convergiendo. Las implementaciones seguirán.
Razonablemente confiado. El cuello de botella para la mayoría de los equipos no será el orquestador. Será el arnés dentro del agente: las indicaciones, las habilidades, los manuales, los comandos de los sensores. Los equipos que ya invierten en la disciplina estilo CLAUDE.md adoptarán Symphony más rápido que los equipos que no lo hacen, y la brecha se ampliará. (Si ha estado ignorando habilidades del agente, ahora es el momento de detenerse).
Apueste un café. Dentro de seis meses, Linear ofrecerá soporte nativo estilo Symphony y OpenAI o un tercero lanzará un tiempo de ejecución alojado de Symphony que abstrae la parte devbox. El patrón actual de "alquilar su propio devbox" es demasiado pesado desde el punto de vista operativo para ser la respuesta a largo plazo.
Pero aquí está el punto más profundo. Symphony no es importante porque es el mejor orquestador. Es importante porque nos dio una especificación compartida: un vocabulario que cualquiera puede implementar, bifurcar o robar. Ese es el movimiento que convierte una herramienta en una categoría.
Vuelva al momento que describí al principio: el ticket Linear de once minutos que se envió sin mí. Ese momento no es impresionante por lo que hizo un agente. Es impresionante por lo que una especificación compartida, ejecutada como un arnés externo, alrededor de cualquier arnés interno, alrededor de cualquier modelo hace posible a escala.
Si hoy lee solo una cosa, lea Symphony SPEC.md de principio a fin. Son doce páginas. Cuando lo termine, verá su flujo de trabajo actual AI de manera diferente. Y ese (no el 500%, ni las 15.000 estrellas) es el cambio real que vale la pena optimizar.
Ahora ve y asígnate un boleto real. El que has estado posponiendo. Escríbalo como una especificación. Agregue una definición de hecho. Imagine que un agente que nunca ha conocido lo va a leer.
Luego pregúntese: ¿se haría el trabajo?
Si la respuesta es no, el problema nunca fue el agente.
Preguntas frecuentes
¿Qué es OpenAI Symphony y cómo funciona?
Symphony es una especificación de código abierto de OpenAI que convierte un rastreador de problemas como Linear en un plano de control para agentes de codificación autónomos. Sondea el rastreador cada 30 segundos, reclama tickets que coinciden con una etiqueta de activación, activa un árbol de trabajo git aislado por ticket, ejecuta un agente Codex o Claude Code en ese espacio de trabajo hasta que produce un PR y vincula el PR nuevamente al ticket. La implementación de referencia está en Elixir, pero la especificación es independiente del idioma. Consulte Configuración de Symphony en un repositorio real más arriba para obtener el tutorial completo.
¿En qué se diferencia Symphony de Gas Town, Archon y Ralph loops?
Symphony supone un ticket, un agente, un PR, y el rastreador de problemas es la cola. Gas Town dirige colonias coordinadas de entre 20 y 30 agentes paralelos con roles explícitos. Archon crea flujos de trabajo YAML deterministas en torno a cualquier agente de codificación con puertas de fase explícitas. Ralph loops son el bucle interno mínimo viable: while not done: run agent again with latest state. Son complementarios: un ticket Symphony puede envolver un bucle Ralph dentro de su espacio de trabajo.
¿Se sostiene en la práctica la afirmación de aumento del 500 % de relaciones públicas de OpenAI Symphony?
La afirmación es real para tickets de alcance limitado en equipos con procesos maduros de redacción y revisión de especificaciones: el rendimiento de generación aumenta considerablemente. Pero las "RP obtenidas" son una métrica de generación y la validación no se escala de la misma manera. En mis propias pruebas, vi entre 3 y 4 veces los tickets con un alcance bien definido y peores que los valores iniciales en los ambiguos. La lectura honesta: Symphony traslada el cuello de botella de la codificación a la redacción de especificaciones y la revisión.
¿Qué es harness engineering y por qué es importante para los agentes codificadores?
La ingeniería de arneses es la disciplina de diseñar todo lo relacionado con el modelo que lo convierte en un agente confiable: guías (dirección anticipada: indicaciones, habilidades, manuales) y sensores (validación de retroalimentación: linters, pruebas, verificadores de tipo, LLM como juez). El [artículo de Martin Fowler] de Birgitta Böckeler (https://martinfowler.com/articles/harness-engineering.html) es la referencia canónica. El marco distingue el arnés interior (dentro del agente) del arnés exterior (alrededor del agente), y Symphony es directamente un arnés exterior.
¿Necesito conocer Elixir para usar Symphony?
No. La implementación de Elixir es una referencia, no un requisito. La especificación es el artefacto real y OpenAI demostró que Codex puede volver a implementar la especificación en TypeScript, Go, Rust, Java y Python. Si su equipo ya utiliza uno de esos idiomas, reimplementar el orquestador es un proyecto de fin de semana manejable. Si se siente cómodo con Elixir o está dispuesto a aprender los conceptos básicos, la referencia está lista para usar.
Trabajemos juntos
¿Quiere crear sistemas AI, automatizar flujos de trabajo o ampliar su infraestructura tecnológica? Me encantaría ayudar.
- Fiverr (compilaciones e integraciones personalizadas): fiverr.com/s/EgxYmWD
- Cartera: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y marca): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
