Hay una sensación específica que se tiene al revisar código asistido por IA después de haberlo hecho durante mucho tiempo.

No es que esté mal, exactamente. El código funciona. Pero hay una especie de... monotonía. Cada función está optimizada para su propósito inmediato, sin tener en cuenta nada más allá de su propio ámbito. Es correcto en todos los aspectos que las herramientas pueden verificar. Sutilmente defectuoso en todos los aspectos que solo salen a la luz seis meses después, cuando alguien intenta ampliarlo.

Llevo dos años persiguiendo esa sensación, tratando de articular lo que me molesta del código que pasa todas las comprobaciones automáticas, pero que sigue incomodando a los ingenieros experimentados.

Las ganancias en productividad son reales. Las plantillas que antes llevaban una tarde, ahora se hacen en minutos. Se gestionan los casos extremos. Se genera la documentación. Mi equipo entrega más rápido que nunca. Las métricas de velocidad harían sonreír a cualquier director de ingeniería en una revisión trimestral.

Pero el código se acumula en la base de código como sedimentos. Cada módulo generado por IA es una pequeña isla, conectada al resto del sistema por los puentes más delgados posibles. No hay comunicación entre los componentes. No hay un lenguaje arquitectónico compartido. Solo una colección creciente de características que coexisten en el mismo repositorio.

No soy el único que lo nota. Y los datos están empezando a confirmar lo que muchos de nosotros hemos sentido.

Lo que revelaron 300 repositorios sobre el punto ciego de la IA

Ox Security analizó recientemente más de 300 repositorios de código abierto, incluidos 50 que fueron generados total o parcialmente por IA. Los resultados pusieron en palabras algo que había estado intuyendo en las revisiones de código durante meses.

Lo llaman el efecto «Ejército de juniors»: la IA produce código que es muy funcional, pero que carece sistemáticamente de criterio arquitectónico. El código funciona. Simplemente no piensa.

Diez antipatrones críticos aparecieron con una frecuencia alarmante. Los comentarios en línea excesivos abarrotaban entre el 90 % y el 100 % de los proyectos generados por IA, comentarios que aumentan el ruido sin mejorar la claridad. Más revelador aún: entre el 80 % y el 90 % mostraban «evitación de refactorizaciones». La IA nunca mejora arquitectónicamente el código existente. Solo añade. Y en el 70-80 % de los proyectos, los errores idénticos seguían repitiéndose porque la IA viola los principios básicos de reutilización de código. El mismo error, copiado en nuevos contextos, una y otra vez.

El análisis de GitClear de 211 millones de líneas de código de 2020 a 2024 proporciona la base cuantitativa. La rotación de código (el porcentaje de líneas revertidas o actualizadas en dos semanas) se ha duplicado desde que se disparó la adopción de la IA. La refactorización se redujo del 25 % a menos del 10 % de todos los cambios de código. Los bloques de código copiados y pegados se multiplicaron por ocho.

Esa última cifra me impactó. Lo he visto ocurrir en mi propio equipo. Cuando la IA genera una solución, los desarrolladores la aceptan. Cuando aparece un problema similar en otro lugar, la IA genera una solución similar. Nadie consolida. Nadie abstrae. La base de código crece lateralmente en lugar de hacia arriba.

Nos dicen que se trata de un problema de herramientas. Mejores indicaciones. Mejores modelos. Mejores procesos de revisión. Y, sin duda, eso ayuda.

Pero cada vez estoy más convencido de que la verdadera crisis no es el código que estamos lanzando hoy. Son los desarrolladores para los que no estamos desarrollando para el mañana.

La paradoja de la productividad que nadie quiere reconocer

Aquí es donde la cosa se pone incómoda.

METR, una organización sin ánimo de lucro dedicada a la evaluación de la IA, ha llevado a cabo recientemente lo que podría ser el estudio de productividad más riguroso hasta la fecha. Reclutaron a 16 desarrolladores de código abierto con experiencia en proyectos masivos con más de 22 000 estrellas y más de un millón de líneas de código, y luego realizaron un ensayo controlado aleatorio con 246 tareas.

Los desarrolladores que utilizaban IA eran un 19 % más lentos que los que trabajaban sin ella.

