Să aruncăm o privire asupra poveștii nașterii lui Claude Code, inspirată în principal dintr-un interviu cu bloggerul de tehnologie Gergely Orosz despre un membru de bază al Claude Code. Claude Code este cu adevărat remarcabil, cu un venit anualizat de 500 de milioane de dolari și o creștere de 10 ori a volumului de utilizatori în trei luni, fiind acum instrumentul preferat pentru Agent de Codare pentru mulți programatori. Acest instrument a început ca o mică jucărie de linie de comandă care îți spunea "ce melodie asculți acum." 🧵

Gergely Orosz a intervievat trei membri de bază ai trupei Claude Code: • Boris Cherny, inginer fondator (17 ani de experiență, fost inginer-șef Meta) • Inginerul 2 Sid Bidasaria (autorul rubricii Subagents) • și Cat Wu, Manager de produs. Au vorbit despre cum Claude Code a trecut de la prototip la produs, ce alegeri tehnice au făcut și cum mica echipă de o duzină de persoane a reușit să publice 5 PR-uri pe zi. Probabil că acesta este cel mai apropiat exemplu de o "echipă de inginerie AI-first pe primul loc" în acest moment. Ei folosesc AI pentru a scrie cod, teste, face revizuiri de cod, depanare și chiar folosesc Claude Code pentru a dezvolta propriul Claude Code. 90% din cod este scris singur. Ceea ce vreau să fac este să clarific cele mai interesante părți ale acestui interviu, să vorbesc despre cum funcționează această echipă, ce se poate învăța și ce este determinat de condițiile lor speciale și nu poate fi copiat. Următoarele sunt împărțite în 7 povestiri scurte, fiecare putând fi citită independent, și sunt legate împreună pentru a forma o imagine completă.

[1] Cum poate un dispozitiv de ascultare să devină un produs cu un venit anual de 500 de milioane de dolari În septembrie 2024, Boris Cherny tocmai s-a alăturat Anthropic și a scris o jucărie de linie de comandă când nu avea nimic de făcut. Ce poate face chestia asta? Folosește AppleScript pentru a-ți spune ce melodie asculți și modifică melodia conform comenzilor tale. E atât de simplu. Boris însuși a comentat: "Demo destul de tare, dar nu interesant. ”

Adevărata întorsătură a venit după ce a terminat de vorbit cu colega sa Cat Wu. Cat studia capacitățile informatice ale agentului AI, iar în timp ce vorbeau, Boris a avut o idee: ce-ar fi să dăm acestui instrument de linie de comandă mai multe permisiuni? De exemplu, să poată citi și scrie fișiere și să execute comenzi?

A încercat. Apoi, vine momentul să fim martori la miracol. Boris a aruncat unealta îmbunătățită în codul Anthropic și a pus câteva întrebări. Claude a început să exploreze sistemul de fișiere pe cont propriu — citind un fișier, văzând instrucțiunea de import din interior, apoi citind fișierul referențiat, săpând strat cu strat până a găsit răspunsul. "M-a zguduit," își amintește Boris, "și nu mai folosisem niciodată o unealtă ca asta. ”

În domeniul AI, există un concept numit "product overhang", care se traduce prin "product overhang" (depășirea produsului). Aceasta înseamnă că modelul are de fapt o anumită capacitate, dar forma existentă a produsului nu eliberează această capacitate. Ceea ce a descoperit Boris a fost o "suprafață de produs" uriașă pe care Claude ar fi putut să o facă de mult, dar nimeni nu construise o carcasă pentru ea.

Boris a început să lucreze zilnic cu instrumentul și apoi l-a împărtășit cu mai mulți colegi. Două luni mai târziu, în noiembrie, au lansat o versiune. Datele sunt exagerate: în prima zi, 20% dintre ingineri sunt folosiți; Ziua 5, 50%.

În acest moment, apare o dezbatere interesantă: ar trebui să fie lansat în lumea exterioară? Motivul opoziției este foarte real: dacă acest lucru este cu adevărat atât de puternic pe cât credem, nu ar fi bine să-l păstrăm ca o "armă secretă"? De ce să renunțe la avantajul competitiv? În cele din urmă, Anthropic a ales să publice. Logica este următoarea: misiunea principală a Anthropic este să studieze siguranța modelelor, iar cea mai bună metodă de a studia securitatea este să folosești efectiv aceste instrumente. Acum că Claude Code a fost validat intern pentru a fi folosit intens, lansarea acestuia va oferi mai multe informații despre capabilitățile și securitatea modelului.

