Perspectiva

Los pull requests en GitHub se multiplicaron por cinco en tres años

El code review se diseñó para otro volumen

El code review se diseñó para un mundo donde lo caro era escribir código.

El 8 de septiembre de 2026, Gergely Orosz publicó en The Pragmatic Engineer un dato de GitHub que lo pone en números: en tres años, los pull requests abiertos en la plataforma se multiplicaron por cinco.

El ritmo no fue parejo. Se aceleró desde fines de 2025 — en ese tramo solo, la cantidad de pull requests y commits casi se duplicó.

La razón que da Orosz para el salto: en muchas empresas de tecnología, los agentes ya generan la mayor parte del código.

Lo hacen más rápido y en más pull requests que los que abría un equipo humano. Para Orosz, el cuello de botella que durante décadas fue escribir el código se movió: ahora es revisarlo.

Otras salidas que prueba la industria

Orosz repasa varios enfoques antes de llegar a Duckbill. Hay equipos que dejaron de revisar la implementación y revisan en cambio el plan, los tests y el esquema de base de datos.

Hay quienes armaron herramientas para que un agente revise el código y el humano revise esa revisión — dice que es el enfoque más adoptado hoy.

Y hay quienes apuestan a producir menos: configurar a los agentes para que generen pull requests más chicos, más fáciles de leer.

El que más me quedó dando vueltas es el de Duckbill, porque no agrega una capa nueva de revisión: decide de entrada qué no hace falta revisar.

El caso Duckbill

Duckbill es una startup de quince personas dedicada a contratos de cómputo en la nube y de IA.

Su cofundador y CEO, Mike Julian, le contó a Orosz que, semanas antes de esa nota, el equipo de cinco personas que escribe código se encontró con 60 pull requests abiertos, acumulados durante semanas.

Dos días enteros de revisión, solo para ponerse al día con lo que ya estaba escrito. En vez de sumar gente o bajar el ritmo de los agentes, cambiaron el proceso.

Lo que cambiaron

Pasaron de revisar todo por igual a un esquema basado en riesgo.

La regla que definieron: un cambio necesita revisión humana obligatoria solo si toca la API pública, autenticación, el sistema de diseño, cambios no aditivos de esquema de base de datos, o las skills de los agentes.

Todo lo que no entra en esa lista lo etiqueta un script y lo aprueba el agente, sin que una persona lo mire.

Para que ese recorte no bajara la calidad, reforzaron lo que Orosz llama guardrails: activaron casi todas las reglas de linting disponibles (ruff, prettier, eslint, ty) y llevaron el piso de cobertura de tests unitarios al 85%.

El resultado que reporta Duckbill, comparando antes y después del cambio: pasaron de fusionar 80 pull requests por semana a 154 — un 94% más, casi el doble.

Los pull requests sin revisión humana se fusionan en una mediana de una hora. Los que sí la requieren, en 26 horas.

No cambió cuánto código se escribe. Cambió qué parte de ese código merece que una persona la mire.

Dónde estoy yo con esto

Yo reviso código que generan mis agentes en muchos proyectos, con skills y plugins como gstack, por ejemplo.

Es la misma lógica que describí cuando conté cómo reparto el trabajo de publicar con el modelo 10-80-10: el agente hace el grueso, pero hay tramos donde mi criterio decide qué pasa y qué no.

Acá el tramo que decide es otro. No es el tono de un texto — es qué cambio de código puede pasar solo y cuál necesita mis ojos.

El código dejó de ser lo caro de producir. Ahora lo caro es decidir qué de todo eso hace falta revisar.

Fuentes

Comentarios