Belangrijkste inzichten
- Coderen is niet langer het langzame gedeelte. In 31 dagen voerde onze main repo 473 pull requests samen. 130 van hen hadden nodig dat iemand teruggaat en main in de branch voegt, 239 merge commits in totaal, en 238 van die werden door een persoon gemaakt.
- De PRs die dat nodig hadden, kostten een mediaan van 44 uur van open naar merge. De PRs zonder dat kostten 2 uur. Van de 60 PRs die langer dan drie dagen open bleven, hadden 51 minstens één merge van main nodig.
- babysit-pr splitst de taak op één label:
LGTM, „looks good to me", wat de auteur toevoegt wanneer het werk voltooid is. Daarvoor houdt een vaardigheid de agent op de PR totdat CI groen is en elke review-bot is beantwoord. Erna houdt een GitHub Actions-workflow de PR merge-klaar totdat een persoon het voegt samen, en voegtRTMtoe, „ready to merge", zodra iemand anders dan de auteur goedkeuring geeft. - De workflow voert nooit samen, sluit nooit en wijzigt nooit een regel die de auteur schreef. Een conflict dat het niet kan oplossen rond de code van de auteur gaat terug naar de auteur als
REWORK. - De vaardigheid is openbaar, MIT gelicentieerd: babysit-pr-skill op GitHub , met het watcher-script en het ontwerp van de workflow. De workflow zelf is nog in dry run op onze repo, en ik zeg hieronder waarom.
Waarom raken voltooide pull requests verouderd?
Coderen is niet langer het langzame gedeelte. Met het architect pattern en agenten die het meeste typen doen, haalt onze repo ongeveer 13 commits per dag in main. Dat is goed voor shipping en slecht voor elke open pull request, omdat elk van die commits een PR in conflict kan zetten of de CI rood kan maken.
Ik haalde de afgelopen 31 dagen van samengevoegde PRs op om te zien waar de tijd heenging.
De 44 versus 2 is een correlatie, geen oorzaak. Een PR die langer open blijft geeft main meer tijd om eronder te gaan, dus is het waarschijnlijker dat het een merge nodig heeft. Maar de merges zelf zijn echt werk dat iemand 239 keer in een maand deed. Vijf mensen maakten 238 van die met de hand. Één PR had acht merges van main nodig over de zeven dagen dat het open was.
De goedkeuring zelf was snel. Zodra een PR zijn eerste goedkeuring kreeg, was de mediaan tijd tot merge nul uur. Het wachten gebeurde daarvoor: de auteur was klaar, dan zat de PR tot een reviewer eraan toekwam, en terwijl het zat, bewoog main. We begonnen afgewerkte PRs op 20 oktober LGTM te labelen. De 20 die sindsdien zijn samengevoegd wachtten een mediaan van 38 uur tussen LGTM en merge, en één op vier wachtte meer dan 78 uur.
Dat is de kloof hier voor. Niemand is slordig hier. De auteur denkt dat ze klaar zijn, de reviewer heeft het nog niet geopend, en de branch rots in het tussenliggende.
Klaar om uw bedrijf te laten groeien?
Start vandaag uw gratis proefperiode en zie binnen enkele dagen resultaten.
Waarom niet verouderde pull requests sluiten met actions/stale?
Het gebruikelijke antwoord op verouderde pull requests is actions/stale : een GitHub Action die een stale label toevoegt aan issues en pull requests na een ingesteld aantal dagen inactiviteit, en sluit ze automatisch enige dagen later tenzij iemand opmerkingen of pushes.
Dat past bij een pull request waar niemand aan werkt. Het doet niets voor de onze. De onze waren afgewerkt werk dat verouderd raakten terwijl ze op een reviewer wachtten, omdat main eronder bewoog. Ze sluiten gooit het werk weg, en een stale label vertelt de auteur wat ze al weten. Wat de PR nodig heeft is iemand die main erin voegt, de rode CI-taak opnieuw uitvoert en het groen houdt tot een persoon het goedkeurt. Dus in plaats van verouderde pull requests te sluiten, houden we ze merge-klaar.
Hoe babysit-pr pull requests merge-klaar houdt
De splitsing volgt wie wacht. Vóór LGTM is de auteur nog op de PR, meestal een agent-sessie, en de vaardigheid houdt die sessie nuttig werk doen in plaats van overwinning af te roepen wanneer de code compileert. Na LGTM is de auteur verder gegaan, dus het werk gaat naar iets dat hen niet nodig heeft: een workflow die draait of iemand kijkt of niet.
LGTM staat voor „looks good to me". Op de meeste teams zegt een reviewer het over iemands anders code. Hier plaatst de auteur het op hun eigen PR als label dat betekent „Ik ben klaar, niets meer voor me om te doen". Het is het woord van een persoon: de agent voegt het alleen toe wanneer het werd opgedragen om de PR af te staan. Dat label is de opt-in voor alles erna, en het is wat een ontwikkelaar comfortabel maakt om een bot naar hun branch te laten pushen.
Schrijf u in voor onze nieuwsbrief
Ontvang gratis de nieuwste tips, trends en aanbiedingen.
Vóór LGTM: een Claude Code-vaardigheid voert de PR naar ready
De vaardigheid begon als de babysit-pr vaardigheid in Theo Browne’s tstack
. Ik hield zijn watcher en zijn kernregels en veranderde waar het stopt.
Één watcher per pull request
pr-wait peilt één pull request en print één regel per echt event: een check mislukt, alle checks klaar, iemand opmerkingen of recensies, main bewegingen onder bestanden deze PR raakt, de branch ging achteruit of in conflict, de PR voegde samen. In Claude Code draait het onder het Monitor tool, dus elk regel wekt de agent eenmaal. Een event dat geen actie nodig heeft eindigt de beurt zonder bericht. “Nog steeds wachten” is geen nieuws, en een agent die het vijftig keer zegt, vult zijn eigen context met niets.
Sorteer de rode CI-taak voor je code aanraakt
Er zijn vier soorten rood, en slechts één is een code fix:
- De PR brak het. Repareer het met de kleinste verandering.
- De runner flakte. Voer de mislukte taken eenmaal opnieuw uit. Een tweede mislukking op dezelfde head is geen flake.
- Main is rood. Repareer main niet op iemands feature branch. Rapporteer het en wacht.
- Een procescheck is rood, bijvoorbeeld de PR linkt geen goedgekeurd issue. Dat is een stap voor een persoon.
Agenten die alleen gelaten worden behandelen alle vier als de eerste, en de PR groeit met een workaround voor een test die op main kapot is.
Bewijs een review bevinding voor je het reparaert
Een review bevinding die de agent accepteert krijgt eerst een mislukkende test, dan de fix. Een bevinding die het weigert krijgt een geschreven reden. Dit is dezelfde regel als onze bewezen review vaardigheid, en het is wat review bots van het sturen op volume tegenhoudt.
Houd de PR de grootte van haar doel
Review loops groeien een PR één goedkoop uitziende fix tegelijk: een guard voor een edge case die niemand raakt, een test voor gedrag dat niet veranderde, een compatibility shim. De vaardigheid reparaert echte bugs in het beoogde geval en weigert de rest in geschreven vorm. De waardevolle worden issues.
Ready is een checklist
Elke gating CI-taak groen op de huidige head, elke review-bot klaar op deze head, niets wacht op een mens, geen onopgeloste thread, geen conflict. Wanneer dat stand houdt rapporteert de agent het en stopt het kijken.
Na LGTM: een GitHub Actions-workflow lost merge-conflicten op
De workflow heeft twee taken.
De gate bepaalt wat elke PR nodig heeft
De gate is goedkoop: geen agent, geen checkout van PR code. Het draait op elke push naar main, elke CI-voltooiing, elk label en review, en elke 30 minuten, en één GraphQL-query geeft het elke open LGTM PR. Voor elk een zuivere functie bepaalt wat te doen. Voeg RTM toe als het door iemand anders dan de auteur is goedgekeurd, groen, en konflictvrij. Laat het met rust als een review draait. Voer rode CI eenmaal opnieuw uit. Stuur een conflict, of CI dat nog steeds rood is na zijn heruitvoering, naar de fixer.
De fixer-agent voegt main in
De fixer is een agent-taak voor één PR op één head. Het voegt main in de branch zonder vast te leggen, geeft de agent de conflicteerde bestanden en de mislukte logs, en laat het alleen de conflicteerde bestanden en bestanden de PR al verandert bewerken. Dan stelt het één vraag.
Kan deze PR landen zonder een regel zijn auteur schreef te veranderen?
Zo ja, het oordeel is MODERNIZE. De agent lost het conflict rond de regels van de auteur op, een validator controleert het resultaat, en de workflow pushed een normale merge commit. Als nee, omdat main de functie die de PR bewerkt verwijderde of de PR’s eigen code faalt CI, het oordeel is REWORK. Niets wordt gepushed, LGTM komt eraf, en de auteur krijgt een opmerking met de kleinste herschrijving. Als main al doet wat de PR doet, het oordeel is CLOSE, en een persoon sluit het.
De validator houdt elke regel de auteur schreef
De validator is wat de regel stand houdt. Het weigert elke merge die een regel de PR toevoegde laat vallen, of een regel main toevoegde aan een conflicteerd bestand. Het weigert bewerkingen buiten de toegestane bestanden, achtergebleven conflict markers, en wijzigingen in CI of beveiligingsbestanden. Een agent die probeert de code van de auteur te “repareren” eindigt met een label waarin om een mens wordt gevraagd, nooit met een push. De workflow pushed zonder force, en alleen als de branch sinds het begin niet is verplaatst. Één poging per head en base, twee per head, drie opmerkingen per PR per dag.
Het voegt nooit samen
RTM, „ready to merge", is de verklaring van de gate dat een PR alles heeft wat het nodig heeft: de LGTM van de auteur, een goedkeuring van iemand anders, groene CI en geen conflict. Een persoon doet het samenvoegen. Dat hield het ontwerp klein, en het hield het debat of een bot zou moeten samenvoegen uit de review.
Wat verandert voor de auteur, de reviewer en wie samenvoegte
De auteur zegt eenmaal klaar. Ze komen niet drie dagen later terug om main samen te voegen en op CI te wachten, en een PR van een agent rekt niet omdat de sessie die het opende eindigde.
De reviewer opent een PR die groen en merge-klaar is op vandaag’s main, dus hun goedkeuring is de laatste stap en niet het begin van nog een ronde.
Wie samenvoegte werkt uit één lijst. RTM blijft zodra de gate het toevoegt, en als main de PR daarna breekt, reparaert de workflow het en blijft het label.
En de auteur behoudt controle over hun code. Het ergste wat de bot naar een branch kan doen is een merge commit toevoegen dat een validator regel voor regel heeft gecontroleerd.
Waarom onze oude merge conflictresolver nooit draaide
We hadden een conflictresolver daarvoor. Een detector vond conflicteerde PRs en commentarieerde op ze, en de resolver draaide wanneer iemand een label toevoegde erom te vragen. In dezelfde periode draaide de detector ongeveer 2.500 keer. De resolver draaide nul keer.
Ik denk niet dat iemand lui was. Een ontwikkelaar die een PR voltooid acht komt niet terug erop om een knop in te drukken. Automatisering die om te worden gevraagd zal niet worden gevraagd. Dat is waarom dit vanaf LGTM begint, het moment dat de auteur zegt dat ze klaar zijn, en de rest zonder hen doet.
Wat werkt nog niet?
Twee dingen, en ik zou ze liever hier zeggen dan dat je ze ontdekt.
De workflow is in dry run
Zijn gate logt alleen wat het zou doen totdat een repository variabele anders zegt. Voordat het zover ging, vond een review die alleen bevindingen houdt het met een mislukkende test kan bewijzen elf bugs in het. Een paar zijn de moeite waard om te weten als je je eigen bouwt. GitHub’s labelsearch vertraagt, dus een PR die het teruggeeft mag het label seconden geleden verloren hebben, en de beslissing moet live labels controleren. Een “deze head had al zijn heruitvoering” marker geschreven voor de heruitvoering aanroep slaagt laat één mislukte API-aanroep de enige retry van de head gebruiken. En een “verlies geen regel” controle die geen naamwijzigingen volgt ziet elke regel van een hernoemd bestand als verloren.
De agent runners waren uit
Sinds 19 oktober is elke taak gericht op onze agent runners mislukt een machine krijgen: 406 geannuleerd, 24 nog in de wachtrij toen ik controleerde. De gate draait elders en is prima, maar de fixer heeft een agent runner nodig, en een dode ziet er exact uit als een stille dag. Niets mislukte luid. Taken in de wachtrij en werden toen geannuleerd. Als je dit bouwt, waarschuw op fixer runs die in de wachtrij zitten.
Dus de getallen hierboven zijn het voorbij plaatje. Nu hebben we 27 open LGTM PRs, 7 van hen met rode CI en geen met RTM. Die zijn de getallen dit zou moeten veranderen, en ik zal rapporteren wat het deed.
Hoe je de babysit-pr vaardigheid installeert
github.com/LivinTribunal/babysit-pr-skill heeft:
SKILL.md, de vaardigheid, met een korte “configureer eenmaal” sectie voor uw CI workflows, review-bots en procescontroles.scripts/pr-wait, de watcher. Het heeft Python en een geverifieerdeghnodig.docs/after-lgtm.md, het ontwerp van de na-LGTMworkflow: de labels, de gate, de fixer, de regel dat het nooit de regels van de auteur verandert, en de elf bugs.
De workflow is een ontwerp eerder dan een bestand om te kopiëren, omdat de onze tegen één bedrijf’s labels, runners en CI draait. Bouw de jouwe van het doc, ship het in log-only mode, lees een dag van zijn besluiten, draai het dan in.
Het wordt gekoppeld met het architect pattern , wat bepaalt wie de code schrijft, en grain , wat bepaalt wat de code eruit ziet. babysit-pr is wat gebeurt nadat een van beiden de pull request opent. Als je de agent zelf aanscherpt, de CLAUDE.md A/B test en de context limiet die token gebruik met 17% reduceerde behandelen de instructies en de kosten.