Pero aquí está el giro: antes de empezar, esos mismos desarrolladores predijeron que la IA les haría un 24 % más rápidos. Después de completar las tareas, estimaron que habían sido un 20 % más rápidos. No podían decir que fueran más lentos. Las herramientas parecían productivas incluso cuando no lo eran.

Reconozco esta sensación. Hay algo satisfactorio en ver aparecer el código en la pantalla, en las sugerencias rápidas, en la sensación de impulso. Se siente como un progreso. Si es un progreso depende de lo que suceda cuando ese código deba ser mantenido, ampliado o depurado por alguien que no lo haya escrito.

La encuesta de Stack Overflow de 2025 a 49 000 desarrolladores refuerza este patrón. ¿Cuál es la principal frustración con las herramientas de IA? El 66 % cita soluciones que son «casi correctas, pero no del todo». La confianza se ha erosionado significativamente: solo el 33 % confía ahora en los resultados de la IA, frente al 43 % del año pasado. La desconfianza activa aumentó del 31 % al 46 %.

La brecha entre la percepción y la realidad puede ser el hallazgo más peligroso de todos. Si los desarrolladores se sienten productivos mientras acumulan deuda, seguirán acumulándola. Si los líderes ven que las métricas de velocidad suben, lo celebrarán. Los problemas permanecen invisibles hasta que dejan de serlo.

La mitad funciona. La otra mitad podría ser peor.

Múltiples estudios independientes coinciden en una cifra preocupante: aproximadamente entre el 40 % y el 50 % del código generado por IA contiene vulnerabilidades de seguridad.

El Centro de Seguridad y Tecnología Emergente de Georgetown probó cinco LLM líderes y descubrió que casi la mitad de los fragmentos de código producidos contenían errores que podían dar lugar a un uso malicioso. Veracode probó más de 100 LLM en 80 tareas de finalización y descubrió que el 45 % producía las 10 vulnerabilidades principales de OWASP. El código Java fue el que peor resultado obtuvo, con una tasa de fallos de seguridad del 70 %.

La investigación de Stanford añade una dimensión psicológica que me quita el sueño. En un estudio controlado, los participantes con acceso a IA escribieron código significativamente menos seguro en cuatro de las cinco tareas. Más preocupante aún: los usuarios de IA eran más propensos a creer que habían escrito código seguro. Una falsa confianza que agrava el riesgo técnico.

Pienso en esto cuando reviso las relaciones públicas. El desarrollador que envía el código cree que es sólido. La IA que lo generó no tiene ningún concepto de creencia. Y yo soy la última línea de defensa, buscando problemas en el código escrito por un proceso optimizado para la plausibilidad en lugar de la corrección.

La velocidad lo empeora. Como dijo el vicepresidente de investigación de Ox Security: ahora se pueden crear aplicaciones funcionales más rápido de lo que los humanos pueden evaluarlas adecuadamente. Hemos creado una velocidad que supera nuestra capacidad de verificación.

La pregunta que nadie en el liderazgo quiere responder

Esto es lo que me sigue rondando la cabeza, la pregunta que hace que esto sea más que un problema técnico:

Si automatizamos las tareas que solían formar a los ingenieros junior: las plantillas, las correcciones de errores, las pequeñas funciones que les enseñaban cómo funcionan realmente los sistemas. ¿Quién desarrollará la intuición arquitectónica para mantener estos sistemas dentro de cinco años? ¿Y dentro de diez?

Las cifras son contundentes. Según Revelio Labs, las ofertas de empleo tecnológico para principiantes han disminuido un 35 % desde enero de 2023. Stanford analizó los datos de nóminas de ADP y descubrió algo incómodo: hay un 16 % menos de desarrolladores de entre 22 y 25 años empleados que a finales de 2022. Cuando siete de cada diez responsables de contratación creen que la IA puede encargarse del trabajo de los becarios, el descenso empieza a tener sentido.

El modelo tradicional de aprendizaje se está fracturando. La IA ahora se encarga de las tareas que históricamente realizaban los junior: generación de plantillas, corrección de errores sencillos, documentación, creación de casos de prueba. El trabajo aburrido. El trabajo que te enseña cómo funcionan realmente las bases de código, cómo las decisiones se propagan por los sistemas, por qué existe ese patrón extraño en el código heredado y qué se rompe si lo cambias.

Charity Majors, directora de tecnología de Honeycomb, lo expresó con precisión:

«Al no contratar y formar a ingenieros junior, estamos canibalizando nuestro propio futuro».

Nos estamos comiendo las semillas. Optimizamos la cosecha de este trimestre, pero nos aseguramos de que no haya nada que plantar el año que viene.

McKinsey prevé una importante escasez de desarrolladores senior para 2030 si continúan las tendencias actuales. No es una exageración. Es aritmética. Si las empresas dejan colectivamente de formar a desarrolladores principiantes porque la IA se encarga de sus tareas tradicionales, la cantera que produce ingenieros de nivel medio y senior simplemente dejará de existir.

Por qué las organizaciones no ven lo que se avecina

He asistido a suficientes reuniones de planificación como para entender por qué sigue ocurriendo esto.

La velocidad es visible. El deterioro arquitectónico es invisible, hasta que deja de serlo. Las métricas de adopción de la IA son las que siguen los directivos. La deuda técnica no aparece en los balances. Las personas que ven el problema con mayor claridad, los colaboradores sénior que revisan el código a diario, no controlan los presupuestos.

Y hay un desajuste temporal que empeora aún más las cosas. Las ventajas de las herramientas de codificación de IA son inmediatas: relaciones públicas más rápidas, más funciones incorporadas, cifras trimestrales impresionantes. Los costes se aplazan: bases de código que se resisten a las modificaciones, incidentes de seguridad que aún no han ocurrido, una cantera de talentos que se está agotando silenciosamente.

La cultura de la permanencia corta en el cargo amplifica el problema. El ejecutivo tecnológico medio permanece en su puesto entre tres y cuatro años. La deuda técnica que se está creando ahora vencerá en cinco o siete años. Las personas que toman las decisiones hoy no estarán ahí cuando llegue el momento de pagar la factura.

El profesor del MIT Armando Solar-Lezama lo cristalizó:

«La IA es como una tarjeta de crédito nueva que nos va a permitir acumular deuda técnica de formas que nunca antes habíamos podido hacer».

Todos sabemos cómo funciona la deuda de las tarjetas de crédito.

Los pagos mínimos parecen manejables hasta que, de repente, dejan de serlo.

Lo que haría de otra manera

No tengo un marco que ofrecerles. Pero si tuviera que crear las prácticas de IA de un equipo desde cero, empezaría por aquí.

Haga un seguimiento de las métricas que importan más que la velocidad: tasa de rotación de código, hallazgos de seguridad por sprint, tiempo de depuración del código asistido por IA frente al código escrito por humanos. Las cifras pueden ser aleccionadoras, pero al menos las estarías viendo.

Protege explícitamente los puestos de desarrollador junior. No como caridad, sino como inversión. Cuando alguien sugiera que «basta con usar IA para eso», pregunta quién va a entender este sistema lo suficientemente bien como para arreglarlo en 2028. A ver si se hace el silencio en la sala.

Trata el código generado por IA como el código de un contratista brillante pero sin contexto. Necesita revisión. Necesita pruebas. Necesita a alguien que entienda el sistema para evaluar si esta solución técnicamente correcta es realmente la solución adecuada para tu arquitectura. La IA se encarga de la implementación; los humanos se encargan del juicio.

Y sé más honesto en las revisiones de código. Cuando algo te parezca mal, esa monotonía que mencioné al principio, no lo apruebes solo porque las pruebas hayan salido bien. Señálalo. Haga preguntas. A veces se equivocará y el código estará bien. Pero la conversación en sí misma es importante. Obliga a los equipos a articular principios arquitectónicos que, de otro modo, permanecerían implícitos.

La factura siempre llega

No dejo de pensar en la capitalización. En las tarjetas de crédito. En las semillas de maíz.

Todos los atajos tienen un coste. La única pregunta es cuándo lo pagará. Las organizaciones que invierten ahora en el juicio humano: en formación, en revisión de código, en el lento trabajo de desarrollar la intuición arquitectónica. Ellas serán las dueñas del futuro. Las que se optimizan únicamente por la velocidad están construyendo otra cosa. Algo que parece impresionante desde fuera, se envía rápidamente y satisface las métricas trimestrales.

Algo que nadie sabrá cómo arreglar cuando se rompa.

Algunos equipos están construyendo catedrales. Otros están construyendo fachadas. La diferencia no será visible durante años.

Pero se hará visible.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.