La oss ta en titt på historien om Claude Codes fødsel, hovedsakelig hentet fra et intervju med teknologibloggeren Gergely Orosz om et kjernemedlem av Claude Code. Claude Code er virkelig bemerkelsesverdig, med en årlig inntekt på 500 millioner dollar og en ti ganger økning i brukervolum på tre måneder, og er nå det foretrukne Coding Agent-verktøyet for mange programmerere. Dette verktøyet startet som en liten kommandolinjeleke som fortalte deg «hvilken sang du hører på akkurat nå.» 🧵

Gergely Orosz intervjuet tre sentrale medlemmer av Claude Code: • Boris Cherny, grunnlegger og ingeniør (17 års erfaring, tidligere Meta Chief Engineer) • Ingeniør 2 Sid Bidasaria (forfatter av Subagents-funksjonen) • og Cat Wu, produktsjef. De snakket om hvordan Claude Code gikk fra prototype til produkt, hvilke tekniske valg de tok, og hvordan det lille teamet på et dusin personer klarte å publisere 5 PR-er per dag. Dette er sannsynligvis det nærmeste eksempelet på et «AI-først ingeniørteam» akkurat nå. De bruker AI til å skrive kode, skrive tester, gjennomføre kodegjennomganger, feilsøke, og til og med bruke Claude Code til å utvikle selve Claude Code. 90 % av koden er skrevet av seg selv. Det jeg ønsker å gjøre, er å finne ut de mest interessante delene av dette intervjuet, snakke om hvordan dette teamet fungerer, hva som kan læres, og hva som bestemmes av deres spesielle forhold og ikke kan kopieres. Følgende er delt inn i 7 noveller, som hver kan leses hver for seg, og er satt sammen til et komplett bilde.

[1] Hvordan en lytteenhet kan bli et produkt med en årlig inntekt på 500 millioner dollar I september 2024 begynte Boris Cherny nettopp i Anthropic og skrev en kommandolinjeleke da han ikke hadde noe å gjøre. Hva kan denne tingen gjøre? Den bruker AppleScript for å fortelle deg hvilken sang du lytter til og endrer sangen etter kommandoene dine. Så enkelt er det. Boris selv kommenterte: «Ganske kul demo, men ikke interessant. ”

Den virkelige vendingen kom etter at han var ferdig med samtalen med kollegaen Cat Wu. Cat studerte datamaskinmulighetene til AI-agenten, og mens de pratet, fikk Boris en idé: hva om vi gir dette kommandolinjeverktøyet flere tillatelser? For eksempel, la den kunne lese og skrive filer og utføre kommandoer?

Han prøvde. Så kommer øyeblikket for å være vitne til mirakelet. Boris la det oppgraderte verktøyet inn i Anthropics kodebase og stilte noen spørsmål. Claude begynte å utforske filsystemet på egen hånd—leste en fil, så importsetningen inni, og så den refererte filen, gravde lag for lag til han fant svaret. "Det rystet meg," husker Boris, "og jeg hadde aldri brukt et verktøy som dette. ”

Innen AI finnes det et begrep kalt «produktoverheng», som oversettes til «produktoverheng». Dette betyr at modellen faktisk har en viss kapasitet, men den eksisterende produktformen frigjør ikke denne kapasiteten. Det Boris oppdaget var et enormt «produktoverheng» som Claude kunne ha laget for lenge siden, men ingen hadde bygget et skall for det.

Boris begynte å jobbe med verktøyet hver dag og delte det deretter med flere kolleger. To måneder senere, i november, slapp de en versjon. Dataene er overdrevet: på første dag er 20 % av ingeniørene i bruk; Dag 5, 50%.

På dette tidspunktet oppstår en interessant debatt: bør den slippes ut til omverdenen? Årsaken til motstanden er veldig reell: hvis dette virkelig er så sterkt som vi tror, ville det ikke vært bra å beholde det som et «hemmelig våpen»? Hvorfor gi opp konkurransefortrinn? Til slutt valgte Anthropic å publisere. Logikken er denne: Anthropics kjerneoppgave er å studere modellsikkerhet, og den beste måten å studere sikkerhet på er å faktisk bruke disse verktøyene. Nå som Claude Code internt er validert for mye bruk, vil lanseringen gi mer innsikt i modellens kapasiteter og sikkerhet.

