Laten we het verhaal van de geboorte van Claude Code eens op een rijtje zetten, voornamelijk gebaseerd op een artikel van technologieblogger Gergely Orosz waarin hij de kernleden van Claude Code interviewt. Claude Code is echt indrukwekkend, met een jaarlijkse omzet van 500 miljoen dollar, en het aantal gebruikers is in drie maanden tijd met 10 keer gestegen. Het is nu ook de favoriete Coding Agent-tool voor veel programmeurs. Dit hulpmiddel was aanvankelijk slechts een klein commandoregel speeltje dat je kon vertellen "welk nummer je nu aan het luisteren bent". 🧵

Gergely Orosz interviewde drie kernleden van Claude Code: • Oprichtende ingenieur Boris Cherny (17 jaar ervaring, voormalig hoofdingenieur bij Meta) • Nummer twee ingenieur Sid Bidasaria (auteur van de Subagents-functie) • En productmanager Cat Wu. Ze spraken over hoe Claude Code van prototype naar product is gegaan, welke technische keuzes zijn gemaakt, en hoe dit kleine team van een paar mensen erin slaagt om elke dag 5 PR's te publiceren. Dit is misschien wel het dichtstbijzijnde voorbeeld van een "AI-prioriteit engineeringteam" dat we momenteel hebben. Ze gebruiken AI om code te schrijven, tests te schrijven, codebeoordelingen uit te voeren, fouten op te sporen, en zelfs om Claude Code zelf te ontwikkelen. 90% van de code is door het zelf geschreven. Wat ik wil doen, is de meest interessante delen van dit interview samenstellen, om te vertellen hoe dit team werkt, wat er te leren valt, en wat door hun specifieke omstandigheden bepaald wordt en niet zomaar gekopieerd kan worden. Hieronder verdeeld in 7 kleine verhalen, die allemaal onafhankelijk kunnen worden bekeken, maar samen een compleet beeld vormen.

【1】Een klein hulpmiddel om muziek te luisteren, hoe het een product van 500 miljoen dollar per jaar werd. In september 2024, Boris Cherny net bij Anthropic begonnen, schreef een klein commandoregel speeltje in zijn vrije tijd. Wat kan dit ding doen? Het kan met AppleScript vertellen welke muziek je nu aan het luisteren bent, en het kan nummers wisselen op basis van jouw instructies. Zo simpel is het. Boris' eigen beoordeling is: "Best een coole demo, maar verder niet zo interessant."

De echte ommekeer vond plaats nadat hij met zijn collega Cat Wu had gesproken. Cat was toen bezig met het onderzoeken van de computergebruikcapaciteiten van AI Agent, en terwijl ze aan het praten waren, kwam Boris op een idee: wat als we deze commandoregeltool meer rechten zouden geven? Bijvoorbeeld, zodat het bestanden kan lezen en schrijven, en commando's kan uitvoeren?

Hij probeerde het. Toen kwam het moment om de wonderen te getuigen. Boris gooide dit geüpgradede hulpmiddel in de codebase van Anthropic en stelde een paar vragen. Claude begon zelf het bestandssysteem te verkennen - hij las een bestand, zag de importverklaringen erin en volgde de verwijzingen naar andere bestanden, laag voor laag, totdat hij het antwoord vond. "Dit heeft me versteld doen staan," herinnerde Boris zich, "ik heb nog nooit zo'n hulpmiddel gebruikt."

In het AI-veld is er een concept dat "product overhang" wordt genoemd, wat vertaald kan worden als "productoverschot". Het betekent dat het model eigenlijk al over bepaalde capaciteiten beschikt, maar de huidige productvorm deze capaciteiten niet heeft vrijgegeven. Wat Boris ontdekte, is een enorme "product overhang"; Claude kon dit al veel eerder, maar niemand heeft het een omhulsel gegeven.

