Ajanik yapay zekayı zorlamanın nedeni ne? Modeller basit bir talimatı bile düzgün izleyemezken

• AI kodlama modellerinin tek bir komutu bile güvenilir şekilde yerine getiremediği bir ortamda, arka planda otonom çalışan ajanik kodlamaya yönelik aşırı beklenti oluşuyor
• Yazar, referans kod olarak 100 satırlık bir Golang fonksiyonu vermesine rağmen GPT-5 ve Gemini Pro’nun bazı mantık parçalarını atladığını veya güncellemeleri eksik bıraktığını deneyimledi
• Ajanik sistemlerin 50 dosya ve çok sayıda fonksiyonu otonom biçimde işlemesi mevcut teknoloji seviyesinde gerçekçi görünmüyor; hatta hata ayıklama için daha fazla zaman harcanması riskini taşıyor
• Topluluk yanıtları, sistematik prompting, dokümantasyon ve adım adım doğrulama ile sınırlı ölçüde başarılı kullanımın mümkün olduğunu savunanlarla, ajanik yaklaşımın henüz pratik olmadığını düşünen şüpheci görüşler arasında ikiye bölünüyor
• Mevcut LLM’ler zeka değil, bilgi tabanlı sistemler olduğundan, geliştiricinin bağlamı bizzat sağlayıp adım adım doğruladığı “araç olarak kullanım” yaklaşımı daha gerçekçi görünüyor

---

Orijinal yazarın ortaya koyduğu sorun

• Basit komut başarısızlığı örneği: Referans olarak 100 satırlık bir Golang fonksiyonu verilip başka bir fonksiyonun aynı yapıda güncellenmesi istendiğinde, hem GPT-5 hem de Gemini Pro bazı mantıkları atladı veya güncellemeleri eksik bıraktı
• Ajanik kodlamanın gerçek dışılığı: Tek bir fonksiyonu bile düzgün işleyemeyen bir durumda, 50 dosya boyunca çok sayıda fonksiyonu otonom olarak değiştiren ajanik yaklaşımın daha fazla sorun yaratacağından endişe ediliyor
• 6000 satırlık dosya güncelleme sorusu: Stripe sürüm güncellemesi gibi 6000 satırlık bir dosyanın güvenli biçimde nasıl değiştirilebileceği konusunda topluluğun görüşü isteniyor

Olumlu kullanım örnekleri ve metodoloji

Sistematik dokümantasyon ve indeksleme yaklaşımı

• Markdown referans dosyası kullanımı: Referansları .md dosyasında tutup AI’a bunu okumasını söylemek tutarlılığı ve doğruluğu artırıyor
  • Örnek istem: "Ekli goLang_Update_reference.md dosyasını referans alarak update fonksiyonunun temel noktalarını özetle ve buna dayanarak bir yazılım güncelleme taslağı hazırla"
• Yerel indeks oluşturma: Büyük dosyalarda (6000 satır ve üzeri) 1000 satırlık bölümler halinde tarama yapıp fonksiyon adları ve satır referanslarını içeren bir indeks üretme
  • Frontend çalışırken fr.index.md gibi yalnızca belirli alanları ayıran indekslerden yararlanma

Ajan yönetimi ve işin yapılandırılması

• Ajan uzmanlaştırma: architect, codeseeker, coder gibi rol bazlı ajanlar kurup her biri için uygun .md kural dosyaları sağlama
• Dikey dilim yaklaşımı: 100 bin token’ın altında tamamlanabilecek küçük özellik birimlerine işi bölme
  • 100 bin token aşıldığında ajanın hatalı davranma olasılığı keskin biçimde artıyor
• İşin dokümante edilmesini zorunlu kılma: docs/TASKS.md, docs/WORKLOG.md, docs/DECISIONS.md güncellemelerini zorunlu tutarak iş sürekliliği sağlama

Plan Mode ve Ask Mode kullanımı

