Claude Code Kurucusu Boris Cherny, Sequoia Konferansı'nda AI Üzerine 7 Anahtar Değerlendirme Paylaşıyor

Düzenleme: A Ying

Claude Code kurucusu Boris Cherny, Sequoia konferansında yaptığı paylaşımda çok sayıda bilgi verdi; birçok fikri ilk kez tam olarak duyuyorum. Bu adam gerçekten AI konusunda iyi bir anlayışa sahip.

Kendi özetimi paylaşayım.

Çok sayıda ana akım geliştirme senaryosunda, kodu elle yazmak artık verimsiz bir şey haline gelmiştir.

Bir fonksiyon teslim edilmeden önce mühendisler oturup, nasıl uygulanacağını önceden düşünür, ardından kodu satır satır yazarlar. Bu süreçte mühendisin en büyük değeri: kod yazıp yazamadığı, yazım kalitesi ve yazım hızıdır.

Şu anda çalışma şekli farklı.

Aynı fonksiyon için mühendislerin yaptığı iş, önce gereksinimleri net bir şekilde açıklamak, işi birkaç parçaya bölüp Agentlere vermek, bir kabul kriteri belirlemek ve ardından Agent'in ürettiği sonucun doğru olup olmadığını kontrol etmekten ibarettir; yanlışsa, ipucunu ayarlayıp tekrar çalıştırmaktır.

Yapay zeka, büyük ölçüde kodlama görevlerini halledebiliyor. Ancak %100 değil; hâlâ çok büyük ve karmaşık kod kütüphaneleri, nadir kullanılan diller veya özel ortamlar için günümüz modellerinin performansı yeterli değil.

Genel olarak, mühendislerin değeri, kod yazabilme yeteneğinden görevleri parçalayabilme, hedefleri net bir şekilde anlatabilme, sonuçları kabul edebilme ve Agent yönetebilme yeteneğine dönüşmüştür.

Bu değişim aslında endüstri devrimine çok benziyor.

Sanayi Devrimi öncesi, bir demirci, demir dövme, şekillendirme, parlatma ve montaj gibi tüm işleri tek başına yapardı. Becerili demirciler doğal olarak değerli olurdu.

Daha sonra üretim hattı ortaya çıktı. Her işçinin yalnızca bir aşamayı görevi vardı, ancak toplam çıktı, el sanatları dönemine kıyasla onlarca, hatta yüzlerce kat daha yüksek oldu.

Bu sırada fabrikada değerli rol, bir işlemi en iyi yapan ustadan, akış hattını iyi tasarlayan, yöneten ve sorunsuz çalıştıran kişidir.

İşçiler kaybolmadı, ancak işçilerin rolü değişti.

Yazılım mühendisliği şu anda benzer bir dönüşüm aşamasındadır. Kod kendisi artık nadir bir kaynak değildir. Kod yazabilme becerisi, PPT kullanabilme gibi temel bir beceri haline gelmektedir.

Gerçekten nadir olan, bulanık ihtiyaçları net görevlere bölebilmek, Agent'in sunduğu birkaç çözüm arasından en uygun olanını seçebilmek ve bir grup AI'nın bir şeyi tamamlamasını sağlayabilmektir.

Bu durum aslında birçok deneyimli mühendis için başlangıçta kabul edilemezdi. Kodu kendi elleriyle yazmak, geçmiş birkaç on yıl boyunca birçok kişinin bu mesleği sevmesinin nedeniydi.

Bu, birçok kişi için yalnızca çalışma şekli değişmekten ziyade, kimlik algısının bir yeniden şekillenmesidir.

Ancak trend, trendtir.

Kodlama, bir mesleki beceriden temel bir yetenek haline gelmektedir. Bu durum, 15. yüzyıl Avrupası'ndaki basım sanatıyla karşılaştırılabilir.

Yazının icadından önce, Avrupa'nın sadece %10'u okuma yazma biliyordu. Bu kişiler genellikle okuma yazma bilmeyen soylular tarafından çalıştırılırdı ve insanlara okumak ve yazmak için görevlendirilirdi.

