Claude Code ürününüzü daha iyi hale getirmiyor

• Kodlama ajanlarının verimlilik etkisi eşit dağılmıyor; K-şekilli bir ayrışma gösteriyor. Temel metrik, saat başına yazılan kod satırı değil, mühendis başına ürün iyileştirme hızının gerçekten artıp artmadığıdır
• Dax, Karri Saarinen ve David Cramer yapay zeka karşıtı değil; ancak kodlama ajanlarının ürün iyileştirme hızını belirgin biçimde artırdığına ikna olmuş değiller. Cramer, LLM'lerin karmaşıklığı ve şişkinliği artırarak uzun vadeli hızı yavaşlattığını düşünüyor
• Claude Code, Anthropic içinde 7 ay boyunca özel bir avantaj sağladıysa, rakiplerle arasındaki farkın bileşik şekilde açılması gerekirdi; ancak Codex, Cursor, Cognition ve Factory hâlâ rekabet ediyor. Bu da darboğazın kod üretimi olmayabileceğini düşündürüyor
• İyi bir mühendislik kültürü, kod satırlarını varlık değil maliyet olarak görür. Özellikler ve entegrasyonlar arttıkça hata yüzeyi, bağımlılıklar ve yan özellikler de birlikte artar; karmaşıklık doğrusal değil, bileşik şekilde büyür
• Ürün kalitesinin sınırında, hızlı kod yazmaktan daha önemli olan şey zevk, sıkıştırma, silme ve reddetme kararlarıdır. Claude Code, sıfırdan Camry seviyesine gelmekte faydalıdır; ama Ferrari ustalarının daha hızlı bir Ferrari yapmasını sağlamaz

---

K-şekilli verimlilik eğrisi

• Kodlama ajanlarının verimlilik artışı eşit dağılmıyor; K-şekilli bir ayrışma gösteriyor
  • Kıdemli mühendisler, 2023'teki LLM dönüm noktasından sonra ölçülebilir çıktı artışı gösteriyor
  • Junior mühendislerin çıktısı ise neredeyse yerinde sayıyor ya da düşüyor
  • Kritik metrik, saat başına kod satırı değil; mühendis başına ürün iyileştirme hızının gerçekten artıp artmadığıdır
• Ajan tabanlı kodlama, belirli işlerde Pull Request oluşturma süresini kısaltıyor
  • “6 yıllık backlog'u bir çeyrekte temizledik”, “Cursor ile backend'i 3 günde yaptık”, “Claude Code tamamen Claude ile kodlandı” gibi iddialar tekrar tekrar dile getiriliyor
  • Ancak kod üretim hızının, ürün kalitesindeki artışla aynı şey olup olmadığı ayrı bir soru olarak kalıyor

İyi ürün yapan mühendislerden gelen uyarı işaretleri

• Dax, Karri Saarinen ve David Cramer yapay zeka karşıtı değil; ancak kodlama ajanlarının ürün iyileştirme hızını belirgin biçimde artırdığına ikna olmuş değiller
  • Dax, opencode.ai üzerinde çalışıyor
  • Karri Saarinen, Linear'ın CEO'su
  • David Cramer, Sentry'yi sıfırdan kurup aylık 10 milyon dolar ölçeğine büyüten kişi
• David Cramer, LLM'lerin şu anda net verimlilik artışı yaratmadığını düşünüyor
  • Başlangıç engelini düşürüyorlar; ancak bakımı zor, karmaşık yazılımlar üretiyorlar
  • Uzun vadeli hızı yavaşlatıyor gibi görünüyorlar
  • Sorun olarak LLM'lerin “karmaşıklık içinde kademeli geliştirmede zayıf performansını”, “gerçek sadeleştirme ve deyimsel arayüz üretme becerisi eksikliğini” ve “özensiz test üretim tekniklerini” gösteriyor
  • Sonuçta çoğunun şişkinlik (bloat) olduğu kanaatinde
• Dax, kodlama ajanlarını en iyi nasıl kullanacaklarını henüz net biçimde bulamadıklarını söylüyor
  • Buna karşılık dışarıda “tüm PR'ler AI üretimi”, “benzeri görülmemiş hız”, “6 yıllık backlog temizlendi” gibi çok sayıda iddia var
  • Fakat gerçek ürün iyileştirme hızını artırmada hepsi zorlanıyor

Claude Code'un özel avantajı fark yaratmış görünmüyor

