De eerste pull request is zelden het laatste woord. De reviewer leest hem en zegt: dit klopt, maar gearchiveerde facturen moeten er ook bij. Dat is geen fout in de run. Het is een wijziging in wat de taak moet doen, ontdekt door naar het resultaat te kijken, en zo worden de meeste wijzigingen ontdekt.
Een tijdlang ging CodeLynq daar slecht mee om. Feedback op een gebouwde taak startte een nieuwe run: een nieuwe branch en een tweede pull request, die we vervolgens toch weigerden omdat de taak er al een had. En de route "itereren op feedback" las alleen wat de git-host had, falende checks en reviewopmerkingen, nooit de feedback op de taak zelf of de specificatie waar hij op gebouwd was.
Feedback wordt een nieuwe versie van de specificatie
Een wijziging begint nu waar de taak begon: in de specificatie. Je schrijft op de taak wat je anders wilt, of je kiest feedback die er al staat. De AI herziet de specificatie zodat die het werk inclusief de wijziging beschrijft. Elk veld komt volledig terug in plaats van als diff, zodat de nieuwe versie op zichzelf leesbaar is, en er komen twee dingen bij:
- Het wijzigingsverzoek: de feedback waar deze versie antwoord op geeft, bewaard bij de versie.
- De samenvatting van de wijziging: wat er volgens de AI anders is dan wat er gebouwd werd, in een paar regels.
De herziening is een concept. Eerdere versies blijven bestaan. Wachtte een eerdere herziening nog op goedkeuring, dan vervangt de nieuwe die; een concept dat iemand met de hand schreef blijft als eigen versie bewaard. Er wordt niets gebouwd voordat iemand goedkeurt.
Waarom via de specificatie, en niet de opmerking rechtstreeks aan de agent geven? Omdat de specificatie vastlegt wat er is afgesproken. Leefde de wijziging alleen in een prompt, dan zou de pull request iets doen wat geen enkel goedgekeurd document beschrijft, en zou de volgende die aan de taak werkt uitgaan van een verouderde specificatie. Het geeft de reviewer ook een moment om te checken of "neem gearchiveerde facturen mee" begrepen is zoals bedoeld, voordat iemand voor een run betaalt.
Gebouwd op dezelfde branch, in dezelfde pull request
Keur je een wijzigingsversie goed, dan start er een wijzigingsrun. Dat is een eigen run, met een eigen log, kosten en status, maar hij gaat verder op de branch van de run waarvan de pull request openstaat en pusht daarheen, zodat de bestaande pull request wordt bijgewerkt. Geen tweede pull request. Bij een taak over meerdere repositories gaat hij verder op één branch per repository die de eerdere run veranderde.
De agent krijgt het wijzigingsverzoek, de samenvatting, de nieuwe specificatie en de vorige, zodat hij het verschil bouwt en niet de hele taak opnieuw. Is de wijziging gepusht, dan kan de pull request nog steeds reviewopmerkingen en falende checks krijgen zoals elke andere, en daar geeft de gewone iteratie antwoord op.
Er zijn twee weigeringen. Een taak zonder open pull request heeft niets om op verder te gaan: pas de specificatie aan en start een run. En zolang er een run aan de taak werkt, wacht een wijziging tot die klaar is. Op self-hosted runners is voor verdergaan op een branch runner 1.9.0 of nieuwer nodig; voldoet geen enkele runner, dan zegt CodeLynq waarom, ook als een runner wel geïnstalleerd is maar nooit verbinding heeft gemaakt.
Wat er misging: de pull request die al gemerged was
Onze registratie van een pull request volgt hem niet op de git-host. Mergede iemand de pull request op GitHub, dan kon CodeLynq nog steeds denken dat hij openstond. Een wijzigingsrun ging dan zoals gevraagd verder op de branch, en de pushes kwamen terecht op de branch van een gemergede pull request. Ze bereikten de basisbranch nooit en verschenen in geen enkele pull request. Van buitenaf gezien was de wijziging gemaakt en weer verdwenen.
Nu vraagt een wijziging of iteratie, voordat er iets gebouwd wordt, de git-host naar elke branch waarop hij verder wil gaan. Is die pull request gemerged of gesloten, dan gaat het werk naar een nieuwe branch vanaf de basisbranch, met een nieuwe pull request. De run volgt de nieuwe pull request, zodat de volgende wijziging daarop verdergaat. We repareerden het eerst voor self-hosted runners; een paar uur lang weigerde de platformworker zo'n wijziging met uitleg, en nu opent ook die de nieuwe branch en pull request.
In dezelfde ronde losten we een kleiner onrecht op. Een iteratie waarin de agent niets meer te repareren vond, mislukte met "made no changes", de melding die een nieuwe run krijgt, waardoor een taak als mislukt stond naast een afgeronde pull request. Die wordt nu gewoon afgerond. Een gevraagde wijziging die niets verandert, mislukt nog steeds, met een melding die dat zegt, want dan is er wel echt iets misgegaan.
En eentje die we vonden tijdens het bouwen: bij self-hosted runs werd een handmatige iteratie naar onze worker gestuurd en bleef hij ook in de wachtrij staan voor een runner. De runner kon hem oppakken als nieuwe run en een tweede pull request openen. Een iteratie is nu als zodanig gemarkeerd, en alleen een runner die op een branch kan verdergaan pakt hem op.
Wat het niet doet
- Het merget niet. Elke wijziging eindigt in een pull request die een mens merget, om de redenen in waarom de AI bij ons niet mag mergen.
- Het slaat goedkeuring niet over. Elke wijziging is een nieuwe versie van de specificatie, en iemand keurt die goed voordat hij gebouwd wordt.
- Reviewopmerkingen op de git-host leveren geen nieuwe specificatieversie op. Die gaan via de iteratie, die de pull request repareert op basis van de opmerkingen. Verandert de opmerking wat de taak moet doen, zet hem dan als wijziging op de taak.
De vraag die je moet stellen
Als je een AI-codingtool beoordeelt, zegt de eerste pull request je minder dan de tweede. Vraag wat er gebeurt als je "bijna" zegt: komt de feedback in dezelfde pull request terecht, beschrijft de specificatie daarna nog wat er gebouwd is, en wat gebeurt er als de pull request intussen gemerged is. Komt een correctie steeds terug, maak er dan een regel van, zie reviewfeedback hoef je maar één keer te geven. Draai je op je eigen machines? De kant van de runner staat bij self-hosted runners.