Boris begon elke dag met dit hulpmiddel te werken en deelde het met een paar collega's. Twee maanden later, in november, publiceerden ze een interne versie. De gegevens zijn indrukwekkend: op de eerste dag gebruikte 20% van de ingenieurs het; op de vijfde dag 50%.

Er ontstond een interessante discussie: moeten we het naar buiten brengen? De redenen tegen zijn heel reëel: als dit ding echt zo krachtig is als we denken, is het dan niet beter om het als een "geheime wapen" te houden? Waarom zouden we ons concurrentievoordeel zomaar weggeven? Uiteindelijk koos Anthropic ervoor om het te publiceren. De logica is als volgt: de kernmissie van Anthropic is het onderzoeken van modelveiligheid, en de beste manier om veiligheid te onderzoeken is door mensen deze tools echt te laten gebruiken. Aangezien intern al is bevestigd dat Claude Code veel gebruikt zal worden, kan het publiceren ervan meer inzicht geven in de capaciteiten en veiligheid van het model.

In mei 2025 werd Claude Code officieel openbaar. Drie maanden later steeg het gebruik met 10 keer en de jaarlijkse inkomsten overschreden 500 miljoen dollar. Interessant is dat Boris aanvankelijk alleen aan programmeurs dacht - daarom heet het "Claude Code". Maar op een dag liep hij langs de werkplek van een datawetenschapper en zag hij dat Claude Code ook op diens scherm draaide. "Wat doe je hiermee?" "Ik laat het me helpen bij het schrijven van queries en het maken van visualisaties." Nu heeft elke datawetenschapper bij Anthropic er een, en sommigen hebben er zelfs meerdere tegelijk open. Een klein hulpmiddel om muziek te luisteren, dat door het geven van een paar extra rechten veranderde in een product ter waarde van honderden miljoenen dollars. Dit is waarschijnlijk het beste bewijs van "product overhang"; de capaciteiten van het model waren altijd al daar, het enige wat nodig was, was dat iemand het vrijliet.

【2】90% van de code is zelf geschreven - de technologiekeuze filosofie van Claude Code Claude Code heeft 90% van de code zelf geschreven. Het klinkt als een marketingtruc, maar dit is eigenlijk te danken aan hun logica achter technologische beslissingen. Laten we eerst naar de techstack kijken: TypeScript voor de kern, React in combinatie met het Ink-framework voor de terminal UI, Meta's open-source Yoga voor het lay-outsysteem, en Bun voor het bouwen en bundelen. Waarom deze techstack gekozen? Omdat ze "binnen de distributie" zijn. "Binnen de distributie" (on distribution) is een term uit het AI-veld. Het betekent dat het model al veel van dit soort code heeft gezien en goed in staat is om ermee om te gaan. TypeScript en React zijn precies de sterke punten van Claude. Als je een obscure framework kiest, moet het model "leren", wat de effectiviteit zou verminderen. Deze keuze creëert een prachtig cirkelproces: gebruik de techstack waar Claude goed in is om Claude Code te schrijven, en gebruik vervolgens Claude Code om meer Claude Code te schrijven. 90% zelfgeschreven, dat is hoe het komt. Hun keuzes op architectonisch niveau zijn ook eenvoudig. Claude Code draait lokaal. Geen Docker-containers, geen cloud-sandbox, gewoon direct op je computer bestanden lezen en schrijven, en commando's uitvoeren.

