# La IA no elimina la revisión del código: la convierte en el cuello de botella real > Generar código dejó de ser el límite. Ahora lo es el criterio para revisarlo. Por qué el volumen de código generado por IA hace la revisión más necesaria. - URL: https://fcgsystems.es/blog/la-ia-no-elimina-la-revision/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Software · Formato: Opinión · Lectura: 4 min - Palabra clave: revisar código generado por ia (también: código generado por ia, riesgos de la ia en desarrollo, revisión de código) Escribir código dejó de ser el cuello de botella hace un par de años. Lo que nadie dice en voz alta es que el cuello de botella no desapareció: se movió. Y se movió a un sitio donde casi nadie ha puesto capacidad. La escena la conoces. Un equipo que antes producía tres cambios a la semana ahora produce quince. La misma gente. Y todo el mundo lo celebra, porque lo que se mide es lo que sale, no lo que se ha mirado de verdad antes de salir. El problema es de cuentas. La capacidad de generar se ha multiplicado. La capacidad de juzgar sigue siendo la misma, porque depende de cuántas personas con criterio tienes y de cuántas horas de atención les caben en el día. Cuando una de las dos se dispara y la otra no, la diferencia no se evapora: se acumula en producción, en forma de cosas que nadie leyó con atención. ## El código generado falla de otra manera Y esto es lo que más me interesa. No es que la IA escriba peor. En muchos casos escribe mejor que la media, y desde luego más ordenado. El asunto es *cómo* falla. El código malo de un humano cansado suele tener mala pinta. Está desordenado, tiene nombres raros, se nota el parche. Tu instinto de revisor se enciende solo: cuando algo se lee mal, lo miras con lupa. El código generado se lee estupendamente. Nombres coherentes, estructura limpia, comentarios en su sitio. Todo pide a gritos que le des al aprobar. Y dentro puede haber una comprobación de permisos que da por hecho un rol que en tu sistema no significa lo mismo, una consulta que funciona con cien registros y muere con cien mil, o una gestión de errores que se traga la excepción y sigue como si nada. La superficie no te avisa. La IA escribe código inseguro igual de rápido que el seguro, y con la misma cara de seguridad. Hay un segundo efecto, más silencioso. Cuando el código lo has escrito tú, lo entiendes por el camino: has dudado, has probado, has descartado dos opciones. Ese proceso deja un mapa mental. Cuando lo genera un modelo, el mapa no existe salvo que lo construyas a propósito leyendo. Y el mapa es justo lo que necesitas seis meses después, a las once de la noche, cuando algo se ha roto y hay que decidir rápido. Lo que te faltará no serán líneas de código: será saber por qué está puesto así. ## La revisión de verdad no es leer el diff Aquí es donde la mayoría de equipos se engaña. Se abre el cambio, se echa un vistazo de treinta segundos, se aprueba. Eso no es revisar. Con quince cambios a la semana, eso es una firma. Revisar de verdad es hacer cuatro preguntas que ningún vistazo responde. **¿Resuelve el problema que teníamos, o uno parecido?** Es el fallo más común y el menos buscado. El código funciona, pasa los tests, hace algo razonable. Y no es lo que hacía falta. Cuando pides poco contexto, recibes una solución para el problema que describiste, no para el que tienes. **¿Qué rompe?** Tu sistema tiene invariantes que no están escritos en ningún sitio: ese campo nunca es nulo, ese proceso corre siempre después de aquel, ese identificador se usa en otros tres lados. Un modelo no los conoce. Tú sí, y eres el único que puede verlos. **¿Qué pasa en el caso feo?** El dato vacío, el usuario sin permisos, el reintento, los dos procesos a la vez. Lo generado cubre el camino feliz con una consistencia admirable. **¿Puedo mantener esto?** Si dentro de seis meses nadie sabe por qué está ahí, ya es deuda. Aunque funcione perfecto hoy. Lo determinista merece un párrafo aparte, porque es donde más veo colarse cosas: cualquier lógica de clasificación, umbral o mapeo que decide algo importante tiene que estar en código legible y probable, nunca escondida dentro de un prompt. Un umbral que vive en una frase de un prompt no se puede testear ni auditar. Es la misma regla que aplico al decidir [qué permisos tiene un agente](https://fcgsystems.es/blog/permisos-de-un-agente-decision-de-riesgo/). ## Qué hago yo Reviso todo lo que genero antes de fiarme. No por desconfianza ceremonial, sino porque "funciona" no es el listón; hay que adelantarse al fallo. En la práctica, tres cosas. Primero: **pedir en trozos pequeños**. Un cambio grande generado de golpe es un cambio que no se revisa, se hojea. Si no cabe en tu cabeza, no lo has revisado. Segundo: **poner señal externa antes que opinión**. Tipos, tests, linters, el build. Todo lo que una máquina pueda comprobar por ti libera tu atención para lo que solo tú puedes juzgar, que es si la solución tiene sentido en tu negocio. Tercero: **dar el contexto antes, no corregir después**. La mayoría de revisiones dolorosas se evitan explicando bien las restricciones al principio. Y una cuarta, la más incómoda: si no entiendo un trozo, no entra. Punto. Entender es tener el control, y aceptar código que no entiendes es firmar una hipoteca en un idioma que no lees. ## El criterio que te llevas La IA no ha eliminado el trabajo de ingeniería. Ha eliminado la parte que menos valor tenía, que era teclear, y ha dejado al descubierto la que siempre fue el trabajo de verdad: decidir qué hay que construir, verificar que lo construido aguanta y saber por qué está hecho así. Si tu equipo genera cinco veces más y revisa igual, no has ganado velocidad. Has ganado velocidad de emisión y has creado una cola invisible. La pregunta útil para medir si vas bien no es cuántos cambios salen a la semana, sino cuántos de ellos alguien podría defender delante de un cliente si mañana fallan. Tu curro no es teclear menos, es juzgar mejor. ## Servicios relacionados - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. - [Sistemas de IA](https://fcgsystems.es/servicios/inteligencia-artificial-aplicada/): Mensajes clasificados, llamadas resumidas en el CRM y leads priorizados, con pruebas y coste medido. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable.