Katsotaanpa Claude Coden syntytarinaa, joka perustuu pääasiassa teknologiabloggaaja Gergely Oroszin haastatteluun Claude Coden ydinjäsenestä. Claude Code on todella merkittävä, sillä vuosittainen liikevaihto on 500 miljoonaa dollaria ja käyttäjämäärä on kasvanut kymmenkertaiseksi kolmessa kuukaudessa, ja se on nyt monien ohjelmoijien suosituin koodausagenttityökalu. Tämä työkalu alkoi pienenä komentorivileluna, joka kertoi "mitä kappaletta kuuntelet juuri nyt." 🧵

Gergely Orosz haastatteli kolmea Claude Code -ryhmän ydinjäsentä: • Boris Cherny, perustava insinööri (17 vuotta kokemusta, entinen Meta-pääinsinööri) • Insinööri 2 Sid Bidasaria (Subagents-ominaisuuden kirjoittaja) • ja Cat Wu, tuotepäällikkö. He kertoivat, miten Claude Code siirtyi prototyypistä tuotteeksi, millaisia teknisiä valintoja he tekivät ja miten pieni, tusinan hengen tiimi pystyi julkaisemaan 5 ennätystä päivässä. Tämä on todennäköisesti lähin esimerkki "tekoäly-ensisijaisesta insinööritiimistä" tällä hetkellä. He käyttävät tekoälyä koodin kirjoittamiseen, testien tekemiseen, koodin tarkistuksiin, vianetsintään ja jopa Claude-koodin kehittämiseen. 90 % koodista kirjoitetaan itse. Haluan järjestää tämän haastattelun mielenkiintoisimmat osat, puhua siitä, miten tämä tiimi toimii, mitä voidaan oppia ja mikä määräytyy heidän erityisolosuhteidensa perusteella eikä sitä voi kopioida. Seuraava on jaettu seitsemään novelliin, joista jokainen voidaan lukea itsenäisesti, ja ne on sidottu yhteen kokonaiskuvaksi.

[1] Kuinka kuuntelulaite voi muuttua tuotteeksi, jonka vuositulot ovat 500 miljoonaa dollaria Syyskuussa 2024 Boris Cherny liittyi juuri Anthropiciin ja kirjoitti komentorivilelun, kun hänellä ei ollut mitään tekemistä. Mitä tämä voi tehdä? Se käyttää AppleScriptiä kertoakseen, mitä kappaletta kuuntelet, ja muuttaa kappaletta käskyjesi mukaan. Se on niin yksinkertaista. Boris itse kommentoi: "Aika siisti demo, mutta ei mielenkiintoinen. ”

Todellinen käänne tuli, kun hän oli lopettanut juttelun kollegansa Cat Wun kanssa. Cat tutki tekoälyagentin tietokoneominaisuuksia, ja keskustellessaan Borisilla oli idea: entä jos antaisimme tälle komentorivityökalulle enemmän oikeuksia? Esimerkiksi, antaisiko sen pystyä lukemaan ja kirjoittamaan tiedostoja sekä suorittamaan komentoja?

Hän yritti. Sitten tulee hetki todistaa ihme. Boris heitti päivitetyn työkalun Anthropicin koodipohjaan ja esitti muutaman kysymyksen. Claude alkoi tutkia tiedostojärjestelmää yksin—luki tiedostoa, näki sisällä olevan tuontilauseen ja sitten luki viitatun tiedoston, kaivaen kerros kerrokselta, kunnes löysi vastauksen. "Se järkytti minua," Boris muistelee, "enkä ollut koskaan käyttänyt tällaista työkalua. ”

Tekoälyn alalla on käsite nimeltä "tuotteen ylijäämä", joka tarkoittaa "tuotteen ylijääkettä". Tämä tarkoittaa, että mallilla on tietty kyky, mutta olemassa oleva tuotemuoto ei vapauta tätä kykyä. Boris löysi valtavan "tuotteen ylijäämän", jonka Claude olisi voinut tehdä jo kauan sitten, mutta kukaan ei ollut rakentanut sille kuorta.

Boris alkoi käyttää työkalua päivittäin ja jakoi sen sitten useille kollegoille. Kaksi kuukautta myöhemmin, marraskuussa, he julkaisivat buildin. Tiedot ovat liioiteltuja: ensimmäisenä päivänä 20 % insinööreistä on käytössä; Päivä 5, 50%.

