Claude Code'un doğum hikayesine bakalım; esas olarak teknoloji blog yazarı Gergely Orosz ile Claude Code'un çekirdek üyelerinden biri hakkında yapılan röportajdan alınmıştır. Claude Code gerçekten olağanüstü; yıllık geliri 500 milyon dolar ve kullanıcı hacmi üç ayda 10 kat arttı; şimdi birçok programcı için tercih edilen Kodlama Ajanı aracı haline geldi. Bu araç başlangıçta "şu anda hangi şarkıyı dinlediğini" söyleyen küçük bir komut satırı oyuncağı olarak başladı. 🧵

Gergely Orosz, Claude Code'un üç temel üyesiyle röportaj yaptı: • Boris Cherny, Kurucu Mühendis (17 yıllık deneyim, eski Meta Baş Mühendisi) • Mühendis 2 Sid Bidasaria (Subagents özelliğinin yazarı) • ve Cat Wu, Ürün Müdürü. Claude Code'un prototipten ürüne nasıl geçtiğini, hangi teknik seçimleri yaptıklarını ve bir düzine kişilik küçük ekibin günde 5 PR yayınlayabildiğini anlattılar. Şu anda muhtemelen "yapay zeka öncelikli mühendislik ekibi"ne en yakın örnek. Kod yazmak, testler yazmak, kod incelemeleri yapmak, sorun gidermek ve hatta Claude Code'u geliştirmek için yapay zeka kullanıyorlar. Kodun %90'ı kendi başına yazılır. Yapmak istediğim şey, bu röportajın en ilginç kısımlarını çözmek, bu ekibin nasıl çalıştığını, neler öğrenilebileceğini ve özel koşullarına bağlı olarak nelerin belirlendiğini ve kopyalanamayacaklarını konuşmak. Aşağıdaki kitap, her biri bağımsız okunabilen 7 kısa hikayeye ayrılmıştır ve tam bir tablo oluşturmak için birbirine bağlanmıştır.

[1] Bir dinleme cihazının yıllık 500 milyon dolar gelirli bir ürüne nasıl dönüşebileceği Eylül 2024'te Boris Cherny, Anthropic'e katıldı ve yapacak bir işi yokken komut satırı oyuncağı yazdı. Bu şey ne yapabilir? AppleScript kullanarak hangi şarkıyı dinlediğinizi söylüyor ve komutlarınıza göre şarkıyı değiştiriyor. Bu kadar basit. Boris bizzat şöyle yorum yaptı: "Oldukça havalı bir demo ama ilginç değil. ”

Gerçek sürpriz, meslektaşı Cat Wu ile sohbetini bitirdikten sonra geldi. Cat, AI Ajanının bilgisayar yeteneklerini inceliyordu ve sohbet ederken Boris'in aklına bir fikir geldi: ya bu komut satırı aracına daha fazla izin versek? Örneğin, dosyaları okuyup yazabiliyor ve komutları çalıştırabiliyor mu?

Denedi. Sonra, mucizeyi görme anı gelir. Boris, yükseltilmiş aracı Anthropic'in kod tabanına attı ve birkaç soru sordu. Claude dosya sistemini kendi başına keşfetmeye başladı—bir dosyayı okudu, içindeki aktarma ifadesini gördü, sonra referans edilen dosyayı kat kat kazarak cevabı buldu. "Beni sarstı," diye hatırlar Boris, "ve böyle bir aleti hiç kullanmamıştım. ”

Yapay zeka alanında "ürün sönmesi" (ürün sönmesi) olarak adlandırılan bir kavram vardır; bu kavram "ürün sönmesi" anlamına gelir. Bu, modelin aslında belirli bir yeteneğe sahip olduğu, ancak mevcut ürün formunun bu yeteneği serbest bırakmadığı anlamına gelir. Boris'in keşfettiği şey, Claude'un çoktan yapabileceği ama kimsenin bunun için bir kabuk inşa etmediği büyük bir "ürün çıkıntısı"ydı.

Boris her gün bu araçla çalışmaya başladı ve ardından birkaç meslektaşınla paylaştı. İki ay sonra, Kasım ayında bir yapı çıkardılar. Veriler abartılı: ilk gün mühendislerin %20'si kullanımda; 5. Gün, %50.

