Anthropic zegt dat Claude Code inmiddels ongeveer 90% van zijn eigen code schrijft en dat het team de beoordeling daarvan anders gaat aanpakken. In een bericht beschrijven Addy Osmani, Morgan Westlee Lunt en Qing Wang het doel: de meeste pullrequests moeten kunnen worden samengevoegd met hooguit één mens erbij. Dat mag ook degene zijn die de wijziging heeft geschreven, zolang het aantal teruggedraaide wijzigingen en incidenten niet toeneemt.
Volgens het team hoeven reviewers Claude Code niet volledig te doorgronden. In plaats daarvan vragen ze Claude om uitleg over het deel van de codebase dat ze moeten begrijpen. Die aanpak kreeg kritiek in een discussie op Hacker News: reageerders vroegen zich af of er nog iemand een storing kan debuggen als iedereen afgaat op AI-uitleg en het model de code verkeerd begrijpt.
Zo werken de beoordelingsstappen
Een classifier deelt wijzigingen in risicocategorieën in op basis van de wijziging zelf, niet van de auteur. Wijzigingen met een laag risico, zoals documentatie, tekst en toevoegingen achter een featureflag, kunnen zonder menselijke goedkeuring worden doorgevoerd. Wijzigingen met een gemiddeld risico, waaronder werk aan caching, de automatische updater en systeemprompts, vereisen één persoon. Goedkeuring door een agent telt niet als menselijke goedkeuring, maar degene die een wijziging heeft aangevraagd kan wel als de vereiste reviewer gelden.
Ook het beoordelingsproces zelf kent een risico: agents handelen naar feedback die een mens misschien zou negeren. Anthropic beschrijft een pullrequest die ’s nachts meer dan 50 beoordelings- en correctierondes doorliep, voordat de auteur het proces stopzette. Het team zegt het aantal rondes te hebben begrensd nadat het merkte dat meer beoordelingen de zaken juist verslechterden. Ook bleek dat ongeveer 59% van de code die in latere rondes werd aangemerkt, al aanwezig was toen de reviewer er voor het eerst naar keek.
Wat nog onzeker is
Een ander voorbeeld uit de openbare repository van Claude Code laat zien waar gegenereerde uitleg tekortschiet. In augustus meldde een door Claude gegenereerd antwoord dat issues waren gesloten wegens inactiviteit, omdat er informatie ontbrak om een probleem te reproduceren. Volgens de regels van de repository kunnen issues echter worden gesloten nadat ze 14 dagen als verouderd zijn gemarkeerd en er nog eens 14 dagen zijn verstreken. Een uitzondering geldt voor issues met minstens 10 upvotes. Een ontwikkelaar telde meer dan 6,000 issues met het label dat ze reproductiestappen bevatten, die toch als inactief waren gesloten. Ook het advies in het antwoord om een reactie te plaatsen om een issue te heropenen liep spaak: na zeven dagen worden gesloten issues door de workflow vergrendeld.
Anthropic zegt nog geen noodremmen te hebben die de goedkeuringseisen aanscherpen als de beoordelingscijfers verslechteren. Het product Code Review is algemeen beschikbaar voor de Team- en Enterprise-abonnementen. De GitHub Action voor beveiligingsbeoordeling is open source, maar in de README staat dat deze niet bestand is gemaakt tegen promptinjectie en alleen vertrouwde pullrequests mag beoordelen.
Waarom het ertoe doet
Voor teams die AI-gestuurde codebeoordeling overwegen, laat de aanpak van Anthropic zien dat wijzigingen met een laag risico zonder menselijke goedkeuring kunnen worden samengevoegd, terwijl wijzigingen met een gemiddeld risico nog steeds door een persoon moeten worden beoordeeld. Het bedrijf zegt geen noodremmen te hebben die de goedkeuringseisen aanscherpen als de beoordelingscijfers verslechteren. Het bericht maakt dus niet duidelijk hoe het proces zou reageren als de beveiligingen tekortschieten.