• Plan Mode: Tüm projeyi inceleyip isteğe göre bir plan oluşturduktan sonra adım adım ilerleme
• Ask Mode: Kod tabanı sorgulama, fikir keşfi, seçenek değerlendirme gibi işler için kullanma; Google/StackOverflow yerine geçebilecek faydalı bir araç

Önce birim testi yazma yaklaşımı

• Test odaklı geliştirme: Fonksiyon yazmadan önce birim testlerini hazırlayıp, AI’ın bu testleri geçen kodu yinelemeli olarak üretmesini sağlama
  • İşlevsel olarak doğru kod elde etme olasılığı büyük ölçüde artıyor; sonrasında yalnızca optimizasyon ve temizlik gerekiyor

Şüpheci görüşler ve sınırların kabulü

Ajanik yaklaşımın pratik sınırları

• Denetimsiz çalışma intihar gibi: Mevcut teknoloji seviyesinde bir bileti atayıp arka planda otonom çalışmasına izin vermenin başarısızlık olasılığı çok yüksek
• Yalan üretme ihtimali: Modellerin başarıdan çok halüsinasyon üretme olasılığı daha yüksek ve en kötü senaryoda mevcut kodu bozabilirler
• Planning Mode’un fazlalığı: Temel modele ayrıntılı bir plan istemek çoğu zaman yeterli; Planning Mode pratikte yeni bir yetenek sunmuyor

LLM’lerin doğasından gelen kısıtlar

• Akıl yürütme değil tahmin: Modeller sonucu doğrulamadan bir sonraki kelimeyi tahmin ederek çalıştığı için, grounding, memory ve feedback iyileşene kadar güvenilirlik dalgalı kalacak
• Zeka olmadan bilgi tabanı: LLM’ler zekadan yoksun, gelişmiş bilgi tabanlarıdır; geliştiricinin zekayı (BYOI: Bring Your Own Intelligence) ve bağlamı bizzat sağlaması gerekir
• Bellek eksikliği: Modellerin gerçek belleği yoktur; yalnızca context ve context cache’e dayanırlar, bu yüzden her yeni sohbette bağlam sıfırlanır

Dil ve veri önyargısı

• Golang’ın görece dezavantajı: Golang, Python veya JavaScript’e göre daha az açık kod tabanına sahip olduğundan, modelin öğrenmiş olduğu örüntü ve teamüller daha sınırlı
  • Bu da tutarlı düzenleme veya dönüşüm çıktıları almayı zorlaştıran yapısal bir etken

Başarılı kullanım için pratik rehber

Prompting ve bağlam sağlama

• Açık ve ayrıntılı talimatlar: Dilbilgisi ve noktalamayı doğru kullanın; muğlak ifadeler yerine açık talimatlar verin
• İlgili tüm dosyalara açık referans: Ajanın kullanması gereken tüm dosyalar açıkça belirtilmezse spagetti kod üretme olasılığı artar
• Kural dosyaları ayarlama: Tüm çalışma alanı için kurallar ve proje bazlı kural dosyaları tanımlayarak tutarlı kod üretimi sağlama
• @Docs kullanımı: Ajanın ihtiyaç duyduğu temel bilgiyi vermek için doküman referans özelliğinden yararlanma (bazı sürümlerde kararsız çalışabiliyor)

İş kapsamı ve doğrulama

• Küçük parçalara bölme: İşi tek seferde işlenebilecek en küçük birimlere ayırın; her adımı doğruladıktan sonra sonraki adıma geçin
• Gerçek zamanlı gözden geçirme: Üretilen tüm kodu anlık inceleyin ve gerekirse hemen düzeltme isteyin; böylece spagetti kod önlenebilir
• Yedekleme ve sürüm kontrolü: Her adımda yedek oluşturun ve GitHub gibi sürüm kontrol sistemlerini kullanın
• Test çalıştırma: Etkilenen testleri pytest --testmon -q ile artımlı biçimde çalıştırın; bitirmeden önce de tüm testleri çalıştırın

Modülerlik ve kod yapısı