Tässä vaiheessa nousee mielenkiintoinen keskustelu: pitäisikö se julkaista ulkomaailmalle? Vastustuksen syy on hyvin todellinen: jos tämä asia on todella niin vahva kuin luulemme, eikö olisi hyvä pitää se "salaisena aseena"? Miksi luopua kilpailuedusta? Lopulta Anthropic päätti julkaista. Logiikka on tämä: Anthropicin ydintehtävä on tutkia mallien turvallisuutta, ja paras tapa tutkia turvallisuutta on oikeasti käyttää näitä työkaluja. Nyt kun Claude-koodi on sisäisesti vahvistettu laajasti käytettäväksi, sen julkaiseminen antaa enemmän tietoa mallin kyvykkyyksistä ja turvallisuudesta.

Toukokuussa 2025 Claude Code julkaistiin virallisesti. Kolme kuukautta myöhemmin käyttö on kasvanut kymmenkertaiseksi ja vuosittainen liikevaihto ylittää 500 miljoonaa dollaria. Mielenkiintoista on, että Boris oli alun perin tarkoitettu ohjelmoijille – tästä juontuu nimi "Claude Code". Mutta eräänä päivänä hän käveli datatieteilijän työpisteen ohi ja löysi Claude Coden toiselta näytöltä. "Miksi käytät tätä?" "Pyysin sitä auttamaan minua kirjoittamaan kyselyitä ja visualisoimaan." Nyt Anthropicin datatieteilijöillä on yksi käsillä, ja jotkut ajavat useita yhtä aikaa. Kuuntelulaite, koska sille annettiin muutama lisälupa, muuttui satojen miljoonien dollarien arvoiseksi tuotteeksi. Tämä on luultavasti paras todiste "tuotteen ylikuormituksesta", mallin kyky on aina olemassa, odottamassa, että joku julkaisee sen.

[2] 90 % koodista on itse kirjoitettu – Claude Coden tekninen valintafilosofia Claude-koodilla on 90 % omasta koodistaan. Kuulostaa tempulta, mutta se johtuu itse asiassa heidän teknisestä päätöksentekologiikastaan. Katsotaanpa ensin teknologiapinoa: TypeScript kirjoittaa päärungon, React käyttää Ink-kehystä päätekäyttöliittymänä, Metan avoimen lähdekoodin Yoga hoitaa asettelujärjestelmän ja Bun vastaa rakentamisesta ja paketoinnista. Miksi valita nämä teknologiapinot? Koska ne ovat "jakelun sisällä". "Jakelusta" on termi tekoälyn alalla. Tämä tarkoittaa, että malli on nähnyt paljon tämänkaltaista koodia ja osaa käsitellä niitä hyvin. TypeScript ja React ovat juuri ne kohdat, joissa Claude on vahva. Jos valitset epäsuositun viitekehyksen, mallin täytyy "oppia", ja vaikutus heikkenee. Tämä valinta johtaa upeaan sykliin: kirjoita Claude-koodi teknologiapinolla, jossa Claude on hyvä, ja sitten lisää Claude-koodia Claude-koodilla. 90 % kirjoita itsestäsi, näin se syntyi. Heidän valintansa arkkitehtonisella tasolla ovat yhtä ytimekkäitä. Claude Code toimii paikallisesti. Docker-kontteja ei ole, ei pilvihiekkalaatikkoa, vain tiedostojen lukeminen ja kirjoittaminen sekä komentojen suorittaminen suoraan tietokoneellasi.