Sonra basım sanayi ortaya çıktı. 50 yıl içinde Avrupa'da basılan kitap sayısı, daha önceki bin yıllık toplamı aştı ve kitap fiyatları yaklaşık 100 kat düştü. Yüzlerce yıl boyunca destekleyici sistemlerin (eğitim sistemi, ekonomik yapı) yavaş yavaş gelişmesinden sonra, dünya çapında okuryazarlık oranı bugünün %70 seviyesine ulaştı.

Boris, AI'nın yazılıma etkisinin, basım devriminin hızlandırılmış bir versiyonu olduğunu düşünüyor. Yazılım, birkaç on yıl içinde herkesin kontrolü altına girecek şekilde tamamen demokratikleşecektir.

Sonuçta, yazılım yapmak, mesaj göndermek kadar doğal hale gelecektir.

Kod yazma işleminin eşiği AI tarafından çok düşük seviyeye indirildikten sonra, bir kişinin yeteneğini gerçekten ayırt eden, ürün hissi ve bir alan hakkında gerçek anlamda derin anlayışıdır.

Bir örnek verelim. İki kişi aynı anda bir doktora yönelik bir ürün geliştirmek istiyor. Birisi kod yazmada hızlı bir mühendis, diğeri ise hastane bilgi sistemi bölümünde birkaç yıl çalışan biri.

Geçmişte, mühendisler fikri gerçekleştirebildikleri için daha yüksek olasılıkla ürün çıkarıyorlardı.

Şimdi durum tersine döndü. Herkes bir fikri gerçekleştirebilir. Bu noktada, hastane günlük akışını gerçekten anlayan kişi daha değerli hale gelir. Çünkü hangi özelliklerin doktorların gerçekten kullanacağını, hangilerinin sadece mantıklı göründüğünü bilir.

Yani AI, yürütme engelini kaldırdıktan sonra yargı farkı büyüdü.

Bu olay, "generalist" kelimesinin anlamını doğrudan değiştirdi.

Geçmişte genelci terimini, iOS, Web ve arka uç yazılımı yazabilen bir mühendis olarak tanımlardık. Bu tür genelciler, temelde mühendislik içi tam yığın anlamına gelir.

Geleceğin genelisti, çok disiplinli bir tam donanımlı uzmandır.

Ürün, tasarım ve mühendisliği aynı anda anlayan kişiler var. Ürün, veri bilimi ve mühendisliği aynı anda anlayan kişiler var. Bu kombinasyonlar, her birinin uzun süreli özel eğitim gerektirmesi nedeniyle geçmişte neredeyse imkânsızdı.

Ancak şimdi AI, her bir görevin uygulama engelini düşürüyor ve bir kişi birkaç alanda aynı anda çalışabiliyor, uzmanlık derinliğini koruyor.

Claude Code ekibi tam olarak böyle. Mühendislik yöneticisi, PM, tasarımcı, veri bilimci, maliye, kullanıcı araştırması, herkes kod yazıyor.

Tasarımcılar, yalnızca görseller hazırlayıp mühendislerin uygulamasını beklemek yerine, etkileşim prototiplerini kendi başlarına çalıştırarak takıma gösterebilir.

Maliye ekibi, şirketin karmaşık mali modellerini çalıştırmak için kendi analiz aracını kurabilir ve BI için sıraya girmek zorunda kalmaz. Kullanıcı araştırması çalışanları, veri ekibiyle iş birliği yapmaya ihtiyaç duymadan verileri kendi başlarına çalıştırılmaya başladı.

Herkesin uzmanlık derinliği hâlâ var. Ancak AI destekli olarak kod yazmak, herkesin ortak dili haline geldi.

Geçtiğimiz on yıl boyunca, SaaS endüstrisinde neredeyse aksiyom olarak kabul edilen birkaç anlayış vardı.

İlk olan maliyet değişimidir. Bir şirket bir kez sisteminizi kullanmaya başladığında, içinde yıllarca hatta onlarca yıl boyunca birikmiş veriler, yapılandırmalar, alanlar ve izin ilişkileri oluşur.

