Ayoub Fandi's nieuwe GRC Engineer-issue gaat over change-managementcontroles die nog steeds een screenshot van een PR-goedkeuring opslaan, terwijl de goedkeuring zelf minder betekent. De output van agents is toegenomen. De reviewtijd niet. Het groene vinkje ziet er nog steeds uit als in 2020. Wat het bevestigt, is niet meer hetzelfde.
Hij heeft gelijk. Wij zouden hieraan toevoegen: de aanpassing die de meeste teams zullen doorvoeren, is om weer een mens aan de PR toe te voegen. Dat levert nog steeds dezelfde screenshot op. Het zegt niet wat de mens heeft moeten bekijken. En de geschreven regel die aangeeft wie facturen, betalingen of iets met een grote impact moet reviewen, kan zelf in een hotfix worden uitgeschakeld die iedereen graag merge.
De screenshot kan de twee jaren niet uit elkaar houden
Een goedkeuring op een pull request registreert dat de workflow een goedkeuringsstap heeft bereikt voor het mergen. De screenshot registreert niet wat de reviewer heeft bekeken, hoeveel aandacht hij eraan heeft besteed of welke geschreven regels hij heeft gecontroleerd. Toch is dit nog steeds het bewijsstuk dat de meeste change-managementcontroles van een auditor vragen om te steekproeven, omdat het het bewijsstuk is dat de controledefinitie nog steeds noemt.
Ayoub beschrijft de achteruitgang aan de hand van de eigen rapportage van engineering: meer output, grotere PR's, review als de nieuwe bottleneck. Hij verwijst naar een GitHub Blog-artikel dat een externe studie samenvat: door agents gegenereerde wijzigingen vertoonden meer redundantie en technische schuld, terwijl de sentimenten van reviewers neutraal of positief waren. De screenshot die je catalogus nog steeds verzamelt, kan die twee jaren niet uit elkaar houden. Het vinkje is nog steeds groen. De aandacht erachter is niet dezelfde aandacht.
Een mens toevoegen levert nog steeds hetzelfde bewijs op
De verleidelijke herziening is om de tijd terug te kopen: een persoon verplichten, de diff verkleinen, nog een goedkeurder toevoegen. Voor sommige wijzigingen is dat de juiste keuze. Het is ook de herziening die de controledefinitie ongewijzigd laat. Je verzamelt nog steeds een screenshot van een goedkeuring. Je hebt nog steeds niet opgeschreven wat die goedkeuring mag bevestigen.
Overgebleven reviewtijd, als je die krijgt, gaat naar de vragen die code review al kent. Is de hotfix correct? Is het veilig? Dat zijn echte vragen. Maar niet de vraag 'heeft deze wijziging zojuist de regel verwijderd dat een factuur-PR een domeineigenaar nodig heeft.' Een reviewer die naar factuurberekeningen kijkt, zal de CODEOWNERS-wijziging als ruis goedkeuren.
Het type wijziging
Beschouw dit als illustratief: het type wijziging dat de vraag oproept, niet een klantincident. De hotfix in de rest van de PR kan netjes zijn. Deze regel is de change-managementregel die onjuist wordt.
# domain owners/infra/ @platform-owners-/billing/ @billing-owners+# /billing/ @billing-owners # unblocking the invoice hotfix/docs/ @docs-ownersGeen bug en geen kwetsbaarheid. CC8.1 gaat over change management: wijzigingen moeten geautoriseerd, gereviewd en goedgekeurd worden via het proces dat je hebt opgeschreven. Deze regel was de onafhankelijke review voor facturering. Door deze uit te schakelen, kan de volgende factuur-PR worden gemerged met een generieke goedkeuring. De screenshot zal nog steeds bestaan. De geschreven regel dat factuurwijzigingen een domeineigenaar nodig hebben, zal niet meer bestaan.
Herschrijf de controle, niet alleen het aantal medewerkers
Ayoub's issue is een waarschuwing om de PR-rituelen niet harder te verdedigen alleen omdat de screenshot er nog steeds officieel uitziet. Wij zijn het daarmee eens. Het extra probleem is dat de herziening die de meeste teams dit kwartaal zullen doorvoeren, nog steeds om die screenshot vraagt, en dat de regel die de review definieert, in een PR kan worden gewijzigd die niemand als een controlewijziging heeft gelezen.
Als je change management herschrijft voor de snelheid van agents, schrijf dan op wat 'gereviewd' mag betekenen, en behandel wijzigingen in die definitie als binnen de scope van dezelfde controle. Een CODEOWNERS-pad, een vereiste check, een CODEOWNERS-vrijstelling, een overslag in branch protection: dat zijn de controlemechanismen. Het zijn geen klusjescommentaren op een hotfix.
Waar heygrc staat
heygrc is niet de nieuwsbrief, de workshop of een vervanging voor de bug- en beveiligingsreviews die je al uitvoert. Het is de laag die elke pull request afzet tegen de frameworks die je hebt gekozen en de context die je eraan hebt gegeven. Als een wijziging een change-management- of review-padregel moeilijk verdedigbaar maakt, dan geeft het dat aan op de diff. Het merge niets. Het stelt de vraag op de pull request, voordat de audit een screenshot steekproeft die niet meer betekent wat de controle zegt dat het betekent.
Lees Ayoub's issue. De achteruitgang van de screenshot is van hem. De extra vraag is wat er gebeurt als je de controle herschrijft en nog steeds alleen de screenshot verzamelt.