Ali Özgür

Yapay zekâ tarafından üretilen içeriğin nasıl ayırt edileceği uzun süredir teknik bir tartışma konusuydu. Bir metnin diline, kelime seçimlerine veya cümle yapılarına bakarak “bunu bir yapay zekâ yazmış olabilir” diyen sınıflandırıcılar geliştirildi; görseller için metadata ve görünür filigranlar kullanıldı; kriptografik imzalar ve içerik kökenini izleyen standartlar üzerinde çalışıldı. Ancak Ağustos 2026 itibarıyla konu yalnızca araştırma laboratuvarlarının veya güvenlik ekiplerinin meselesi olmaktan çıktı. Avrupa Birliği’nin Yapay Zekâ Tüzüğü’nün (AI Act) şeffaflığa ilişkin hükümlerinin uygulanmaya başlaması, üretken yapay zekâ sağlayıcılarını doğrudan teknik önlem almaya zorluyor.

Yapay zekâ hayatımıza yeni girmedi. On yılı aşkın süredir arama motorlarının sonuçları sıralamasından öneri sistemlerine, kredi kartı işlemlerindeki sahtekârlık tespitinden görüntü işlemeye, talep tahmininden kestirimci bakıma kadar pek çok sistemin arkasında makine öğrenmesi ve yapay zekâ modelleri bulunuyor. Hatta bugün geriye dönüp baktığımızda, günlük hayatımızda kullandığımız birçok ürünün uzun süredir AI destekli olduğunu ancak çoğu zaman bunun farkında bile olmadığımızı söyleyebiliriz.

Yuval Noah Harari’nin yapay zekâ üzerine yaptığı konuşmalarda kullandığı cin hikâyeleri benzetmesini oldukça düşündürücü buluyorum. Harari, dünyanın farklı kültürlerinde farklı biçimlerde karşımıza çıkan cin ve dilek hikâyelerindeki ortak bir noktaya dikkat çekiyor. Bu hikâyelerde temel problem çoğu zaman cinin yeterince güçlü olmaması veya insanın dileğini gerçekleştirememesi değildir. Asıl problem, insanların ne istemeleri gerektiğini bilmemeleri ve yanlış şeyleri dilemeleridir. Cin kendisinden isteneni yapar; hatta bazen dileği kelimesi kelimesine ve kusursuz biçimde gerçekleştirir. İnsan ise istediği şeyi elde ettikten sonra bunun aslında arzuladığı sonuç olmadığını veya dileğinin öngöremediği sonuçlar doğurduğunu fark eder.

Yapay zekânın yazılım geliştirme süreçlerine girişi artık “gelecekte yaşanabilecek” bir dönüşüm değil.

Bugün bir yazılım geliştirici gereksinimi analiz ederken ChatGPT kullanabiliyor, mimari alternatifleri Claude ile tartışabiliyor, Cursor veya GitHub Copilot ile kod yazabiliyor, Codex benzeri bir ajanı bir issue üzerinde çalıştırabiliyor, oluşturulan kodu başka bir LLM’e (Large Language Model — Büyük Dil Modeli) inceletebiliyor ve son olarak ortaya çıkan değişikliği Git üzerinden pull request olarak gönderebiliyor.

“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:

• AI-powered
• AI-native
• AI-first

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:

• Daha hızlı ilerliyorum
• Ama daha çabuk yoruluyorum
• Daha az yazıyorum
• Ama daha fazla düşünüyorum

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:

• Yazılım geliştiricilik meslek olarak geçerliliğini yitirecek mi?
• Artık kod yazmaya gerek var mı?
• AI her şeyi yapabilecek mı?

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.