Contexto técnico
Cada vez veo con más frecuencia el mismo escenario: las empresas recurren a la programación con IA de agentes (agentic AI coding) no por moda, sino porque la brecha en costo y velocidad es demasiado grande. Para la implementación de IA, parece casi un truco: un prototipo en días, primeros usuarios rápidamente y un equipo más reducido. Y es justo aquí donde suelo detenerme.
Si dejamos de lado la demostración y observamos la base de código seis meses después, el panorama es mucho menos festivo. Según los datos más citados en estudios recientes sobre código generado por IA, la productividad aumenta aproximadamente un 31.4%, pero al mismo tiempo las vulnerabilidades crecen un 23.7%, las advertencias de análisis estático aumentan un 30% y la complejidad del código se dispara un 41%.
Lo que me llama la atención de estas cifras no es el deterioro de la calidad en sí, sino el hecho de que se disfraza bajo una apariencia de ingeniería normal. Por fuera, el código puede parecer modular, pero por dentro esconde dependencias ocultas, encapsulación débil y fragmentos que un desarrollador humano tendrá que desenredar más tarde como si fuera una improvisación ajena.
Otra señal preocupante es que una parte de los métodos generados se elimina directamente durante la revisión. En los estudios se menciona una cifra cercana al 9.9% de código eliminado en las solicitudes de extracción (pull requests) generadas por agentes. Es decir, el agente no solo acelera la entrega, sino que también llena el flujo de trabajo con basura que el equipo debe analizar, verificar y descartar.
En el ámbito corporativo (enterprise), esto es especialmente peligroso porque el agente pasa por los procesos habituales de CI/CD e introduce dependencias que resuelven un problema local, pero que no cumplen con los estándares de seguridad establecidos. Mientras el producto es pequeño, esto se tolera. Sin embargo, cuando comienza el crecimiento, esta integración de IA se convierte repentinamente en un impuesto sobre cada cambio posterior.
Qué cambia esto para los negocios y la automatización
No pretendo ser dramático ni descartar este enfoque por completo. Para arrancar un proyecto, crear herramientas internas, desarrollar un MVP o automatizar procesos específicos, el uso de automatización con IA suele estar totalmente justificado. Un lanzamiento rápido a veces es realmente más importante que una mantenibilidad perfecta.
But los que ganan aquí son aquellos que, desde el principio, separan la velocidad de usar y tirar del núcleo de su producto. Pierden los equipos que permiten al agente escribir de todo sin límites arquitectónicos, sin trazabilidad de cambios y sin un presupuesto realista para la carga que supone la revisión de código.
En la práctica, yo prestaría atención a tres factores: en qué áreas puede escribir el agente con total libertad, qué dependencias tiene permitido introducir y quién es el responsable de transformar un prototipo exitoso en un sistema robusto. En Nahornyi AI Lab resolvemos este tipo de cuellos de botella constantemente para nuestros clientes: no prohibimos la automatización con IA, sino que la integramos de forma que, dentro de un año, no sea necesario reconstruir el producto desde cero.
Si su base de código ya está creciendo y nota que la velocidad empieza a perjudicar la calidad, analicémoslo a nivel de flujo de trabajo y arquitectura de IA. En Nahornyi AI Lab puedo ayudarle a estructurar el desarrollo de soluciones de IA para que la automatización no termine consumiendo el futuro de su producto y de su equipo.