Deuda técnica bajo control: la guía del CTO para gestionarla con pair programming con IA
La deuda técnica es ese problema que todos los CTOs con los que hablo reconocen tener — y que casi ninguno presupuesta.
He pasado suficientes años dentro de codebases enterprise como para decirlo sin rodeos: la deuda técnica no es un problema que se resuelva, es un problema que se gestiona. Toda organización de ingeniería la acumula. La pregunta no es si tienes deuda; es si tus decisiones sobre la deuda son deliberadas o accidentales.
Lo que ha cambiado en 2025 es la economía de retirarla. El pair programming con IA — no como novedad, no como el autocompletado de Copilot, sino como un codesarrollador de verdad — ha reducido el coste del refactoring, la migración y la modernización a una fracción de lo que costaban hace 18 meses. Eso no arregla tu problema de deuda por sí solo. Pero sí significa que las conversaciones que llevas posponiendo porque "no tenemos tiempo" ahora tienen una respuesta distinta.
Este es el manual que yo seguiría para gestionar la deuda técnica con cabeza en 2025.
Qué es realmente la deuda técnica (y qué no es)
La mayoría de las discusiones sobre deuda técnica fracasan porque el término se usa con imprecisión. Antes de montar un framework de gestión, categoriza bien.
Deuda deliberada: trade-offs conscientes en los que elegiste velocidad antes que perfección. Una startup que lanza un MVP con tests mínimos, una scale-up que pospone un refactor porque la feature era urgente. Es deuda útil — sirvió para conseguir algo valioso. Hay que registrarla y, en algún momento, pagarla.
Deuda heredada: código escrito por gente que ya no está en el equipo, o para requisitos que ya no existen. Es la categoría más común. Suele ser más cara de arreglar de lo que parece, porque el contexto original se ha perdido.
Deuda arquitectónica: decisiones estructurales de fondo que ya no encajan con la escala del sistema, sus casos de uso o la estructura del equipo. Es la categoría más cara. Microservicios que proliferan sin control, monolitos que deberían haberse partido hace tres años, modelos de datos incapaces de soportar nuevas líneas de producto.
Deuda accidental: código roto o ineficiente porque lo escribieron ingenieros que no sabían hacerlo mejor. Es la categoría más barata de abordar de forma aislada — el pair programming con IA brilla aquí — pero el problema organizativo (contratación, calidad de las reviews, mentoría) suele importar más que el código.
Deuda por deterioro: código que estaba bien cuando se escribió pero que se ha degradado porque el ecosistema a su alrededor avanzó. Librerías deprecadas, frameworks en end-of-life, vulnerabilidades de seguridad en dependencias. Se acumula sin parar si no la gestionas activamente.
Cada categoría exige un enfoque distinto. Tratarlas todas igual es la razón de que la mayoría de las «iniciativas de reducción de deuda técnica» fracasen.
Mide la deuda en coste de negocio, no en métricas de código
No puedes gestionar lo que no mides. Pero "medir la deuda técnica" suele significar algo vago: puntuaciones de complejidad, porcentajes de cobertura de tests, warnings del linter. Eso son señales, no mediciones.
Las mediciones que importan son las que conectan la deuda con el coste de negocio:
Impacto en la velocidad: ¿Cuánto más lenta sale una feature típica en una zona cargada de deuda frente a una zona limpia? Mídelo comparando features de complejidad similar en distintas partes del codebase. Una diferencia de 3x es habitual y material.
Correlación con incidentes: ¿Qué porcentaje de los incidentes de producción tiene su origen en código legacy? Si supera el 40%, la deuda te está costando más de lo que ahorras al aplazarla.
Tiempo de onboarding: ¿Cuánto tarda un ingeniero senior recién llegado en ser productivo en cada zona del codebase? En las zonas con mucha deuda tarda 2–3 veces más. Ese coste es real cada vez que contratas.
Riesgo de cambio: ¿Qué probabilidad hay de que un cambio no trivial en un módulo provoque una regresión en otro sitio? Un riesgo de cambio alto es un síntoma directo de deuda arquitectónica.
Percepción de los desarrolladores: una encuesta trimestral preguntando a los ingenieros en qué zonas evitan trabajar. Las zonas que todo el mundo esquiva suelen ser donde la deuda está matando la velocidad.
Estas mediciones no necesitan un dashboard. Necesitan existir en algún sitio donde el equipo las vea, para que la deuda pase de invisible a visible.
Prioriza por impacto en el negocio, no por lo que molesta al ingeniero
Con las mediciones en marcha, priorizar la deuda se vuelve abordable. El framework que funciona:
| Impacto / Esfuerzo | Bajo esfuerzo de arreglo | Alto esfuerzo de arreglo |
|---|---|---|
| Alto impacto de negocio | Hazlo ya — son las victorias fáciles que recuperan valor compuesto | Planifícalo y fináncialo — son las iniciativas arquitectónicas que necesitan capacidad dedicada |
| Bajo impacto de negocio | Arréglalo de forma oportunista, cuando ya estés tocando ese código | No lo arregles — acepta la deuda, documéntala y sigue adelante |
Los errores habituales:
- Tratar toda la deuda como de alto impacto porque los ingenieros se quejan de ella. Los ingenieros se quejan de la deuda que les molesta, que no siempre es la que hace daño al negocio.
- Tratar toda la deuda como de alto esfuerzo porque hay una pieza difícil a la vista. La mayoría de la deuda tiene arreglos baratos si te molestas en buscarlos.
- Arreglar deuda que nadie pidió arreglar porque "es lo correcto". Los arreglos de deuda deberían ir alineados con las prioridades de producto, no con la estética de ingeniería.
El resultado de la priorización debería ser una lista corta: los 3–5 elementos de mayor impacto y menor esfuerzo que se abordarán este trimestre, más las 1–2 iniciativas arquitectónicas que se planifican y financian aparte.
El pair programming con IA como herramienta para retirar deuda
Aquí es donde 2025 es genuinamente distinto de 2023. El pair programming con IA — al nivel de Cursor, Claude Code, Copilot Workspace o herramientas similares — ya no es solo una ayuda de productividad para trabajo greenfield. Es un multiplicador de fuerza serio para el tipo de trabajo metódico y denso en contexto que exige retirar deuda.
Las tareas concretas donde el pair programming con IA destaca:
1. Migraciones de lenguaje y de framework
Pasar de JavaScript a TypeScript, de Python 2 a Python 3, de Express a Fastify, de componentes de clase a hooks. Es trabajo mecánico pero sensible al contexto — del que le lleva semanas a un ingeniero senior y meses a uno junior. Bien usado, el pair programming con IA lo comprime a días.
El patrón que funciona: empareja a un ingeniero senior con un asistente de IA para hacer unos pocos archivos a mano, codifica los patrones en un prompt bien especificado, y después usa la IA para ejecutar la misma transformación en el resto del codebase con review humana. El rol del ingeniero pasa de escribir a revisar y detectar edge cases — una ganancia de apalancamiento de 5–10x.
2. Mejoras de cobertura de tests
Añadir tests a código legacy es trabajo ingrato y denso en contexto, perfecto para el pair programming con IA. Dada una función y unos pocos casos de test de ejemplo, la IA moderna genera scaffolding útil de tests más rápido que un ingeniero. El rol del ingeniero es verificar que los tests realmente ejercitan la lógica, añadir los edge cases que a la IA se le escaparon e identificar cuándo una función "cubierta" sigue estando rota de fondo.
3. Documentación y comentarios de código
Mucha deuda es en realidad deuda de contexto: código que funciona pero del que nadie recuerda el porqué. El pair programming con IA puede leer un módulo, extraer su comportamiento y generar documentación arquitectónica con una calidad razonable. Esto, por sí solo, ya amortiza el tooling en la mayoría de equipos.
4. Refactoring para legibilidad
Renombrar variables para ganar claridad, extraer funciones helper, partir funciones largas, eliminar código muerto. La IA hace casi todo el trabajo mecánico; el ingeniero verifica que el refactor realmente mejora las cosas.
5. Actualizaciones de dependencias y parches de seguridad
Actualizar un framework suele exigir cientos de cambios pequeños: imports, firmas de API, patrones deprecados. El pair programming con IA puede mapear el alcance completo de los cambios necesarios, redactar las modificaciones y señalar las zonas que requieren juicio humano. Lo que antes costaba un sprint puede costar una tarde.
Dónde no funciona el pair programming con IA
Seamos precisos con los límites:
- Rediseños arquitectónicos. La IA puede ayudarte a implementar una nueva arquitectura, pero no puede decirte cuál es la correcta. Las decisiones estratégicas exigen criterio senior.
- Entender el conocimiento tribal. Si la deuda existe por una regla de negocio que no está ni en el código ni en los comentarios, a la IA se le escapará. La arqueología humana sigue siendo necesaria.
- Deuda entre sistemas. El pair programming con IA rinde mejor en deuda a nivel de código. La deuda a nivel de sistema — servicios que deberían consolidarse, modelos de datos que cruzan fronteras de propiedad — requiere trabajo estratégico humano.
Despliega la IA como tooling de squad, no como una ventaja individual
La mayoría de los equipos no extraen todo el valor del pair programming con IA porque lo despliegan como herramienta de productividad individual. El patrón de despliegue que multiplica la velocidad de retirada de deuda:
1. Squads dedicados a retirar deuda
En lugar de repartir el trabajo de deuda por todo el equipo, destina 2–4 ingenieros con el pair programming con IA como herramienta principal, enfocados en una zona de deuda concreta durante una ventana de tiempo concreta. El foco concentrado más el apalancamiento de la IA produce resultados que el esfuerzo disperso no puede igualar.
2. Librería de prompts compartida
Los ingenieros que más rendimiento sacan del pair programming con IA tratan los prompts como artefactos. Guardan los que funcionan para tipos concretos de refactoring, los comparten con el resto del equipo e iteran sobre ellos. Una librería compartida de 30–50 prompts probados para patrones comunes de deuda vale más que la mayoría de las herramientas.
3. Cultura de review primero
El pair programming con IA funciona cuando los humanos lo revisan todo. Falla cuando los humanos aprueban el output de la IA sin mirarlo. Un squad de retirada de deuda debería mantener al menos una ratio 2:1 de tiempo de review frente a generación, con ingenieros senior fijando el listón de calidad.
4. Medición antes y después
Cada iniciativa de retirada de deuda debería tener mediciones antes/después sobre las métricas que importan: cobertura de tests, tasa de incidentes, riesgo de cambio, percepción de los desarrolladores. Si no, solo estás moviendo código de sitio.
Las herramientas no arreglan la deuda — la arreglan las organizaciones
Y las organizaciones solo la arreglan cuando deciden hacerlo. La disciplina que separa a las que gestionan bien la deuda de las que la acumulan:
La deuda se financia, no se tolera. El presupuesto de ingeniería asigna capacidad explícita a retirar deuda. Típicamente, un 15–25% de la capacidad de ingeniería. No "cuando tengamos tiempo": capacidad comprometida.
Las decisiones de deuda se documentan. Cada decisión de deuda deliberada recibe un ADR corto (architectural decision record) que explica qué se eligió, por qué, y cuánto costaría pagarla más adelante. Esto evita el problema de "no sabemos por qué esto está aquí".
Las revisiones de deuda son trimestrales. Cada trimestre, el CTO y los tech leads revisan el registro de deuda, las mediciones y el plan de retirada. Es el mecanismo que obliga a que la deuda no vuelva a hacerse invisible.
La velocidad de retirada se mide. La cantidad de deuda retirada por trimestre debería ser medible y tender en la dirección correcta. Si no lo hace, o la asignación está mal o la priorización está mal.
Los squads nearshore resuelven la política del trabajo de deuda
Un patrón que funciona especialmente bien en organizaciones con problemas reales de deuda: usar capacidad de ingeniería nearshore como squads dedicados a retirarla.
La lógica: retirar deuda es trabajo de alto impacto pero con poco brillo político. Los equipos in-house se resisten porque no luce en las demos. Los squads nearshore, desplegados en engagements acotados de 3–6 meses específicamente para retirar deuda, tienen el foco y el nivel técnico para ejecutar sin esa fricción política.
La estructura de engagement que funciona:
- Llamada de descubrimiento con el CTO para entender el panorama de deuda y priorizar qué merece la pena abordar.
- Diseño del squad: 2–4 ingenieros senior nearshore más un tech lead, con pair programming con IA como tooling estándar.
- Alcance acotado: módulos concretos, resultados concretos, antes/después medible. No "reducir deuda" — "retirar el middleware de auth legacy y consolidar tres response handlers antes de que acabe el Q3".
- Plan de handoff: transferencia clara de la propiedad de vuelta al equipo in-house al final del engagement.
Esto no es externalizar tu ingeniería core. Es añadir un squad de retirada dedicado durante un período acotado para acelerar trabajo al que tu equipo in-house no llega — sin aumentar la plantilla permanente.
La deuda que nunca deberías pagar
Un apunte contraintuitivo: hay deuda que nunca debería retirarse. Debería quedarse tal cual, documentada y olvidada.
- Deuda en código que vas a retirar. Si vas a abandonar un sistema legacy en 6 meses, no lo refactorices. Invierte esa capacidad en otra parte.
- Deuda en código que apenas se toca. Si un módulo no ha cambiado en 18 meses y no causa incidentes, la deuda es teórica. Ignórala.
- Deuda que es pragmatismo razonable. No todo el código necesita ser elegante. Si funciona, se entiende y no bloquea nada, está bien como está.
La disciplina consiste en distinguir la deuda que te hace daño de la que solo es estéticamente desagradable. El pair programming con IA abarata arreglar la primera; ni la IA ni los ingenieros deberían perder el tiempo con la segunda.
¿Tienes por delante un programa de retirada de deuda que no puedes dotar internamente? Habla con un CTO sobre desplegar un squad nearshore dedicado, con pair programming con IA, para retirar deuda en un plazo acotado y medible.
