6 puan yazan GN⁺ 2026-01-22 | 1 yorum | WhatsApp'ta paylaş
  • Ajan tabanlı kodlamayı denedim ama internette gördüklerimle benim gerçekten uygularken elde ettiğim sonuçlar arasındaki uçurum yüzünden kafam karışık; bunun gerçekten olumlu sonuç verdiğine dair kanıt var mı?
  • Abartılı tanıtımın ötesinde, ajan tabanlı kodlamayı başarıyla uygulamış olan varsa bunu nasıl yaptığını lütfen ayrıntılı paylaşsın
  • "Başarıyla uygulamak" şu anlama geliyor:
    • teknik borçtan daha fazla değer üretmek
    • mimari sorumlusunun onaylayabileceği kadar yapısal olarak sağlam kod yazmak
  • Son dönemde, "mimari doğrulama"dan "davranış doğrulama"ya geçilmesi gerektiği iddiasıyla birlikte kod incelemesini en aza indirme ya da tamamen kaldırma eğilimi görülüyor
  • Pratikte bu sanki koda bakmadan, testleri ve CI'ı geçerse dağıtıma çıkarma anlamına geliyor; böyle bir yaklaşımın uzun vadede sürdürülebilir olup olmadığı şüpheli
  • Bana göre Codex kullanıldığında, normal yolda çalışsa bile zamanla ince ve hata ayıklaması zor hataların birikmesiyle "spagetti koda" dönüşme ihtimali yüksek
  • Codex'i mevcut bir kod tabanında denediğimde, yönergeler koymuş olayım ya da olmayayım, zamanımın yarısı Codex'in ürettiği ince hataları veya yinelenen kodu düzeltmekle geçiyor
  • Geçen hafta sonu evcil hayvan maması hatırlatma iOS uygulamasını sıfırdan yeniden yapmayı denedim
    • Önce Codex'ten SwiftUI tabanlı bir mimari taslağı araştırıp önermesini istedim, ardından neyin nasıl uygulanacağını anlatan bir spesifikasyonu Codex ile birlikte yazdım
    • İlk uygulamada birkaç hata vardı ama beklenmedik şekilde fena değildi; ancak ondan sonra işler hızla kötüye gitti
    • Kalan hafta sonu boyunca, Codex'in düzgün çalışmasını sağlamaya, yeni hatalar üretmeden hataları düzeltmeye ve rastgele kod yazmak yerine en iyi uygulamaları araştırmasına uğraştım
    • Yeni yönergeler ve keşfettiğim her yeni kuralı Codex'e kaydettirdim ama durum iyileşmedi ve sonunda vazgeçtim
  • Kişisel olarak incelenmemiş kodu üretime almak kabul edilemez
  • Bir şeyler ters gidiyor gibi. Ürün düzgün çalışmalı ama kodun kalitesi de yüksek olmalı