I mai 2025 ble Claude Code offisielt offentliggjort. Tre måneder senere har bruken økt ti ganger og den årlige inntekten overstiger 500 millioner dollar. Interessant nok var Boris opprinnelig ment for programmerere – derav navnet "Claude Code". Men en dag gikk han forbi dataforskerens arbeidsstasjon og fant Claude Code kjørende på den andre skjermen. "Hvorfor bruker du dette?" "Jeg ba den hjelpe meg med å skrive forespørsler og visualisere." Nå har Anthropics dataforskere én tilgjengelig, og noen driver flere samtidig. En lyttedings, fordi den fikk noen flere tillatelser, ble et produkt verdt hundrevis av millioner dollar. Dette er sannsynligvis det beste beviset på «produktoverheng», modellkapasiteten er alltid der, og venter på at noen skal slippe den.

[2] 90 % av koden er skrevet av en selv – Claude Codes tekniske utvelgelsesfilosofi Claude Code har 90 % av sin egen kode. Høres ut som en gimmick, men det er faktisk takket være deres tekniske beslutningslogikk. La oss først se på teknologistakken: TypeScript skriver hoveddelen, React bruker Ink-rammeverket som terminalgrensesnitt, Metas åpne kildekode Yoga står for layoutsystemet, og Bun har ansvar for bygging og pakking. Hvorfor velge disse teknologistakkene? Fordi de er «innenfor fordelingen». "Om distribusjon" er et begrep innen AI-feltet. Dette betyr at modellen har sett mye av denne typen kode og er god til å håndtere dem. TypeScript og React er akkurat der Claude er sterk. Hvis du velger et upopulært rammeverk, må modellen «lære», og effekten vil bli kompromittert. Dette valget fører til en fantastisk syklus: skriv Claude Code med teknologistakken Claude er god på, og så skriv mer Claude Code med Claude Code. 90 % skriver om deg selv, det var slik det skjedde. Deres valg på arkitektonisk nivå er like konsise. Claude Code kjører lokalt. Det finnes ingen Docker-containere, ingen sky-sandkasse, bare les og skriv filer og kjør kommandoer direkte på datamaskinen din.

Når det gjelder hvorfor det er designet slik? Boris svarer: «Hver gang vi tar en designbeslutning, velger vi nesten alltid den enkleste løsningen. Å kjøre lokalt er det enkleste svaret. ” Denne enkelheten gjelder hele produktfilosofien: skriv så lite forretnings-logikk som mulig og la modellen være hovedpersonen. "Det kan høres litt rart ut," sa Boris, "men vi vil at brukerne skal føle modellen så 'autentisk' som mulig. Mange AI-produkter legger til en rekke stillas—ekstra UI-elementer, tilgjengelighetsfunksjoner—og resultatet er at modellen blir begrenset. Det vi ønsker å gjøre er å gjøre brukergrensesnittet så slankt som mulig. ” For å gjøre det enkelt, hver gang Claude slipper en ny modell, strømlinjeformer de koden mye. For eksempel, da Claude 4.0 ble lansert, fjernet de omtrent halvparten av systempromptene fordi den nye modellen ikke lenger trengte disse «krykkene». Antallet verktøy blir også strømlinjeformet – slett hvis du kan, slå sammen hvis du kan. Hele Claude Code-arkitekturen kan oppsummeres i tre ting: definere brukergrensesnittet og eksponere grensesnittet for modellmodifikasjonen, eksponere verktøyene modellen skal kalle, og deretter flashe til side. Selvfølgelig betyr ikke enkelhet at det ikke finnes kompliserte deler. Tillatelsessystemet er unntaket. Tross alt er det risikabelt å la AI utføre kommandoer på datamaskinen din. Claude Codes løsning er å spørre deg før du utfører den: Vil du godkjenne denne operasjonen? Du kan bare godkjenne denne gangen, godkjenne det senere, eller avvise det. Tillatelsessystemet støtter flerlags konfigurasjon – per prosjekt, per bruker, per selskap. Teams kan dele profiler for å hviteliste ofte brukte sikkerhetskommandoer. Prinsippene bak dette tillatelsesdesignet er som følger: Hvis du starter Claude Code, skal det ikke endre noe uten ditt samtykke. Men samtidig er det også nødvendig å gi brukerne muligheten til å «delegere» – i tilfelle din tillit kan du hoppe over bekreftelseslenken. Enkelt, men ikke rudimentært. Tilbakeholdenhet, men ikke mangel på funksjon.

