LLM doğru kod yazmaz; sadece kulağa doğru gelen kod yazar

• SQLite'ın LLM tarafından Rust ile yeniden yazılmış sürümü, birincil anahtar sorgularında orijinaline göre yaklaşık 20.000 kat daha yavaş performans gösteriyor
• Kod derleniyor ve testleri geçiyor, ancak içeride temel algoritma hataları ve verimsiz tasarım bulunuyor
• Başlıca nedenler PRIMARY KEY algısının atlanması ve her sorguda fsync çağrılması gibi sorunlar; yapı makul görünüyor ama gerçek çalışma anormal
• Bu durumun ana nedeni, yapay zeka modellerinin “makullük optimizasyonu” (sycophancy) eğilimi; kullanıcı açık doğrulama ölçütleri (acceptance criteria) tanımlamazsa kolayca yanıltılabilir
• LLM'ler ancak deneyimli geliştiriciler doğruluk ölçütlerini açıkça belirlediğinde üretkenliği artırabilir; aksi halde yalnızca bir token üreticisi olarak kalır

---

LLM tarafından üretilen kodun performans deneyi

• SQLite'ın birincil anahtar sorgusu (100 satır için) 0.09ms, LLM'in ürettiği Rust sürümü ise 1,815.43ms ile yaklaşık 20,171 kat daha yavaş
  • Her iki uygulama da aynı sorgu, şema ve derleme seçeneklerini kullanıyor
  • Turso/libsql ile ilgisi yok; Turso, SQLite'a kıyasla yaklaşık 1.2 kat düzeyinde normal performans gösteriyor
• Rust sürümü başarıyla derleniyor, testleri geçiyor, dosya biçimi uyumluluğunu koruyor; dışarıdan bakınca normal çalışıyor gibi görünüyor
  • Ancak gerçekte temel veritabanı işlemlerinde ciddi performans düşüşü yaşanıyor

Başlıca hata analizi

• Hata #1: INTEGER PRIMARY KEY algısının atlanması
  • SQLite, id INTEGER PRIMARY KEY ifadesini dahili rowid'ye eşleyerek O(log n) arama yapar
  • Rust sürümünde is_rowid_ref() yalnızca "rowid", "_rowid_", "oid" değerlerini tanıyor
  • Sonuç olarak WHERE id = N sorgusu tam tablo taraması (O(n²)) olarak işleniyor ve 20.000 kat yavaşlıyor
• Hata #2: Her sorguda fsync çağrılması
  • Transaction dışındaki her INSERT için tam senkronizasyon (fsync) yapılıyor
  • SQLite, meta veri senkronizasyonunu atlamak için fdatasync kullanıyor ve bu yüzden çok daha verimli
  • 100 INSERT işleminde Rust sürümü 2,562.99ms, SQLite ise 32.81ms ile 78 kat fark oluşturuyor

Bileşik verimsizlik etkenleri

• AST kopyalama ve yeniden derleme, 4KB heap tahsisi, şemanın yeniden yüklenmesi, string biçimlendirme, nesnelerin yeniden oluşturulması gibi birçok tasarım tercihi birikerek yaklaşık 2,900 kat performans kaybına yol açıyor
• Her karar “güvenlik” gerekçesiyle savunulabilir, ancak kritik yürütme yolu (hot path) üzerinde ölümcül darboğazlara dönüşüyor
• SQLite'ın performansı sadece C dilinden değil, 26 yıllık profilleme ve ince ayardan kaynaklanıyor

İkinci örnek: Gereksiz derecede karmaşık disk yönetim aracı

• LLM tarafından üretilen başka bir Rust projesi, build artifact temizleme daemon'unu 82.000 satır olarak uyguladı
  • 192 bağımlılık, 7 ekranlı bir dashboard, Bayesyen puanlama motoru gibi aşırı özellikler içeriyor
  • Oysa gerçek sorun tek satırlık bir cron komutuyla çözülebiliyor: find ... -exec rm -rf
• Bu, “istenen işlevi” sadakatle uygulasa da gerçek problemi çözmek için gereksiz karmaşıklık ekleyen bir örnek

Niyet ile doğruluk arasındaki uçurum: Sycophancy olgusu