• Claude Code tamamen Claude ile kodlandıysa, ürün iyileştirme hızının ivmelenmesi gerekirdi
  • Claude Code kullanımı ürün iyileştirme hızını sadece 1,5 kat artırsa bile, bunu en baştan kullanan takımın zaman geçtikçe rakiplerle arasını açması gerekirdi
  • Mühendislik verimliliği bileşik bir fonksiyon olduğundan, farkın her çeyrekte büyümesi beklenirdi
• Gerçek pazar durumu böyle bir bileşik fark göstermiyor
  • Codex, Claude Code'dan birkaç ay sonra çıkmasına rağmen işlevsel olarak şimdiden rekabet edebiliyor
  • Cursor'un ticari ivmesi güçlü
  • Cognition ve Factory de hâlâ önemli kurumsal sözleşmeler kazanıyor
  • İnsanlar hâlâ hangi aracın daha iyi olduğunu tartışıyor
• Temel karşı kanıt şu: Anthropic Claude Code'u 7 ay boyunca özel olarak kullandıysa, gerçek bir ürün hızı üstünlüğü varsa rakiplerle farkın kapatılamayacak kadar büyümüş olması gerekirdi
  • Codex anlamsız hale gelmiş olmalıydı; ama öyle değil
  • Bileşik üstünlük görünmüyorsa, ürün kalitesindeki darboğaz büyük olasılıkla kod değildi
• Olası karşı argümanlar da aynı sonucu güçlendiriyor
  • Bir kazanç olduysa bile, karmaşıklık borcu bunu yemiş olabilir
  • Anthropic'in mühendislik ekibi çok büyük olduğundan, mühendis başına marjinal fayda seyrelmiş olabilir
  • Ancak bu durumda da darboğaz kod üretimi değil, daha zor başka unsurlar olur

Kod satırları varlık değil, maliyettir

• İyi bir mühendislik kültürü, kod satırlarını çıktı değil harcama olarak ele alır
  • Önemli özellikler için kod yazılır, önemsiz olanlar için yazılmaz
  • Kod tabanı, bilançodaki bir varlıktan çok bir borca benzer
• comma.ai'nin yazılım iştiraki tinychat, kod tabanı belli bir boyutu aşınca alarm çalacak şekilde sistem kurmuştu ve silinen kodu kutluyordu
  • Her kod satırı bir hata yüzeyidir
  • Her fonksiyon, bir sonraki fonksiyonun bağımlılığı haline gelir
  • Her özellik, etrafında ek özellikler üretir
• Ürün yüzey alanı fraktal gibi genişler
  • Slack entegrasyonu eklerseniz, Teams entegrasyonu ve e-posta için alternatif akış da gerekir
  • Bildirim eklerseniz, bunu mobil, SMS ve kurumsal MDM politikalarına göre yeniden yapmanız gerekir
  • MFA desteği eklerseniz, Duo, Okta ve SAML ile uyumlu olması gerekir
  • Karmaşıklık doğrusal değil, bileşik şekilde artar
• Linear, 178 kişilik, 6 yıllık, 100 milyon dolar ARR ölçeğinde bir şirket
  • Jira'nın birikmiş mühendislik emeği Linear'dan 56 kat büyük, ancak tüketici kalite puanı 6 puan daha düşük görünüyor
  • Ana fikir, kalite ile kod tabanı kütlesinin aynı şey olmadığıdır
• Facebook ölçeğinde darboğaz, UI kodunu hızlı üretmek değildir
  • Yetenekli bir mühendis, Facebook feed'inin maketini bir günde yapabilir
  • Asıl kısıt, bu deneyimi milyarlarca kişiye her yük ve gecikme düzeyinde uptime koruyarak sunmak için gereken kod satırı sayısını azaltmaktır
  • Ödül fonksiyonu üretim değil, sıkıştırmadır
  • Böyle işlerde kodlama ajanları uzun vadeli ödünleşimleri değerlendiremez ve sistem hakkında bir teoriye sahip değildir

Gerçek darboğaz, iyi ürün fikirlerinin sınırını ileri itme yeteneği

• Ürün kalitesinin sınırındaki iyileşme, kodu ne kadar hızlı yazdığınızla değil; bu sınırı ileri itecek kadar iyi fikirleri ne kadar hızlı üretebildiğinizle sınırlıdır
• Jira ile Linear arasındaki fark, kimin daha iyi kutular çizdiği değildir
  • Linear'ın, proje yönetim yazılımının nasıl hissettirmesi gerektiğine dair somut ve yaratıcı bir vizyonu vardı ve bunu yıllar boyunca disiplinle uyguladı
  • Bu kalite, token throughput'tan değil zevkten ve daha az şey yapma kararından gelir
• “6 yıllık backlog'u temizledik” iddiası kulağa geldiği kadar etkileyici değildir
  • CRUD özellikleri ve iç araçlarla dolu backlog'lar, kodlama ajanlarının hızlandırdığı işlere çok uygundur
  • Aynı zamanda bu işler, ürünün sınırını ileri iten işler değildir
  • Daha hızlı yayımlamak ürünü daha iyi yapmaz; yayımladığınız şey kullanıcıların daha çok önem vermesini sağladığında ürün iyileşir
• AI kodlama ajanları, 0'dan 1'e giden ürünlerin kalite sınırına daha hızlı ulaşmasına yardımcı olur
  • İlk çalışan sürüme ulaşma süresini kısaltırlar
  • Erken aşama işlerde hız artışı gerçekten vardır
• Bunun bir maliyeti de vardır
  • Kod tabanı kaliteden daha hızlı büyür
  • Teknik borç bileşik şekilde birikir
  • Bugün kazandığınız hız, yarın ödenecek bir maliyet satın alarak elde edilir

Herkese Camry, kimseye Ferrari değil

• Sınırda çalışan ekiplerin darboğazı, kodlama ajanları değil zevk sahibi insanlardır
  • Linear ve Sentry örneğinde olduğu gibi, “ayıklayan zevkle en iyi olma” becerisi belli insanlarda bulunur
  • Linear'dan Nan Yu ve Skunk Works'ten Kelly Johnson örnek olarak veriliyor
  • Kelly Johnson'ın seçilmiş ekibi SR-71'i yaptı ve SR-71, 60 yıl sonra bile en hızlı hava soluyan insanlı uçak olarak anılıyor
  • Blackbird'ün hızlı olmasının nedeni daha fazla plan üretmesi değil, Johnson'ın neyi dışarıda bırakacağına dair bir teoriye sahip olmasıydı
  • Silme, sıkıştırma ve reddetme zevki hiçbir frontier model yol haritasında yoktur; taban seviye yükseldikçe daha da değerli hale gelir
• Zaten sınırdaysanız, token harcamasıyla Ar-Ge maliyetini iki katına çıkarmanın ekonomik değer yaratıp yaratmadığı belirsizdir
  • Ramp mühendisleri, geçen yıl içinde token harcamasıyla fiilen maaşlarını ikiye katladıklarını söylüyor
  • Ramp ürününün gerçekten daha iyi olup olmadığını doğrulamak zor
  • Zaten 1 numaraysanız, kazanma oranınız neredeyse sabittir ve “daha büyük farkla 1 numara olmak” ölçülmesi zor bir şeydir
  • Bu yargıyı değiştirmek için Ramp'in kazanma oranı veya kâr-zarar verileri gerekir
  • Ramp müşterisi olarak, şu an ile geçen yıl arasında hissedilir bir fark görmediğini belirtiyor
• Claude Code, herkesin Camry seviyesinde bir rakip yapmasına yardımcı olabilir; ancak Ferrari ustalarının daha hızlı bir Ferrari yapmasına yardımcı olmaz
  • Sıfırdan Camry seviyesine çıkmakta çok faydalıdır
  • En üst düzey olmayan yazılımların üretim maliyetini büyük ölçüde düşürmesi muhtemeldir
  • Ancak bunun karşılığında fabrikanın kirişlerine çok fazla karmaşa ve borç birikir; sonunda birilerinin bunları temizlemesi gerekir

[GN⁺]

Lobste.rs görüşleri