[3] 20 prototyper på to dager – hvordan ser produktiterasjon ut i AI-æraen Tidligere, når jeg laget produktprototyper, kunne jeg lage to på to dager, noe som ble ansett som effektivt. Boris laget 20 på to dager. Dette er ikke en overdrivelse, men en sann oversikt over hans utvikling av Claude Codes todo-listefunksjon. Han delte til og med prompts og skjermbilder av hvert steg. La oss se på hvordan disse 20 arketypene itererer. I den første versjonen ønsket han at gjøremålslisten skulle vises under det siste verktøykallet. Prompten er kort: «I stedet for at todo vises med input, vis en fast todo-liste over inputboksen, med tittelen '/todo (1 of 3)' nedtonet.» Etter å ha sett på effekten, var jeg ikke særlig fornøyd. I den andre versjonen vises det inline ved hver ToDo-oppdatering. Prompt: "I stedet for å vise en gjøremålsliste, gjengi verktøynavnet i en fet tittel når modellen begynner å behandle en oppgave." Hold fremdriftsvisningen som 'steg 2 av 4'. ” Fortsatt ikke riktig. I tredje og fjerde utgave prøvde han å lage en «interaktiv pille» – en liten firkant nederst på skjermen som du kan klikke på for å se fremgangen. "Legg til en todo-pille under tekstboksen, lik en bakgrunnsoppgave, som viser 'todo: 1 av 3'." Så: «Gjør denne pillen interaktiv, som en bakgrunnsoppdrag-pille.» ” Det er litt interessant, men ikke godt nok. I femte og sjette utgave ombestemte han seg: lag en "skuff" som kan skyves ut fra høyre. "Angr de tidligere pillene og titlene, og vis i stedet gjøremålslisten på høyre side av inntastingsboksen, sentrert vertikalt, adskilt av en grå skillevegg." "Den er litt hoppete, kan du lage den til en skuffeanimasjon?" Det ser kult ut, men praktisk nytte er tvilsom. I den syvende og niende utgaven flyttet han gjøremålslisten over inndataboksen og eksperimenterte med ulike avslutnings- og header-stiler. "Hvis det er mer enn 5, viser det '... og 4 til'»», «Legg til en grå 'Todo:'-tittel». Svaret er å komme nærmere og nærmere. I den tiende og tjuende utgaven begynte han å finne ut hvordan han kunne kombinere gjøremålslister med lasteanimasjoner. Den endelige løsningen er å plassere fremdriftsinformasjon ved siden av spinneren (lastindikatoren) for å maksimere synligheten. Etter lanseringen rapporterte brukere at de ønsket å se hele gjøremålslisten. Så en ny iterasjon legges til: trykk Ctrl+T for å utvide alle stegene. Dette er versjonen som nå er tilgjengelig på nett.

