Slik driver Anthropic en AI-native ingeniørorganisasjon

Kort fortalt

Da Fiona Fung kom til Anthropic for å lede ingeniørarbeidet bak Claude Code, var det første hun merket ikke bare at folk skrev kode raskere. Det var at gamle arbeidsmåter begynte å stå i veien.

Foredraget hennes på Anthropics utviklerkonferanse Code with Claude handler om hva som "stille sluttet å fungere" da selve kodingen ikke lenger var den dyreste delen av jobben. Dette er ikke en ferdig oppskrift, men en nyttig sjekkliste for team som fortsatt organiserer seg som om koding er den store flaskehalsen.

---

Flaskehalsen som flyttet seg

I mange år har programvareutvikling vært organisert rundt én begrensning: utviklerkapasitet. Altså hvor mye kode et team faktisk klarer å skrive.

Det forklarer mye av måten bransjen jobber på: waterfall, agile, designdokumenter før store kodeendringer, spørsmål om hvem som "eier" hvilken kode, og faste tommelfingerregler for hvor mange utviklere én leder kan ha ansvar for. Hele systemet ble bygget rundt at det var dyrt å skrive kode.

Det er ikke lenger like sant, sier Fung. På Claude Code-teamet er koding sjelden det som tar mest tid. Volumet har økt kraftig. Folk produserer ikke bare litt mer kode, de produserer mye mer.

Når flaskehalsen forsvinner ett sted, dukker den opp et annet. Hos Anthropic har de nye flaskehalsene blitt verifisering, kodegjennomgang, sikkerhet, juridiske vurderinger, produktvurderinger og vedlikehold av en stadig større kodebase.

Fung sammenligner dette med tidligere skifter i programvarehistorien. Da hun jobbet med Visual Studio 2005 hos Microsoft, måtte programvaren være ferdig i tide til å bli brent på CD-ROM, pakket i esker og sendt til butikker. Da programvare etter hvert kunne distribueres over nettet, endret hele leveransemodellen seg.

Hun ser AI-skiftet på samme måte. Det handler ikke bare om et nytt verktøy, men om at kostnadene i utviklingsarbeidet flytter seg.

Det som stille slutter å fungere

Et av Fungs viktigste poenger er at prosesser sjelden forsvinner av seg selv. De slutter bare stille å fungere.

Team legger ofte nye regler, møter og rutiner oppå de gamle. Etter hvert kan man ende med så mange overlappende frister, rapporter og godkjenningsløp at selve systemet blir tyngre enn problemet det skulle løse.

Derfor stiller hun stadig det samme spørsmålet til Claude Code-teamet: Hjelper denne prosessen oss fortsatt, eller følger vi den bare av gammel vane?

Normene som måtte skrives om

Planlegging

Fung beskriver måten de planlegger på som JIT-planlegging, altså "just-in-time". Poenget er å lage akkurat nok plan, akkurat når den trengs.

Da hun begynte, laget teamet et veikart for seks måneder. Etter tre måneder var verden endret nok til at planen allerede føltes gammel. Nå planlegger de kortere, oftere og mer praktisk. I stedet for lange diskusjoner på papir bygger de prototyper.

Tekniske debatter

Tidligere ville mange tekniske diskusjoner endt foran en tavle. Fung forteller at hun nesten gjorde det samme med Boris Cherny da de diskuterte hvordan en API burde ryddes opp i.

Så stoppet hun seg selv. I stedet ba hun Claude lage tre ulike pull requests, altså tre konkrete forslag til kodeendringer. Da kunne teamet ikke bare diskutere teorien, men se nøyaktig hvordan hver løsning påvirket resten av kodebasen.

Når det er billig å bygge, blir det dyrt å krangle.

Kodegjennomgang

Claude brukes tungt i kodegjennomgang. Den kan ta seg av stil, linting, enkle tilbakemeldinger, småfeil og forslag til tester.

Men mennesker er fortsatt nødvendige der vurderingene krever ansvar, ekspertise eller smak. Det gjelder for eksempel juridiske vurderinger, sikkerhetskritisk kode og produktdetaljer.

Fung forteller om da hun ba Claude lage en liten julevariant av terminalfiguren. Resultatet skulle ligne en snømann, men designpartneren hennes mente den så mer ut som Mr. Peanut. Slike vurderinger, om noe faktisk føles riktig for brukeren, vil hun fortsatt ha mennesker inn i.

