Låt oss titta på historien om Claude Codes födelse, främst hämtad från en intervju med teknikbloggaren Gergely Orosz om en kärnmedlem i Claude Code. Claude Code är verkligen anmärkningsvärd, med en årlig omsättning på 500 miljoner dollar och en tiofaldig ökning av användarvolymen på tre månader, och är nu det föredragna Coding Agent-verktyget för många programmerare. Detta verktyg började som en liten kommandoradsleksak som berättade "vilken låt du lyssnar på just nu." 🧵

Gergely Orosz intervjuade tre kärnmedlemmar i Claude Code: • Boris Cherny, grundande ingenjör (17 års erfarenhet, tidigare Meta Chief Engineer) • Ingenjör 2 Sid Bidasaria (författare till Subagents-funktionen) • och Cat Wu, produktchef. De pratade om hur Claude Code gick från prototyp till produkt, vilka tekniska val de gjorde, och hur det lilla teamet på ett dussin personer kunde publicera 5 PR:er per dag. Detta är förmodligen det närmaste exemplet på ett "AI-först-ingenjörsteam" just nu. De använder AI för att skriva kod, skriva tester, göra kodgranskningar, felsöka och till och med använda Claude Code för att utveckla egen Claude Code. 90 % av koden är skriven av sig själv. Det jag vill göra är att reda ut de mest intressanta delarna av den här intervjun, prata om hur detta team fungerar, vad som kan läras och vad som bestäms av deras speciella förhållanden och inte kan kopieras. Följande är uppdelat i 7 noveller, var och en kan läsas självständigt, och är sammanfogade för att bilda en komplett bild.

[1] Hur en lyssningspryl kan bli en produkt med en årlig inkomst på 500 miljoner dollar I september 2024 började Boris Cherny precis på Anthropic och skrev en kommandoradsleksak när han inte hade något att göra. Vad kan den här saken göra? Den använder AppleScript för att tala om vilken låt du lyssnar på och ändrar låten enligt dina kommandon. Så enkelt är det. Boris själv kommenterade: "Ganska cool demo, men inte intressant. ”

Den verkliga vändningen kom efter att han pratat klart med sin kollega Cat Wu. Cat studerade AI-agentens datorkapacitet, och medan de pratade fick Boris en idé: tänk om vi ger detta kommandoradsverktyg fler behörigheter? Till exempel, låta den kunna läsa och skriva filer samt utföra kommandon?

Han försökte. Sedan kommer ögonblicket att bevittna miraklet. Boris slängde in det uppgraderade verktyget i Anthropics kodbas och ställde några frågor. Claude började utforska filsystemet på egen hand—läste en fil, såg importsatsen inuti, och sedan läste den refererade filen, grävde lager för lager tills han hittade svaret. "Det skakade mig," minns Boris, "och jag hade aldrig använt ett verktyg som det här. ”

Inom AI-området finns ett begrepp som kallas "produktöverhäng", vilket översätts till "produktöverhäng". Detta innebär att modellen faktiskt har en viss kapacitet, men den befintliga produktformen frigör inte denna kapacitet. Det Boris upptäckte var en enorm "produktöverhäng" som Claude kunde ha gjort för länge sedan, men ingen hade byggt ett skal för det.

Boris började arbeta med verktyget varje dag och delade det sedan med flera kollegor. Två månader senare, i november, släppte de en version. Datan är överdriven: första dagen är 20 % av ingenjörerna i bruk; Dag 5, 50%.

Vid denna tidpunkt uppstår en intressant debatt: bör den släppas till omvärlden? Anledningen till motståndet är mycket verklig: om detta verkligen är så starkt som vi tror, vore det inte bra att behålla det som ett "hemligt vapen"? Varför ge upp konkurrensfördel? Till slut valde Anthropic att publicera. Logiken är denna: Anthropics kärnuppdrag är att studera modellsäkerhet, och det bästa sättet att studera säkerhet är att faktiskt använda dessa verktyg. Nu när Claude Code internt har validerats för att användas flitigt, kommer lanseringen att ge mer insikt i modellens kapacitet och säkerhet.

