Revisión humana frente a código 100 % generado por IA: por qué la diferencia es el producto
Date Published
El código 100 % generado por IA y el código generado por IA y revisado pueden salir del mismo modelo, con el mismo prompt, y ser aún dos productos distintos. La versión revisada es software sobre el que montar un negocio. La versión sin revisar es una demo que todavía no ha fallado. La revisión es la diferencia.
Todo equipo eficiente usa ya IA para escribir código, así que "¿usáis IA?" dejó de ser una pregunta útil. La pregunta que separa a un proveedor de fiar de uno que no lo es apunta más fino: ¿quién lee el código antes de publicarlo, y qué caza? Las dos respuestas van abajo, con el detalle al que el resto de nuestro clúster de vibe coding no deja de remitir. Para la práctica sobre la que se apoya esta revisión, empieza por el vibe coding y el desarrollo asistido por IA.
El mismo código, dos productos distintos
Un modelo de IA produce código de apariencia plausible. Plausible no es la misma afirmación que correcto, o seguro, o mantenible, y el modelo no carga con ninguna consecuencia por la brecha entre unas cosas y otras. Respondió al prompt. Si la respuesta se sostiene es problema de otro, y en un proyecto hecho con vibe coding ese otro no existe.
La revisión humana cierra esa brecha. Un ingeniero sénior lee lo que escribió el modelo, lo cuestiona, lo corrige y solo entonces deja que se fusione. Nada del paso de generación cambia. Todo lo del resultado sí. El código pasó de una conjetura informada a una decisión revisada, y tu empresa ya puede depender de él. Las organizaciones más hábiles con el código de IA son las más disciplinadas a la hora de leer su salida.
Qué caza de verdad un revisor humano
La revisión no es un mero trámite. El NIST SSDF recomienda revisar y analizar el código legible por humanos para identificar vulnerabilidades y verificar el cumplimiento de los requisitos de seguridad, por lo que el código generado por IA debe someterse a controles de revisión antes de integrarse. Es donde se detienen cuatro modos de fallo concretos, los mismos cuatro que salen directos a producción cuando nadie lee el código. Nuestra guía sobre si el código generado por IA es seguro cubre la lista de riesgos; aquí tienes lo que hace el revisor con cada uno.
Agujeros de seguridad que el modelo copió de sus datos de entrenamiento. Los modelos de lenguaje se entrenan con grandes corpus de datos, que pueden incluir código público; la fuente concreta y la composición de los datos dependen del modelo y no deben darse por supuestas. En una evaluación de más de 100 modelos de lenguaje y cuatro lenguajes, el 45 % de las muestras de código analizadas por el informe 2025 de seguridad del código generativo de Veracode falló las pruebas de seguridad e introdujo vulnerabilidades del OWASP Top 10: credenciales escritas en el código, validaciones de entrada ausentes, consultas propensas a inyección. Ese resultado es el de la evaluación de Veracode, no una tasa universal para todo código generado por IA. Un revisor caza la clave expuesta y el campo de formulario sin validar en el diff, antes de que se conviertan en incidente.
Dependencias que no existen. Los modelos importan a veces paquetes de software que se inventaron. Un estudio presentado en USENIX Security '25, que generó y analizó 576.000 muestras de código con 16 modelos de lenguaje, estimó al menos un 5,2 % de paquetes alucinados en modelos comerciales y hasta un 21,7 % en modelos de código abierto. Un nombre de paquete alucinado puede crear una oportunidad de ataque de confusión de paquetes ("slopsquatting") si un tercero registra después un paquete malicioso con ese nombre, aunque eso no demuestra que cada paquete inventado haya sido registrado o explotado; si ocurre, la siguiente persona que "arregla" la importación fallida acaba instalándolo. La verificación de la existencia y procedencia de cada dependencia, junto con el análisis de la cadena de suministro, reduce el riesgo de que una recomendación ficticia llegue a la compilación, según el NIST. Un revisor, respaldado por un análisis de dependencias, impide que la importación ficticia llegue siquiera a la build.
Lógica equivocada que no se cuelga. Un descuento que redondea mal en una divisa, un filtro de fechas que descarta el último día del mes, una comprobación de permisos que pasa para todos los roles menos el que nadie probó: estos fallos salen limpios durante semanas y solo emergen cuando un cliente nota que el total está mal. Un revisor que entiende el negocio lee buscando intención, no solo si compila.
Código que funciona hoy y no se puede cambiar mañana. Los modelos duplican lógica en vez de reutilizarla, porque cada prompt se responde de cero, sin memoria de la base de código. Un revisor puede detectar duplicación y problemas de coherencia arquitectónica, pero ninguna revisión garantiza por sí sola que futuros cambios no provoquen regresiones; hacen falta revisión, pruebas y controles de integración combinados para que un cambio pequeño seis meses después no rompa algo sin relación.
Por qué las herramientas automáticas no bastan por sí solas
La objeción habitual es que los analizadores y los linters pueden sustituir a la persona. No pueden, y tratarlos como sustituto es su propio modo de fallo.
El análisis automatizado de dependencias es genuinamente valioso, y se ejecuta en cada construcción seria: un paquete que arrastra un aviso conocido debería hacer fallar la build en lugar de llegar a producción. Pero un analizador comprueba patrones conocidos contra bases de datos conocidas. No sabe que tu lógica de descuento redondea mal, que un límite de permisos está en el sitio equivocado o que el modelo resolvió correctamente el problema equivocado. Eso son decisiones de criterio, y el criterio es justo lo que a un modelo, y a un linter, les falta.
La relación correcta es por capas, no una u otra. Las herramientas cazan los fallos mecánicos a velocidad y escala de máquina. Una persona caza los que exigen entender el negocio al que sirve el software. Quita a la persona y las comprobaciones mecánicas siguen pasando mientras el software hace en silencio lo que no debe. Nuestro circuito completo, donde las dos capas conviven, está descrito en cómo definimos el alcance, construimos y revisamos, y el lado del instrumental en detalle en cómo aseguramos cada construcción.
La revisión es también donde vive la responsabilidad
Hay una segunda cosa que la revisión produce y que ninguna herramienta puede: una persona responsable que entiende tu software.
Cuando un ingeniero lee cada línea antes de la fusión, alguien puede explicar cómo funciona el sistema, por qué se construyó así y qué se romperá si lo cambias. Esa persona puede ceder la base de código con limpieza, responder con honestidad a un cuestionario de seguridad y arreglar el siguiente fallo sin una negociación a ciegas con el modelo. Una aplicación hecha con vibe coding no tiene a nadie así, y por eso cuesta tanto poseerla: el CISQ cifró el coste anual de la mala calidad del software en EE. UU. en 2,41 billones de dólares, la mayor parte en corregir y ampliar código que nadie entiende del todo (CISQ, 2022).
La responsabilidad es también la razón por la que revisión y propiedad viajan juntas. Un proveedor que lee cada línea y luego te asigna la propiedad del código completa te entrega algo que entiende y que respalda. Un proveedor que publica salida sin leer y te mantiene dependiente de él hace lo contrario, diga lo que diga el contrato.
Qué preguntarle a un proveedor sobre la revisión
Todo taller de desarrollo con IA llamará "revisado" a su código. Pocos saben describir la revisión de una forma que puedas comprobar. Tres preguntas separan a unos de otros.
Pregunta quién lee el código: quieres un rol con nombre, un ingeniero sénior, no "el equipo" ni "nuestro proceso". Pregunta cuándo lo lee: antes de cada fusión, no "en algún momento" ni "si algo parece raro". Pregunta qué pasa cuando una comprobación falla: un circuito real bloquea la publicación; uno decorativo registra un aviso y publica igual. Un proveedor que responde a las tres con frases claras tiene un paso de revisión. Un proveedor que responde con adjetivos probablemente no lo tenga, y esa única carencia pesa más que casi todo lo demás de su propuesta.
Preguntas frecuentes
¿Quién debería revisar el código generado por IA?
Un ingeniero sénior capaz de leer el código, entender el negocio al que sirve y ser dueño de las decisiones de arquitectura. No el modelo que lo escribió, no un júnior que firma sin leer, y no un analizador automático a solas. La revisión es una tarea de criterio, así que necesita criterio humano cualificado.
¿Pueden las herramientas automáticas sustituir la revisión humana de código?
No. Los analizadores de dependencias y los linters cazan rápido los problemas mecánicos de patrón conocido, y deben estar en cada build. No pueden saber que el código resolvió correctamente el problema equivocado o que un límite de permisos está mal puesto. Eso exige una persona que entienda para qué sirve el software.
¿Qué caza un revisor humano que a la IA se le escapa?
Agujeros de seguridad que el modelo copió de sus datos de entrenamiento, importaciones de paquetes que no existen, lógica equivocada que no se cuelga y código duplicado que vuelve peligrosos los cambios futuros. Los cuatro salen directos a producción cuando nadie lee la salida antes de publicarla.
¿Revisar el código generado por IA ralentiza el proyecto?
Apenas, y ahorra mucho más después. La IA sigue comprimiendo la escritura, así que una construcción revisada se entrega en semanas, no meses. Saltarse la revisión solo parece más rápido hasta el primer incidente, cuando el atajo sin revisar se vuelve emergencia en vez de comentario de revisión.
¿Es el código de IA revisado tan seguro como el escrito por una persona?
Sí, por la misma razón por la que el código escrito por una persona es seguro: alguien cualificado lo leyó, lo probó y lo aseguró. La seguridad viene de la revisión y de las pruebas, no de si produjo el primer borrador una persona o un modelo. Revisado es la palabra que importa, no IA ni humano.
¿Cómo revisa Globaprom el código generado por IA?
Un ingeniero sénior lee cada línea antes de la fusión, el análisis de dependencias se ejecuta en cada build y una batería de pruebas demuestra el comportamiento antes de la entrega. Nuestros servicios de desarrollo asistido por IA ponen ese proceso por escrito, con revisores con nombre por los que puedes preguntar directamente.
La revisión es lo que estás comprando
La velocidad viene de la IA. La confianza viene de la revisión. Compra solo lo primero y tienes una demo que todavía no ha fallado; compra las dos y tienes software que sostiene una empresa. Cuéntanos qué necesitas construir y te mostraremos exactamente quién lee tu código y cuándo, junto a un alcance cerrado, un precio cerrado y una fecha de entrega.