Yapay zeka bizi iyi kod yazmaya zorluyor

 (bits.logic.inc)
17 puan yazan GN⁺ 2025-12-31 | 1 yorum | WhatsApp'ta paylaş
  • Yapay zeka ajanları kod yazımının merkezine girdikçe, testler, dokümantasyon, statik tipleme gibi daha önce ‘isteğe bağlı’ görülen iyi uygulamalar artık zorunlu hale geliyor
  • %100 kod kapsamı talep edilerek, her kod satırının gerçekten doğrulanması ve çalıştırılabilir örneklerle desteklenmesi sağlanıyor
  • Dizin yapısı ve dosya adlandırması netleştirilerek LLM’in kod tabanında gezinmesi kolaylaştırılıyor ve küçük birimlere ayrılmış dosya düzeni teşvik ediliyor
  • Hızlı, geçici ve eşzamanlı çalışabilen geliştirme ortamları kurularak birden fazla ajanın paralel çalışması mümkün kılınıyor
  • Statik tip sistemleri ve otomatik kalite kontrol araçları ile yapay zekanın güvenebileceği bir kod ekosistemini korumak temel unsur haline geliyor

Yapay zeka ve ‘iyi kod’un zorunluluğu

  • Uzun süre boyunca geliştiriciler testler, dokümantasyon, küçük modüller ve statik tipleme gibi unsurları iyi kodun ölçütü olarak gördü, ancak pratikte bunlar sık sık atlandı
  • Ancak yapay zeka ajanları kodu kendi başlarına iyi toparlayamadığı için, bu iyi uygulamalar artık mutlaka gerekli
  • Ajanların yanlış yöne sapmaması için net koruma sınırları belirlemek ve bunları zorunlu kılmak şart
  • Sağlam koruma sınırları olduğunda LLM doğru yola yakınsıyor; eksik bir ortamda ise sorunları büyütüyor

%100 kod kapsamı

  • Ekip %100 kod kapsamını zorunlu tutuyor; bunun amacı yalnızca hataları önlemek değil, ajanın yazdığı tüm kodun davranışını doğrulamak
  • %95 ya da %99,99 kapsamda test edilmemiş kodun kaynağı belirsiz kalırken, %100 kapsamda doğrulanmamış her satır açıkça tespit edilebiliyor
  • Kapsam raporu test edilmesi gerekenlerin listesi gibi kullanılıyor ve LLM’in kod değiştirirken mutlaka çalıştırılabilir örnekler sunması gerekiyor
  • Bu yaklaşımın ulaşılamayan kodun kaldırılması, uç durumların açıkça belirtilmesi ve kod incelemesinin verimliliğinin artması gibi yan etkileri de var

Ad alanları ve dosya yapısı

  • Ajanlar kod tabanında dosya sistemi üzerinden gezindiği için, dizin yapısı ve dosya adları önemli bir arayüz işlevi görüyor
  • ./billing/invoices/compute.ts gibi net bir yol, ./utils/helpers.ts’ye göre çok daha fazla bilgi taşıyor
  • Küçük ve iyi tanımlanmış dosya birimleri tercih edilmeli; bu sayede LLM dosyanın tamamını bağlama yükleyebiliyor ve performans düşüşü önleniyor
  • Bu tür bir yapılandırma, ajanın gezinme hızını ve doğruluğunu artırıyor

Hızlı, geçici ve eşzamanlı çalışabilen geliştirme ortamları

  • Geleneksel tekil geliştirme ortamı yerine, ajan tabanlı geliştirmede birden fazla sürecin paralel yönetildiği bir yapıya geçiliyor
  • Fast: Test ve doğrulama süreçleri hızlı çalışmalı; ekip 10.000’den fazla assertion’ı 1 dakika içinde tamamlayacak şekilde optimizasyon yapıyor
    • Yüksek düzeyde paralelleştirme, güçlü izolasyon ve üçüncü taraf çağrıları için önbellekleme katmanı ile hız sağlanıyor
  • Ephemeral: new-feature <name> komutuyla 1-2 saniye içinde yeni ortam oluşturuluyor, otomatik kurulum yapılıyor ve ajan çalıştırılıyor
    • Manuel kurulum gerektiğinde kullanım sıklığı keskin biçimde düştüğü için, tam otomasyon kritik önem taşıyor
  • Concurrent: Birden fazla geliştirme ortamını aynı anda çalıştırabilmek için port, veritabanı, önbellek gibi kaynaklarda çakışmayı önleyecek ayarlar gerekiyor
    • Docker kullanılabiliyor ya da ortam değişkeni tabanlı izolasyon kurulabiliyor

