Los Pull Requests nunca fueron pensados para tu equipo

11 min de lectura

La barrera que se convirtió en jaula

Breve historia de la desconfianza hacia los desconocidos

Antes de que existiera GitHub, los proyectos de código abierto aceptaban contribuciones a través de listas de correo. Escribías un parche, lo formateabas según las convenciones del proyecto, lo mandabas a la lista y esperabas. Mantenedores que nunca habías conocido leían tu código, discutían sobre él en público y eventualmente lo aceptaban o rechazaban. El kernel de Linux sigue funcionando así. Linus Torvalds revisa parches de miles de desarrolladores con los que nunca ha compartido oficina. El proceso existe porque la confianza no existe.

GitHub lanzó los pull requests en 2008 para formalizar este flujo de trabajo. El pull request es una propuesta: “Escribí algo. Por favor, revísenlo antes de fusionarlo en su proyecto.” La palabra clave es su. El contribuidor no es dueño del código. El mantenedor sí. El pull request es una frontera entre adentro y afuera.

Esto tiene todo el sentido para el código abierto. Cuando un desconocido envía código a un proyecto que no mantiene, alguien que entiende la arquitectura debería revisarlo. El PR es una barrera, y las barreras son útiles cuando no sabes quién toca la puerta.

Entonces las empresas miraron GitHub y pensaron: “Nuestros desarrolladores deberían hacer esto también.”

Y ahí fue donde todo se torció.

Tu equipo no es una colección de desconocidos

Un equipo cohesionado comparte contexto. Conocen el código. Conocen el dominio. Se sentaron en las mismas reuniones, discutieron las mismas decisiones de arquitectura y arreglaron el mismo incidente de producción a las 02:00 un sábado.

Los pull requests tratan cada contribución como si viniera de afuera. Cada cambio necesita permiso antes de llegar a la rama principal. Cada desarrollador tiene que esperar a que alguien más presione el botón verde antes de que su trabajo cuente.

En un equipo de cinco desarrolladores que hacen pair programming regularmente y hablan del código a diario, esto es burocracia disfrazada de calidad. Contrataste a estas personas. Las capacitaste. Les diste acceso a producción. Pero, ¿no confías en que puedan hacer push a la rama principal sin un permiso firmado?

El contraargumento siempre es el mismo: “¿Y si alguien comete un error?” Buena pregunta. Pero el PR no está detectando el error. Un estudio de Microsoft Research encontró que la principal motivación para las revisiones de código en Microsoft era la difusión de conocimiento, no la detección de defectos. La gran mayoría de los comentarios de revisión se refieren al estilo de código y convenciones, no a errores. Los errores que importan, los errores sutiles de lógica, las condiciones de carrera, las reglas de negocio mal entendidas, pasan sin ser detectados porque los revisores dedican un promedio de unos pocos minutos a mirar un diff que no escribieron y que no comprenden del todo.

La línea de ensamblaje de sellos de goma

Así se ven las revisiones de pull requests en la mayoría de los equipos. Se abre el PR. En algún momento entre tres y seis minutos después, alguien hace clic en aprobar. El comentario dice “LGTM” o contiene un emoji de pulgar arriba. Sin preguntas. Sin enfoques alternativos sugeridos. Sin evidencia de que el revisor leyó algo más allá del título del PR.

He visto dos caminos en la práctica. El rápido: aprobación en menos de cinco minutos para diffs de cientos de líneas. Nadie lee doscientas líneas de código en cinco minutos. El revisor echa un vistazo al título, quizás recorre la lista de archivos, y aprueba. Sin hacer checkout, sin probar localmente, sin entender nada. Es un emoji de fuego y una marca verde. El camino lento: alguien realmente descarga la rama, la ejecuta localmente, intenta entender qué cambió y por qué. Eso toma un día. Un día completo de trabajo perdido revisando el lote de cambios de otra persona. Ninguno de los dos funciona. El rápido no detecta nada. El lento destruye la capacidad de entrega. Ambos fingen ser control de calidad.

Lo peligroso no es la falta de atención. Lo peligroso es la confianza que genera. El equipo cree que tiene un proceso de revisión. El historial de PRs muestra aprobaciones, comentarios, marcas verdes. Los gerentes lo señalan en auditorías. “Tenemos revisión de código obligatoria.” Esa frase crea la ilusión de que alguien está detectando problemas. Nadie está detectando problemas. El proceso no detecta nada. Pero parece que sí, y eso es peor que no tener proceso, porque al menos sin proceso sabes que estás expuesto.