Başka bir sisteme geçmek istemek, bunları aynen dışarı çıkarıp tekrar içeri almak kadar zorlu olabilir ki, harekete geçmek istemeyebilirsiniz.

İkinci madde iş akışı kilitlidir. Çalışanların günlük işlemleri, çapraz departman iş birliği ve onay noktaları tamamen bu SaaS üzerinden oluşmuştur.

Bir sistemi değiştirmek sadece veri taşımak değil, şirketin geçen yıllar içinde kazandığı kasımlarını yıkıp yeniden inşa etmektir.

Bu ikisi birlikte, geçmişte SaaS endüstrisinin en derin koruma duvarını oluşturdu. Ancak yeterince güçlü bir modele sahip olduktan sonra, şeyerin mantığı değişmeye başladı.

Öncelikle geçiş maliyetine bakalım. Geçmişte bir SaaS’ten başka bir SaaS’e geçmek için alanları eşleştirmek ve veri yapısını tekrar oluşturmak yalnızca mühendislik ekibinin aylarca fazla mesai yapmasına neden olurdu.

Şimdi her iki tarafın arayüzlerini ve veri yapılarını doğrudan modele verin, model kendi kendine eşleme ilişkisini anlasın ve adım adım en iyi çözüme doğru tırmandırsın. Önceden aylar süren bir iş, birkaç gün içinde kullanılabilecek bir sürüm çıkartabilir.

İş akışı kilitlenmesine bir kez daha bakalım, bu daha ilginç. Geçmişte iş akışları, kendileri karmaşık, gizli ve insanlara bağımlı olduğu için müşterileri kilitliyordu.

Çalışanların zihinlerindeki, kimin kimden onay istediğini ve hangi aşamada takıldığını anlayan bir anlayış doğrudan taşınamaz.

Ancak Opus 4.7 gibi modeller, tam olarak karmaşık bir süreci anlayıp, parçalara ayırmayı ve yeni bir ortamda yeniden kurmayı en iyi yapar. Hatta yeniden kurulan versiyon, orijinalinden daha akıcı olabilir.

Dolayısıyla, geçmişte veri birikimi ve süreç birikimiyle oluşturulmuş koruma duvarı çökmektedir.

SaaS çalışanlar için bu kötü bir haber olabilir. Ancak SaaS kullanan tüm müşteriler ve yeni nesil SaaS geliştirmek üzere hazırlanan ekipler için gerçek bir fırsat penceresidir.

Gelecek 10 yıl içinde endüstriyi gerçekten devirici olan startup'lar, geçen 10 yıla göre 10 kat daha fazla olabilir.

Neden aslında karmaşık değil.

Küçük ekipler, AI kullanarak büyük şirketlerle aynı seviyede hatta daha iyi ürünler oluşturabilir. Tersine, büyük şirketlerin AI'yi gerçekten kullanması, negatif bir varlıktır.

How to say it?

On yılın üzerinde bir geçmişi olan bir şirket, kendi iş süreçlerini, pozisyon dağılımını, iş birliği alışkanlıklarını, eğitim sistemini ve KPI değerlendirme sistemini geliştirmiştir. Bu şeyler geçmişte bir varlık ve bir engel olmuştur.

Ancak AI'yi gerçekten entegre etmek, bunların tümünün yeniden gözden geçirilmesi anlamına gelir: iş süreçleri yeniden yapılandırılmalı, tüm çalışanlar yeniden eğitilmeli, her adım ilerledikçe büyük iç dirençlerle karşılaşılmalı, N adet departman ve N seviye onay koordinasyonu sağlanmalıdır.

Üç kişilik bir startup ekibi, ilk günden itibaren AI'yi varsayılan temel olarak benimsemiştir. Çözmeleri gereken tarihsel yükleri, değiştirmeleri gereken alışkanlıkları veya ikna etmeleri gereken insanları yoktur. Bugün tartışılır, yarın demo çıkarılır, dayanaksız kullanıcılar için hemen canlı hale getirilir.

Bu hız farkı, AI önce de vardı. Başlangıç şirketlerinin büyük şirketlere karşı hız avantajı vardı. Ancak AI bu farkı çok katlarca artırdı.

Neden?

