Dividir la revisión de código en capas: un revisor por cada forma de leer el código
One reviewer per layer: splitting code review by the way code is read
El equipo de Claude Code pasó de 2.500 a más de 30.000 cambios fusionados al día en su monorepo, y la proporción de reversiones cayó más del 40%. En lugar de dejar de revisar, repartieron la revisión en seis capas: intención, forma, significado local, cableado, tiempo de ejecución y uso. Cada capa tiene su propio revisor con contexto fresco, y la información sube en forma de contratos, no de código crudo. Es información oculta aplicada a quien revisa.
Cada lector se define tanto por lo que no se le muestra como por lo que es.
- jwpapi
Mi problema ahora mismo es que todo tipo de proceso de revisión añade complejidad innecesaria que luego ralentiza tu agilidad, aumenta tu coste y degrada el rendimiento.
Si tienes una feature y 6 revisores diferentes la examinan, la lógica se infla fácilmente. Me pregunto cómo lo manejan otros. Estoy totalmente a favor y quiero que esto funcione, pero esta es mi limitación actual.
A menudo recibo malas sugerencias de los monitores de revisión porque se equivocan en algo. A veces recibo buenas, muy buenas, pero algunas son malas. Así que siempre estoy dispuesto a mirar revisiones sobre bugs, pero me daría miedo que después de 6 revisores sea solo un montón de texto que me confunde, y el resultado final sea peor que si yo mismo revisara lo realmente crítico. Mi contexto también es limitado y un proceso completamente sin intervención no es lo suficientemente fiable...
¿Cómo lo hacéis vosotros?
- visarga
Creo que es un buen enfoque para este año, pero pasa por alto algo importante: ¿cómo sabes que el código sigue reflejando tu intención después de haber estado dirigiendo durante semanas y meses, a lo largo de muchas sesiones? Los mensajes fluyen en la sesión y se pierden de vista, y entre compactaciones y nuevas sesiones se olvidan. Para solucionar esto, registro cada mensaje del usuario en un chat log y lo reviso de vez en cuando para destilar la forma más reciente de la intención del usuario.
Otro tipo de revisión que no se menciona aquí ni en el artículo de Anthropic es la revisión del plan. Genero el plan para un tramo de trabajo y luego hago que uno o más agentes revisen el plan (guardado como archivo). Esto verifica el plan contra las restricciones del proyecto antes de ejecutarlo.
Si podemos resolver las pruebas, la codificación está casi totalmente automatizada. El único problema que siempre quedaba era la confianza: ¿por qué deberíamos confiar en ese código? Si lo lees manualmente, es como caminar una motocicleta. Si no lo haces, necesitas alguna forma de reducir el riesgo. Hay muchas ideas circulando sobre cómo hacer esto; el OP y Anthropic mostraron sus propuestas. Sin embargo, creo que el enfoque es específico de cada proyecto, no hay un método general.
- zomtorg
Me pregunto si veremos más equipos de ingeniería pasándose de git a Sapling. Necesitamos un refresco en cómo revisamos y enviamos código.
Sé que GH lanzó recientemente PRs apilados, pero todavía parece que queda un largo camino por recorrer tanto en usabilidad como en fiabilidad en comparación con lo que Meta y probablemente Anthropic tienen internamente.