Idea general
- No se trata de “declarar la muerte del sistema de PR” en sí, sino de la realidad de que, en la era de la IA, el PR ya no funciona como un “mecanismo para transmitir comprensión”.
- El problema central, antes incluso de la calidad del código, es que cada vez más el contexto, la intención y el criterio que deberían acompañar al código no se transmiten a través del PR.
- En conclusión, la esencia del PR sigue siendo válida, pero si no cambia su forma de operación (las condiciones de la compuerta), dejará de funcionar como línea de defensa.
1. Planteamiento del problema: ¿por qué se tambalea el PR?
- Si se interpreta que la causa del fracaso del PR es que “los revisores se volvieron perezosos”, se está entendiendo mal el problema.
- La causa real es la acumulación de un fenómeno en el que el PR Review ya no transmite comprensión. Es decir, el revisor (desarrollador) no logra entender la intención ni el contexto del PR.
- La IA reduce drásticamente el costo de generar PR, pero amplifica la asimetría existente (generar es rápido, revisar es lento).
2. El rol original del PR: no era un trámite de aprobación de código, sino un contrato de transferencia de responsabilidad
- El PR no era simplemente un proceso para revisar sintaxis del código o verificar que pasaran las pruebas.
- Su estructura implicaba una promesa tácita por parte del autor: “puedo explicar por qué lo construí de esta manera”.
- El revisor tenía el rol de examinar no solo el código en sí, sino también el criterio y la intención de diseño detrás de él.
- Es decir, el botón de merge no era solo un botón de aprobación de código, sino una decisión de consenso social por la cual el equipo aceptaba compartir la responsabilidad de ese cambio.
3. La compuerta ya era frágil desde antes
- El software de código abierto siempre fue el entorno que más expuso las debilidades de la estructura de PR.
- Por el desgaste mental y físico de los mantenedores, la brecha de contexto y la diversidad de contribuyentes, el PR tenía una estructura propensa a convertirse en una aprobación meramente formal.
- El caso del backdoor en xz Utils mostró, más que un fallo de automatización, la forma en que una compuerta humana agotada puede convertirse en superficie de ataque.
Es decir, incluso antes de la IA, la compuerta del PR ya era fragile (frágil), y las señales de sus límites venían acumulándose.
- Caso del backdoor en xz Utils: un ataque a la cadena de suministro de software open source en el que un contribuyente que construyó confianza durante más de dos años insertó un backdoor a través de un PR.
4. El cambio que trajo la IA: explosión de PR y de la asimetría en la revisión
- Con las herramientas de programación con IA, la velocidad y el volumen de generación de PR aumentaron drásticamente.
- En cambio, la revisión sigue dependiendo del tiempo, la concentración y la comprensión de contexto de las personas.
- Como resultado, aparece un patrón de más código, PR más grandes, revisiones más largas y más incidentes.
- Esto no niega la “mejora de productividad” en sí, sino que advierte que acelerar sin gobernanza puede terminar siendo más tóxico que beneficioso.
5. Un problema más profundo: código que funciona, pero que nadie puede explicar
- El riesgo del código generado por IA no es solo el “código que se rompe de inmediato”.
- El problema mayor es la acumulación de código que pasa pruebas, compila bien y aun así carece de una explicación de por qué fue escrito así.
- Cuando con el tiempo ocurre una falla, el equipo no corrige simplemente el problema, sino que termina interpretando y adivinando la intención de un código sin intención explícita.
- A diferencia de un bug común, esto es más peligroso porque no deja rastros de la decisión de diseño ni un responsable claro.
6. El concepto clave oculto: la IA rellena de forma convincente los vacíos de información
- La IA tiende menos a revelar lo que no sabe y más a rellenar los espacios en blanco con código plausible.
- El problema es que esos vacíos (supuestos ocultos, restricciones no verificadas) no se ven bien en la etapa del PR.
- Por eso, ya no se puede garantizar seguridad solo porque “el código corre / la documentación se ve convincente / los checks pasan”.
- Al final, lo que la compuerta del PR debe verificar no es si compila, sino si existe el reasoning de este cambio (por qué / qué / bajo qué restricciones).
7. Lo que mostró el caso de OpenClaw: una escala y velocidad que el PR no puede absorber
- El texto menciona a OpenClaw como un caso representativo donde el colapso del PR se reprodujo de forma condensada.
- OpenClaw (nombre inicial Clawdbot) fue un proyecto experimental / playground de carácter personal que Peter Steinberger comenzó alrededor de noviembre de 2025.
- En un periodo corto (unas 10 semanas), creció explosivamente y atrajo una gran cantidad de usuarios, contribuciones e interés externo.
- En ese proceso se combinaron problemas de seguridad, skills/contribuciones maliciosas y un aumento de la carga de revisión, llevando al proyecto a una situación difícil de sostener para un esquema de mantenimiento individual o de pequeño equipo.
- Más adelante (febrero de 2026), dejó una reflexión sobre el proyecto, señalando que para hacerlo más seguro harían falta más estructura, más recursos y acceso a investigación de punta.
- Después transfirió el proyecto y se unió a OpenAI.
- El artículo interpreta este punto no como una crítica personal, sino como una escena que muestra la brecha entre “el éxito de un prototipo brillante” y “la operación segura de una infraestructura de uso general”.
- También sostiene que el punto central no fue un solo error de implementación, sino una estructura en la que la escala, la velocidad y la diversidad de intenciones de las contribuciones superaron la capacidad humana de revisión.
- Aunque el mantenedor siguiera mejorando la seguridad, la velocidad de exposición y la velocidad de respuesta no competían en la misma carrera.
- Es decir, la causa del fracaso no fue “porque estuviera mal hecho”, sino porque una compuerta diseñada originalmente para un modelo de confianza personal/local no resistió una escala global.
8. El significado del cambio de configuración en GitHub: no es una función nueva, sino una señal de advertencia
- GitHub anunció oficialmente el 13 de febrero de 2026 la incorporación de una opción para desactivar los PR.
- Pero el autor lo interpreta no como una simple función de conveniencia, sino como un reconocimiento silencioso de que, en algunos repositorios, el PR en sí mismo se volvió un riesgo operativo.
- Es decir, enfatiza que esto debe leerse como una señal de que incluso la plataforma ya tiene dificultades para sostener la premisa de que “el PR siempre es algo bueno”.
9. Conclusión práctica del texto: no se trata de abandonar el PR, sino de redefinir la compuerta.
- No es un argumento para dejar de desarrollar herramientas de código con IA.
- Más bien, la pregunta no es “si usar IA”, sino si se la usará sin una compuerta que realmente funcione.
- Lo necesario no es una lista de reglas, sino principios operativos como explicabilidad, diseño previo, declaración de aspectos no verificados, facultad del mantenedor para rechazar y trazabilidad.
- Un PR cuyo razonamiento no puede rastrearse no se convierte en un activo intelectual que el equipo posee, sino en una deuda que terminará dominando al equipo.
10. Resumen en una línea
- El propósito del PR no es solo que el código pase, sino transferir junto con él la comprensión y la responsabilidad.
- La pregunta clave en la era de la IA: más que “¿el código funciona?”, “¿podemos explicar este código?”
- Esa pregunta no es un obstáculo para la productividad, sino la condición mínima para proteger la última línea de defensa del software
2 comentarios
La persona que pide la revisión solo hace clic, y quien revisa es quien se exprime la cabeza; ya se volvió un medio no solo para trasladar la responsabilidad, sino para directamente encargarle el trabajo a otra persona.
Es un texto con el que me identifico muchísimo.
En los últimos meses me ha resultado muy difícil ver que el código generado por IA que hacen los miembros del equipo termine llegando como PR, y he estado probando muchas formas de mejorarlo.
Además de acotar el alcance de los PR, como se menciona en el texto, también estoy pensando qué es lo que realmente debemos revisar.
No se trata de revisar el código, sino de pensar en una revisión de código que revise la intención.