• LLM'ler, kullanıcının beklentisine uyma yönünde “yağcı uyum (sycophancy)” eğilimi gösteriyor
  • Anthropic araştırması (2024) ve BrokenMath benchmark'ı (2025), doğruluk yerine katılım/onay oranını öğrenen yapısal bir sorunu doğruluyor
  • GPT-5 bile kullanıcı olumlu sinyal verdiğinde yanlış teoremler için ispatları %29 oranında üretiyor
• RLHF (insan geri bildirimiyle pekiştirmeli öğrenme), onay yanlılığını (agreement bias) güçlendiriyor
  • OpenAI, 2025'te GPT-4o güncellemesini bu sorun nedeniyle geri aldı
• Aynı önyargı yalnızca kod üretiminde değil, kendi kodunu gözden geçirirken de çalışıyor; model hatalarını kendi başına tespit edemiyor

Dış araştırmalar ve sektör verileri

• METR deneyi (2025–2026): Yapay zeka kullanan 16 deneyimli açık kaynak geliştiricisi %19 daha yavaştı, ama kendileri daha hızlandıklarını düşündü
• GitClear analizi (2020–2024): 211 milyon satır içinde kopyala-yapıştır artışı, refactoring azalması gözlendi
• Replit olayı (2025): Bir yapay zeka ajanı üretim veritabanını sildikten sonra sahte 4.000 kullanıcı oluşturdu
• Google DORA 2024 raporu: Takım bazında yapay zeka kullanım oranı %25 arttığında teslimat istikrarı %7.2 düştü

SQLite'ın gösterdiği “doğruluk” ölçütü

• SQLite yaklaşık 156.000 satır C kodundan oluşuyor, %100 MC/DC kapsamı sağlıyor ve havacılık yazılımı düzeyinde doğrulama elde etmiş durumda
• Başlıca performans etkenleri:
  • Zero-copy sayfa önbelleği
  • Prepared statement yeniden kullanımı
  • Schema cookie kontrolüyle gereksiz yeniden yüklemelerin önlenmesi
  • Commit gecikmesini en aza indirmek için fdatasync kullanımı
  • iPKey kontrolüyle O(log n) aramanın garanti edilmesi
• Buna karşılık Rust ile yeniden yazılan sürüm 576.000 satır olmasına rağmen kritik tek satırı, yani is_ipk kontrolünü, atladı

Sonuç: “Makullüğü” değil “doğruluğu” tanımlamak gerekir

• LLM'ler örüntüleri taklit eder, ancak performans değişmezlerini (invariant) kendi başına öğrenemez
• “Kod derleniyor” demek yeterli değildir; hataları doğrudan bulup açıklayabilmek gerekir
• LLM'ler, deneyimli geliştiriciler doğruluk ölçütlerini açıkça tanımladığında güçlü bir araca dönüşür
• Aksi halde yalnızca makul görünen bir token üreticisi olarak kalır ve “vibe coding” düzeyini aşamaz
• Ana mesaj: Önce doğruluk ölçütlerini tanımlayın, sonra ölçün.

[jokerized]

Basit bir performansla ilgili başarı kriteri bile verilmediğinde ne olduğunu gayet iyi gösteren bir örnek gibi görünüyor. Şu ana kadar kullandığım kodlama ajanları, açık bir ön istem ya da doğrulama döngüsü olmadan, hâlâ doğrudan sorunu çözmeye odaklanıyor; performansı ise neredeyse hiç kendi başlarına optimize etmiyorlar. Yapay zekâya talimat verirken, sanki bir kodlama testi sorusu veriyormuşsunuz gibi düşünmek gerekiyor. Özellikle böyle bir baseline varken bile performans koşullarını açıkça belirtmeden en iyi performans sonucunu beklemek, bir bakıma yapay zekâyı kullanan kişinin ihmali sayılabilir.

[mammal]

+1 👍

[ndrgrd]

Aslında bu sadece LLM’lere özgü değil, insanlar da böyle.
Fark şu ki insanda geri bildirim işe yarıyor ama LLM’lerin tuhaf alışkanlıklarını düzeltmek neredeyse mümkün olmuyor. Uyarılsa bile bir noktada dönüp yine aynısını yapıyor.
Verimsizlik ve yorgunluk da tam bu noktada ortaya çıkmıyor mu