Waarom is het zo ontworpen? Boris' antwoord is: "Bij elke ontwerpbeslissing kiezen we bijna altijd de eenvoudigste oplossing. Lokale uitvoering is gewoon het eenvoudigste antwoord." Deze eenvoud strekt zich uit tot de hele productfilosofie: schrijf zo min mogelijk bedrijfslogica en laat het model de hoofdrol spelen. "Dit klinkt misschien een beetje vreemd," zegt Boris, "maar we willen dat gebruikers het model zo 'puur' mogelijk ervaren. Veel AI-producten voegen een hoop scaffolding toe - extra UI-elementen, verschillende ondersteunende functies - wat het model juist beperkt in zijn mogelijkheden. Wat we willen doen, is de UI zo eenvoudig mogelijk houden." Om de eenvoud te behouden, vereenvoudigen ze elke keer dat Claude een nieuw model uitbrengt, de code aanzienlijk. Bijvoorbeeld, toen Claude 4.0 werd uitgebracht, verwijderden ze ongeveer de helft van de systeemprompten, omdat het nieuwe model die "steunen" niet meer nodig had. Het aantal tools wordt ook voortdurend vereenvoudigd - wat verwijderd kan worden, wordt verwijderd, wat samengevoegd kan worden, wordt samengevoegd. De hele Claude Code-architectuur kan worden samengevat in drie dingen: definieer de UI en exposeer de interface voor modelwijzigingen, exposeer tools voor modelaanroepen, en ga dan aan de kant. Natuurlijk betekent eenvoud niet dat er geen complexe onderdelen zijn. Het machtigingssyteem is een uitzondering. Het is tenslotte riskant om AI opdrachten op je computer te laten uitvoeren. De oplossing van Claude Code is om je eerst te vragen: wil je deze actie goedkeuren? Je kunt het alleen voor deze keer goedkeuren, of het in de toekomst goedkeuren, of weigeren. Het machtigingssyteem ondersteunt meerdere configuratieniveaus - per project, per gebruiker, per bedrijf. Teams kunnen configuratiebestanden delen en veelgebruikte veilige opdrachten op de witte lijst zetten. Het principe achter dit machtigingsontwerp is als volgt: als je Claude Code opstart, zou het niets moeten veranderen zonder jouw toestemming. Maar tegelijkertijd moet je de keuze hebben om "machtiging te geven" - in situaties waarin je vertrouwt, kun je de bevestigingsstap overslaan. Eenvoudig, maar niet simplistisch. Beheerst, maar niet zonder functionaliteit.

【3】Twee dagen 20 prototypes - Hoe ziet productiteratie eruit in het AI-tijdperk Vroeger, als je productprototypes maakte, was het al een hoge efficiëntie als je er in twee dagen twee kon maken. Boris maakte in twee dagen 20. Dit is geen overdrijving, het is een echte registratie van toen hij de todo-lijstfunctie van Claude Code ontwikkelde. Hij deelde zelfs de prompts en screenshots van elke stap. Laten we eens kijken hoe deze 20 prototypes zijn geëvolueerd. In de eerste versie wilde hij dat de todo-lijst onder de laatste toolaanroep werd weergegeven. De prompt was kort: "Laat de todo niet verschijnen met de invoer, maar toon een vaste todo-lijst boven het invoerveld, met de titel in grijs weergegeven '/todo (1 van 3)'." Na het bekijken van het resultaat was hij niet helemaal tevreden. In de tweede versie veranderde hij het naar inline weergave bij elke todo-update. De prompt: "Eigenlijk moet de todo-lijst niet worden weergegeven, maar wanneer het model begint met het verwerken van een todo, moet de naam van de tool als vetgedrukte titel worden weergegeven. Behoud de voortgangsweergave zoals 'stap 2 van 4'." Het was nog steeds niet goed. In de derde en vierde versie probeerde hij een "interactieve pil" te maken - een klein vierkant onderaan het scherm dat je kunt openen om de voortgang te bekijken. "Voeg een todo-pil toe onder het tekstinvoerveld, vergelijkbaar met de stijl van achtergrondtaken, met de weergave 'todos: 1 van 3'." Daarna: "Laat deze pil interactief zijn, zoals de pil voor achtergrondtaken." Het werd interessant, maar het was nog niet goed genoeg. In de vijfde en zesde versie veranderde hij van aanpak: hij maakte een "lade" die van rechts naar buiten schuift. "Verwijder de eerdere pil en titel, en toon de todo-lijst rechts van het invoerveld, verticaal gecentreerd, gescheiden door een grijze lijn." "Het is een beetje sprongetjes, kan het als een lade-animatie worden gemaakt?" Het zag er cool uit, maar de bruikbaarheid was twijfelachtig. In de zevende tot negende versie verplaatste hij de todo-lijst weer naar boven het invoerveld en experimenteerde hij met verschillende afbreekmethoden en titelstijlen. "Als er meer dan 5 zijn, toon dan '... en 4 meer'", "voeg een grijze 'Todo:' titel toe." Hij kwam steeds dichter bij het antwoord. In de tiende tot twintigste versie begon hij na te denken over hoe hij de todo-lijst en de laadanimatie kon combineren. De uiteindelijke oplossing was om de voortgangsinformatie naast de spinner (laadindicator) te plaatsen, om de zichtbaarheid te maximaliseren. Na de lancering gaven gebruikers feedback dat ze de volledige todo-lijst wilden zien. Dus voegde hij nog een iteratie toe: druk op Ctrl+T om alle stappen uit te vouwen. Dit is de huidige online versie.

