Cómo cambia la ingeniería con agentes de código

OpenAI publicó una pieza sobre harness engineering que vale la pena leer con calma porque no habla solo de herramientas, sino de cómo cambia el trabajo cuando los agentes de código entran al flujo diario. El punto de fondo es simple: si un agente puede escribir, modificar y proponer cambios a la misma velocidad con la que tú abres un pull request, entonces revisar, probar y aprobar ya no se puede pensar igual.

Ese cambio no afecta solo a quien programa. También toca a QA, a quien mantiene la CI, a quien define estándares de calidad y a quien decide qué se puede automatizar y qué sigue requiriendo criterio humano. La lección para equipos en LatAm es directa: no basta con “usar Codex” o cualquier otro agente, hay que rediseñar el sistema alrededor de él.

Qué significa realmente trabajar con agentes de código

Cuando OpenAI habla de harness engineering, está poniendo el foco en el arnés, no en el modelo. El arnés es el conjunto de reglas, prompts, scripts, pruebas, validaciones y límites que hace posible que un agente trabaje dentro de un entorno real sin romper cosas. En otras palabras, el valor no está solo en que el agente genere código, sino en cómo lo encadenas con el resto del sistema de desarrollo.

En un equipo tradicional, una persona escribe código, lo prueba localmente, abre un PR y otra persona revisa. Con agentes, ese orden se vuelve más poroso. El agente puede generar una primera versión, iterar con feedback, correr pruebas y hasta preparar el contexto para revisión. Eso cambia el cuello de botella: ya no es solo escribir más rápido, sino evitar que la velocidad aumente el ruido, los errores sutiles y el costo de revisión.

La documentación oficial de OpenAI sobre Codex deja claro que el producto está pensado para tareas de ingeniería de software dentro de un flujo controlado, no como un reemplazo mágico del equipo. Puedes revisar la referencia oficial aquí: https://platform.openai.com/docs/guides/codex. La lectura correcta es esta: si el agente entra al día a día, tu proceso tiene que asumir que habrá más cambios, más iteraciones y más necesidad de validación automática.

Del PR humano al PR asistido por agente

Un pull request hecho por una persona suele venir con contexto implícito: sabes por qué cambió algo, qué decisión se tomó y qué riesgo se aceptó. Un PR generado o editado por un agente no siempre trae ese contexto de forma natural. Por eso, el equipo tiene que obligar al sistema a producir evidencia: tests ejecutados, archivos tocados, supuestos y límites.

Eso no significa deshumanizar el proceso. Significa que la revisión deja de depender tanto de la memoria de quien escribió el cambio y pasa a depender de artefactos verificables. Si el agente cambió una función crítica, tú quieres ver pruebas unitarias, pruebas de integración y, cuando aplique, una explicación corta de por qué la modificación no rompe contratos existentes.

En la práctica, esto empuja a los equipos a definir plantillas de PR más estrictas. No para burocratizar, sino para que el agente trabaje con una estructura repetible. Si cada cambio llega con el mismo tipo de evidencia, la revisión humana se vuelve más rápida y más consistente.

Por qué el contexto vale más que la velocidad

Un agente puede escribir mucho código en poco tiempo, pero el contexto sigue siendo el activo más caro. Si no le das restricciones claras, va a producir soluciones plausibles que no siempre encajan con tu arquitectura, tu estilo o tus límites de seguridad. En un equipo pequeño, eso puede parecer manejable. En un equipo mediano, se convierte en deuda técnica acumulada a velocidad alta.

Por eso, harness engineering no es solo ingeniería de prompts. También es ingeniería de contexto: qué archivos ve el agente, qué pruebas puede correr, qué tareas tiene permitidas y cuáles no. El objetivo es reducir la superficie de error antes de que el código llegue a revisión.

Si trabajas en una empresa en Ecuador, México, Colombia o Chile, este punto importa todavía más porque muchos equipos operan con menos margen de tiempo para re-trabajo. Un agente mal acotado puede ahorrar dos horas hoy y costarte un día mañana. La economía del flujo cambia cuando la generación de código se vuelve barata y la corrección sigue siendo cara.

Cómo cambia la revisión de código

La revisión de código en un entorno con agentes ya no puede centrarse solo en sintaxis, estilo o pequeñas mejoras. Eso sigue existiendo, pero se vuelve una capa menor. Lo que de verdad importa es evaluar si el agente respetó el contrato del sistema, si mantuvo el comportamiento esperado y si no introdujo regresiones difíciles de ver a simple vista.

OpenAI describe en su enfoque de harness engineering que el sistema debe facilitar ciclos rápidos de prueba y corrección. Eso implica que la revisión humana se desplaza hacia preguntas de intención y riesgo. Ya no es tanto “¿este código compila?” sino “¿este cambio preserva el comportamiento esperado bajo casos reales?”.