Miksi se on suunniteltu näin? Boris vastaa: "Joka kerta kun teemme suunnittelupäätöksen, valitsemme lähes aina yksinkertaisimman ratkaisun. Paikallisesti ajaminen on yksinkertaisin ratkaisu. ” Tämä yksinkertaisuus ulottuu koko tuotefilosofiaan: kirjoita mahdollisimman vähän liiketoimintalogiikkaa ja anna mallin olla päähenkilö. "Se saattaa kuulostaa hieman oudolta," Boris sanoi, "mutta haluamme, että käyttäjät kokevat mallin mahdollisimman 'aidolla'. Monet tekoälytuotteet lisäävät joukon tukirakenteita—lisäkäyttöelementtejä, saavutettavuusominaisuuksia—ja tuloksena malli on rajallinen. Haluamme tehdä käyttöliittymästä mahdollisimman tiiviin. ” Yksinkertaisuuden vuoksi, aina kun Claude julkaisee uuden mallin, koodia virtaviivastetaan paljon. Esimerkiksi kun Claude 4.0 julkaistiin, he poistivat noin puolet järjestelmäkehotteista, koska uusi malli ei enää tarvinnut näitä "tukikeinoja". Työkalujen määrää myös virtaviivaistetaan—poista jos voit, yhdistä jos voit. Koko Claude Code -arkkitehtuuri voidaan tiivistää kolmeen asiaan: käyttöliittymän määrittelyyn ja rajapinnan altistamiseen mallin muokkaukselle, työkalujen esittelyyn, joita malli voi kutsua, ja sitten sivuuttamiseen. Tietenkään yksinkertaisuus ei tarkoita, etteikö osia olisi monimutkaisia. Käyttöoikeusjärjestelmä on poikkeus. Loppujen lopuksi tekoälyn antaminen suorittaa komentoja tietokoneellasi on riskialtista. Claude Coden ratkaisu on kysyä sinulta ennen suoritusta: Haluatko hyväksyä tämän operaation? Voit hyväksyä sen vain tällä kertaa, hyväksyä myöhemmin tai hylätä. Käyttöoikeusjärjestelmä tukee monikerroksista konfiguraatiota – projektia kohden, käyttäjää kohden, yritystä kohden. Teams voi jakaa profiileja ja sallia yleisesti käytetyt turvakomennot. Tämän lupasuunnittelun periaatteet ovat seuraavat: Jos aloitat Claude Coden, sen ei pitäisi muuttaa mitään ilman suostumustasi. Mutta samalla on myös tarpeen antaa käyttäjille mahdollisuus "delegoida" – luottamuksen tapauksessa voit ohittaa vahvistuslinkin. Yksinkertaista, mutta ei alkeellista. Pidättyväisyys, mutta ei toiminnan puute.

[3] 20 prototyyppiä kahdessa päivässä – miltä tuotteen iterointi näyttää tekoälyn aikakaudella Aiemmin, kun tein tuoteprototyyppejä, pystyin tekemään kaksi kahdessa päivässä, mikä oli tehokasta. Boris teki 20 kahdessa päivässä. Tämä ei ole liioittelua, vaan todellista tallennetta hänen kehityksestään Claude Coden tehtävälista-ominaisuudesta. Hän jakoi jopa kehotuksia ja kuvakaappauksia jokaisesta askeleesta. Katsotaanpa, miten nämä 20 arkkityyppiä toistuvat. Ensimmäisessä versiossa hän halusi, että tehtävälista näkyisi viimeisimmän työkalukutsun alapuolelle. Kehote on lyhyt: "Sen sijaan, että tehtävät ilmestyisivät syötteen kanssa, näytä kiinteä tehtävälista syötelaatikon yläpuolella, otsikolla '/todo (1 of 3)' harmaana". Kun katsoin vaikutusta, en ollut kovin tyytyväinen. Toisessa versiossa se näytetään rivissä jokaisen ToDo-päivityksen yhteydessä. Kehote: "Sen sijaan, että näytettäisiin tehtävälista, renderöi työkalun nimi lihavoidulla otsikolla, kun malli alkaa käsitellä tehtävää." Pidä edistymisnäyttö 'vaihe 2/4'. ” Ei vieläkään oikein. Kolmannessa ja neljännessä painoksessa hän yritti tehdä "interaktiivisen pillerin" – pienen ruudun ruudun alareunassa, jota voi klikata nähdäksesi edistymisen. "Lisää tehtäväpilleri tekstin syöttökentän alle, joka muistuttaa taustatehtävää, näyttäen 'tehtävät: 1/3'." Sitten: "Tee tästä pilleristä interaktiivinen, kuin taustatehtäväpilleri." ” Se on vähän mielenkiintoinen, mutta ei tarpeeksi hyvä. Viidennessä ja kuudennessa painoksessa hän muutti mielensä: tehdä "laatikko", joka liukuu ulos oikealta. "Peruuta aiemmat pillerit ja otsikot, ja näytä tehtävälista syötelaatikon oikealla puolella, keskitettynä pystysuoraan, harmaalla jakajalla erotettuna." "Se on vähän nykivä, voisitko tehdä siitä laatikon animaation?" Se näyttää siistiltä, mutta sen käytännöllisyys on kyseenalaista. Seitsemännessä ja yhdeksännessä painoksessa hän siirsi tehtävälistan syöttölaatikon yläpuolelle ja kokeili erilaisia katkaisu- ja otsikkotyylejä. "Jos niitä on enemmän kuin viisi, se näyttää '... ja 4 lisää'", "Lisää harmaa 'Todo:' -otsikko". Vastaus on tulla yhä lähemmäs. Kymmenennessä ja kahdeskymmenennessä painoksessa hän alkoi oppia, miten yhdistää tehtävälistat latausanimaatioihin. Lopullinen ratkaisu on sijoittaa edistymistiedot spinnerin (latausindikaattorin) viereen näkyvyyden maksimoimiseksi. Julkaisun jälkeen käyttäjät kertoivat haluavansa nähdä koko tehtävälistan. Joten lisätään toinen iterointi: paina Ctrl+T laajentaaksesi kaikki vaiheet. Tämä on versio, joka on nyt verkossa.

