- Explica la estructura en la que la velocidad de ejecución del trabajo se vuelve exponencialmente más lenta a medida que aumentan las etapas de aprobación y revisión dentro de una organización, y presenta casos donde en la práctica cada etapa de aprobación provoca aproximadamente un retraso de 10x
- Aunque las herramientas de codificación con IA aumenten drásticamente la velocidad de escritura de código, la latencia de la tubería de revisión posterior no se reduce, por lo que la mejora total de velocidad es mínima
- Aplicando la filosofía de calidad en manufactura de W. E. Deming al software, señala que agregar etapas de QA en realidad empeora tanto la calidad como la velocidad
- Hay que reducir las revisiones, pero al mismo tiempo sustituirlas por una cultura de calidad basada en modularidad y confianza, y la clave es hacer mejoras estructurales que vuelvan innecesaria la revisión misma
- Los equipos pequeños tienen ventaja en la era de la IA, y es necesario rediseñar organizaciones y sistemas de forma que combinen componentes pequeños y bellos
La ley de que las etapas de revisión crean un retraso de 10x
- Igual que con la ley de los efectos de red, cuando el tamaño del equipo crece aparece el overhead de coordinación, y duplicar el equipo no duplica la velocidad
- Una regla empírica aprendida hace décadas: cada etapa adicional de revisión hace que el proceso sea 10 veces más lento
- No hay una base teórica sólida, pero es un fenómeno observado repetidamente en la realidad
- El tiempo que se mide aquí no es esfuerzo (
effort) sino tiempo de reloj real (wall clock time), y la mayor parte del tiempo adicional es tiempo de espera
- Ejemplos concretos:
- Codificar una corrección simple de bug: 30 minutos
- Revisión de código por un colega sentado al lado: 300 minutos (unas 5 horas, medio día)
- Aprobación de documento de diseño por el equipo de arquitectura: 50 horas (aprox. 1 semana)
- Ponerlo en el calendario de otro equipo (por ejemplo, una solicitud de función de cliente): 500 horas (12 semanas, 1 trimestre fiscal)
- La siguiente etapa, 10 trimestres (unos 2.5 años), tampoco es irrealista, y en una empresa relativamente pequeña como Tailscale también ocurre este nivel de retraso cuando se cambia la dirección del producto
La IA no puede resolver este problema
- Aunque Claude haga en 3 minutos una tarea de codificación de 30 minutos, uno termina usando los 27 minutos ahorrados para iterar directamente con la IA y revisar una y otra vez, o entregando código no validado al revisor
- El revisor igual tarda 5 horas, y si le pasas código que ni tú mismo leíste, el revisor se molesta
- Se dice que el verdadero valor de la codificación agéntica es completar en pocas horas proyectos grandes que normalmente tomarían una semana, pero el resultado es tan grande que el revisor no puede inspeccionarlo de una sola vez
- Hay que dividirlo en unidades pequeñas y cada una genera un ciclo de revisión de 5 horas
- Como tampoco hay arquitectura intencional sin documento de diseño, al final se regresa a una reunión de revisión de diseño
- Como resultado, un proyecto terminado en 2 horas vuelve a convertirse en 1 semana
La única forma es reducir las revisiones
- La premisa de la teoría de la Singularity: un sistema crea sistemas cada vez más inteligentes, y si el tiempo por unidad de mejora converge a 0, aparece un crecimiento explosivo
- La razón para no creer en esa teoría: la mayor parte del tiempo necesario para completar algo no es trabajo real sino tiempo de reloj, es decir, espera y retraso
- La latencia no se puede vencer por fuerza bruta (
brute force)
¿Pero no es imposible dejar de revisar?
- Mucha gente reconoce el síntoma: la primera etapa del pipeline (código generado por IA) se volvió rápida, pero las etapas posteriores de revisión son el cuello de botella
- La solución intuitiva sería: dejemos de revisar → aunque el resultado sea tosco, si es 100 veces más barato, basta con que entregue 1% del valor para alcanzar el punto de equilibrio
- Detrás de esa lógica hay una suposición bastante tonta
- AI Developer's Descent Into Madness:
- Construyes un prototipo increíblemente rápido → se siente como tener superpoderes
- El prototipo tiene bugs → le dices a la IA que los arregle
- Cada vez que corriges algo, aparecen bugs nuevos en la misma medida
- Te engañas pensando que si un agente de IA revisa su propio código encontrará sus propios bugs
- Te descubres pasándoles datos directamente entre agentes
- Llegas a la conclusión de que necesitas un framework de agentes
- Usas agentes para escribir un framework de agentes
- Regresas al paso 1
- Como Claude Code apenas se volvió utilizable hace unos meses, este ciclo recién empezó hace poco, y muchos colegas y personas respetadas están atrapados en él
¿Por qué hacemos revisiones?
- A medida que la empresa crece, aumentan las etapas de colaboración, revisión y gestión → el objetivo es evitar errores, porque mientras más grande es la escala, más alto es el costo de los errores
- Llega un punto en que el valor agregado promedio de una nueva función cae por debajo de la pérdida promedio causada por los nuevos bugs que introduce
- Como no hay manera de aumentar el valor de la función, se termina yendo en dirección a reducir las pérdidas
- Si aumentas inspecciones y controles, la velocidad baja pero la calidad crece de forma monótona (
monotonically increasing) → parece la base de una mejora continua
- Pero "más inspección y más control" no es la única manera de mejorar la calidad, y además es una manera peligrosa
El "aseguramiento de calidad (QA)" en realidad baja la calidad
- Se hace referencia a la filosofía de calidad que W. E. Deming popularizó en la manufactura automotriz japonesa
- El problema de una etapa de QA en una fábrica: fabricar widgets → inspección/QA → retirar los que no pasan → para evitar omisiones, se agrega una segunda QA
- En un modelo matemático simple suena razonable (si cada etapa de QA detecta 90% de los defectos, con 2 etapas se reducen 100 veces)
- Pero en un entorno de humanos agénticos (
agentic humans) los incentivos se distorsionan:
- El equipo de QA secundario evalúa al equipo de QA primario → no tiene incentivos para buscar con empeño resultados que podrían causar el despido de sus colegas
- El equipo de QA primario reduce su esfuerzo esperando que el segundo equipo atrape lo que se le pase
- El equipo que fabrica widgets también descuida su propia revisión porque ya existe QA → un 10% de descarte parece mejor que ir 20% más lento
- Un rediseño de ingeniería de punta a punta para mejorar la calidad se evita porque cuesta demasiado
- El Toyota Production System elimina por completo las etapas de QA y le da a todos un botón de "detener la línea"
- Los fabricantes estadounidenses instalaron el mismo botón, pero nadie lo presionaba → por miedo a ser despedido
Confianza (Trust)
- La diferencia entre el éxito del sistema japonés y el fracaso del sistema estadounidense es la confianza
- Confianza entre personas: certeza de que el jefe realmente quiere conocer todos los defectos y que hay que detener la línea cuando se detectan
- Confianza entre gerentes: certeza de que la dirección realmente se toma la calidad en serio
- Confianza entre ejecutivos: certeza de que, si existen el sistema y los incentivos correctos, las personas harán trabajo de alta calidad y encontrarán sus propios defectos
- Condición adicional: confianza en que el sistema realmente funciona → primero hay que tener un sistema que funcione
Falibilidad (Fallibility)
- Los codificadores con IA escriben mal código con frecuencia y, en ese sentido, son iguales a los programadores humanos
- En el enfoque de Deming no hay una solución mágica → los ingenieros tienen que diseñar la calidad desde abajo hacia arriba en todo el sistema
- Cada vez que ocurre un problema, hay que preguntar "¿cómo pudo pasar esto?" y usar postmortems y Five Whys para encontrar la causa raíz y corregirla
- "El coder se equivocó" no es una causa raíz, sino un síntoma → hay que encontrar la causa estructural que permitió que el coder se equivocara
- El verdadero papel del revisor de código no es revisar código, sino hacer innecesarios sus propios comentarios de revisión
- Mejorar el sistema para que ese tipo de comentario no vuelva a aparecer en el futuro
- La meta debe ser llegar a un estado en el que ya no haga falta revisar
- Ejemplo: quienes crearon
go fmt → eliminaron para siempre los comentarios de revisión sobre espacios y formato → eso es la verdadera ingeniería
- Cuando una revisión detecta un error, el error ya ocurrió → la causa raíz ya quedó atrás
Modularidad (Modularity)
- El pipeline de revisión (las etapas de QA) no funciona, y al ralentizar todo oculta la causa raíz → resolverla se vuelve más difícil
- El atractivo de codificar con IA: la primera etapa del pipeline es abrumadoramente rápida → se siente como un superpoder
- Puede que ahora exista suficiente motivación para resolver problemas escondidos durante 20 años por la cultura de code review y reemplazarlos por una verdadera cultura de calidad
- Los optimistas tienen razón a medias: sí hace falta reducir etapas de revisión, pero si se reducen sin poner nada a cambio, el resultado es un Ford Pinto o los recientes aviones de Boeing
- Igual que lo que Deming llevó a la manufactura, hace falta un cambio de paquete completo (
table flip) → un sistema de "calidad total" no se puede adoptar a medias
- Hay que eliminar las revisiones y al mismo tiempo volverlas innecesarias
- Es posible adoptar por completo el nuevo sistema en unidades pequeñas:
- Se compara con un fabricante automotriz estadounidense de la vieja escuela que compra componentes de alta calidad a proveedores japoneses
- Si las piezas están bien hechas, se pueden eliminar etapas de QA en otras partes → la complejidad del trabajo de "ensamblar piezas" baja muchísimo
- Se pueden combinar cosas pequeñas y bellas para crear algo grande y bello
- Equipos pequeños que confían entre sí fabrican componentes individuales sabiendo qué significa calidad para ellos
- El equipo cliente explica con claridad qué significa calidad para ellos → la calidad se propaga desde abajo hacia arriba
Equipos pequeños y diseño organizacional en la era de la IA
- Es probable que las startups pequeñas tengan más ventaja en el nuevo mundo → como tienen menos gente, ya de por sí tienen menos etapas de revisión
- Algunas startups encontrarán cómo producir rápidamente componentes de alta calidad y las demás fracasarán → calidad por selección natural
- Las grandes empresas tienen sistemas lentos de revisión ya enquistados, así que eliminarlos puede provocar caos total
- Sin importar el tamaño de la empresa, los equipos de ingeniería pueden hacerse más pequeños y se pueden definir con más claridad las interfaces entre equipos
- Es posible un modelo en el que varios equipos dentro de una misma empresa desarrollen en competencia el mismo componente
- Cada equipo está formado por pocas personas y bots de código
- Se prueban 100 maneras y se elige la mejor → calidad por evolución
- El código es barato, pero las buenas ideas siguen siendo caras → ahora se pueden probar ideas nuevas más rápido que antes
- Puede aparecer un nuevo punto óptimo en el continuo monolito-microservicios
- Los microservicios ganaron mala fama por ser demasiado pequeños, pero en el término original un servicio "micro" era del tamaño adecuado para que un "equipo de dos pizzas" lo construyera y operara
- En la era de la IA, eso pasa a ser "una pizza y unos cuantos tokens"
- Con la nueva velocidad de codificación se puede experimentar más rápido con los propios límites de los módulos
- Las funcionalidades (
feature) siguen siendo difíciles, pero el refactoring y las pruebas de integración automatizadas son áreas donde la IA sí rinde bien
- Se puede intentar separar módulos que antes daba miedo separar → aumentan las líneas de código, pero sigue siendo barato comparado con el overhead de coordinación de un equipo grande manteniendo ambos lados
- En todos los equipos hay un monolito demasiado grande y demasiadas etapas de revisión
- Aunque no lleguemos a la singularidad, sí podemos diseñar un mundo mucho mejor → el problema se puede resolver
- La clave es la confianza
2 comentarios
Cuando vi
go fmtpor primera vez: pero ¿por qué no puedo darle formato a mi gusto..?Ahora: ¿para qué hace falta tener gustos sobre el formateo?
Comentarios de Hacker News
Incluso se podría no hacer revisión en absoluto
Si mueves la revisión hacia la izquierda y la conviertes en una sesión de diseño de código, planteas los problemas en el daily y resuelves las partes difíciles con programación en pareja, la mayoría de los objetivos de la revisión desaparecen
El 10% restante —nombres de variables, espacios, patrones— se puede automatizar con un linter
Al final, lo importante es crear una cultura de equipo basada en la confianza donde el equipo pueda confiar en el código acordado y escribirlo
Solo durante la implementación real te das cuenta de los problemas
Casi nunca vi que todo saliera exactamente según el plan. Al final hacen falta reuniones iterativas de arquitectura, pero eso también termina cayendo en el pantano de la reunión semanal
En el momento en que dejan de revisar incluso el código que ellos mismos escribieron, la confianza acumulada se derrumba en un instante
Como en el Toyota Production System, para eliminar la etapa de QA hace falta la confianza de que cualquier integrante pueda detener todo de inmediato al detectar un defecto
El pipeline de revisión solo oculta los problemas y ralentiza la velocidad
Esa sola frase suena como la definición del infierno
Eso funciona bastante bien. La gente escribe sus propias pruebas y también hace validación manual
También construimos una red de seguridad que permite revertir un despliegue erróneo en 10 minutos
La revisión de código es un dilema del voluntario
Porque en la evaluación pesa más “lancé muchas funciones” que “revisé muchos PR”
Al final, la gente solo revisa activamente cuando eso tiene impacto directo en su propio trabajo
Pero como el código es flexible, un merge rápido y correcciones posteriores pueden llevar a una convergencia más rápida
En especial, también pesa mucho la motivación de detectar bugs antes para reducir el estrés del on-call
Aunque no entiendan algo, dejar preguntas ayuda muchísimo para aprender
Si quieres convertirte en líder, tienes que revisar mucho código y también documentos de diseño
Este artículo puso en orden con claridad mi intuición y experiencia
Ya me gustaba el producto de Tailscale, pero ahora creo que también me volveré fan del CEO
Gracias a Avery por escribirlo; pienso compartir este texto ampliamente
Valve es una de las pocas empresas que entiende los límites del ancho de banda de comunicación
Cuanto más crece una organización, la carga de comunicación aumenta exponencialmente
Uno pensaría que otras empresas ya también lo habrían entendido, pero todavía no es así
Sorprende que las revisiones se procesen en 5 horas
La mayoría avanza en escalas de varios días
Pero si existe una cultura donde cualquier desarrollador puede detener todo de inmediato al detectar un bug, tal vez la revisión no haga falta
La realidad es una estructura donde si no se cumplen los objetivos de lanzamiento, la persona sale perjudicada
En mi empresa actual, las revisiones terminan en minutos, pero la deuda técnica se dispara
Cuando pasaba cierto tiempo, llegaba automáticamente un mensaje de “revisión pendiente”
Todo se medía y la presión por resultados era fuerte
Si el tamaño del equipo es razonable, este hábito se puede aprender y propagar
Ni al negocio ni a los desarrolladores les importa demasiado
La relación valor/esfuerzo de la revisión suele ignorarse
Si la revisión en realidad no mejora la calidad, ese tiempo se desperdicia
En vez de discutir detalles minuciosos, es más eficiente verificar solo “¿funciona?” y hacer merge rápido
Luego se puede mejorar en commits posteriores
La revisión debería ser un checkpoint breve que solo confirme la dirección
Estoy totalmente de acuerdo con la idea de que el trabajo del revisor es eliminar la revisión
El artículo asume un proceso serializado, pero en la práctica todo avanza en paralelo
Si se resuelven varios bugs al mismo tiempo, la demora de revisión no es un gran problema
La clave es ajustar la cantidad de trabajo simultáneo (N)
Enlace
Cuanto más lenta es la velocidad de revisión de PR, mayor es el costo de cambio de contexto
Según los cálculos, mejorar la velocidad de revisión aumenta mucho la productividad
Comparto la idea de que el objetivo del revisor es hacer innecesaria la revisión, pero
cuando el alcance de la confianza se extiende fuera de la empresa, la historia cambia
Por ejemplo, si se despliega código malicioso con
npm update, reaccionar después ya sería demasiado tardeIncluso en un sistema basado en la confianza, a veces existen puntos donde hace falta validación humana
Los managers enfatizan la productividad y, al mismo tiempo, mantienen procesos que reducen la velocidad
Es un problema complejo, así que no se puede decir simplemente que sea bueno o malo
Los operadores deben hacerse responsables tanto de la productividad como de la seguridad
Antes de un incidente se enfatiza la productividad; después de un incidente, la seguridad
La gente de afuera no suele entender bien el equilibrio de este doble rol
Enlace relacionado