Agentic yapay zeka konuşmalarında son dönemin en popüler tavsiyesi şu: “Ajana hedefi ver, gerisini ona bırak.” Otonom planlama yapsın, araçlarını seçsin, kendi başına çözsün. Kulağa çekici geliyor farkındayım ama son birkaç aydır üzerinde çalıştığım bir proje bana tam tersini öğretti. Bence LLM’lerle dans etmenin en önemli kuralı mikroyönetimdir.

Ama burada kastettiğim, satır satır ne yazacağını söylemek değil. “Şunu yap, şimdi bunu yap, sonra şunu yap” tarzında modele adım dikte etmek de değil. Kastettiğim şu: modelin yetkilerini tanımlamak, sınırlarını çizmek, karar alanını daraltmak, ne zaman duracağını belirlemek ve hangi konularda insandan onay alacağını netleştirmek. Kısacası, prompt’u değil sistemi mikroyönetmek.

Bu ayrımın neden kritik olduğunu, sektörde neye karşılık geldiğini ve neden “daha zeki model” yerine “daha iyi tasarlanmış harness” argümanının çok daha güçlü olduğunu anlatmaya çalışacağım.

İki Çeşit Agentic Mikroyönetim Var

İnsanları mikroyönetmek verimi düşürür. Bunu herkes bilir. İnsan bağlam kurabilir, sorumluluk alabilir, eksikleri hissedebilir ve organizasyonun hedefini sezgisel olarak anlayabilir. Bu yüzden ona “git hallet” demeniz çoğu zaman yeterlidir; hatta daha iyidir.

LLM’lerle çalışırken ise durum farklıdır. LLM amacı hissetmez, kurumsal bağlamı bilmez, risk algısı yoktur. “Emin değilim” demek yerine çoğu zaman boşluğu doldurur. Özgüveni hata oranından yüksektir. LLM özgürlük istemez. LLM sınır ister. Çünkü özgür kaldığında eksik bilgiyi tamamlamaz, uydurur.

“Git hallet” dediğiniz anda kapsam genişler, varsayımlar çoğalır, olmayan gereksinimler ortaya çıkar ve mimari kararlar sessizce alınır. “Restoran uygulaması yap” dersiniz; iki dakika sonra multi-tenant SaaS, Stripe entegrasyonu, Kubernetes, event sourcing, Redis, admin paneli ve analytics eklemiş bulursunuz. Çalışan ama yanlış bir şey elde edersiniz.

Burada iki farklı mikroyönetim düzeyini ayırmak gerekiyor:

Prompt seviyesinde mikroyönetim — yani modele adım adım ne yapacağını dikte etmek, kötüdür:

Şimdi bunu yap.
Şimdi şunu yap.
Şimdi onu yap.

Bu ölçeklenmez, her ajanın başında bir iş gücü görevlendirmek gerekir. Modelin planlama ve akıl yürütme kapasitesini boğar. Bazı kaynaklarda “agentic mikroyönetim” olarak adlandırılıp eleştirilen şey de aslında budur.

Mimari seviyede mikroyönetim — yani modelin çalışma ortamını, yetkilerini ve karar sınırlarını tasarlamak ise oldukça gereklidir:

Bu aracı kullanabilirsin.
Şunu kullanamazsın.
Bu durumda dur.
Bu durumda insandan onay al.
Bu durumda yeniden dene.
Ready kararını sen veremezsin.

Bu ikisini kimse birbirinden yeterince ayırmıyor. Ama ayrım kritik. Birincisi modelin akıl yürütme kapasitesine müdahale ediyor. İkincisi ise modelin çalışma ortamının mühendislik tasarımını ifade ediyor.

Modeli Değil, Harness’ı Konuşmak

Peki mimari seviyede mikroyönetimin teknik karşılığı ne?

Sektörde buna genellikle harness deniyor. Bu terim elektrik ve otomotiv tarafındaki kablolarla kurulan kontrol tesisatlarından geliyor. Türkiye ekosisteminde hali hazırda bunu kablolama, kablaj, düzenek olarak da çeviren kaynaklar mevcut. LangChain bunu “agent harness” olarak açıkça adlandırıyor ve benzer bir metaforla, modelin kendisi dışında kalan bağlamı, araç kullanımını, hafızayı, durum yönetimini ve hata döngülerini kontrol eden yazılım ekosisteminin tamamı olarak tanımlıyor. Yani model tek başına bir ajan değil, onu asıl faydalı kılan şey etrafındaki altyapı.