Koko prosessin ajan Boriksen vihjeet olivat yllättävän lyhyitä – enimmäkseen yksi tai kaksi lausetta. Mutta jokainen versio on prototyyppi, joka voidaan oikeasti ajaa, ei staattinen piirros, ei PPT. Hän voi todella testata ja varmistaa tämän toiminnon ja tuntea, toimiiko se hyvin. Perinteinen tuotekehitysprosessi on: idea→ keskustelu → lankakehysten piirtäminen → korkean tarkkuuden suunnittelu → kehitys → testaus → käyttöönotto. Jokainen askel vie aikaa, ja jokainen askel voi jäädä jumiin. Nyt kulku muuttuu: Idea → Yhden lauseen kehote → Suoritettava prototyyppi → Jos jokin ei tunnu oikealta, tee se uudelleen. Tämä vaatii kehittäjiltä ajattelutavan muuttamista sopeutuakseen tähän kehitysprosessiin. Aiemmin prototyyppien rooli oli "vahvistaa ideoita" – koska prototyyppien tekemisen kustannukset olivat korkeat, ja piti miettiä tarkkaan ennen sen tekemistä. Nyt prototyypeistä on tullut "mahdollisuuksien tutkimista" – koska prototyyppien valmistuskustannukset ovat alhaiset, ne voi ensin tehdä ja sitten heittää pois. Boris sanoi, että Claude Code -menetelmää käytettäessä hän usein jättää piirustuksen vaiheen väliin ja tekee vain juoksevan version, joka on intuitiivisempi kuin mikään muu. Claude Code -tiimin päivittäinen rytmi on seuraava: jokainen insinööri julkaisee noin 5 ennätystä päivässä, 60–100 julkaisua sisäisesti päivässä ja yhden ulkoisen julkaisun päivässä. 5 ennätystä päivässä, mikä on useimmissa yrityksissä käsittämätöntä. Uber on intensiivisimmässä uudelleenjärjestelyvaiheessa, eikä ole huono asia pystyä tekemään keskikokoista ennätystä päivässä. Kun työkalut vaihtuvat, rytmi muuttuu ja ajattelutapa täytyy muuttua.