Uçtan uca tip sistemi ve otomatik kalite yönetimi

  • Mümkün olduğunca çok iyi uygulama otomatikleştirilerek LLM’in hareket alanı daraltılıyor ve tutarlı kalite korunuyor
  • Otomatik linter ve formatter araçları sıkı biçimde yapılandırılıyor; böylece LLM işi bitirdiğinde düzeltmeler otomatik uygulanıyor
  • Statik tipli dillerin kullanılması öneriliyor; özellikle TypeScript etrafında güçlü tip sistemlerinden yararlanılıyor
    • UserId, WorkspaceSlug, SignedWebhookPayload gibi anlamlı tip adları ile kodun niyeti açıkça ifade ediliyor
  • OpenAPI ile frontend ve backend arasında tip uyumu korunuyor
  • Postgres tip sistemi ve trigger’ları kullanılarak veri bütünlüğü sağlanıyor, Kysely ile tip güvenli istemciler üretiliyor
  • Tüm üçüncü taraf istemciler de doğru tip tanımlarına sahip olmalı ya da bu amaçla sarmalanarak kullanılmalı

Sonuç: Yapay zeka çağında kod kalitesinin yeniden tanımı

  • Ajanlar yorulmayan ve çok yetenekli kodlayıcılar, ancak performansları ortamın kalitesine bağlı
  • ‘İyi kod’ artık bir tercih değil, yapay zekanın düzgün çalışması için ön koşul
  • İlk kurulum yük gibi görünse de bu, uzun süredir ertelenen zorunlu bir yatırım
  • Geliştirme liderliğinin desteğiyle, yapay zeka dostu bir kod tabanı kurmak hedeflenmeli

İlgili okumalar