Ansettelse og ledelse

Fung ønsket en flat organisasjon. Hun ville også at ledere på Claude Code-teamet først skulle jobbe som individuelle bidragsytere, altså være tett på koden før de fikk lederansvar.

Rekruttererne var skeptiske. De mente mange ledere ikke ville være interessert i en jobb der de først måtte skrive kode. Fung mente det var greit å finne ut av tidlig.

For henne handler dette om dogfooding: å bruke sitt eget produkt i praksis. Hvis lederne ikke kjenner produktet og kodebasen fra innsiden, mister de viktig forståelse.

Teamsammensetning

Når AI tar mer av det rene kodevolumet, blir ikke rå produksjonskapasitet like viktig som før.

Fung ser særlig etter to typer utviklere: kreative byggere med produktsans, og folk med dyp systemkompetanse. Den første gruppen ser problemer og bygger raske løsninger. Den andre trengs for de vanskelige delene, som infrastruktur og distribuerte systemer.

Samtidig blir rollene mer flytende. Designere og produktsjefer skriver mer kode. Utviklere bruker Claude til oppgaver som tidligere hørte til design, innhold eller produktarbeid.

Sannhetskilde

På Claude Code-teamet er koden den viktigste sannhetskilden. Ikke et eget dokument som raskt kan bli utdatert.

Når Fung skal svare på kundespørsmål, åpner hun ofte Claude Code mot den lokale kodebasen og spør direkte. Hvis et team har gode spesifikasjoner, bør de ligge i samme repository som koden, slik at Claude kan bruke dem til å sjekke om koden faktisk gjør det den skal.

Prinsippene de lever etter

Teamet har noen tydelige prinsipper.

Alle bruker Claude Code, ikke bare utviklerne, men også produktsjefer, designere og andre samarbeidspartnere.

De prøver å "Claudify" alt som kan automatiseres. Det betyr å spørre: Kan Claude hjelpe oss med dette? Kan denne manuelle rutinen gjøres enklere, raskere eller mer automatisk?

Og de har eksplisitt lov til å drepe gamle prosesser. Fung forteller om et tidligere ukentlig statusmøte med 50 personer, der alle satt på laptopen sin helt til det var deres tur til å rapportere. Da hun spurte hvorfor møtet egentlig fantes, ble det raskt klart at det kunne fjernes.

Hva de måler

Fung deler ikke konkrete tall, men peker på tre målinger team kan følge med på.

Den første er onboarding-tid: hvor raskt nye utviklere, designere eller produktsjefer begynner å bidra meningsfullt.

Den andre er PR-syklustid: hvor lang tid en pull request bruker fra start til den blir slått sammen med hovedkoden. Hvis denne tiden ikke går ned, kan flaskehalsen ligge i testene, infrastrukturen eller godkjenningsløpet.

Den tredje er andelen Claude-assisterte commits. På hennes team er dette i praksis 100 prosent.

Men hun advarer mot å gjøre AI-generert kode til et mål i seg selv. Det viktige er ikke hvor mange prosent av koden som er skrevet med AI. Det viktige er om produktet blir bedre, mer stabilt og mer nyttig for brukerne.

Det hun fortsatt ikke vet

Fung avslutter med spørsmål hun fortsatt ikke har sikre svar på.

Gir det fortsatt mening å ha separate iOS- og Android-team når utviklere lettere kan jobbe på tvers av plattformer?

Hvor langt bør man gå med automatisert kodegjennomgang?

Og hvordan sørger man for at alle føler seg produktive når rollene flyter mer over i hverandre enn før?

Hva du kan ta med deg

Hovedrådet hennes er enkelt: revurder.

Velg den mest støyende arbeidsflyten i teamet ditt. Det møtet, den rapporten eller den rutinen alle misliker. Spør om den fortsatt tjener formålet sitt.

Hvis svaret er nei, har du to valg: automatiser den, eller fjern den.

Foredraget handler ikke egentlig om at AI gjør koding billigere. Det handler om hva som skjer etterpå. Når kodingen går raskere, må tid, ansvar og oppmerksomhet fordeles på nytt. Hvis ikke blir de bare spist opp av gamle prosesser som for lengst har sluttet å fungere.

---

Ordliste

---

Kilder og ressurser