El código que nadie entiende ya está en producción

Hace poco me contó un colega una historia que no me puedo quitar de la cabeza.

Alerta a las 2 AM. Latencia disparada en un servicio crítico de e-commerce. El ingeniero de guardia abre el código, mira los logs, revisa las métricas. Todo parece correcto pero el sistema se está muriendo.

Tres horas después, descubren el problema. Una pieza del servicio había sido generada casi entera con Copilot meses atrás. El ingeniero que la generó ya no estaba en el equipo. Y el de guardia no tenía modelo mental de cómo funcionaba. No es que el código fuera malo. Es que nadie lo entendía del todo.

Con un modelo mental del sistema, habría llevado 20 minutos. Sin él, fueron 3 horas de arqueología a ciegas.

Esta historia no es rara. Apuesto a que algo parecido ya te ha pasado, o te va a pasar pronto.

El coste que nadie está midiendo

Llevamos dos años celebrando que la IA escribe código. Y con razón. La productividad es real. He visto a ingenieros entregar en días lo que antes tardaban semanas.

Pero hay un trade-off del que casi nadie habla: estamos intercambiando velocidad de desarrollo por opacidad operacional. Y ese intercambio no es gratis.

Históricamente, cuando escribías código, construías un modelo mental del sistema al mismo tiempo. Sabías dónde podía fallar porque habías pensado en cada decisión. Sabías qué métricas mirar porque habías diseñado los flujos. Sabías qué dependencias eran frágiles porque habías elegido las librerías.

Cuando la IA escribe el código, te saltas todo eso. Tienes un sistema funcionando pero no tienes el mapa mental que viene de haberlo construido. Armando Solar-Lezama, del MIT, lo describió perfectamente: la IA es como una nueva tarjeta de crédito que nos permite acumular deuda técnica de formas que nunca pudimos antes.

Y la parte más peligrosa de esta deuda es que ni siquiera sabes que la tienes.

Piensa en tu propio equipo. ¿Cuántas PR de la última semana contenían código generado por IA que el reviewer entendió al 100%? ¿Al 80%? ¿Al 50%? Esa diferencia entre "funciona" y "entiendo por qué funciona" es exactamente donde viven los incidentes futuros.

Y no, no es solo un problema de vibe coders generando apps con prompts. Satya Nadella admitió que la IA escribe hasta el 30% del código de Microsoft. Sundar Pichai dijo lo mismo de Google, más del 30%. Y según la Stack Overflow Developer Survey 2025, el 84% de developers ya usa o planea usar herramientas de IA, y casi la mitad las usa a diario. Esto no es un nicho (es la norma). Cada línea que se acepta sin comprensión profunda es un trozo del sistema que entra en una zona gris. No es código malo. Es código opaco. Y la opacidad se acumula.

Qué se rompe cuando nadie entiende el sistema

Las consecuencias son concretas y las estoy viendo en equipos reales:

El debugging se convierte en arqueología. En vez de ir directamente al punto de fallo porque conoces el flujo, estás haciendo ingeniería inversa bajo presión y a las 3 AM. Los stack traces te llevan a boilerplate generado. Las abstracciones que la IA eligió no son las que tú habrías elegido. Estás leyendo el código de un "developer" que no existe, que no tiene contexto de negocio, y al que no puedes preguntarle nada.

Cada fix genera problemas nuevos. Cuando no entiendes la arquitectura subyacente, cada parche es un tiro al aire. Arreglas un bug y creas dos porque no viste la dependencia implícita que la IA introdujo. Es reparar una máquina sin manual: cada pieza que tocas puede romper tres que no sabías que estaban conectadas. El sistema se vuelve más frágil con cada intervención. GitClear analizó 211 millones de líneas de código y encontró que los bloques de código duplicado se han multiplicado por 4 desde la adopción masiva de IA, y que por primera vez en la historia el copy/paste supera al refactoring. No es que el código sea peor (es que nadie entiende lo suficiente como para mejorarlo).

La observabilidad tradicional deja de ser suficiente. Puedes tener el mejor setup de monitorización del mundo. Pero las métricas solo te dicen qué está pasando. Si no tienes el modelo mental del sistema, no sabes por qué está pasando ni qué hacer al respecto. Las herramientas de observabilidad asumen que alguien entiende el sistema. Esa asunción se está rompiendo.

Gestionando equipos que operan sistemas a escala, veo un patrón claro: el tiempo de resolución de incidentes sube en servicios donde se usó IA extensivamente para generar código. No porque el código sea peor (las métricas de calidad son similares). Sino porque el ingeniero de guardia tarda más en entender qué está pasando. Los datos lo confirman: según la Stack Overflow Developer Survey 2025, el 45% de developers dice que debuggear código AI-generated tarda más que escribirlo ellos mismos. Y el 66% señala como su mayor frustración las soluciones de IA que están "casi bien pero no del todo."

La habilidad que nadie está entrenando

Aquí es donde creo que la industria tiene un punto ciego enorme. Y donde quiero hacer foco.

Estamos invirtiendo miles de millones en herramientas que generan código más rápido. Estamos invirtiendo en observabilidad cada vez más sofisticada. Pero no estamos invirtiendo en la habilidad humana de operar sistemas que no entendemos del todo.

