Revisar salida a gran escala

Aquí está el problema honesto: cuando los agentes están escribiendo cientos de líneas a través de varias tareas, no puedes leer cada línea de la forma en que revisarías un diff de diez líneas. Fingir que puedes lleva o bien al sellado automático (apruebas sin mirar) o a la parálisis (nunca confías en nada). Ninguno de los dos logra enviar algo.

El camino a seguir es filtrar en unas pocas capas en lugar de leerlo todo:

• Las pruebas son el piso mínimo. Ninguna salida de agente se fusiona sin que las pruebas relevantes estén en verde y el verificador de tipos esté limpio. Esto no es negociable y es automático — la máquina hace esta parte.
• Revisa puntualmente las partes riesgosas. No puedes leerlo todo, así que lee las partes donde el radio de impacto es alto: cualquier cosa que toque autenticación, dinero, borrado de datos o llamadas externas. Hojea el resto buscando las señales de alerta del capítulo de construcción de funcionalidades — archivos que no debería haber tocado, cosas borradas silenciosamente, una petición diminuta que produjo un diff enorme.
• Lee el diff, no el código base. git diff --stat te dice qué cambió y cuánto en segundos. Una tarea delimitada a un solo módulo que muestra cambios en seis es una señal para mirar más de cerca, antes de leer una sola línea.
• Ejecútalo. Una suite de pruebas en verde no es una aplicación funcionando. Haz clic en la cosa. La verificación final es siempre la misma de todos los demás capítulos: ¿realmente hace lo que pediste, delante de ti?

Delimitar bien la tarea rinde frutos dos veces aquí. Una tarea que delimitaste con precisión produce un diff que realmente puedes revisar; una tarea que dejaste suelta produce uno que no puedes. El problema de la revisión se resuelve en su mayor parte río arriba, en el encargo.