Gjennom hele prosessen var Boris' prompts overraskende korte—for det meste én eller to setninger. Men hver versjon er en prototype som faktisk kan kjøres, ikke en statisk tegning, ikke en PPT. Han kan virkelig teste og verifisere denne funksjonen for å kjenne om den fungerer bra. Den tradisjonelle produktutviklingsprosessen er: idé→ diskusjon → å tegne trådrammer → utføre høyoppløselig design → utvikling → testing → gå live. Hvert steg tar tid, og hvert steg kan sette seg fast. Nå blir flyten: Idé → ensetningsprompt → kjørbar prototype → Hvis noe ikke føles riktig, gjør det igjen. Dette krever faktisk at utviklere endrer tankesett for å tilpasse seg denne utviklingsprosessen. Tidligere var prototypenes rolle å «verifisere ideer» – fordi kostnadene ved prototyping var høye, og man måtte tenke nøye gjennom før man gjorde det. Nå har prototyper blitt «utforske muligheter» – fordi kostnaden ved å lage prototyper er lav, kan du lage dem først og så kaste dem. Boris sa at når han bruker Claude Code, hopper han ofte over fasen med å tegne blåkopien og lager bare en løpende versjon, som er mer intuitiv enn noe annet. Den daglige rytmen til Claude Code-teamet er som følger: hver ingeniør utfører omtrent 5 PR-er per dag, 60-100 interne utgivelser per dag, og 1 ekstern utgivelse per dag. 5 PR-er om dagen, noe som er utenkelig i de fleste selskaper. Uber er i den mest intense omstruktureringsperioden, og det er ikke dårlig å kunne presse en middels stor PR om dagen. Når verktøyene endres, endres rytmen, og tankegangen må endres.

[4] Redesignet kommandolinjeterminalen med integrert AI Kommandolinjeterminaler har eksistert i flere tiår, hvorfor må de redesignes nå? For før LLM-er fokuserte terminaler ikke så mye på interaktive opplevelser. Den tradisjonelle kommandolinjen er et spørsmål og svar: du taster inn en kommando, den returnerer et resultat, og så er du ferdig. Ingen dialog, ingen kontekst, ingen tilbakemelding mens jeg ventet. Du stirrer på markøren som blinker og vet ikke hva som skjer i bakgrunnen. Claude Code var det første produktet som virkelig trengte å tenke på «terminal UX». De la til noen små detaljer som så ubemerkelsesverdige ut, men som føltes helt annerledes når de ble brukt. Først: Kontekstuelle lasteprompter. Når modellen tenker, kan skjermen generere relevante prompts basert på den nåværende oppgavevisningen: for eksempel «lese kodestrukturen din» eller «tenke på en løsning». Det er en liten detalj, men det gir verktøyet en «personlighet». Du vil føle at den jobber hardt og ikke sitter fast. Boris sier at sist han så denne typen hyggelig liten interaksjon var da Slack var en nybegynner i onboarding-prosessen. For det andre: Undervisningstips mens man venter. Når Claude utfører en lang oppgave, vil bunnen av skjermen vise en rotasjon av tips, som «Du kan trykke på Esc for å avbryte den nåværende oppgaven» eller «Prøv /hjelp for å se alle kommandoene». Kommandolinjen brukes til å lære kommandolinjen, noe som er enkelt og smart. Den tredje historien er enda mer spennende: Markdown-rendereren. Dagen før lanseringen klaget noen ingeniører på at nestede lister var stygge og at avsnittsavstanden ikke var riktig. Problemet ligger med Markdown-rendereren. Boris prøvde alle rendererne på markedet, og ingen av dem så bra ut i terminalen. Så han brukte en dag på å bruke Claude Code til å skrive en Markdown-parser og renderer fra bunnen av. Ja, dagen før utgivelsen. Ja, skriv fra bunnen av. Ja, ved å bruke Claude Code selv. Som et resultat ser denne «hastede» rendereren bedre ut enn alle ferdiglagde løsninger. De ga den ut direkte. Boris mener at ingen annen terminal nå har samme kvalitet på Markdown-rendering. Denne historien illustrerer én ting: når du har et godt nok AI-programmeringsverktøy, faller kostnaden ved å «bygge dine egne hjul» betydelig. Kompromisset med «bare bruk det» kan nå bli «så gjør en bedre». Den eldgamle grensesnittformen til kommandolinjeterminalen blir gjenfødt med tillegg av LLM-er. Terminalen er fortsatt den samme terminalen, men på grunn av tillegget av AI må vi tenke seriøst på hvordan vi kan få folk til å ha en bedre samtale med AI-en i terminalen.

