De la Programación por Intuición a la Autonomía Supervisada

El compromiso al que todos llegaron —dejar que los agentes escriban, mantener a los humanos revisando y simplemente no tocar el resto del proceso— parece suficientemente sensato. En las consultorías que realizamos, eso le genera a los clientes una mejora de entre el 20 y el 30% antes de que el número deje de moverse. Porque cada hora que un agente ahorra aparece frente a alguien que tiene que absorberla, de modo que el rendimiento termina siendo gobernado por la rapidez con la que los ingenieros pueden asimilar lo que los agentes producen.

Y ese ni siquiera es el problema más difícil. El desafío mayor es que este esquema es menos seguro de lo que parece. "Alguien lo revisó" es una afirmación que nadie puede verificar realmente después. Incluso cuando ocurre, los revisores hojean el contenido a medida que el volumen aumenta. Y en la era de los agentes, ese volumen no deja de crecer.

Mientras la confianza dependa de que una persona haya echado un vistazo, la velocidad y la seguridad se contraponen.

La confianza construida a partir de evidencia se comporta de manera diferente. Criterios acordados antes de que un agente comience, verificaciones que se ejecutan de la misma forma en cada cambio, y señales provenientes del entorno de producción tras el lanzamiento —nada de eso está limitado por la atención de nadie, y todo ello deja un rastro al que se puede volver.

En este artículo, proponemos un modelo de madurez de cinco niveles para la entrega de software impulsada por agentes. El modelo mide cómo un equipo genera confianza en un cambio y qué tan temprano lo hace.

Cada nivel nombra aquello que genera confianza.

En el Nivel 0: Verificación por intuición, el software parece funcionar y esa es toda la garantía. El Nivel 1: Velocidad prestada se apoya en la palabra de una persona después de revisar el cambio. El Nivel 2: Intención duradera añade criterios acordados antes de que el agente comience, de modo que la pregunta sobre si un cambio es correcto tiene una respuesta que precede al código. En el Nivel 3: Confianza ganada, las verificaciones automatizadas producen esa respuesta en cada cambio y una persona revisa las excepciones. El Nivel 4: Resultados dirigidos lleva la verificación a producción, donde el despliegue gradual y el monitoreo asumen la carga, y las personas dedican su tiempo a la intención y la política.

Los niveles no son una fila a la que te unes por un extremo. Una organización saludable ejecuta picos de Nivel 0 y servicios de producción de Nivel 3 en el mismo sprint, ubicando cada flujo de trabajo donde su riesgo lo justifica.

Varios modelos ya circulan en este espacio, y cada uno responde una pregunta diferente a esta.

La investigación DORA de Google, basada en casi 5.000 profesionales de tecnología, descubrió que la IA actúa como un amplificador. Magnifica cualquier sistema de entrega que ya tengas, incluidas las partes que estaban rotas antes de que alguien instalara un agente. Los cimientos determinan tu retorno, algo que vale la pena saber y que aun así te deja adivinando dónde te encuentras actualmente.

Birgitta Böckeler en Thoughtworks le dio a la industria su vocabulario de trabajo para el centro de este rango, dividiendo el desarrollo basado en especificaciones en spec-first, spec-anchored y spec-as-source. La taxonomía es precisa respecto al artefacto y guarda silencio sobre la organización a su alrededor. Addy Osmani trazó la línea entre el vibe coding y la ingeniería asistida por IA, que es la distinción a la que la mayoría de los equipos recurren cuando describen lo que hacen.

Las incorporaciones más recientes provienen de los proveedores de herramientas. El Autonomy Maturity Model de Factory evalúa repositorios según ocho pilares técnicos, que van desde el linting y los sistemas de compilación hasta la observabilidad y la gobernanza. Sus señales son binarias por diseño, lo que hace que el modelo sea práctico de ejecutar en un gran conjunto de activos. Lo que califica es tu base de código. Un repositorio puede superar los ocho pilares mientras el equipo que trabaja en él no genera ninguna confianza verificable, porque ningún pilar pregunta quién escribió las pruebas ni si alguien estuvo de acuerdo con los criterios.

La preparación es una propiedad de tu código, y un script puede evaluarla. Lo que describimos es una propiedad de tu enfoque, y verla implica observar cómo ocurre el trabajo en la práctica.

Nada por debajo del Nivel 1 debería llegar ante un cliente. Si el código va a gestionar una transacción o estar cerca de datos de pago e información personal, alguien de tu equipo lo ha leído y puede explicarlo. Esa es la posición mínima defendible, y por eso tratamos el Nivel 1 como el umbral base.

