Emilio Carrión
El 96% no confía en el código de la IA. Solo el 48% lo verifica. Houston, tenemos un problema.
Casi todos usamos IA para programar, pero muy pocos verifican siempre el código que generan las herramientas. Así nace una deuda de verificación que puede salir carísima.
Déjame contarte algo que me pasó hace cosa de un año. Estaba en una de esas etapas Erasmus que hago como Staff Engineer, integrado dentro de un equipo que trabaja en dashboards para la preparación en tiendas. Yo, emocionado con la potencia de las herramientas de IA, decidí usarla para generar tests y parte de la implementación. Todo pintaba bien. Subí la PR y me fui tan contento.
A los veinte minutos me llega la tech lead del equipo. "Oye Emilio, estos tests de aquí... no acabo de pillar lo que hacen."
Nos sentamos juntos. Los miramos. Y en efecto: los tests que había generado la IA no tenían sentido con el resto de la suite. Unos no comprobaban nada útil. Otros lo hacían de una forma extraña. Y los que quedaban eran duplicados de tests que ya existían.
¿Qué había pasado? Que me relajé. Me dejé llevar por el ansia de ir rápido, por la comodidad de que era un cambio de poco riesgo. No revisé el código como debería haberlo hecho. Y tuvo que ser otra persona la que me frenase.
Si a mí, que me considero bastante atento a estos temas, se me escapó... ¿qué está pasando con el resto de la industria?
En 60 segundos: El State of Code Developer Survey de Sonar confirma lo que muchos intuíamos: casi todos los developers usan IA, casi nadie confía plenamente en el código que genera, y aun así solo la mitad lo verifica siempre antes de subirlo a producción. Esto crea una deuda de verificación silenciosa que va a explotar antes de lo que pensamos.
Los datos que deberían preocuparte
Hace unos días se publicó el State of Code Developer Survey Report de Sonar, y los datos son bastante reveladores.
Primero, lo esperado: el 72% de los developers que han probado IA la usan a diario. Esto no sorprende a nadie que la haya probado. La herramienta gusta, ayuda y se queda. Hasta aquí todo bien.
El dato interesante viene cuando les preguntan si confían en que el código generado por IA es funcionalmente correcto. Solo un 4% dice estar completamente de acuerdo. Un 25% dice estar de acuerdo a secas. Un 23% ni fu ni fa. Y el resto, en contra.
Dicho de otra forma: el 96% de los developers no puede afirmar con total confianza que el código generado por IA sea funcionalmente correcto. Lo entiendo. Yo soy uno de ellos. Es sano tener ese escepticismo.
El problema no está ahí. El problema está en lo que viene después.
El Verification Bottleneck: no confío, pero tampoco verifico
De ese 96% que dice no fiarse, solo el 48% verifica siempre el código generado por IA antes de hacer commit o desplegarlo.
Léelo otra vez. No confío, pero no siempre lo verifico.
Esto es una contradicción brutal. Y si lo piensas fríamente, es el tipo de incoherencia que genera problemas a escala. Porque no estamos hablando de un developer suelto en un proyecto pequeño. Estamos hablando de una industria entera adoptando herramientas de generación de código a un ritmo que nunca habíamos visto.
El problema de escala que nadie quiere ver
Vuelvo a mi ejemplo. Yo, siendo consciente de estos riesgos, me relajé un día y se me escapó. Fue en una PR de bajo riesgo, con una tech lead atenta que lo cazó en la revisión. El sistema funcionó.
Pero ahora piensa en escala. En mi empresa hay más de cien ingenieros generando código asistido por IA, semana tras semana, día tras día. ¿Cuántas cosas se nos pueden estar escapando? ¿Cuántos tests que no testean nada? ¿Cuántas validaciones que parecen correctas pero no lo son? ¿Cuánta lógica de negocio sutilmente mal implementada?
Y esto no es solo mi empresa. Es la industria entera.
Aquí viene el punto importante: cuanto más fácil y barato es generar código, más atención hay que prestar a lo que se genera. Parece contraintuitivo, pero es exactamente así. La facilidad de generación no nos libera de la responsabilidad de verificación. Al contrario, la amplifica.
La Verification Debt: la nueva deuda técnica silenciosa
El CTO de AWS lo llamó Verification Debt, deuda de verificación. Y me parece un concepto brillante porque captura exactamente lo que está pasando.
Estamos llevando código a producción a una velocidad sin precedentes. Pero no estamos verificando ese código al mismo ritmo. La diferencia entre lo que generamos y lo que validamos es una deuda que se acumula en silencio. Y como toda deuda, los intereses van creciendo.
¿Te suena? Es exactamente el mismo patrón que la deuda técnica clásica. Tomas atajos para ir rápido, no pasa nada visible a corto plazo, y un día te explota en la cara. Solo que esta vez el atajo no es un hack en el código, sino la falta de verificación del código que una máquina escribió por ti.
La realidad es que estamos en una transición donde las herramientas de generación van muy por delante de nuestros procesos de verificación. Y eso es un riesgo real.