Bu sırada ilginç bir tartışma ortaya çıkıyor: Dışarı mı açıklanacak? Karşı çıkmanın sebebi çok gerçek: Eğer bu şey gerçekten düşündüğümüz kadar güçlüyse, onu "gizli silah" olarak tutmak iyi olmaz mı? Neden rekabet avantajından vazgeçelim? Sonunda Anthropic yayın yapmayı seçti. Mantık şudur: Anthropic'in temel misyonu model güvenliğini incelemek ve güvenliği incelemenin en iyi yolu bu araçları gerçekten kullanmaktır. Artık Claude Code yoğun şekilde kullanılmak üzere dahili olarak doğrulandığı için, yayımlanması modelin yetenekleri ve güvenliği hakkında daha fazla bilgi sağlayacak.

Mayıs 2025'te Claude Code resmen kamuoyuna açıklandı. Üç ay sonra, kullanım 10 kat arttı ve yıllık gelir 500 milyon doları aştı. İlginç bir şekilde, Boris başlangıçta programcılar için tasarlanmıştı - bu yüzden "Claude Code" adı da buradan geliyor. Ama bir gün veri bilimcinin çalışma istasyonunun yanından geçti ve diğer ekranda çalışan Claude Code'u buldu. "Neden bunu kullanıyorsun?" "Sorgu yazmamda ve görselleştirmemde yardımcı olması için onu istedim." Şimdi, Anthropic'in veri bilimcileri bir tane elinde ve bazıları aynı anda birden fazla araç kullanıyor. Dinleme cihazı, birkaç izin daha verildiği için yüz milyonlarca dolar değerinde bir ürün haline geldi. Bu muhtemelen "ürün baskınlığı"nın en iyi kanıtıdır, model yeteneği her zaman orada, birinin yayınlamasını bekliyor.

[2] Kodun %90'ı kendi başı tarafından yazılır - Claude Code'un teknik seçim felsefesi Claude Code kendi kodunun %90'ına sahiptir. Kulağa bir numara gibi geliyor ama aslında teknik karar alma mantığı sayesinde oldu. Önce teknoloji yığınına bakalım: TypeScript ana gövdeyi yazıyor, React terminal arayüzü olarak Ink framework'ü kullanıyor, Meta'nın açık kaynak Yoga'sı düzen sistemini yapıyor ve Bun ise inşa ve paketlemeden sorumlu. Neden bu teknoloji yığınlarını seçersiniz? Çünkü "dağılım içinde". "Dağıtım üzerine" yapay zeka alanında kullanılan bir terimdir. Bu da modelin bu tür kodları çok gördüğü ve onları iyi kullandığı anlamına gelir. TypeScript ve React tam olarak Claude'un güçlü olduğu yerler. Popüler olmayan bir çerçeve seçerseniz, model "öğrenmek" zorunda kalır ve etki zarar görür. Bu seçim harika bir döngüye yol açar: Claude'un iyi olduğu teknoloji yığınıyla Claude Kodu yaz, sonra Claude Code ile daha fazla Claude Code yaz. %90'ı kendinden bahsediyor, işte böyle ortaya çıktı. Mimari düzeyde seçimleri de aynı derecede öz. Claude Code yerel olarak çalışıyor. Docker konteynerleri yok, bulut sandbox yok, sadece dosyaları okumak, yazmak ve doğrudan bilgisayarınızda komutları çalıştırmak yeterli.