• 6000 satırlık dosyayı bölme: Tek dosyada 6000 satır modüler değildir ve bağlam sağlamayı zorlaştırır; bunu 500 satırlık 12 dosyaya bölmek daha etkilidir
• Dikey dilimleri tercih etme: Uçtan uca çalışabilen küçük özellik birimlerinde geliştirme yapma

Model seçimi ve maliyet yönetimi

• Claude Sonnet 4.5’i öncelikli değerlendirme: GPT veya Gemini’ye göre daha yüksek tutarlılık ve doğruluk sunarak ek maliyetini hak edebilir
• Token tüketimine dikkat: Büyük planlar çok token harcar; gerçek uygulamada küçük adımlara bölmek daha maliyet etkindir

Özel kullanım senaryoları

Tek seferlik script üretimi

• Analiz scriptleri: Günde yüzlerce tek seferlik veri analizi scripti yazılması gerekiyorsa, doğruluk %50 olsa bile elle yazmaya kıyasla 1000 kat daha hızlı üretim ve çalıştırma mümkün olabilir
• Sonucu doğrulayabilme: Sonuç doğrudan doğrulanabildiği için düşük doğruluk oranı bile pratikte işe yarayabilir

Sıfırdan uygulama kurma

• Çok ajanlı yapı: Büyük bir uygulama sıfırdan kurulurken, denetleyici bir ajan diğer ajanların işini inceleyerek tutarlılığı koruyabilir
  • import adları, değişken adları tutarlılığı ve kod tekrarının önlenmesinde etkili olabilir
• Maliyet/verim dengesi: Yine de karmaşık değişiklikler ve refactoring gerektiğinden, adım adım yaklaşım uzun vadede daha ucuz olabilir

Topluluk görüşlerinin özeti

Olumlu deneyimler (3–5 kat verim artışı)

• Next.js web sitesi: Sıfırdan tamamen çalışan ve dağıtıma hazır bir web sitesini dakikalar içinde kurma
• Karmaşık özellik geliştirme: Bir sohbet uygulamasına threads özelliğini 3–4 dakikada ekleme (normalde tahmini 3 günlük iş)
• Sistematik yaklaşımda: Net kurallar, yeterli bağlam ve adım adım doğrulama birlikte kullanıldığında istikrarlı başarı mümkün olabilir

Olumsuz deneyimler (şimdilik pratik değil)

• Spagetti kod üretimi: Geniş kapsamlı hedefler verildiğinde doküman güncellemelerinin atlanması, artık dosyaların silinmemesi gibi sorunlar ortaya çıkıyor
• Anlamsal hatalar: Teknik olarak çalışsa da kodun yanlış yere konması veya mevcut fonksiyonun yeniden yazılması gibi yapısal sorunlar oluşabiliyor
• 5 dakikayı aşan takiplerin başarısızlığı: 5 dakikadan uzun süren izleme oturumları çoğunlukla işe yaramaz sonuçlar üretiyor

[GN⁺]

Hacker News görüşleri

