Tu IA acaba de producir deuda técnica en masa.
Se suponía que la IA mejoraría tu código. Lo empeoró.
Por primera vez desde la invención del control de versiones, los equipos están lanzando más rápido y rompiendo más cosas.
La IA hace tres cosas por los equipos de ingeniería. Escribe código más rápido. Detecta defectos antes. Construye cosas que tu equipo actual no puede construir solo.
La industria lo apostó todo al primero. Velocidad. Más código, más rápido.
Nadie preguntó qué pasa cuando triplicas la producción de un equipo que ya no entendía la mitad de su propio código.
Fuente: https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways
Ya he visto esto antes. Todos lo hemos visto.
A finales de los 90, Java empresarial prometía "escribe una vez, ejecuta en cualquier lado". Las empresas apostaron líneas de producto enteras a eso. J2EE, EJBs, pilas middleware.
Para 2005, cambiar el color de un botón en la aplicación Java empresarial promedio requería 14 archivos en 6 paquetes. Martin Fowler lo llamó "la enfermedad empresarial". Las empresas no podían lanzar. No podían contratar a nadie que entendiera el sistema. No podían reescribir porque no podían documentar lo que hacía el sistema antiguo.
La solución tomó una década. Frameworks ligeros. TDD. CI. Ágil. La industria tuvo que reconstruir la capa de gestión alrededor de la tecnología.
La IA está haciendo lo mismo en un plazo comprimido.
Le dimos a cada desarrollador la capacidad de generar miles de líneas de código al día. El desarrollador que lo indicó no puede explicar lo que construyó. El revisor que lo aprobó no lo leyó. Y el siguiente desarrollador que lo herede lo tratará como una caja negra, porque eso es lo que es.
He observado esto en bases de código heredadas y en demos desde cero. Se rompen de las mismas maneras.
Estos son los 5 modos de fallo que vemos en los proyectos.
Los 5 modos de fallo de la IA en bases de código reales
1. El volumen generado por IA es el nuevo "tirar gente al problema".
Todos los CTOs compraron asientos de Cursor. Cada junta pidió el ROI. El ciclo de hype se completó en menos de un año.
Pero más código nunca fue el problema.
El 70% de las empresas Fortune 500 todavía ejecutan software de más de veinte años. Esas bases de código no son lentas porque los desarrolladores escriban demasiado lento. Son lentas porque nadie vivo en la empresa entiende todas las reglas de negocio codificadas en el código.
Dale acceso a un agente de IA a esa base de código. Producirá código funcional que pasa pruebas y viola contratos que nadie documentó.
Informe DORA 2026: las herramientas de IA ofrecen ganancias del 35-40% en tareas limpias desde cero. En bases heredadas, las mismas herramientas, 10% o menos. Una brecha de 4x.
El cuello de botella era la comprensión. La IA lo empeoró.
2. La deuda de comprensión es la nueva deuda técnica.
GitClear analizó 623 millones de cambios de código. La refactorización heredada cayó un 74% desde 2023. Las herramientas de IA generan código nuevo en lugar de reutilizar lo que existe. Una prueba que pasa. Un ticket cerrado. Sin consolidación contra el sistema existente.
Addy Osmani en Google lo llamó deuda de comprensión: la brecha entre cuánto código existe y cuánto entiende cualquier humano.
En una base de código de 6 meses, te recuperas. En un monolito de 10 años con integraciones no documentadas y lógica de negocio repartida en cientos de archivos, no.
La deuda técnica es código que sabes que es malo. La deuda de comprensión es código que no puedes evaluar en absoluto. La IA es la primera tecnología que genera el segundo tipo a escala.
3. El teatro de revisión es el nuevo sello de goma.
31% más PRs fusionados con cero revisión en el conjunto de datos de 22,000 desarrolladores de Faros AI. El tiempo medio de revisión se multiplicó por 5 porque los revisores no podían seguir el ritmo del volumen.
Más producción, menos control de calidad, nadie autorizado para frenarlo. Hemos visto este patrón organizativo cien veces antes de que existiera la IA. Ahora funciona a velocidad de máquina.
Anthropic encontró que los desarrolladores que usaban IA para delegación pasiva obtuvieron puntuaciones por debajo del 40% en pruebas de comprensión. Consulta activa: 65%+. Las mismas herramientas. La variable era el humano.
La mayoría de los equipos usan la IA para evitar pensar. Eso te pasa factura en producción.
4. Las personas que entienden el sistema tienen menos incentivos para alimentarlo a la IA.
Hablé con el director de ingeniería de una empresa de software respaldada por capital privado que factura ~$15M. Su equipo probó Claude internamente. Sus palabras: "Hizo un montón de tonterías".
Tiene razón en ser escéptico.
Ford dejó ir a ingenieros experimentados antes de que su conocimiento pudiera entrenar los sistemas de calidad. Tres años y miles de millones en costos de garantía después, recontrataron a 350 ingenieros veteranos. Esos ingenieros reentrenaron la IA. Reconstruyeron procesos de calidad. Ford ahora encabeza el Estudio de Calidad Inicial de JD Power 2026 por primera vez en 16 años.
Su VP de ingeniería de hardware: pensaron que ingerir requisitos de diseño produciría un producto de alta calidad. No fue así. La experiencia en el dominio tenía que venir primero.
Las personas que poseen el conocimiento institucional vieron la última ronda de iniciativas de "eficiencia". Saben lo que pasa después de que se documenta el proceso. Los gremios medievales mantenían sus métodos en secreto por la misma razón.
5. La base de código que más necesita la IA es donde la IA funciona peor.
Plataformas SaaS de mercado medio. Sistemas de salud. Backends logísticos. Productos de servicios financieros construidos por desarrolladores que se fueron hace años.
Estas empresas tienen clientes que pagan, ingresos reales y lógica de negocio que vale la pena preservar. Tienen la mayor superficie para que la IA acelere.
Cada herramienta de codificación de IA que se vende hoy asume que la base de código está limpia, la arquitectura es modular, el desarrollador puede darle al agente suficiente contexto. Esa suposición se rompe dentro de un monolito de 10 años con integraciones no documentadas y reglas de negocio que nadie recuerda haber escrito.
El 74% de las iniciativas de IA no escalan más allá del piloto, según Gartner. El modelo funciona bien. La base de código no estaba lista para ello.
Lo que realmente soluciona esto
Lo demostramos en un proyecto real. Dos ingenieros en una plataforma logística heredada. 330 PRs fusionados en 6 meses. ~90% de código generado por IA. El cliente los llamó su equipo de mejor rendimiento. Recibieron bonos discrecionales dos veces.
Ese resultado vino de la preparación, no de mejores modelos. Tres cosas sucedieron antes de que la IA tocara una línea de código.
Documenta antes de indicar. Lo llamamos Step Zero. Antes de que cualquier agente de IA toque una base de código heredada, escaneas el código existente, produces documentación legible por IA, haces que el sistema sea comprensible para las herramientas. El agente no puede razonar sobre lo que no puede ver. El cambio de Ford comenzó aquí. Trajeron de vuelta a las personas que entendían el sistema, documentaron lo que sabían, y solo entonces reentrenaron la IA.
Define las zonas. 80/20/0. 80% de código repetitivo (CRUD, pruebas, config, docs): la IA genera libremente. 20% de lógica de negocio e integraciones: modo copiloto, la IA redacta, el ingeniero reescribe. 0% de autenticación, pagos, cifrado, decisiones de arquitectura: la IA no toca nada. Esa disciplina evita que la deuda de comprensión se acumule.
Mide antes de escalar. Costo por commit. Patrones de uso del modelo. Porcentaje de código de IA. Métricas DORA en cada equipo. Línea base antes de la IA. Mide después. Sin esos datos, vuelas a ciegas hacia el mismo latigazo de aceleración que golpeó a 22,000 desarrolladores en el conjunto de datos de Faros.
Hacia dónde va esto
Microsoft comprometió $2.5 mil millones. Amazon comprometió $1 mil millones. Anthropic recaudó $1.5 mil millones. OpenAI recaudó $4 mil millones. Todo apuntado al mismo problema: hacer que la IA funcione dentro de empresas que ya existen.
El mercado se enfocó en proyectos desde cero porque las demostraciones se ven mejor. El mayor impacto en ingeniería vendrá de las empresas cuyas bases de código son las más feas, cuyos productos son los más antiguos, y cuyos pipelines se construyeron antes de que alguien hubiera oído hablar de un LLM.
El cuello de botella es el sistema de ingeniería debajo del modelo.
P.D. Esto es lo que hacemos en Limestone Digital. Integramos equipos de ingeniería nativos de IA en bases de código existentes. Step Zero, disciplina de zonas, infraestructura de medición. Si tu piloto de IA se estancó en una base de código heredada, envíame un DM.
Ponte en contacto: limestonedigital.com
