Deuda de verificación en el desarrollo con IA: hipótesis, explicaciones rivales y mitigación

Por Alfredo Castillejos · Dixi-Project · 16 de octubre de 2026 · 12 min de lectura

Con inteligencia artificial, un equipo genera software más rápido de lo que puede verificarlo. Esa diferencia no desaparece: se acumula como deuda de verificación. Y si el código pendiente se vuelve más caro de revisar con el tiempo, porque otros cambios ya dependen de él, la deuda crece de forma exponencial.

Los datos públicos de GitHub ya muestran el síntoma. Entre enero de 2024 y septiembre de 2026, los pull requests (PRs) integrados al mes crecieron 5.6 veces; los aprobados por otra persona, solo 2.6. Lo que todavía no está demostrado es el daño: que ese código sin verificar termine en más fallas.

Este artículo propone qué hipótesis hay que contrastar, qué explicaciones rivales podrían dar cuenta de los mismos datos sin que haya un problema grave, y qué palancas existen para mitigar. La conclusión central: el objetivo no es eliminar la deuda, sino mantenerla bajo un umbral y concentrar la verificación donde fallar cuesta caro. Y actuar temprano cuesta mucho menos que actuar tarde.

El planteamiento

Un programador con IA genera más código del que puede revisar. Para compensar, añade pruebas, especificaciones y arquitectura. Pero ese andamiaje también lo genera la IA, y también supera la capacidad humana de revisión. Lo que queda es una deuda que crece con el tiempo.

El modelo DVI (deuda de verificación y riesgo de IA) lo expresa en tres ecuaciones:

\frac{d D}{d t} = α G - V + δ D, D \geq 0

P_{fallo} = 1 - (1 - p_{c}) \prod_{i} [1 - p_{i} (1 - s_{i})]

L = \sum_{i} P (F_{i}) C_{i}

Símbolo	Significado
D	Deuda de verificación acumulada, en horas de verificación pendientes
G	Cambios generados por día
α	Horas necesarias para verificar un cambio
V	Horas de verificación efectiva por día
δ	Tasa a la que la deuda pendiente se encarece (retrabajo, dependencias)
p_i, s_i	Probabilidad de defecto en el cambio i y de que la validación lo detecte
p_c	Probabilidad de falla de causa común: el código y sus pruebas comparten el mismo error
C_i	Costo de que el fallo i llegue a producción
L	Pérdida esperada

Con parámetros constantes, la deuda sigue esta curva:

D (t) = \frac{α G - V}{δ} (e^{δ t} - 1)

De ella salen tres resultados que no son obvios:

Hay un punto de no retorno. Si la deuda supera el umbral D*, sigue creciendo aunque se verifique más rápido de lo que se genera.

D^{*} = \frac{V - α G}{δ}

La velocidad entra en el exponente. Si el encarecimiento depende del ritmo de cambio (δ = βG), generar más no solo suma deuda: acelera su crecimiento.
Existe un piso de riesgo. La probabilidad de falla nunca baja de p_c. Más pruebas generadas por la misma IA no reducen el riesgo de que código y pruebas compartan el error.

Lo que dicen los datos

Recolectamos los datos el 16 de octubre de 2026 con la API pública de GitHub:

Indicador	Ene-2024	Sep-2026
PRs integrados al mes	3.28 M	18.4 M
PRs integrados con aprobación de otra persona	0.67 M	1.76 M
ρ̂ = PRs integrados por cada aprobado	4.9	10.5
PRs integrados sin ninguna revisión	76.7%	89.3%
PRs firmados por agentes de IA	casi 0	18.7%

En una muestra de PRs de repositorios con al menos 10 estrellas, un PR firmado por Claude Code se integra en una mediana de 58 minutos, contra 19 días de uno sin IA. Además, recibe 4.8 veces menos revisiones por cada 1,000 líneas.

Un dato va en contra de la intuición: los PRs de agentes no son más grandes. La presión viene del número de cambios, no de su tamaño.