Peki neden böyle tasarlanmış? Boris şöyle yanıtlıyor: "Her tasarım kararı verdiğimizde, neredeyse her zaman en basit çözümü seçiyoruz. Yerel olarak çalıştırmak en basit cevaptır. ” Bu sadelik tüm ürün felsefesine uzanır: mümkün olduğunca az iş mantığı yaz ve modelin ana karakter olmasına izin verin. "Biraz garip gelebilir," dedi Boris, "ama kullanıcıların modeli mümkün olduğunca 'özgün' hissetmelerini istiyoruz. Birçok yapay zeka ürünü, ek arayüz öğeleri, erişilebilirlik özellikleri gibi bir sürü iskele ekliyor ve sonuç olarak model sınırlı kalıyor. Yapmak istediğimiz şey, arayüzü mümkün olduğunca sade yapmak. ” Basitçe tutmak gerekirse, Claude her yeni model çıkardığında kodu çok sadeleştiriyorlar. Örneğin, Claude 4.0 çıktığında, yeni modelin artık bu "koltuk değneklerine" ihtiyaç duymaması nedeniyle sistem uyarılarının yaklaşık yarısını kaldırdılar. Araç sayısı da sadeleştiriliyor—mümkünse sil, mümkünse birleştir. Tüm Claude Code mimarisi üç şeyle özetlenebilir: arayüzü tanımlamak ve arayüzü model modifikasyonuna sunmak, modelin çağrısı için araçları açmak ve ardından bir kenara atmak. Elbette, sadelik karmaşık kısımların olmadığı anlamına gelmez. İzin sistemi istisnadır. Sonuçta, yapay zekanın bilgisayarınızda komutları çalıştırması risklidir. Claude Code'un çözümü, işlemi yapmadan önce size şu soruyu sormaktır: Bu operasyonu onaylamak ister misiniz? Sadece bu sefer onaylayabilir, sonra onaylayabilir veya reddedebilirsiniz. İzin sistemi, çok katmanlı yapılandırmayı destekler – proje başı, kullanıcı başı, şirket başı. Teams, sık kullanılan güvenlik komutlarını beyaz listeye almak için profilleri paylaşabilir. Bu izin tasarımının arkasındaki prensipler şunlardır: Claude Code'u başlatırsan, izniniz olmadan hiçbir şeyi değiştirmemeli. Ama aynı zamanda, kullanıcılara "devretme" seçeneği de vermek gereklidir - güven senaryosunda onay bağlantısını atlayabilirsiniz. Basit, ama ilkel değil. Kendini tuttu, ama işlevsizlik değil.

[3] İki günde 20 prototip - yapay zeka çağında ürün yinelemesi nasıl görünüyor Geçmişte, ürün prototipleri yaparken, iki günde iki prototip üretebiliyordum ki bu verimli sayılırdı. Boris iki günde 20 tane yaptı. Bu abartı değil, Claude Code'un yapılacaklar listesi özelliğini geliştirmesinin gerçek bir kaydıdır. Hatta her adımın uyarılarını ve ekran görüntülerini bile paylaştı. Bu 20 arketipin nasıl yinelediğine bir bakalım. İlk versiyonda, yapılacaklar listesinin en güncel araç çağrısının altında görünmesini istedi. Komut kısa: "Giriş kutusunun üzerinde sabit bir yapılacaklar listesi gösterin ve başlığı '/todo (1 of 3)' gri olarak gösterilir." Etkisine baktıktan sonra pek tatmin olmadım. İkinci versiyonda, her ToDo güncellemesinde satırca olarak gösterilir. İstem: "Yapılacaklar listesi göstermek yerine, model bir yapılacakları işi işlemeye başladığında araç adını kalın başlığa çevirin." İlerleme göstergesini '4 üzerinden 2. adım' gibi tut. ” Hâlâ doğru değil. Üçüncü ve dördüncü baskılarda, ekranın altındaki küçük bir kare olan "etkileşimli hap" yapmaya çalıştı ve ilerlemeyi görmek için üzerine tıklayabiliyorsun. "Metin giriş kutusunun altında, arka plan görevine benzer bir yapılacak şey hapı ekle, 'yapılacaklar: 3'ten 1'i" gösteriliyor." Sonra: "Bu hapı bir arka plan görev hapı gibi etkileşimli yap." ” Biraz ilginç ama yeterince iyi değil. Beşinci ve altıncı baskılarda fikrini değiştirdi: sağdan kayan bir "çekmece" yapmak. "Önceki hapları ve başlıkları geri alın, bunun yerine giriş kutusunun sağ tarafında, dikey ortada, gri bir bölücüyle ayrılmış yapılacaklar listesini gösterin." "Biraz sinirli, bunu çekmece animasyonuna dönüştürebilir misin?" Görünüşü havalı ama pratikliği tartışmalı. Yedinci ve dokuzuncu baskılarda, yapılacaklar listesini giriş kutusunun üstüne taşıdı ve farklı kesinti ve başlık stilleriyle denemeler yaptı. "Eğer 5'ten fazla varsa, '... ve 4 tane daha'", "Gri bir 'Todo:' başlığı ekle". Cevap giderek yaklaşmak. Onuncu ve yirminci baskılarda, yapılacaklar listelerini yükleme animasyonlarıyla nasıl birleştireceğini çözmeye başladı. Son çözüm, görünürlüğü en üst düzeye çıkarmak için ilerleme bilgisini spinner'ın (yük göstergesi) yanına yerleştirmektir. Yayınlandıktan sonra kullanıcılar tam yapılacaklar listesini görmek istediklerini bildirdi. Böylece başka bir yineleme ekleniyor: tüm adımları genişletmek için Ctrl+T tuşlarına basın. Şu anda çevrimiçi olan sürüm bu.

