NAME
codex-multi-agent-workflows — Codex y flujo de trabajo multiagente: trabaje con agentes sin perder el control
SYNOPSIS
cat codex-multi-agent-workflows.md
DESCRIPTION
La primera vez que un agente de codificación soluciona un error, la reacción es casi siempre la misma: una mezcla de entusiasmo y sospecha. Bien, claro. Pero luego miras la diferencia y te preguntas: "Ok, pero ¿qué tocó exactamente? ¿Puedo confiar en él? ¿Lo volverá a hacer de la misma manera mañana?".
Ahí es donde creo que comienza la parte interesante. No cuando el agente escribe una función, sino cuando se vuelve lo suficientemente capaz de asumir tareas completas de trabajo: leer el repositorio, crear un parche, ejecutar pruebas, abrir un PR, regresar después de un comentario de revisión. Codex se está moviendo precisamente en esa dirección: trabajo en segundo plano, árboles de trabajo separados, navegador integrado, automatizaciones, complementos, memoria y controles de permisos más explícitos.
La cuestión no es imaginar un futuro en el que ya nadie lea códigos. Sería un futuro terrible, además de bastante ingenuo. La cuestión es descubrir cómo trabajar con agentes que puedan hacer mucho sin dejarles hacerlo todo.
El cambio de costumbre
Con el autocompletado tradicional siempre estabas al volante. La IA sugirió una línea, decidiste. Con un agente, sin embargo, la relación cambia: le das una meta y él sigue varios pasos por su cuenta.
Esto es poderoso, pero cambia el problema. La pregunta ya no es simplemente "¿puede el modelo programar?". La pregunta es:
- ¿Le di un alcance lo suficientemente pequeño?
- ¿Sabes cómo comprobar el resultado?
- ¿Estoy trabajando en un entorno aislado?
- ¿La revisión final sigue siendo humana y cuidadosa?
Un flujo de trabajo saludable se parece más a esto que a una varita mágica:
Suena menos romántico que "el agente construye todo", pero funciona mucho mejor. Y también es así como trabajan los equipos que son buenos con los humanos: tareas claras, retroalimentación rápida, responsabilidad explícita.
El buen aviso es casi un buen boleto.
El mensaje más peligroso es vago pero seguro: "arreglar la página de facturas", "mejorar la arquitectura", "limpiar el módulo de autenticación". Estas son solicitudes que suenan productivas y generan enormes diferencias. Pero luego te encuentras haciendo arqueología.
Un mensaje útil es más aburrido. Por ejemplo: implementar exportación CSV para la página de facturas, sabiendo que la tabla está en app/(dashboard)/invoices/page.tsx, las consultas están en src/server/invoices.ts y ya existe un patrón similar en app/(dashboard)/reports.
Luego agregue restricciones claras: no cambie el esquema de la base de datos, no agregue dependencias si una pequeña utilidad es suficiente, mantenga el estilo de interfaz de usuario existente. Y cerrar con la verificación: npm test -- invoices y npm run build.
Este tipo de informe no pretende "explicarle mejor a la IA". Sirve sobre todo para dejarte más claro lo que estás delegando. Si no puedes escribirlo de manera concreta, tal vez la tarea aún no esté lista para un agente.
Tres trabajos que delego de buen grado
El primero es un trabajo repetitivo pero verificable: agregar pruebas, migrar llamadas a una nueva API interna, actualizar importaciones, reemplazar componentes obsoletos, corregir errores de TypeScript. Aquí el agente puede ahorrar horas y el riesgo es controlable.
El segundo es un trabajo exploratorio: "buscar dónde se calcula este total", "explícame por qué esta prueba es frágil", "reproduce el error y dime qué archivos parecen estar afectados". Incluso cuando no produce un parche de inmediato, puede realizar un reconocimiento útil.
El tercero es el trabajo de mantenimiento recurrente: pequeñas actualizaciones de dependencias, limpieza de indicadores de funciones antiguas, resumen de PR bloqueados, verificación de TODO olvidados. No es glamoroso, pero es exactamente el tipo de trabajo que tiende a acumularse.
Tres trabajos que mantengo humanos
Las decisiones sobre productos siguen siendo humanas. Si un cambio cambia la forma en que un usuario paga, elimina datos, ve precios o comprende un permiso, quiero una persona responsable.
Los límites de seguridad también merecen atención humana: autenticación, roles, tokens, registro de datos confidenciales, migraciones de bases de datos. Un agente puede ayudar a implementar, pero no tiene por qué ser el único que toma las decisiones.
Finalmente, mantengo todo lo que requiere el gusto arquitectónico humano. Un agente puede proponer una refactorización, pero comprender si una abstracción es realmente necesaria o si simplemente estamos puliendo un problema inexistente sigue siendo un trabajo.
La revisión no es opcional.
La tentación, cuando un agente es bueno, es confiar en el verde de la IC. Es comprensible. También es cuando empiezan los problemas.
Siempre miro al menos cinco cosas:
- ¿El parche sólo resuelve la tarea solicitada?
- ¿Tocó archivos que no tenían nada que ver con eso?
- ¿Las pruebas cubren comportamientos novedosos o simplemente una feliz casualidad?
- ¿El código sigue patrones locales?
- ¿Se manejan los errores como en el resto del proyecto?
Cuando algo anda mal, la retroalimentación debe ser específica. "Arreglarlo" es una pereza. Mejor: esta utilidad duplica parseMoney en src/lib/money.ts; reutilice esa función, agregue una prueba para el caso EUR y no cambie la API pública del módulo de facturación.
Los agentes responden mucho mejor a comentarios pequeños y verificables. Curiosamente, la gente también.
Barandillas que valen la pena
Si un agente puede leer archivos, escribir código y ejecutar comandos, debe tratarse como un proceso poderoso. No hay necesidad de paranoia, necesitas higiene.
Utilice árboles de trabajo o ramas separados. De modo que puede comparar las diferencias, descartar experimentos fallidos y no mezclar el trabajo del agente con lo que estaba haciendo.
Limitar permisos. Comandos como rg, git diff, npm test y npm run build pueden ser bastante gratuitos. Las implementaciones, las migraciones de bases de datos, el acceso a secretos y los comandos destructivos deben permanecer explícitos.
Reduzca el acceso a la red cuando no lo necesite. Para muchas tareas, la documentación oficial, el registro de paquetes y servicios internos específicos son suficientes. Menos superficie, menos sorpresas.
Seguimiento de acciones. Cuando llega un parche para revisión, debería poder reconstruir las indicaciones, los comandos ejecutados, las pruebas aprobadas y los archivos modificados. No para crear burocracia, sino para poder entender qué pasa si algo sale mal.
Una forma fácil de empezar como equipo
Si tuviera que introducir agentes en un equipo pequeño, empezaría sin grandes revoluciones.
Crearía una etiqueta agent-ready para problemas con un alcance claro. Agregaría una plantilla con contexto, restricciones y comandos de verificación. Solicitaría relaciones públicas pequeñas, idealmente de unos pocos cientos de líneas. Necesitaría pruebas o capturas de pantalla para detectar cambios visibles. Y sobre todo mantendría a una persona responsable de la fusión.
Después de dos semanas, miraba los datos: qué tareas se aceleraron realmente, qué revisiones eran intensas, qué indicaciones eran confusas, qué partes del código base son demasiado frágiles para delegar.
Es un planteamiento menos espectacular que "a partir de hoy haremos todo con los agentes", pero es el que permite llegar a la tercera semana sin remordimientos.
La parte más humana.
Lo curioso es que cuanto más autónomos se vuelven los agentes, más importantes vuelven a ser las habilidades clásicas: escribir un buen ticket, hacer pequeños cortes, crear pruebas, leer diferencias, comunicar compensaciones. El agente acelera a quienes ya saben trabajar bien. También amplifica el caos de quienes delegan mal.
Entonces no, no veo los flujos de trabajo de múltiples agentes como un atajo para dejar de hacer ingeniería. Los veo como una forma de trasladar más energía a las partes que importan: decidir qué construir, asegurarse de que funcione y mantener el sistema comprensible.
Los agentes pueden ser excelentes colegas asincrónicos. Pero un colega asincrónico, para ser útil, necesita contexto, límites y revisión. Como todos los demás.
Fuentes útiles
METADATA
- date: 2026-05-24
- reading: 7 min
- author: Filippo Spinella
- tags: AI, Developer Tools, Productivity, Software Engineering