# La deuda técnica de IA no es lo que creen los ingenieros URL: https://codebasechat.com/es/journal/deuda-tecnica-ia-codigo-cognitiva Type: blog Locale: es Published: 2026-07-14 Updated: 2026-07-14 --- > La deuda técnica de IA no es solo código duplicado. Dividimos el problema en deuda de código y deuda cognitiva, y explicamos por qué la mayoría de equipos solo miden una. ## La deuda técnica de IA no es lo que creen los ingenieros La deuda técnica de IA no es el desorden que parece. No es solo funciones duplicadas y nombres inconsistentes que un linter puede marcar. La mitad de ella se ve completamente bien en el pull request, pasa revisión, se fusiona, y solo aparece seis semanas después cuando nadie en el equipo puede explicar por qué un cambio en un lugar rompió tres cosas que nadie esperaba. Esa segunda mitad es la parte que la mayoría de los equipos no están midiendo en absoluto. ## La deuda técnica de IA son dos problemas diferentes, no uno solo Pregunta a cinco engineering managers cómo definen la deuda técnica de IA y obtendrás cinco respuestas, pero tienden a agruparse en dos categorías muy diferentes. La primera es la deuda de código: duplicación, patrones inconsistentes, código que es técnicamente correcto pero agrega superficie que nadie pidió. Este es el cubo para el que fueron construidas las herramientas de análisis estático. La segunda es la deuda cognitiva: la brecha entre qué tan rápido se genera código y qué tan rápido el equipo realmente construye un modelo mental compartido de lo que hace. La encuesta de desarrolladores 2026 "State of Code" de Sonar encontró que el 88% de los desarrolladores reportan al menos un impacto negativo de la IA en la deuda técnica, y el 53% dice que la IA genera código que se ve correcto pero introduce defectos ocultos. Eso es deuda de código. Lo que la encuesta no captura completamente es el segundo tipo, y [el reporte de LeadDev sobre el concepto](https://leaddev.com/ai/ai-coding-creates-two-kinds-of-debt-youre-only-measuring-one) es el tratamiento más claro que hemos leído. Tres equipos de cada cinco confunden los dos. Aquí está lo que los otros dos hacen diferente: rastrean la deuda de código con herramientas, y rastrean la deuda cognitiva con conversaciones. ## La parte de deuda de código: código que parece correcto pero no lo es La deuda de código es el tipo familiar. El código generado por IA tiende a duplicar lógica que ya existe tres archivos más allá, porque el asistente no sabe que la lógica existe a menos que esté en contexto. La encuesta de Sonar le pone número: el 40% de los desarrolladores dice que la IA ha aumentado la deuda generando código innecesario o duplicado. La variante peligrosa no es el código que se ve mal. Es el código que se ve bien. Una función pasa sus tests, maneja el camino feliz de manera limpia, y se lee como algo que escribiría un ingeniero senior, excepto que silenciosamente deja caer un caso límite que la implementación original manejaba. La revisión atrapa typos. La revisión es mucho peor atrapando una función plausible que sea sutilmente incompleta. `// Generado por IA: pasa tests, se ve limpio function getActiveUsers(users) { return users.filter(u => u.status === "active"); } // Lo que el original manejaba, tres archivos más allá: function getActiveUsers(users) { return users.filter(u => u.status === "active" && !u.deletedAt); }`Nada aquí lanza un error. Nada falla CI. La brecha solo aparece cuando un usuario soft-deleted reaparece en un reporte tres semanas después, y quienquiera que sea paged tiene que hacer grep, blame, y preguntar alrededor para descubrir cuál versión es correcta y por qué. Ese loop de grep-y-pregunta es el costo real, y se mide en horas, no en un sentido vago de que algo se siente mal. Las herramientas docs-as-code que se sientan al lado del repo en lugar de en un wiki separado reducen cuán a menudo sucede ese loop, porque el razonamiento detrás de una función vive un clic del código en lugar de en la memoria de alguien. ![Primer plano de manos en un teclado con un diff de código rojo y verde visible en la pantalla borrosa detrás](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/eaeaef-inline1.webp) ## La parte de deuda cognitiva: cuando el equipo pierde el hilo La Dra. Margaret-Anne Storey, profesora de informática en la Universidad de Victoria, acuñó el término "deuda cognitiva" en octubre de 2025 después de ver a sus estudiantes enviar rápido con IA y luego luchar para actuar sobre su propio feedback de usuarios. Su diagnóstico: los estudiantes no habían perdido el rastro del código, habían perdido el rastro de lo que estaban construyendo y por qué, y quién en el equipo sabía qué. Ese enfoque toma prestado del viejo argumento de Peter Naur de que el software no es realmente el código, es la teoría compartida en la cabeza de las personas que lo construyeron. Cuando el código se genera más rápido de lo que el equipo puede construir esa teoría, la teoría nunca se forma. Puedes tener un codebase limpio, completamente testeado, y aún tener deuda cognitiva significativa si las personas que lo enviaron no pueden explicarlo completamente, o si solo una persona puede. Esta es la parte que las métricas estándar de deuda técnica de IA pierden completamente, porque los dashboards rastrean el código, no la comprensión. La pregunta que vale la pena hacer en tu próximo retro es contundente: coloca un diagrama de arquitectura, y pregunta quién en el equipo puede explicar cada caja. Si la respuesta es "una persona, y están de vacaciones esta semana", tienes deuda cognitiva independientemente de lo que tu linter dice. Un wiki interno viviente no arregla la deuda cognitiva por sí solo. Le da al equipo un lugar para escribir el "por qué" antes de que viva en la cabeza de una sola persona solamente, que es un comienzo. ![Tres ingenieros de pie frente a una pizarra esbozando un diagrama de arquitectura de sistemas juntos](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/e90110-inline2.webp) ## Por qué la revisión de código no puede seguir la velocidad de generación Aquí está el problema mecánico debajo de ambos tipos de deuda: la IA permite que un ingeniero genere una semana de código antes del almuerzo, pero la capacidad de revisión no se ha escalado en absoluto. El cuello de botella se movió de escribir a leer, y leer es la parte que nadie aceleró. Aquí es donde la comparación de herramientas realmente importa, y vale la pena ser específico en lugar de vago. Copilot y Cursor son rápidos generando código dentro del archivo que ya tienes abierto, que es exactamente por qué son buenos produciendo más código del que un equipo puede revisar. Cody y Continue.dev se inclinan más hacia recuperación a través del repo antes de generar, que ayuda a evitar el problema de duplicación anterior, pero ninguno reemplaza el paso humano de decidir si el código nuevo se ajusta a cómo se supone que funciona el sistema. Ninguno de ellos te dice si la persona fusionando el PR realmente entiende lo que cambió, que es una pregunta diferente a si el diff es sintácticamente correcto. Las herramientas ask-your-codebase existen por esta brecha específicamente: la forma más rápida de revisar código generado por IA bien es poder preguntar, en lenguaje natural, "dónde más existe este patrón" o "qué ya maneja este caso", antes de que apruebes el merge. Esa pregunta solía tomar a un ingeniero senior veinte minutos de grep y blame. No debería. También hay un efecto de tamaño de repo que vale la pena nombrar. En un servicio de 5,000 líneas, un revisor puede sostener la mayoría del sistema en su cabeza, así que una función plausible resalta porque no coincide con el modelo mental del revisor. En un monorepo de 80,000 líneas tocado por seis equipos, ningún revisor tiene ese modelo mental más, así que el código plausible pasa simplemente porque nadie en la sala tiene el contexto para notar que está mal. Cuanto más grande el repo, más el cuello de botella de revisión depende de herramientas en lugar de la memoria de un ingeniero senior. ## Los juniors pagan esta deuda primero, y más rápido Anthropic ejecutó un estudio controlado en enero de 2026, un ensayo aleatorizado con 52 desarrolladores junior, y encontró que quienes usaron asistentes de IA obtuvieron un 17% menos en pruebas de comprensión de código, aproximadamente dos calificaciones de letras. El equipo de ingeniería interna de Infobip, ejecutando un programa de pasantía desde 2022 con 225 interns, vio el mismo patrón en datos longitudinales reales: cohortes pre-IA crecieron en promedio 2.50 puntos en habilidad técnica auto-evaluada durante una pasantía; cohortes de era de IA crecieron 1.56. El mecanismo no es el uso de IA en sí. Dos interns en la cohorte más reciente de Infobip usaron IA a la misma frecuencia, con resultados opuestos. Uno hizo preguntas de seguimiento y pudo explicar completamente lo que produjo la IA; su crecimiento fue el más alto en la cohorte. El otro aceptó output con revisión mínima, lo trató como una caja negra, y creció por cero. La herramienta era idéntica. La relación con ella no lo fue. Grabar sesiones de pairing y walkthroughs de arquitectura, y hacerlas buscables después, da a los juniors algo a qué volver en lugar de re-preguntar la misma pregunta a quien esté disponible. No reemplazará un mentor, pero reduce el costo de preguntar dos veces. ![Un ingeniero senior apuntando a una pantalla de laptop mientras un ingeniero junior se inclina para seguir](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/ec3aa0-inline3.webp) ## Salta la recomendación "Prohibir IA a Juniors" Cada resumen sobre este tema aterriza en la misma recomendación eventualmente: restringir acceso a IA para ingenieros junior hasta que lo hayan "ganado". Salta esa. No coincide con lo que los equipos que realmente midieron el problema encontraron, e intercambia un modo de fallo por otro; juniors que no pueden usar las herramientas que su equipo envía quedan rezagados de una manera diferente, igualmente real. Lo que funcionó para Infobip fue secuenciación, no prohibición: intenta el problema primero, chequea con IA segundo, así el hábito de pensamiento independiente se forma antes de que la IA se convierta en el movimiento default. Agregaron checkpoints sin IA, no como castigo sino como calibración, así tanto intern como mentor saben dónde la habilidad realmente está. Los mentores también cambiaron de revisar pull requests a rastrear proceso: quién preguntó qué, quién se quedó atascado dónde, quién explicó su propio cambio sin ayuda. Las puntuaciones de satisfacción subieron el tiempo entero mientras el crecimiento de habilidad caía, que es la advertencia real en sus datos: si solo estás rastreando cómo la gente se siente sobre las herramientas, no verás esto venir. El 20% de interns en la cohorte más reciente de Infobip no sabía qué se esperaba de un ingeniero junior en su nivel en primer lugar, lo que hizo que la auto-evaluación fuera casi sin sentido. No puedes medir una brecha contra un punto de referencia que nadie escribió. ## Qué realmente cambiaríamos este sprint Comienza con la pregunta de retro anterior: quién puede explicar cada parte del sistema, en voz alta, ahora. Esa pregunta única expone más deuda cognitiva en diez minutos que cualquier dashboard lo hará. Para deuda de código, mantén análisis estático en el loop. [La encuesta de desarrolladores 2026 de Sonar](https://www.sonarsource.com/blog/how-ai-is-redefining-technical-debt/) muestra que el 70% de los desarrolladores ya lo usan, y los equipos que lo ejecutan reportan resultados significativamente mejores en costo de rehacer que equipos que lo saltan. Esa no es una recomendación controvertida, es solo una que los equipos saltan cuando se mueven rápido porque el output de IA se veía terminado. El trabajo que la IA quita de escribir código no desaparece. Sonar llama a esto el "gran cambio de trabajo": reaparece aguas abajo, en gestionar deuda y corregir output de IA. Automatizar las partes recurrentes de ese triage, marcar PRs antiguas, enrutar requests de revisión, perseguir follow-ups, libera tiempo de senior para la parte que realmente requiere un humano: decidir si el equipo entiende lo que acaba de enviar. Mide trayectoria, no satisfacción. Un equipo que se siente bien sobre la IA y no puede explicar su propia arquitectura en seis meses no ha ahorrado tiempo. Lo ha tomado prestado, a una tasa que nadie escribió. ## FAQ ### ¿Cuál es la diferencia entre deuda de código y deuda cognitiva? La deuda de código es el problema técnico: duplicación, patrones inconsistentes, que se miden con herramientas de análisis estático. La deuda cognitiva es la brecha entre qué tan rápido se genera código y qué tan rápido el equipo construye un modelo mental compartido de lo que hace. Requiere conversación para medir, no dashboards. ### ¿Por qué el 88% de desarrolladores reportan impacto negativo de IA en deuda técnica? Según la encuesta 2026 'State of Code' de Sonar, el 53% dice que la IA genera código que se ve correcto pero introduce defectos ocultos; el 40% reporta código duplicado o innecesario. El código que pasa revisión pero causa problemas después es el problema más difícil de detectar. ### ¿Cómo mido deuda cognitiva si mi linter no la captura? Haz una pregunta simple en tu próximo retro: coloca un diagrama de arquitectura y pregunta quién en el equipo puede explicar cada componente. Si solo una persona puede, tienes deuda cognitiva, independientemente de lo que tus herramientas digan. ### ¿Debe mi equipo prohibir IA a los juniors? No. Los datos de Infobip muestran que la secuenciación funciona mejor: intenta el problema primero, chequea con IA segundo. Esto forma hábitos de pensamiento independiente antes de que la IA sea el default. Los juniors que no pueden usar las herramientas quedan rezagados de otra manera. ### ¿Cuál es el costo real de esta deuda? Es medible en horas, no en sentimientos. Cuando un cambio rompe tres cosas inesperadamente, alguien hace grep, blame y pregunta alrededor — ese loop de diagnóstico es el costo real. Multiplicado por la frecuencia de esos incidentes.