Factory in de praktijk: code reviews, tests en opruimwerk
Factory helpt teams met code reviews, tests en bugfixes die altijd blijven liggen. Zo zet je AI-agenten in zonder risico.
👁 115 keer gelezen
Factory levert de meeste waarde voor teams waar belangrijk programmeerwerk in de wachtrij blijft staan omdat er altijd iets dringenders is: code reviews, tests, kleine bugfixes, opruimen van oude code. We hebben de toepassingen verzameld waarin Droid-agenten het meeste werk van je team overnemen.
Hoe je Droid installeert en code review instelt, hebben we beschreven in de Factory-handleiding.
Waar begin je in je team
De veiligste eerste stap is automatische review van pull requests. Het verandert geen code, maar voegt alleen commentaar toe, zodat je team de kwaliteit van de agent kan beoordelen zonder risico. Na twee weken zie je of de opmerkingen relevant zijn. De tweede stap zijn kleine bugs van de backlog, één voor één toegewezen en beoordeeld zoals wijzigingen van een collega. Pas daarna grotere taken in specificatiemodus.
Het is belangrijk dat het hele team de regels kent: wie wijst taken toe aan de agent, wie beoordeelt zijn wijzigingen en welke delen van de code de agent niet aanraakt zonder toestemming.
Automatische review van elke pull request
De eenvoudigste implementatie en vaak het meest merkbaar. Droid beoordeelt elke pull request voordat een mens hem ziet en geeft commentaar op specifieke regels. Hij focust op fouten, niet op stijl. De menselijke reviewer krijgt een wijziging waaruit de voor de hand liggende problemen al zijn gehaald, en kan zich richten op logica en architectuur.
Review voor het indienen
Een commando om lokale wijzigingen te reviewen stelt een programmeur in staat code te controleren voordat iemand anders hem ziet. Minder rondes met correcties in de pull request betekent sneller mergen en minder schakelen tussen taken.
Kleine bugfixes
Elk project heeft een lijst met kleine bugs die niemand tijd heeft om te fixen. Je beschrijft de bug, Droid vindt de oorzaak en stelt een fix voor, die je beoordeelt zoals elke andere wijziging. De achterstallige lijst krimpt zonder tijd af te nemen van nieuwe features.
Tests voor code die ze niet heeft
Oudere modules hebben vaak geen tests, waardoor elke wijziging erin risicovol is. Droid schrijft tests voor bestaande code, en jij controleert of ze testen wat echt belangrijk is. Na een paar weken zijn wijzigingen in oude code geen loterij meer.
Migraties en grotere wijzigingen met een plan
Een bibliotheek updaten, databasestructuur wijzigen, overstappen naar een nieuwe taalversie. Specificatiemodus onderzoekt eerst het project en presenteert een plan, en het team keurt het goed voor de eerste wijziging. De Factory-documentatie beveelt deze modus aan bij migraties en beveiligingsgevoelige wijzigingen.
Taken in scripts en CI
Als bepaald werk met Droid goed werkt, kun je het uitvoeren zonder interactief venster, bijvoorbeeld in een CI-pipeline. Repetitieve taken, zoals review of het genereren van een wijzigingsrapport, gebeuren automatisch bij elke deployment.
Werken in je favoriete editor
Droid werkt in VS Code, Cursor, Windsurf, JetBrains-editors en Zed. Je team hoeft geen tools te veranderen, en in VS Code ziet de agent het geopende bestand en fouten uit de editor.
Voorbeeld: een week met technische schuld
Een team van vier programmeurs heeft dertig kleine bugs op de lijst en een betalingsmodule zonder tests. Op maandag schakelen ze automatische review van pull requests in. Elke programmeur wijst dagelijks twee kleine bugs toe aan Droid en beoordeelt de fixes. Op woensdag plannen ze in specificatiemodus tests voor de betalingsmodule, en op vrijdag mergen ze die na review. De buglijst daalt met de helft zonder werk aan de nieuwe feature te annuleren.
Cruciaal is dat het team het werk aan de nieuwe feature niet heeft geannuleerd. De agent nam taken over die toch in de wachtrij stonden, en mensen hielden zich bezig met het reviewen van zijn wijzigingen, wat korter duurt dan zelf fixes schrijven. Het is de moeite waard om één regel in de gaten te houden: elke wijziging van de agent heeft een eigenaar in het team die hem heeft beoordeeld en goedgekeurd. Zo verliest niemand kennis over wat er in de code is veranderd.
Waar je op moet letten
- Beoordeel elke wijziging van de agent zoals een wijziging van een mens.
- Automatische review vervangt geen reviewer bij architectuurbeslissingen.
- Vergroot de zelfstandigheid van de agent geleidelijk, als je weet hoe hij met het project omgaat.
Hoe controleer je of het de moeite waard is
Meet wat het team echt pijn doet. Tijd van het openen van een pull request tot het mergen, want automatische review zou die moeten verkorten. Aantal bugs op de backlog aan het begin en na een maand. Testdekking in modules die geen tests hadden.
Als geen van deze cijfers na een maand is veranderd, ligt het probleem meestal niet bij de tool, maar bij het feit dat niemand tijd heeft om wijzigingen van de agent te reviewen. Dan is het de moeite waard om een vast moment in de week aan te wijzen voor het reviewen van wat hij heeft voorbereid.
Het is ook nuttig om bij te houden welke soorten taken de agent het beste uitvoert. Na een maand weet het team wat ze meteen kunnen toewijzen en wat ze beter zelf kunnen doen, en verspillen ze geen tijd meer aan pogingen om taken aan de agent te geven die kennis buiten de code vereisen, bijvoorbeeld afspraken met de klant.
More on this from HELDER
benchmarks·VPS: model doorzoekt hoogresolutie beelden parallelVPS laat AI-modellen eerst parallel zoeken in beeldfragmenten voordat ze inzoomen. Tot 8 procentpunt nauwkeuriger dan sequentieel zoomen.