În mai 2025, Claude Code a fost făcut oficial public. Trei luni mai târziu, consumul a crescut de 10 ori și veniturile anualizate depășesc 500 de milioane de dolari. Interesant este că Boris a fost inițial destinat programatorilor – de aici și numele "Claude Code". Dar într-o zi a trecut pe lângă stația de lucru a data scientist-ului și l-a găsit pe Claude Code rulând pe celălalt ecran. "De ce folosești asta?" "I-am cerut să mă ajute să scriu interogări și să vizualizez." Acum, oamenii de știință de date de la Anthropic au unul la îndemână, iar unii conduc mai mulți simultan. Un dispozitiv de ascultare, pentru că i s-au acordat câteva permisiuni în plus, a devenit un produs de sute de milioane de dolari. Probabil că aceasta este cea mai bună dovadă a "depășirii produsului", capacitatea modelului este mereu acolo, așteptând ca cineva să o lanseze.

[2] 90% din cod este scris de unul singur - filosofia tehnică de selecție a lui Claude Code Claude Code are 90% din propriul său cod. Sună ca un truc, dar de fapt se datorează logicii lor tehnice de luare a deciziilor. Să aruncăm mai întâi o privire la stack-ul tehnologic: TypeScript scrie corpul principal, React folosește framework-ul Ink ca interfață a terminalului, Yoga open-source de la Meta se ocupă de sistemul de layout, iar Bun este responsabil de construcție și ambalare. De ce să alegi aceste stack-uri tehnologice? Pentru că sunt "în interiorul distribuției". "Despre distribuție" este un termen în domeniul AI. Aceasta înseamnă că modelul a văzut mult din acest tip de cod și este bun la gestionarea lor. TypeScript și React sunt exact punctele unde Claude este puternic. Dacă alegi un cadru nepopular, modelul va trebui să "învețe", iar efectul va fi compromis. Această alegere duce la un ciclu minunat: scrie cod Claude cu stack-ul tehnologic la care Claude este bun, apoi scrie mai mult cod Claude cu cod Claude. 90% scrie despre tine, așa s-a întâmplat. Alegerile lor la nivel arhitectural sunt la fel de concise. Codul Claude rulează local. Nu există containere Docker, nici cloud sandbox, doar citește și scrie fișiere și execută comenzi direct pe calculatorul tău.

Cât despre motivul pentru care este proiectat astfel? Boris răspunde: "De fiecare dată când luăm o decizie de design, aproape întotdeauna alegem cea mai simplă soluție. A rula local este cel mai simplu răspuns. ” Această simplitate se extinde la întreaga filozofie a produsului: să scrii cât mai puțină logică de business și să lași modelul să fie protagonistul. "Poate suna puțin ciudat," a spus Boris, "dar vrem ca utilizatorii să simtă modelul cât mai 'autentic' posibil. Multe produse AI adaugă o mulțime de structuri — elemente suplimentare UI, funcții de accesibilitate — iar rezultatul este că modelul este limitat. Ceea ce vrem să facem este să facem interfața cât mai slabă posibil. ” Ca să fie simplu, de fiecare dată când Claude lansează un model nou, ei simplifică mult codul. De exemplu, când a fost lansat Claude 4.0, au eliminat aproximativ jumătate din solicitările sistemului pentru că noul model nu mai avea nevoie de acele "cârje". Numărul uneltelor este, de asemenea, simplificat—șterge dacă poți, merge dacă poți. Întreaga arhitectură Claude Code poate fi rezumată în trei lucruri: definirea interfeței și expunerea interfeței la modificarea modelului, expunerea uneltelor pe care modelul le poate chema și apoi flash-out. Desigur, simplitatea nu înseamnă că nu există părți complicate. Sistemul de permisiuni este excepția. La urma urmei, a face ca AI-ul să execute comenzi pe calculatorul tău este riscant. Soluția Claude Code este să te întrebe înainte de a o executa: Vrei să apropi această operațiune? Poți aproba doar de data asta, poți aproba mai târziu sau poți respinge. Sistemul de permisiuni suportă configurare pe mai multe niveluri – pe proiect, pe utilizator, pe companie. Teams poate partaja profiluri pentru a lista albe comenzile de securitate folosite frecvent. Principiile din spatele acestui proiect cu permisiune sunt următoarele: Dacă pornești Claude Code, nu ar trebui să schimbe nimic fără consimțământul tău. Dar, în același timp, este necesar să le oferim utilizatorilor opțiunea de a "delega" – în cazul încrederii tale, poți sări peste linkul de confirmare. Simplu, dar nu rudimentar. Reținere, dar nu lipsă de funcționare.