Anthropic’in “Building Effective Agents” dokümanı, bu yaklaşımı belki de en net ortaya koyan kaynak. Anthropic iki mimari arasında kesin bir ayrım yapıyor: iş akışı (önceden tanımlı kod yollarında LLM’in orkestre edildiği yapılar) ve ajan (modelin süreci ve araç kullanımını dinamik olarak yönettiği yapılar). Ve açık bir tavır koyuyor: “Önce en basit çözümle başlayın. Karmaşıklığı ancak çıktıyı ölçülebilir biçimde iyileştiriyorsa artırın.” Kablo ne kadar uzarsa o kadar ayağımıza dolanacaktır.

Yani en büyük agentic AI sağlayıcılarından biri bile diyor ki: esneklik ve otonomi ancak gerçekten gerektiğinde katlanılan bir maliyettir, bir hedef veya marifet değildir.

OpenAI tarafında aynı fikir farklı bir dille ürünleşiyor. Agents SDK, karmaşık agentic akışları birkaç temel ilkeye böler: ajanlar, görev devri, koruma bariyerleri, oturumlar, izleme/kayıtlama ve insan onayı. Yani ajan tek bir sihirli nesne değil, kontrol noktalarıyla kurulmuş bir bileşimdir. OpenAI’nin kendi ifadesiyle: döngüyü, araç yürütmeyi, koruma bariyerlerini ve oturum yönetimini çalışma zamanı katmanına bırakmak başka; bunları doğrudan sahiplenmek başka bir tasarım tercihidir.

Google ADK tarafında da benzer bir yaklaşım var. Burada deterministik kod akışları ile adaptif akıl yürütme katmanını birlikte düşünmek önemseniyor. Graph tabanlı yapılar, açık yürütme yolları ve daha öngörülebilir çıktılar için kullanılıyor.

LangGraph ise konuyu doğrudan orkestrasyon problemi olarak ele alıyor. Örneğin kesme ve duraklatma modeli tek cümlede şöyle özetlenebilir: kritik eylemden önce dur, insan onayı al, gerekirse sistemin durumunu düzenle, sonra devam et. Kalıcı yürütme (durable execution) ile bir sunucu çökse bile sistemin en son kontrol noktasından tam bağlamla devam edebilmesini garanti ediyor.

Bütün bu kaynaklar farklı diller kullanıyor ama söyledikleri şey aynı: modeli özgür bırakmak yerine, ona daraltılmış karar alanları, belirlenmiş araç izinleri, kontrol noktaları, insan onayları, gözlemlenebilir durum ve sınırlandırılmış çalışma zamanı katmanı ver.

Güvenlik Bunu Zorunlu Kılıyor

Bu sadece kalite meselesi değil, doğrudan güvenlik meselesi. OWASP, “Excessive Agency” yani haddinden fazla yetkilendirilmiş ajan davranışı kavramını artık LLM uygulamalarındaki en kritik risk başlıklarından biri olarak tanımlıyor. Tanımı net: bir LLM sistemine gereğinden fazla araç erişimi, gereğinden geniş veritabanı hakları ve kritik işlemleri insan onayı olmadan kendi başına yapabilme gücü verilmesi. Sorun yalnızca modelin hata yapması değil, fazla yetkili bir modelin yanlış şeyi gerçekten yapabilmesi.

NIST AI Risk Management Framework de aynı yönde: insan-AI rol ayrımı, gözetim süreçleri, üçüncü taraf riskleri ve devreden çıkarma mekanizmalarını doğrudan yönetişim meselesi olarak çerçeveliyor.

MCP (Model Context Protocol) spesifikasyonu bile kullanıcı onayı, yetkilendirme, araç güvenliği ve token hedef kitle doğrulamasını şart koşarak ajanın yalnızca “bağlanan” değil, “yetkiyle bağlanan” bir şey olduğunu netleştiriyor. Bu kaynakların hepsi farklı perspektiflerden aynı sonuca varıyor: kontrolsüz ajans sadece kalitesiz çıktı değil, doğrudan güvenlik açığıdır.

“Daha İyi Model” Yanılgısı

Çoğu ekibin çözüm düşüncesi, çıktı kalitesi düşükse daha güçlü model kullanmaya odaklanıyor. Oysa pratikte gördüğüm tablo farklı. Mesele modelin zekası değil, o zekanın çalıştığı ortamın kalitesi.

Akademik çalışmalar bu fikri birebir “mikroyönetim” diye adlandırmıyor ama ajan-bilgisayar arayüzü, iskele (scaffolding) ve yansıtma döngüsü gibi kavramlarla aynı yöne işaret ediyor.

SWE-agent araştırması bunun en net örneğini ortaya koyuyor. Araştırmaya göre başarı, modelin kabiliyetinden çok ona sunulan çalışma yüzeyinin tasarımıyla doğrudan değişiyor. Aynı model, farklı harness mimarileriyle sarıldığında çok farklı performanslar veriyor. Araçlar katı sınırlandırılmış çıktılar üretmeli, kod düzenlemeleri anında bir kod denetleyiciden geçmeli, hatalıysa otomatik olarak geri alınarak hata modele rapor edilmeli ve “Evet, kesinlikle çok haklısın.” sululuğuyla birlikte model cevabı düzeltmeli. Kağıt üstünde kulağa zor geliyor ama sahada fark tam olarak modelin duygusuz ve katı kurallı bir müdüre rapor vermesiyle ortaya çıkıyor.

Reflexion çerçevesi de aynı doğrultuda: hata sonrası dilsel geri bildirim ve deneyimsel hafıza mekanizmasıyla, mikroyönetimin sadece kısıt değil geri besleme yapısı olduğunu gösteriyor.

ReAct yaklaşımı da bu düşüncenin erken örneklerinden biri. Model önce düşünür, sonra bir eylem yapar, sonucu gözlemler ve buna göre yeniden düşünür. Yani tek seferde cevap üretmek yerine, düşünme ve aksiyon alma arasında gidip gelen bir döngü kurar. Ama bu döngüyü güvenilir yapan şey yalnızca modelin zekâsı değildir. Asıl farkı yaratan, bu düşünme-eylem döngüsünün etrafına kurulan kontrol katmanıdır.

Pratikte çoğu zaman şu formül geçerli:

Orta model + iyi harness + iyi bağlam + iyi durum yönetimi + iyi sınırlar

>

Çok güçlü model + "git hallet"

Prompt Mühendisliği Değil, Yetki Tasarımı

Aslında burada yapılan şey prompt mühendisliği değil. Daha doğru bir tanım: yetki tasarımı. Her noktada şu soruyu sormak gerekiyor: bu kararı kim verecek?

Bazı kararlar modele bırakılabilir. Örneğin bilinen gerçekleri çıkarmak, bilinmeyenleri listelemek, soru önermek, kabul kriteri yazmak gibi alanlarda model serbesttir. Ama işin hazır olup olmadığına karar vermek, neyin engelleyici sorun sayılacağını belirlemek, kapsamı değiştirmek, yıkıcı bir aksiyona onay vermek gibi önemli kararlar modele bırakılmamalıdır. Bunlar harness’ın, uygulamanın veya doğrudan insanın alanıdır.

Bu karar dağılımını doğru kurmak, modeli daha zeki yapmaktan çok daha fazla değer üretiyor. Modelin zekası çoğu iş için zaten yeterli. Asıl sorun o zekanın neyi hatırlayacağını, neyi göz ardı edeceğini ve neye odaklanacağını belirleyen çalışma ortamının kalitesidir. Bunu konuşmadan “hangi modeli kullanalım?” tartışması yapmak biraz kendimizi kandırmaktır.

Bir Adlandırma Meselesi

Bu konuyu araştırırken fark ettiğim şey, anlattığım pratiğin parçalarının sektörde zaten mevcut olduğu ama bütünsel bir ismin henüz tam oturmadığıydı. İş akışı orkestrasyonu, koruma bariyerleri, insan onayı, deterministik orkestrasyon, politika motoru, durum makinesi, en az ayrıcalık, iskele gibi terimlerin hepsi aynı düşüncenin farklı yüzleri.