[4] Komentoriviterminaalin uudistettu integroidulla tekoälyllä Komentorivipäätteet ovat olleet olemassa vuosikymmeniä, miksi ne pitäisi suunnitella uudelleen nyt? Koska ennen LLM:iä terminaalit eivät keskittyneet liikaa interaktiivisiin kokemuksiin. Perinteinen komentorivi on kysymys ja vastaus: syötät komennon, se palauttaa tuloksen, ja olet valmis. Ei dialogia, ei kontekstia, ei palautetta odotellessa. Tuijotat vilkkuvaa kursoria etkä tiedä, mitä taustalla tapahtuu. Claude Code oli ensimmäinen tuote, joka todella tarvitsi ajatella "terminal UX:tä". He lisäsivät muutamia pieniä yksityiskohtia, jotka näyttivät huomaamattomilta, mutta tuntuivat täysin erilaisilta käytössä. Ensiksi: Kontekstuaaliset latauskehotteet. Kun malli ajattelee, näyttö voi tuottaa relevantteja kehotuksia nykyisen tehtävän perusteella: esimerkiksi "koodirakenteen lukeminen" tai "ratkaisun pohtiminen". Se on pieni yksityiskohta, mutta se antaa työkalulle "persoonallisuuden". Sinusta tuntuu, että se tekee kovasti töitä eikä jää jumiin. Boris kertoo, että viimeksi hän näki tällaista hauskaa pientä vuorovaikutusta, kun Slack oli aloittelija perehdytysprosessissa. Toiseksi: Opetusvinkkejä odotellessa. Kun Claude suorittaa pitkää tehtävää, näytön alareunassa näkyy kierron vinkkejä, kuten "Voit painaa Esc-näppäintä keskeyttääksesi nykyisen tehtävän" tai "Yritä /auttaa nähdäksesi kaikki komennot". Komentoriviä käytetään komentorivin opettamiseen, mikä on yksinkertaista ja älykästä. Kolmas tarina on vieläkin jännittävämpi: Markdown-renderöinti. Päivää ennen julkaisua jotkut insinöörit valittivat, että sisäkkäiset listat olivat rumia ja kappaleiden väli ei ollut oikea. Ongelma on Markdown-renderöijässä. Boris kokeili kaikkia markkinoilla olevia renderöijiä, eikä mikään niistä näyttänyt hyvältä terminaalissa. Niinpä hän vietti päivän Claude Codea käyttäen kirjoittaakseen Markdown-jäsentäjän ja renderöijän alusta alkaen. Kyllä, päivää ennen julkaisua. Kyllä, kirjoita alusta asti. Kyllä, käyttäen itse Claude Codea. Tämän seurauksena tämä "kiireinen" renderöinti näyttää paremmalta kuin kaikki valmiit ratkaisut. He julkaisivat sen suoraan. Boris uskoo, ettei mikään muu pääte enää tarjoa yhtä laadukasta Markdown-renderöintiä. Tämä tarina havainnollistaa yhtä asiaa: kun sinulla on tarpeeksi hyvä tekoälyohjelmointityökalu, "omien pyörien rakentamisen" kustannukset laskevat merkittävästi. Kompromissi "käytä sitä vain" voi nyt muuttua "tee parempi". Muinaisen komentoriviterminaalin käyttöliittymämuoto on syntymässä uudelleen LLM-järjestelmien myötä. Terminaali on edelleen sama terminaali, mutta tekoälyn lisäämisen vuoksi meidän täytyy vakavasti miettiä, miten saada ihmiset käymään parempaa keskustelua terminaalin tekoälyn kanssa.

[5] Tekoäly läpäisee jokaisen linkin – insinööritiimin "kattava tekoäly"-koe Anthropicin insinööritiimi on luultavasti yksi tekoälytyökalujen äärimmäisimmistä käyttökohteista tällä hetkellä. Kyse ei ole pelkästään koodin kirjoittamisesta, vaan koko projektin osa-alueesta. Koodien tarkistus: Ensimmäisen kaikkien PR-arviointien tekee Claude Code ja toisen insinöörit. Boris sanoo, että Claude-koodi voi löytää paljon ongelmia ensimmäisellä kierroksella. Tätä ominaisuutta käytettiin alun perin vain sisäisesti, mutta myöhemmin se julkaistiin, jotta kaikki voisivat käyttää Claude-koodia tietoturvatarkastukseen. Kirjoitustestit: Claude Coden testisarja on lähes kokonaan Claude Coden kirjoittama. "Aiemmin, jos joku toi esiin PR:n eikä kirjoittanut testiä, epäröin sanoa mitään — se tuntui kuin poimimiselta," Boris sanoi. Mutta nyt Clauden kanssa kokeen kirjoittaminen on kehotussana, eikä ole mitään tekosyytä olla kirjoittamatta sitä. ” Tapahtumiin reagointi: Oncallin insinöörit pyytävät Claude Codelta apua ongelman juurisyyn (ongelman juurisyyn) analysointiin. Se hakee olennaisia keskusteluja Slackista, virhelokit Sentryltä, dataa eri valvontajärjestelmistä ja analysoi ne synteettisesti. Boris sanoo, että Claude Code löytää juuren nopeammin kuin ihminen joissain tilanteissa. GitHub-ongelman triage: Aina kun uusi ongelma tulee, Claude Code tekee ensin analyysin, ja sitten insinööri kysyy, voiko sen toteuttaa. Boris sanoo, että noin 20–40 % ajasta se onnistuu ensimmäisellä kerralla. Kaaviot ja kyselyt: Tuotetiedot sijaitsevat BigQueryssä, ja lähes kaikki kyselyt ja visualisoinnit luodaan Claude-koodilla. Insinöörit antavat jopa ASCII-kaavioiden suoraan tuottamisen.