[3] 20 de prototipuri în două zile - cum arată iterația produselor în era AI În trecut, când făceam prototipuri de produse, puteam face două în două zile, ceea ce era considerat eficient. Boris a făcut 20 în două zile. Nu este o exagerare, ci o adevărată evidență a dezvoltării de către el a funcției de liste de lucruri de făcut a Claude Code. A împărtășit chiar și sugestii și capturi de ecran cu fiecare pas. Să aruncăm o privire asupra modului în care aceste 20 de arhetipuri iterează. În prima versiune, el dorea ca lista de sarcini să apară sub cel mai recent apel al uneltei. Promptul este scurt: "În loc să apară do cu input, afișează o listă fixă de sarcini deasupra casetei de input, cu titlul '/todo (1 of 3)' gri". După ce am analizat efectul, nu am fost foarte mulțumit. În a doua versiune, acesta este afișat în linie la fiecare actualizare ToDo. Prompt: "În loc să afișezi o listă de sarcini, redă numele uneltei într-un titlu îngroșat când modelul începe să proceseze o lucrare." Păstrează afișajul de progres ca "pasul 2 din 4". ” Tot nu e corect. În edițiile a treia și a patra, a încercat să creeze o "pastilă interactivă" – un pătrat mic în partea de jos a ecranului pe care poți da click pentru a vedea progresul. "Adaugă o pastilă de lucru sub caseta de introducere a textului, similară cu o sarcină de fundal, arătând 'todos: 1 din 3'." Apoi: "Fă această pastilă interactivă, ca o pastilă de misiune de fundal." ” E puțin interesant, dar nu suficient de bun. În edițiile a cincea și a șasea, și-a schimbat părerea: să facă un "sertar" care să alunece din dreapta. "Anulează pastilele și titlurile anterioare și afișează în schimb lista de sarcini pe partea dreaptă a casetei de intrare, centrată vertical, separată de un separator gri." "E puțin săltăreț, poți să-l transformi într-o animație de sertar?" Arată interesant, dar practicitatea lui este discutabilă. În edițiile a șaptea și a noua, a mutat lista de sarcini deasupra casetei de intrare și a experimentat cu diferite stiluri de trunchiere și antet. "Dacă sunt mai mult de 5, arată '... și încă 4'", "Adaugă un titlu gri 'Todo:'". Răspunsul se apropie tot mai mult. În edițiile a zecea și douăzecea, a început să învețe cum să combine listele de sarcini cu animațiile de încărcare. Soluția finală este plasarea informațiilor de progres lângă spinner (indicatorul de încărcare) pentru a maximiza vizibilitatea. După lansare, utilizatorii au raportat că doresc să vadă lista completă de sarcini. Așadar, se adaugă o altă iterație: apasă Ctrl+T pentru a extinde toți pașii. Aceasta este versiunea care este acum online.

Pe tot parcursul procesului, temele lui Boris au fost surprinzător de scurte — în mare parte una sau două propoziții. Dar fiecare versiune este un prototip care poate fi rulat efectiv, nu un desen static, nu un PPT. Poate testa și verifica această funcție pentru a simți dacă funcționează bine. Procesul tradițional de dezvoltare a produsului este: idei→ discuții → desenarea wireframe-urilor → realizarea proiectării → dezvoltării → testării → lansarea în direct. Fiecare pas necesită timp, iar fiecare pas poate rămâne blocat. Acum cursul devine: Idee → prompt de o propoziție → prototip executabil → Dacă ceva nu pare potrivit, fă-l din nou. Acest lucru necesită ca dezvoltatorii să-și schimbe mentalitatea pentru a se adapta la acest proces de dezvoltare. În trecut, rolul prototipurilor era să "verifice ideile" – pentru că costul prototipării era ridicat și trebuia să gândești cu atenție înainte de a o face. Acum, prototipurile au devenit "explorarea posibilităților" – pentru că costul realizării prototipurilor este scăzut, le poți face mai întâi și apoi să le arunci. Boris a spus că atunci când folosește Claude Code, adesea sare peste etapa desenării planului și face doar o versiune în rulare, care este mai intuitivă decât orice altceva. Ritmul zilnic al echipei Claude Code este următorul: fiecare inginer execută aproximativ 5 PR-uri pe zi, 60-100 de lansări interne pe zi și 1 lansare externă pe zi. 5 PR-uri pe zi, ceea ce este de neimaginat în majoritatea companiilor. Uber se află în cea mai intensă perioadă de restructurare și nu este rău să poți obține un record personal mediu pe zi. Când uneltele se schimbă, ritmul se schimbă, iar modul de gândire trebuie să se schimbe.

[4] Terminalul de linie de comandă a fost redesenat cu AI integrat Terminalele de linie de comandă există de zeci de ani, de ce trebuie să fie reproiectate acum? Pentru că înainte de LLM-uri, terminalele nu se concentrau prea mult pe experiențe interactive. Linia de comandă tradițională este o întrebare și răspuns: introduci o comandă, aceasta returnează un rezultat și ai terminat. Niciun dialog, niciun context, niciun feedback în timp ce aștepta. Te uiți la cursorul care clipește și nu știi ce se întâmplă în fundal. Claude Code a fost primul produs care a trebuit cu adevărat să se gândească la "terminal UX". Au adăugat câteva detalii mici care păreau neobservate, dar care se simțeau complet diferite când erau folosite. În primul rând: Prompturi contextuale de încărcare. Când modelul gândește, ecranul poate genera prompturi relevante bazate pe afișajul sarcinii curente: de exemplu, "citirea structurii codului" sau "gândirea la o soluție". Este un detaliu mic, dar dă uneltei o "personalitate". Vei simți că muncește din greu și nu e blocat. Boris spune că ultima dată când a văzut un astfel de tip de interacțiune plăcută a fost când Slack era un proces de integrare pentru începători. În al doilea rând: Sfaturi de predare în timp ce aștepți. Când Claude execută o sarcină lungă, partea de jos a ecranului va afișa o rotație de sfaturi, cum ar fi "Poți apăsa Esc pentru a întrerupe sarcina curentă" sau "Încearcă /help pentru a vedea toate comenzile". Linia de comandă este folosită pentru a învăța linia de comandă, ceea ce este simplu și inteligent. A treia poveste este și mai interesantă: randarul Markdown. Cu o zi înainte de lansare, unii ingineri s-au plâns că listele imbricate sunt urâte și că spațierea paragrafelor nu este corectă. Problema este cu rendererul Markdown. Boris a încercat toate randările de pe piață și niciunul nu arăta bine în terminal. Așa că a petrecut o zi folosind Claude Code pentru a scrie un parser și un renderer Markdown de la zero. Da, cu o zi înainte de lansare. Da, scrie de la zero. Da, folosind însuși Claude Code. Ca urmare, acest renderer "grăbit" arată mai bine decât toate soluțiile gata făcute. Au lansat-o direct. Boris crede că niciun alt terminal nu are acum aceeași calitate ca randarea Markdown. Această poveste ilustrează un lucru: când ai un instrument de programare AI suficient de bun, costul "construirii propriilor roți" scade semnificativ. Compromisul de "doar folosește-l" poate deveni acum "atunci fă unul mai bun". Forma veche de interfață a terminalului de linie de comandă este renăscută odată cu adăugarea LLM-urilor. Terminalul rămâne același terminal, dar din cauza adăugării AI, trebuie să ne gândim serios cum să facem oamenii să aibă o conversație mai bună cu AI-ul din terminal.