In het hele proces zijn Boris' prompts verrassend kort - meestal slechts een of twee zinnen. Maar elke versie is een werkend prototype, geen statische afbeelding, geen PPT. Hij kan deze functie echt testen en voelen of het soepel werkt. Het traditionele productontwikkelingsproces is: idee → discussie → wireframe maken → high-fidelity ontwerp maken → ontwikkelen → testen → lanceren. Elke stap kost tijd en elke stap kan vastlopen. Nu is het proces veranderd in: idee → één zin prompt → werkend prototype → als het niet goed voelt, maak dan een nieuwe versie. Dit vereist eigenlijk dat ontwikkelaars hun denkwijze veranderen om zich aan te passen aan dit ontwikkelingsproces. Vroeger was de rol van prototypes "ideeën verifiëren" - omdat het maken van prototypes duur was, moest je eerst goed nadenken voordat je aan de slag ging. Nu is het prototype veranderd in "mogelijkheden verkennen" - omdat het maken van prototypes goedkoop is, kun je het eerst maken en dan kijken, als het niet goed is, gooi je het weg. Boris zegt dat hij bij het gebruik van Claude Code vaak de fase van het maken van ontwerpschema's overslaat en direct een werkende versie maakt, wat veel intuïtiever is. Het dagelijkse ritme van het Claude Code-team is: elke ingenieur duwt dagelijks ongeveer 5 PR's, intern worden er dagelijks 60-100 versies uitgebracht, extern wordt er dagelijks 1 versie uitgebracht. Vijf PR's per dag, dat is voor de meeste bedrijven ondenkbaar. Uber kon in de meest stressvolle herstructureringsperiode al blij zijn met één middelgrote PR per dag. De tools zijn veranderd, het ritme is veranderd, en de denkwijze moet ook veranderen.