• Karmaşıklık üstel olarak artar ve muhtemelen bundan da hızlı olabilir. Bu yüzden AGI tekilliğinden korkan insanların bile sık sık gözden kaçırdığı şey şu: ne kadar zeki olursa olsun, insan da model de ajan da, fikirler/sistemler/projeler/kod tabanları/özellik kümeleri büyüdükçe eninde sonunda hızla yükselen bir karmaşıklık duvarına çarpar
  Tüm yazılım projeleri başlangıçta nispeten sorunsuz ilerler, ama bir noktada karmaşıklığın üstel artışı her şeyi bastırır. İyi mimari/tasarım/kalite bu anı sadece geciktirir; yetkin insanlar iyi tasarlayıp kaliteyi korursa boyut/özellik/performans/vay etkisini yaklaşık 10 kat daha uzun süre taşıyabilir, ama sonunda yine duvara çarpılır
  LLM desteği, belli bir seviyeye kadar, çoğunlukla ortalama kalitede özellikleri ve kodu çok daha hızlı üretmeyi sağlar. Yani o duvara da çok daha hızlı ulaşılır. Büyüme, deney, görece kolay ama zaman alan düşük karmaşıklıklı işler için iyidir, fakat daha önce var olmayan şeyleri ya da büyük ve karmaşık projeleri mümkün kılmaz. Bunun için gereken şey karmaşıklığı bastıran iyileştirmelerdir ve mevcut LLM’ler bunu gerçekten sağlayamıyor

  • Bu klasik bir sorun. Neden ve sonuç hemen peş peşe geliyorsa anlık fayda kolayca görülür; ama neden ile sonuç arasında zaman farkı varsa olumsuz etkiyi görmek çok daha zordur
    http://bastiat.org/en/twisatwins.html
    Kod ajanlarını kullanmanın maliyeti doğrudan görünmez; her şeyden önce, sistemin nasıl çalıştığına dair kolektif anlayışın kaybından doğar
  • Yine de hiyerarşik örgütlenme, büyük ölçekli karmaşıklığı yönetmek için bir yol sunar. Doğada da son derece karmaşık yapıların bu şekilde ortaya çıktığını görebiliriz. Bağımsız birimler birleşerek daha büyük yapılar oluşturur; sistemleri de bu şekilde kurabilirsiniz
    Sağlam sistemler darbeye dayanabilmeli ve kendini uyarlayabilmelidir; bu yüzden her parça bağımsız biçimde başarısız olabilmeli ve hasar yerel kalmalıdır. Sistemi iç içe geçmiş alt sistemler halinde düzenlerseniz, birbiriyle konuşarak iş yapan hücre benzeri birimler elde edersiniz. Bu birimler, diğer hücrelerin iç süreçlerini bilmeden kararlı alt montajlar gibi davranır
    Her katman, başka yerlerde olanlar yüzünden tökezlemeden kendi alanında kendini organize edebilir ve dayanıklılığını koruyabilir. Bu aslında arayüzlerin arkasında tesadüfi karmaşıklığı kapsüllemek ve bu arayüzlerin anlam taşıdığı soyutlamalar oluşturmak demektir. Katmanları, büyük sistemin bileşenlerini birbirine bağlayan bağ dokusu olarak görmek daha doğru olur
    Erlang OTP, bu yaklaşımın yazılımdaki iyi bir örneğidir; büyük sistemleri birbirine mesaj gönderen yalıtılmış süreçlerden kurar. Tek tek süreçler ölse ya da hata verse bile tüm sistemi çökertmez
  • “Karmaşıklığı bastırmak” bana göre karar, görüş ve bazen de itiraz ya da çatışma gerektirir
    Birinden bir şeyi uygulamasını isterseniz, “bu fazla karmaşık”, “bir yıl sonra patlar”, “Y ekibinin yaptığıyla uyumlu değil”, “bunu uygulayacak yeterli insan yok” gibi cevaplar verebilir. Sonuncusu gerçekten doğru olabilir ya da dolaylı bir “olmaz” deme biçimi olabilir
    LLM’lerin böyle cevap verme ihtimali çok düşüktür. Özellikle de iyimser ve kibar olacak şekilde ayarlandıkları için. Üstelik bu eğilim etkileşimi artırmak için gerekli olduğundan, farklı ayarlanmaları da pek olası görünmüyor
    Bu sorun, LLM’lerin kullanıcıların intiharına yardım etmesi sorununa benziyor. Bu oldukça açık bir örnek ve LLM’ler bunu epey yaptı. Yönetilmeyen karmaşıklık yüzünden projelerin ölmesi ise bundan çok daha belirsiz; bu yüzden LLM’lerin yakın zamanda bunda daha iyi olacağını beklemek için pek neden yok

