Hoe krijgt u vastgelopen pull requests weer in beweging?
Een AI werknemer voor codereview die één keer per dag elke open pull request in al uw repos leest, de pull requests markeert die een SLA voor reviews hebben overschreden, verouderd zijn geraakt of blijven hangen op onbehandelde wijzigingsverzoeken, en de auteur of reviewer in Slack een seintje geeft met precies wat er blokkeert. Deze leest GitHub en plaatst berichten in Slack, meer niet.
×
Een SLA voor reviews is makkelijk op te schrijven en moeilijk af te dwingen. Niemand houdt de reviewwachtrij fulltime in de gaten, dus een PR die maandagochtend is geopend en woensdagmiddag nog niet is beoordeeld ziet er in de repolijst hetzelfde uit als een PR die vijf minuten geleden is geopend, totdat iemand toevallig ver genoeg scrolt om het op te merken. Verouderde PR's zijn erger: een branch zonder commits, zonder opmerkingen en zonder reviews in een week is meestal gewoon vergeten, en die verrot stilletjes totdat een rebaseconflict iemand dwingt er iets mee te doen. En "gevraagde wijzigingen" is een status, geen waarschuwing. Een reviewer vraagt om wijzigingen, de auteur ziet het, het leven gaat door, en de PR blijft daar open lijken terwijl deze eigenlijk geblokkeerd is. De gangbare aanpakken sluiten deze cirkel niet. GitHub's eigen meldingen zijn makkelijk te dempen en maken geen onderscheid tussen een PR van vijf minuten oud en een van vijf dagen oud. Een wekelijkse standup vangt de luidste blokkades, niet de stille. Handmatig de PR lijst doornemen is de eerste keer grondig en wordt de tweede keer overgeslagen.
De AI werknemer voor codereview draait volgens een dagelijks schema, leest elke open PR in al uw repos via de gh CLI met alleen leestoegang en classificeert elke PR aan de hand van drie regels: wacht op review en de SLA is overschreden, verouderd zonder activiteit in N dagen, of draagt gevraagde wijzigingen die de auteur niet heeft behandeld. Voor elke PR die een regel raakt, plaatst deze een seintje in Slack aan degene die aan zet is: de gevraagde reviewer als de PR te laat is, de auteur als de PR verouderd is of onbehandelde feedback heeft. Het seintje bevat een samenvatting van één regel over wat de PR daadwerkelijk blokkeert. Deze voegt nooit iets samen, sluit nooit iets en keurt nooit iets goed.
Zie precies hoe het werk wordt gedaan.
Draait volgens een dagelijks schema
Een geplande uitvoering wordt één keer per dag afgevuurd. Elke uitvoering herberekent de reviewstatus vanuit de huidige staat van GitHub, dus er wordt niets meegenomen van de seintjes van gisteren. De repo is de bron, niet het geheugen van de AI werknemer.
Draagt uw SLA regels mee
Wat telt als "SLA overschreden", "verouderd" en "onbehandeld" reist met deze mee als skill: de SLA klok voor reviews, het venster voor veroudering, hoe je herkent dat een review met gevraagde wijzigingen daadwerkelijk is behandeld in plaats van alleen maar te blijven liggen, en wie per situatie een seintje krijgt.
Verbindt met GitHub met alleen lezen, met rechten die u instelt
Via de gh CLI leest deze open pull requests in de geconfigureerde repos: hun leeftijd, auteur, gevraagde reviewers en huidige status, plus de reviews en opmerkingen op elke PR. Vervolgens plaatst deze het seintje in Slack. Inloggegevens blijven in het geheugen, worden tijdens de uitvoering ingevoegd, worden nooit naar schijf geschreven en worden nooit aan het model getoond.
Nooit schrijftoegang tot GitHub
Deze kan een PR niet samenvoegen, niet sluiten, niet goedkeuren en geen review afwijzen. De enige output is het seintje in Slack. Al het andere is een leesactie.
Geeft de juiste persoon een seintje
Elke ochtend brengt een seintje in Slack voor elke PR die vastzit: voor wie deze is, waarom deze vastzit (te laat, verouderd of onbehandelde wijzigingen), hoe lang dat al zo is en een link rechtstreeks naar de PR. Het team beslist wat er daarna gebeurt: de PR beoordelen, de reviewer porren of de PR sluiten.
Draait in uw eigen omgeving
Elke uitvoering is geïsoleerd binnen uw eigen infrastructuur en bereikt alleen GitHub (alleen lezen) en Slack. Uw data verlaat uw omgeving nooit.
Rechten die u instelt
De GitHub inloggegevens blijven in het geheugen, worden tijdens de uitvoering ingevoegd, worden nooit aan het model getoond en worden nooit naar de logs geschreven.
Alleen een seintje geven en samenvatten
Deze voegt nooit een PR samen, sluit nooit een PR en keurt nooit een PR goed, en wijst nooit een review af en lost nooit een review op. Deze rapporteert wat er blokkeert en laat de beslissing aan een persoon.
Beoordeeld aan de hand van de huidige staat
Elke uitvoering wordt herberekend vanuit de huidige staat van GitHub, zonder verouderde overdracht en zonder te handelen op een seintje dat de uitvoering van gisteren al heeft opgelost.
De regels zijn van u
De SLA drempels, het venster voor veroudering en de GitHub rechten zijn van u, met versiebeheer en aangepast op uw voorwaarden, niet in het dashboard van een leverancier.
Een reviewwachtrij waarvoor iemand er vroeger aan moest denken om er doorheen te scrollen brengt nu elke ochtend zijn eigen blokkades naar boven, in Slack, gericht aan degene die aan zet is. De AI werknemer leest en geeft alleen een seintje; het team beslist nog steeds wat er met elke PR gebeurt.
Elke dag
Elke open PR opnieuw getoetst aan de huidige staat van GitHub
3 controles
Te laat voor review, verouderd en onbehandelde wijzigingen, in één ronde
0 schrijfacties
Samenvoegingen, sluitingen of goedkeuringen door de AI werknemer
Onze gratis AI-audit laat zien waar AI kansen biedt voor uw bedrijf, welke risico's daarbij komen kijken, en zet meteen uw eerste AI werknemer aan het werk.
Hoe houden AI werknemers uw documentatie synchroon met de code?
Doorloopt dagelijks de samengevoegde code, herschrijft de documentatie die door die wijzigingen is geraakt, en opent één beoordeelbare pull request. Publiceren wacht op een merge door een mens.
×Hoe testen AI werknemers elke pull request voordat een mens deze beoordeelt?
Checkt elke pull request uit, draait de suite, beproeft de wijziging via de edge op een testdeploy, en plaatst het resultaat. Blijft weg van productie en laat de merge aan een persoon over.
×Hoe krijgt u een postmortem opgesteld op het moment dat een incident is opgelost?
Reconstrueert de incidenttijdlijn, zet die af tegen deploys en logpieken en opent een gestructureerde postmortem als een document PR. De AI werknemer stelt op, het team maakt af.
×