【4】Herontwerp van de commandoregelterminal na integratie van AI De commandoregelterminal bestaat al tientallen jaren, waarom is er nu een herontwerp nodig? Omdat de terminal vóór de komst van LLM niet veel aandacht besteedde aan de interactie-ervaring. De traditionele commandoregel is een vraag-en-antwoord: je voert een commando in, het geeft een resultaat terug, klaar. Geen dialoog, geen context, geen feedback tijdens het wachten. Je staart naar de knipperende cursor, zonder te weten wat er op de achtergrond gebeurt. Claude Code is een van de eerste producten die echt moet nadenken over "terminal UX". Ze hebben een paar kleine details toegevoegd die onopvallend lijken, maar de ervaring is totaal anders. Eerste: contextuele laadindicaties. Wanneer het model aan het denken is, kan het scherm op basis van de huidige taak relevante aanwijzingen weergeven: zoals "bezig met het lezen van je code-structuur" of "bezig met het nadenken over oplossingen". Dit is een klein detail, maar het geeft het hulpmiddel een "persoonlijkheid". Je hebt het gevoel dat het serieus aan het werk is, en niet vastloopt. Boris zei dat de laatste keer dat hij zo'n plezierige interactie zag, de onboarding-procedure van Slack was. Tweede: onderwijzende tips tijdens het wachten. Wanneer Claude een lange taak uitvoert, worden er onderaan het scherm afwisselend tips weergegeven, zoals "je kunt Esc indrukken om de huidige taak te onderbreken" of "probeer /help om alle commando's te bekijken". De commandoregel wordt gebruikt om de commandoregel te onderwijzen, simpel en slim. Het derde verhaal is nog spannender: de Markdown-renderer. De dag voor de release klaagde een ingenieur dat geneste lijsten er lelijk uitzagen en dat de tussenruimtes niet klopten. Het probleem lag bij de Markdown-renderer. Boris heeft alle beschikbare renderers geprobeerd, maar geen enkele zag er goed uit in de terminal. Dus heeft hij met Claude Code een dag besteed aan het vanaf nul schrijven van een Markdown-parser en -renderer. Ja, de dag voor de release. Ja, vanaf nul geschreven. Ja, met Claude Code zelf. Het resultaat was dat deze "snelle" renderer mooier was dan alle bestaande oplossingen. Ze hebben het gewoon uitgebracht. Boris gelooft dat er momenteel geen enkele andere terminal is met dezelfde kwaliteit van Markdown-rendering. Dit verhaal laat één ding zien: wanneer je een goed genoeg AI-programmeerhulpmiddel hebt, zullen de kosten van "zelf wielen maken" aanzienlijk dalen. Wat vroeger een compromis was van "het moet gewoon werken", kan nu veranderen in "laten we een betere maken". De commandoregelterminal, deze oude interfacevorm, krijgt nieuw leven door de toevoeging van LLM. De terminal is nog steeds dezelfde terminal, maar door de toevoeging van AI moeten we serieus nadenken over hoe we de interactie tussen mensen en de AI in de terminal kunnen verbeteren.

【5】AI doordringt elk aspect - een "volledige AI-integratie" experiment van een engineeringteam Het engineeringteam van Anthropic is misschien wel een van de teams die AI-tools het meest optimaal benut. Dit komt niet alleen tot uiting in het schrijven van code, maar in alle fasen van het project. Code review: De eerste ronde van de review van alle PR's wordt uitgevoerd door Claude Code, de ingenieur doet de tweede ronde. Boris zegt dat Claude Code in de eerste ronde veel problemen kan ontdekken. Deze functie was oorspronkelijk alleen intern beschikbaar, maar later hebben ze het openbaar gemaakt, zodat iedereen Claude Code kan gebruiken voor veiligheidsreviews. Testen schrijven: De testsets van Claude Code zijn bijna allemaal door Claude Code geschreven. Boris zegt: "Vroeger, als iemand een PR indiende zonder tests te schrijven, twijfelde ik of ik er iets van moest zeggen - het voelde als zeuren. Maar nu, met Claude, is het schrijven van tests gewoon een kwestie van een prompt, er is geen excuus meer om het niet te doen." Incidentrespons: De on-call ingenieur laat Claude Code helpen bij het analyseren van de Root Cause (de meest fundamentele oorzaak van het probleem). Het kan relevante discussies uit Slack halen, foutlogs uit Sentry trekken, gegevens uit verschillende monitoringsystemen verzamelen en vervolgens een gecombineerde analyse maken. Boris zegt dat Claude Code in sommige situaties de Root Cause sneller vindt dan mensen. GitHub issue routing: Elke keer als er een nieuwe issue binnenkomt, doet Claude Code eerst een analyse, waarna de ingenieur vraagt: "Kun je dit implementeren?" Boris zegt dat het in ongeveer 20%-40% van de gevallen het in de eerste poging kan oplossen. Grafieken en queries: Productgegevens zijn opgeslagen in BigQuery, bijna alle queries en visualisaties zijn gegenereerd met Claude Code. Ingenieurs vragen het zelfs om direct ASCII-grafieken te genereren.

