Dejad de enviarme PRs enormes; una diatriba
Los pull requests enormes generados por IA están abrumando a los revisores humanos de código y poniendo de manifiesto los límites de los flujos de trabajo de desarrollo actuales. Los comentaristas debaten si imponer límites estrictos al tamaño de los PR, confiar más en la revisión automatizada y asistida por IA, o replantear la planificación de funcionalidades para introducir cambios en fragmentos más pequeños y narrativos, más fáciles de entender y probar. Debajo de la discusión sobre herramientas hay una preocupación más profunda por la responsabilidad, la calidad del software y cuánto puede delegarse con seguridad en los modelos de lenguaje grandes.
PRs grandes generados por IA y cuello de botella en la revisión
- Muchos mantenedores reportan fatiga por PRs de 1.000–4.000 líneas “hechos de una sola pasada” por agentes; la revisión humana se convierte en el cuello de botella.
- Algunos dicen que si un PR es demasiado grande para que lo revisen humanos, los equipos pueden verse tentados a eliminar las aprobaciones y depender solo de CI, algo que otros consideran peligroso.
- Existe la preocupación de que, si nadie puede revisar por completo el código, nadie entienda ya de verdad el sistema, debilitando el “moat” de una empresa.
Límites, herramientas y estrategias de flujo de trabajo
- Mitigaciones propuestas: comprobaciones de CI o hooks de git que rechacen PRs por encima de N líneas con un mensaje cortés; otros sostienen que esto solo fragmenta trabajo incomprensible.
- Los PRs apilados de GitHub, las herramientas de revisión de PRs “capituladas” y las extensiones del navegador se citan como formas de hacer más digeribles los cambios grandes.
- Algunos describen “habilidades” o flujos de trabajo personalizados que imponen commits atómicos o dividen ramas; otros encuentran que a los LLM les cuesta terriblemente mantener una buena higiene de git sin un fuerte prompting.
Filosofía de PRs pequeños vs grandes
- Un bando insiste en PRs pequeños y narrativos: introducir bases, luego pegamento, luego la funcionalidad; se rechazan los volcados grandes o varios PRs grandes a la vez.
- Otro bando argumenta que algunas funcionalidades “no pueden estar medio embarazadas”; dividirlas es trabajo extra e inútil, especialmente cuando todo debe salir junto.
- Contraargumento: la mayoría de las funcionalidades grandes pueden escalonarse usando feature flags o refactorizaciones preparatorias; “si hay voluntad, hay manera”.
Papel de las pruebas y la calidad del código
- Varios comentaristas enfatizan que las pruebas escritas por LLM pueden ser vacías o codificar un comportamiento incorrecto como si fuera la especificación; a menudo las pruebas deberían ser escritas o, como mínimo, revisadas cuidadosamente por humanos.
- El historial de commits limpio y los cambios pequeños y centrados se presentan como parte central de una buena revisión, no como un pulido opcional.
Humanos vs IA en la revisión y la responsabilidad
- Algunos defienden las revisiones con IA como la única vía escalable; los críticos preguntan quién audita a la IA y advierten que “slop engendra slop”.
- Una visión opuesta: reducir o eliminar revisores humanos y aumentar la responsabilidad personal del “prompter”.
- Otros mantienen que la revisión humana genuina es crítica, especialmente en contextos regulados o de seguridad crítica.
Dinámicas organizativas y de OSS
- En OSS, los mantenedores pueden simplemente cerrar PRs enormes/de IA y a menudo consideran bloquear por completo las contribuciones anónimas de IA.
- En las empresas, el cumplimiento normativo, los plazos, las actitudes del liderazgo y las dinámicas de poder entre revisor y autor hacen que “simplemente decir que no” sea mucho más difícil.