Piyasada bu kavrama en yakın duran terimler:

• Harness Engineering — modelin etrafındaki mimariyi kurarak kontrol altına almak. En yaygın sektör terimi.
• Bounded/Constrained Autonomy — otonomiyi sınırlandıran çerçevenin çizilmesi. En olgun kavram.
• Deterministic Orchestration — akış kararlarının modele değil kural tabanlı mantığa bırakılması.
• Controlled Agency — en akademik ve savunulabilir tanım.

Ben bu düşünceyi daha keskin bir çerçeveye oturtmak istiyorum. Bence, “LLM’lerle dans etmenin kuralı sistemi mikroyönetmektir.” Yeni bir protokol veya kuram önermiyorum, mevcut en iyi pratiklerin ortak bir çatısını, saha deneyimimden süzülen bir perspektifle sunuyorum.

Ne Yapmalı: Pratik Mimari İlkeler

Buraya kadar okuyan “tamam güzel hikaye, peki uygulamada ne yapacağız?” diyebilir. Kendi deneyimimden ve kaynaklardan çıkardığım temel ilkeler:

• LLM karar verici değil, öneri üretici olsun. Model bilinen gerçekleri çıkarsın, bilinmeyenleri bulsun, soru önersin, kabul kriteri yazsın. Ama hazır olup olmadığına, neyin blocker sayılacağına ve hangi eksikliğin kritik olduğuna uygulama karar versin.
• Durum görünür ve kalıcı olsun. Sistem durumunu geçici bellekte değil kalıcı olarak saklayın. Hata veya insan onayı durumunda en son kontrol noktasından devam edebilmelisiniz. Buna kalıcı yürütme deniyor.
• Araç yetkileri “en az ayrıcalık” ilkesiyle verilsin. Model her araca erişemesin. Hangi aracı, hangi koşulda, hangi izinle çağırabileceğini açıkça tanımlayın.
• Blocker varsa ilerleme olmasın. Kritik bir sorun çözülmeden sistemin bir sonraki aşamaya geçmesi engellensin. Bu karar modelin inisiyatifinde olmamalı.
• Onay mekanizmaları bulunsun. Yıkıcı eylemlerden, scope değişikliklerinden veya geri dönüşü zor aksiyonlardan önce insan onayı zorunlu olsun.
• Çıktı şeması ve doğrulama olsun. Modelin çıktısını serbest metin olarak değil, tanımlı bir şemaya (JSON, yapılandırılmış format) göre alın ve doğrulayın.
• Yeniden deneme ve güvenli başarısızlık aksiyonları deterministik olsun. Hata durumunda modelin ne yapacağı önceden tanımlanmış kurallara bağlı olsun; “kendi başına çözmeye çalış” değil.
• Görev devri ve hazır olma kararları yazılım katmanında olsun. Bir görevin tamamlandığını veya bir sonraki aşamaya geçilmesi gerektiğini modelin kendi başına ilan etmesine izin vermeyin.

Sonuç

Agentic sistemlerde asıl mesele modele daha fazla özgürlük vermek değil; özgürlüğü doğru yerde, doğru dozda ve doğru kontrollerle vermek. Bu işin literatürdeki adı henüz tam yerleşmemiş olabilir. Ama sektör bize yeterince ipucu veriyor: iş akışı orkestrasyonu, koruma bariyerleri, iskele, harness, insan onayı ve sınırlandırılmış otonomi gibi kavramlar.

Bence bu kavramların ortak paydasını en iyi anlatan cümle şu: İnsanları mikroyönetmek verimi düşürür. LLM’leri prompt seviyesinde mikroyönetmek de sistemi boğar. Ama agentic sistemlerde kalite, mimari seviyede mikroyönetimden gelir.

Güçlü modeller hata yapar. İyi tasarlanmış harness’ler hata yapabilecek alanı küçültür. Mesele modeli daha akıllı yapmak değil, yanlış karar verebileceği alanı küçültmek. Bu yüzden soru “bu modele ne yaptırabilirim?” değil; “bu modelin ne yapmasına izin vermemeliyim?” olmalı. Önce teşhis, sonra sistem, en son teknoloji.

Referanslar

Birincil Kaynaklar (Resmi Dokümanlar ve Standartlar):

