Coste del cambio de contexto: qué revelan 5 M de PRs
Analizamos datos de más de 5 millones de PRs para medir el coste real del cambio de contexto para desarrolladores – y no está donde crees.
By Ellis Keane · 2026-03-29
El coste del cambio de contexto que la mayoría de artículos citan – 23 minutos para reenfocarse después de una interrupción, de la investigación de Gloria Mark en UC Irvine – es un hallazgo real de un estudio real. Pero midió a trabajadores del conocimiento en general en 2008, no a ingenieros de software. Y la industria casera de posts de blog que multiplica 23 minutos por un número estimado de interrupciones para producir alarmantes cifras anuales en dólares (siempre acompañadas de una foto de banco de alguien agarrándose la cabeza) está haciendo algo que la investigación original nunca pretendió.
Tengo un interés personal en esta pregunta. En una empresa anterior, pasé – y esto no es hipérbole – entre el 80 y el 100 por ciento de algunos días siendo un enrutador humano. No escribiendo código, no revisándolo. Enrutando información entre personas y herramientas, porque ningún sistema único las conectaba. Esa experiencia es parte de por qué construimos Sugarbug, pero también es por qué soy escéptico de las calculadoras estándar de coste de cambio de contexto. Miden la interrupción. No miden los días que pasas sin llegar nunca a aquello en lo que se supone que debías estar trabajando.
Así que queríamos saber qué cuesta realmente el cambio de contexto en el trabajo de ingeniería – no en términos abstractos de productividad del desarrollador, sino medido en el artefacto que los equipos producen a diario: los pull requests. Sintetizamos hallazgos de tres estudios a gran escala que cubren más de 5 millones de PRs en miles de proyectos de código abierto, y analizamos qué impulsa realmente el tiempo de revisión de los pull requests.
El hallazgo principal: el cambio de contexto más costoso no es la notificación de Slack que interrumpe tu flujo. Es el pull request que lleva un día en una cola de revisión, obligando al autor a reconstruir todo un modelo mental cuando finalmente llegan las preguntas.
Los conjuntos de datos de los que nos nutrimos
No construimos un scraper personalizado y analizamos 10.000 PRs de forma aislada. Sintetizamos hallazgos de dos estudios revisados por pares y un gran conjunto de datos de la industria, y luego contrastamos sus conclusiones entre sí.
stat: "3,35 M" headline: "Pull requests analizados por Zhang et al." source: "Pull Request Latency Explained: An Empirical Overview (Empirical Software Engineering, 2022)"
Los tres conjuntos de datos principales:
- Zhang et al. (2022), revisado por pares: 3.347.937 PRs cerrados en 11.230 proyectos. Usó regresión lineal de efectos mixtos para identificar qué genera retrasos en la revisión de PRs. Publicado en Empirical Software Engineering.
- Adadot (2023), conjunto de datos de la industria: Más de 300.000 PRs fusionados de ~30.000 desarrolladores. No revisado por pares, pero la muestra es grande y la metodología (correlación tau de Kendall) es transparente. Enfocado en el tamaño del PR frente al tiempo de entrega.
- Estudio de revisión múltiple (2019), revisado por pares: 1.836.280 PRs en 760 proyectos de GitHub. Publicado en Information and Software Technology. Examina el comportamiento de revisión concurrente – un proxy directo del cambio de contexto en la revisión de código.
Los cruzamos con el 2024 DORA State of DevOps Report y el Atlassian Developer Experience Report 2024 (encuesta a más de 2.100 desarrolladores sobre cambio de contexto, productividad del desarrollador y el lado humano de la ecuación).
La cola es el verdadero asesino
Zhang et al. encontraron que el tiempo que tarda un PR en recibir su primera respuesta – primer comentario, primera revisión, cualquier cosa primera – explica el 58,7 % de la varianza en la vida total del PR. Es el predictor observado más fuerte del conjunto de datos – ¡por delante del tamaño del PR, la complejidad del código o el número de archivos modificados! Sin punto de comparación.
El mayor coste del cambio de contexto en la revisión de código no es el cambio en sí – es la cola que se forma mientras todos están ocupados cambiando entre otras cosas.
Piensa en lo que eso significa en la práctica. Un ingeniero abre un PR a las 10:00. El revisor designado está inmerso en su propia rama de funcionalidades, o en una reunión, o triando mensajes de Slack (y honestamente, probablemente las tres cosas seguidas). El PR espera. Para cuando alguien lo toma a las 15:00, el autor ya ha pasado a otra cosa completamente diferente. Ahora el revisor tiene preguntas, lo que significa que el autor tiene que hacer un cambio de contexto de vuelta al código que escribió hace cinco horas, reconstruir el modelo mental y responder. Esa respuesta llega a las 16:30, pero el revisor se ha ido a casa.
El PR envejece otro día.
Los datos sugieren que esto es más un problema de colas que un problema de disciplina – y el coste del cambio de contexto de esa cola se multiplica de formas que las calculadoras de interrupciones pasan completamente por alto.
Los PRs pequeños no te salvarán
Ya has escuchado esto antes: los PRs más pequeños se revisan más rápido, así que mantén tus PRs pequeños. Eso no es exactamente incorrecto, pero el tamaño del efecto es (genuinamente) más pequeño de lo que esperarías.
El análisis de Adadot de más de 300.000 PRs encontró una correlación tau de Kendall de solo 0,06 entre el tamaño del PR y el tiempo de entrega – una asociación débil, aunque el estudio no reportó intervalos de confianza para la cifra agregada. Los PRs de menos de 100 líneas tienen aproximadamente un 80 % de probabilidad de completarse en una semana, lo que suena genial hasta que te das cuenta de que esa es la misma tasa de finalización que un PR que ha estado seis días en la cola de revisión de alguien.
stat: "0,06" headline: "Correlación entre el tamaño del PR y el tiempo de entrega" source: "Análisis de Adadot de más de 300.000 PRs de ~30.000 desarrolladores (2023)"
El hallazgo más interesante: esta correlación varió enormemente entre organizaciones, oscilando entre 0,1 y casi 0,7 dependiendo de la empresa. Lo que sugiere que el tamaño del PR no es inherentemente el cuello de botella – sino la cultura de revisión y el proceso en torno al PR. Un equipo con un cadencia de revisión sólida puede manejar PRs más grandes de forma eficiente. Un equipo donde las revisiones son una ocurrencia tardía luchará con PRs de cualquier tamaño.
El umbral de 400 líneas del estudio de revisión de código de SmartBear/Cisco se mantiene como una heurística útil – los datos de Adadot también encontraron que la participación en la revisión cae más allá de ese rango. Pero optimizar el tamaño de los PRs sin corregir la cadencia de revisión subyacente es (y lo digo con genuino cariño por cada engineering manager que lo ha intentado) reorganizar las tumbonas en el Titanic.
Todo el mundo revisa todo a la vez
El estudio de revisión múltiple encontró que el 62 % de los pull requests involucran a desarrolladores que simultáneamente están revisando múltiples PRs. Más importante aún, encontraron una correlación estadísticamente significativa: más revisiones concurrentes por revisor se asociaba con mayor latencia en la resolución del PR.
El 62 % de los pull requests involucran a desarrolladores que simultáneamente revisan múltiples PRs – y la revisión múltiple correlaciona directamente con tiempos de resolución más largos. attribution: Estudio de revisión múltiple de pull requests, 1,8 M de PRs en 760 proyectos
El mecanismo es intuitivo (aunque el estudio, al ser observacional, no prueba la dirección de la causalidad). Un revisor toma el PR n.º 1, lee el diff, empieza a formarse un modelo mental de lo que el código intenta hacer. Luego llega una notificación – el PR n.º 2 necesita revisión porque está bloqueando un despliegue. El revisor cambia. Cuando vuelve al PR n.º 1, tiene que releer la mitad del diff porque el modelo mental se ha degradado.
Escala eso a un equipo de ocho ingenieros, cada uno con dos o tres PRs abiertos, cada uno revisando para dos o tres colegas, y la sobrecarga de coordinación empieza a explicarse sola. Por separado, el 2024 DORA Report encontró que el clúster de "alto rendimiento" se redujo del 31 % al 22 % mientras el clúster de bajo rendimiento creció del 17 % al 25 %. DORA no aísla la concurrencia de revisión de PRs como factor, pero el aumento de la sobrecarga de coordinación es un posible contribuidor a ese cambio.
Lo que las estimaciones del coste de cambio de contexto no captan
Permíteme ser directo sobre la cifra de "50.000 $ por desarrollador al año" que circula ampliamente en los artículos sobre coste de cambio de contexto. La metodología detrás de la mayoría de estas estimaciones es: toma los 23 minutos de tiempo de reenfoque, multiplica por el número estimado de interrupciones diarias (normalmente entre 6 y 15, dependiendo de cuán dramático esté siendo el autor), multiplica por una tarifa horaria del desarrollador y anualizas.
El problema no es que las matemáticas estén mal. El problema es que trata todos los cambios de contexto como equivalentes. Cambiar de programación profunda a un mensaje de Slack preguntando dónde es el almuerzo del equipo – eso es un cambio de contexto. Cambiar de revisar un PR a revisar un PR diferente en una base de código completamente distinta – eso también es un cambio de contexto. Pero el coste cognitivo no es ni remotamente comparable, y aplanarlos en una única tarifa horaria oscurece dónde ocurre el daño real.
Para ponerlo de forma concreta: en mi último trabajo, un día típico significaba cambiar entre Notion, Linear, Mattermost, Proton Mail, Proton Calendar, Discord, Twitter, Farcaster y un sinfín de canales de Telegram y Signal – y estoy seguro de que me olvido de media docena. Ahora uso un puñado (Signal, Obsidian, Figma, GitHub, correo electrónico, calendarios). El coste por cambio no cambió. Lo que cambió fue cuántos contextos estaban en cola esperando atención – y cuáles de ellos realmente importaban.
Los datos de PRs sugieren que los cambios costosos son los que crean colas, no los que interrumpen el flujo. Un desarrollador al que se le notifica de inmediato (en minutos) que revise un PR y hace una revisión rápida de 50 líneas – eso es una interrupción corta con alto retorno. Un desarrollador que pone esa solicitud de revisión en cola junto a otras cuatro y la atiende mañana – eso es una interrupción más larga para el revisor pero crea un coste mucho mayor para el autor y el equipo.
Lo que miden las calculadoras de coste
- Interrupciones individuales – con qué frecuencia se rompe el flujo de alguien
- Tiempo de reenfoque – cuánto tiempo para volver a la tarea anterior
- Multiplicación por tarifa horaria – grandes números anuales aterradores
Lo que realmente muestran los datos de PRs
- Formación de colas – PRs esperando la primera respuesta
- Concurrencia de revisiones – revisores haciendo malabarismos con múltiples PRs
- Retrasos en cascada – cambios de contexto del autor que amplifican los retrasos del revisor
Lo que esto significa para tu equipo
Si estás intentando reducir el coste del cambio de contexto para los desarrolladores de tu equipo, la respuesta práctica es aburrida – lo que probablemente explica que no se escriba mucho sobre ella. No es una herramienta. No es un marco de proceso con un programa de certificación. Es la cadencia de revisión. (Lo sé, lo sé. Nadie ha sido promocionado nunca por mejorar la cadencia de revisión.)
Los benchmarks de ingeniería 2025 de LinearB, extraídos de 6,1 millones de PRs en 3.000 organizaciones, encontraron que los equipos que lograban tiempos de ciclo élite (menos de 2,5 días) compartían un rasgo: revisaban los PRs rápidamente. No porque tuvieran menos PRs, ni porque sus PRs fueran más pequeños (aunque a menudo lo eran), sino porque responder a las solicitudes de revisión en horas era una norma del equipo, no una ocurrencia tardía.
Por lo que vale, Ben y yo – un equipo de dos personas – promediamos minutos en la primera respuesta a los PRs, no horas. Eso no es alardear de disciplina (no la tenemos). Es un acuerdo de equipo: las solicitudes de revisión son la única notificación que no se pone en cola. Las acciones de CI y las pruebas automatizadas manejan las comprobaciones mecánicas, lo que significa que la revisión humana – la parte que requiere contexto real – es más corta y ocurre inmediatamente. El acuerdo vino primero. Las herramientas simplemente lo hicieron sostenible.
En la práctica, eso significa:
- Mide el tiempo hasta la primera respuesta, no solo el tiempo de ciclo. Si estás siguiendo métricas DORA, añade esta. Es el predictor individual más fuerte del rendimiento de PRs (explica el 58,7 % de la varianza de vida útil, según Zhang et al.).
- Limita la concurrencia de revisiones. Si un revisor tiene tres solicitudes de revisión pendientes, una cuarta no va a recibir una buena revisión de todos modos. Los datos de revisión múltiple mostraron una clara asociación entre la concurrencia y la latencia. Empieza con un límite WIP de dos revisiones concurrentes y monitoriza el impacto.
- Deja de optimizar el tamaño de los PRs de forma aislada. Los PRs pequeños son buenos, pero no son un sustituto de un equipo que realmente revisa las cosas. Un equipo que produce veinte PRs de 50 líneas al día con un backlog de revisión de 48 horas está peor que un equipo que produce cinco PRs de 200 líneas con revisiones el mismo día.
- Reconoce que la revisión es trabajo real. La encuesta de Atlassian de 2024 encontró que el 69 % de los desarrolladores pierde más de 8 horas semanales por ineficiencias. La revisión no tiene por qué ser una de esas ineficiencias – pero solo si se trata como una actividad de ingeniería de primer nivel, no como una interrupción del trabajo "real".
Y aquí está la parte que nadie en el espacio de herramientas de productividad (nosotros mismos incluidos, para ser justos) quiere decir en voz alta: la intervención más impactante para el coste del cambio de contexto en equipos de ingeniería no es una herramienta. Es un acuerdo de equipo sobre cuándo se revisan los PRs. Si la norma implícita de tu equipo es "me ocuparé de las revisiones cuando tenga un hueco", ninguna cantidad de herramientas evitará la cascada de colas que revelan los datos de PRs.
Las herramientas ayudan – poder ver el contexto completo de un PR sin abrir cuatro pestañas del navegador reduce la carga cognitiva por cambio, y destacar qué revisiones están bloqueando el trabajo de otras personas ayuda a priorizar. Pero la palanca central es el acuerdo, y los acuerdos son gratuitos. No se necesita ninguna calculadora de 23 minutos.
El cambio de contexto más costoso no es la notificación que interrumpe tu flujo. Es la solicitud de revisión que lleva un día en una cola, obligando al autor a reconstruir el contexto mental cuando finalmente llegan las preguntas.
Recibe inteligencia de señales directamente en tu bandeja de entrada.
Preguntas frecuentes
Q: ¿Cuánto cuesta el cambio de contexto por desarrollador al año? A: Las estimaciones varían, pero la investigación subyacente es más escasa de lo que la mayoría de artículos sugieren. El estudio de Gloria Mark en UC Irvine encontró 23 minutos de tiempo de reenfoque por interrupción, y la encuesta de Atlassian de 2024 a más de 2.100 desarrolladores reveló que el 69 % pierde más de 8 horas semanales por ineficiencias. La cifra en dinero depende en gran medida de las suposiciones salariales, la frecuencia de interrupciones y cómo se define "cambio" – por eso nos centramos en los datos de PRs.
Q: ¿Ayuda Sugarbug a reducir el cambio de contexto en equipos de ingeniería? A: Sí. Sugarbug conecta herramientas como Linear, GitHub, Slack y Figma en un único grafo de conocimiento, para que los ingenieros puedan ver el contexto completo de una tarea – el PR relevante, la discusión de Slack, el comentario de Figma – sin abrir cuatro pestañas. El objetivo es menos cambios, no menos herramientas.
Q: ¿Cuál es el tamaño ideal de un pull request para minimizar los retrasos en revisión? A: La investigación del análisis de Adadot sobre más de 300.000 PRs encontró que los PRs de menos de 100 líneas de código tienen aproximadamente un 80 % de probabilidad de completarse en una semana. Por encima de 400 líneas, tanto la calidad de la revisión como la velocidad de finalización disminuyen. Los PRs más pequeños también reducen la carga de cambio de contexto del revisor.
Q: ¿Sugarbug se integra con los pull requests de GitHub? A: Sí. Sugarbug extrae la actividad de GitHub – PRs, comentarios, revisiones y cambios de estado – y los vincula con señales relacionadas en tus otras herramientas. Si un issue de Linear originó el PR y un hilo de Slack debatió el enfoque, Sugarbug conecta los tres automáticamente.
Q: ¿De dónde proviene el dato de "23 minutos para reenfocarse"? A: Proviene de la investigación de Gloria Mark en UC Irvine, publicada en "The Cost of Interrupted Work: More Speed and Stress" (CHI 2008). El estudio encontró que los trabajadores tardaban una media de 23 minutos y 15 segundos en volver a su tarea original tras una interrupción. Vale la pena señalar que el estudio observó a trabajadores del conocimiento en general, no específicamente a ingenieros de software.