I maj 2025 offentliggjordes Claude Code officiellt. Tre månader senare har användningen ökat tiofalt och den årliga omsättningen överstiger 500 miljoner dollar. Intressant nog var Boris ursprungligen avsedd för programmerare – därav namnet "Claude Code". Men en dag gick han förbi dataforskarens arbetsstation och fann Claude Code på den andra skärmen. "Varför använder du det här?" "Jag bad den hjälpa mig skriva frågor och visualisera." Nu har Anthropics dataforskare en till hands, och vissa driver flera samtidigt. En lyssningsapparat, eftersom den fick några fler behörigheter, blev en produkt värd hundratals miljoner dollar. Detta är förmodligen det bästa beviset på "produktöverhäng", modellkapaciteten finns alltid där och väntar på att någon ska släppa den.

[2] 90 % av koden skrivs av en själv – Claude Codes tekniska urvalsfilosofi Claude Code har 90 % av sin egen kod. Det låter som ett trick, men det är faktiskt tack vare deras tekniska beslutslogik. Låt oss först titta på teknikstacken: TypeScript skriver huvudkomponenten, React använder Ink-ramverket som terminalgränssnitt, Metas open source Yoga sköter layoutsystemet, och Bun ansvarar för byggande och paketering. Varför välja dessa teknologistackar? För att de är "inom fördelningen". "Om distribution" är en term inom AI-området. Detta innebär att modellen har sett mycket av denna typ av kod och är bra på att hantera dem. TypeScript och React är precis där Claude är stark. Om du väljer ett impopulärt ramverk måste modellen "lära sig", och effekten kommer att komprometteras. Detta val leder till en underbar cykel: skriv Claude Code med den teknikstack som Claude är bra på, och skriv sedan mer Claude Code med Claude Code. 90% skriver om dig själv, det är så det kom till. Deras val på arkitektonisk nivå är lika koncisa. Claude Code körs lokalt. Det finns inga Docker-containrar, ingen molnsandlåda, bara läs och skriv filer och utför kommandon direkt på din dator.

Varför är det designat så här? Boris svarar: "Varje gång vi fattar ett designbeslut väljer vi nästan alltid den enklaste lösningen. Att köra lokalt är det enklaste svaret. ” Denna enkelhet gäller hela produktfilosofin: skriv så lite affärslogik som möjligt och låt modellen vara huvudpersonen. "Det kan låta lite konstigt," sa Boris, "men vi vill att användarna ska känna modellen så 'autentiskt' som möjligt. Många AI-produkter lägger till en massa byggnadsställningar – ytterligare UI-element, tillgänglighetsfunktioner – och resultatet är att modellen är begränsad. Det vi vill göra är att göra användargränssnittet så slimmat som möjligt. ” För att hålla det enkelt, varje gång Claude släpper en ny modell, effektiviserar de koden mycket. Till exempel, när Claude 4.0 släpptes, tog de bort ungefär hälften av systempromptarna eftersom den nya modellen inte längre behövde dessa "kryckor". Antalet verktyg effektiviseras också – ta bort om du kan, slå ihop om du kan. Hela Claude Code-arkitekturen kan sammanfattas i tre saker: definiera UI:t och exponera gränssnittet för modellmodifieringen, exponera verktygen för modellen att kalla, och sedan flasha åt sidan. Självklart betyder enkelhet inte att det inte finns komplicerade delar. Behörighetssystemet är undantaget. Att låta AI utföra kommandon på din dator är ju riskabelt. Claude Codes lösning är att fråga dig innan du kör den: Vill du godkänna denna operation? Du kan bara godkänna den här gången, godkänna det senare eller avvisa det. Behörighetssystemet stödjer flerskiktad konfiguration – per projekt, per användare, per företag. Teams kan dela profiler för att vitlista vanliga säkerhetskommandon. Principerna bakom denna tillståndsdesign är följande: Om du startar Claude Code borde det inte förändra något utan ditt samtycke. Men samtidigt är det också nödvändigt att ge användarna möjlighet att "delegera" – i fallet med ditt förtroende kan du hoppa över bekräftelselänken. Enkelt, men inte grundläggande. Återhållsamhet, men inte brist på funktion.

