De todos los números que ha dejado 2026 sobre programar con IA, hay uno que no aparece en ninguna presentación de ventas: los pull requests que se mergean sin ninguna revisión, ni humana ni automática, subieron un 31,3%. El dato es de Faros AI, sobre dos años de telemetría de 22.000 desarrolladores en más de 4.000 equipos. En el mismo periodo, los bugs por desarrollador subieron un 54% y la proporción de incidentes por pull request se multiplicó por más de tres.
La lectura fácil es que la gente se ha vuelto descuidada. La lectura útil es otra: el review no se está saltando por dejadez, se está saltando porque el proceso pide algo que ya no se puede dar. Cuando llega el triple de cambios, cada uno el doble de grande, y quien los envía no puede explicarlos mejor que tú, la revisión deja de ser un control y pasa a ser una cola. Y las colas, cuando aprietan, se drenan por el sitio más barato: aprobando.
Esta pieza no va de revisar más rápido. Va de que revisar código generado es revisar otra cosa, y de qué hay que cambiar en el proceso cuando el autor deja de existir como interlocutor.
Primero, la objeción seria
Conviene despacharla antes de construir nada encima, porque si es correcta, media industria está optimizando el sitio equivocado.
En junio de 2026, GitLab publicó con Harris Poll una encuesta a 1.528 desarrolladores y compradores de tecnología en seis países: el 85% está de acuerdo en que la IA ha movido el cuello de botella de escribir código a revisarlo y validarlo. El 78% dice que sus desarrolladores escriben y comitean más rápido desde que adoptaron IA, y el 79% suscribe lo que el informe llama la paradoja: la productividad individual mejoró, la entrega global no siguió el ritmo.
Steve Fenton, en julio de 2026, discute la premisa completa. Su argumento es que ni programar era el cuello de botella antes ni el review lo es ahora, y propone una prueba que se contesta en un minuto: en el sistema en el que trabajas, ¿cuántos cambios han pasado el review y todavía no están desplegados y activos para usuarios? Si ese número está muy por encima de cero, la restricción no está en el review — está aguas abajo. Su señal es el despliegue por lotes: según sus datos, el 92% de los equipos despliega en lote y sólo el 8% despliega cambios de forma independiente. Acelerar la generación de código con IA, sin tocar eso, produce lotes más grandes, no entregas más tempranas.
Fenton tiene razón, y no invalida nada de lo que viene después. Están midiendo dos cosas distintas y las dos importan:
Qué dicen los datos, y de quién son
Antes de la tabla, una advertencia de procedencia que casi nunca se hace y que aquí cambia cuánto peso soporta cada cifra. Buena parte de los datos disponibles sobre esto los publican empresas que venden herramientas de analítica de ingeniería o de seguridad de código. No los descarta —son las únicas series longitudinales grandes que existen—, pero no son revisión por pares y el sesgo de selección de sus clientes es real. Lo marco en la última columna.
| Qué se midió | El número | Qué tipo de fuente es |
|---|---|---|
| Volumen y defectos | Epics por desarrollador +66%; bugs por desarrollador +54% (frente a +9% el año anterior); incidentes por pull request +242,7%; merges sin ninguna revisión +31,3% | Telemetría de proveedor (Faros AI, 22.000 devs, 2 años) |
| Tamaño y espera del PR | PR asistidos por IA: más de 400 líneas en el percentil 75 frente a 157 de los no asistidos; espera al primer revisor de unas 16 horas frente a algo más de 3; tasa de aceptación 32,7% frente a 84,5% | Telemetría de proveedor (LinearB, 8,1 M de PR, 4.800 equipos) |
| Forma del código | Movimiento de código por refactorización: 21% en 2022 → 3,8% en 2026. Copiar y pegar: 9,4% → 15,7%. Duplicación de bloques +81%. Llamadas entre ficheros −35% desde 2023 | Telemetría de proveedor (GitClear, 623 M de cambios) |
| Seguridad de lo generado | 55% de las muestras pasa las pruebas de seguridad —plano en dos años— con más del 95% de corrección sintáctica. Por lenguaje: Python 62%, Java 29%. Por fallo: XSS 15%, inyección en logs 13% | Banco de pruebas de proveedor (Veracode, 80 tareas, +150 modelos) |
| Estabilidad de la entrega | 90% usa IA en el trabajo y más del 80% cree que le ha subido la productividad; el 30% declara poca o ninguna confianza en el código que genera. La adopción de IA correlaciona positivo con caudal y negativo con estabilidad | Investigación con muestra amplia (DORA 2025, ~5.000 profesionales) |
| Experiencia declarada | 66% se topa con «soluciones casi correctas, pero no del todo»; 45,2% dice que depurar código generado le lleva más tiempo. Confían en su exactitud un 32,7% frente a un 45,7% que desconfía | Encuesta abierta (Stack Overflow 2025, ~33.000 respuestas en la sección de IA) |
Seis mediciones independientes que apuntan al mismo sitio: más caudal, misma o peor calidad, y menos revisión efectiva
La convergencia es lo interesante. GitClear y LinearB no comparten metodología ni clientes, y los dos encuentran lo mismo por caminos distintos: la refactorización desaparece. En GitClear, el movimiento de código cae al 3,8%; en LinearB, la tasa de refactorización de los pull requests asistidos por IA es prácticamente cero frente a un 37% en los no asistidos. Cuando dos telemetrías con sesgos diferentes coinciden en la dirección y en el orden de magnitud, la señal aguanta más peso que cualquiera de las dos por separado.
Los cuatro supuestos que se rompieron
El code review moderno se estabilizó en la industria alrededor de una idea sencilla: dos personas miran un cambio, una lo explica y la otra pregunta. Todo el valor está en la conversación, no en el formulario. Y esa conversación descansa sobre cuatro supuestos que hasta 2024 se cumplían solos.
1 · Que existe alguien a quien preguntarle por qué
Es el supuesto que sostiene todos los demás. «¿Por qué lo hiciste así?» era la pregunta más productiva de un review porque tenía destinatario: alguien había considerado alternativas y descartado unas cuantas. Con un cambio generado, esa persona puede no existir. Quien abre el pull request revisó una salida y le pareció bien, que es exactamente lo que va a hacer el revisor. Se han duplicado los lectores y se ha quedado sin autor.
El efecto práctico: el review se desliza de detectar problemas de diseño a detectar problemas de superficie. Y los problemas de superficie son justo los que el generador ya no comete.
2 · Que escribir cuesta más que revisar
Toda la economía del review dependía de esta asimetría. Escribir doscientas líneas costaba una tarde; leerlas, veinte minutos. Por eso era razonable que una persona revisara el trabajo de varias. Cuando generar esas doscientas líneas pasa a costar noventa segundos y leerlas sigue costando veinte minutos, la relación se invierte y el sistema se atasca por donde no se había diseñado para atascarse. Los datos de espera de LinearB —de tres horas a dieciséis para el primer revisor— no describen revisores más lentos: describen la misma capacidad de lectura contra un caudal multiplicado.
3 · Que el tamaño del diff refleja el tamaño de la decisión
Un pull request grande solía significar un cambio importante, y por eso merecía más atención. Ahora un diff de cuatrocientas líneas puede ser una decisión trivial expresada con generosidad, o tres decisiones serias escondidas entre andamiaje. El tamaño dejó de ser señal, y con él se cayó la heurística que los equipos usaban para repartir esfuerzo de revisión.
4 · Que el código nuevo se parece al que ya hay
Un desarrollador que lleva un año en el repositorio reutiliza sin pensarlo: sabe que esa validación ya existe. Un generador, con la ventana de contexto que sea, tiende a resolver el problema que tiene delante escribiéndolo otra vez. De ahí el hallazgo de GitClear que más incomoda: en 2026 la duplicación de bloques ha subido un 81% respecto a 2023 y las llamadas a funciones de otros ficheros —el mejor indicador barato de reutilización— han caído un 35%.
Y esto es lo que ningún review basado en el diff puede ver. Un bloque duplicado es impecable dentro de su pull request. Sólo es un problema en relación con algo que está en otro fichero, que el revisor no tiene abierto, y que a menudo no sabe que existe. La revisión de código está estructuralmente ciega al modo de fallo dominante del código generado.
La trampa de la percepción
Aquí entra la fuente más incómoda de esta pieza, y merece contarse con todas sus limitaciones porque se cita muy mal.
En julio de 2025, METR publicó un ensayo controlado aleatorizado con 16 desarrolladores de código abierto experimentados, sobre 246 tareas reales en repositorios propios —una media de más de 22.000 estrellas y más de un millón de líneas—, con Cursor Pro y Claude 3.5/3.7 Sonnet. Antes de empezar, los participantes pronosticaron que la IA les haría un 24% más rápidos. El resultado medido fue que tardaron un 19% más. Y lo que convierte el estudio en algo más que una anécdota: después de haber hecho las tareas, seguían estimando que la IA les había hecho un 20% más rápidos.
Las limitaciones son grandes y los propios autores las escriben: la muestra es pequeña, son repositorios que los participantes conocían a fondo, las herramientas son de principios de 2025 y METR marca hoy el resultado como histórico, sin afirmar que describa los flujos de trabajo actuales. No sirve para sostener que la IA hace más lenta a la gente. Ninguna de esas limitaciones toca, sin embargo, el hallazgo que importa aquí:
Esto explica el dato con el que empieza el artículo mejor que la hipótesis de la dejadez. Un equipo que aprueba rápido no está siendo negligente: está aplicando su intuición calibrada durante años sobre cuánto tarda alguien en escribir algo y cuánto cuidado merece leerlo. Esa intuición se ha quedado sin base, y como toda intuición rota, falla en silencio y con confianza. Es el mismo mecanismo que hace que el ROI de Copilot y Cursor se mida donde no está: se pregunta a la gente si va más rápido en lugar de mirar qué llega a producción y qué vuelve.
Lo que el generador no revisa de sí mismo
La respuesta reflexiva del mercado es poner un revisor automático delante. Es una buena idea mal dimensionada, y los datos de Veracode explican por qué.
En su actualización de 2026, con 80 tareas de código, cuatro lenguajes y más de 150 modelos evaluados a lo largo del tiempo, la corrección sintáctica supera el 95% mientras la tasa de aprobado en seguridad se queda en el 55% — y esa segunda cifra lleva dos años esencialmente plana. Los modelos han mejorado mucho en escribir código que funciona y nada en escribir código que no se puede explotar. El desglose es más elocuente que el agregado: Python aprueba el 62% y Java el 29%; y por tipo de fallo, la inyección de logs aprueba el 13% y el cross-site scripting el 15%, frente al 82-86% de la inyección SQL y la criptografía insegura. Ni siquiera los lanzamientos más recientes mueven la aguja de forma apreciable, con la excepción parcial de los modelos de razonamiento, en torno al 70-72%.
La conclusión operativa no es «no uses revisión automática». Es que la revisión automática es más fuerte justo donde el código generado ya es fuerte, y comparte puntos ciegos con el generador. Sirve como primera pasada sobre diffs largos y como sustituto del linter. No sirve como último eslabón antes de mergear, por la misma razón por la que los filtros no pueden ser el último eslabón antes de una acción irreversible: un porcentaje alto de detección es una buena noticia para el coste del error y una mala base para una garantía.
Y hay un efecto de segundo orden peor que el técnico. Un revisor automático visible en el pull request produce la sensación de que alguien ya ha mirado. El 31,3% más de merges sin ninguna revisión de la telemetría de Faros es consistente con eso: no es que la máquina revise mal, es que su presencia se lee como permiso para no mirar.
Qué se cambia en el proceso
Nada de lo que sigue requiere herramienta nueva ni parar entregas. Son cambios de contrato entre quien abre un pull request y quien lo aprueba.
| El cambio | Qué supuesto roto repara | Cómo se sabe que funciona |
|---|---|---|
| Techo duro de tamaño, y se devuelve sin leer | Que el tamaño ya no es señal. Partir dejó de ser caro: el coste de generar era el que hacía razonable el PR grande | Percentil 75 del tamaño de PR estable mes a mes, no creciendo |
| El PR llega con la especificación contra la que se generó | Que existe un autor. Si nadie puede explicar el porqué, el porqué tiene que venir escrito antes y por separado | Los comentarios de review citan la spec, no sólo líneas |
| Revisar por riesgo declarado, no por líneas | Que el diff refleja la decisión. El autor marca qué toca dinero, datos personales, permisos o migraciones | Reparto de tiempo de revisión desacoplado del tamaño |
| Buscar el duplicado fuera del diff | La ceguera estructural: el bloque clonado es impecable dentro de su PR | Tasa de duplicación del repositorio, medida y en el panel |
| Los tests son el artefacto que se revisa primero | Que el revisor puede simular el comportamiento leyendo. Con 400 líneas ajenas, no puede | Los tests fallan al menos una vez antes de pasar (si no, no prueban nada) |
| La revisión automática va delante, nunca al final | Comparte puntos ciegos con el generador: fuerte en sintaxis, floja en XSS e inyección en logs | Cero merges con aprobación exclusivamente automática |
| Prohibido aprobar sin comentario en cambios de riesgo | Que aprobar rápido es señal de calidad. Con la intuición descalibrada, es señal de cola | Porcentaje de merges con cero comentarios, por nivel de riesgo |
Siete cambios de contrato, ninguno de herramienta
El artefacto que devuelve el porqué al pull request
De los siete, el segundo es el que sostiene a los demás, y es también donde esto conecta con algo que ya defendíamos antes de que los datos lo respaldaran.
Si el review perdió valor porque perdió al autor, la reparación no es buscar un autor que ya no existe: es mover el porqué a un artefacto que se escribe antes de generar y se revisa aparte. Eso es exactamente lo que hace el Spec-Driven Development: la especificación deja de ser documentación que envejece y pasa a ser la unidad que se discute, se aprueba y se versiona. El código generado se convierte en su consecuencia comprobable, no en la fuente de verdad.
Visto desde el review, el cambio es concreto. La conversación se parte en dos, y cada mitad recupera un interlocutor:
- Sobre la especificación —antes de generar nada— sí hay un autor humano con intención, alternativas descartadas y criterios. Es la conversación cara que merece la pena tener, y cuesta minutos porque el artefacto es corto.
- Sobre el código la pregunta deja de ser «¿por qué así?» y pasa a ser «¿hace esto lo que dice la spec, y qué hace además de eso?». Es una pregunta que un revisor sí puede contestar leyendo un diff, incluso sin haber escrito nada.
El «y qué hace además de eso» es la parte que la gente se salta y donde vive el problema real, porque el código generado tiende a traer trabajo no pedido: una dependencia nueva, un fichero de configuración tocado de paso, un manejo de errores que se traga la excepción. Ese exceso es invisible si revisas contra tu memoria de lo que se pidió, y evidente si revisas contra un documento. Es también, dicho sea de paso, lo que separa un MVP de un quick ship.
La misma lógica que hace que un golden set sea el artefacto que sobrevive a los cambios de modelo en un sistema de IA opera aquí: lo que persiste no es la salida, es el criterio contra el que se juzga. Y si ese criterio no está escrito en ningún sitio, cada review lo reinventa — con el resultado desigual que cabe esperar.
Cómo saber si esto te está pasando
Cinco preguntas que se contestan con los datos que tu repositorio ya guarda. No hacen falta encuestas de percepción — que, como acabamos de ver, son justo lo que no funciona aquí.
- ¿Qué porcentaje de tus merges de los últimos treinta días entró con cero comentarios? Si sube mes a mes mientras sube el volumen, tu review ya es un trámite. Es la medición más barata y la que más duele.
- ¿Qué porcentaje de tus incidentes salió de un cambio que sí pasó el review? Mide si detecta algo. Un review que aprueba todo y no evita nada tiene coste y no tiene función.
- ¿Está creciendo el percentil 75 del tamaño de tus pull requests? Es el indicador adelantado de todo lo demás, y el más fácil de corregir con una regla de equipo.
- ¿Cuánta duplicación tiene tu repositorio hoy frente a hace un año? Si no lo sabes, el modo de fallo dominante del código generado no está en tu panel.
- ¿Cuántos cambios han pasado el review y no están desplegados? La prueba de Fenton. Si es alta, arregla eso primero: rediseñar el review no te va a entregar antes.
Las cuatro primeras dicen si tu review sigue haciendo su trabajo. La quinta dice si el review es siquiera tu problema más urgente. Vale la pena en ese orden, y vale la pena tenerlas antes de la próxima conversación sobre comprar otra licencia — porque el patrón que describe el gap del 70% se repite aquí exactamente igual: la herramienta llegó, el método no.
Los equipos que están saliendo bien de esto no revisan más rápido ni revisan menos. Revisan otra cosa: un documento corto antes de generar, y un diff acotado después, contra ese documento. Suena a más pasos. En horas de persona sale más barato que leer cuatrocientas líneas que nadie escribió, buscando un error que, si es el habitual, ni siquiera está dentro del pull request.
Preguntas frecuentes
¿De verdad se ha movido el cuello de botella al code review?
Depende de qué llames cuello de botella, y conviene ser preciso porque la respuesta cambia la inversión. En la encuesta de GitLab de junio de 2026, el 85% de 1.528 desarrolladores y compradores de tecnología dice que sí. Steve Fenton discute la premisa entera: si el trabajo se acumula después del review —cambios aprobados que no están desplegados— entonces la restricción está aguas abajo, en el despliegue por lotes, y acelerar el review no entrega nada antes. Los dos pueden tener razón a la vez, porque hablan de cosas distintas: el review casi nunca es tu restricción de caudal, pero es donde se concentra el riesgo. Se rediseña por lo segundo, no por lo primero.
¿Qué cambia exactamente al revisar código generado por IA?
Se rompe el supuesto de que existe un autor. Un review tradicional es una conversación con alguien que tomó decisiones y puede explicarlas: por qué esta estructura, qué alternativa descartó, qué pasa si llega un valor nulo. Con código generado, quien abre el pull request a menudo lo está leyendo por primera vez con la misma atención que el revisor. La pregunta «¿por qué lo hiciste así?» deja de tener destinatario, y con ella se cae buena parte del mecanismo por el que el review detectaba problemas de diseño y no sólo de sintaxis.
¿Los datos dicen que el código generado es peor?
Dicen algo más incómodo: no es peor línea a línea, es más y peor conectado. Veracode midió en 2026 que el 55% de las muestras generadas pasan sus pruebas de seguridad —una cifra plana durante dos años— mientras la corrección sintáctica supera el 95%. GitClear, sobre 623 millones de cambios entre 2023 y 2026, encuentra que el movimiento de código propio de la refactorización cayó del 21% en 2022 al 3,8% en 2026 y que el copiar y pegar subió del 9,4% al 15,7%. El código compila, pasa, parece razonable en el diff y duplica lo que ya existía tres carpetas más allá. Eso no se ve leyendo el pull request: se ve leyendo el repositorio.
¿Sirve poner una IA a revisar el código de otra IA?
Sirve para la capa que ya cubría el linter y para dar una primera pasada sobre diffs largos, y es una mejora real frente a no mirar nada. No sirve como último eslabón, por dos razones medidas. La primera es que el modo de fallo del código generado no es sintáctico, y la revisión automática es más fuerte justo donde el código ya es fuerte. La segunda la puso Faros en su telemetría de 2026: los pull requests que se mergean sin ninguna revisión, humana o agéntica, subieron un 31,3%. El riesgo práctico no es que el revisor automático se equivoque, es que su presencia se lea como permiso para no mirar.
¿Cómo se revisa un pull request de 400 líneas que nadie escribió?
No se revisa: se devuelve. Es la única regla de esta pieza que funciona sin nada más, y la que más resistencia genera. Los datos de LinearB sobre 8,1 millones de pull requests sitúan los asistidos por IA en más de 400 líneas en el percentil 75, frente a 157 de los no asistidos, y su tasa de aceptación cae del 84,5% al 32,7%. Un cambio grande generado en veinte minutos cuesta lo mismo de partir que uno pequeño, porque el coste de generar dejó de ser el límite. Lo que sí hay que cambiar con él es qué acompaña al pull request: la especificación contra la que se generó, y los casos que la comprueban.
¿Por dónde empiezo esta semana sin parar entregas?
Por medir dos cosas que casi nadie tiene en el panel y que no requieren herramienta nueva: qué porcentaje de vuestros merges de los últimos treinta días entró con cero comentarios de revisión, y qué porcentaje de vuestros incidentes de ese mes salió de un cambio que sí pasó el review. La primera dice si el review existe o es un trámite; la segunda, si detecta algo. Con esas dos cifras encima de la mesa, la conversación sobre el tamaño de los pull requests y sobre qué debe acompañarlos deja de ser una opinión de estilo y pasa a tener un número al lado.
Fuentes citadas
- Faros AI — The AI Engineering Report 2026: The Acceleration Whiplash (dos años de telemetría de 22.000 desarrolladores en más de 4.000 equipos; merges sin revisión +31,3%, bugs por desarrollador +54%, incidentes por PR +242,7%)
- LinearB — 2026 Software Engineering Benchmarks Report (8,1 millones de pull requests, 4.800 equipos, 42 países; tamaño, espera al primer revisor y tasa de aceptación por tipo de PR)
- GitClear — The Maintainability Gap: 2026 AI Code Quality Research (623 millones de cambios entre 2023 y 2026; refactorización, duplicación y llamadas entre ficheros)
- Veracode — Spring 2026 GenAI Code Security Update (80 tareas, cuatro lenguajes, más de 150 modelos; 55% de aprobado en seguridad frente a más del 95% de corrección sintáctica)
- DORA / Google Cloud — 2025 DORA Report · State of AI-assisted Software Development (cerca de 5.000 profesionales; relación positiva con el caudal y negativa con la estabilidad de la entrega)
- Stack Overflow — 2025 Developer Survey · AI (66% «casi correcto, pero no del todo»; 45,2% más tiempo depurando código generado)
- METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (16 desarrolladores, 246 tareas; pronóstico de +24% de velocidad, resultado de −19%, percepción posterior de +20%). Los autores acotan explícitamente el alcance del resultado y METR lo marca hoy como histórico
- GitLab y The Harris Poll — AI Accountability Report (23 de junio de 2026; 1.528 encuestados en seis países; el 85% del «cuello de botella movido al review»)
- Fenton, S. — Code Review Isn't Your Bottleneck, Even With AI (21 de julio de 2026; la prueba de los cambios aprobados y no desplegados, y el despliegue por lotes)
Jordi García es Tech Lead en onext. Trabaja en llevar la IA a producción gobernada en equipos de desarrollo y de producto —con Spec-Driven Development, ingeniería de contexto y verificación humana en cada paso— y firma los insights técnicos de onext sobre método, calidad y coste de la IA aplicada.
LinkedIn →