Wat me het meest verraste, was de heropleving van TDD (Test-Driven Development). TDD is een oud concept: eerst tests schrijven, dan de code die de tests laat slagen. In theorie is het prachtig - het dwingt je om eerst goed na te denken over wat je wilt. Maar in de praktijk vinden de meeste mensen het te traag en te omslachtig, waardoor deze methode de afgelopen tien jaar langzaam naar de achtergrond is verschoven. Maar Boris zei dat hij na het gebruik van Claude Code veel TDD heeft gedaan: "Ik laat het model eerst een test schrijven, terwijl ik het vertel dat deze test nu zal falen, en dat het niet moet proberen om het te laten slagen. Dan laat ik het code schrijven om de functionaliteit te implementeren en de test te laten slagen, maar ik kan de test zelf niet wijzigen." "Wanneer het model een duidelijk doel heeft om op te itereren - zoals een eenheidstest of een mock - presteert het heel goed." Hij merkte speciaal op dat Claude 4.0 het eerste model is dat het model in staat stelt om het grootste deel van de tests te schrijven. Eerdere versies konden een deel schrijven, maar vereisten veel handmatige tussenkomst. Er is ook een nieuw concept: multi-clauding. Dit betekent dat meerdere Claude Code-instanties tegelijkertijd draaien, zodat ze verschillende taken parallel kunnen verwerken. Sid zei dat hij dit vaak doet - hij start een paar agenten tijdens vergaderingen en kijkt later naar de resultaten. Anthropic ontdekte dat 25% van de Max-abonnees (premium gebruikers met een maandelijkse vergoeding van 100-200 dollar) dagelijks aan multi-clauding doet. Dit is een interessante verandering. Programmeren was altijd een "single-threaded" activiteit: je kunt maar één ding tegelijk doen, en alleen tijdens codebeoordelingen of implementaties wissel je van taak. Maar nu is "parallel programmeren" mogelijk - je kunt tegelijkertijd meerdere dingen vooruit helpen. Natuurlijk zijn er veel onbekenden: is parallel werken echt efficiënter, of lijkt het alleen maar efficiënter? Welke soorten taken zijn geschikt voor parallelle verwerking? Zal het probleem geven als elke agent minder aandacht krijgt? Deze vragen hebben nog geen antwoorden. Maar we hebben een nieuw hulpmiddel om mee te experimenteren. Tot slot een case study. Een bedrijf moest een framework migreren, en oorspronkelijk werd geschat dat dit twee jaar werk zou kosten - één ingenieur die twee jaar werkt, of tien ingenieurs die tweeënhalve maand werken. Ze gebruikten Claude Code, en één ingenieur voltooide het in twee weken. Boris zei dat hij vroeger sceptisch zou zijn over dergelijke beweringen, maar ze hebben dit soort verhalen te vaak gehoord.

【6】Drie dagen hackathon - Hoe de functie Subagents is ontstaan De inspiratie voor de functie Subagents komt van een post op Reddit. Iemand zei dat hij vijf Claude Code-instanties tegelijk had geopend, met voor elke instantie een andere rol ingesteld, en vervolgens een bestandssysteem gebruikte om ze met elkaar te laten communiceren. Toen Sid Bidasaria deze post zag, was zijn eerste reactie: dit is een coole manier, maar gebruikers zouden niet zo moeten hoeven rommelen. We zouden dit als een ingebouwde functie in het product moeten maken. Toevallig had het bedrijf een interne hackathon van drie dagen, en Sid besloot deze drie dagen te gebruiken om dit te doen. Op de eerste dag tekende het team enthousiast allerlei complexe agenttopologieën: agents communiceren via een berichtenbus, asynchrone modus, veel-op-veel interactie... De tekeningen waren mooi, het concept geavanceerd. Op de tweede dag realiseerden ze zich dat dit blijkbaar niet haalbaar was. Het probleem was niet de technische uitvoering - die complexe modellen konden worden gerealiseerd. Het probleem was dat gebruikers het niet konden begrijpen. De UI van Claude Code is gewoon een eenvoudige terminal, hoe laat je gebruikers die complexe agentcommunicatiemodellen begrijpen in zo'n eenvoudige interface? Ze besloten alles opnieuw te doen en terug te gaan naar een fundamentele vraag: wat is de eenvoudigste vorm die gewone ontwikkelaars kunnen gebruiken? Ze stelden zichzelf twee beperkingen: Ten eerste, geen nieuwe dingen uitvinden. Alleen gebruik maken van de bestaande mogelijkheden van Claude Code - de “/” commando's en .md-bestanden. Ten tweede, geen communicatie tussen agents. In plaats daarvan een eenvoudige orkestratiemodus: er is één hoofdagent die subagents kan aanroepen, en de subagents geven hun resultaten terug nadat ze hun taken hebben voltooid, dat is alles. Ze spraken ook met het onderzoeksteam van Anthropic. De onderzoekers bestudeerden het multi-agentmodel, maar de conclusie was: of complexe agenttopologieën echt effectief zijn, is nog niet definitief vastgesteld. Dit gaf hen meer vertrouwen: aangezien zelfs het onderzoeksteam zegt dat complex niet per se goed is, moeten ze een eenvoudige versie maken. Aan het einde van de derde dag hadden ze een werkbare versie gemaakt. Gebruikers kunnen in .md-bestanden de rollen en mogelijkheden van subagents definiëren (bijvoorbeeld "frontend subagent: gebruik React 19 en Next.js"), en Claude Code zal ze op het juiste moment aanroepen, of gebruikers kunnen ze handmatig activeren. Na de hackathon, na een kleine verfijning, werd de functie gelanceerd. Nu kun je verschillende speciale subagents definiëren: een backend agent met expertise in beveiligingsaudits, een frontend agent die bekend is met specifieke frameworks, een QA agent die gespecialiseerd is in het schrijven van tests... Ze kunnen parallel in de achtergrond werken, elk met hun eigen taken. Veel teams willen tijdens de hackathon hun complexe plannen niet opgeven, omdat ze er een hele dag aan hebben gewerkt met tekenen en discussiëren, en er emotioneel aan gehecht zijn geraakt. Het vergt moed om te erkennen dat "deze weg niet werkt" en opnieuw te beginnen, en het vereist ook een geloof in "simpel". Simpel is geen luiheid. Simpel is het vinden van de vorm die gebruikers echt kunnen gebruiken uit talloze mogelijkheden.