Süreç boyunca Boris'in önerileri şaşırtıcı derecede kısaydı—çoğunlukla bir ya da iki cümle. Ama her versiyon gerçekten çalıştırılabilen bir prototip, statik bir çizim ya da PPT değil. Bu işlevi gerçekten test edip doğrulayabilir ve iyi çalışıp çalışmadığını hissedebilir. Geleneksel ürün geliştirme süreci: fikir→ tartışma → tel çerçeve çizmek → yüksek kaliteli tasarım → geliştirme → test → canlı yayına geçmek. Her adım zaman alır ve her adım takılabilir. Şimdi akış şöyle oluyor: Fikir → Tek cümlelik istem → Çalıştırılabilir prototip → Bir şey doğru gelmiyorsa, tekrar yapın. Bu aslında geliştiricilerin bu geliştirme sürecine uyum sağlamak için zihniyetlerini değiştirmelerini gerektirir. Geçmişte, prototiplerin rolü "fikirleri doğrulamak" idi - çünkü prototiplemenin maliyeti yüksekti ve bunu yapmadan önce dikkatlice düşünmek gerekiyordu. Şimdi, prototipler "olasılıkları keşfetme" haline geldi - çünkü prototip yapmanın maliyeti düşük olduğu için önce onları yapabilir, sonra çöpe atabilirsiniz. Boris, Claude Code kullanırken genellikle planı çizme aşamasını atlayıp sadece çalışan bir versiyon yaptığını ve bunun her şeyden çok sezgisel olduğunu söyledi. Claude Code ekibinin günlük ritmi şöyledir: her mühendis günde yaklaşık 5 PR, günde 60-100 dahili sürüm ve günde 1 dış sürüm yapıyor. Günde 5 kişisel profil, ki bu çoğu şirkette hayal edilemez. Uber en yoğun yeniden yapılandırma döneminde ve günde orta ölçekli bir PR yapabilmek kötü değil. Araçlar değiştiğinde, ritim değişir ve düşünme biçimi değişmek zorunda.