Eniten minua yllätti TDD:n (test-driven development) uudelleen nousu. TDD on vanha käsite: kirjoita ensin testit ja sitten koodi, joka läpäisee testit. Teoriassa se on hyvä – pakottaa sinut ensin miettimään, mitä haluat. Mutta käytännössä useimmat ihmiset pitävät sitä liian hitaana ja kömpelönä, joten tämä menetelmä on vähitellen jäänyt marginaaliin viimeisen kymmenen vuoden aikana. Mutta Boris sanoi, että Claude-koodin käytön jälkeen hän teki paljon TDD:tä: "Aloitan pyytämällä mallia kirjoittamaan testin ja kerron sille, että testi epäonnistuu nyt, älä yritä saada sitä läpi. Sitten pyysin sitä kirjoittamaan koodin funktion toteuttamiseksi ja antamaan testin mennä läpi, mutta ei muuttaa itse testiä. ” "Kun mallilla on selkeä tavoite iterointiin—kuten yksikkötesti tai harjoitus—se suoriutuu erittäin hyvin." Hän mainitsi erityisesti, että Claude 4.0 on ensimmäinen mallisarja, jossa mallit voivat kirjoittaa suurimman osan testeistä. Aiemmat versiot pystyivät kirjoittamaan roolin, mutta vaativat paljon ihmisen väliintuloa. On myös uusi konsepti: moniklaudointi. Tämä tarkoittaa useiden Claude Code -instanssien ajamista samanaikaisesti, jolloin he voivat työskennellä eri tehtävien parissa rinnakkain. Sid sanoo tekevänsä näin usein – aloittavansa muutaman agentin kokouksissa ja palaavansa myöhemmin katsomaan tuloksia. Anthropic havaitsi, että 25 % Maxin tilaajista (premium-käyttäjät, joiden hinta on $100–$200 kuukaudessa) käyttää monintiimiä joka päivä. Tämä on mielenkiintoinen muutos. Ohjelmointi on aina ollut "yksisäikeistä" toimintaa: voit tehdä vain yhtä asiaa kerrallaan ja vaihtaa tehtäviä vain, kun koodia tarkastellaan tai otetaan käyttöön. Mutta nyt "rinnakkaisohjelmointi" on mahdollista – voit edistää useita asioita yhtä aikaa. Tietenkin tässä on paljon tuntemattomia: onko rinnakkaistyö todella tehokkaampaa vai tuntuuko se vain tehokkaammalta? Millaiset tehtävät sopivat rinnakkaisuuteen? Tuleeko ongelma, jos jokainen agentti saa vähemmän huomiota? Näihin kysymyksiin ei ole vielä vastattu. Mutta meillä on uusi työkalu kokeiltavaksi. Lopuksi puhutaan tapauksesta. Yritys aikoi tehdä kehysmigraatiota, ja arvioitiin, että se veisi kaksi insinöörivuotta – kaksi vuotta yhdelle insinöörille tai kaksi ja puoli kuukautta kymmenelle insinöörille. He käyttivät Claude Codea, ja yksi insinööri teki sen kahdessa viikossa. Boris sanoi, että hän oli aiemmin skeptinen tällaisia väitteitä kohtaan, mutta he ovat kuulleet samanlaisia tarinoita liian monta kertaa.

