Los agentes de código escriben más rápido de lo que un equipo humano puede revisar. Esa frase parece una observación menor sobre productividad. No lo es. Describe un desplazamiento del cuello de botella que la mayoría de las organizaciones todavía no ha reconocido, porque las métricas con las que miden a sus equipos siguen contando lo que se produce y no lo que se aprueba con criterio.
Durante quince años el trabajo escaso fue escribir código. Ahí se puso el dinero, ahí se midió la productividad y ahí se construyeron las herramientas. La revisión era el trámite del final.
Se ha dado la vuelta. Y el problema es que el trámite del final ahora es la única barrera entre un agente que genera con enorme seguridad y un sistema en producción que nadie ha entendido del todo.
La generación asistida de código ha movido el cuello de botella de escribir a revisar. El volumen que un agente produce en una tarde supera lo que un revisor puede leer con atención en una semana, y el riesgo no es el código roto, que se detecta, sino el código plausible que pasa la revisión sin que nadie lo haya comprendido. En España la señal ya está en las ofertas: 1.563 mencionan revisión de código y 779 nombran Copilot. La competencia escasa dejó de ser producir y pasó a ser juzgar.
Qué cambió exactamente cuando llegaron los agentes
Conviene ser preciso, porque la conversación pública mezcla dos cosas distintas.
La primera es la velocidad de generación, que efectivamente ha subido mucho y es la que sale en las presentaciones. La segunda, mucho menos comentada, es la naturaleza de lo que llega a revisión, y ahí está el cambio que de verdad importa: un agente no produce el mismo tipo de error que produce una persona con prisa, sino uno distinto, más difícil de detectar y considerablemente mejor escrito.
Un desarrollador cansado deja código que se nota. Nombres apresurados, un bloque comentado que sobra, una función que hace tres cosas a la vez porque a las siete de la tarde separarla en tres parecía un lujo innecesario. El revisor lo detecta porque el desorden es visible.
Un agente entrega otra cosa. Entrega código ordenado, con nombres coherentes, con la estructura que cualquier revisor esperaría de un commit cuidado por alguien con experiencia y con comentarios que explican, además, correctamente lo que hace cada bloque. Todo eso puede ser cierto y aun así el conjunto puede estar resolviendo el problema equivocado, apoyándose en una suposición que nadie verificó o introduciendo una dependencia que nadie pidió.
El error dejó de ser feo. Ese es el cambio.
Por qué revisar cuesta más que escribir
Hay una asimetría cognitiva que explica casi todo lo demás.
Cuando alguien escribe una función, construye durante el proceso un modelo mental del problema: por qué esa estructura, qué casos consideró, qué descartó y por qué motivo. Ese modelo queda en su cabeza y el código es solo su residuo.
Cuando alguien revisa una función que no escribió, tiene que reconstruir ese modelo desde el residuo, sin acceso a las decisiones intermedias, sin saber qué alternativas se evaluaron y sin la ventaja de haber recorrido el camino. Reconstruir cuesta más que construir. Siempre ha sido así, y durante años no importó demasiado porque el volumen que llegaba a revisión estaba limitado por la velocidad a la que una persona podía teclear, de manera que la asimetría existía pero quedaba escondida bajo el techo natural de la producción humana.
Ahora sí. Si un agente genera en una tarde lo que antes ocupaba una semana, el revisor recibe siete veces más residuo del que puede procesar, y el resultado predecible es que la revisión se degrada a una comprobación de superficie: compila, los tests pasan, el estilo es correcto, adelante.
Eso no es revisar. Es firmar.
Qué tipo de fallo se cuela
El código que no funciona no es el problema. Ese lo caza la integración continua, o lo caza el primer usuario, y en cualquier caso se detecta pronto y se arregla.
El fallo que sobrevive a una revisión degradada es otro: el que funciona. Funciona en el caso que se probó, tiene buena pinta, pasa sin despeinarse los tests que el propio agente escribió para comprobarse a sí mismo, y contiene en algún punto una decisión de diseño que nadie tomó conscientemente y que nadie sabrá reconstruir dentro de seis meses, cuando alguien pregunte por qué eso está hecho así.
Los tres patrones que más se repiten son estos. Una suposición implícita sobre los datos de entrada que se cumple hoy y dejará de cumplirse cuando cambie el proveedor. Una dependencia nueva que entra sin revisión de licencia ni de mantenimiento, que es exactamente el vector que hace peligroso al slopsquatting. Y un manejo de errores que captura la excepción, la registra y sigue adelante como si nada hubiera pasado, ocultando durante meses un fallo que se habría visto el primer día.
Ninguno de los tres es un bug. Los tres son deuda, y la deuda que entra por una revisión superficial no aparece en ningún panel hasta que ya cuesta cara.
Qué dice el mercado español
La señal está en las ofertas de empleo, y es más nítida de lo que cabría esperar de un cambio tan reciente.
Según el análisis de mercado de Shakers, sobre 23.581 ofertas de tecnología activas en España entre el 14 de junio y el 25 de agosto de 2026, hay 1.563 que mencionan explícitamente la revisión de código. Es una de cada quince. Y 779 nombran Copilot, aproximadamente una de cada treinta.
El dato relevante no es que las herramientas de generación se hayan normalizado, cosa que ya se daba por hecha. Es que la revisión aparece nombrada como requisito en un volumen de ofertas que multiplica por dos a las que citan la herramienta, lo cual sugiere que las organizaciones están pidiendo la competencia de juzgar código ajeno con mucha más insistencia que la de producirlo con ayuda.
Encaja con lo que BCG midió en enero de 2025: tres de cada cuatro empresas habían probado IA y solo una de cada cuatro veía resultados relevantes. La diferencia entre las dos cifras no está en el acceso a la herramienta, que es universal y barato, sino en la capacidad de sostener lo que la herramienta produce.
Por qué no se resuelve poniendo más revisores
La respuesta intuitiva es aumentar el equipo de revisión. No funciona, por tres motivos que conviene separar.
El primero es que la revisión no se reparte bien entre varias personas. Dos revisores sobre el mismo cambio no van el doble de rápido: se dividen la superficie, cada uno ve menos contexto del que necesitaría para juzgar el conjunto, y la probabilidad de que algo se cuele por la costura entre las dos mitades aumenta en lugar de bajar.
El segundo es que revisar bien exige conocer el sistema. Alguien que entra hoy puede escribir código útil en dos semanas, pero no estará en condiciones de juzgar un cambio en el núcleo hasta pasados varios meses, porque juzgar no consiste en leer lo que hay delante sino en saber qué se rompió la última vez que alguien tocó esa zona y quién tuvo que quedarse a arreglarlo.
El tercero es el que más duele. Los perfiles capaces de hacer esa revisión son exactamente los mismos que están ocupados con el resto del trabajo difícil, así que ampliar la revisión significa quitarles tiempo de otra cosa que también solo pueden hacer ellos.
De ahí que la salida realista no sea más gente revisando, sino cambiar qué se revisa y con qué criterio se prioriza.
Qué se hace en su lugar
Cuatro decisiones que sí mueven la aguja, ordenadas por lo que rinden.
Revisar por riesgo, no por línea. Un cambio en autenticación, en gestión de permisos o en cualquier punto del sistema que toque dinero merece una revisión completa, sin prisa y hecha por alguien con experiencia suficiente para reconocer las formas en que ese código puede fallar en producción. Un cambio en una pantalla interna no. Tratar todo el código con el mismo nivel de escrutinio garantiza que el escrutinio será superficial justo donde importa.
Exigir la intención, no solo el diff. Si quien propone el cambio, sea persona o agente, no puede explicar en tres líneas qué problema resuelve y qué descartó por el camino, el revisor no tiene contra qué contrastar. Esa explicación es el modelo mental que falta, y pedirla convierte una revisión imposible en una comprobación acotada. Es el mismo principio que sostiene el desarrollo guiado por especificación.
Automatizar lo mecánico para liberar lo cognitivo. Estilo, formato, cobertura y detección de patrones conocidos no deben consumir ni un minuto de atención humana. Todo lo que una máquina pueda comprobar tiene que estar ya comprobado, y en verde, antes de que un revisor humano abra el cambio por primera vez, porque cada minuto que esa persona dedica a señalar una coma es un minuto que no dedica a lo único que ella puede hacer. Esa disciplina es parte de lo que hoy se agrupa bajo el harness engineering.
Medir la revisión como trabajo. Mientras revisar siga siendo eso que uno hace entre tareas de verdad, con la cabeza puesta en lo que tenía a medias y el cronómetro corriendo hacia la siguiente reunión, se hará mal y además se hará con mala conciencia. Si es el cuello de botella del sistema, ocupa un hueco en la planificación como cualquier otra actividad crítica.
Qué competencia hay que buscar ahora
El perfil que resuelve esto no es el que más código produce.
Es alguien que lee un cambio y detecta la suposición que no está escrita en ninguna parte. Que pregunta por qué se eligió esa librería y no la que ya estaba en el proyecto. Que reconoce cuándo un test comprueba el comportamiento y cuándo se limita a confirmar lo que el código ya hace. Y que sabe cuándo dejar de revisar y devolver el cambio a su autor con una pregunta en lugar de seguir leyendo líneas por inercia hasta convencerse de que probablemente esté bien.
Esa competencia no se acredita con un certificado ni se detecta en una prueba técnica de escribir código, porque lo que hay que evaluar es precisamente lo contrario: cómo juzga alguien el trabajo de otro. La forma práctica de comprobarlo es darle un cambio real con un problema plantado dentro y ver qué pregunta. No qué encuentra. Qué pregunta.
Preguntas frecuentes sobre revisión de código y agentes
- ¿Los agentes de código reducen o aumentan la carga de revisión?
La aumentan en la práctica, aunque reduzcan el tiempo de escritura. El volumen que llega a revisión crece, y el tipo de error cambia: el código generado suele estar bien estructurado y bien nombrado, así que los fallos de criterio no se detectan por inspección visual. El resultado es más material que revisar y menos pistas superficiales para hacerlo rápido.
- ¿Puede otro agente revisar el código que genera un agente?
Sirve para lo mecánico y no sustituye el juicio. Un revisor automático detecta patrones conocidos, problemas de estilo y algunas clases de fallo, que es exactamente el trabajo que conviene quitarle a una persona. Lo que no puede hacer es decidir si el cambio resuelve el problema correcto, porque esa evaluación exige conocer el contexto de negocio y el historial del sistema.
- ¿Qué tipo de fallo se cuela en una revisión superficial?
No el código roto, que lo detecta la integración continua. Se cuela el código que funciona en el caso probado y contiene una decisión que nadie tomó de forma consciente: una suposición sobre los datos de entrada que dejará de cumplirse, una dependencia nueva sin revisar o un manejo de errores que oculta el fallo en lugar de exponerlo.
- ¿Se arregla ampliando el equipo de revisión?
No, por tres motivos. La revisión no se reparte bien, porque dividir un cambio entre dos personas reduce el contexto de cada una. Revisar con criterio exige conocer el sistema, y eso tarda meses. Y los perfiles capaces de hacerlo son los mismos que ya están ocupados con el resto del trabajo difícil, así que ampliar la revisión es quitarles tiempo de otra cosa.
- ¿Cómo se evalúa a alguien para esta competencia?
No con una prueba de escribir código, porque lo que hay que medir es cómo juzga el trabajo ajeno. Lo que funciona es entregar un cambio real con un problema plantado dentro y observar qué preguntas hace: si detecta la suposición no escrita, si cuestiona la dependencia añadida y si distingue un test que comprueba comportamiento de uno que confirma lo que el código ya hace.