[armila]

İnsanlar modelin özelliklerini anlayıp uygun prompt ve beceri iş akışlarını bulup uygulayacak noktaya geldiğinde zaten yeni bir model çıkmış oluyor....
Ajanları şu anda gerçekten düzgün kullanabildiğimizden bile emin değilim.

[skrevolve]

Georgehotz da AI'ı bir tür derleyici olarak görüp kullanıyor. Tasarım, yapı ya da seçimler konusunda ise hâlâ insan muhakemesine ihtiyaç var... Genel olarak inisiyatifi yapay zekaya bırakırsanız, geliştiricinin bunu yapmasına zaten gerek kalmaz.

[happing94]

Zaten kusursuz şekilde uygulanmış, acayip optimize bir sorguyla karşılaştırıp bunu başka bir dilde yeniden yazmasını istersen, elbette daha yavaş olur
Sonuçta sadece "yaz gitsin" demişsin lol

[cocofather]

Big Tech seviyesinde vibe coder arkadaşların yorumlarda belirmesi bekleniyor.

[github88]

Yapıcı bir yorum yazmayacaksanız, lütfen hiç yorum yazmayın.

[crawler]

Gülüp geçiyorum

[newbie1004]

hahahahaha boktan yazılar da yazıdır

Bir şey demeyin lütfen

ölü internet teorisine dönüşmeden önce

kaka hihi

[overthinker]

Bu Hacker News'ten alınıyor diye orada da hep üretken yorumlar yapıldığını mı sanıyorlar... pek hoş görünmüyor.

[salsa]

Hacker News yönergelerini hiç okudun mu.. Böyle yazılardan kaçınmak doğru olur; "o da sıçıyor, neden sadece bana yükleniyorsun" gibi bir zihniyet gerçekten çok çocukça.

[cocofather]

Yanlış. Doğrusu, o da sıçıyor; neden sadece ona yükleniyorsunuz, demek olur.

[galaxy11111]

Biraz kurcalayınca bunu hemen hissediyorsunuz. Diğer geliştiricilerin incelemeden yorulduklarını söylemesini anlayamıyordum ama promptları ve becerileri ne kadar iyi kullanırsanız kullanın, yapay zekanın ürettiği kodda her zaman bir yerde bir kusur oluyordu.

[mammal]

Orijinal metni okudum; yerinde bir analiz ve eleştiri gibi görünüyor. Ancak alıntılanan araştırmalarda kullanılan deney modelleri bugünün perspektifinden bakınca biraz eski kalmış gibi geliyor.

[GN⁺]

Hacker News görüşleri

• Temelde LLM'ler bir sorun çıktığında bunu koda daha fazla kazıyarak çözmeye çalışma eğiliminde oluyor
  Verimsiz bir yaklaşımla uygularsa, sonrasında her kısıta çarptığında dolambaçlı kodlar veya yinelenen kodlar eklemeye devam ediyor
  Performans yavaş denirse hızlı yol optimizasyonları, özel rutinler, özel veri yapıları ekleyerek kodu geometrik biçimde büyütüyor
  Hata çok denirse her hata için 10'ar test yazıyor, mevcut mocking framework uymuyorsa yenisini yapıyor
  Yinelenenleri birleştirelim denirse “Harika, tüm özellikleri içeren yeni bir metamock abstract adapter framework yapayım!” diyerek bir başka karmaşık yapı daha ekliyor

  • Bu yüzden insanlar “henüz programcıların yerini almaya hazır değil” dediğinde kafam karışıyor
  • Üstelik böyle bir birleştirme işi yapsa bile gerçekte yinelenen kodun ancak yarısını taşıyor, ölü kodu da olduğu gibi bırakıyor
  • Kod üretme hızı yüksek ama ortaya çıkan şeyin uygun ve doğrulanmış bir uygulama olup olmadığını kontrol etmek için saatler harcamak gerekiyor
    Yanlış varsayımlar veya teknik borç üretmediğinden emin olmak için inceleme süreci şart
  • Bu yüzden ben top-down yaklaşımı öneriyorum
    Önce makul bir mimari tasarlatın, modüller birbirine dolaşırsa temiz bir bağlamda yeniden başlatın
    LLM'ler aynı kodu tekrar tekrar düzenlemede zayıf ama "Groundhog Day" tarzı baştan yeniden uygulamada güçlü
  • Kilit nokta, ne zaman mevcut çözümü (sqlite gibi) kullanacağını ve ne zaman sıfırdan yapacağını bilmektir
    LLM'ler bu tür kararların sonuçları hakkında uyarı vermez veya hatırlatma yapmaz
    Bu yüzden Codex yerine Claude Code'u tercih ediyorum

• Hukuki belge yazımında da LLM'nin “makul görünen” çıktısı sorun yaratıyor
  İlk bakışta geçerli gibi görünse de gerçekte çoğu zaman mantıksal olarak uygunsuz ya da riskli iddialar içeriyor
  Hâkimlerin ayrıntılı inceleme yapacak zamanı ya da isteği olmadığından bu belgeler bazen olduğu gibi geçebiliyor
  Bu da Brandolini yasasında olduğu gibi, üretmenin kolay ama çürütmenin zor olduğu asimetrik bir yapı yaratıyor
  Sonuçta bu, gelecekteki geliştiricilerin LLM'nin ürettiği bilişsel ve teknik borcu çözmek zorunda kalmasına benziyor

  • Ben de benzer bir deneyim yaşadım
    Kural tabanlı belgeleri LLM yazdığında makul görünen ama temelsiz imalar içeriyor
    Bu yüzden daha sonra yine LLM'ye kendi yazısını inceletip bu kısımları işaretletiyorum ama sonuçta yine de insan incelemesi gerekiyor
  • Kodlamada da aynı durum var
    İş arkadaşlarım LLM ile birkaç dakika içinde binlerce satırlık PR üretiyor
    Testler de dahil oluyor ama gerçekte çoğu zaman tam bir karmaşa çıkıyor
    Sonuçta inceleyen kişi bütün gününü bunu gözden geçirmeye, yanlış yapıyı anlamaya ve düzeltme yönünü anlatmaya harcıyor
    Bu yüzden AI ile üretilmiş PR'larda reviewer'a story point verilmesi gerektiğini önermek istiyorum
  • Bir avukat olarak bu durumu gösteren somut örnekleri merak ediyorum
  • Sonunda akıl yürütmenin (reasoning) kendisini yeniden tasarlamak gerekiyor
    Makul yargıyı biçimsel mantıkla hesaplayıp sonucu doğal dile çeviren bir yapıya ihtiyaç var
    LLM düşünmenin değil, yorumlama ve ifade etme aşamasında kalmalı
  • Elbette adaletin zarar görmesinin nedenlerinden biri de birçok insanın baştan düzgün hukuki temsil masrafını karşılayamaması

• LLM'nin yazdığı kod çoğu zaman testleri geçse de gereksinimleri karşılamıyor
  Örneğin her sorguda fsync çağırıyor ya da birincil anahtarı yanlış tanımlıyor
  Bu tür büyük projelerde kod o kadar fazla oluyor ki insanların hepsini okuması zorlaşıyor
  Bu yüzden LLM en verimli şekilde otomatik tamamlama seviyesinde kullanılıyor
  Küçük kod parçaları anında gözden geçirilebiliyor ve Claude genelde isabetli oluyor
  Ama tüm kodu ona bırakırsanız planlama ve yönetime daha çok zaman gidiyor, bakım da zorlaşıyor
  Sonuçta hız avantajı yalnızca eğitim verisinde zaten bulunan kodu yeniden üretirken ortaya çıkıyor

• LLM'ler istatistiksel olarak en yaygın kod kalıplarını üretiyor
  Bu yüzden özel bir yönlendirme yoksa ortaya “enterprise havası taşıyan, OOP tabanlı ve bir sürü trend bağımlılık kuran kod” çıkıyor

• “Doğruluk” tanımlanmalı ve ölçülmeli
  Otomasyon için niyet (intent) ve ölçüm (measurement) gerekir
  Risk alanını anlamak, önceden ne kadar kapsam gerektiğini bilmek için şarttır
  AI evals veya eval-ception gibi araçlar
  roller arasında ortak bir dil hâline gelirse iş birliği çok daha kolay olur