[6] Kolmen päivän hackathon – miten Subagents-ominaisuus syntyi Tämän ominaisuuden inspiraation lähteenä Subagentsissa on Reddit-postaus. Jotkut sanovat, että hän avasi viisi Claude Code -instanssia samanaikaisesti, asetti eri roolit jokaiselle instanssille ja käytti tiedostojärjestelmää kommunikoidakseen keskenään. Kun Sid Bidasaria näki tämän postauksen, hänen ensimmäinen reaktionsa oli: Tämä pelattavuus on siistiä, mutta käyttäjien ei pitäisi joutua heittämään näin. Meidän pitäisi tehdä siitä tuotteen sisäänrakennettu toiminto. Sattumalta yrityksellä oli kolmen päivän sisäinen hackathon, ja Sid päätti käyttää ne kolme päivää siihen. Ensimmäisenä päivänä tiimi piirsi innokkaasti erilaisia monimutkaisia agenttitopologioita: viestiväylän viestintää agenttien välillä, asynkronista tilaa, monen ja monen välillä vuorovaikutuksia...... Kuva on kauniisti piirretty ja konsepti edistynyt. Seuraavana päivänä he tajusivat, ettei se vaikuttanut mahdolliselta. Ongelma ei ole tekninen toteutus – monimutkaisia kuvioita voidaan tehdä. Ongelma on, että käyttäjät eivät ymmärrä sitä. Claude Coden käyttöliittymä on yksinkertainen päätelaite, miten käyttäjät ymmärtävät monimutkaisia agenttien viestintätapoja näin yksinkertaisessa käyttöliittymässä? He päättivät aloittaa alusta ja palata peruskysymykseen: Mikä on yksinkertaisin muoto, jota keskiverto kehittäjä voi käyttää? He asettivat itselleen kaksi rajoitetta: Ensinnäkin, älä keksi mitään uutta. Käytä vain Claude Codella jo olevia ominaisuuksia – "/"-komentoa ja .md-tiedostoja. Toiseksi, älä kommunikoi agenttien välillä. Muutos yksinkertaiseen orkestrointimalliin: on master-agentti, joka voi kutsua lapsiagentin, ja lapsiagentti palauttaa tuloksen tehtävän suorittamisen jälkeen, ja siinä kaikki. He myös juttelivat Anthropicin tutkimusryhmän kanssa. Tutkijat työskentelevät moniagenttien mallien parissa, mutta johtopäätös on, että on edelleen epävarmaa, toimivatko monimutkaiset agenttitopologiat todellisuudessa. Tämä antaa heille lisää itsevarmuutta: koska jopa tutkimusryhmä sanoo, että monimutkaisuus ei välttämättä ole hyvä, on parempi tehdä yksinkertainen versio. Kolmannen päivän lopussa he tekivät toimivan version. Käyttäjät voivat määritellä aliagenttien roolit ja ominaisuudet .md-tiedostoissa (esim. "front-end agentit: käyttäen React 19:ää ja Next.js"), Claude Code kutsuu ne tarvittaessa tai käyttäjä voi käynnistää ne manuaalisesti. Hackathonin jälkeen, pienen hiotuksen jälkeen, ominaisuus on livenä. Nyt voit määritellä erilaisia eksklusiivisia aliagentteja: taustaagentit, joilla on tietoturvaauditointiosaamista, front-end-agentit, jotka tuntevat tietyt kehykset, ja QA-agentit, jotka erikoistuvat testien kirjoittamiseen...... He voivat työskennellä rinnakkain taustalla, jokainen hoitaen omaa rooliaan. Monet joukkueet epäröivät kumota monimutkaisia suunnitelmiaan hackathonissa, sillä he käyttävät kokonaisen päivän piirtäen ja keskustellen, ja heillä on tunteita. Kyky myöntää, että "tämä tie ei toimi", kaataa se ja aloittaa alusta vaatii rohkeutta ja uskoa "yksinkertaisuuteen". Yksinkertaisuus ei ole laiskuutta. Yksinkertainen asia on löytää muoto, jota käyttäjä voi käyttää lukemattomien mahdollisuuksien joukosta.