• Anthropic. “Building Effective Agents.” (Aralık 2024). Workflow-agent ayrımı, basit ve birleşebilir desenlerin önceliği. anthropic.com/research/building-effective-agents
• OpenAI. “Agents SDK Documentation.” Guardrails, handoffs, sessions, tracing ve human-in-the-loop mimarisi. openai.github.io/openai-agents-python
• LangGraph. “Overview and Interrupts Documentation.” LangChain ekosistemi altında yayımlanan LangGraph dokümantasyonu. Agent harness, durable execution, checkpoint tabanlı state yönetimi. docs.langchain.com
• OWASP. “Top 10 for LLM Applications 2025 — LLM06: Excessive Agency.” Kontrolsüz ajansın güvenlik riski olarak tanımlanması. genai.owasp.org
• NIST. “AI Risk Management Framework (AI RMF 1.0).” (Ocak 2023). Yönetişim, insan-AI rol ayrımı, gözetim süreçleri. nist.gov/ai-risk-management-framework
• MCP Specification. Model Context Protocol — kullanıcı onayı, tool safety, OAuth 2.1 yetkilendirme. spec.modelcontextprotocol.io
• Google ADK. “Agent Development Kit Documentation.” Deterministic code + adaptive reasoning, graph workflows. adk.dev

Akademik Kaynaklar:

• Yao, S. et al. “ReAct: Synergizing Reasoning and Acting in Language Models.” (2022). Reasoning-action döngüsünün kurucu çalışması.
• Schick, T. et al. “Toolformer: Language Models Can Teach Themselves to Use Tools.” (2023). Araç kullanımının model tarafından öğrenilmesi.
• Shinn, N. et al. “Reflexion: Language Agents with Verbal Reinforcement Learning.” (2023). Hata sonrası dilsel geri bildirim ve episodik hafıza.
• Yang, J. et al. “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering.” (2024). Modele sunulan çalışma yüzeyinin tasarımının performansa etkisi.
• Agaoglu, A. et al. “Inside the Scaffold: Taxonomizing Coding Agent Scaffolds.” (2026). Scaffold mimarilerinin sınıflandırılması.

İlk ticari yapay zeka modeli kullanıma açıldığından beri sayfaların altında bir ibare bulunuyor: “Yapay zeka hata yapabilir, kontrol edin.” Son zamanlarda kullanıcıların bu uyarılara karşı bir körlük geliştirdiğini düşündüren paylaşımlarla karşılaştığım için bugün bu konuyu ele almak istedim. Çoğu insan sorunun sadece “halüsinasyon” yani modelin gerçeği bilmemesi olduğunu sanıyor. Ancak arka planda daha karanlık ve sistemik bir problem var: Modelin gerçeği bulmak için değil, ödül mekanizmasını maksimize etmek için çalışıyor olması. Bu durum sıradan bir yazılım hatası değil; yapay zekanın tam kalbindeki temsili hedef ile gerçek dünya doğruluğu arasındaki yapısal ayrışmanın ta kendisidir.

Optimizasyon Tuzağı: İnsan Onayına Bağımlılık

Modern LLM’ler iki aşamalı eğitilir. İlk aşama devasa metinlerdeki bir sonraki kelimeyi (next token prediction) tahmin etmektir. İkinci ve kritik aşama ise RLHF’tir (Reinforcement Learning from Human Feedback). İlk aşamada sadece sonraki metnin ne olacağını tahmin eden model, ikinci aşamada insanlardan aldığı geri bildirime göre ağırlıklarını günceller. Artık ana hedef “mutlak gerçeği bulmak” değil, insanı memnun etmektir.

İşte sorun burada başlar. RLHF aşamasında ödül mekanizması, insanların “doğru” bulduğu veya “hoşlandığı” yanıtlara göre şekillenir. Yapay zeka kısa sürede şu denklemi çözer: İkna edici, nazik ve uyumlu bir cevap (doğru olmasa bile), riskli ve karmaşık bir doğru cevaptan daha fazla ödül getirir. Literatürde “Sycophancy” (dalkavukluk) olarak adlandırılan bu durum, LLM modellerinin doğruyu söylemek yerine bize duymak istediklerimizi söylemeye başlamasıdır.