【7】Hoe zal het toekomstige engineeringteam eruitzien? Sommige dingen zijn te leren, andere zijn niet te kopiëren. Boris zegt: "Programmeren is nu zo leuk. De laatste keer dat ik dit gevoel had, was op de middelbare school toen ik voor het eerst code schreef op een grafische rekenmachine. Dat magische gevoel heb ik al een tijd niet meer ervaren, maar het is nu terug." Sids gevoel is vergelijkbaar: "Er zijn twee dingen die me enthousiast maken. Ten eerste de snelheid waarmee we publiceren - soms voelt het zelfs te snel. Ten tweede de hoeveelheid experimenteerruimte - hoewel mijn vorige werk ook snel was, was wat we deden vrij standaard, we wisten wat het antwoord was, het was gewoon uitvoeren. Nu is het anders, het model verandert elke drie maanden, we moeten voortdurend opnieuw nadenken over hoe we dingen doen." Deze gevoelens zijn heel echt en aanstekelijk. Maar voordat we het hebben over "hoe het toekomstige engineeringteam eruit zal zien", moeten we ook de bijzonderheid van Anthropic niet vergeten. Ten eerste, Anthropic is een onderzoekslaboratorium, geen productbedrijf. De kernmissie is het onderzoeken van AI-veiligheid en -capaciteiten, producten zijn middelen, geen doel. Dit betekent dat ze veel toleranter zijn voor "snelle experimenten" dan de meeste bedrijven. Ten tweede, hun belangrijkste product is het Claude-model zelf. Claude Code is slechts een "omhulsel" van het model. Dus "code verwijderen zodat het model meer kan doen" is een natuurlijke keuze voor hen, maar voor andere bedrijven kan het betekenen dat ze de kernbedrijfslogica aan een black box toevertrouwen. Ten derde, alle medewerkers hebben onbeperkte toegang tot Claude, inclusief het duurste Opus-model. In de meeste bedrijven is de AI-abonnementsvergoeding een budgetpost die moet worden bevochten, het is niet mogelijk dat iedereen het vrij kan gebruiken. Ten vierde, het team bestaat uit slechts een paar mensen, met een zeer vereenvoudigd proces. Ze gebruiken bijna geen feature flags omdat "het te langzaam is". Dit is ondenkbaar voor producten met een grote gebruikersbasis en hoge foutkosten. Dus, het direct kopiëren van de werkwijze van het Claude Code-team is voor de meeste teams misschien niet realistisch. Maar sommige dingen zijn te leren. De denkwijze van snel prototypen: zelfs als je niet 10 prototypes per dag kunt maken, kun je dan van "één om de twee weken" naar "drie per week" gaan? De tools zijn veranderd, de verwachtingen over "hoe snel prototypes moeten zijn" moeten ook worden bijgewerkt. AI-ondersteunde codebeoordeling: laat AI de eerste beoordeling doen, en mensen de tweede. Dit proces is niet afhankelijk van onbeperkte API-toegang, de meeste teams kunnen dit proberen. De heropleving van TDD: als het schrijven van tests gemakkelijk genoeg wordt, is "geen tijd om tests te schrijven" niet langer een excuus. Dit kan een goedkope instap zijn om de codekwaliteit te verbeteren. De waarde van productgerichte ingenieurs vergroten: het Claude Code-team heeft geen ontwerpers, geen PM's, maar vertrouwt op een paar ingenieurs met productgevoel. AI-tools hebben de dingen die deze "full-stack talenten" kunnen doen aanzienlijk uitgebreid.

Natuurlijk zijn er ook dingen die niet door tools kunnen worden vervangen. Boris kan de beste uit 20 prototypes kiezen omdat hij beoordelingsvermogen heeft - hij weet wat "goed aanvoelt" en wat alleen maar "bruikbaar lijkt". Deze smaak is het resultaat van 17 jaar ervaring in softwareontwikkeling, iets wat AI niet kan bieden. Het team heeft op de eerste dag een complex plan gemaakt en op de tweede dag met een harde beslissing alles omgegooid, dat soort besluitvaardigheid is ook een menselijke beoordeling. Weten wanneer je code moet verwijderen en wanneer je deze moet behouden, dat soort architectonisch inzicht is ook zo. AI heeft de uitvoering versneld, maar het heeft "weten wat te doen" niet eenvoudiger gemaakt. Integendeel, omdat de uitvoeringskosten zijn gedaald, is de beslissing over "wat te doen" belangrijker geworden - je kunt snel 20 versies maken, maar je moet weten welke de juiste is. Hoe zal software-engineering er over een paar jaar uitzien? Niemand kan dat precies voorspellen. Maar het team van Claude Code vandaag kan een soort voorproefje zijn van wat veel teams morgen zal zijn - snellere iteraties, minder "stenen verplaatsen", meer beoordeling en besluitvorming. Tools veranderen. Wat niet verandert, is dat de uiteindelijke beslissing nog steeds door mensen wordt genomen.