Çünkü AI ne kadar güçlüyse, bir bireyin birim zamanda harekete geçirebileceği kaldıraç o kadar büyük olur. AI'yi gerçekten iyi kullanan küçük bir ekip, bugünün üretimi geçmişte on kişinin üretimi kadar olabilir, yarın ise geçmişte otuz kişinin üretimi kadar olabilir.

Ancak büyük şirketlerin organizasyonel ağırlığı hafiflememiş, aksine AI'yı içine sindirmek zorunda kalınca daha da ağırlaşmıştır. AI ne kadar güçlü olursa, küçük takımların ivmesi ile büyük şirketlerin çekme kuvveti arasındaki fark o kadar büyüyordur.

İşte Boris'in negatif varlık dediği şey. Büyük şirketlerin parası, insanı ya da isteği yok değil, eski zamanlarda kazanç getiren bu kaslar, bugün AI'nın gerçek değeri ortaya çıktığı yolda takılı kalmış durumda.

MCP ölmeyecek.

Beceriler popüler hale geldikten sonra birçok kişi MCP'nin gerekli olmadığını düşünüyor. OpenClaw'un kurucusu da benzer bir görüşe sahip.

Ancak Boris bu görüşe katılmıyor. MCP'nin AI çağındaki yazılım bağlantı katmanı olacağını düşünüyor.

Geçmişte internet yazılımlarının bağlantı yöntemi API idi.

Ancak API'nin temel sorunu, mühendisler için tasarlanmış olmasıdır. Bir API kullanmak için önce belgelere bakmanız, bir Token başvuruda bulunmanız, kod yazmanız, alanları eşleştirmeniz ve istisnaları işlememeniz gerekir. Açıkçası, API insan geliştiriciler için yazılmıştır.

MCP farklı. Modeli doğrudan bağlayıp kullanmanıza izin verir, model kendi kendine anlar ve çağırır, arada bir programcının onu çevirmesine gerek yoktur.

Boris, API'yi İnsan Geliştirici Arayüzü olarak, MCP'yi Model Arayüzü Protokolü olarak adlandırdı. Biri insanlar için, diğeri modeller için.

Bu aslında o zamanlar oldukça benzer. Mobil internet çağında, tüm hizmetlerin API'ye dönüştürülmesi varsayıldı. AI çağında, tüm hizmetlerin MCP'ye dönüştürülmesi varsayıldı.

Çok sayıda kişi şu anda Computer Use hakkında konuşurken, bu yönün işe yaramayabileceğini düşünüyor.

Neden de oldukça mantıklı: Token tüketimi çok yüksek, yavaş çalışıyor ve istikrarlı değil. Görünüşe göre daha çok bir gösteri amaçlı demo gibi, gerçek kullanım için hâlâ uzak.

Ancak Boris'in gördüğü düzey tamamen farklı.

O, Computer Use'un AI uygulamasının en büyük sorunlarından birini çözdüğünü, yani gerçek dünyada API veya MCP'si olmayan çok sayıda sistemin bulunduğunu gerçekten önemsiyor.

Özellikle kurumsal dünyada.

Şirkete girdikten sonra, içerdeki birçok temel sistemin çok eski olduğunu anlarsınız. ERP, OA, maliyet sistemi, dahili onay, tedarik zinciri arka planı, çeşitli özelleştirilmiş sistemler. Bunların çoğu açık API'ye sahip değil, belgelendirilmemiş ve otomasyon yeteneğine sahip değil. Bunlar orada, her gün binlerce çalışan tarafından elle işletiliyor.

Peki neden onlara doğrudan API sağlamıyorsunuz?

Çünkü yapmak mümkün değil. Bu sistemleri geliştiren sağlayıcılar zaten olmayabilir. IT departmanının yeniden yapılandırmak için hem motivasyonu hem de bütçesi yok.

İş birimleri altı ay ya da bir yıl beklemek mümkün değil. Bu sistemler, kendi kendini kurtaracak mükemmel bir API'yi beklemeyecek.

Kısa vadeli olarak, büyük modeller hala Computer Use yeteneklerini geliştirmeye devam edecektir.