[4] Komut satırı terminali entegre yapay zeka ile yeniden tasarlandı Komut satırı terminalleri onlarca yıldır var, neden şimdi yeniden tasarlanmaları gerekiyor? Çünkü LLM'lerden önce, terminaller etkileşimli deneyimlere çok fazla odaklanmazdı. Geleneksel komut satırı bir soru-cevaptır: bir komut giriyorsunuz, sonuç döndürüyor ve işiniz bitiyor. Ne diyalog, ne bağlam, ne de beklerken geri bildirim yok. İmlecin yanıp sönmesine bakıyorsun ve arka planda ne olduğunu bilmiyorsun. Claude Code gerçekten "terminal UX" üzerine düşünmesi gereken ilk üründü. Birkaç küçük detay eklediler, fark edilmeyen ama kullanıldığında tamamen farklı hissettiren bir detay. Birincisi: Bağlamsal yükleme uyarıları. Model düşünürken, ekran mevcut görev gösterisine göre ilgili istekler üretebilir: örneğin "kod yapınızı okumak" veya "bir çözüm düşünmek". Küçük bir dokunuş ama araca bir "kişilik" katıyor. Sıkışmış gibi hissedeceksiniz, sıkışıp kalmamış gibi. Boris, bu tür keyifli küçük etkileşimi en son Slack'in yeni başlayan bir giriş süreci olduğu zaman gördüğünü söylüyor. İkincisi: Beklerken öğretme ipuçları. Claude uzun bir görev yaparken, ekranın alt kısmında "Esc tuşuna basarak mevcut görevi kesebilirsin" veya "Tüm komutları görmek için /yardım et" gibi ipuçları döndürülür. Komut satırı, basit ve akıllıca olan komut satırını öğretmek için kullanılır. Üçüncü hikaye ise daha da heyecan verici: Markdown renderer. Çıkıştan bir gün önce, bazı mühendisler iç içe listelerin çirkin olduğundan ve paragraf boşluklarının doğru olmadığından şikayet etti. Sorun Markdown renderer'ında. Boris piyasadaki tüm render cihazlarını denedi ve hiçbiri terminalde iyi görünmedi. Bu yüzden Claude Code kullanarak sıfırdan bir Markdown ayrıştırıcı ve render cihazı yazdı. Evet, çıkıştan bir gün önce. Evet, sıfırdan yaz. Evet, Claude Code ile bizzat konuşuyor. Sonuç olarak, bu "acele" render cihazı tüm hazır çözümlerden daha iyi görünüyor. Doğrudan yayınladılar. Boris, artık başka hiçbir terminalin Markdown render kalitesine sahip olmadığına inanıyor. Bu hikaye bir şeyi gösteriyor: yeterince iyi bir yapay zeka programlama aracınız olduğunda, "kendi tekerleklerinizi inşa etmenin" maliyeti önemli ölçüde düşer. "Sadece kullan" taviz artık "o zaman daha iyisini yap" haline gelebilir. Komut satırı terminalinin eski arayüz formu, LLM'lerin eklenmesiyle yeniden doğulmaktadır. Terminal hâlâ aynı terminal, ancak yapay zeka eklendiği için, insanların terminaldeki yapay zeka ile daha iyi bir sohbet kurmasını sağlamak için ciddi bir şekilde düşünmemiz gerekiyor.

[5] Yapay zeka her bağlantıya nüfuz eder - bir mühendislik ekibi tarafından yapılan "kapsamlı bir YZE" deneyi Anthropic'in mühendislik ekibi muhtemelen şu anda yapay zeka araçlarının en aşırı kullanımlarından biri. Sadece kod yazmakla ilgili değil, projenin her yönüyle ilgili. Kod incelemesi: Tüm PR'lerin ilk incelemesi Claude Code tarafından, ikincisi ise mühendisler tarafından yapılır. Boris, Claude Code'un ilk geçişte birçok sorun bulabileceğini söylüyor. Bu özellik başlangıçta sadece iç kullanımda kullanılıyordu, ancak daha sonra herkesin Claude Code'u güvenlik incelemesi için kullanabilmesi için kamuya açık hale getirildi. Yazma testleri: Claude Code'un test paketi neredeyse tamamen Claude Code tarafından yazılır. "Geçmişte, biri PR açıp test yazmasaydı, bir şey söylemekte tereddüt ederdim — sanki bir seçim ve nokta gibi hissettirirdi," dedi Boris. Ama şimdi Claude ile sınav yazmak bir prompt kelimesi ve yazmamak için hiçbir bahane yok. ” Olay Müdahalesi: Oncall mühendisleri, Claude Code'dan sorunun temel nedenini analiz etmesini ister. Slack'ten ilgili tartışmaları, Sentry'den hata kayıtlarını, çeşitli izleme sistemlerinden verileri alır ve bunları sentetik olarak analiz eder. Boris, Claude Code'un bazı senaryolarda Root Cause'u bir insandan daha hızlı bulduğunu söylüyor. GitHub sorun triage: Yeni bir sorun geldiğinde, Claude Code önce bir analiz yapar, ardından mühendis bunun uygulanıp uygulanamayacağını sorar. Boris, yaklaşık %20 ila %40 oranında ilk seferde yapılabileceğini söylüyor. Grafikler ve sorgular: Ürün verileri BigQuery'de bulunur ve neredeyse tüm sorgular ile görselleştirmeler Claude Code ile oluşturulur. Mühendisler hatta ASCII diyagramlarını doğrudan çıkarmasına izin veriyor.