Qué está demostrado y qué no

Afirmación	Estado
La generación de cambios crece mucho más rápido que la aprobación humana	Demostrado con datos públicos
La proporción de código que entra sin revisión de otra persona está subiendo	Demostrado
Ese código sin revisión produce más fallas, incidentes o retrabajo	Pendiente
La deuda crece de forma exponencial (δ > 0)	Pendiente: el modelo lo permite, falta estimar δ
Las pruebas generadas por la IA comparten los errores del código de la IA	Plausible: hay antecedentes, falta el experimento

El salto del síntoma al daño es justo lo que hay que probar, y lo que un crítico atacará primero.

Hipótesis a confirmar

Cada hipótesis viene con el resultado que la refutaría.

	Hipótesis	Qué esperaríamos encontrar	Qué la refutaría
H1	Divergencia: con ρ > 1 sostenido, la deuda crece	Líneas sin revisión acumuladas por repositorio, en aumento	Repositorios con ρ > 1 durante 8 semanas o más sin acumulación
H2	Amplificación: δ > 0, el crecimiento es más que lineal	El modelo con δ predice mejor fuera de muestra que el lineal	El modelo lineal ajusta igual o mejor
H2b	La velocidad en el exponente: δ crece con G	Los equipos más rápidos tienen más retrabajo por cambio	La relación entre δ y G no es positiva
H3	Causa común: las pruebas de la misma IA no detectan los errores de esa IA	Más mutantes sobreviven a sus pruebas que a pruebas escritas desde la especificación	No hay diferencia entre ambas suites
H4	Saturación: arriba de cierto ρ, producir más deja de dar más software confiable	Los defectos que escapan crecen más rápido que los PRs	El software confiable sigue creciendo con G
H5	Histéresis: con deuda alta, verificar más ya no basta para bajarla	Equipos que suman revisores y no reducen su deuda	La deuda baja siempre que V > αG

Explicaciones rivales

Son explicaciones que dan cuenta de los mismos datos sin que haya un problema grave. Conviene plantearlas antes que nadie y decir qué dato las separa de la tesis.

	Rival	Si fuera cierta	Cómo distinguirla
R1	Desplazamiento. La verificación no desaparece: pasa de la revisión humana a CI, tipos, análisis estático y monitoreo en producción	La verificación real es mucho mayor que la medida	Si la tasa de cambios fallidos y los reverts se mantienen planos mientras ρ̂ sube, gana R1
R2	Selección. Lo que entra sin revisión es de bajo riesgo: prototipos, documentación, repositorios personales	La deuda existe, pero fallar casi no cuesta	Si en repositorios con usuarios o dependientes ρ no sube, gana R2
R3	Mejor calidad base. El código de IA tiene menos defectos por línea	La deuda crece en horas, pero su riesgo crece menos	Comparar defectos por cada 1,000 líneas de código de IA y humano
R4	Pago diferido. La deuda se paga más tarde como incidentes, vulnerabilidades y reescrituras	Es la tesis vista desde el costo	Código reescrito en menos de dos semanas, vulnerabilidades, proyectos abandonados
R5	Aprobar sin revisar. Las aprobaciones crecen, pero cada una revisa menos	El problema es peor de lo que mide ρ̂	Comentarios y tiempo por aprobación. Ya hay una señal: 1.23 frente a 5.92 revisiones por cada 1,000 líneas

R1 y R2 son las que podrían desactivar la alarma, y R5 la agravaría. R4 no es una rival: es la misma tesis medida en dinero. Un estudio serio tiene que medir las tres primeras.

¿Hay que mitigar?

Sí, pero no para llevar la deuda a cero. Verificarlo todo a mano anularía la ventaja de la IA. Hay deuda aceptable, como la de un prototipo que se va a tirar, y deuda inaceptable, como la de un cambio en pagos, autenticación o datos personales.

El objetivo correcto tiene dos partes:

Mantener la deuda bajo el punto de no retorno. Por encima de él, el sistema deja de ser recuperable con esfuerzo normal.
Minimizar la pérdida esperada, no la deuda. La misma hora de verificación vale mucho más en un cambio cuyo fallo cuesta caro.

La deuda de verificación es una decisión de riesgo. Se puede tomar a conciencia, como cualquier otra deuda, siempre que se sepa cuánta hay, dónde está y cuánto cuesta si falla.

Las palancas de mitigación

Cada término de la fórmula es un lugar donde intervenir.

Palanca	Mecanismos	Costo o riesgo
Bajar G: generar menos	Limitar el trabajo en curso; presupuesto de cambios por ciclo	Renuncia a parte de la productividad
Bajar α: que verificar cueste menos	PRs pequeños (la detección de defectos cae arriba de 500 líneas por hora de revisión); especificación antes del código; tipos estrictos	Barato y muy efectivo
Subir V: más capacidad	Verificación automática independiente: pruebas basadas en propiedades, de mutación y de contrato; análisis estático; métodos formales en el núcleo crítico	Solo cuenta si no comparte sesgo con quien generó el código
Bajar δ: que la deuda no se pudra	Modularidad y bajo acoplamiento; contratos versionados; decisiones registradas; revisar pronto	Cambia la forma de la curva: de exponencial a lineal
Bajar p_c: romper la causa común	Pruebas escritas antes del código y congeladas; pruebas de otra persona u otro modelo; revisión con un modelo distinto al que generó	Es lo único que baja el piso de riesgo
Bajar C_i: que fallar cueste menos	Despliegue gradual; feature flags; reversión automática; radio de impacto acotado	No reduce la deuda, la vuelve tolerable
Asignar por riesgo	Revisión humana completa solo donde fallar cuesta caro; el resto, automática	Exige clasificar el riesgo de cada cambio

Cuánto mueve cada palanca

Simulamos cada palanca con el propio modelo. Los parámetros son ilustrativos, no medidos: 100 cambios por día, 1.2 horas por cambio, 70 horas de verificación por día y δ = 0.2% diario.

Deuda de verificación a 24 meses por escenario: base, bajar α, bajar δ y combinada

Escenario	A 30 días	A 1 año	A 2 años	Frente a la base
Base	1,546 h	26,877 h	82,649 h	—
Bajar α de 1.2 a 1.0 h por cambio	928 h	16,126 h	49,589 h	−40%
Subir V de 70 a 90 h por día	928 h	16,126 h	49,589 h	−40%
Bajar G de 100 a 80 cambios por día	804 h	13,976 h	42,977 h	−48%
Bajar δ de 0.2% a 0.1% diario	1,523 h	22,026 h	53,754 h	−35%
Combinada: α = 1.0 y δ = 0.1%	914 h	13,215 h	32,252 h	−61%
Verificar al ritmo de generación (V = 120 h)	0 h	0 h	0 h	−100%

Tres lecturas:

Bajar α equivale a contratar capacidad. Ahorrar 0.2 horas por cambio rinde lo mismo que sumar 20 horas diarias de verificación, y suele costar mucho menos: PRs más chicos y mejor especificados.
δ casi no se nota al mes y domina a los dos años. A 30 días, bajar δ a la mitad reduce la deuda menos de 2%; a dos años, 35%. Por eso la inversión en arquitectura parece inútil en el corto plazo y es decisiva en el largo.
Actuar tarde cuesta más. Para frenar la deuda desde el día cero bastan 120 horas diarias de verificación. Si se espera un año, con 26,877 horas ya acumuladas, hacen falta 174 horas diarias, un 45% más, solo para que deje de crecer.

Controles según el riesgo del cambio

Riesgo	Ejemplos	Controles mínimos
Bajo	Documentación, estilos, prototipos, scripts internos	Verificación automática; se acepta integrar sin revisión humana
Medio	Funcionalidad de negocio sin datos sensibles	Pruebas escritas antes del código; PRs de 400 líneas o menos; revisión de un agente y confirmación humana
Alto	Autenticación, datos personales, dinero, entradas externas	Todo lo anterior, más revisión humana línea a línea, modelo de amenazas con una prueba por amenaza y despliegue gradual
Crítico	Núcleo de cálculo, seguridad, cumplimiento regulatorio	Todo lo anterior, más dos aprobaciones humanas independientes, verificación formal o por propiedades y reversión ensayada