• Kendi deneyimime göre, çoğu LLM yönergelerimi gayet iyi takip ediyor gibi geliyor. Elbette özenle rafine edilmiş prompt'lar ve önceden planlama gerekiyor ama o üç şeye hakim olunca bu tür kodlama ajanlarıyla fazlasıyla uçabiliyorsunuz. Bazen 10 denemede 1 kez hata yapıyor ama böyle durumlarda da hızlıca durdurup yeniden yönlendirerek hemen doğru yola dönüyor. Burada HN'de pek çok insanın bunun etkisine şüpheyle yaklaşması şaşırtıcı. Elbette maliyet, iş gücü değişimi gibi kaygılar var ama kodlama ajanlarının faydasından bu kadar sık şüphe edilmesini beklemiyordum
  • Ajan sistemlerinin ya da LLM'lerin Google aramasının veya Stack Overflow'un ötesinde değer ürettiğini gösteren video ya da gerçek örnekler görmek isterdim
  • Mevcut durumu, istenen sonucu ve nasıl ilerleneceğini yeterince açıklarsanız, ajanla birlikte plan yapıp onu rafine ederek uygulayabilirsiniz. Böyle yapınca güncel teknoloji seviyesi oldukça etkileyici. Tek bir cümleyle karmaşık bir şey beklemek gerçekçi değil. Bu, sektörde deneyimi olmayan zeki bir stajyere teknik iş vermek gibi; gerçekten zaman ve emek istiyor. Ama AI ajanı insan stajyere göre çok daha hızlı çalışıyor
  • “Çoğunlukla iyi çalışıyor” demek, fiilen güvenilirlik metriği (kaç tane 9 olduğu) olmadığı anlamına geliyor
  • Az önce köpeği gezdirirken Codex (gpt-5-high) ile bir Python uygulamasını tek seferde Go'ya dönüştürdüm. Ortaya çıkan şeyi test ettim, gayet çalışıyordu. Sanal ortam olmadan tek bir binary olarak dağıtılabilmesi hoşuma gitti. Komutun aşırı kolay olup olmadığından ise emin değilim
  • “Çoğunlukla iyi çalışıyor” standardı bana yeterli gelmiyor. Daha ciddi sorun ise, talimatlara uymamasından çok, yanlış olduğunu kabul etmeyip üstelemeye devam etmesi. Orta karmaşıklıkta bir şey istediğimde ya da hata analizi talep ettiğimde, epey sık şekilde yanlış sonuca saplanıp kalıyor. Sorunu ben doğrudan işaret edene kadar da çoğu zaman çıkış yolu bulamıyor. Basit kod ya da boilerplate işlerinde gerçekten iyi ve biraz geri bildirimle yeni kütüphaneler bile oluşturabildi. Ama sık sık yanlış yaptığı için daha karmaşık işleri ona bırakmak istemiyorum. Yine de tıkandığımda fikir üretmek için kullanıyorum; yanlış olsa bile motive edici oluyor
• Geliştiricilerin LLM'lerle ilgili deneyimlerinin bu kadar farklı olması karşısında aslında sormamız gereken soru “neden bu kadar farklı deneyimler yaşıyoruz?” olmalı. “Doğru kullanmıyorsun” türü açıklama en basiti ama AI sistemleri geliştiren biri olarak, gerçekten de hiçbir karmaşık talimat vermeden sadece “düzelt”, “rapor hazırla” yazıp sonuç bekleyen çok kullanıcı olmasına hâlâ şaşırıyorum. Bir de “AI ile her şey yapılabilir” tarzı abartılı yönetici hype'ı var; bu da şirket değeri ve hisse fiyatıyla bağlantılı. Genel kamuoyu da AI'ı sanki “gerçek yapay zeka” gibi görüyor. Aslında LLM'lerin basit yönergeleri bile takip edemediği iddiası pek inandırıcı değil; asıl mesele, karmaşık işleri hâlâ gerektiği gibi yapamıyor olmaları
  • Bir başka teorim de şu: herkesin kafasında bir spec var ama bunu dağınık biçimde yazıp LLM'nin uygulamasını bekleyince, ortaya çıkan sonuç doğal olarak o spec'ten sapıyor. Bazı geliştiriciler bunu sonradan zihninde değiştiriyor ya da küçük farkları olduğu gibi kabul ediyor, bazıları ise LLM'nin kafasındaki planı tutturamamasına hayal kırıklığıyla yaklaşıyor. Biraz psikolojik “sahte anı” gibi; kimi daha esnek ve uzlaşmacı, kimi daha katı. Ben de bu iki durumu sırayla yaşıyorum
  • Artık gerçekten trivial olmayan bir özelliğin baştan sona nasıl yapıldığını gösteren daha fazla screencast, uzun yazı, her neyse görmek istiyorum. AI influencer'ları neredeyse hep AI ile AI aracı yapıyor ya da CRUD, hello world demoları gösteriyor. Kıdemli geliştiriciler bile kod tabanının yarısından fazlasını AI'ın yazdığını söylüyor ama gerçekte neredeyse hepsini atıp sadece bir kısmını referans aldıklarını da ekliyorlar. “Tek prompt → tamamlanmış uygulama” hikâyesi çok çabuk “boş sayfaya bakarken motivasyon sağlamakta faydalı” noktasına geliyor. Gerçek profesyonel geliştiricilerin bunu sahada nasıl kullandığını daha şeffaf biçimde paylaşmaları iyi olurdu
  • Aslında “geliştirici” diye bir kategori o kadar geniş ki bu tartışmada çok anlamlı değil. Çoğunluğun yaptığı benzer CRUD tarzı kod parçalarını birleştirme işinde LLM'ler epey iyi çalışıyor
  • Herkes farklı kod tabanlarında bambaşka işler yapıyor. Bu önemli ayrıntı neredeyse hiç konuşulmuyor. Ne kadar sık kullanırsanız beklenti çıtanız o kadar yükseliyor ve sınırları daha çabuk hissediyorsunuz. Ara sıra kullanınca etkileyici ama bütün gün kullanınca hayal kırıklığı birikiyor. “Bunu artık yapabiliyor olması gerekir” dediğiniz şeylerde bile tekrar elden geçirmek gerekebiliyor
  • Sonuçların farklı olduğuna değil, beklentilerin farklı olduğuna eminim. Şirketimizdeki IT SVP tam bir AI evangelisti. Yakın zamanda onun yıllar önce yaptığı eski bir PHP projesi üzerinde çalışırken, kabul ettiği kod kalitesi seviyesinin ne kadar düşük olduğunu fark ettim. Ben de her gün LLM kullanıyorum ama çıkan sonucu hep düzenliyorum. Yani kod kalitesi beklentiniz ne kadar düşükse, LLM çıktısından o kadar memnun kalıyorsunuz
