PulseFlow Tecnologia
← Insights
·6 min de lectura·framework-playbook·adopcion-de-agentes·coding-agents·ingenieria-de-software
PulseFlow Tecnologia

Un playbook para adoptar agentes de IA en ingeniería de software

La mayoría de los equipos no falla al elegir el agente de código equivocado - falla al saltar directo a "poner un agente a trabajar" sin antes diseñar el flujo en el que va a operar. Dos casos reales muestran los dos extremos de ese espectro: el GitHub Copilot coding agent, pensado para operar dentro del flujo de PR ya existente de cualquier equipo, y el experimento de harness engineering de OpenAI, en el que un repositorio entero (~1 millón de líneas, 1.500+ PRs) fue construido solo por agentes. La mayoría de las empresas transitará entre esos dos puntos.

Cómo funciona realmente el flujo (Copilot coding agent)

GitHub describe el funcionamiento del Copilot coding agent en cinco pasos concretos: (1) alguien asigna una issue a Copilot desde GitHub.com, GitHub Mobile, VS Code o el panel de agentes; (2) el agente abre un pull request en borrador, marcado como [WIP], en una rama dedicada (copilot/*); (3) el agente explora el repositorio, hace los cambios, y ejecuta pruebas y lint; (4) actualiza el PR con título y descripción y solicita revisión humana; (5) el equipo itera comentando @copilot directamente en el PR. Como dice GitHub, el agente "opera directamente dentro del flujo de pull request de GitHub", y "cada paso queda registrado, visible y abierto a la participación del equipo" - nada ocurre fuera del proceso de revisión que ya existe.

El otro extremo: legibilidad a escala (harness engineering)

El experimento de OpenAI muestra hasta dónde puede llegar este camino cuando un repositorio se diseña desde el primer día para ser leído por agentes, no por humanos. En cinco meses, tres ingenieros conduciendo agentes produjeron cerca de un millón de líneas de código y más de 1.500 PRs fusionados - sin ninguna línea escrita manualmente. La lección central no fue sobre qué modelo se usó, sino sobre la "legibilidad": el equipo tuvo que llevar al propio repositorio el contexto que normalmente vivía en conversaciones de Slack, porque era tan invisible para el agente como lo sería para un nuevo integrante.

Un playbook de diez pasos

Combinando los dos extremos - adopción incremental dentro de un flujo existente, y el caso más maduro de ejecución agentic a escala —, un playbook de adopción realista pasa por:

  1. Diagnóstico - mapear dónde está hoy el cuello de botella (bugs, cobertura de pruebas, refactorización - los mismos tipos de tarea que GitHub recomienda como punto de entrada)
  2. Elección del caso de uso - empezar por issues de complejidad baja a media, no por el problema más crítico del backlog
  3. Definición de agentes - quién hace qué (un agente de corrección de bugs no es lo mismo que uno de refactorización)
  4. Definición de herramientas - qué puede acceder y ejecutar el agente
  5. AGENTS.md - el artefacto que da contexto y límites, como en el ejemplo de Copilot y en el caso de OpenAI
  6. Flujo spec-driven - una issue se convierte en especificación antes de convertirse en código
  7. Pruebas - obligatorias antes de que cualquier PR se considere listo para revisión
  8. Observabilidad - cada paso registrado y visible, como en el flujo de PR de Copilot
  9. Métricas - PRs por período, tasa de aprobación sin retrabajo, tiempo de ciclo
  10. Escala - solo después de validar los pasos anteriores en repositorios pequeños, expandir a más equipos y más autonomía

El punto práctico

La diferencia entre "tener un agente" y "tener adopción real de agentes" no está en la herramienta - está en cuánto del proceso alrededor de ella (contexto, revisión, pruebas, observabilidad) ya existía antes de que el agente llegara. Los equipos que intentan saltar directo a alta autonomía sin ese proceso tienden a acumular retrabajo; los que parten del flujo de PR ya existente, como propone el Copilot coding agent, logran una rampa mucho más predecible hacia el nivel de madurez que documentó OpenAI.

Fuentes