[3] 20 prototyper på två dagar – hur ser produktiteration ut i AI-eran Tidigare, när jag gjorde produktprototyper, kunde jag göra två på två dagar, vilket ansågs effektivt. Boris gjorde 20 på två dagar. Detta är ingen överdrift, utan en sann dokumentation av hans utveckling av Claude Codes att-göra-listafunktion. Han delade till och med prompts och skärmdumpar av varje steg. Låt oss titta på hur dessa 20 arketyper itereras. I den första versionen ville han att att-göra-listan skulle visas under det senaste verktygsanropet. Prompten är kort: "Istället för att behöva göra två gör-göra-uppgifter med inmatning, visa en fast att-göra-lista ovanför inmatningsrutan, med titeln '/todo (1 av 3)' gråmarkerad". Efter att ha tittat på effekten var jag inte särskilt nöjd. I den andra versionen visas den inline vid varje ToDo-uppdatering. Prompt: "Istället för att visa en att-göra-lista, rendera verktygsnamnet till en fetstil titel när modellen börjar bearbeta en att-göra-uppgift." Behåll progressvisningen som 'steg 2 av 4'. ” Fortfarande inte rätt. I den tredje och fjärde upplagan försökte han skapa en "interaktiv tablett" – en liten ruta längst ner på skärmen som du kan klicka på för att se framstegen. "Lägg till en att-göra-tablett under textrutan, liknande en bakgrundsuppgift, som visar 'att-göras: 1 av 3'." Sedan: "Gör det här pillret interaktivt, som ett bakgrundsuppdragspill." ” Det är lite intressant, men inte tillräckligt bra. I femte och sjätte upplagan ändrade han sig: gör en "låda" som skjuts ut från höger. "Ta bort de tidigare pillren och titlarna, och visa istället att-göra-listan på höger sida av inmatningsrutan, centrerad vertikalt, separerad av en grå avdelare." "Den är lite hoppig, kan du göra den till en lådaanimation?" Den ser cool ut, men dess praktiska användning är tveksam. I den sjunde och nionde upplagan flyttade han att-göra-listan ovanför inmatningsrutan och experimenterade med olika trunkerings- och headerstilar. "Om det är fler än 5, visar det '... och 4 till'","Lägg till en grå 'Todo:'-titel". Svaret är att komma närmare och närmare. I den tionde och tjugonde upplagan började han lista ut hur man kombinerar att-göra-listor med laddningsanimationer. Den slutgiltiga lösningen är att placera framstegsinformation bredvid spinnaren (lastindikatorn) för att maximera sikten. Efter lanseringen rapporterade användare att de ville se hela att-göra-listan. Så en ny iteration läggs till: tryck Ctrl+T för att utöka alla steg. Detta är versionen som nu finns online.