Beni en çok şaşırtan şey TDD'nin (test odaklı geliştirme) yeniden ortaya çıkmasıydı. TDD eski bir kavramdır: önce testler yaz, sonra testleri geçen kodu yaz. Teoride iyidir - önce ne istediğinizi düşünmenizi zorlar. Ancak pratikte, çoğu insan bunun çok yavaş ve hantal olduğunu düşünüyor, bu yüzden bu yöntem son on yılda yavaş yavaş marjinalleştirildi. Ama Boris, Claude Kodu'nu kullandıktan sonra çok fazla TDD yaptığını söyledi: "Modelden bir test yazmasını ve testin şimdi başarısız olacağını söyleyerek başlayacağım, geçmeye çalışma. Sonra fonksiyonu uygulamak için kod yazmasını, testin geçmesine izin vermesini ama testi değiştirmemesini istedim. ” "Bir modelin net bir hedefi olduğunda—örneğin bir birim testi veya deneme gibi—çok iyi performans gösterir." Özellikle, Claude 4.0'ın, modellerin çoğu testi yazmasına izin veren ilk model serisi olduğunu belirtti. Önceki versiyonlar bir rol yazabiliyordu ama çok fazla insan müdahalesi gerektiriyordu. Ayrıca yeni bir kavram var: çoklu klauding. Bu, aynı anda birden fazla Claude Code örneğini çalıştırmak ve farklı görevler üzerinde paralel çalışabilmeleri anlamına gelir. Sid, sık sık bunu yaptığını söylüyor – toplantılarda birkaç ajan başlatıp sonra sonuçları görmek için geri dönüyor. Anthropic, Max abonelerinin %25'inin (aylık 100-200$ maliyetli premium kullanıcılar) her gün çoklu klaud yaptığını buldu. Bu ilginç bir değişiklik. Programlama her zaman "tek iş parçacıklı" bir etkinlik olmuştur: aynı anda sadece bir şey yapabilir ve kod incelendiğinde veya dağıtıldığında görevleri değiştirebilirsiniz. Ama şimdi, "paralel programlama" mümkün – aynı anda birkaç şeyi ilerletebilirsiniz. Elbette, burada birçok bilinmeyen şey var: paralel çalışma gerçekten daha mı verimli, yoksa sadece daha verimli mi hissediliyor? Paralellik için hangi tür görevler uygundur? Her temsilci daha az ilgi görürse sorun olur mu? Bu sorular henüz cevaplanmadı. Ama denemek için yeni bir aracımız var. Son olarak, bir davadan bahsedelim. Bir şirket bir çerçeve geçişi yapacaktı ve bunun iki mühendislik yılı alacağı tahmin ediliyordu - bir mühendis için iki yıl, on mühendis için ise iki buçuk ay. Claude Code kullandılar ve bir mühendis bunu iki haftada başardı. Boris, eskiden bu tür iddialara şüpheyle yaklaştığını ama benzer hikayeleri çok fazla duyduklarını söyledi.