• Cursor forumlarında sürekli “yanlış kullandın” deniyor ama benim gerçekten merak ettiğim güven, süreç ve gerçek üretim ortamı uygulaması. Burada da sonuçta büyük ölçekte kullanım örneğini pek görmüyoruz gibi geliyor. Biz de AI'ı çoğunlukla “aptal bir ekip arkadaşı” gibi kullanıyor, daha az kısıtlı yan projelerde daha deneysel davranıyoruz. Ajanlar ise neredeyse tamamen hype gibi geliyor (ya da ancak çok niş durumlarda işe yarıyor)
  • OP'nin kötü sonuç almasının nedeni Cursor kullanıyor olması. Cursor, maliyeti kısmak için konuşma bağlamını acımasızca kesiyor. Model sağlayıcılarının aksine LLM kullanımını perakende fiyatla ödemek zorunda olduğu için fiyat rekabetinde dezavantajlı. Cursor bağlamı ne kadar kestiğini şeffaf biçimde açıklamıyor ve benim deneyimime göre gerçekten agresif biçimde buduyor; ne olup bittiğini anlaması için aynı dosyaları tekrar tekrar yükletmek gerekiyor. Benim tavsiyem Cursor'a daha fazla zaman yatırmayı bırakmak. Cursor'ın ürettiği kod borç biriktiriyor. Codex ve Claude'a geçtim, çok daha memnunum
  • Özellikle ne tür iyileştirmeler beklediğinizi merak ediyorum. Orijinal gönderide somut örnek, prompt veya metodoloji yok; sadece “ben prompt yazmayı biliyorum” havası var. Bu durumda ne değerlendirme yapmak ne de tavsiye vermek kolay. En baştan ajan tabanlı workflow'lara şüpheyle bakılmasını da anlıyorum ama insanlara sağlam bir karşı argüman üretme fırsatı da vermemiş oluyor. Ben de aylardır ajanlarla çalışıyorum ve hâlâ neyin iyi gittiğini, neyin başarısız olduğunu öğreniyorum. Benim deneyimimde:
    • agent-os gibi bir framework ile orkestrasyon şart
    • yönlendirme ile özerklik arasında denge kurmak önemli
    • özellikle legacy kodda önceden planlama gerçekten önemli
    • benim örneğim: legacy bir sistemde context window sürekli aşılıyor ve bağlamı özetleyince gerekli bilgiler eksik kalıyor, böylece aynı hataları tekrar ediyor
    • işe yarayan yöntem: problemi net biçimde yapılandırmak, keşfedilen/öğrenilen her şeyi tek tek kayda geçirmek ve çok spesifik alt ajanlara bölmek (böylece context window yönetilebiliyor). Ancak o zaman ajanlar legacy kodu keşfetmede gerçekten işe yarar hale geliyor
  • Ajanların, benim bulamadığım birkaç production bug'ını yakaladığı oldu (yeterince zaman ayıramadığım yabancı bug'lardı). Elbette bulamadıkları çok daha fazla bug var ama bir yazılım mühendisinin bir saatlik aramasına kıyasla neredeyse bedava sayılır; arada bir işe yarıyorsa bile bu yeterince kullanılabilir bir strateji
  • Gerçek ve somut örnekler içeren bir yazı çok daha anlamlı olur, ayrıca daha iyi yanıtlar doğurur. Somut iş problemlerini ve LLM'nin nerede başarısız olduğunu gösteren bilgiler daha faydalı
  • Gerçek iş değeri, insanların düşündüğünden çok daha düşük ve bu sinir bozucu. Elbette boilerplate ya da iyi bildiği alanlarda insandan daha iyi yazdığı durumlar var. Ama bunun dışındaki sorunlar (big tech bağımlılığı, veri kirlenmesi, doğrulanamayan bilgi, yaratıcılığın zayıflaması, özgünlüğün çöküşü, AI fanatiklerinin cehaleti, enerji tüketimi, insan üretimlerinin yağmalanması vb.) çok büyük. Bütün bunların insanlık için net pozitif olduğuna inanılması bana şaşırtıcı geliyor
