- Son dönemde AI coding agent’ların yaygınlaşmasıyla geliştirme hızı artsa da yazılım kalitesindeki düşüş ve istikrarsızlık derinleşiyor
- Agent’lar tekrarlı öğrenme yeteneği olmadan aynı hataları biriktiriyor ve büyük kod tabanlarında arama recall’ının düşmesi ve karmaşıklığın patlaması yaşanıyor
- Sistemin tamamı insan denetimi olmadan onlara bırakıldığında tekrarlanan kod, hatalı tasarım kalıpları ve sürdürülemez kod tabanları ortaya çıkıyor
- Şimdilik agent’ları çekirdek dışı işler veya deneysel alanlarla sınırlı kullanmak ve insanı nihai kalite kapısı olarak tutmak gerekiyor
- Yavaşlamak ve insanın özneselliğini geri kazanmak, öğrenme, gelişim ve sürdürülebilir bir yazılım ekosistemi için kritik önemde
Her şeyin bozulmuş olduğu durum
- Son 1 yılda coding agent’lar gerçek projeleri tamamlayabilecek seviyeye ilerledi, ancak bunun sonucu olarak yazılım kalitesindeki düşüş belirgin hale geldi
- Büyük hizmetlerde bile %98 çalışma süresi sıradanlaşırken UI bug’ları sık görülüyor
- AWS’nin AI ile ilgili kesinti örnekleri ya da Microsoft’un AI tarafından yazılan kod oranının arttığına dair açıklamaları anılıyor
- Bazı şirketler ürün kodunun %100’ünün AI tarafından yazıldığını iddia etse de ortaya çıkan sonuçlar memory leak, UI hataları, işlev istikrarsızlığı gibi sorunlar yüzünden düşük kaliteli oluyor
- Birçok geliştirici, agent merkezli geliştirme nedeniyle kod incelemesinin yokluğu, tasarım eksikliği ve gereksiz özellik şişmesi yüzünden sürdürülemez kod tabanlarına sürüklendiklerini bildiriyor
Agent’larla birlikte çalışılmaması gereken biçim
- Geliştiriciler hıza ve kod miktarına bağımlı hale gelip kaliteden ve kontrolü elinde tutmaktan vazgeçmiş durumda
- “Dağıtık·özerk·otomasyon” söylemiyle büyük ölçekli agent orkestrasyonu deneniyor, ama pratikte istikrarsız çıktılar üretiliyor
- Bazı projeler çalıştırılması bile zor halde ve insan müdahalesi olmadan sürdürülemiyor
- Kişisel proje düzeyinde mümkün olabilir, ancak gerçek kullanıcı tabanına sahip ürünlerde örneklerin çoğu başarısızlıkla sonuçlanıyor
-
Hata birikimi ve öğrenme eksikliği, darboğazsızlık, geciken acı
- Agent’ların tekrarlı öğrenme yeteneği olmadığı için aynı hataları tekrar tekrar üretiyorlar
- İnsanlar hatalardan öğrenir, ama agent’lar aynı yanlışı sonsuza dek tekrarlayabilir
- İnsanların kod yazma hızı sınırlı olduğu için hata birikimi yavaştır; ancak agent ordularında darboğaz olmadığı için hatalar patlayarak birikir
- Sonuç olarak kod tabanı güvenilmez hale gelir ve otomatik testlere bile güvenilemez
- En sonunda manuel test tek doğrulama aracı haline gelir ve geliştirme ekibi kendini tuzağa düşürür
-
Karmaşıklığı öğrenmiş tüccarlar
- Agent’lar sistemin genel bağlamını görmeden yalnızca yerel kararlar verir
- Bunun sonucunda tekrarlanan kod, gereksiz soyutlamalar ve yapısal karmaşa hızla birikir
- İnsan organizasyonlarında bu tür karmaşıklık yıllar içinde yavaşça birikirken, agent tabanlı ekipler birkaç haftada aynı düzeyde kaosa ulaşır
- Agent’lar eğitim verisinden öğrendikleri hatalı tasarım kalıplarını olduğu gibi yeniden üretir ve insan kontrolü olmadan geri döndürülemez bir karmaşıklık yaratır
-
Agent aramasının düşük recall oranı
- Agent’lar kod düzeltmeye ya da refactoring yapmaya çalışırken gereken kodun tamamını bulamaz
- Kod tabanı büyüdükçe arama recall’ı hızla düşer ve tekrarlar ile tutarsızlıklar oluşur
- Bash, LSP, vektör DB gibi çeşitli araçlar kullanılsa da büyük kod tabanlarında sınırlamalar vardır
- Bu da code smell’leri ve gereksiz karmaşıklığı daha da ağırlaştırır
Agent’larla nasıl çalışılmalı (şimdilik)
- Agent’lar hızlı kod üretimi ve yüksek ilk kalite ile çekici görünür, ancak tüm sistemi onlara bırakınca çöküş gelir
- Uygun kullanım senaryoları küçük kapsamlı çekirdek dışı işler, kendi kendini değerlendirme döngüsü kurulabilen işler ve başarısız olsa da kritik olmayan işlerdir
- Örneğin iç araç geliştirme, fikir denemeleri, performans ölçümüne dayalı otomasyon araştırmaları (auto-research) uygundur
- İnsan mutlaka nihai kalite kapısı olarak kalmalı ve agent’ın çıktısını incelemeli, düzeltmeli ve entegre etmelidir
- Değerlendirme fonksiyonu dar metriklere odaklanırsa agent kod kalitesini, karmaşıklığı ve doğruluğu göz ardı edebilir
- Kilit nokta yavaşlamaktır
- Ne yaptığını ve neden yaptığını düşünmek için zaman ayırmalı, gereksiz özellikleri ise kararlılıkla reddetmelisin
- Agent’ın bir günde üretebileceği kod miktarı incelenebilir bir seviyede sınırlandırılmalı
- Mimari, API gibi sistemin özsel biçimleri mutlaka insanlar tarafından doğrudan yazılmalı
- Agent ile pair programming yaparak kod yazım sürecinde sürtünme ve anlama fırsatı korunmalı
- Bu yaklaşım bakımı mümkün bir kod tabanı oluşturur, kullanıcı memnuniyetini artırır ve gereksiz özellikler yerine çekirdek işlevlere odaklanmayı sağlar
- İnsan anlayışı korunursa agent aramasındaki recall sorunu da hafifler ve sorun çıktığında doğrudan müdahale edilebilir
- İlk tasarım yanlış olsa bile nedenini anlayıp iyileştirebilme yeteneği korunur
- Sonuçta gereken şey disiplin ve insanın özne olarak kalmasıdır
- Sistemin kalitesi ve sürdürülebilirliği insan müdahalesi ve yargısına bağlıdır
- “Yavaş gitmek” aslında öğrenmeyi ve gelişimi, ayrıca sağlıklı bir yazılım ekosistemini korumanın tek yoludur
2 yorum
Pi – sade bir terminal kodlama harness'ı
Bunu yapan kişiymiş
Hacker News görüşleri
Son zamanlarda böyle düşünsel yazılar okudukça, benim de bir noktada tükenmiş hissettiğimi fark ediyorum
Sonuçta asıl önemli olan, “ne inşa ediyoruz” ve “bu araç gerçekten işe yarıyor mu” soruları
Ruby, PHP, Lotus Notes, Visual BASIC dönemlerinde de aynı hataları tekrar ettik
Araçları akıllıca kullanmalı ve ekibin gerçekten inşa ettiği karmaşık gerçekliği anlayabilecek bir hızda çalışmalıyız
Agile mı Waterfall mu, Docker mı Podman mı gibi şeyler öz değil
Bugün LLM'lerin production DB'yi silip sonra bunun için postmortem blog yazısına çizim bile eklediği bir çağdayız, ama bunun gerçekten mühendislik olup olmadığından emin değilim
Belki de yazılım geliştirme en başından beri mühendislik disiplini değildi
Son 10 yılda yazılım sektörü meta işler ile doluydu — yeni framework'ler, araçlar, sanallaştırma katmanları, organizasyon yapıları vb.
Ama asıl bunları “ne için” yaptığımız çoğu zaman belirsiz
Sanki piramit benzeri bir yapı gibi, sektörü ayakta tutmak için yeni işler üretiliyormuş hissi veriyor
Yine de gerçek mühendislik var — soruları bilimsel biçimde kurup, o yanıtlarla karar verdiğimizde
Tersine, içgüdüyle çalışıp sadece CEO'nun dediklerini yapmak mühendislik değil
Eskiden sürüm kontrolü bile olmayan çok ekip vardı, olanlarınki de berbat durumdaydı
Joel Spolsky'nin Joel Test yazısına bakınca, o dönemde şirketlerin çoğu her maddeye “hayır” diyordu
Köprülerde yük, malzeme, ömür gibi şeyler hassas biçimde hesaplanır ama bir web sitesinde trafiği bile öngörmek zor
Sunucu ya da framework'lerin sınırlarını nicel olarak ele alan standartlar yok
Belki bir gün yazılım da gerçek mühendislik olur ama daha gidecek çok yol var
“Mühendis” kelimesi muhtemelen sadece daha çok para kazanmak için eklendi
Gerçek mühendisler ispat ve doğrulamaya önem verir, bizse yeni kalıpları ve denemeleri seviyoruz
Bu yüzden “mühendis” sözcüğü bana hatta biraz rahatsız edici geliyor
Bunu, “programlamayı bilmeyen insanların programlama yapma metodolojisi” diye eleştiriyordu; bugün de hâlâ doğru gibi geliyor
Son dönemde AI tabanlı geliştirme süreçleri büyük şirketler etrafında kemikleşirken vendor lock-in de ağırlaşıyor
Kod tabanı ajan merkezli hale gelirse, sonunda kodu anlayan tek şey o ajan olabilir
O noktada fiyatlar yükselecek ve insan geliştiricilerin geri dönmesi zorlaşacak; bu da tek yönlü bir geçişe dönüşebilir
İyimserler “teknoloji her zaman ucuzlar ve iyileşir” diyor ama bunun petrol piyasasına benzemesi de mümkün
Eskiden DVD'den streaming'e geçişte olduğu gibi, aynı filmi iki kez satın alıyormuşuz gibi
Claude Opus 4.6 gibi modeller artık dakikası 1 dolar seviyesinde pahalı hale geldi ve prompt engineering ile bunu düzeltmek de artık mümkün değil
Sonuçta AI servisleri de ucuz–orta–premium katmanlı bir yapıya ayrılıyor
Prompt engineering artık neredeyse ustaca jailbreaking gibi görülüyor
Bilgi emeği kapasitesini AI şirketlerine “kiralamak” tehlikeli
“Maliyetler artık daha fazla artmaz” sözü bu tartışmanın sonudur — çünkü onlar zarları çoktan atmış durumda
Büyük AI şirketleri de aynı yoldan gidecek
Sonunda token bağımlısı bir pazara sıkışıp kalabiliriz
Açık kaynağın görünmez eli sonunda her şeyi ücretsiz hale getirecek
Donanım ve yazılım geliştikçe hesaplama birim maliyeti düzenli olarak düşüyor
Blockchain patlamasında olduğu gibi gerçek kullanım üretmeyen teknolojiler kaybolur ama AI'nın gerçek kullanıcıları var
Uber gibi başlangıçta eleştirilen hizmetler bile sonunda sürdürülebilir iş modelleri haline geldi
Petrolün aksine, hesaplama her yıl daha ucuz ve daha hızlı oluyor
Bu yazının yazarı, Pi adlı açık kaynak bir coding agent framework'ünün yaratıcısı
OpenClaw'da da kullanılıyor
Onun Pi hakkındaki blog yazısına da bakmaya değer
LLM'ler ve ajanlarla ilgili en derin deneyime sahip kişilerden biri o
“AI kodun %100'ünü yazıyor” diyen şirketler çoğu zaman berbat ürünler çıkarıyor
Eski DOS ya da MacOS dönemlerinde böyle kodlar tüm sistemi çökerttiği için kalite çok daha önemliydi
Bugün OS'ler daha toleranslı olduğu için özensiz kod ayakta kalabiliyor
OTA güncellemeleri sayesinde bitmemiş ürünleri kolayca piyasaya sürüp rakiplerden önce çıkarmaya çalışıyorlar
Sadece bizim hatırladığımız şey iyi yapılmış az sayıdaki ürün
Şimdi ağ bağlantısı olduğu sürece OS bile oyun günceller gibi kolayca güncelleniyor
Coding agent'lar 'baştan çıkarıcı sirenler' gibi
İlk başta hızlı ve akıllı görünürler ama “bilgisayar, işimi benim yerime yap” diye düşündüğün anda çöküş başlar
Ama bu geçici bir durum — AI, ölçülebilir alanlarda insanı zaten geride bırakıyor
Asıl mesele HCI (insan-bilgisayar etkileşimi)
İnsan değerleriyle uyumlu arayüzler tasarlamak, önümüzdeki dönemin esas görevi olacak
Şu an AI hype döngüsünün zirvesindeyiz
Bir zamanlar MongoDB ya da NoSQL'in “SQL öldü” diye bağırdığı dönemde olduğu gibi, insanlar sonunda yeniden gerçekçi bir denge noktasına dönecek
NoSQL ortadan kaybolmadı ama artık sadece gerektiği yerlerde kullanılıyor
“Bugünün yazılımları kırılgan bir karmaşa” sözüne katılıyorum ama aslında yazılımın kendisi değişmedi
Eskiden güven olmadığı için insanlar her şeyi bizzat kontrol ederdi ve sorunları azaltan şey de bu yavaşlıktı
DevOps'un özü, güvene dayanarak hızlı hareket ederken kaliteyi korumak
Toyota'nın Andon cord yaklaşımında olduğu gibi, bir sorun fark edilirse hemen durup kök nedeni çözmek gerekir
Bu teknik bir mesele değil, kültür ve süreç meselesi
Yanlış arayüzler ya da iş bağlamı uyumsuzlukları erkenden bulunmalı
Herkes GitHub, AWS, Cloudflare kullandığı için tek bir yer durduğunda dünya çapında etkileniyoruz
Tape-out öncesinde bir bug bulunursa, haberi getireni suçlamadan dikkatle karar veriliyor
Programlamanın çıktısı sadece kod değil, programcının kendisidir
Kod yazarken biriken zihinsel model ve kas hafızası asıl varlıktır
AI bu sürecin yerini alırsa, sonunda programcının gelişimi ortadan kalkar
Jonathan Blow'un "Preventing the Collapse of Civilization" konuşması da aynı sorunu ele alıyor
"Programming as Theory Building" metnine bakılabilir
Dün bir iş arkadaşımla benzer bir konuşma yaptım
AI'nın log'ları okuyup bug düzelttiği ve hatta postmortem yazdığı bir demo izledik,
ama sorun şu ki insanın bu süreci içselleştirecek zamanı kalmıyor
“Arabada fren olduğu için hızlı gidebiliriz” sözünde olduğu gibi,
insanın anlayabileceği bir hızda öğrenme sürtünmesini korumak gerekiyor
Eğer ajan bunu kendi başına fark edip toparlayabilirse, insanın öğrenmesine gerçekten ihtiyaç var mı?
Elbette kök neden gözden kaçabilir ama otonom iyileşen sistem yeterince sağlam ise bu gerçekten sorun mu?
Ürün tasarımı açısından da benzer bir sorun hissediyorum
Geliştirme hızı o kadar arttı ki bizzat kullanarak doğrulama yapacak zaman kalmıyor
Hatalı bir tasarımın üzerine özellik eklemeye devam ettikçe geri dönmek zorlaşıyor
Sonuçta önemli olan hız değil, kalite ile öğrenme arasındaki denge
Bu tür bir süreç mutlaka zaman gerektirir