[6] Üç günlük hackathon - Subagents özelliğinin nasıl doğduğu Subagents'teki bu özelliğin ilhamı bir Reddit gönderisinden geliyor. Bazıları onun aynı anda beş Claude Code örneğini açtığını, her örnek için farklı roller belirlediğini ve ardından dosya sistemini birbirleriyle iletişim kurmak için kullandığını söylüyor. Sid Bidasaria bu gönderiyi gördüğünde ilk tepkisi şu oldu: Bu oynanış harika, ama kullanıcılar böyle atmamalı. Bunu ürünün yerleşik bir fonksiyonu haline getirmeliyiz. Şirketin üç günlük bir iç hackathonu vardı ve Sid bu üç günü bunu yapmak için kullanmaya karar verdi. İlk gün, ekip heyecanla çeşitli karmaşık ajan topolojilerini ortaya çıkardı: ajanlar arasında mesaj veri yolu iletişimi, asenkron mod, çoktan çoktan çok etkileşimler...... Resim çok güzel çizilmiş ve konsept ileri seviyede. Ertesi gün, bunun mümkün görünmediğini fark ettiler. Sorun teknik uygulama değil - karmaşık kalıplar oluşturulabilir. Sorun şu ki, kullanıcılar bunu anlayamıyor. Claude Code'un arayüzü basit bir terminal, kullanıcıların bu karmaşık ajan iletişim modlarını böyle basit bir arayüzde nasıl anlamalarını sağlıyorsunuz? Yeniden başlamaya ve temel soruya dönmeye karar verdiler: Ortalama bir geliştiricinin kullanabileceği en basit form nedir? Kendilerine iki kısıtlama koyarlar: Öncelikle, yeni bir şey icat etmeyin. Sadece Claude Code'un zaten sahip olduğu yetenekleri - "/" komutu ve .md dosyalarını kullanın. İkincisi, ajanlar arasında iletişim kurmayın. Basit bir orkestrasyon desenine geçin: Bir ana ajan var ve o da çocuk ajanı çağırabiliyor ve görev tamamlandıktan sonra sonucu döndürüyor, hepsi bu. Ayrıca Anthropic'in araştırma ekibiyle sohbet ettiler. Araştırmacılar çoklu ajan kalıpları üzerinde çalışıyor, ancak sonuç şu ki, karmaşık ajan topolojilerinin gerçekten işe yarayıp çalışmadığı hâlâ kesin değil. Bu onlara daha fazla özgüven verir: araştırma ekibi bile karmaşıklığın mutlaka iyi olmadığını söylediği için, basit bir versiyon yapmak daha iyidir. Üçüncü günün sonunda çalışan bir versiyon yapıldı. Kullanıcılar, alt ajanların rollerini ve yeteneklerini .md dosyalarında tanımlayabilir (örneğin, "ön uç ajanları: React 19 ve Next.js kullanılarak"), Claude Code uygun olduğunda onları çağırır veya kullanıcı manuel olarak tetikleyebilir. Hackathondan sonra, biraz cilalandıktan sonra özellik canlı. Şimdi çeşitli özel alt ajanlar tanımlayabilirsiniz: güvenlik denetimi uzmanlığına sahip arka uç ajanlar, belirli çerçevelere aşina ön uç ajanları ve test yazma konusunda uzmanlaşmış QA ajanları...... Arka planda paralel çalışabilirler, her biri kendi rolünü üstlenir. Birçok takım, hackathonda karmaşık planlarını bozmaya isteksiz olacak, sonuçta bütün günü çizim yapıp tartışmak için harcıyorlar ve duyguları var. "Bu yol işe yaramıyor" diye kabul edip onu yıkıp sıfırdan başlamak cesaret ve "sadelik"e inanç gerektirir. Basitlik tembellik değildir. Basit olan, kullanıcının sayısız olasılık arasında gerçekten kullanabileceği formu bulmaktır.

