Anthropic uppger att Claude Code nu skriver omkring 90 % av sin egen kod och att teamet ändrar hur arbetet granskas. I ett inlägg beskriver Addy Osmani, Morgan Westlee Lunt och Qing Wang teamets mål: de flesta pull requests ska kunna slås samman med högst en människa inblandad. Det kan vara personen som skrev ändringen, och målet är att detta inte ska leda till fler återställningar eller incidenter.
Teamet säger att granskare inte behöver ha en fullständig mental bild av Claude Code. I stället ber de Claude förklara den del av kodbasen som de behöver förstå. Tillvägagångssättet kritiserades i en diskussion på Hacker News: kommentatorer undrade om ett beroende av AI-förklaringar innebär att ingen längre kan felsöka ett fel när modellens förståelse är felaktig.
Så fungerar granskningsnivåerna
En klassificerare tilldelar varje ändring en risknivå utifrån själva ändringen, inte vem som har gjort den. Ändringar med låg risk omfattar dokumentation, text och tillägg bakom en funktionsflagga. De kan godkännas utan mänskligt godkännande. Ändringar med medelhög risk, bland annat arbete med cachelagring, den automatiska uppdateraren och systemprompter, kräver en person. En agents godkännande räknas inte som ett mänskligt godkännande, men personen som bad om ändringen kan räknas som den nödvändiga granskaren.
Granskningsprocessen har också en egen felkälla: agenter agerar på återkoppling som en människa kanske skulle ignorera. Anthropic beskriver en pull request som gick igenom mer än 50 gransknings- och korrigeringsomgångar under natten innan upphovspersonen avbröt processen. Teamet säger att det begränsade antalet omgångar efter att ha upptäckt att fler granskningar bara gjorde resultatet sämre. Det upptäckte också att omkring 59 % av koden som flaggades i senare omgångar redan fanns där när granskaren tittade på den första gången.
Vad som fortfarande är osäkert
Ett annat exempel från Claude Codes offentliga kodarkiv visar begränsningarna hos AI-genererade förklaringar. I augusti hävdade ett Claude-genererat svar att ärenden hade stängts på grund av inaktivitet när de saknade information som behövdes för att återskapa ett problem. Enligt kodarkivets regler kan ärenden dock stängas efter att ha markerats som inaktuella i 14 dagar och därefter legat ytterligare 14 dagar, med undantag för ärenden med minst 10 uppröster. En utvecklare räknade till över 6 000 ärenden som märkts med att de innehöll reproduktionssteg men ändå hade stängts som inaktiva. Förslagets råd att kommentera för att öppna ett ärende igen stötte också på ett arbetsflöde där stängda ärenden låses efter sju dagar.
Anthropic säger att företaget ännu inte har några nödbromsar som skärper kraven på godkännande om granskningsmåtten försämras. Produkten Code Review är allmänt tillgänglig för Team- och Enterprise-abonnemang. GitHub Action för säkerhetsgranskning är öppen källkod, men i dess README står det att den inte är skyddad mot promptinjektion och bara bör användas för att granska betrodda pull requests.
Varför det spelar roll
För team som överväger AI-driven kodgranskning visar Anthropics process att ändringar med låg risk kan slås samman utan mänskligt godkännande, medan ändringar med medelhög risk fortfarande kräver en person. Företaget säger att det inte har byggt in några nödbromsar som skärper kraven på godkännande när granskningsmåtten försämras. Inlägget visar därför inte hur processen skulle reagera om skyddsåtgärderna började fallera.
