Tu IA acaba de producir deuda técnica en masa.
Se suponía que la IA haría mejor 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.
La IA hace tres cosas para los equipos de ingeniería: escribe código más rápido, detecta defectos antes y construye cosas que tu equipo actual no puede construir solo.
La industria apostó todo por lo 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 base.
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 de middleware.
Para 2005, cambiar el color de un botón en una app 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, y 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, Agile. La industria tuvo que reconstruir la capa de gestión alrededor de la tecnología.
La IA está haciendo lo mismo en un cronograma comprimido.
Le dimos a cada desarrollador la capacidad de generar miles de líneas de código al día. El desarrollador que lo escribió no puede explicar lo que construyó. El revisor que lo aprobó no lo leyó. Y el próximo desarrollador que lo herede lo tratará como una caja negra, porque eso es lo que es.
He observado esto en bases de código legacy y en demos desde cero. Se rompen de la misma manera.
Aquí están los 5 modos de falla que vemos en los proyectos.
Los 5 modos de falla de la IA en bases de código reales
1. El volumen generado por IA es la nueva "a base de personas".
Todos los CTO compraron asientos de Cursor. Todas las juntas directivas pidieron 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 muy despacio. Son lentas porque nadie vivo en la empresa entiende todas las reglas de negocio codificadas.
Dale acceso a un agente de IA a esa base de código. Producirá código funcional que pasa las pruebas y viola contratos que nadie documentó.
Informe DORA 2026: las herramientas de IA ofrecen ganancias del 35-40% en tareas verdes limpias. En legacy, 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 de legacy 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 te recuperas.
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 sin revisión en el conjunto de datos de 22,000 desarrolladores de Faros AI. El tiempo medio de revisión aumentó 5x porque los revisores no podían seguir el ritmo del volumen.
Más producción, menos control de calidad, nadie con poder para frenar. 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 menos del 40% en pruebas de comprensión. Con indagación activa: 65%+. Las mismas herramientas. La variable era el humano.
La mayoría de los equipos usan la IA para evitar pensar. Eso se cobra 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 con ~$15M en ingresos. 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 a 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 tienen 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 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.
Lo que realmente soluciona esto
Lo probamos en un proyecto real. Dos ingenieros en una plataforma logística heredada. 330 PRs fusionados en 6 meses. ~90% 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. Pasaron tres cosas antes de que la IA tocara una línea de código.
Documenta antes de escribir. Lo llamamos Step Zero. Antes de que un agente de IA toque una base de código legacy, 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 a la IA.
Define las zonas. 80/20/0. 80% de código repetitivo (CRUD, pruebas, configuración, documentación): 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. Esta 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 todos los equipos. Línea base antes de la IA. Medir después. Sin esos datos, estás volando 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 apuntando al mismo problema: hacer que la IA funcione dentro de empresas que ya existen.
El mercado se centró en proyectos nuevos porque las demostraciones se ven mejor. El mayor impacto de 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 escuchara 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 legacy, envíame un DM.
Ponte en contacto: limestonedigital.com