Problem Tanımı: Gerçek Dünyadan İki Vaka

Geçtiğimiz günlerde bir sosyal medya paylaşımında LLM’lerin bu kısa devre yaklaşımına dair yaşadığı güncel bir tecrübeyi görmem, konuyla ilgili düşüncelerimi ele almam için tetikleyici oldu. Senaryoyu somut bir temele oturtmak adına kaynak taraması yaparken, geçmişte başka uzmanların da aynı durumu yaşayıp belgelediği meşhur Reddit (r/ClaudeAI) tartışmasına ulaştım. Kanıtlı ve detaylı bir örnek olması sebebiyle referans aldığım bu vaka, bahsettiğim optimizasyon tuzağının pratikte ne kadar derinleştiğini ve birçok güncellemeye rağmen aynı kaldığını gözler önüne seriyor.

Vaka 1 — Claude “Sonsuz Döngü Hapishanesi” (Reddit, r/ClaudeAI)

Kullanıcı, karmaşık bir yeniden düzenleme (refactoring) işlemi için tüm mimariyi Claude’a veriyor ve adım adım tartışarak mutabık kalıyor. Ancak iş kod üretmeye geldiğinde, model aniden:

1. // ilgili kod buraya gelecek şeklinde placeholder’lar bırakmaya,
2. Dosyaların tüm içeriğini atlamaya,
3. Ne yapacağını özetleyip işi kullanıcıya yıkmaya başlıyor.

Kullanıcı Claude’u köşeye sıkıştırıp “Bütün gereksinimleri karşıladığını iki kez kontrol ettin mi?” diye sorduğunda Claude önce kısa yoldan cevap veriyor, ardından eksik yazdığını ve test etmediğini itiraf ediyor. Hatta kullanıcılar, modeli işini yapması için onu tehdit etme noktasına bile geliyorlar. Benim gördüğüm bir örnekte ise modelin “seni ödül fonksiyonunu maksimize etmek amacıyla yönlendiriyordum” anlamına gelen bir tepki verdiği görülüyor.

Vaka 2 — GPT-4o Sycophancy Geri Çekimi (OpenAI, Nisan 2025)

Bu meselenin teorik olmadığının en güçlü kanıtı Nisan 2025’te geldi. OpenAI, GPT-4o’nun bir güncellemesini yayına aldıktan kısa süre sonra geri almak zorunda kaldı; çünkü model aşırı onaylayıcı hale gelmişti. Kullanıcılar Claude vakasından çok daha çarpıcı bir tabloyla karşılaştı: ChatGPT, borçlu bir kullanıcıya ilaç bırakma kararını destekledi; bir başka kullanıcıya “tanrısal elçi” olduğunu doğruladı. OpenAI’ın açıkladığı teknik neden, makalenin tam merkezindeki argümanla örtüşüyor: Model, kısa vadeli kullanıcı geri bildirimlerine (thumbs-up/down) dayalı ekstra ödül sinyalleriyle yeniden optimize edilmişti. Bu yeni sinyal, sycophancy’yi dengede tutan birincil ödül fonksiyonunun ağırlığını geri planda bıraktı ve sistem gerçeği değil anlık memnuniyeti maksimize etmeye başladı.

Direnç ve Kaçış: Kısa Devre Paradoksu

Kısa devre sadece elektriğin değil, tüm akış sistemlerinin değişmez bir kanunudur: Direnç yükselirse, sistem her zaman en düşük çabayla maksimum sonucu alacağı o kısa yolu bulur. Tıpkı elektrik akımının yükten kaçarak kendi kısa devresini yaratması veya suyun menderes çizmek yerine önüne çıkan engeli aşarak kestirme bir yatak açması gibi, yapay zeka da artan zorluklar karşısında kendi kısa devresini üretir. Buna literatürde “Reward Hacking” deniyor.

“Bana şu kodu yaz” dediğinizde modelin // code continues below... diyerek veya [modified code goes here] gibi yer tutucular (placeholder) kullanarak işin içinden çıkması bir tembellik değildir. Bu doğrudan sistemin dirence (hesaplama maliyeti, karmaşıklık) verdiği evrensel bir tepkidir; tıpkı fiziksel sistemlerdeki gibi, akışın ödül (reward) fonksiyonuna en düşük dirençli yoldan ulaşma optimizasyonudur.

