Confiando en la entrega impulsada por agentes en producción

La respuesta honesta es que ambas partes de esa preocupación son válidas, porque describen aspectos distintos de un mismo cambio. Una parte tiene que ver con la velocidad a la que un agente puede producir código funcional. La otra, con el costo de confiar en lo que produjo y el daño que puede ocasionar en el proceso. Son problemas separados, y el segundo es donde vive casi toda la resistencia al desarrollo impulsado por agentes.

(Por desarrollo impulsado por agentes nos referimos a delegar unidades completas de trabajo a agentes de IA que planifican, escriben, prueban y proponen cambios, mientras las personas dirigen y revisan en lugar de escribir cada línea.)

Es importante establecer esa distinción, porque cambia lo que se debe hacer a continuación. Si el problema fuera la capacidad bruta, la solución sería esperar un modelo mejor. Pero no lo es, así que esa no es la respuesta. La confianza y la seguridad no llegan con la próxima versión. Las produce el sistema dentro del cual opera el agente: cómo está fundamentado, qué puede tocar, quién revisa su trabajo y qué queda registrado cuando actúa.

Entre todos, pasamos nuestros días construyendo estos sistemas, tanto en la entrega propia de Orium como dentro de los equipos de ingeniería de nuestros clientes, y la lección ha sido consistente. La respuesta no es un agente mejor. Es el proceso de entrega en sí mismo. Cuando se hace explícito el ciclo de vida por el que pasa el trabajo y se elimina la fricción en cada etapa, la promesa y la resistencia dejan de estar en conflicto.

Lo que es cierto, empecemos por ahí. Algo ha cambiado en la forma en que se desarrolla el software, y quienes están más cerca de ese proceso no están siendo cautelosos al respecto. Andrej Karpathy, cofundador de OpenAI que recientemente se unió al equipo de preentrenamiento de Anthropic, escribió en X que los agentes de codificación basados en LLM habían cruzado "algún tipo de umbral de coherencia" hacia diciembre de 2025, y calificó 2026 como un año de alta energía mientras la industria asimila esta nueva capacidad. El presidente de Y Combinator, Garry Tan, reportó que se publicaban 37.000 líneas de código generado por IA al día en cinco proyectos. El dato de Tan fue cuestionado más tarde cuando un desarrollador auditó el resultado público y encontró mucho desperdicio, lo cual es en sí mismo una lección: el volumen bruto y el software confiable no son lo mismo.

La naturaleza del trabajo está cambiando. El desarrollador pasa de escribir cada línea a dirigir un sistema que las escribe, para luego evaluar lo que produce. Si se trata como un autocompletado más rápido, la ganancia es modesta. Si se trata como un nuevo modelo operativo, la ganancia es considerable. Hemos sentido ese cambio en nuestros propios equipos, donde el apalancamiento es real una vez que el trabajo está configurado para aprovecharlo.

Las ganancias en producción bruta no llegan intactas a producción, y la evidencia es específica.

En cuanto a la calidad, el informe sobre el estado de la generación de código por IA frente a humanos de CodeRabbit encontró que, en 470 pull requests, los cambios coescritos por IA presentaban aproximadamente 10,83 problemas por PR frente a 6,45 en los cambios realizados exclusivamente por humanos, es decir, aproximadamente 1,7 veces más defectos. GitClear, basándose en 211 millones de líneas de código modificado, observó que la rotación de código (la proporción revisada o descartada en las dos semanas posteriores a su escritura) aumentaba a medida que se extendía la autoría por IA, junto con un marcado incremento en el código duplicado. Su CEO, Bill Harding, describe "una gran cantidad de código que se escribe y que inmediatamente necesita ser corregido."

Esa brecha de calidad es lo que erosiona la velocidad. La producción aumenta, pero una parte de ella regresa al ciclo de revisión y corrección, por lo que el rendimiento neto queda por debajo de la cifra titular.

El coste tiene dos caras. La primera es ese retrabajo, pagado en las horas más costosas que se tienen. La segunda es el coste de la inferencia en sí. Un agente que planifica, reintenta y opera en bucles multiagente consume muchos más tokens que un único prompt, y una configuración de alta autonomía sin supervisión puede generar gastos reales rápidamente. Sin visibilidad del uso ni controles de gasto, la factura se vuelve impredecible de una manera que el área financiera no pasa por alto.

Luego está la superficie que la mayoría de los equipos nunca ha mapeado. Un agente que trabaja en su pipeline puede almacenar credenciales, invocar herramientas, modificar el host en el que se ejecuta y enviar su código a un proveedor de modelos que podría conservarlo. Cada uno de estos aspectos plantea preguntas de seguridad que una demo en diapositivas nunca suscita y que una empresa regulada no puede ignorar.