Un caso límite: un solo mantenedor

Analizamos también un repositorio de producción con un único mantenedor y los controles automáticos ya instrumentados:

Las pruebas se escriben primero, y un mecanismo impide que el agente las edite.
Ningún PR puede pasar de 400 líneas de código.
La verificación completa es obligatoria antes de dar algo por terminado.
El agente revisa y una persona aprueba.
Hay una aprobación antes de producción y reversión por artefacto.

En ese repositorio, el 70% de los commits tiene coautoría de IA, y ninguno de sus 116 PRs tuvo revisión de otra persona. Es un caso útil para la pregunta de fondo: ¿los controles automáticos sustituyen a la revisión humana, o solo la disfrazan?

Cómo validarlo

Paso	Qué se mide	Qué decide
1. Síntoma contra daño	ρ̂ por repositorio frente a la tasa de reverts y de PRs de corrección	Si gana la tesis o el rival R1
2. Separar por riesgo	ρ̂ en repositorios con usuarios o dependientes frente a repositorios personales	Si gana la tesis o el rival R2
3. Causa común	Mutantes que sobreviven a pruebas de la misma IA, de otra IA y escritas desde la especificación	H3, el resultado más original y el más barato de producir
4. Estimar δ	Ajuste lineal frente a exponencial de la deuda por repositorio	Si el crecimiento es realmente exponencial

Solo con estos resultados tendrá sentido decir cuánto conviene invertir en cada palanca.

Limitaciones

ρ̂ cuenta aprobaciones, no horas de verificación. Es un indicador de tendencia, no una medida directa de la capacidad de verificación.
Los parámetros de la simulación son ilustrativos. Muestran la forma del fenómeno, no su tamaño en un equipo concreto.
GitHub público no representa al software empresarial privado, donde las prácticas de revisión suelen ser más estrictas.
La firma de agentes en los PRs es opcional, así que el uso real de IA está subestimado.
El concepto de «deuda de verificación» ya existe (Sonar, 2026). Lo que este trabajo aporta es la formalización, los resultados derivados y la evidencia, no el término.

Fuentes

GitHub Search API y GraphQL API, recolección propia del 16 de octubre de 2026.
SmartBear y Cisco Systems: estudio de 2,500 revisiones de código. La revisión es efectiva con 200 a 400 líneas por sesión, y la detección cae arriba de 500 líneas por hora.
DORA, State of DevOps: métricas de entrega y tasa de cambios fallidos.
GitHub, Octoverse: volumen anual de contribuciones.
Sonar, What is AI code verification debt? (2026).
Ehsani et al., TOSEM (2026); Jin y Chen (2026); Leu et al. y Nam y Yang, ESEM (2026); Cheung (2026).

Calcula la deuda de verificación de tu equipo

Captura los datos de tu equipo. El cálculo se hace en tu navegador: nada se envía ni se guarda.

Cambios por díaPRs o commits que se integran en un día normal

Qué es: Cuántos cambios entran al código principal en un día normal: PRs integrados o, si no usan PRs, commits a la rama principal.
Cómo obtenerlo: Cuenta los PRs integrados en las últimas 4 semanas y divide entre los días hábiles (unos 20). En GitHub, busca en tu repositorio: is:pr is:merged merged:>=AAAA-MM-DD.
Ejemplo: 80 PRs integrados en 4 semanas ÷ 20 días = 4 cambios por día.

Horas para verificar un cambioRevisión, pruebas y validación de un cambio típico