Cheat Sheet: Deuda Técnica
La guía visual y práctica para entender, identificar y gestionar la deuda técnica. Incluye cuadrantes, señales, estrategias y ventajas de pagarla.
La moda del "AI Code Fixer"
Hace poco empecé a ver en LinkedIn perfiles que se posicionaban como AI Code Fixers. Gente que se dedica a arreglar los problemas generados por la IA. Y aunque suene a broma, es una señal clara de hacia dónde vamos.
Si estamos creando un rol entero dedicado a limpiar lo que genera la IA, quizás deberíamos preguntarnos si estamos abordando el problema desde el ángulo correcto. Quizás la solución no es arreglar después, sino verificar durante.
¿Te gusta lo que lees?
Únete a otros ingenieros que reciben reflexiones sobre carrera, liderazgo y tecnología cada semana.
Qué significa esto para los perfiles senior
Esto es algo que llevo diciendo mucho tiempo: cuanto más senior eres, más tienes que gestionar el riesgo. Y el código generado por IA sin verificar es un riesgo real que estamos viviendo ahora mismo.
Los perfiles senior y los tech leads tienen una responsabilidad extra en esta etapa. No solo en verificar su propio código, sino en crear procesos y cultura de equipo donde la verificación del código generado por IA sea parte del flujo natural de trabajo.
Porque al final, la IA no va a desaparecer. Cada vez más gente la va a usar. Cada vez va a generar más código. Y si no establecemos procesos sólidos de verificación ahora, vamos a pagar un precio muy alto después. Antes que después.
Tres cosas que puedes hacer esta semana
- Revisa tus PRs de IA con ojo extra. No asumas que porque compila y pasa los tests está bien. Lee los tests como si los hubiera escrito un junior: ¿realmente comprueban lo que dicen comprobar?
- Establece un proceso en tu equipo. Habla abiertamente sobre el uso de IA y definid juntos qué nivel de verificación esperáis antes de hacer merge. Hacer explícito lo implícito.
- Presta especial atención a los tests generados por IA. El código de negocio se puede verificar con tests. Pero si los tests están mal, no tienes red de seguridad. Es lo más importante de todo y lo primero que se suele descuidar.
La clave está en esto: la IA hace que el código sea gratis. Pero el juicio para saber si ese código es correcto sigue siendo caro. Y es exactamente ahí donde tu valor como ingeniero crece.
Pregunta para ti: ¿Usas IA en tu día a día? Y si lo haces, ¿revisas el código o confías en que otra persona lo haga por ti? ¿Tenéis un proceso en vuestro equipo donde estéis seguros de que el código que lleváis a producción es válido? Me encantaría saber vuestras experiencias.
Este contenido fue enviado primero a mi newsletter
Cada semana envío reflexiones exclusivas, recursos y análisis profundos sobre ingeniería de software, liderazgo técnico y desarrollo de carrera. No te pierdas el próximo.
Únete a más de 5,000 ingenieros que ya reciben contenido exclusivo cada semana
Artículos relacionados
La deuda técnica y la metáfora de los suegros
¿La deuda técnica es mala? Spoiler: No. Pero tiene truco. Descubre cómo gestionarla usando la metáfora de la cocina y los suegros.
El código bonito no paga facturas (pero el pragmatismo sí)
El purismo técnico no paga facturas. Aprende a decidir cuándo priorizar velocidad, cuándo invertir en arquitectura y cómo usar la deuda técnica con cabeza.
¿Para qué escribimos tests? (El CTO que no entendía nada)
El software que no resuelve el problema para el que fue creado no vale nada. Descubre por qué los tests son la única garantía de valor.
