¿Qué listón de calidad esperas de tu equipo y cómo lo haces cumplir?

Fija el listón por riesgo y no por una regla uniforme. Define qué tiene que ser cierto antes de que el código salga (pruebas que capturen los modos de fallo realistas, revisión por alguien capaz de cuestionarlo de verdad, instrumentación en la ruta nueva, una vuelta atrás documentada) y automatiza todo eso que puedas en el pipeline. Haz que se cumpla mediante valores por defecto y automatización en vez de dando la lata en las revisiones de código.

Lo fijo por radio de impacto. Un cambio en la ruta de pagos y un cambio en una página de marketing no merecen la misma ceremonia, y aplicar un solo estándar a ambos significa que o frenas todo o te quemas donde importa. Para cualquier cosa que importe, mi lista es: pruebas que capturarían de verdad el fallo realista y no teatro de porcentaje de cobertura, un revisor que entienda el dominio lo bastante como para discrepar, instrumentación en la ruta nueva para poder observarla en producción y una vuelta atrás documentada. Luego empujo todo lo que puedo de eso al pipeline, porque los estándares que dependen de que un humano se acuerde durante la revisión se degradan en cosa de un mes. Lint, puertas de tests, comprobaciones de migraciones, una nota de rollback obligatoria en la plantilla. Cuando alguien senior se lo salta, lo trato como una conversación sobre el estándar y no sobre esa persona, porque normalmente tiene un motivo real y el estándar está mal. Si pasa dos veces sin motivo, eso es una conversación de rendimiento, no de proceso.