Yo lo llamo operar a ciegas. La capacidad de mantener, debuggear y evolucionar sistemas cuyo funcionamiento interno no comprendes completamente.

No es lo mismo que "leer código ajeno." Eso siempre ha existido. El código ajeno tradicional fue escrito por una mente humana con intenciones, convenciones y patrones reconocibles. El código AI-generated fue escrito por un modelo estadístico que optimiza para "funcionar" sin ningún concepto de "se entiende." Las abstracciones son arbitrarias. Los nombres son plausibles pero no semánticos. La estructura refleja los patrones del training data, no las necesidades del dominio.

Operar a ciegas es una disciplina nueva. Y requiere habilidades que no estamos enseñando: construir modelos mentales rápidos de sistemas que no construiste (no leyendo cada línea, sino reconociendo patrones arquitecturales y formulando hipótesis sobre el diseño); desarrollar heurísticas de fallo que funcionen sin conocimiento profundo de la implementación; detectar cuándo la IA tomó una decisión arquitectural cuestionable sin revisar cada fichero; debuggear comportamiento emergente en sistemas cuyas partes no fueron diseñadas por la misma mente.

Lo interesante es que los ingenieros con más experiencia ya hacen esto, pero no saben que lo hacen. Cuando un senior resuelve un incidente en código que nunca vio más rápido que un mid-level, no es magia. Son años de heurísticas acumuladas sobre cómo fallan los sistemas. Patrones que reconocen sin pensar. Intuiciones entrenadas en miles de horas de producción real.

Lo que antes llamábamos "experiencia" ahora es una ventaja competitiva crítica. Y la mayoría de seniors no sabe articularla, transmitirla, ni enseñarla.

El puente roto entre junior y senior

Tradicionalmente, un junior construía su modelo mental del mundo de forma gradual. Empezaba con tareas simples. Veía cómo su código se comportaba en producción. Rompía cosas pequeñas. Aprendía de los postmortems. Después de años, tenía las heurísticas de un senior.

Ese camino se está cerrando.

La IA se está comiendo exactamente las tareas que servían de campo de entrenamiento. Los juniors que entran hoy al mercado no van a tener el lujo de construir comprensión de forma gradual a través de años de trabajo simple. Necesitan llegar a un nivel de competencia operacional mucho más alto, mucho más rápido.

Y no hay nada que les enseñe esto. Ni cursos. Ni herramientas. Ni frameworks. Los bootcamps enseñan a escribir código. Las universidades enseñan algoritmia. Los tutoriales enseñan tecnologías. Nadie enseña a operar sistemas que no entiendes. Nadie enseña a construir un modelo mental de un sistema a partir de sus síntomas y no de su código fuente.

Los seniors tienen la habilidad pero no la enseñan. Los juniors necesitan la habilidad pero no saben que existe. Y la industria no ha reconocido que esto es un problema diferente a "aprender a programar mejor."

Esto es un gap que se va a ensanchar. Cuanto más código genere la IA, más crítica se vuelve la capacidad de operar lo que la IA genera. Y menos gente tendrá el camino tradicional para desarrollarla.

Esto no es un argumento contra la IA

Que quede claro: no estoy diciendo que dejemos de usar IA para escribir código. Eso sería absurdo. La productividad es real y quien no la adopte se queda atrás.

Lo que digo es que necesitamos ser honestos sobre lo que estamos sacrificando para obtener esa velocidad. Y necesitamos empezar a trabajar en lo que falta.

Si gestionas un equipo, tres cosas que puedes hacer ahora:

Mide la comprensión, no solo la calidad. En tus code reviews de código AI-generated, la pregunta no es "¿funciona?" sino "¿podría alguien debuggear esto a las 3 AM sin ayuda?" Si la respuesta es no, eso no significa rechazar el PR (significa que necesitas invertir tiempo en entender las decisiones que la IA tomó y documentarlas).

Haz que los postmortems entrenen heurísticas. La próxima vez que resolváis un incidente, centra el postmortem no en "qué falló" sino en "cómo llegamos al diagnóstico." El proceso de razonamiento bajo incertidumbre es la habilidad más valiosa en un mundo de código opaco. Cada incidente resuelto es una oportunidad de hacer ese razonamiento explícito y transmisible.

Documenta las decisiones que la IA no documenta. Cuando aceptas código generado, añade contexto explicando el por qué de la approach. La IA eligió una estrategia, pero el contexto de negocio lo tienes tú. Ese contexto es el puente entre el código opaco y el ingeniero de guardia del futuro.

El territorio que se abre

El código gratis no existe. La IA no cobra por escribirlo, pero alguien va a pagar por operarlo.

Creo que operar a ciegas va a definir una parte importante de lo que significa ser buen ingeniero en los próximos años. No es solo un problema (es un cambio de paradigma en lo que valoramos como habilidad técnica). Y ahora mismo, casi nadie lo está mirando.

Voy a seguir tirando de este hilo. Hay mucho que explorar: cómo se entrenan estas habilidades, cómo cambian los procesos de equipo, qué herramientas necesitamos que aún no existen. Si operas sistemas en producción, esto te va a afectar (si no lo está haciendo ya).

Pregunta para ti: ¿Ya estás notando este efecto en tu equipo? ¿Los incidentes tardan más en resolverse cuando el código fue generado por IA? Me encantaría saber tu experiencia.