Cuando ocurre un incidente de producción, el post-mortem mira el commit, encuentra el PR, ve la aprobación y concluye: “El proceso de revisión funcionó. Fue un caso extremo que nadie podía haber detectado.” Nadie hace la pregunta obvia: ¿el revisor realmente leyó el código? La respuesta casi siempre es no. Pero la marca verde dice que sí, y la marca verde es lo que queda en el informe.

Ahora la IA escribe el código que nadie leía de todos modos

Usamos generación de código con IA todos los días. Es genuinamente potente. Escribes una prueba que falla, dejas que la IA proponga una implementación, evalúas el resultado, ajustas, haces commit. TDD con un compañero de pairing IA sobre desarrollo basado en tronco crea ciclos de retroalimentación cortos que producen código sólido rápido. La IA sugiere, tú cuestionas, refinan juntos. La disciplina no cambió. Los principios tienen décadas. La herramienta es nueva.

El problema no es la IA. El problema es lo que pasa cuando el código generado por IA se encuentra con los flujos de pull request.

Ahora que todos proclaman que “programar es un problema resuelto,” el volumen de código que pasa por pull requests se dispara. Desarrolladores que antes escribían cincuenta líneas al día ahora generan trescientas. Los diffs son más largos. El código se ve plausible. Pasa el linting. Puede que hasta tenga pruebas, también generadas, también sin leer.

Nadie leía el código antes. Ahora hay tres veces más.

El código generado por IA se ve seguro de sí mismo. Sintácticamente limpio. Nombres de variables razonables. Comentarios incluidos. Tiene la forma de código escrito por alguien que sabe lo que hace. Cuando trabajas con él en diálogo, primero la prueba, detectas los huecos de inmediato: los casos límite que omitió, la regla de negocio enterrada en una conversación de Slack de hace ocho meses, la razón por la que existe esa verificación de nulo. El ciclo corto de rojo-verde-refactorizar no deja sobrevivir las alucinaciones.

Pero ¿meter ese mismo código en un pull request? El revisor que aprueba en cuatro minutos no detecta nada de eso. Antes de la IA, al menos el desarrollador que escribió el código lo entendía. Podías acercarte y preguntar. El flujo de PR ahora tiene código que fue generado sin contexto completo, enviado sin conversación y aprobado sin comprensión. La marca verde cubre las tres brechas por igual.

La IA como compañero de pairing funciona. La IA como cañón de código disparando hacia una cola de PRs, no. La diferencia no está en la IA. Está en si alguien mantiene un diálogo con el código antes de que se despliegue.

Los pull requests matan la integración continua

La integración continua significa que cada desarrollador integra su trabajo en la base de código principal varias veces al día. No una vez al día. No al final de una funcionalidad. Varias veces al día. Cambios pequeños, integrados frecuentemente, probados inmediatamente.

Los pull requests trabajan en contra de cada elemento de esa definición.

Un pull request crea una rama. La rama diverge de la principal. Cuanto más tiempo vive la rama, más se aleja. Cada hora que esa rama existe sin ser fusionada es una hora de riesgo de integración acumulándose. Otros desarrolladores están cambiando la misma base de código. Los conflictos de fusión crecen. Las suposiciones se deterioran.

Después el PR queda en una cola. Esperando a un revisor. El revisor está ocupado. Tiene sus propios PRs que enviar y su propio trabajo que hacer. El PR promedio en muchas organizaciones espera horas. A veces días. Algunos equipos miden sus colas de PRs en semanas.

Durante esa espera, el desarrollador que envió el PR comienza trabajo nuevo. Ahora tiene dos contextos mentales: el trabajo que está haciendo y el trabajo que está esperando. Cuando la revisión regresa con comentarios, tiene que cambiar de contexto. Ya avanzó a otra cosa. El código es el problema de ayer con la interrupción de hoy.

El desarrollo basado en tronco elimina todo esto. Todos trabajan sobre la rama principal. Los commits son pequeños. La integración ocurre continuamente. No hay rama secundaria. No hay cola. No hay barrera. El ciclo de retroalimentación es corto: escribir, probar, hacer commit, hacer push. Si algo se rompe, lo sabes inmediatamente porque la suite de pruebas se ejecuta en cada push.

