Deze praktijk is erg slecht, maar er zijn enkele manieren om dit probleem op te lossen. 1. Probeer ervoor te zorgen dat alle testinfrastructuur op zijn plaats is. Vibe coding wordt gemakkelijker, en de bijbehorende vide eenheidstest, evenals de verschillende regressietests en functionele tests die voorheen moeilijk waren, moeten worden uitgevoerd. Dit zorgt ervoor dat, zelfs als iemand het verprutst, er veel tests zijn die je in de gaten houden. 2. Vergelijkbaar met de serverzijde, verschillende ringen/fases kunnen geleidelijk worden uitgerold. Zelfs als er een probleem wordt ontdekt, is het gemakkelijk om terug te rollen. Dit zal geen grote problemen veroorzaken. 3. Eigenlijk ligt de wortel nog steeds in de consensus, of het nu voor jezelf handig is of voor anderen, of zelfs voor de beoordeling van hogerop. Probeer een grote pull request op te splitsen in kleinere. Dit maakt het voor de agent gemakkelijker om te reviewen, en ook voor jezelf om te reviewen, wat de nauwkeurigheid verhoogt. Op deze manier kun je in principe voorkomen dat iemand een grote puinhoop maakt, maar je kunt nooit helemaal voorkomen dat iemand het verprutst.🤣
GeekPlux
GeekPlux26 aug, 09:02
Wanneer in een groot project een deel van de mensen begint met vibe coding, waarbij elke PR tientallen bestanden wijzigt, is het volledig onmogelijk om te reviewen... Ik heb geprobeerd Claude Code review te gebruiken, maar dat voelt ook niet betrouwbaar. Hoe kan ik, zonder deze collega's te verbieden om door te gaan met vibe coding, de bijwerkingen tot een minimum beperken? Hoe kan ik de stabiliteit en betrouwbaarheid van het project waarborgen?
21,03K