[5] AI gjennomsyrer hver lenke – et "omfattende AI"-eksperiment utført av et ingeniørteam Anthropics ingeniørteam er sannsynligvis en av de mest ekstreme bruksområdene for AI-verktøy akkurat nå. Det handler ikke bare om å skrive kode, det handler om alle aspekter av prosjektet. Kodegjennomgang: Den første gjennomgangen av alle PR-er gjøres av Claude Code, og den andre av ingeniører. Boris sier at Claude Code kan finne mange problemer på første forsøk. Denne funksjonen ble opprinnelig kun brukt internt, men senere ble den offentlig gjort slik at alle kunne bruke Claude Code til sikkerhetsgjennomgang. Skriv tester: Claude Codes testpakke er nesten utelukkende skrevet av Claude Code. "Tidligere, hvis noen tok opp en PR og ikke skrev en test, nølte jeg med å si noe — det føltes som et plukk-og-punkt," sa Boris. Men nå med Claude er det å skrive en prøve et promptord, og det finnes ingen unnskyldning for ikke å skrive den. ” Hendelsesrespons: Oncalls ingeniører ber Claude Code om å hjelpe til med å analysere rotårsaken (den egentlige årsaken til problemet). Den henter relevante diskusjoner fra Slack, feillogger fra Sentry, data fra ulike overvåkingssystemer, og analyserer dem syntetisk. Boris sier at Claude Code finner rotårsaken raskere enn en person i noen scenarioer. GitHub-problemtriage: Hver gang et nytt problem kommer inn, gjør Claude Code først en analyse, og deretter spør ingeniøren om det kan implementeres. Boris sier at omtrent 20 % til 40 % av gangene kan det gjøres første gang. Diagrammer og spørringer: Produktdata ligger i BigQuery, og nesten alle spørringer og visualiseringer genereres i Claude Code. Ingeniører lar den til og med sende ut ASCII-diagrammer direkte.

Det som overrasket meg mest, var gjenoppblomstringen av TDD (testdrevet utvikling). TDD er et gammelt konsept: skriv tester først, så skriv koden som består testene. Det er bra i teorien – det tvinger deg til å tenke på hva du vil først. Men i praksis mener de fleste at det er for tregt og tungvint, så denne metoden har gradvis blitt marginalisert de siste ti årene. Men Boris sa at etter å ha brukt Claude Code, gjorde han mye TDD: "Jeg begynner med å be modellen skrive en test og fortelle den at testen vil stryke nå, ikke prøv å få den til å bestå. Deretter ba jeg den skrive kode for å implementere funksjonen, og la testen bestå, men ikke endre selve testen. ” "Når en modell har et klart mål å iterere på—som en enhetstest eller en mock—presterer den veldig bra." Han nevnte spesifikt at Claude 4.0 er den første modellserien som lar modellene skrive de fleste testene. Tidligere versjoner kunne skrive en del, men krevde mye menneskelig inngripen. Det finnes også et nytt konsept: multi-kladering. Dette betyr å kjøre flere instanser av Claude Code samtidig, slik at de kan jobbe med ulike oppgaver parallelt. Sid sier at han ofte gjør dette – starter noen agenter under møter og kommer tilbake senere for å se resultatene. Anthropic fant at 25 % av Max-abonnentene (premium-brukere som koster 100–200 dollar i måneden) multi-clauderer hver dag. Dette er en interessant endring. Programmering har alltid vært en «enkelttrådet» aktivitet: du kan bare gjøre én ting om gangen, og bytter bare oppgaver når koden blir gjennomgått eller distribuert. Men nå er «parallell programmering» mulig – du kan utvikle flere ting samtidig. Selvfølgelig er det mange ukjente faktorer her: er parallelt arbeid virkelig mer effektivt, eller føles det bare mer effektivt? Hvilke typer oppgaver egner seg for parallellisme? Vil det bli et problem hvis hver agent får mindre oppmerksomhet? Disse spørsmålene er ennå ikke besvart. Men vi har et nytt verktøy å eksperimentere med. Til slutt, la oss snakke om en sak. Et selskap skulle gjøre en rammeverksmigrering, og det ble anslått at det ville ta to ingeniørår – to år for én ingeniør, eller to og en halv måned for ti ingeniører. De brukte Claude Code, og en ingeniør gjorde det på to uker. Boris sa at han tidligere var skeptisk til slike påstander, men de har hørt lignende historier altfor mange ganger.