Nada de esto es principalmente un problema de modelo. Es un problema de fricción, y la fricción tiene una forma. Mapea el trabajo que realiza un agente, desde la formulación de una solicitud hasta su observación en producción, y podrás ver adónde van el tiempo y la confianza.

La columna vertebral en el centro es el ciclo de vida por el que pasa cada cambio (aunque la terminología aún está evolucionando): Formular, Especificar, Planificar, Implementar, Probar, Integrar, Verificar, Lanzar, Observar. Presionando desde arriba está la carga operativa, la fricción de personas y procesos: solicitudes ambiguas, alineación débil con las partes interesadas, criterios de marca y UX difíciles de codificar, ausencia de un catálogo de funcionalidades existentes, convenciones sin documentar, capacidad de revisión limitada y controles de gestión del cambio. Empujando desde abajo está la carga de infraestructura y tecnología: arquitectura sin documentar, higiene deficiente del código base, compilaciones manuales lentas, ausencia de un entorno de pruebas donde el agente pueda ejecutar código, pipelines manuales, cobertura de regresión escasa y poca observabilidad en producción.

Un agente se topa con cada uno de estos obstáculos, más rápido de lo que lo haría una persona. Apúntalo hacia un código base sin documentar y adivinará, igual que lo haría un empleado nuevo, solo que a velocidad y volumen de máquina. Cambia a un modelo más capaz y nada de esto cambia. La arquitectura sin documentar sigue sin estar documentada, la cola de revisión sigue siendo el cuello de botella, el agente sigue teniendo más acceso del que su tarea requiere. La promesa se escapa entre la fricción, y la fricción no está en el modelo.

Coloca las objeciones sobre ese diagrama y dejarán de parecer quejas separadas. Son la misma fricción que emerge en distintas etapas.

La calidad y la velocidad se pierden en el centro de la columna vertebral, en las fases de Implementar, Probar y Verificar, y en la puerta de revisión que se encuentra sobre ellas. Un agente escribe rápido, pero con una cobertura de regresión escasa y una cola de revisión que ya está al límite, los defectos o se escapan o se acumulan esperando turno, y la velocidad que ganaste se convierte en retrabajo.

El costo se filtra por dos lugares a la vez. Está el retrabajo mencionado, que se paga en horas de personal sénior. Y está la carga de infraestructura que hay debajo: compilaciones y pipelines manuales, y sin un entorno sandbox para que el agente ejecute su propio código, lo que obliga a una persona a supervisar cada paso. El gasto en tokens se escapa allí donde un agente opera con alta autonomía sin visibilidad del uso que lo controle.

La seguridad se filtra donde la columna vertebral se conecta con tus sistemas reales, en las fases de Integrar y Publicar, cuando no hay un sandbox que contenga lo que hace el agente ni una puerta que verifique lo que está a punto de hacer. Esa superficie es lo suficientemente amplia como para que hayamos escrito sobre ella por separado, pero en el diagrama aparece como una forma más de resistencia: la fricción que encuentra el trabajo en su camino hacia producción.

Esto es lo que realmente hacen los equipos más ágiles con los que trabajamos. No esperan un modelo mejor. Hacen explícito el ciclo de vida, identifican los puntos de fricción en cada etapa y los eliminan uno a uno. Documentan las convenciones que el agente no deja de adivinar. Configuran un entorno de pruebas para que el agente pueda construir y verificar su propio trabajo sin necesidad de intervención humana en cada ejecución. Incorporan verificaciones automatizadas al flujo de trabajo para que la revisión deje de ser la única barrera. Y tejen la verificación y la observabilidad a lo largo de cada etapa, en lugar de añadirlas al final, de modo que un problema aparezca en la fase de pruebas y no en producción.

Nada de esto es glamoroso, y nada de esto implica actualizar el modelo. Es el trabajo sin brillo de eliminar la fricción, y es lo que convierte un resultado en bruto en algo que se puede entregar. Los equipos que lo hacen obtienen dos cosas a la vez: la velocidad se multiplica, y también la resiliencia, porque la misma claridad que permite a un agente moverse rápido es la que permite detectar y recuperarse cuando algo sale mal.

No necesitas un modelo más grande ni una reorganización para empezar. Toma un equipo y un flujo de trabajo, y recórrelo de principio a fin, desde el Encuadre hasta la Observación. En cada etapa, identifica el obstáculo: la solicitud ambigua, la convención no documentada, el entorno de pruebas que falta, la cola de revisión que se ha convertido en el cuello de botella. Luego elimina el peor, y repite el proceso el mes siguiente.

Haz eso algunas veces y la brecha entre la promesa y tu realidad comenzará a cerrarse. El agente no mejoró; el camino que recorre se volvió más claro. Ese es el trabajo que realizamos con equipos de ingeniería listos para pasar de una velocidad prestada a una entrega que les pertenece.