Para un equipo de producto, esto cambia la forma de asignar tiempo. Revisar un PR grande hecho por agente sin evidencia puede tomar más que revisar tres cambios más pequeños con pruebas claras. En otras palabras, si no diseñas el arnés, la velocidad del agente te puede generar más trabajo manual del que quitó.

Qué debe mirar una persona que revisa

Una revisión útil en este contexto debería mirar al menos cinco cosas:

1. Si el agente tocó más archivos de los necesarios.
2. Si los tests cubren el comportamiento que cambió.
3. Si hay dependencias nuevas o riesgos de seguridad.
4. Si la solución respeta convenciones del repositorio.
5. Si el cambio es entendible sin leer todo el historial de prompts.

Ese último punto es clave. La revisión no puede depender de saber qué se le pidió al agente. El PR debe ser autosuficiente. Si no lo es, vas a terminar con una dependencia invisible entre el prompt y el código que luego nadie puede auditar bien.

Un patrón útil es exigir que el agente produzca un resumen corto al final de cada tarea. No un texto largo, sino algo como: qué cambió, por qué, qué pruebas corrió y qué quedó fuera. Esa disciplina ahorra tiempo en revisión y ayuda a detectar cambios demasiado amplios.

Tabla de cambios en la revisión

Pruebas y QA ya no pueden ir detrás

Si el agente puede generar cambios más rápido que tu suite de pruebas, entonces tu suite pasó a ser el verdadero límite del sistema. Ese es el mensaje práctico detrás del enfoque de OpenAI: el arnés debe incluir pruebas que corran rápido, fallen de forma clara y cubran el comportamiento que importa. Si no, el agente solo acelera la producción de incertidumbre.

En equipos con agentes, QA deja de ser una fase al final y pasa a ser parte del circuito. El ideal no es “probar después”, sino diseñar el flujo para que el agente reciba señales inmediatas de si su cambio es correcto. Eso puede incluir unit tests, integration tests, snapshots, e2e y validaciones específicas del dominio.

También cambia la relación entre cobertura y confianza. Tener 90% de coverage no sirve de mucho si los tests no detectan regresiones reales. Lo que importa es que el arnés obligue al agente a pasar por escenarios relevantes. Si el cambio toca facturación, permisos o autenticación, tu suite debe cubrir flujos críticos, no solo funciones aisladas.

Qué automatizar primero

Si tu equipo está empezando, no intentes automatizar todo al mismo tiempo. Prioriza donde el costo de un error sea alto y la verificación sea objetiva. Un orden razonable sería este:

1. Linting y formato.
2. Unit tests de lógica pura.
3. Integration tests de rutas críticas.
4. Checks de seguridad básicos.
5. Validaciones de contrato o esquema.

Ese orden no es teórico. Sirve porque cada capa reduce una clase distinta de error. El agente puede equivocarse en detalles menores, pero si el pipeline atrapa rápidamente el problema, el costo baja. Lo que no conviene es dejar que el cambio llegue a staging sin señales tempranas.

Si usas GitHub Actions, por ejemplo, el objetivo no es tener más workflows por deporte. El objetivo es que cada tarea del agente tenga un camino de verificación corto y predecible. La documentación oficial de GitHub sobre Actions te puede servir como base para estructurar esto: https://docs.github.com/actions.

El QA cambia de rol

QA no desaparece. Se mueve. En vez de concentrarse solo en encontrar bugs al final, QA empieza a diseñar el sistema de validación que hace que el agente trabaje mejor desde el principio. Eso incluye casos borde, datos de prueba, entornos reproducibles y criterios de aceptación más explícitos.

En equipos pequeños, esta transición puede verse como una carga extra. En realidad, es una forma de evitar que cada nuevo cambio del agente requiera una revisión manual más pesada. Si el QA define bien el arnés, el equipo gana velocidad sin sacrificar control.

También aparece una nueva tarea: revisar el comportamiento del agente como herramienta. ¿Tiende a sobreescribir archivos? ¿Se salta convenciones? ¿Produce código correcto pero innecesariamente complejo? Esas preguntas ya forman parte de la calidad del sistema de desarrollo, no solo del producto final.

Control de calidad, seguridad y límites operativos

Cuando un agente entra al flujo, el control de calidad no solo verifica código. También verifica comportamiento del proceso. ¿El agente puede acceder a archivos que no debería? ¿Puede proponer cambios en áreas sensibles sin revisión adicional? ¿Tiene límites para tocar migraciones, permisos o configuración de producción? Esas preguntas importan tanto como el test unitario.

Los equipos que trabajan con agentes necesitan políticas claras. No basta con decir “usar IA con cuidado”. Tienes que definir qué tareas están permitidas, cuáles requieren doble aprobación y cuáles deben bloquearse por completo. Eso se vuelve aún más crítico si tu repositorio maneja datos sensibles o infraestructura compartida.

La idea de harness engineering es útil porque obliga a convertir principios vagos en controles concretos. Si el agente no debe modificar secretos, el arnés debe impedirlo. Si no debe abrir cambios en ciertos directorios, el entorno debe bloquear esa acción. La calidad deja de depender de la buena voluntad del modelo y pasa a depender de reglas del sistema.