• 2025'te pazarlama gerçekten çok iyi yapılıyor; Reddit, LinkedIn gibi bütün forumlarda markalar konuşmaların içine sızıyor. CEO'lar, AI “düşünürleri”, VC'ler LLM'leri sihir gibi pazarlıyor ve v0, Lovable gibi şeyleri bir sonraki büyük devrim diye paketliyor. Liderlerin cevapları da birbirinin aynısı (ilgili video). Ama gerçekte CLAUDE.md ya da cursorrules gibi şeyleri ne kadar hazırlarsanız hazırlayın, neredeyse hiç etkisi olmuyor. Sonuçta LLM'nin talimatları izlemesi gerekiyor ama pratikte rastgele davranıyor gibi. En basit kurallara bile çoğu zaman uymuyor; bu yüzden Cursor forumlarına yazanların çoğunun amatör olduğunu düşünüyorum. Ayrıca yeni kod yazma işlerinde LLM'ler gerçekten çok kötü. Var olmayan kütüphaneleri varsayıp işe yaramaz harf yığınları üretiyorlar. Ben onları kelimenin tam anlamıyla speech-to-text gibi kullanıyorum ama LLM'ler benim kaçırdığım edge case'leri, bilmediğim best practice'leri ve sözdizimini daha iyi yakalıyor
  • [1] Arama, Perplexity vb. yerlerden çıkan sonuçların çoğu pazarlama ekiplerinin her yere yaydığı pazarlama çöplüğü
  • Yeni kod yazma işlerinde LLM'lerin gerçekten korkunç olduğuna tamamen katılıyorum. Güncel SOTA modeller, çok bilinen ve tutarlı desenleri olan framework'lerde (MVC vb.) boilerplate ya da basit yapı kurmada fena değiller. Asıl parladıkları alan, büyük miktarda bilgiyi tarayıp bir şeyi bulmak; örneğin kod tabanında, log'larda ya da stack trace'lerde. Ama “ajan tüm kod tabanını üretir” pazarlamasının şu an için gerçek olmadığını düşünüyorum
  • Benim deneyimim bunun tam tersi. Son bir haftadır Claude Code, sorumlu olduğum bir derleyici sorununu neredeyse kendi başına düzeltti. Arada can sıkıcı anlar olsa da, ince kod üretimi ve parser bug'larını istikrarlı biçimde iyi düzeltti; benim müdahale ettiğim noktalar daha çok compaction yönetimi gibi araç sınırlamalarıyla ilgiliydi. Kitap bakmadan bilinmeyecek yöntemleri bile uyguladı ve gerçekten çalıştığını da doğruladım. Tamamen yeni ve gerçekten “yenilikçi” şeyler daha azdır ama zaten kodun neredeyse hiçbiri bütünüyle yeni değil. Benim deneyimimde, iyi yapılandırılmış bir rehbere göre hareket ettirirseniz çoğunlukla çok iyi uyuyor. Sadece CLAUDE.md içine gelişigüzel notlar yazmak yetmiyor. Esas olan sürece dair titiz yönlendirme. Benim çalışma biçimim şuna ayrılıyor: 1) proje bazlı debugging rehberi, 2) net kabul kriterleri, 3) testleri sık çalıştırmak ve küçük değişiklikleri birim bazında dosyaya kaydettirmek. Bunu yaptığımda Claude'u saatlerce neredeyse gözetimsiz otomatik çalıştırabiliyorum (arada sadece “devam” komutu vermek ya da /compact kullanmak gerekiyor). Her seferinde kusursuz kod vermiyor ama ben de vermiyorum. Yine de çoğunlukla olumlu değişime yol açıyor ve harcadığım emek ciddi biçimde azalıyor. Tam tasarlanmamış bir durumda bootstrap için hâlâ önermem ama bazen onu da başarıyor (yine de ön inceleme gerekli). Hatta bu aralar Claude'un günler boyunca kesintisiz çalışıp sorunları otomatik çözmesini düşünüyorum
  • Herkesin LLM deneyiminin bu kadar farklı olabilmesi gerçekten ilginç. Benim durumumda codex-cli ile verimliliğin 5 kat arttığını hissettim. Çok sıra dışı yapıya sahip kaynaklardan ve dahili SVG execution trace'lerinden özel bir JSON graph formatına dönüşüm yapmakta ya da karma Python/C++ kod tabanlarından (düşük seviyeli RISCV kernel'e kadar) doğru dokümantasyon çıkarmakta çok rahattı. Aynı araçla bile bu kadar farklı sonuçların ortaya çıkmasının nedenini gerçekten merak ediyorum
  • Claude ile kod yazmak bana slot makinesi oynatıyormuş gibi geliyor. Bazen tam istediğiniz şeyi veriyor ama çok daha sık olarak ya vermiyor ya da tamamen ıskalıyor. Kesinlikle tek başına, denetimsiz bırakmak tehlikeli
  • Bana göre de LLM'lerin en tutarlı değeri, insanların sık kaçırdığı küçük hataları, en iyi örnekleri ve kod sözdizimini iyi yakalamaları. Bu yüzden PR reviewer olarak, biraz ihtiyat payıyla, gayet işe yarıyorlar