1 yorum

 
GN⁺ 2025-12-31
Hacker News görüşleri

  • %100 kapsama sağlamanın tuzağı, kod ve testler aynı ajan tarafından yazıldığında kendi kendini çürüten bir doğrulama durumuna düşülebilmesidir
    Ajan hatalı mantık kurup bunu doğrulayan testleri de hatalı yazarsa, testler geçer ama gerçekte hatalı bir kod ortaya çıkar
    Bu tür kapsama ancak testler koddan önce yazıldığında ya da bir insan tarafından sıkı biçimde doğrulandığında anlam taşır
    Aksi halde sadece hayali bir güvenilirlik üretmekten ibarettir

    • Dediğin doğru ama çözüm basitçe “bunu insan yapsın” ya da “koddan önce test yazalım” değil
      Asıl önemli olan, farklı düşünme biçimlerine sahip birden çok insanın birbirinin kör noktalarını doğrulamasıdır
      AI modeli birden fazla olsa bile sonuçta tek bir ‘zihin’ gibi ele alınmalıdır
      İnsan koduna AI testi, AI koduna insan testi ya da karşılıklı code review gibi yaklaşımlar iyi olur
      Ama insanlar arasında da güç ilişkileri yüzünden bazen yalnızca tek kişinin görüşü yansır; AI bunu engellemez
    • Bu yüzden testleri test etmek gerekir
      Bilerek hata ekleyip başarısız olup olmadıklarını görmek gerekir
      Bu yalnızca AI’a özgü bir sorun değil; insanlar için de aynı şey geçerli
      Yine de AI sayesinde birçok geliştiricinin doğru mühendislik ilkelerini öğrenmeye başlaması sevindirici
    • Değişimin %100 kapsamada değil, %100 MC/DC kapsamasında ortaya çıktığını düşünüyorum
      SQLite ya da havacılık yazılımları böyle bir seviyeyi hedefliyor
      Yine de bu henüz akademik olarak doğrulanmış bir hipotez değil
    • İnsan eliyle yazılmış birim testleri de aynı sorunu taşır
      Bu yüzden gerçek kullanıcı senaryolarını entegrasyon testleri veya UI otomasyon testleriyle doğrulamak gerekir
      Üretim ortamından alınan veriler ya da shadow environment testleri de yardımcı olur
    • Zaten BDD veya Acceptance Test gibi iyi, kod tabanlı çözümler var
      LLM öncesinde kurulum zahmetliydi ama şimdi ROI daha iyi
      Uncle Bob’un vurguladığı gibi testleri yapılandırmaya yatırım yapmak önemli
      LLM tekrar eden testleri yazar ama istersen DRY ilkesi ya da factory pattern’i de gayet iyi uygular

  • Dün denemeye başladığım bir yöntem var: önce TLA+/PlusCal ile spesifikasyonu yazıyorum, sonra Codex’ten bu spesifikasyonu olduğu gibi uygulamasını istiyorum
    Yaratıcılık göstermeden yalnızca spesifikasyona sadık kalmasını söylüyorum
    Ortaya çıkan kod çirkin ama doğru, ve elle çevirmekten çok daha hızlı
    Ama optimizasyon zayıfsa ya da fazla dağınıksa bazı kısımları düzenliyorum
    Özellikle kilitsiz veri yapıları üzerinde denemeler yapıyorum ama Codex hâlâ kilit kullanmaya meylediyor, bu yüzden elle düzeltmem gerekiyor
    Sonuçta ben matematiksel mantığa odaklanıyorum, AI ise uygulama ayrıntılarını üstleniyor
    Bu da tam olarak “önce spesifikasyon, sonra kod” akışının ideal hali

    • Ben de benzer şekilde geliştiriyorum
      Martin Kleppmann’ın yazısına katılıyorum
    • Son zamanlarda Haskell ya da Prolog ile yinelemeler denedim; LLM ile modelleme/doğrulamayı birlikte araştıracak bir grup olsa iyi olurdu
    • LLM’in spesifikasyon yazımına da katılmasını sağlarsan etkisi daha da artıyor
      Yeni modellerde bu gerçekten işe yarıyor ve maliyet verimliliği de 10 ila 100 kat iyileşti

  • Bu bana halüsinasyon ya da bir satış konuşması gibi geliyor
    Gerçek üretim hataları ve bakım yükü iyi kodu zorunlu kılamıyorsa, AI da kılamaz
    Bugünkü seviyedeki AI muhtemelen kodu daha da kötüleştirir

    • Sorun, “iyi kodun ne olduğunu herkes biliyor” varsayımı
      Metot uzunluğu konusunda bile uzlaşma yokken evrensel bir kalite standardı yok
      Test kapsamı gibi metrikler kolayca manipüle edilebilir ve yanlış uygulanırsa zararlı bile olabilir
    • Test kapsamı iyi kodun yerine geçmez
      Özellikle testleri AI yazdığında sahte bir özgüven verebilir
    • Orijinal yazının yazarı bir AI şirketinin CEO’su olduğu için önyargı olabilir /s

  • Bence yazılım geliştirme, LLM’in tek gerçek anlamda pratik kullanım alanı olabilir
    Çünkü diğer alanlara göre geri bildirim döngüsü çok daha hızlı kurulabiliyor
    LLM ile bir plan yapıp birkaç saat sonra başarısız olduğunu görünce, LLM “işte bu yüzden öyle yapmamalısın” diyor
    Bu, Amerikan elektrik standardıyla bir ev kurup sonra Kanada tipi bir bulaşık makinesi takarken sorun fark etmeye benziyor

    • Bu yüzden diğer mühendislik alanlarında katı kurallar ve yetkinlik sistemleri var
      Yazılım görece güvenli olduğu için bugüne kadar anonim geliştirme mümkündü ama artık sorumluluk içeren imza kültürü oluşuyor
      Gelecekte yalnızca yüksek riskli ve yenilikçi kod yazanlar yüksek ücret alabilir
    • Ama bunun neden LLM’in faydalı olduğu sonucuna vardığını anlamıyorum
      AI sürekli saçma kod üretir, biz debug ederiz, sonra bir yenisini üretir; sonuçta sonsuz bir döngüye gireriz
    • Kanada tipi bulaşık makinesi de kurulabilir
      Sadece akım standardı uygunsa güvenlidir
    • Simülatörler veya digital twin yaklaşımı düşünülürse, gerçek sistemi kurmadan da geri bildirim döngüsü oluşturulabilir
      Yine de benim için birim testlerle gerçek dünyaya temasın doğrulanabiliyor olması sevindirici
    • “Yazılım dışında pratik kullanım alanı yok” demek kibirli bir iddia
      Ben LLM ile RLC devreleri ve inerter çalışıyorum

  • Birçok kişi LLM’in hızlı kod üretmesini görünce etkileniyor ama hız veya miktar kalite darboğazı değil
    Gerçek devrim, AI insanlardan daha doğru kod yazabildiğinde olacak

    • LLM kullandığında mühendis, sistemin gerçek uygulamasını anlama noktasından uzaklaşır
      Asıl değer, kodun nasıl çalıştığını bilmekten gelir
      Toplantıda herkes tahmin yürütürken bir kişinin gerçekten kodu açıp göstermesi en değerli andır

  • “İyi kod” belki de insanın sınırlı çalışma belleğine göre optimize edilmiş koddur
    Model tüm bağlamı aynı anda görebildiği için böyle bir kısıtı yok
    Context window 100 kat büyürse bu tartışmaların önemi azalabilir

  • LLM’den %100 kapsama istemenin yanlış varsayımları kalıcılaştırmasından endişe ediyorum
    Yine de insan incelemesi varsa “bu yanlış, testleri silip yeniden yazalım” denebilir, değil mi?

    • Evet, hâlâ test senaryolarını insan gözden geçiriyor
      LLM sanki röportaj yapar gibi PRD’yi birlikte hazırlıyor; böylece kapsam ve beklentiler netleşiyor
    • Gerçekte LLM sık sık “1=1 mi?” gibi anlamsız testler üretiyor

  • “Best practice” teknik ortama göre değişir
    Artık kod yazmanın kolaylaştığı bir dönemde, %100 kapsama LLM için daha faydalı olabilir
    Testler LLM’e net bir hedef verir ve sonraki etkileşimleri daha güvenli hale getirir

    • Uzun süre evrilen sistemlerde testler can simididir
      Her test geçmişteki bir bug kaydına referans verir ve düzeltmenin korunmasını sağlar
    • “Best practice” uygulama farklı olsa da örüntü olarak benzerdir
      LLM’e senaryoyu verdiğinde çoğu zaman benzer kalitede kod üretir
      Yaratıcı sanatların aksine yazılım, otomasyona çok uygun bir endüstridir

  • Yazıyı görünce “AI’ın etkili olabilmesi için bizim iyi kod yazmamız gerekir” deneceğini sanmıştım
    Gerçekte Claude, belirsiz değişken adlarında ya da mantıksız kodda sık sık hata yapıyor
    Değişkenin adı “iteration_count” olup içinde toplam tutuluyorsa AI kolayca yanılıyor
    Sonuçta temiz kod, hem AI’a hem insana yardımcı olur

    • AI sayesinde ekipler dokümantasyon ve yorum bakımına daha çok dikkat etmeye başladı
      AI iç dokümanları öğrenme kaynağı olarak kullandığı için artık güncel dokümantasyon zorunlu görülüyor
      Eskiden düşük öncelikliydi ama şimdi model kalitesini doğrudan etkiliyor
    • İnsanlar bir kez gördükleri kodun bağlamını hatırlar ama AI her oturumda yeniden öğrenmek zorundadır
      Yine de zamanla bu tarafın da iyileşeceğini düşünüyorum
    • Etkili yöntem, metot imzaları ve yorumlarla niyet ile mantığı açıkça yazmak
      Böylece LLM’in tek seferde doğru uygulama üretme olasılığı artar

  • Bu yazı, prompt şirketlerinin yüzeysel mühendislik anlayışını ortaya koyuyor
    %100 kapsama, tüm girdi kombinasyonlarının doğrulandığı anlamına gelmez
    Sadece birkaç örnekle tüm satırların çalıştırıldığı anlamına gelir
    Sonuçta gereken şey biçimsel ispat ama onun maliyeti astronomik ve LLM burada işe yaramaz

    • Peki çözüm ne? Kıdemli birinin PR’ye bakıp “LGTM” demesi duygusal bir testten ibaret
      Bunun yerine testlerle tepkisel bir geliştirme ortamı kurmak yeni bir altın çağ başlatabilir
      Kapsamayla ilgili sorun çıkarsa sonra genişletilir
      En baştan olabildiğince kapsamlı bir test düzeni kurmak daha iyi
    • LLM’in biçimsel doğrulamada işe yaramadığını söylemek fazla iddialı
      Zaten proof assistant’larla birlikte kullanma yönünde birçok deneme var
      Spesifikasyonda küçük hatalar olsa bile çoğu zaman işe yarar sonuçlar üretiyor