Under hela processen var Boris prompts förvånansvärt korta—mest en eller två meningar. Men varje version är en prototyp som faktiskt kan köras, inte en statisk ritning, inte en PPT. Han kan verkligen testa och verifiera denna funktion för att känna om den fungerar bra. Den traditionella produktutvecklingsprocessen är: idé→ diskussion → att rita wireframes → göra högupplöst design → utveckling → testning → gå live. Varje steg tar tid, och varje steg kan fastna. Nu blir flödet: Idé → en-meningsprompt → exekverbar prototyp → Om något inte känns rätt, gör om det. Detta kräver faktiskt att utvecklare ändrar sitt tankesätt för att anpassa sig till denna utvecklingsprocess. Tidigare var prototypernas roll att "verifiera idéer" – eftersom kostnaden för prototypframställning var hög och man var tvungen att tänka noga innan man gjorde det. Nu har prototyper blivit "utforska möjligheter" – eftersom kostnaden för att göra prototyper är låg kan du göra dem först och sedan slänga dem. Boris sa att när han använder Claude Code hoppar han ofta över ritningen och gör bara en löpande version, vilket är mer intuitivt än något annat. Den dagliga rytmen för Claude Code-teamet är följande: varje ingenjör driver cirka 5 PR per dag, 60–100 interna releaser per dag och 1 release externt per dag. 5 PR per dag, vilket är otänkbart i de flesta företag. Uber är inne i den mest intensiva omstruktureringsperioden, och det är inte dåligt att kunna pressa ett medelstort PR om dagen. När verktygen förändras, förändras rytmen, och tankesättet måste förändras.

[4] Omdesignade kommandoradsterminalen med integrerad AI Kommandoradsterminaler har funnits i årtionden, varför behöver de designas om just nu? För innan LLM:er fokuserade terminaler inte så mycket på interaktiva upplevelser. Den traditionella kommandoraden är en fråga och svar: du skriver in ett kommando, det returnerar ett resultat, och du är klar. Ingen dialog, ingen kontext, ingen återkoppling medan man väntar. Du stirrar på markören som blinkar och vet inte vad som händer i bakgrunden. Claude Code var den första produkten som verkligen behövde tänka på "terminal UX". De lade till några små detaljer som såg obemärkta ut, men kändes helt annorlunda när de användes. Först: Kontextuella laddningspromptar. När modellen tänker kan skärmen generera relevanta prompts baserat på den aktuella uppgiftsvisningen: till exempel "läsa din kodstruktur" eller "fundera på en lösning". Det är en liten detalj, men det ger verktyget en "personlighet". Du kommer att känna att den jobbar hårt och inte fastnar. Boris säger att senaste gången han såg den här typen av trevlig liten interaktion var när Slack var en nybörjarintroduktion. För det andra: Undervisningstips medan man väntar. När Claude utför en lång uppgift visas en rotation av tips längst ner på skärmen, som "Du kan trycka på Esc för att avbryta den aktuella uppgiften" eller "Försök /help för att se alla kommandon". Kommandoraden används för att lära ut kommandoraden, vilket är enkelt och smart. Den tredje berättelsen är ännu mer spännande: Markdown-renderaren. Dagen före lanseringen klagade några ingenjörer på att nästlade listor var fula och att styckeavståndet inte var rätt. Problemet ligger i Markdown-renderaren. Boris provade alla renderare på marknaden, och ingen av dem såg bra ut i terminalen. Så han tillbringade en dag med att använda Claude Code för att skriva en Markdown-parser och renderare från grunden. Ja, dagen innan premiären. Ja, skriv från grunden. Ja, med Claude Code själv. Som ett resultat ser denna "stressade" renderer bättre ut än alla färdiga lösningar. De släppte den direkt. Boris anser att ingen annan terminal nu har samma kvalitet på Markdown-rendering. Den här berättelsen illustrerar en sak: när du har ett tillräckligt bra AI-programmeringsverktyg sjunker kostnaden för att "bygga dina egna hjul" avsevärt. Kompromissen "använd det bara" kan nu bli "gör då en bättre". Den urgamla gränssnittsformen av kommandoradsterminalen återuppstår med tillägget av LLM:er. Terminalen är fortfarande samma terminal, men på grund av tillägget av AI måste vi tänka seriöst på hur vi kan få människor att ha en bättre konversation med AI:n i terminalen.