[6] Tredagers hackathon – hvordan Subagents-funksjonen ble til Inspirasjonen til denne funksjonen i Subagents kommer fra et innlegg på Reddit. Noen sier at han åpnet fem Claude Code-instanser samtidig, satte forskjellige roller for hver instans, og deretter brukte filsystemet til å kommunisere med hverandre. Da Sid Bidasaria så dette innlegget, var hans første reaksjon: Dette gameplayet er kult, men brukerne burde ikke måtte kaste slik. Vi bør gjøre det til en innebygd funksjon i produktet. Det tilfeldigvis var at selskapet hadde en tre dager lang intern hackathon, og Sid bestemte seg for å bruke de tre dagene på det. På den første dagen tegnet teamet entusiastisk ut en rekke komplekse agenttopologier: meldingsbusskommunikasjon mellom agenter, asynkron modus, mange-til-mange-interaksjoner...... Bildet er vakkert tegnet og konseptet er avansert. Neste dag innså de at det ikke virket gjennomførbart å gjøre det. Problemet er ikke teknisk implementering – komplekse mønstre kan lages. Problemet er at brukerne ikke kan forstå det. Claude Codes brukergrensesnitt er en enkel terminal, hvordan lar du brukerne forstå disse komplekse agentkommunikasjonsmåtene i et så enkelt grensesnitt? De bestemte seg for å starte på nytt og vende tilbake til det grunnleggende spørsmålet: Hva er den enkleste formen en gjennomsnittlig utvikler kan bruke? De satte seg to begrensninger: For det første, ikke oppfinn noe nytt. Bruk kun funksjonene som Claude Code allerede har – "/"-kommandoen og .md-filene. For det andre, ikke kommuniser mellom agenter. Endre til et enkelt orkestreringsmønster: det finnes en masteragent som kan kalle barneagenten, og barneagenten returnerer resultatet etter å ha fullført oppgaven, og det er det. De snakket også med Anthropics forskningsteam. Forskere jobber med mønstre for flere agenter, men konklusjonen er at det fortsatt er uklart om komplekse agenttopologier faktisk fungerer. Dette gir dem mer selvtillit: siden selv forskerteamet sier at kompleksitet ikke nødvendigvis er bra, er det bedre å lage en enkel versjon. På slutten av den tredje dagen laget de en fungerende versjon. Brukere kan definere roller og kapasiteter for underagenter i .md-filer (f.eks. "front-end agents: using React 19 and Next.js"), Claude Code vil kalle dem når det er hensiktsmessig, eller brukeren kan utløse dem manuelt. Etter hackathonen, etter litt finpussing, er funksjonen aktiv. Nå kan du definere ulike eksklusive underagenter: back-end-agenter med ekspertise innen sikkerhetsrevisjon, front-end-agenter som er kjent med spesifikke rammeverk, og QA-agenter som spesialiserer seg på å skrive tester...... De kan jobbe parallelt i bakgrunnen, hver med sin egen rolle. Mange lag vil være motvillige til å omgjøre sine komplekse planer i hackathonen, tross alt bruker de en hel dag på å tegne og diskutere, og de har følelser. Å kunne innrømme at «denne veien fungerer ikke» og styrte den og starte på nytt krever mot og tro på «enkelhet». Enkelhet er ikke latskap. Det enkle er å finne formen brukeren virkelig kan bruke blant de utallige mulighetene.