• Bizim şirket klasik XP yaklaşımını uyguluyor. Brownfield bir uygulamaya yeni özellik geliştirirken işi “red-test-writer”, “minimal-green-implementer”, “refactorer” gibi yaklaşık 8 alt ajana bölüyoruz. Artık Claude Code'a sadece “bu TDD süreciyle X özelliğini yap” yazıyorum; 30 dakika içinde çok daha iyi kod, %90 test coverage ve hemen kabul edilebilir durumda bir çıktı alıyorum. Bunun arkasında yıllara dayanan XP, pair programming ve TDD deneyimi var ama bir yıldan uzun süredir production kodumuzun %95'ini AI yazıyor (trivial olmayan karmaşık özellikler dahil). Neredeyse hiçbir gizli püf nokta olmadan da gayet çalışıyor. Bizim için etkisi gerçekten çok büyük
• Burada görüş ayrılığı çok fazla. Herkes neyin başarısız olduğunu, bunu hangi işlerde kullandığını söylemeden düzgün bir tartışma mümkün değil. LLM'nin başarısız/başarılı olduğu somut kategoriler konuşulmadıkça bunların hepsi gürültüden ibaret
  • Tartışmalarda dil/framework, problem alanı, SRE seviyesi, LLM (model/sürüm), agentic harness (claude code, codex, copilot vb.), başarısız/başarılı örnekler ve LLM kullanım becerisi gibi ayrıntılar belirtilmeli. Ayrıca mühendisin tek bir kod tabanında 10 yıl geçirip geçirmediği, birden çok proje arasında gidip gelmediği, yeni geliştirme (Greenfield) mi bakım mı yaptığı, inovasyon araştırması mı yoksa CRUD mu yaptığı gibi koşullar da değişebilir