“¿Pero qué pasa con las funcionalidades incompletas?” Feature flags. Despliegas código que está desactivado por defecto y lo activas cuando está listo. El código está integrado, probado y en producción. Solo que aún no es visible para los usuarios. Sin rama. Sin PR. Sin cola.

Para qué sirve realmente la revisión de código

El verdadero valor de mirar el código de alguien no es detectar errores. Las pruebas automatizadas, los linters y el análisis estático detectan errores con más fiabilidad que un humano escaneando un diff a las 16:45 de un viernes. El verdadero valor es la comprensión compartida. Dos personas mirando el mismo código desarrollan un modelo mental compartido de cómo funciona el sistema. Transfieren contexto. Construyen propiedad colectiva.

Los pull requests son terribles para esto. Leer un diff en una pestaña del navegador es la peor forma posible de entender el trabajo de alguien. Ves líneas cambiadas. No ves las decisiones que llevaron a esos cambios. No escuchas el razonamiento. No experimentas las concesiones. Apruebas en aislamiento lo que fue creado en aislamiento. No se transfiere comprensión. No se comparte contexto.

El pair programming hace lo que las revisiones de código prometen. Dos desarrolladores se sientan juntos y escriben el código juntos. La revisión ocurre en tiempo real. Las preguntas se hacen cuando importan, durante la creación, no después. Las decisiones de diseño se discuten mientras las alternativas son baratas. Uno escribe la prueba, el otro escribe la implementación. La comprensión fluye en ambas direcciones, continuamente.

El mob programming extiende esto aún más. Todo el equipo trabaja en el mismo código al mismo tiempo. La revisión está integrada en la creación. No hay un paso separado de revisión porque la revisión nunca se detuvo.

Estos enfoques se sienten más lentos. No lo son. El pair programming produce menos defectos, lo que significa menos retrabajo. La comprensión compartida reduce los silos de conocimiento, lo que significa menos situaciones de “solo Tomasz sabe cómo funciona esto”. Cuando el desarrollador que escribió una lógica de protección crítica se va de la empresa, cuatro personas entienden esa lógica porque la escribieron juntos. No porque alguien puso un pulgar arriba en un diff.

Cuándo los pull requests sí tienen sentido

Los PRs no son inútiles. Están mal aplicados.

Usa pull requests cuando un contribuidor externo envía código a un proyecto que no mantiene. Ese es el caso original, y sigue funcionando.

Úsalos cuando un nuevo miembro del equipo está aprendiendo la base de código y quiere retroalimentación explícita. Que sea temporal. Cuando gane confianza, que pase a desarrollo basado en tronco.

Úsalos en entornos regulados donde los registros de auditoría requieren aprobaciones documentadas. Pero sé honesto sobre lo que contiene ese registro. Contiene firmas, no comprensión. Si tu marco de cumplimiento requiere evidencia de revisión de código, considera si los registros de sesiones de pair programming satisfacen ese requisito mejor que PRs aprobados automáticamente.

No los uses como sustituto de la confianza. Si confías en tu equipo lo suficiente como para darle acceso a producción, confía lo suficiente como para que haga push a la rama principal.

La conversación que reemplaza la barrera

Deja de revisar código después de que fue escrito. Empieza a discutir el código mientras se está escribiendo. Pair programming. Mob programming. Habla sobre lo que construyes y por qué. Haz de la comprensión el estándar y del aislamiento la excepción. Y usa la IA para cuestionar el código mismo: pídele que encuentre casos límite que pasaste por alto, que desafíe tus suposiciones, que explique qué hace realmente una función versus lo que crees que hace. La IA es un revisor incansable que nunca aprueba automáticamente y nunca hace clic en aprobar por compromiso social. Apúntala a tu código y pregunta “¿qué podría salir mal aquí?” Obtendrás retroalimentación más útil en treinta segundos de lo que la mayoría de los PRs entregan en un día.

La integración continua requiere conversación continua. Un pull request es un monólogo demorado, asíncrono y aislado. Reemplázalo con lo real: desarrolladores trabajando juntos, construyendo comprensión compartida un commit a la vez.

Tu equipo nunca fue una colección de desconocidos. Deja de tratarlo como si lo fuera.