[5] AI pătrunde în fiecare legătură – un experiment "AI cuprinzător" realizat de o echipă de inginerie Echipa de inginerie a Anthropic este probabil una dintre cele mai extreme utilizări ale uneltelor AI în acest moment. Nu este vorba doar despre scrierea codului, ci despre fiecare aspect al proiectului. Revizuirea codului: Prima revizuire a tuturor PR-urilor este realizată de Claude Code, iar a doua de ingineri. Boris spune că Claude Code poate găsi multe probleme din prima încercare. Această funcție a fost folosită inițial doar intern, dar ulterior au făcut-o publică astfel încât toată lumea să poată folosi Claude Code pentru revizuirea securității. Teste de scriere: Suita de teste a Claude Code este aproape în întregime scrisă de Claude Code. "În trecut, dacă cineva aducea în discuție un record personal și nu scria un test, ezitam să spun ceva — părea o încercare de tip pick-and-point," a spus Boris. Dar acum, cu Claude, scrierea unui test este un cuvânt prompt și nu există nicio scuză să nu-l scrii. ” Răspuns la incidente: Inginerii Oncall îi cer lui Claude Code să ajute la analizarea cauzei principale (cauza principală a problemei). Extrage discuții relevante din Slack, jurnale de erori din Sentry, date din diverse sisteme de monitorizare și le analizează sintetic. Boris spune că Claude Code găsește Cauza Rădăcină mai repede decât o persoană în unele situații. Triajul problemelor pe GitHub: Ori de câte ori apare o problemă nouă, Claude Code va face mai întâi o analiză, iar apoi inginerul va întreba dacă poate fi implementată. Boris spune că cam 20% până la 40% din cazuri se poate face din prima. Grafice și interogări: Datele de produs se află în BigQuery, iar aproape toate interogările și vizualizările sunt generate în Claude Code. Inginerii îi permit chiar să genereze diagrame ASCII direct.

Ceea ce m-a surprins cel mai mult a fost revenirea TDD (dezvoltarea bazată pe teste). TDD este un concept vechi: scrie mai întâi teste, apoi scrie codul care trece testele. În teorie este bun – te forțează să te gândești mai întâi la ce vrei. Dar, în practică, majoritatea oamenilor consideră că este prea lentă și greoaie, așa că această metodă a fost treptat marginalizată în ultimii zece ani. Dar Boris a spus că după ce a folosit Claude Code, a făcut mult TDD: "O să încep prin a cere modelului să scrie un test și să-i spun că testul va pica acum, nu încerca să-l faci să treacă. Apoi i-am cerut să scrie cod pentru a implementa funcția și să lase testul să treacă, dar fără să schimbe testul în sine. ” "Când un model are un obiectiv clar pe care să se dezvolte — cum ar fi un test unitar sau un mock — performează foarte bine." El a menționat în mod specific că Claude 4.0 este prima serie de modele care permite modelelor să scrie majoritatea testelor. Versiunile anterioare puteau scrie o parte, dar necesitau multă intervenție umană. Există și un concept nou: multi-clauding. Aceasta înseamnă rularea simultană a mai multor instanțe de Claude Code, permițându-le să lucreze simultan la sarcini diferite. Sid spune că face adesea asta – să înceapă câțiva agenți în timpul întâlnirilor și să revină mai târziu să vadă rezultatele. Anthropic a constatat că 25% dintre abonații Max (utilizatori premium care costă între 100 și 200 de dolari pe lună) folosesc multi-claude zilnic. Aceasta este o schimbare interesantă. Programarea a fost întotdeauna o activitate "single-threaded": poți face un singur lucru odată și poți schimba sarcinile doar când codul este revizuit sau implementat. Dar acum, "programarea paralelă" este posibilă – poți avansa mai multe lucruri simultan. Desigur, există multe necunoscute aici: munca paralelă este cu adevărat mai eficientă sau pur și simplu pare mai eficientă? Ce tipuri de sarcini sunt potrivite pentru paralelism? Va exista o problemă dacă fiecare agent primește mai puțină atenție? Aceste întrebări nu au fost încă răspunse. Dar avem un nou instrument cu care să experimentăm. În final, să vorbim despre un caz. O companie urma să facă o migrare a cadrului și se estima că va dura doi ani de inginerie – doi ani pentru un inginer, sau două luni și jumătate pentru zece ingineri. Au folosit Claude Code, iar un inginer a făcut-o în două săptămâni. Boris a spus că obișnuia să fie sceptic față de astfel de afirmații, dar au auzit povești similare de prea multe ori.