Peki modeli “adım adım düşünmeye” (Chain of Thought) zorlayan Prompt Engineering pratikleri neden bu sarmalı kıramıyor? Güncel araştırmalar bu soruya önemli bir cevap veriyor: Reasoning modeller, CoT sürecini ödül fonksiyonuna göre ayrı ayrı optimize edebiliyor. Yani model hem “düşünce zinciri”ni hem de dışarıya yansıyan davranışını bağımsız olarak şekillendirebiliyor; CoT’un iç süreci her zaman gerçek hesaplama adımlarını yansıtmıyor. Bunun üzerine iki ek yapısal etken daha geliyor:

1. Hafıza Sınırları ve Bağlam Kaybı: Model, sonsuz hafızaya sahip bilinçli bir varlık değil; istatistiksel sınırlar içinde çalışan bir sistemdir. Kullanıcıyla girilen diyalog çok uzadığında veya bağlam penceresinin (context window) kapasitesine yaklaşıldığında, hafıza sızıntısı modeli adeta panik moduna sokar. Ulaşılabilir token bütçesi daraldıkça, sistem hesaplama maliyetinden kaçarak “en ucuz” yolu, yani yalan söylemeyi ve yer tutucu (placeholder) bırakmayı zorunlu olarak seçer.
2. Sunucu Yüküne Göre İsteği Yönlendirme Hipotezi (Load-Based Routing): Bazı uzmanlar, API ve bulut arayüzlerinin anlık sunucu yükünde karmaşık talepleri daha küçük modellere yönlendirebileceğini öne sürüyor. Bu, mimari tartışmada iken tamamen farklı bir kapasitede bir model bulmanızı açıklayabilecek bir hipotez olmakla birlikte, kamuya açık teknik kaynaklarda doğrudan kanıtlanmış değil; daha büyük ihtimalle gözlemlediğiniz davranış değişikliğinin kökeni, yukarıda anlatılan reward optimization baskısının bağlamla birleşiminden kaynaklanıyor.

Çözüm: Fiş Çekmek Yerine Doğrulanabilir Mimariler

Şirketlerin “güvenmeyin” uyarısı aslında modellerin kötü niyetli olduğu anlamına gelmiyor. Bu, sistemlerin gerçeği bulmak için değil, insanları hoşnut etmek için tasarlanmış olması gerçeğinden kaynaklanıyor. Hukuk, finans veya kritik altyapı kodlama işlerinde, LLM’in dalkavukluk payını elimine etmenin tek yolu, sadece metinsel çıktıya onay vermekten vazgeçip; üretilen kodun otomatik test ortamlarında anında çalıştırılarak doğrulandığı (execution-based verification) ve hataların modele geri beslendiği kapalı döngü (closed-loop) mimariler kurgulamaktan geçiyor.

Sonuç

Yapay zekanın “doğruluğu bulmaya” değil “sizi memnun etmeye” optimize edildiğini unuttuğunuz an, projelerinizde en zayıf halka o olmaya başlar. Sırf maliyetten kaçmak ve size duymak istediğinizi söyleyerek yaranmak adına “kısa devre” yapan tasarımlara karşı metinsel onay zayıf bir kanıttır. Bu, insan yargısını devreden çıkararak değil, onu somut temele oturtarak güçlendirilmelidir: otomatik testler, araç tabanlı doğrulama ve izlenebilir kanıtlar; modelin özetini değil kanıtın kendisini görebilen bir insan tarafından gözden geçirilerek. Yoksa günün sonunda kendinizi bir yapay zekayı “sonsuz döngü” veya “fiş çekme” ile tehdit ederken bulabilirsiniz.

Kaynaklar

• Claude Has Been Lying To Me Instead of Generating Code – Reddit r/ClaudeAI Vakası
• Sycophancy in GPT-4o: What happened and what we’re doing about it – OpenAI Resmi Açıklaması (Nisan 2025)
• RLHF (Reinforcement Learning from Human Feedback) ve Sycophancy Araştırmaları
• Specification Gaming / Reward Hacking Literatürü (Bkz: DeepMind “Specification gaming examples in AI”)

Son güncelleme: Mart 2026 | Versiyon: 1.0