“Loop Engineering: Kendi Kendini İyileştiren Yapay Zekâ Döngüleri” yazımda loop engineering kavramını, yani LLM tabanlı sistemleri tek seferlik cevap üreten araçlar olmaktan çıkarıp kontrollü, doğrulanabilir ve gerektiğinde kendini düzelten süreç bileşenleri haline getirme fikrini ele almıştım.
Orada temel soru şuydu:
Bir LLM’i hedefe doğru adım adım ilerleyen, hata yaptığında geri dönebilen, sonucu test edebilen ve gerektiğinde kendini iyileştirebilen bir yapıya nasıl dönüştürürüz?
Yapay zekâ, yazılım geliştirme süreçlerini kökten değiştirdi. Artık dakikalar içinde kod üretebiliyor, test senaryoları hazırlayabiliyor, SQL yazabiliyor, dokümantasyon oluşturabiliyor ve mimari alternatifleri tartışabiliyoruz.
Bu değişimin en görünür sonucu üretkenlik artışı oldu. Ancak, bence gözden kaçan başka bir değişim daha yaşanıyor. Yapay zeka yalnızca üretkenliğimizi artırmıyor, yazılım geliştirirken nasıl davrandığımızı da değiştiriyor.
Yapay zekâ ile yazılım geliştirme, veri analizi, dokümantasyon ve iş süreçleri otomasyonu artık tek seferlik “soru-cevap” etkileşimlerinin ötesine geçiyor. Birkaç yıl önce gündemimizde daha çok prompt engineering vardı: Modele doğru soruyu nasıl sorarız? Bağlamı nasıl veririz? Beklediğimiz çıktıyı nasıl tarif ederiz?
Bugün ise daha farklı bir noktaya doğru ilerliyoruz. Artık mesele yalnızca iyi prompt yazmak değil; yapay zekâ sistemlerinin bir işi alıp, adım adım ilerleyebileceği, hata yaptığında geri dönebileceği, sonucu test edebileceği, öğrendiğini kaydedebileceği ve bir sonraki denemede daha iyi davranabileceği kontrollü döngüler tasarlamak.
Bu yaklaşımı genel olarak loop engineering olarak adlandırabiliriz.
Loop engineering, yapay zekâ destekli sistemlerde şu soruya cevap arar:
Bir LLM’i tek seferlik cevap üreten bir araç olmaktan çıkarıp, hedefe doğru kontrollü şekilde ilerleyen, doğrulanan ve gerektiğinde kendini düzelten bir süreç bileşeni haline nasıl getiririz?
Bu yazıda loop engineering kavramını, self-improving loop yani kendi kendini iyileştiren döngü fikrini, erken benchmark sonuçlarının bu konuda bize ne söylediğini ve bu yaklaşımın yazılım geliştirme ile kurumsal yapay zekâ sistemleri açısından ne anlama geldiğini ele alacağım.
Teknoloji tarihinde bazı dönemler vardır. Herkes büyük bir değişimin geldiğini hisseder, şirketler yatırım yapar, yöneticiler sunumlarında bu yeni teknolojiden bahseder, danışmanlar yeni kavramlar üretir, tedarikçiler hızlıca yeni ürünler çıkarır. Fakat bütün bu hareketliliğe rağmen verimlilik göstergeleri beklenen hızda değişmez. İnsanlar doğal olarak şu soruyu sormaya başlar: “Bu kadar büyük teknoloji yatırımı yapıyoruz ama gerçek verimlilik nerede?”
Brett Hemenway Falk ve Gerry Tsoukalas’ın Mart 2026 tarihli “The AI Layoff Trap” başlıklı çalışması, yapay zekâ ve istihdam tartışmasına alıştığımız eksenden bakmıyor. Makalenin odağı, “çalışanlar işlerini kaybederse ne olur?” sorusuyla sınırlı değil. Daha sert ve teknoloji liderleri açısından daha rahatsız edici bir soru soruyor:
Şirketler yapay zekâ ile maliyetlerini düşürürken, bir taraftan da kendi ürün ve hizmetlerine olan toplam talebi de düşürüyor olabilir mi?
Bir cuma akşamı production ortamında kritik bir hata çıktığını düşünün. Sistem çalışıyor ama bazı müşteriler sipariş oluşturamıyor. Loglar temiz. Monitoring sistemleri olağan dışı bir şey göstermiyor. Kodun ilgili kısmına bakan ekip üyeleri mantıksal bir problem göremiyor.
Sonra ekipte biri şöyle diyor:
“Ah… bu davranış aslında bilerek böyle yapılmıştı.”
Herkes dönüp soruyor: “Bunu kim yaptı?”
Cevap: “Üç yıl önce ayrılan bir geliştirici.”
O noktada organizasyon bir gerçekle yüzleşiyor. Kod orada olabilir. Ama sistemi gerçekten anlayan kişi artık organizasyonda değildir.
Bu sahne yazılım sektöründe sanıldığından çok daha yaygındır. Tam olarak bu nedenle Baldur Bjarnason’ın “Theory-building and why employee churn is lethal to software companies” yazısı bence yazılım organizasyonları üzerine yazılmış en önemli metinlerden biri.
Çünkü yazının merkezindeki fikir oldukça net:
Yazılım yalnızca kod değildir. Yazılım, ekiplerin zihnindeki kolektif anlayışın çalışan bir dışavurumudur.
Bu yaklaşımın kökeni ise Peter Naur’un yıllar önce ortaya koyduğu “Programming as Theory Building” düşüncesine dayanıyor.
Son birkaç yıldır teknoloji dünyasında sürekli aynı cümleyi duyuyoruz:
“Yapay zeka her şeyi değiştirecek.”
Bu cümle artık o kadar sık tekrarlandı ki, neredeyse anlamını kaybetti. Ama bazen bazı metinler çıkıyor ve size teknolojinin sadece ne yapabildiğini değil, insanlık için ne anlama geldiğini düşündürüyor.
Kyle Kingsbury’nin “The Future of Everything is Lies, I Guess” başlıklı uzun denemesi tam olarak böyle bir metin. Teknik bir makale değil. Bir yatırım sunumu değil. Bir ürün lansmanı hiç değil. Daha çok, yapay zekanın insan hayatına sızarken beraberinde getirdiği kültürel, psikolojik ve toplumsal kırılmaları anlatan karanlık ama dürüst bir düşünce yazısı.
Kök neden analizi, yani RCA (Root Cause Analysis), endüstride uzun yıllardır kullanılan en önemli iyileştirme araçlarından bir tanesi. Üretimden havacılığa, finanstan enerji sektörüne kadar birçok alanda, yaşanan bir problemin gerçek nedenini bulmak ve aynı problemin tekrar yaşanmasını engellemek için RCA süreçleri uygulanıyor.
Temel mantık oldukça basit. Bir sorun yaşandıysa sadece görünen sonucu değil, o sonucu ortaya çıkaran gerçek nedeni bulmak gerekir. Çünkü semptomları düzeltmek ile problemi çözmek aynı şey değildir.
Jevons Paradoksu, bir kaynağın kullanım verimliliği arttığında o kaynağın toplam tüketiminin azalmak yerine artabileceğini ifade eder. İlk bakışta bu durum sezgisel olarak yanlış gibi görünür. Çünkü yaygın beklenti, verimlilik artışının daha az kaynak tüketimine yol açmasıdır. Ancak ekonomik sistemler çoğu zaman sezgisel beklentilerle değil, teşvikler ve davranışlar üzerinden çalışır.
Paradoksun temelinde oldukça basit ama güçlü bir mekanizma vardır. Bir kaynağın daha verimli kullanılması, o kaynağın efektif maliyetini düşürür. Maliyet düştüğünde ise talep artar.
Agent sistemleriyle ilgili konuşurken çoğu ekip hala aynı varsayımla ilerliyor: eğer kod doğruysa sistem güvenlidir. MCP ile birlikte bu varsayım artık geçerli değil. Çünkü bu sistemlerde kararları kod değil, model veriyor. Model ise dünyayı API contract’ları üzerinden değil, doğal dil üzerinden anlıyor.
Bu fark küçük gibi görünür ama etkisi büyük. Çünkü model bir şeyi yanlış anladığında, bu artık sadece yanlış bir cevap değildir; yanlış bir aksiyondur. MCP’nin sunduğu şey tam olarak bu: modelin dış dünyada işlem yapabilmesi. Ama aynı zamanda yeni bir risk katmanı da ekler: semantic yanlış anlama.
Yapay zeka son birkaç yılda “hızlı dene – hızlı üret” paradigmasıyla ilerledi. Model seç, prompt yaz, deploy et. Özellikle LLM tabanlı ürünlerde bu yaklaşım neredeyse varsayılan hale geldi. Ancak Avrupa Birliği’nin AI Act düzenlemesi ile birlikte bu dönem kapanıyor. Artık yapay zeka sadece bir yazılım bileşeni değil; regüle edilen bir ürün.
Bu yazıda AI Act’in ne olduğunu anlatmanın ötesine geçip, geliştiriciler ve teknoloji şirketleri için gerçek dünyada neyi değiştirdiğini konuşalım.
2023-2024 yıllarında başlayıp günümüze kadar geldiğimiz süreçte teknoloji dünyasında çok net bir örüntü oluştu. Neredeyse her ürün, her platform ve her servis kendini şu şekilde konumlandırıyor:
Bu noktada açık konuşmak gerekiyor.
Bugün piyasadaki birçok ürün için “AI” bir teknoloji bileşeni değil, bir pazarlama zorunluluğudur.
Bu sert bir ifade olabilir. Ancak sahadaki gerçeklik çoğu zaman bunu doğruluyor.
Yazılım geliştirme pratiği kökten bir dönüşüm geçiriyor. “Vibe coding”, AI-assisted yazılım geliştirme ve agentic sistemler artık günlük iş akışımızın parçası haline geldi.
İlk bakışta tablo oldukça net görünüyor: Daha az kod yazıyoruz, daha hızlı ilerliyoruz, daha az efor harcıyoruz.
Ancak sahadaki deneyim farklı bir şey söylüyor.
Birçok geliştirici şu hissi paylaşıyor:
Bu yazıda bu hissin arkasındaki gerçeği inceleyeceğiz: AI gerçekten bilişsel yükü azaltıyor mu, yoksa sadece yeniden mi dağıtıyor?
1970’lerin sonlarında Meir Lehman, büyük ölçekli yazılım sistemlerinin zaman içindeki davranışlarını inceleyerek bir dizi kanun ortaya koydu. Bu kanunlar teorik değil, doğrudan üretim sistemlerinden elde edilen gözlemlere dayanıyordu.
Bugün ise farklı bir kırılma noktasındayız. Yazılım artık sadece insanlar tarafından yazılmıyor, giderek artan oranda AI ile üretiliyor.
Son birkaç yılda yazılım dünyasında çok yoğun şekilde konuşulan, sürekli gündemde tutulan ve ciddi bir hype ile sunulan bir dönüşüm yaşanıyor.
Her yerde aynı sorular:
Kurumsal sistemlerde yıllardır tekrar eden bir döngü var: Önce problemi araçla çözmeye çalışıyoruz, sonra aracın neden çalışmadığını tartışıyoruz. BPM araçları, iş akışı (workflow) motorları, entegrasyon platformları derken şimdi aynı refleksi agentic AI ile görüyoruz.
Soru aslında hiç değişmedi: İşletme süreçlerimizi gerçekten biliyor muyuz, yoksa sadece çalışıyor gibi görünen bir operasyonu mu otomatikleştirmeye çalışıyoruz?
Agentic AI bu soruyu ortadan kaldırmaz. Aksine, cevabın eksik olduğu durumlarda problemi büyütür.
Bu yazının temel tezi şudur:
Agentic AI, süreç problemini çözmez. Süreçlerin tanımlı olmadığı ortamlarda kaosu hızlandırır ve büyütür.
The current generation of AI coding tools is impressive as a product category, but much less convincing as a platform category.
That distinction matters.
There is a lot of attention on the user-facing side of these tools: prompt boxes, agent workflows, code generation, terminal loops, patch application, context gathering, and various forms of assisted editing. But when these products are examined from the perspective of integration, automation, governance, and third-party extensibility, the picture becomes much weaker.
Disclaimer: This is not written as a criticism of any specific product or team. The issues discussed here are structural and ecosystem-wide. No pun intended toward any particular tool, vendor, or approach.
Yazılım geliştirme dünyasında sık karşılaşılan bir yaklaşım vardır. Birçok kişi bir teknolojiyi veya yöntemi öğrenmenin en iyi yolunun gözlem yapmak olduğunu düşünür. Çalışan kodları incelemek, başkalarının çözümlerini görmek, örnek projeleri takip etmek ve bunları taklit etmek.
Bu yaklaşımın belirli bir değeri vardır. Gözlem öğrenmenin önemli bir parçasıdır. Ancak tek başına yeterli değildir. Sadece gözleme dayalı bir öğrenme modeli yazılım mühendisliği gibi karmaşık bir disiplinde ciddi sınırlamalara sahiptir.
Teori bu noktada devreye girer. Teori, gözlemlenen davranışların arkasındaki yapıyı anlamayı sağlar.
A detailed explanation of why HARP defines a cryptographic human authorization layer instead of building on top of existing MCP-style tool invocation protocols.
HARP defines a deterministic artifact model, canonical hashing, and signed decision tokens to cryptographically bind human approval to AI agent actions, with replay resistance, strict enforcement requirements, and interoperability primitives.