Límites que conviene imponer desde el día uno

Hay límites que casi cualquier equipo debería considerar desde el inicio:

• Permisos de escritura acotados por carpeta o tarea.
• Prohibición de tocar archivos de producción sin revisión humana.
• Tests obligatorios antes de cualquier merge.
• Logs de acciones del agente para auditoría.
• Plantillas de salida para que el cambio sea revisable.

No necesitas una política de veinte páginas para empezar. Necesitas pocos límites, bien elegidos y fáciles de hacer cumplir. Si el arnés es demasiado complejo, nadie lo usa. Si es demasiado laxo, el agente se convierte en una fuente de cambios difíciles de rastrear.

Esto también impacta en compliance. En empresas que operan con clientes corporativos o fintech, poder explicar quién cambió qué y bajo qué validación ya no es un lujo. Es parte del proceso de entrega. Un agente sin trazabilidad clara complica auditorías y revisiones internas.

Cómo medir si el arnés funciona

No mides solo cuántas tareas completó el agente. Mides cuántos cambios pasaron sin re-trabajo, cuántas regresiones detectó la CI antes de merge y cuántas veces el equipo tuvo que intervenir para corregir contexto mal entendido. Esas métricas te dicen si el sistema está bien diseñado.

Una señal útil es observar el tiempo de revisión. Si baja el tiempo por PR pero sube el número de comentarios correctivos después del merge, el arnés está fallando. Si baja el tiempo de revisión y también baja la tasa de re-trabajo, vas por buen camino.

Otra métrica práctica es la tasa de tareas que el agente resuelve sin intervención adicional. No para celebrar automatización por sí misma, sino para ver qué tipo de trabajo sí se puede delegar y cuál sigue requiriendo a una persona. Esa distinción te ayuda a asignar mejor el tiempo del equipo.

Qué deberían hacer los equipos en LatAm ahora

Para muchos equipos en Latinoamérica, el reto no es adoptar agentes, sino hacerlo sin romper el ritmo de entrega. Hay menos margen para experimentar con procesos caóticos, sobre todo cuando el equipo ya trabaja con plazos ajustados y recursos limitados. Por eso conviene empezar por casos de uso acotados y medibles.

El mejor punto de partida suele ser un flujo donde el impacto sea visible y el error sea fácil de detectar. Por ejemplo, generación de tests, refactors pequeños, documentación técnica o tareas repetitivas de mantenimiento. Ahí puedes evaluar si el agente mejora el throughput sin degradar la calidad.

La clave es no convertir la adopción en una iniciativa de “usar IA” sin dueño. Alguien tiene que encargarse del arnés, de la política de revisión y de las métricas. Si no hay responsable claro, el agente termina siendo una capa más de complejidad.

Un plan de adopción simple

Puedes arrancar con este plan de cinco pasos:

1. Elige una sola categoría de tareas repetitivas.
2. Define qué puede tocar el agente y qué no.
3. Crea una plantilla de salida para cada tarea.
4. Añade pruebas obligatorias antes del merge.
5. Mide re-trabajo, tiempo de revisión y fallos detectados por CI.

Ese plan sirve porque te obliga a aprender con datos y no con impresiones. Si el agente funciona, lo vas a ver en menos re-trabajo y más consistencia. Si no funciona, también lo vas a ver rápido.

En una empresa de comercio electrónico en Perú, por ejemplo, podría tener sentido empezar con generación de tests para módulos de catálogo. En una fintech de Colombia, quizá convenga empezar por documentación y validaciones internas antes de tocar flujos de pagos. El orden depende del riesgo, no de la moda.

Lo que cambia en el equipo

También cambia la conversación entre perfiles. Ingeniería ya no discute solo sobre implementación, sino sobre cómo diseñar el proceso para que el agente no genere ruido. Producto tiene que entender que un cambio más rápido no siempre significa un cambio mejor. Y QA gana peso como diseñador del sistema de verificación.

Ese cambio cultural es más profundo de lo que parece. Un equipo que adopta agentes sin redefinir responsabilidades suele terminar culpando al modelo cuando el problema real era el proceso. En cambio, un equipo que trata al agente como parte del flujo puede mejorar su velocidad sin perder control.

La señal de madurez no es cuánto código genera el agente. Es cuánto del trabajo repetitivo pudiste absorber sin aumentar el riesgo. Ahí está la diferencia entre usar una herramienta y rediseñar la ingeniería alrededor de ella.

Tabla resumen

La lectura de OpenAI deja una idea clara: cuando los agentes de código pasan a ser parte del día a día, la ingeniería cambia de centro de gravedad. Ya no se trata solo de escribir más rápido, sino de diseñar un sistema donde la velocidad no destruya la calidad. Si tu equipo quiere aprovechar agentes de forma seria, el trabajo empieza en el arnés, no en el prompt.