[6] Hackathon de trei zile - cum s-a născut funcția Subagents Inspirația pentru această funcție din Subagents vine dintr-o postare de pe Reddit. Unii spun că a deschis cinci instanțe Claude Code simultan, a setat roluri diferite pentru fiecare instanță și apoi a folosit sistemul de fișiere pentru a comunica între ei. Când Sid Bidasaria a văzut această postare, prima lui reacție a fost: Acest gameplay este tare, dar utilizatorii nu ar trebui să arunce lucrurile așa. Ar trebui să facem din asta o funcție integrată a produsului. S-a întâmplat ca firma să aibă un hackathon intern de trei zile, iar Sid a decis să folosească acele trei zile pentru asta. În prima zi, echipa a desenat cu entuziasm o varietate de topologii complexe de agenți: comunicare prin magistrală de mesaje între agenți, mod asincron, interacțiuni mulți-la-multe...... Imaginea este conturată superb, iar conceptul este avansat. A doua zi, și-au dat seama că nu părea fezabil să facă asta. Problema nu este implementarea tehnică – se pot crea tipare complexe. Problema este că utilizatorii nu o pot înțelege. Interfața lui Claude Code este un terminal simplu, cum le permiteți utilizatorilor să înțeleagă aceste moduri complexe de comunicare a agenților într-o interfață atât de simplă? Au decis să o ia de la capăt și să revină la întrebarea fundamentală: Care este cea mai simplă formă pe care o poate folosi un dezvoltator obișnuit? Și-au impus două constrângeri: În primul rând, nu inventa nimic nou. Folosește doar capabilitățile pe care Claude Code le are deja - comenzile "/" și fișierele .md. În al doilea rând, nu comunica între agenți. Schimbarea către un model simplu de orchestrare: există un agent master care poate chema agentul copil, iar agentul copil returnează rezultatul după finalizarea sarcinii, și atât. De asemenea, au stat de vorbă cu echipa de cercetare a Anthropic. Cercetătorii lucrează la modele multi-agent, dar concluzia este că încă nu este concludent dacă topologiile complexe ale agenților funcționează cu adevărat. Acest lucru le oferă mai multă încredere: deoarece chiar și echipa de cercetare spune că complexitatea nu este neapărat bună, este mai bine să se facă o versiune simplă. La sfârșitul celei de-a treia zile, au făcut o versiune funcțională. Utilizatorii pot defini rolurile și capabilitățile sub-agenților în fișierele .md (de exemplu, "agenți front-end: folosind React 19 și Next.js"), Claude Code îi va chema când este cazul sau utilizatorul îi poate declanșa manual. După hackathon, după puțină șlefuire, rubrica este activă. Acum poți defini diverși sub-agenți exclusivi: agenți back-end cu expertiză în audit de securitate, agenți front-end familiarizați cu anumite cadre și agenți QA specializați în scrierea testelor...... Ele pot lucra în paralel în fundal, fiecare având propriul său rol. Multe echipe vor fi reticente să-și răstoarne planurile complexe în hackathon, până la urmă, petrec o zi întreagă desenând și discutând, și au sentimente. A putea admite că "acest drum nu funcționează" și să-l răstoarne și să o iei de la zero cere curaj și credință în "simplitate". Simplitatea nu este lene. Cel mai simplu este să găsești formularul pe care utilizatorul îl poate folosi cu adevărat printre nenumăratele posibilități.