[5] AI genomsyrar varje länk – ett "omfattande AI"-experiment av ett ingenjörsteam Anthropics ingenjörsteam är förmodligen en av de mest extrema användningarna av AI-verktyg just nu. Det handlar inte bara om att skriva kod, utan om varje aspekt av projektet. Kodgranskning: Den första granskningen av alla PR:er görs av Claude Code, och den andra av ingenjörer. Boris säger att Claude Code kan hitta många problem vid första passet. Denna funktion användes ursprungligen endast internt, men senare blev den offentlig så att alla kunde använda Claude Code för säkerhetsgranskning. Skriv tester: Claude Codes testsvit är nästan helt skriven av Claude Code. "Tidigare, om någon tog upp ett PR och inte skrev ett prov, tvekade jag att säga något — det kändes som en poängplockning," sa Boris. Men nu med Claude är det ett promptord att skriva ett prov, och det finns ingen ursäkt för att inte skriva det. ” Incidenthantering: Oncalls ingenjörer ber Claude Code att hjälpa till att analysera grundorsaken (grundorsaken till problemet). Den hämtar relevanta diskussioner från Slack, felloggar från Sentry, data från olika övervakningssystem och analyserar dem syntetiskt. Boris säger att Claude Code hittar Root Cause snabbare än en person i vissa scenarier. GitHub-problemtriage: När ett nytt problem kommer in gör Claude Code en analys först, och sedan frågar ingenjören om det kan implementeras. Boris säger att ungefär 20 % till 40 % av gångerna kan det göras första gången. Diagram och frågor: Produktdata finns i BigQuery, och nästan alla frågor och visualiseringar genereras i Claude Code. Ingenjörer låter till och med den ge ASCII-diagram direkt.

Det som överraskade mig mest var återkomsten av TDD (testdriven utveckling). TDD är ett gammalt koncept: skriv tester först, sedan skriv koden som klarar testerna. Det är bra i teorin – tvingar dig att tänka på vad du vill först. Men i praktiken tycker de flesta att det är för långsamt och krångligt, så denna metod har långsamt marginaliserats under de senaste tio åren. Men Boris sa att efter att ha använt Claude Code gjorde han mycket TDD: "Jag börjar med att be modellen skriva ett test och säga att testet kommer att misslyckas nu, försök inte få den att godkänna. Sedan bad jag den skriva kod för att implementera funktionen, och låta testet passera, men inte ändra testet självt. ” "När en modell har ett tydligt mål att iterera på—som ett enhetstest eller en mock—presterar den mycket bra." Han nämnde specifikt att Claude 4.0 är den första modellserien som tillåter modeller att skriva de flesta testerna. Tidigare versioner kunde skriva en del, men krävde mycket mänsklig inblandning. Det finns också ett nytt koncept: multi-klausering. Detta innebär att köra flera instanser av Claude Code samtidigt, vilket gör att de kan arbeta med olika uppgifter parallellt. Sid säger att han ofta gör så – startar några agenter under möten och kommer tillbaka senare för att se resultaten. Anthropic fann att 25 % av Max-prenumeranterna (premiumanvändare som kostar 100–200 dollar per månad) multi-kluderar varje dag. Detta är en intressant förändring. Programmering har alltid varit en "enkeltrådad" aktivitet: du kan bara göra en sak åt gången och byter bara uppgifter när koden granskas eller distribueras. Men nu är "parallell programmering" möjlig – du kan utveckla flera saker samtidigt. Självklart finns det många okända faktorer här: är parallellt arbete verkligen mer effektivt, eller känns det bara mer effektivt? Vilka typer av uppgifter är lämpliga för parallellism? Blir det problem om varje agent får mindre uppmärksamhet? Dessa frågor är ännu inte besvarade. Men vi har ett nytt verktyg att experimentera med. Slutligen, låt oss prata om ett fall. Ett företag skulle göra en rammigrering, och det uppskattades att det skulle ta två ingenjörsår – två år för en ingenjör, eller två och en halv månad för tio ingenjörer. De använde Claude Code, och en ingenjör gjorde det på två veckor. Boris sade att han brukade vara skeptisk till sådana påståenden, men de har hört liknande historier alldeles för många gånger.