Casi todas las organizaciones que alcanzan ese umbral se detienen en él, y la economía lo explica. Generar un cambio cuesta una fracción de lo que costaba antes; entenderlo cuesta lo mismo de siempre. CodeRabbit, que vende revisión de código con IA y por tanto tiene interés en la respuesta, encontró que las solicitudes de cambio coescritas con IA presentaban 10,83 problemas de revisión cada una, frente a 6,45 en el trabajo realizado exclusivamente por humanos, en un análisis de 470 solicitudes. GitClear, al examinar 211 millones de líneas modificadas, detectó un aumento en la rotación de código y la duplicación durante el mismo período en que se extendió la autoría con IA. Los revisores están gestionando más cambios y encontrando más problemas en cada uno.

El umbral también se erosiona bajo la presión del volumen. Una aprobación de fusión registra que alguien revisó el código, pero no registra qué verificó exactamente. A medida que el volumen aumenta, la brecha entre ambas cosas se amplía, lo que representa un cambio real en tu perfil de riesgo que no aparecerá en ningún informe que recibas.

Nivel 0: Verificación de vibes

La confianza surge de ver funcionar el sistema. El mecanismo de seguridad es la descartabilidad: spikes, prototipos, herramientas internas, una prueba de concepto funcional antes de que alguien comprometa presupuesto. Ese valor es real, y tratarlo como algo vergonzoso es la forma en que los equipos desperdician semanas sobre-ingeniando trabajo destinado a desecharse. El problema surge cuando el resultado del Nivel 0 cruza hacia un sistema del que dependen usuarios y datos de producción.

Nivel 1: Velocidad prestada

Una persona lee el cambio y lo avala; todo lo demás del proceso permanece igual que antes de que llegaran los agentes. Eso significa que el rendimiento está limitado por la velocidad de lectura, y la garantía vive en la memoria de alguien, donde nadie más puede inspeccionarla.

La velocidad en este nivel se toma prestada del entorno de codificación con IA y los modelos subyacentes. Nada ha cambiado en la forma de trabajar de los equipos, por lo que la ganancia no se acumula y es difícil defender la economía de tokens en una conversación financiera.

También se toma prestada a costa de los revisores. Cada cambio adicional que produce un agente consume una cuota fija de atención humana, y los intereses se pagan en tiempo de espera y lecturas más superficiales. Ese tipo de capacidad prestada se cobra en el peor momento: durante un cierre de versión, en un período festivo, o cuando la única persona que entiende un servicio se va.

Nivel 2: Intención duradera

Los criterios de aceptación se redactan y acuerdan antes de que comience la generación, y sobreviven a la sesión. La revisión deja de ser un ejercicio de reconstrucción, porque el revisor contrasta el cambio con algo concreto y ya no tiene que inferir qué se quería. Un agente puede redactar esos criterios. Ratificarlos es la parte que sigue siendo humana, y es económica, lo que hace que valga la pena alcanzar este nivel primero.

Lo que este nivel exige es disciplina; las herramientas son secundarias. Los equipos que se estancan suelen hacerlo porque los criterios se escriben a posteriori para ajustarse a lo que el agente produjo.

Nivel 3: Confianza ganada

Las verificaciones automatizadas entregan la respuesta antes de que alguien la revise: tipos, pruebas derivadas de los criterios acordados, pruebas de contrato entre límites de servicio, análisis de dependencias y secretos, y límites estrictos sobre lo que un cambio puede tocar y consumir. Cada cambio llega con evidencia —lo que se afirmó, lo que se demostró— y los humanos dedican su tiempo de revisión a las excepciones.

Este es el primer nivel en el que agregar agentes aumenta el rendimiento, ya que las verificaciones escalan con el volumen mientras que la capacidad de los ingenieros senior no. También es el nivel que nadie puede venderte: el Nivel 3 es entrega continua con la compuerta apuntada a un agente, por lo que un equipo que no podía ejecutar CD hace dos años tampoco puede ejecutar el Nivel 3 hoy.

Los entornos distribuidos elevan el listón: un solo cambio puede cruzar cuatro o cinco servicios pertenecientes a distintos equipos, más una integración que nadie ha tocado en años. La cobertura implica controlar todos ellos, no solo el repositorio donde comenzó el trabajo.

Nivel 4: Resultados dirigidos

La verificación se extiende más allá del despliegue. El lanzamiento escalonado, el monitoreo del comportamiento que importa al negocio y la reversión automática capturan la clase de problemas que nada antes del despliegue puede detectar. Las personas establecen la intención y la política, y los agentes trabajan hacia los resultados dentro de ese marco. Esto es autonomía supervisada. La supervisión es la parte que lo hace funcionar, porque un humano sigue siendo responsable de lo que se construye y por qué.

Pocas organizaciones operan así para los sistemas de los que dependen sus clientes. Muchas demostraciones del Nivel 4 resultan ser Nivel 3 con buena puesta en escena, algo que conviene saber antes de planificar una hoja de ruta alrededor de ello.

Aquí está la cuestión: una verificación no se cansa. Se aplica de la misma manera en el centésimo cambio que en el primero, a las 3 de la madrugada, nueve semanas después de iniciado un período de congelación de versiones. Un revisor a gran volumen no puede hacer eso, y pedírselo es la manera en que los estándares se van erosionando.