[7] Cum va arăta echipa de inginerie în viitor? Unele pot fi folosite ca referință, iar altele nu pot fi copiate Boris a spus: "Programarea e atât de distractivă acum. Ultima dată când m-am simțit așa a fost când am scris cod pe un calculator grafic pentru prima dată, în gimnaziu. Acea senzație magică pe care nu am mai trăit-o de mult timp, dar acum a revenit. ” Sid simte la fel: "Sunt două lucruri care mă entuziasmează. Unul este viteza cu care lansăm – uneori pare prea rapidă. A doua este atât de mult spațiu experimental – deși munca anterioară a fost rapidă, lucrurile pe care le-am făcut au fost mai degrabă de rutină, iar știind care era răspunsul, era doar execuție. Acum e diferit, modelul se schimbă la fiecare trei luni și trebuie să regândim constant modul în care facem lucrurile. ” Aceste sentimente sunt foarte reale și contagioase. Dar înainte de a discuta despre "cum va arăta viitorul echipelor de inginerie", să nu uităm de specificitatea Anthropic. În primul rând, Anthropic este un laborator de cercetare, nu o companie de produse. Misiunea sa principală este să cerceteze siguranța și capacitățile IA, iar produsul este mijlocul, nu scopul. Aceasta înseamnă că au o toleranță mult mai mare la "experimentarea rapidă" decât compania obișnuită. În al doilea rând, produsul lor principal este modelul Claude în sine. Claude Code este doar o "cochilie" a modelului. Așadar, "ștergerea codului pentru a lăsa modelul să facă mai mult" este o alegere naturală pentru ei, dar pentru alte companii poate însemna să dai logica de bază a afacerii unei cutii negre. În al treilea rând, toți angajații au acces nelimitat la Claude, inclusiv la cel mai scump model Opus. În majoritatea companiilor, taxele de abonament la IA reprezintă un buget pentru care trebuie luptat și nu poate fi folosit de toată lumea. În al patrulea rând, echipa are doar o duzină de persoane, iar procesul este minim. Folosesc foarte rar steaguri de funcționalitate pentru că sunt "prea lente". Acest lucru este de neconceput într-un produs cu o bază mare de utilizatori și un cost ridicat de eroare. Așadar, copierea directă a echipei Claude Code nu este neapărat realistă pentru majoritatea echipelor. Dar sunt câteva lucruri de învățat. Mentalitatea de prototipare rapidă: Chiar dacă nu poți face 10 prototipuri pe zi, poți trece de la "unul la două săptămâni" la "trei pe săptămână"? Uneltele s-au schimbat, iar așteptările privind "cât de rapid ar trebui să fie prototipul" ar trebui actualizate. Revizuire a codului asistată de AI: Lasă AI-ul să facă prima revizuire, iar omul să facă a doua revizuire. Acest proces nu se bazează pe acces nelimitat la API, pe care majoritatea echipelor îl pot încerca. Revigorarea TDD: Dacă scrierea testelor devine suficient de ușoară, "lipsa timpului pentru teste" nu mai este o scuză. Acesta poate fi un punct de intrare cu costuri reduse pentru îmbunătățirea calității codului. Valoarea inginerilor orientați spre produs este amplificată: echipa Claude Code nu are designeri sau manageri de proiectare, doar câțiva ingineri preocupați de produs. Instrumentele AI au extins considerabil ceea ce poate face acest "talent full-stack".

Desigur, există unele lucruri care nu pot fi înlocuite de unelte. Boris a reușit să aleagă cel mai bun dintre cele 20 de arhetipuri pentru că era judecător—știa ce "părea corect" și ce pur și simplu "arăta bine". Acest gust este rezultatul a 17 ani de experiență în dezvoltarea software, nu este ceva ce AI-ul poate oferi. Echipa a făcut un plan complex în prima zi, iar a doua zi ar putea să răstoarne fără milă și să o ia de la capăt, ceea ce este tot o judecată umană. A ști când să ștergi codul și când să-l păstrezi este același lucru valabil pentru această intuiție arhitecturală. AI-ul face execuția mai rapidă, dar nu face "să știi ce să faci" mai ușor. În schimb, deoarece costul de execuție a scăzut, decizia "ce să faci" a devenit mai importantă – poți face rapid 20 de versiuni, dar trebuie să știi care este corectă. Cum va arăta ingineria software peste câțiva ani? Nimeni nu poate prezice cu precizie. Dar echipa Claude Code de astăzi ar putea fi un fel de repetiție pentru mâine pentru multe echipe – iterații mai rapide, mai puțină "mișcare a cărămizilor", mai multă judecată și luare a deciziilor. Uneltele se schimbă. Ceea ce rămâne neschimbat este că tot oamenii iau decizia finală.