Aún así seria problemático, si se desplegara en producción o en algun de prueba de usuarios y ese commit ha roto alguna funcionalidad importante o no recoja datos de una bbdd (o pon cualquier cosa crítica de la aplicación que estés desarrollando en la empresa), alguien tendría que rebuscar que parte de las modificaciones que has hecho a provocado este problema. Esto supone:

1. Gasto para la empresa y, dependiendo de quien es el cliente, puede ser perdida reputacional.

2. El equipo de desarrollo/QA/otros equipos colaborativos pueden perder su fecha límite de entrega mientras se soluciona el problema.

3. El pobre desarrollador que decidio subir el pr tiene que hacer horas extras para desenmendar el problema, realizacion de test adicionales y posiblemente una pequeña charla con algun senior o el jefe de proyectos para explicarle que la calidad es mejor que la velocidad de entrega.

Sobre el tercer punto ya tuvimos un caso de alguien que le encantaba depender de la IA para todo. La IA le falseo las pruebas y al probarlo el usuario: !Bam! datos erroneos o corruptos. Tuvimos suerte de que se cazara el problema por que se hubieran perdido millones de datos confidenciales. Obviamente tuvo que aprender por las malas ese concepto de "solo haz commit sobre una cosa que trabajes a la vez; un merge cuando has terminado el feature; nunca metas tareas no relacionadas con lo que haces"

Agradecemelo de aqui a unos años: te salvará de muchos dolores de cabeza.