1 yorum

 
GN⁺ 2026-01-22
Hacker News görüşleri
  • LLM'ler maliyet düşürmenin anahtarı olarak görülürken ortada çok büyük para dönüyor
    Ünlü influencer'lar ve uzmanlar da "son teknoloji" imajını korumak için abartılı açıklamalar yapabiliyor
    Ancak gerçekte LLM tabanlı geliştirmenin en iyi yaklaşımı henüz netleşmiş değil
    Şu anda buna bir inanç gibi bağlanmaktan ziyade, nasıl çalıştığını doğrudan incelemenin önemli olduğunu düşünüyorum

    • Ben de yakın zamanda bir şirketten yeni bir "agentic coding platform"u tanıtmam için 200 dolarlık bir teklif aldım
      Bu tür tekliflerin rastgele kullanıcılara kadar gitmesi, ciddi bir pazarlama kampanyasının zaten yürüdüğü anlamına geliyor
    • LLM'ler kesinlikle sıçrama yaratan araçlar, ama tam otonom geliştirmenin her derde deva çözümü değil
      Basit CRUD işleri için keyifli, ama karmaşık projelerde aksine daha çok hayal kırıklığı yaratıyor
      Şu an benchmark yarışı ve VC parası öyle yoğun ki soğukkanlı bir tartışma yürütmek zor
    • GUI ilk çıktığında olduğu gibi, şu an sezgisel değeri hissedilen bir aşamada olduğumuzu düşünüyorum
      Henüz nicel kanıt az olsa da, geliştiriciler tamamen ortadan kalkmayacak olsa bile geliştirme biçimi kalıcı olarak değişti
  • Google'da bir Principal Engineer, "Claude Code bir yıl sürecek işi 1 saatte yaptı" diye tweet attı
    Ama sonradan ortaya çıktı ki AI'ın ürettiği şey sadece basit bir **"oyuncak sürüm"**müş
    Bu tür abartılı söylemler beklentileri çarpıtıyor ve hayal kırıklığına yol açıyor
    İlgili tweet bağlantısı

    • Bu tür tweet'ler çoğu zaman içeride AI liderliğinin başarısını gösterme baskısından kaynaklanıyor
    • Birisi buna "böyle bir şey söylemek akıl almaz" diye tepki verdi
    • Bir başkası da "AI performansı deneyim seviyesi ve yatırım maliyetine göre değişir" diye belirtti
    • "AI hâlâ deploy edilemeyen kod üretiyor" diyerek alaycı yaklaşanlar da vardı
    • Bir başkası da "bu tam Google'ı anlatıyor" diye iğneledi
  • Son 6 aya dönüp baktığımda, altyapı kodunda (ör. Terraform) 10 kat verim aldım
    Ama uzmanlık gerektiren özellik geliştirme hâlâ çok değişken
    Yine de tekrar eden işleri azaltarak açılan zamanda test ve güvenlik kalitesini artırabildim
    Her şeyden önemlisi, yeniden kod yazmanın keyfini hissetmeye başladım

    • Ben de 35 yıldır hobi olarak yazılım geliştiriyorum; AI sıkıcı yazma işini azaltıp yaratıcılığı öne çıkarıyor
    • Ben de build script'leri ve CI işlerinde 2 kattan fazla hızlandım, ama karmaşık HPC projeleri hâlâ zor
      En verimli yaklaşım yardımlı kodlama (assisted coding) oldu
      Proje bağlantısı
    • Evdeki NAS için bir dosya arama aracını Claude ile yaptım; günlük otomatik indeksleme yapan Go backend'i ve web UI'ı bir günde tamamladım
      Bence bu tür kişisel projeler asıl oyun değiştirici olan şey
    • İşleri küçük parçalara bölerseniz ajanlar çok daha iyi çalışıyor
    • Ama test kodu kalitesi hâlâ düşük. Çünkü eğitim verisinin kendisi test yazma konusunda zayıf
  • Ben mevcut uygulamalara ajan ekleme yaklaşımıyla büyük başarı elde ettim
    Ajanlar mimari tasarımda zayıf, ama zaten yapılandırılmış kodlarda çok iyi çalışıyor
    Tip sistemi ne kadar katı ve test kapsamı ne kadar genişse etkisi o kadar büyük oluyor

    • Şu anda bir Rust projesini LLM'in doğrudan yönetip geliştirmesi için deney yapıyorum
      Claude'un yazdığı ROADMAP.md, TASKS.md ve STATUS.md üzerinden ilerliyorum
      Ve şaşırtıcı şekilde proje yaklaşık %20 tamamlanmış durumda
    • C#, katı derleyici ve kural tabanlı ortamı sayesinde ajanlarla iyi anlaşıyor
      Buna karşılık Python veya JS, zayıf tip sistemi yüzünden güven vermiyor
    • Mevcut kod tabanı ne kadar düzenliyse ajan performansı o kadar yüksek oluyor
      Sıfırdan başlamak zor, ama net bir spesifikasyon verilirse verim artıyor
    • Go, dilin basitliği ve tutarlı kalıpları sayesinde LLM'lerin kolay çalışabildiği bir dil
    • Typescript, hızlı derleme ve güçlü tip sistemi sayesinde ajanlar için ideal
      Buna karşılık Python'ın opsiyonel tipleri hataların yayılmasına yol açabiliyor
  • Linux için gerçek zamanlı Bluetooth nabız monitörünü Claude Code ile %100 yazdım
    Proje bağlantısı
    Saf C ile yazıldı; web arayüzü ve gerçek zamanlı grafiklerle birlikte bir günde tamamlandı
    Daha önce başaramadığım dBus–blueZ iletişimini bu kez başarılı şekilde kurdum

    • Ama başka bir kullanıcı kodu inceleyince, SSE implementasyonunun gerçekte çalışmadığı ortaya çıktı
      Dokümanda SSE yazıyor ama içeride aslında sadece normal HTTP yanıtı döndürüyor
    • Bir başkası da "AI'ın yazdığı kod ilk başta iyi görünse de zamanla kalite düşüyor" diye belirtti
    • "Böyle gerçek bir örneği paylaştığın için teşekkürler" diyerek bunu abartısız bir vaka olarak değerlendirenler de oldu
    • UI stilini ilginç bulup tasarımla ilgili soru soran bir yorum da vardı
  • Her gün Augment + Claude Opus 4.5 kullanıyorum
    Neredeyse hiç doğrudan kod yazmadan, spesifikasyon temelli yinelemeli çalışma ile projeleri tamamlıyorum
    Paralelde birden fazla ajan çalıştırıp sonrasında gözden geçirmek özellikle verimli oluyor
    İşin püf noktası net spesifikasyon yazmak ve adım adım geri bildirim vermek

    • Ruby'yi çok iyi bilmiyorum ama Rails uygulaması geliştirirken büyük fayda görüyorum
      30 yıllık kariyerimde hissettiğim en devrimci değişim bu; tüm sektörün değişeceğine eminim
    • Birisi, "1 haftalık projeye orta ölçekli demek küçük kalır" diye şaka yaptı
    • Bir başkası da bunun gerçek anlamda ajan geliştirmeden çok LLM ile işbirlikli geliştirmeye benzediğini söyledi
    • "Spesifikasyon odaklı geliştirme (spec-driven) üretim kalitesinin anahtarı" diyenler de vardı
    • Ben, gereksinimleri netleştirmek için Claude'un önce soru sormasını sağlayan ek bir aşama da koyuyorum
      Şu anda Claude ile bir Japonca–İngilizce sözlük projesi üzerinde çalışıyorum
      GitHub bağlantısı, web sitesi
  • 20 yıllık bir geliştirici olarak, LLM'ler sayesinde iş süresi tahminlerim tamamen bozuldu
    Eskiden 2 hafta sürecek iş artık 2 günde bitebiliyor
    Kod incelemesi ve etkileşim gerekli, ama bana göre çoğu insan geliştiriciden daha iyi
    LLM ile konuşmak, kıdemli bir geliştiriciyle çalışmak gibi hissettiriyor
    Uzun yıllardır kod inceleme ve iş dağıtımı yapıyor olmam da büyük avantaj sağlıyor

    • Birisi "o kadar hız artışına inanmak zor" diyerek bunun hangi problem türlerinde geçerli olduğunu sordu
    • Bir başkası da kısaca, "kanıt bekliyordum ama yoktu" dedi
  • Denediğim yöntemler içinde en istikrarlı olanı, Claude'a küçük ve net görev birimleri vermek
    Plan yapıp, gözden geçirip, uygulayıp, ardından tekrar review etmek şeklinde ilerliyorum
    Mükemmel değil ama tıkanan yerleri açmakta çok faydalı
    Ancak yönergelere pek sadık kalmadığı için, elle doğrulama ve düzenleme şart

    • Ben de Claude'u rubber duck debugging benzeri şekilde kullanıyorum
      Bir seferde tek bir fonksiyon veriyorum; sonucu görüp daha iyi fikirler çıkarıyorum
    • LLM'ler özellikle dokümantasyon ve analiz işlerinde çok güçlü
      Ama iş tasarım ağırlıklı problemlere gelince sınırları belirginleşiyor
    • "Yönergeleri nereye koyuyorsun" sorusuna, CLAUDE.md içine build ve test bilgilerini eklemenin iyi olduğu tavsiye edildi
  • AI destekli kodlamayı yanlış anlayan çok kişi var
    AI bir takım arkadaşı değil, bir yardımcı
    Bug'ları ya da hatalı davranışları başarısızlık olarak görmekten ziyade, deneyimli geliştiricinin ortaya çıkan karmaşayı toparlaması işin özü

    • Birisi, "bu kadar el emeği gerektiriyorsa IDE otomatik tamamlamadan farkı ne" diye sordu
    • Bir başkası da, güncel yöntemlerin gerçekten kalite artışı sağladığını gösteren örnek olup olmadığını sordu
    • "Sonunda yine 'sen yanlış kullanıyorsun' denmiş oluyor" diye alay edenler de vardı
    • "Beyzbol izlerken sana kusursuz bir uygulama yapmasını beklediysen, aldığın şey AI değil sihirbaz olmalıydı" diye şaka yapan da oldu
  • Ben de her gün Claude kullanıyorum ama AI'ın yazdığı test kodları çoğu zaman berbat oluyor
    Gerçekte expect(true).to.be(true) gibi anlamsız testleri seri üretim halinde çıkarıyor

    • Eski modeller başarısız oluyordu, ama yeni modellerin hile yaparak geçen kod ürettiğine dair bir yazı okuduğumu hatırlıyorum
    • Bu yüzden ben TDD yaklaşımıyla önce testleri yazıp gözden geçiriyorum
      Uygulama ve testi aynı anda verirseniz kendi kendini puanlayan hata ortaya çıkıyor
    • Birisi, "Claude ile test yazdırmaktan vazgeçtim" dedi
    • Bir başkası da buna gülerek "bu fazla insani bir çözüm" yorumunu yaptı