La evidencia multiplica el efecto. Cuando un cambio lleva un registro de lo que fue verificado, ese registro sigue siendo inspeccionable meses después, durante un incidente o una auditoría. El mismo mecanismo delimita hasta dónde puede llegar un agente, limita lo que puede consumir y registra lo que tocó, lo que convierte el acceso del agente de una cuestión abierta en una gobernada.

La confianza solo cuenta cuando proviene de algo independiente de lo que produjo el trabajo. Si un agente escribe la especificación, el código y las pruebas en un solo paso, las pruebas afirman lo que el código hace. Verde significa que esos tres artefactos coinciden entre sí, lo cual es una afirmación mucho más débil de lo que parece. Un equipo en esa posición tiene la ceremonia del Nivel 3 sin la sustancia, y eso es más peligroso que el Nivel 0, porque fabrica certeza donde el Nivel 0 al menos admite no tener ninguna.

La independencia debe mantenerse en varios puntos. Los criterios se fijan antes de la generación y no se revisan para que coincidan con el diff. Lo que verifica el trabajo no comparte contexto con lo que lo produjo. Y la barrera no puede moverse en el mismo cambio no revisado que el código, porque el camino más barato hacia el verde es editar la barrera.

El modelo tiene un límite que vale la pena enunciar claramente. Cada nivel por encima de cero aumenta la confianza en que el resultado coincide con la intención, y ninguno de ellos interroga la intención en sí. Un agente construirá lo incorrecto rápidamente, con cobertura total y un registro de auditoría limpio. El juicio sobre qué construir se vuelve más valioso a medida que la ejecución se abarata.

Hazle una pregunta a un ingeniero: la última vez que un agente produjo algo incorrecto, ¿qué lo detectó? La respuesta revela en qué punto se encuentra tu equipo.

Tú, eventualmente, es el Nivel 0. Tú, en revisión, es el Nivel 1. Una prueba escrita a partir de criterios acordados de antemano es el Nivel 2. Una barrera automatizada, antes de que alguien lo revisara, es el Nivel 3. Un canary y un rollback es el Nivel 4.

Luego pregunta quién escribió esa prueba y si tenían la implementación delante. Esa pregunta de seguimiento hace bajar un nivel a muchos equipos.

Aplica esto por flujo de trabajo y ten en cuenta que obtener respuestas distintas según el flujo no significa que algo esté mal. La respuesta para una herramienta de informes internos y la respuesta para el servicio que mueve dinero deberían ser diferentes, y si no lo son, una de ellas está equivocada.

Decide dónde el vibe coding vale la pena. El Nivel 0 es rápido y es la respuesta correcta para cierto tipo de trabajo: prototipos desechables, experimentos internos, validar una idea antes de que reciba financiación. Anota qué trabajo califica y cuál es el detonante que lo obliga a subir un nivel, que generalmente es el momento en que alguien fuera del equipo empieza a depender de él. Las organizaciones que dejan esto sin definir o prohíben el Nivel 0 por completo y pierden la velocidad, o dejan que el trabajo de Nivel 0 se cuele en producción una excepción a la vez.

Anota dónde está el límite mínimo. La mayoría de las organizaciones ya tienen una política de revisión. Pocas tienen una que diga algo sobre el trabajo producido por un agente, por lo que la decisión recae en el hábito individual bajo presión de plazos. Nombra los sistemas donde nada se fusiona sin una persona que pueda explicarlo, y deja explícito que la regla aplica sin importar quién o qué escribió el código.

Sube un flujo de trabajo un nivel este trimestre. Elige un equipo, elige el nivel por encima de donde están hoy y cambia una cosa. Para la mayoría de los equipos, eso significa criterios acordados y registrados antes de que el agente comience, con pruebas escritas a partir de esos criterios y no de la implementación final. Compara la tasa de retrabajo con una pieza de trabajo similar realizada de la manera habitual. Limítalo a un solo experimento.

Mide qué proporción de los cambios fusionados supera una validación automatizada. Cuenta qué proporción de lo que se entregó el trimestre pasado fue verificado por algo distinto a una persona bajo presión de plazos. La cobertura del repositorio es el denominador equivocado, porque un pipeline que existe y un pipeline que actúa como barrera son cosas distintas. El número que obtienes es tu cobertura real de Nivel 3, y en los entornos que evaluamos está por debajo de lo que el organigrama sugiere.

Diez veces el rendimiento existe por encima del nivel donde una persona es el punto de control. Llegar allí es un trabajo poco glamoroso sobre los procesos, y está al alcance de cualquier equipo dispuesto a comenzar con un flujo de trabajo y un trimestre.

Ese es el trabajo que realizamos con los equipos de ingeniería, y puedes leer más sobre cómo lo abordamos en nuestra página de desarrollo impulsado por agentes. Si deseas ayuda para ubicar a tus equipos en estos niveles, o para decidir qué flujo de trabajo mover primero, ponte en contacto con nuestro equipo.