Los agentes de IA disparan el volumen de commits mientras la revisión de código, los tests y la seguridad siguen operando a velocidad humana. Analizo por qué el cuello de botella ya no es programar, cómo cambia el trabajo de los desarrolladores y qué prácticas separan la productividad real del software generado sin control.
Escucha el artículo

La IA no está resolviendo la crisis del software: está fabricando código más rápido de lo que somos capaces de entenderlo. Celebrar que un agente entrega diez pull requests mientras nadie puede revisar tres no es productividad. Es convertir el repositorio en una fábrica de deuda técnica con luces de neón.
Durante meses, la conversación sobre inteligencia artificial para programar se ha obsesionado con una pregunta bastante cómoda: ¿cuánto código puede producir? La pregunta incómoda es otra: ¿cuánto de ese código puede demostrar que funciona, que es seguro y que seguirá siendo mantenible dentro de seis meses?
La respuesta, por ahora, no invita a descorchar champán.
The New Stack resumió el problema con un dato difícil de ignorar: los commits en GitHub se duplicaron en cuatro meses, pero la capacidad de verificación no creció al mismo ritmo. El cuello de botella se movió. Antes estaba en escribir la implementación; ahora está en revisar, probar y asumir responsabilidad por ella.
No significa que todo ese crecimiento proceda exclusivamente de agentes de IA. Sí refleja una realidad visible en cualquier equipo que use herramientas de programación asistida: generar una función, una migración o una batería de tests cuesta minutos. Comprender sus efectos laterales todavía exige contexto, experiencia y tiempo humano.
Al mismo tiempo, el ecosistema empuja en la dirección contraria. AMD y la Digital Cooperation Organization anunciaron una iniciativa para ampliar un ecosistema abierto de desarrolladores de IA. Más herramientas, más acceso y más capacidad de construir son buenas noticias. Pero democratizar la generación sin democratizar también la verificación deja media infraestructura sin terminar.
Y la tensión ya salió del IDE. Andrew Bailey, gobernador del Banco de Inglaterra y presidente del Financial Stability Board, advirtió al G20 que los riesgos de la IA de frontera no respetan fronteras nacionales. Su preocupación apunta al sistema financiero, pero el mecanismo es reconocible para cualquier programador: sistemas más autónomos, controles insuficientes y consecuencias que aparecen lejos del lugar donde se tomó la decisión inicial.
Todo software falla. El código humano también introduce vulnerabilidades, condiciones de carrera y consultas que incendian producción un viernes a las 18:00. Presentar la IA como una fuente inédita de errores sería intelectualmente perezoso.
El problema es la escala combinada con una falsa sensación de certeza.
Un desarrollador cansado escribe una función defectuosa. Un agente puede replicar el mismo supuesto defectuoso en veinte archivos, generar tests que validan su propia interpretación equivocada y envolver el resultado en una explicación impecablemente convincente. La forma parece profesional aunque el razonamiento de fondo esté roto.
Ahí nace el software “write-only”: barato de producir, caro de comprender y peligrosísimo de modificar. El pull request pasa porque compila. Los tests pasan porque fueron diseñados alrededor del mismo error. La revisión humana se vuelve superficial porque el diff tiene miles de líneas. Tres semanas después, nadie sabe por qué existe esa abstracción.
Si revisar cuesta más que escribir, producir más código deja de ser una ventaja y se convierte en riesgo operativo.
La seguridad agrava la ecuación. Un agente no necesita “volverse malvado” para causar daño. Basta con que exponga un secreto en un log, use una dependencia vulnerable, aplique permisos demasiado amplios o interprete mal una instrucción ambigua. Cuando estos patrones se automatizan, también se automatiza el radio de explosión.
La oportunidad no está en abandonar los agentes de IA. Eso sería como responder a los bugs prohibiendo los compiladores. La ventaja competitiva estará en usar agentes para reducir complejidad, no solo para multiplicar archivos.
Los mejores equipos no preguntarán “¿cuántas tareas cerró el agente?”. Preguntarán cuántas decisiones quedaron verificadas, cuántos riesgos fueron aislados y cuánto tiempo tardaría una persona nueva en comprender el cambio.
Esto cambia la arquitectura del trabajo. Un agente puede proponer una implementación; otro puede intentar romperla. Los tests deben derivarse de requisitos y amenazas, no únicamente del código generado. Los cambios pequeños vuelven a ser valiosos porque permiten revisar intención, no solo sintaxis. Los entornos aislados dejan de ser una sofisticación empresarial y pasan a ser el cinturón de seguridad básico.
También cambia lo que significa ser rápido. Velocidad ya no es llegar primero al merge. Es llegar a producción con evidencia suficiente y poder revertir sin drama. Un sistema que genera cien cambios diarios, pero necesita dos semanas para investigar cada incidente, no es rápido. Solo adelanta el trabajo visible y esconde la factura.
Primero, limitar el tamaño de los cambios. Un agente con acceso a todo el repositorio puede ser útil para explorar, pero no debería recibir carta blanca para reescribirlo. Divide el trabajo por comportamiento verificable y exige un criterio de aceptación concreto.
Segundo, separa generación y evaluación. Si el mismo modelo escribe código y define la prueba que demuestra que está bien, existe un conflicto lógico. Usa especificaciones independientes, tests de contrato, análisis estático y revisión adversarial. Para rutas críticas, añade intervención humana real, no un clic automático sobre “Approve”.
Tercero, registra la procedencia. Saber qué cambió un agente, con qué contexto y bajo qué instrucciones acelera la investigación cuando algo sale mal. No hace falta convertir cada prompt en un documento ceremonial, pero sí conservar trazabilidad suficiente para reconstruir la decisión.
Cuarto, trata las herramientas como colaboradores con permisos limitados. Secretos fuera del contexto, credenciales temporales, sandbox para ejecutar código y acceso mínimo a producción. Si una tarea no necesita publicar, no le des capacidad de publicar. Principio de mínimo privilegio: aburrido, antiguo y todavía brutalmente efectivo.
Por último, mide resultados, no volumen. Incidentes, tiempo de recuperación, defectos escapados, complejidad añadida y esfuerzo de revisión cuentan más que líneas generadas. La IA puede aumentar la productividad de un buen sistema de ingeniería. También puede acelerar un sistema caótico hasta estrellarlo antes.
La programación con inteligencia artificial no elimina al desarrollador. Elimina parte del trabajo mecánico y hace más valioso el criterio: decidir qué construir, comprobar qué ocurrió y responder cuando la realidad contradice la demo.
Si quieres integrar agentes de IA en tu producto sin convertir el repositorio en una caja negra, escríbeme. Soy Brayan, desarrollador freelance, y puedo ayudarte a diseñar el flujo, la arquitectura y las barreras de seguridad con las que esa velocidad sí se convierte en negocio.