Ali Hamie trabaja como ingeniero en Meta. El 17 de octubre escribió en LinkedIn que nunca se había sentido tan incómodo haciendo su trabajo. Hoy escribe código y todo le parece una caja negra. Textual: “I’m used to understanding what I’m building” (estoy acostumbrado a entender lo que construyo).

No dijo que el código fuera malo. Dijo que a esta velocidad, revisar cada línea lo volvería el cuello de botella, y que entiende sus sistemas a nivel general pero ya no en cada detalle.

Eso tiene nombre. Addy Osmani lo llama deuda de comprensión: la distancia entre cuánto código existe en un sistema y cuánto de ese código alguien entiende. Un tablero no la muestra. Los tests pasan, la velocidad se ve excelente, y la cuenta llega en una caída de producción, cuando alguien tiene que depurar algo que nadie conoce.

Una aclaración que le debo al lector: Osmani trabaja en Anthropic, en Claude Code, la herramienta que uso, y Anthropic es quien publicó el estudio que cito más abajo.

Si diriges un equipo de ingeniería, esta es la deuda que no estás midiendo.

Cuánto código entra sin que nadie lo lea entero

Leí las fuentes primarias. La encuesta de Sonar a más de 1.100 desarrolladores, publicada en enero, dice que el 42% del código commiteado ya es de IA o asistido por IA, y los encuestados esperan 65% para 2027. El 96% dice que no confía del todo en que ese código sea correcto. Solo el 48% afirma revisarlo siempre antes del commit.

Sonar lo conecta con lo que Werner Vogels, CTO de AWS, llamó “verification debt” (deuda de verificación). Es una deuda vecina, pero distinta. La de verificación pregunta si alguien revisó el código. La de comprensión pregunta si alguien puede contarte cómo funciona. Se puede revisar una línea y no entenderla.

Sobre Meta, People Matters resumió un reporte de Business Insider de marzo (no leí el original): la organización que cubre Facebook, WhatsApp y Messenger fijó como meta que el 65% de sus ingenieros escriba más del 75% de su código con IA en el primer semestre de 2026. Hamie no mencionó ningún equipo ni meta. Eso es contexto, no su queja.

Lo que sí mide el estudio de Anthropic, y lo que no

La cifra que más circula viene de un experimento de Anthropic. Reclutaron a 52 ingenieros, en su mayoría junior, con más de un año de Python, y les pidieron programar con una librería que ninguno conocía, Trio. Después, un cuestionario. El grupo con asistente de IA promedió 50%. El grupo que programó a mano, 67%. La mayor brecha estuvo en las preguntas de depuración. Terminar la tarea fue apenas dos minutos más rápido con IA, y esa diferencia no fue estadísticamente significativa.

El estudio midió cuánto aprendió una persona de una herramienta nueva, no cuánto entiende de un sistema de producción que lleva años manteniendo. Tampoco se puede estirar a ingenieros senior. Es evidencia temprana y apunta en una dirección. No es una medición de tu equipo.

Lo que sí es útil: el patrón de uso importó. Quienes pidieron explicaciones o hicieron preguntas conceptuales mientras programaban retuvieron más. Los patrones de dependencia fuerte de la IA, ya fuera para generar código o para depurar, promediaron menos del 40%.

Qué haría con esto

Llevo 36 años programando, desde 1990, y uso Claude Code todos los días. Lo que sigue es opinión mía, no una medición.

El diff es el momento más barato para entender un cambio. Después, entenderlo cuesta un incidente. Por eso no apostaría a revisar más líneas, algo que menos de la mitad dice hacer siempre. Apostaría a decidir qué código necesita que alguien lo entienda y quién es esa persona.

Cuatro cosas que cualquier CTO puede hacer esta semana.

Primero, un nombre por cambio. Cada cambio hecho por IA tiene una persona que responde por él y que debe poder explicarlo si se lo piden. State of AI cuenta que algunos equipos ya hacen esto.

Segundo, revisión según el riesgo. Un script interno puede salir con tests y una mirada rápida. Un servicio de pagos necesita un revisor que explique cada rama.

Tercero, que el modelo explique antes del merge. Pídele que explique qué escribió y qué descartó. Toma más tiempo que aceptar el diff, y es justo el uso que el estudio de Anthropic asocia con retener la comprensión.

Cuarto, la prueba de explicar. Una vez al mes, elige un módulo que la IA tocó. Pídele a quien lo aprobó que lo explique en voz alta sin abrir la herramienta. Cuenta cuántos pueden. Ese número es lo más cercano que conozco a un indicador de deuda de comprensión. State of AI tampoco vio que alguna empresa publique una medida así.

Hay un contraargumento serio. Nadie en Meta lee el compilador ni cada dependencia, y el software siempre ha confiado en capas ajenas. State of AI responde algo que me parece correcto: el código de un agente cae en tu repositorio, a tu nombre, hecho para tu sistema. Eres su autor de registro te guste o no. Un compilador se comporta igual todas las veces. Esto no.

Sobre el código base, escribí por qué el código no es barato. Sobre qué pasa con la revisión cuando sube el volumen, está code review para humanos con 41% de código de IA.

Si quieres saber cuánto de tu código puede explicar tu equipo, escríbeme y hacemos la prueba de explicar sobre un módulo tuyo. Tú eliges el módulo.