• Bir bilim insanı olarak her veri seti için biraz farklı boilerplate'i tekrar tekrar yazmak zorunda kaldığım çok oluyor; kodlama ajanları bunu büyük ölçüde çözüyor. Özellikle “kesinlikle veri uydurma, np.random kullanma” diye beş kez büyük harflerle vurgulasam bile Claude'un bazen bunu görmezden gelmesi gerçekten absürt. Böyle durumlar şaşırtıcı derecede saçma. İyi çalıştığında harika ama çalışmadığında başarısızlık sinyali bile vermiyor. LLM pazarlaması açısından düşününce, kodlama ajanının arkasında onu gerçek zamanlı denetleyen bir “PIPA (Performance Improvement Plan Agent)” gibi başka bir ajanın dolaştığını hayal edebiliyorum. PIPA, kodlama ajanının performansını izler, böylece HR ya da yöneticiler AI çalışanı (ajanı) yönetir; gelecek belki de böyle gelir
  • “Pembe tütü giymiş bir fili düşünme!” denince aklına gelmedi mi? Bilim insanıysan LLM'lerin yapısı gereği olumsuz cümleleri iyi anlamadığını da bilmelisin. LLM'ler token düzeyinde öğreniyor; bu yüzden “NO ELEPHANTS” desen bile “elephant” kelimesi bağlamda kalıyor. Böylece istemeden o kelimeyi tetikliyorsun. Pozitif talimatlar vermek daha avantajlı
  • Sadece PIPA fikrini hayal etmek bile korkutucu
• Doğru prompt'lar (iyi hata mesajları vb.) modelin uygun bağlamı kendisinin bulmasını sağlamada kritik ve işi çok küçük, tutarlı parçalara bölerseniz yinelemeli/aşamalı test sonuçlarını bir sonraki işin bağlamına taşıyabiliyorsunuz. Sorunların %50'si bu yönteme uyuyor, %50'sinde ise LLM döngüsü geleneksel otomasyondan daha az zahmetli olsa da bunların yarısı yatırım getirisi açısından peşinden koşmaya değmiyor. Sonuçta büyülü “%12,5”lik bir kullanım alanı varsa, en iyi yaklaşım sıkı biçimde sınırlandırılmış (constrained) ajan yöntemidir
  • Bütün bu süreci YouTube vb. yerlerde canlı yayınla (öğretici değil, doğal live coding olarak) göstermek iyi içgörüler paylaşılmasını sağlar
• Neredeyse 30 yıl önce AI'a ilk girdiğimde bana şunu söylemişlerdi: “intelligent agent” dendiğinde bunu “eğitilebilir bir karınca” gibi düşün
  • Daha fazla ayrıntı merak ettim
• Benim için en büyük sorun, AI araçlarının performansının işe göre çok değişmesi ve nerede başarısız olacağını öngörmenin zor olması yüzünden zaman kaybettirmesi. Araç deneyimi arttıkça prompt yazma becerim gelişir sanıyordum ama yine de sinir bozucu. Yine de ajanların ve AI'ın yararlı olduğu bir kesişim kümesi var (ör. yeni proje boilerplate'ini otomatik üretmek gibi). Böyle durumlarda “agent mode” daha rahat oluyor. Şimdilik gerçek saha deneyimim hâlâ sınırlı
  • Ne kadar iyi çalışırsa beklenti de o kadar yükseliyor ve kullanım alanı genişliyor; sonra sınırlarına çarpınca ilk zamankinden bile daha büyük bir hayal kırıklığı oluşuyor