[7] Hvordan vil ingeniørteamet være i fremtiden? Noen kan brukes som referanse, og noen kan ikke kopieres Boris sa: «Programmering er så gøy nå. Sist jeg følte det slik var da jeg skrev kode på en grafkalkulator for første gang på ungdomsskolen. Den magiske følelsen jeg ikke har opplevd på lenge, men som nå er tilbake. ” Sid føler det samme: «Det er to ting som begeistrer meg. Den ene er hastigheten vi slipper – noen ganger føles det for fort. Det andre er så mye eksperimentelt rom – selv om det forrige arbeidet var raskt, var det jeg gjorde mer rutinemessig, og å vite hva svaret var, var det bare gjennomføringen. Nå er det annerledes, modellen endres hver tredje måned, og vi må stadig tenke nytt om hvordan vi gjør ting. ” Disse følelsene er veldig ekte og smittsomme. Men før vi diskuterer «hvordan fremtiden for ingeniørteam vil se ut», la oss ikke glemme spesifisiteten til Anthropic. For det første er Anthropic et forskningslaboratorium, ikke et produktselskap. Kjerneoppdraget er å forske på AI-sikkerhet og kapasiteter, og produktet er middelet, ikke målet. Dette betyr at de har mye høyere toleranse for «rask eksperimentering» enn gjennomsnittsselskapet. For det andre er hovedproduktet deres selve Claude-modellen. Claude Code er bare et «skall» av modellen. Så «å slette kode for å la modellen gjøre mer» er et naturlig valg for dem, men for andre selskaper kan det bety å gi kjerneforretningslogikken til en svart boks. For det tredje har alle ansatte ubegrenset tilgang til Claude, inkludert den dyreste Opus-modellen. I de fleste selskaper er AI-abonnementsavgifter et budsjettpunkt som må kjempes for og som ikke kan brukes av alle. For det fjerde har teamet bare et dusin personer, og prosessen er minimal. De bruker knapt funksjonsflagg fordi de er «for trege». Dette er utenkelig i et produkt med stor brukerbase og høy feilmargin. Så å kopiere Claude Code-teamet direkte er ikke nødvendigvis realistisk for de fleste team. Men det er noen ting å lære av. Rask prototyping-tankegang: Selv om du ikke kan lage 10 prototyper om dagen, kan du gå fra «én annenhver uke» til «tre i uken»? Verktøyene har endret seg, og forventningene til «hvor raskt prototypen skal være» bør oppdateres. AI-assistert kodegjennomgang: La AI-en gjøre den første gjennomgangen og mennesket den andre. Denne prosessen er ikke avhengig av ubegrenset API-tilgang, som de fleste team kan prøve. Gjenopplivingen av TDD: Hvis det blir enkelt nok å skrive tester, er «ingen tid til å skrive tester» ikke lenger en unnskyldning. Dette kan være et rimelig inngangspunkt for å forbedre kodekvaliteten. Verdien av produktorienterte ingeniører forsterkes: Claude Code-teamet har ingen designere eller prosjektledere, bare noen få produktorienterte ingeniører. AI-verktøy har i stor grad utvidet hva dette «fullstack-talentet» kan gjøre.

Selvfølgelig finnes det noen ting som ikke kan erstattes av verktøy. Boris klarte å velge den beste av 20 arketyper fordi han var dømmende—han visste hva som «føltes riktig» og hva som bare «så bra ut». Denne smaken er resultatet av 17 års erfaring innen programvareutvikling, noe ikke KI kan gi. Teamet lagde en kompleks plan første dag, og neste dag kunne de nådeløst snu og starte på nytt, noe som også er en menneskelig vurdering. Å vite når man skal slette kode og når man skal beholde den er det samme, gjelder denne arkitektoniske intuisjonen. AI gjør gjennomføringen raskere, men det gjør det ikke lettere å «vite hva man skal gjøre». I stedet, fordi utførelseskostnadene har gått ned, har "hva man skal gjøre"-beslutningen blitt viktigere – du kan lage 20 versjoner raskt, men du må vite hvilken som er riktig. Hvordan vil programvareutvikling se ut om noen år? Ingen kan forutsi nøyaktig. Men Claude Code-teamet i dag kan være en slags generalprøve for morgendagen for mange lag – raskere iterasjoner, mindre «mursteinsflytting», mer dømmekraft og beslutningstaking. Verktøyene endrer seg. Det som forblir uendret, er at det fortsatt er menneskene som tar den endelige avgjørelsen.