La IA puede escribir el código. No puede hacerse responsable de él.

Los agentes de programación cambiaron la economía de escribir software más rápido de lo que la mayoría de los equipos cambió su forma de trabajar. El resultado es predecible: más código, antes, con la misma cantidad de personas responsables de que sea correcto. Algunos equipos entregan mejor que nunca. Otros acumulan una nueva clase de deuda técnica —código que nadie del equipo leyó por completo— y no lo descubrirán hasta dentro de un año.

La diferencia no es el modelo que usan. Es si conservaron la disciplina que el modelo no puede aportar.

El modelo es rápido y se equivoca con convicción

Un agente escribirá una función, sus pruebas y un mensaje de commit en el tiempo que toma describirlos. También inventará una API que no existe, cumplirá la prueba que escribió en lugar del comportamiento que querías y ampliará silenciosamente el alcance de un cambio porque la instrucción era imprecisa. Nada de eso es un motivo para no usarlo. Es el motivo por el que el proceso a su alrededor importa más que antes, no menos.

Una forma útil de verlo: el agente es el ingeniero junior más productivo con el que hayas trabajado, y nunca se volverá senior por sí solo. Todo lo que hace un buen equipo para que el trabajo de un junior sea seguro —instrucciones claras, revisión, pruebas, una persona que aprueba— es exactamente lo que hace seguro el trabajo de un agente.

Qué se sostiene

La especificación va primero y vive en el repositorio. La mayor palanca es la calidad de las instrucciones. "Agrega exportación a CSV" produce una suposición; una especificación escrita con los estados, los casos límite y lo que significa "terminado" produce la funcionalidad. Escribir esa especificación es la habilidad difícil que la mayoría de los equipos omite, y los agentes encarecen esa omisión. Mantenla versionada junto al código para que la intención y la implementación se revisen juntas.

Cada línea se lee. No se ojea para revisar el estilo: se lee para entender qué hace. La revisión detecta la API inventada, la prueba que no comprueba nada, el cambio que tocó un archivo que no tenía motivo para tocar. Si el volumen de código generado impide una revisión completa, la respuesta son cambios más pequeños, no revisiones más superficiales.

Las pruebas son el contrato, así que una persona escribe qué verifican. Los agentes son excelentes para armar la estructura de las pruebas y pésimos para decidir qué significa que algo sea correcto. Deja que el agente genere los casos; una persona decide qué debe y qué no debe hacer la funcionalidad, y rechaza las pruebas que sólo reflejan la implementación.

Los controles verifican antes de entregar cualquier cambio. Verificaciones de tipos, linters, el conjunto de pruebas, análisis de seguridad y una comprobación de que el cambio se mantiene dentro del alcance declarado: se ejecutan automáticamente en cada cambio, en CI, antes de que una persona dedique su atención. Un control que sólo se ejecuta en la máquina del desarrollador es una sugerencia.

Observabilidad desde la primera versión. Si un cambio escrito por un agente se comporta mal en producción, necesitas verlo ese día, no en la retrospectiva trimestral. Registros, seguimiento de errores y una trazabilidad desde cualquier resultado hasta el cambio que lo causó.

Verificaciones de licencia y procedencia. El código generado puede reproducir fragmentos con licencia. Búscalos como buscas vulnerabilidades y trátalos como la misma clase de problema.

Un nombre en cada entrega. El agente no decide. Un ingeniero sí, y se hace responsable de lo que salió, como siempre. Esta es la regla que sostiene las demás: cuando una persona tiene que responder por la entrega, se escribe la especificación, se hace la revisión y se lee la prueba.

Cómo se ve esto en la práctica

La intención se convierte en una especificación en git. Un agente construye a partir de ella, en una rama, con las pruebas cuya estructura armó y las que escribió una persona. Los controles se ejecutan. Un ingeniero senior revisa el cambio frente a la especificación, no sólo el diff. La versión se entrega con el nombre de ese ingeniero, de forma abierta, donde el cliente puede ver cada commit. Para el trabajo en el que el código y los datos del cliente no pueden salir de un entorno controlado, los agentes se ejecutan sobre nuestra propia plataforma de inferencia, construida internamente, en lugar de una API de terceros. Con el tiempo, las clases de cambios que el agente hace bien dejan de necesitar revisión línea por línea, y las que siguen sorprendiéndote la conservan. La autonomía se gana por tipo de cambio, nunca se concede de manera general.

Nada de esto es nuevo. Es lo que los buenos equipos de ingeniería ya hacían, aplicado a un colaborador que escribe más rápido que cualquiera de ellos. Los equipos que más obtienen de la IA no son los que más confiaron en ella. Son los que nunca dejaron de comprobar.