[7] Mühendislik ekibi gelecekte nasıl olacak? Bazıları referans olarak kullanılabilir, bazıları kopyalanamaz Boris, "Programlama artık çok eğlenceli. En son böyle hissettiğim zaman, ortaokulda ilk kez bir grafik hesap makinesine kod yazdığımda. Uzun zamandır yaşamadığım o sihirli his, ama şimdi geri döndü. ” Sid de benzer şekilde hissediyor: "Beni heyecanlandıran iki şey var. Bunlardan biri, serbest bırakma hızımız – bazen çok hızlı hissettiriyor. İkincisi ise çok fazla deneysel alan - önceki işler hızlı olmasına rağmen, yaptığım şeyler daha rutindi ve cevabı bildiğim için sadece uygulamaydı. Şimdi farklı, model her üç ayda bir değişiyor ve sürekli olarak işleri nasıl yaptığımızı yeniden düşünmemiz gerekiyor. ” Bu duygular çok gerçek ve bulaşıcıdır. Ama "mühendislik ekiplerinin geleceği nasıl olacak" diye konuşmadan önce, Anthropic'in özgüllüğünü unutmayalım. Birincisi, Anthropic bir araştırma laboratuvarıdır, bir ürün şirketi değildir. Temel misyonu, yapay zeka güvenliği ve yeteneklerini araştırmaktır ve ürün, amaç değil, araçtır. Bu, ortalama şirketlere göre "hızlı deneme" konusunda çok daha yüksek bir toleransları olduğu anlamına gelir. İkincisi, ana ürünleri Claude modelinin kendisidir. Claude Code modelin sadece bir "kabuğu". Bu yüzden "modelin daha fazlasını yapmasına izin vermek için kodu silmek" onlar için doğal bir tercih, ancak diğer şirketler için temel iş mantığını kara kutuya vermek anlamına gelebilir. Üçüncüsü, tüm çalışanların Claude'a sınırsız erişimi vardır, en pahalı Opus modeli dahil. Çoğu şirkette, yapay zeka abonelik ücretleri bütçe maddesidir ve herkes tarafından kullanılamaz. Dördüncüsü, ekipte sadece bir düzine kişi var ve süreç çok az. Özellik bayraklarını neredeyse hiç kullanmazlar çünkü "çok yavaşlar". Bu, büyük bir kullanıcı kitlesi ve yüksek hata maliyeti olan bir üründe düşünülemez. Bu yüzden, Claude Code ekibini doğrudan kopyalamak çoğu takım için gerçekçi olmayabilir. Ama öğrenilecek bazı şeyler var. Hızlı prototipleme zihniyeti: Günde 10 prototip yapamasanız bile, "her iki haftada bir"den "haftada üç"e geçebilir misiniz? Araçlar değişti ve "prototipin ne kadar hızlı olacağı" beklentileri güncellenmeli. Yapay Zeka Destekli Kod İncelemesi: İlk incelemeyi yapay zeka, ikinci incelemeyi insan yapsın. Bu süreç, çoğu ekip deneyebileceği sınırsız API erişimine dayanmaz. TDD'nin yeniden canlanması: Test yazmak yeterince kolay hale gelirse, "test yazmaya zaman yok" artık bir bahane olmuyor. Bu, kod kalitesini artırmak için düşük maliyetli bir giriş noktası olabilir. Ürün odaklı mühendislerin değeri artıyor: Claude Code ekibinde tasarımcı veya PM yok, sadece birkaç ürün odaklı mühendis var. Yapay zeka araçları, bu "tam yığın yeteneğin" yapabileceklerini büyük ölçüde genişletti.

Elbette, bazı şeyler aletlerle değiştirilemez. Boris, yargılayıcı olduğu için 20 arketip arasından en iyisini seçebildi—neyin "doğru hissettirdiğini" ve neyin "iyi göründüğünü" biliyordu. Bu zevk, 17 yıllık yazılım geliştirme deneyiminin sonucudur, yapay zekanın verebileceği bir şey değildir. Ekip ilk gün karmaşık bir plan yaptı ve ertesi gün acımasızca bozulup yeniden başlayabildiler, ki bu da insani bir yargıdır. Kodu ne zaman sileceğini, ne zaman saklayacağını bilmek bu mimari sezgi için de geçerlidir. Yapay zeka uygulamayı hızlandırıyor, ama "ne yapacağını bilmeyi" kolaylaştırmıyor. Bunun yerine, uygulama maliyeti azaldığı için "ne yapacağım" kararı daha önemli hale geldi - hızlıca 20 versiyon yapabilirsiniz, ama hangisinin doğru olduğunu bilmeniz gerekir. Birkaç yıl içinde yazılım mühendisliği nasıl görünecek? Kimse doğru tahmin edemez. Ama bugün Claude Code ekibi birçok takım için yarın için bir tür prova olabilir - daha hızlı iterasyonlar, daha az "tuğla taşıma", daha fazla yargı ve karar verme. Araçlar değişiyor. Değişmeyen ise, nihai kararı hâlâ insanların vermesidir.