Qué es: Las horas que tomaría verificar bien un cambio típico: leerlo, probarlo y comprobar que hace lo que debe.
Cómo obtenerlo: Toma 10 PRs recientes, estima el tiempo de revisión y de pruebas de cada uno y usa el promedio. Si no lo registran, una referencia: una revisión cuidadosa avanza unas 300 líneas por hora (estudio de Cisco y SmartBear), más el tiempo de prueba manual.
Ejemplo: PRs de 150 líneas: 0.5 h de revisión + 0.5 h de pruebas = 1 h por cambio.

Horas de verificación por díaDe todo el equipo, no por persona

Qué es: Las horas que tu equipo de verdad dedica a verificar cada día, sumando a todas las personas. No es la jornada completa.
Cómo obtenerlo: Pregunta a cada persona cuánto tiempo al día dedica a revisar PRs, probar y validar, y súmalo. La verificación automática cuenta solo si es independiente y sustituye trabajo humano.
Ejemplo: 4 personas × 1.5 h al día = 6 h de verificación por día.

Encarecimiento diario de la deuda (%)0.05 poco acoplado · 0.2 típico · 0.5 muy acoplado

Qué es: Cuánto se encarece cada día el trabajo que sigue sin verificar: mientras más tiempo pasa, más código depende de él y más cuesta revisarlo o corregirlo.
Cómo obtenerlo: Mídelo con el retrabajo: en un mes, ¿qué porcentaje del trabajo pendiente hubo que volver a revisar o rehacer porque algo cambió debajo (conflictos, revisiones repetidas, correcciones en cadena)? Divide ese porcentaje entre 30. Si no lo mides, usa una referencia según el acoplamiento: 0.05 si los módulos están bien aislados, 0.2 si es típico y 0.5 si es un monolito muy acoplado.
Ejemplo: Si cada mes hay que rehacer el 6% de lo pendiente: 6 ÷ 30 = 0.2% diario.

Deuda actual (horas)Horas de verificación pendientes hoy; 0 si no lo sabes

Qué es: Las horas de verificación que ya van atrasadas hoy.
Cómo obtenerlo: Cuenta los cambios que entraron sin revisar a fondo o que siguen esperando revisión, y multiplícalos por las horas por cambio. Si no lo sabes, deja 0: el cálculo parte de hoy.
Ejemplo: 25 PRs pendientes × 1.2 h = 30 h de deuda actual.

Umbral de insostenible (%)Capacidad extra que tu equipo no podría conseguir

Qué es: Cuánta capacidad extra de verificación podría conseguir tu equipo, como máximo y en poco tiempo. Por encima de eso, frenar la deuda deja de ser realista.
Cómo obtenerlo: Piensa en cuánto podrías aumentar las horas de revisión sin dejar de entregar: horas extra, reasignar personas o contratar. 50% es un punto de partida prudente.
Ejemplo: Si como mucho puedes pasar de 6 h a 9 h diarias de verificación, el umbral es 50%.

En riesgo: la deuda se vuelve insostenible en 6,7 meses (203 días).

Deuda a 30 días: 928 h · Deuda a 1 año: 16.126 h

━ Deuda · ╌ Umbral insostenible · horas de deuda

Qué aplicar primero

Generas 120 h de verificación al día y tienes 90 h: faltan 30 h diarias. Mientras no cierres esa brecha, la deuda crece.
Baja 20% el costo de verificar cada cambio: PRs pequeños, especificación antes del código, tipos estrictos. Con esto: insostenible en 33,1 meses.
Genera 20% menos cambios: limita el trabajo en curso. Con esto: insostenible en 33,1 meses.
Suma 20% de verificación independiente: pruebas de propiedades y de mutación, análisis estático. Con esto: insostenible en 24,7 meses.
Evita que la deuda se pudra (δ a la mitad): modularidad, contratos versionados y revisar pronto. Con esto: insostenible en 13,3 meses.
Escribe las pruebas antes del código y no dejes que la misma IA que generó el código las cambie.
Asigna la revisión humana por riesgo: completa en pagos, autenticación y datos personales; automática en lo demás.

CompartirLinkedIn X WhatsApp