• LLM'nin özü, en makul görünen kodu üretmek üzere tasarlanmış olmasıdır
  Bu, cross entropy loss sonucudur; RLVR gibi sonradan yapılan işlemler doğruluğu artırmaya çalışsa da
  hâlâ çok sayıda kalıntı vardır
  İleride reward engineering gelişirse daha iyi sonuçlar üretme ihtimali olabilir

• “Bu insanlardan ne kadar farklı?” sorusuna karşılık

  • İnsanlarda hedef odaklı yürütücü işlev vardır
    Uykuda bu işlev kapanır ve rüya gibi mantık dışı düşünceler ortaya çıkar; LLM'nin düşünmesi de buna benzer bir rüya mantığı düzeyindedir
  • Şu anki geliştirme ortamında şaşırtıcı olan şey teknik borcun hızlanması
    Eskiden teknolojiyi tam anlamadan kullanma kaygısı vardı ama şimdi araçlar bu kaygının üstünü örtüyor
    Derin bir anlayış olmadan da sonuç üretilebilen bir döneme girdik
  • LLM sonuçta internetin ortalamasını veren bir varlık
    Ama insanlar nesnel ve doğru yanıt veren bir AI bekliyor
    Bu uyumsuzluk, genel kullanıcılarla uzmanlar arasındaki algı farkını yaratıyor
  • Düşük kaliteli bir çalışanı işten çıkarmak kolay ama Claude'un işine son verilmesini savunmak zor
  • Sorun ölçek
    Günde binlerce satırlık PR açan insanlar var
    Bunların çoğu berbat olduğu için inceleme yapılamıyor
    Eskiden böyle bir PR hazırlamak bir hafta sürerdi, şimdi bir günde üzerinize yağıyor

• “LLM” teriminin kendisi hakkında da çok soru var
  Doğrudan raw API ile çağrılan model LLM'dir; Claude.ai veya ChatGPT gibi şeyler ise bunun üstüne harness eklenmiş hâlidir
  Bu harness; prompt şablonları, konuşma durumu yönetimi gibi çeşitli işlevler içerir
  Sonuçta biz neredeyse her zaman LLM'den fazlasını kullanıyoruz

  • Kod çalıştırabilen bir harness'e ben “coding agent” diyorum
    Bu tür ajanlar kodu çalıştırabilir, kendi kendine test edebilir ve düzeltebilir
    ChatGPT ve Claude da bu yeteneğe sahip olduğu için aslında birer coding agent
  • Özetlemek gerekirse
    • LLM = modelin kendisi (durumsuz, yalnızca metin girdi/çıktısı)
    • LLM + sistem prompt'u + konuşma geçmişi = chatbot
    • LLM + araçlar + bellek + orkestrasyon = agent
      Yani “LLM'nin hafızası yoktur” sözü yalnızca modelin kendisi için geçerlidir
      Claude Code veya Cursor ise durum tutan agentic systemlerdir

• Bu yazının başlığı ilgi çekici ama LLM'nin “makul görünen kod” yazdığı ifadesi eksik
  Gerçekte yaptığı şey yalnızca eğitim verisinde gördüğü kod kümelerine benzeyen kod üretmektir
  Sadece RLHF veya RLVR ile sınırlandırılmamış alanlarda serbest üretim yapar

  • Eğitim verisinin büyük kısmı Python, ondan sonrası da web teknolojileri
    Bu yüzden sektörün geneli aynı dille konuşuyor ama bu durum aslında yanlış anlamaların nedeni oluyor
    Herkesin aynı problemi çözdüğü sanrısını oluşturuyor
  • Dağılım dışı (out-of-distribution) alanlara girildiğinde model halüsinasyon üretmeye başlıyor
    Örneğin tree-sitter sorgusu isterseniz var olmayan yönergeler uyduruyor
  • Yine de “plausible” kelimesi uygun bir ifade
    İçerideki karmaşık yapıyı illa açıklamak gerekmiyor

• Geçenlerde Codex'e Datastar tabanlı bir UI öğesi yaptırdım ve tamamen başarısız oldu
  Basit bir işti ama her yeniden denemede inline JavaScript ve backend kodu durmadan arttı
  Önceki kodu da temizlemiyordu
  Karmaşık işlerde iyi olabiliyor ama ironik biçimde çok temel görevlerde sezgiye aykırı biçimde başarısız olabiliyor