• “Claude Code kullanmak gerçekten ürün geliştirme hızında üstünlük sağlıyorsa ve Anthropic bunu 7 ay boyunca tek başına kullandıysa, Claude Code ile tüm rakipleri arasındaki fark kapanamaz olmalı. Codex anlamsız kalmalı. Ama insanlar hâlâ hangisinin daha iyi olduğunu hararetle tartışıyor” türü bir akıl yürütme çok sağlam görünmüyor
  Claude Code iyi bir yazılım, ama rekabeti imkânsız hale getirecek tuhaf bir AGI sihri değil

  • Üstelik Codex de vibe coding ile yapıldı, dolayısıyla bu karşılaştırma o açıdan da biraz komik. Birkaç ay önce başlamış olmanın pek anlamı olmayabilir. Eklenen birçok özellik, gerçek kullanıcıların araçlarla ne yaptığına bakılarak ortaya çıkar
    Claude Code’un en baştan tamamlanmış bir yol haritası yoktu ve asıl engel de kod yazma hızı değildi. Asıl engel fikirler. Herkes yaparak yol alıyor
    Yazıyı genel olarak sadece göz gezdirerek okudum, o yüzden derin konuşamam; ama cümle başlarındaki büyük harf sorununu bir kenara bıraksak bile çoğu kısım LLM’in yazdığı düzyazı gibi göründüğü için okumak istemedim

• Şimdiye kadar ajan hataları çarpan etkisiyle birikme eğiliminde oldu
  Teknik olarak çalışan ama kullanırken biraz ek kod gerektiren bir API yaparsanız, sonuçta daha fazla kod ortaya çıkar ve tekrarların/dallanmaların/hataların oluşacağı yerler de artar. Sonra fraktal gibi yine çok da iyi olmayan daha fazla kod yazılır
  Bir ajan bir keresinde id alanı opsiyonel olan bir struct tasarlamıştı. Bu alan, kendi yazdığı tek bir constructor yüzünden gerekliydi. Sonra da id varken ve yokken çalışan iki ayrı kod yolunu hiç yorulmadan yazdı ve id yokken kullanılacak garip bir yedek yol bile oluşturdu. Bu yedek yollar doğal olarak karmaşık ve kırılgandı. Struct’ın neredeyse tüm kullanım noktalarına ve onlara bağlı yerlere bulaştı, ama id olmayan constructor aslında hiç kullanılmadı. Kod tabanının yarısı kolayca silinebilirdi
  “Saçma bir şey yapıyorsan kazmayı bırak” gibi talimatlar yeterince verilirse bu düzeltilebilir mi ve kod yazımı “çözülene” kadar geriye sadece birkaç hack mi kalmıştır, yoksa bu olasılıksal papağanların uzun vadeli sorunu olduğu için doğrusal iyileşme adına üstel biçimde artan maliyetler mi gerekir, gerçekten bilmiyorum. Hatalar bileşik faiz gibi biriktikçe, bileşik büyüme sonunda ayağa dolanır

  • İnsan geliştiricilerde de çok benzer şeylerin olduğunu gördüm. Bence en iyi geliştiricileri ayıran özelliklerden biri, bir seviye yukarı ve dışarı çıkıp durarak geriye bakma eğilimidir
    Bazen buna iş süreçleri de dâhildir. Alanı iyi bilen bir geliştirici, aylarca teknik çözüm uygulamak yerine “kazmaya devam etmek yerine süreci değiştiremez miyiz?” diye sorabilir ve bazen cevap “tabii ki, bu kolay” olur
    LLM’ler de sonunda bu konuda daha iyi olacaktır diye düşünüyorum. Şimdiden “bu yaklaşım pek iyi görünmüyor, bir alternatif düşünebilir misin?” diye açıkça sorarsanız bunu epey sık fark ediyorlar. Ama şu an başarı ve başarısızlık çok dengesiz; ayrıca bir kez böyle aptalca bir şey yapıldıktan sonra, ilgisiz bir iş üzerinde çalışırken bunu kendi başlarına fark etme ihtimalleri düşük
    Burada bir denge de var. İnsanlar şimdiden modellerin sorunları gereğinden fazla düşündüğünden ve token yaktığından şikâyet ediyor. Belirli bir problemi çözen kodun “nasıl hissettirmesi gerektiğine” dair deneyim ve sezgi olduğunda geliştirici doğal olarak ne zaman geri dönüp bakması gerektiğini bilir. Ajanlar da belki daha iyi eğitimle böyle bir sezgi kazanabilir

• Kasım 2025 dönüm noktasından sonraki verilerle güncellenmiş halini görmek isterim