La IA no genera deuda técnica. Genera algo peor.
AI-generated cruft es distinto al legacy code — más uniforme, más plausible, más difícil de detectar. Y se acumula 10x más rápido.
Toda discusión sobre “deuda técnica con IA” empieza mal. Asume que es el mismo problema de siempre — código mal escrito, atajos, hardcodes — solo que más rápido.
No es el mismo problema. Es uno nuevo.
La deuda técnica clásica es visible. El junior la ve y dice “esto está mal”. El linter la marca. El reviewer la rechaza. Es fea, y la fealdad funciona como señal.
La cruft generada por IA es invisible. Compila, pasa tests, sigue convenciones, no levanta linter. Y aún así está mal: usa la API equivocada de tu codebase, repite lógica que ya existía en otro helper, introduce una abstracción innecesaria que nadie va a mantener. La fealdad no funciona como señal porque no hay fealdad.
Por qué el AI-cruft es peor
Tres razones que vemos en proyectos:
1. Plausibilidad. El código se ve correcto. Sigue el estilo del repo, usa los mismos imports, parece “uno más de tantos PRs”. El reviewer entrenado para detectar olores no detecta nada — porque no hay olor.
2. Velocidad de acumulación. El junior con linter puede meter 2-3 bugs por semana. El junior con agente sin review puede meter 80 funciones-que-duplican-helpers-existentes por semana. La escala es órdenes de magnitud distinta.
3. Difícil arqueología. Cuando llega un bug y haces git blame,
el commit dice “feature X done”. El diff es de 14 archivos. Tú no
sabes qué decisiones tomó el agente, qué descartó, ni por qué. Hay
menos rastro humano que en código escrito a mano.
El patrón que ya está pasando
Empresas que adoptaron AI coding sin actualizar code review están viendo lo siguiente:
- Mes 1-3: productividad sube 3-5x. Todos felices.
- Mes 4-8: empiezan los bugs raros. Cosas que “no deberían pasar”. Features que dependen de helpers que tienen tres implementaciones casi idénticas, con bugs sutiles en una.
- Mes 9-12: el costo de tocar el código sube. Nadie quiere refactorizar porque “no sabemos qué tan profundo va el problema”. La velocidad regresa al baseline o por debajo.
Eso no es deuda técnica. Es deuda epistémica: nadie sabe ya qué hace el código ni por qué lo hace. Y eso cuesta más que la deuda técnica clásica porque no se paga con refactor — se paga con re-aprendizaje.
Cómo se detecta antes de que se acumule
Lo que vemos funcionar:
- Review obligatoria de cada AI-generated diff, con la persona que aprobó como responsable de defenderlo. No “el agente lo escribió” — tú lo aprobaste.
- Métrica de duplicación en CI: detectar funciones similares cross-archivo. La IA es prolífica en re-implementar lo que ya existe.
- ADRs como prerequisito: cualquier decisión arquitectónica nueva pasa por ADR. Eso fuerza al humano a articular intent — el agente no escribe ADRs (no debería).
- Tests que codifican intent: si un test pasa, el código representa el intent. Pero los tests también pueden generarse con IA — y entonces validan al agente contra sí mismo. Cuidado.
El reframe que importa
La pregunta vieja: “¿cómo evitamos deuda técnica?”. Linter, review, refactor.
La pregunta nueva: “¿cómo mantenemos que alguien entienda lo que mergeamos?”. Esa pregunta no se contesta con tooling — se contesta con cultura de review y ownership.
La pregunta para tu codebase
Si despides hoy a todo tu equipo y te quedas solo con el repo, los logs de CI y los PRs de los últimos 6 meses — ¿puedes reconstruir por qué cada decisión está como está?
Si la respuesta es no, ya tienes deuda epistémica. La técnica era el problema viejo. La nueva es saber qué hace tu propio código.
Si tu equipo siente esto y quieren prácticas concretas de review para evitarlo, conversemos — el chat está abierto.