[7] Millainen insinööritiimi tulee olemaan tulevaisuudessa? Jotkut voidaan käyttää viitteinä, ja toisia ei voi kopioida Boris sanoi: "Ohjelmointi on nyt niin hauskaa. Viimeksi tunsin näin, kun kirjoitin koodia graafiseen laskimeen ensimmäistä kertaa yläasteella. Se taianomainen tunne, jota en ole kokenut pitkään aikaan, mutta nyt se on palannut. ” Sid tuntee samoin: "Minua innostaa kaksi asiaa. Yksi on se nopeus, jolla vapautumme – joskus se tuntuu liian nopealta. Toinen on niin paljon kokeellista tilaa – vaikka edellinen työ oli nopeaa, tekemäni asiat olivat rutiininomaisempia, ja kun tiesin vastauksen, kyse oli vain toteutuksesta. Nyt tilanne on erilainen, malli vaihtuu kolmen kuukauden välein, ja meidän täytyy jatkuvasti miettiä uudelleen, miten teemme asioita. ” Nämä tunteet ovat hyvin todellisia ja tarttuvia. Mutta ennen kuin keskustelemme "miltä insinööritiimien tulevaisuus tulee näyttämään", älkäämme unohtako Anthropicin erityispiirteitä. Ensinnäkin Anthropic on tutkimuslaboratorio, ei tuoteyritys. Sen ydintehtävänä on tutkia tekoälyn turvallisuutta ja kykyjä, ja tuote on väline, ei päämäärä. Tämä tarkoittaa, että heillä on paljon korkeampi sietokyky "nopealle kokeilulle" kuin keskimääräisellä yrityksellä. Toiseksi heidän päätuotteensa on itse Claude-malli. Claude Code on vain mallin "kuori". Joten "koodin poistaminen, jotta malli voisi tehdä enemmän" on heille luonnollinen valinta, mutta muille yrityksille se voi tarkoittaa ydinliiketoiminnan logiikan antamista mustalle laatikolle. Kolmanneksi, kaikilla työntekijöillä on rajattomasti pääsy Claudeen, mukaan lukien kallein Opus-malli. Useimmissa yrityksissä tekoälyn tilausmaksut ovat budjetti, josta täytyy taistella, eikä kaikkia voi käyttää niihin. Neljänneksi, tiimissä on vain tusina henkilöä, ja prosessi on minimaalinen. He käyttävät harvoin ominaisuuslippuja, koska ne ovat "liian hitaita". Tämä on käsittämätöntä tuotteessa, jossa on suuri käyttäjäkunta ja korkeat virhekustannukset. Siksi Claude Code -tiimin suora kopioiminen ei ole välttämättä realistista useimmille tiimeille. Mutta on asioita, joista voi oppia. Nopea prototyyppien ajattelutapa: Vaikka et pystyisi tekemään 10 prototyyppiä päivässä, voitko vaihtaa "yhden kahden viikon välein" -prototyyppistä "kolmeen viikossa"? Työkalut ovat muuttuneet, ja odotukset siitä, kuinka nopeasti prototyypin pitäisi olla, pitäisi päivittää. Tekoälyavusteinen koodin tarkistus: Anna tekoälyn tehdä ensimmäinen kertaus ja ihmisen tehdä toinen. Tämä prosessi ei perustu rajattomaan API-käyttöön, jota useimmat tiimit voivat kokeilla. TDD:n herääminen: Jos testien kirjoittaminen muuttuu helpoksi, "ei aikaa kirjoittaa testejä" ei enää ole tekosyy. Tämä voi olla edullinen aloituspiste koodin laadun parantamiseksi. Tuotesuuntautuneiden insinöörien arvo kasvaa: Claude Code -tiimissä ei ole suunnittelijoita tai projektipäälliköitä, vain muutama tuotesuuntautunut insinööri. Tekoälytyökalut ovat laajentaneet merkittävästi tämän "full-stack talentin" mahdollisuuksia.

Tietenkin on asioita, joita ei voi korvata työkaluilla. Boris pystyi valitsemaan parhaan 20 arkkityypistä, koska hän oli tuomitseva – hän tiesi, mikä "tuntui oikealta" ja mikä vain "näytti hyvältä". Tämä maku on 17 vuoden ohjelmistokehityskokemuksen tulos, ei mitään, mitä tekoäly voi tarjota. Tiimi teki monimutkaisen suunnitelman ensimmäisenä päivänä, ja seuraavana päivänä he saattoivat armottomasti kääntää päätöksen ja aloittaa alusta, mikä on myös inhimillinen tuomio. Tieto siitä, milloin koodia pitää poistaa ja milloin säilyttää, pätee tähän arkkitehtoniseen intuitioon. Tekoäly nopeuttaa toteutusta, mutta se ei tee "mitä tehdä" helpommaksi. Sen sijaan, koska toteutuksen kustannukset ovat laskeneet, "mitä tehdä" -päätös on tullut tärkeämmäksi – voit tehdä 20 versiota nopeasti, mutta sinun täytyy tietää, mikä niistä on oikea. Miltä ohjelmistokehitys näyttää muutaman vuoden kuluttua? Kukaan ei voi ennustaa tarkasti. Mutta Claude Code -tiimi saattaa tänään olla jonkinlainen harjoitus huomista varten monille tiimeille – nopeammat versiot, vähemmän "tiilien siirtämistä", enemmän harkintaa ja päätöksentekoa. Työkalut muuttuvat. Mikä pysyy muuttumattomana, on se, että lopullisen päätöksen tekevät yhä ihmiset.