[6] Tredagars hackathon – hur Subagents-funktionen föddes Inspirationen till denna funktion i Subagents kommer från ett Reddit-inlägg. Vissa säger att han öppnade fem Claude Code-instanser samtidigt, satte olika roller för varje instans och sedan använde filsystemet för att kommunicera med varandra. När Sid Bidasaria såg det här inlägget var hans första reaktion: Det här spelmekaniken är cool, men användare borde inte behöva kasta så här. Vi borde göra det till en inbyggd funktion i produkten. Det råkade vara så att företaget hade en intern hackathon på tre dagar, och Sid bestämde sig för att använda de tre dagarna till det. På första dagen ritade teamet entusiastiskt upp en mängd komplexa agenttopologier: meddelandebusskommunikation mellan agenter, asynkront läge, många-till-många-interaktioner...... Bilden är vackert tecknad och konceptet är avancerat. Nästa dag insåg de att det inte verkade genomförbart att göra det. Problemet är inte den tekniska implementeringen – komplexa mönster kan skapas. Problemet är att användarna inte kan förstå det. Claude Codes gränssnitt är en enkel terminal, hur låter man användare förstå dessa komplexa agentkommunikationslägen i ett så enkelt gränssnitt? De bestämde sig för att börja om och återvända till den grundläggande frågan: Vilken är den enklaste formen som en genomsnittlig utvecklare kan använda? De satte upp två begränsningar: För det första, uppfinna inget nytt. Använd endast de funktioner som Claude Code redan har – kommandot "/" och .md-filerna. För det andra, kommunicera inte mellan agenter. Byt till ett enkelt orkestreringsmönster: det finns en masteragent som kan anropa barnagenten, och barnagenten returnerar resultatet efter att uppgiften slutförts, och det är allt. De pratade också med Anthropics forskningsteam. Forskare arbetar med mönster för flera agenter, men slutsatsen är att det fortfarande är oklart om komplexa agenttopologier faktiskt fungerar. Detta ger dem mer självförtroende: eftersom även forskarteamet säger att komplexitet inte nödvändigtvis är bra, är det bättre att göra en enkel version. I slutet av den tredje dagen gjorde de en fungerande version. Användare kan definiera roller och kapaciteter för underagenter i .md-filer (t.ex. "front-end agents: using React 19 and Next.js"), Claude Code anropar dem när det är lämpligt, eller så kan användaren trigga dem manuellt. Efter hackathonen, efter lite polering, är funktionen live. Nu kan du definiera olika exklusiva underagenter: backend-agenter med expertis inom säkerhetsrevision, frontend-agenter som är bekanta med specifika ramverk och QA-agenter som specialiserar sig på att skriva tester...... De kan arbeta parallellt i bakgrunden, var och en i sin egen roll. Många lag kommer att vara ovilliga att omkullkasta sina komplexa planer i hackathon, de tillbringar ju trots allt en hel dag med att rita och diskutera, och de har känslor. Att kunna erkänna att "den här vägen fungerar inte" och störta den och börja om från början kräver mod och tro på "enkelhet". Enkelhet är inte lathet. Det enkla är att hitta den form som användaren verkligen kan använda bland de otaliga möjligheterna.

