Esta práctica es muy mala, pero hay algunas formas de resolver este problema. 1. Intenta asegurarte de que toda la infraestructura de pruebas esté lista. Hacer coding de vibe es más fácil, y los correspondientes tests unitarios de video, así como las diversas pruebas de regresión y funcionales que antes eran difíciles de realizar, deberían implementarse. De esta manera, aseguras que incluso si alguien hace cambios inapropiados, una gran cantidad de pruebas estarán ahí para vigilarte. 2. Similar a los diferentes anillos/etapas del lado del servidor, se puede hacer un despliegue gradual. Incluso si se descubre un problema, es fácil revertir la operación. No causará grandes problemas. 3. En realidad, la raíz del problema está en el consenso, ya sea para facilitar las cosas para uno mismo o para los demás, e incluso para las evaluaciones de arriba. Intenta dividir un gran pull request en partes más pequeñas. Así, es más fácil para el agente revisarlo y para ti mismo revisarlo, aumentando la precisión. De esta manera, se puede prevenir en gran medida que alguien cause un gran problema, aunque siempre hay formas de que eso suceda. 🤣
GeekPlux
GeekPlux26 ago, 09:02
Cuando en un gran proyecto, hay un grupo de personas que comienza a hacer "vibe coding", cada PR modifica decenas de archivos, lo que hace que sea completamente imposible revisarlos... Intenté usar Claude Code review, pero no me parece confiable. En la situación en la que no se puede prohibir a estos compañeros continuar con el "vibe coding", ¿cómo se puede minimizar al máximo los efectos secundarios? ¿Cómo garantizar la estabilidad y fiabilidad del proyecto?
21,05K