Claude åpnet 388 pull requests på Anthropics apper, 180 ble merget

I en Slack-kanal som heter proj-claude-maintains-apps går Claude løs på Anthropics egne apper hver dag. Kanalen er arbeidsflaten for et eksperiment Boris Cherny, Anthropic-ingeniøren som lagde Claude Code, beskrev i et LinkedIn-innlegg. Rutinene kjøres via verktøyet Tag, på tvers av iOS, Android, desktop, web, CLI og Agent SDK, skriver The Decoder.

The Decoder lister et titalls navngitte rutiner. En crash fuzzer åpner appen i en simulator og trykker seg tilfeldig rundt til noe kræsjer, finner rotårsaken og skriver fiksen. En dup unifier leter etter abstraksjoner som ligner på hverandre uten å være helt like, og foreslår å slå dem sammen. En abstraction police retter lagbrudd i arkitekturen, og en flaky-test fixer tar de ustabile CI-testene. Mest interessant er fjerneren av død kode: i stedet for å slette kode den bare mistenker er unådd, legger den inn logging og sjekker dagen etter om koden faktisk aldri kjøres.

Over de første ukene åpnet rutinene 388 pull requests på tvers av Anthropics repoer. 180 gikk gjennom både Claude Code-review og menneskelig gjennomgang og ble merget. Det gir en merge-rate på rundt 46 prosent, og 208 forslag som ikke holdt mål. Cherny kaller resultatene «overraskende positive» og beskriver eksperimentet som «tidlige livstegn» for at autonomt vedlikehold kan fungere, ikke som en ferdig arbeidsflyt. Anthropic ser nå på hvordan selve merge-steget kan gå raskere for denne typen mekaniske endringer.

Ifølge Cherny treffer Claude stort sett riktig på første forsøk. Når den bommer, justerer teamet rutinen slik at modellen gjør det bedre dagen etter, og den tuningen tar noen ganger flere dager. Cherny delte flere av promptene sine i Slack, og det er lite prompt-konstruksjon i dem. Han ber Claude i klartekst om å starte daglige rutiner for crash fuzzing på iOS, Android og desktop, bruke de ekte appene uten mocks, utløse kræsj og opprette pull requests med fikser.

Fellesnevneren for rutinene er at de alle har en billig fasit. En kræsj er en kræsj. Død kode kan bekreftes med logging. Duplisert abstraksjon er strukturelt synlig i koden. Ingen av dem ber modellen om å ta et smaksvalg, og det skiller dem fra agent-oppgaver der du må lese hele diffen for å vite om svaret er brukbart. Det er også derfor 46 prosent er et tall du kan jobbe med: de 208 avviste PR-ene kostet reviewtid, ikke produksjonsfeil.

For deg som bygger alene eller i et lite team er poenget at oppsettet ikke krever noe eget rammeverk. Det ligger i klartekst-instruksjoner, en kanal å kjøre dem fra, og en review-terskel som fanger de drøyt halvparten som ikke holder mål.

Hva bør du gjøre?

1. Begynn med rutinen som har tydeligst fasit. Fjerning av død kode og fiksing av ustabile tester kan verifiseres maskinelt, så du ser raskt om oppsettet er til å stole på.
2. Kopier logg-først-trikset: la rutinen legge inn logging i kode den tror er død, og slett den først dagen etter, når loggen bekrefter at den aldri kjøres.
3. Regn med å justere prompten daglig. Ifølge The Decoder bruker teamet noen dager på å tune en rutine som bommer, i stedet for å skrive den ferdig i første forsøk.