[7] Hur kommer ingenjörsteamet att vara i framtiden? Vissa kan användas som referens, och vissa kan inte kopieras Boris sa: "Programmering är så roligt nu. Senast jag kände så här var när jag skrev kod på en grafräknare för första gången i högstadiet. Den magiska känslan som jag inte upplevt på länge, men nu är den tillbaka. ” Sid känner likadant: "Det finns två saker som gör mig upphetsad. En är hastigheten vi släpper – ibland känns det för snabbt. Det andra är så mycket experimentellt utrymme – även om det tidigare arbetet gick snabbt, var det jag gjorde mer rutinmässigt, och med tanke på vad svaret var det bara utförande. Nu är det annorlunda, modellen ändras var tredje månad, och vi måste ständigt tänka om kring hur vi gör saker. ” Dessa känslor är mycket verkliga och smittsamma. Men innan vi diskuterar "hur framtiden för ingenjörsteam kommer att se ut", låt oss inte glömma Anthropics specifika egenskaper. För det första är Anthropic ett forskningslaboratorium, inte ett produktföretag. Dess kärnuppdrag är att forska om AI:s säkerhet och kapaciteter, och produkten är medlet, inte målet. Detta innebär att de har en mycket högre tolerans för "snabba experiment" än genomsnittsföretaget. För det andra är deras huvudprodukt själva Claude-modellen. Claude Code är bara ett "skal" av modellen. Så att "radera kod för att låta modellen göra mer" är ett naturligt val för dem, men för andra företag kan det innebära att ge kärnaffärslogiken till en svart låda. För det tredje har alla anställda obegränsad tillgång till Claude, inklusive den dyraste Opus-modellen. I de flesta företag är AI-prenumerationsavgifter en budgetpost som måste kämpas för och som inte kan användas av alla. För det fjärde består teamet bara av ett dussin personer, och processen är minimal. De använder knappt funktionsflaggor eftersom de är "för långsamma". Detta är otänkbart i en produkt med stor användarbas och hög felprocent. Så att kopiera Claude Code-teamet direkt är inte nödvändigtvis realistiskt för de flesta team. Men det finns vissa saker att lära sig av. Snabb prototypframställning: Även om du inte kan göra 10 prototyper om dagen, kan du byta från "en varannan vecka" till "tre i veckan"? Verktygen har förändrats, och förväntningarna på "hur snabbt prototypen ska vara" bör uppdateras. AI-assisterad kodgranskning: Låt AI:n göra den första granskningen och människan den andra. Denna process bygger inte på obegränsad API-åtkomst, vilket de flesta team kan prova. TDD:s återupplivning: Om det blir tillräckligt enkelt att skriva tester är "ingen tid att skriva tester" inte längre en ursäkt. Detta kan vara en kostnadseffektiv ingångspunkt för att förbättra kodkvaliteten. Värdet av produktinriktade ingenjörer förstärks: Claude Code-teamet har inga designers eller projektledare, bara några produktinriktade ingenjörer. AI-verktyg har kraftigt utökat vad denna "fullstack-talang" kan göra.

Självklart finns det vissa saker som inte kan ersättas av verktyg. Boris kunde välja den bästa av 20 arketyper eftersom han var dömande – han visste vad som "kändes rätt" och vad som bara "såg bra ut." Denna smak är resultatet av 17 års erfarenhet av mjukvaruutveckling, inte något som AI kan ge. Teamet gjorde en komplex plan första dagen, och nästa dag kunde de skoningslöst vända och börja om, vilket också är en mänsklig bedömning. Att veta när man ska radera kod och när man ska behålla den är densamma gäller denna arkitektoniska intuition. AI gör utförandet snabbare, men det gör inte "att veta vad man ska göra" lättare. Istället, eftersom kostnaden för utförandet har minskat, har beslutet om "vad man ska göra" blivit viktigare – du kan göra 20 versioner snabbt, men du måste veta vilken som är rätt. Hur kommer mjukvaruteknik att se ut om några år? Ingen kan förutsäga exakt. Men Claude Code-teamet idag kan vara någon form av repetition inför morgondagen för många team – snabbare iterationer, mindre "tegelstensflyttande", mer omdöme och beslutsfattande. Verktygen förändras. Det som förblir oförändrat är att det fortfarande är människor som fattar det slutgiltiga beslutet.