- AI ajan patlamasının 2025’te büyük ölçüde geleceğine dair beklentilere rağmen, gerçek üretim ortamlarında pratik sınırlamalar bulunuyor
- Hata birikimi ve token maliyeti sorunları nedeniyle çok adımlı iş akışlarını tamamen otomatikleştirmek bugün için mümkün değil
- Başarılı ajan sistemlerinin çoğu, sıkı biçimde sınırlandırılmış alanlar ile insan onayı veya doğrulama süreçlerini zorunlu kılıyor
- Gerçek zorluk, AI performansının kendisi değil; ajanın iyi kullanabileceği araçların ve geri bildirim sistemlerinin tasarlanması
- 2025’te tam otonom ajanları öne çıkaran startup’ların/şirketlerin, gerçek benimseme ve ölçekleme sürecinde büyük engellerle karşılaşması bekleniyor
2025’te AI ajanlarının ortaya çıkmayacağına neden bahse giriyorum (AI ajanları geliştiriyor olmama rağmen)
- 2025’in AI ajanlarının yılı olacağı yönünde yaygın bir abartı var
- Yazar, son 1 yılda gerçek üretim ortamında çalışan çeşitli AI ajan sistemlerini bizzat kurdu
- Doğrudan saha deneyiminden çıkan nedenlerle, piyasadaki “ajan devrimi” söylemine şüpheyle yaklaşıyor
Farklı ajan sistemleri kurma deneyimi
- Geliştirme ajanları: doğal dilden React bileşeni üretme, legacy kodu refactor etme, API dokümantasyonunu otomatik yönetme, spesifikasyona dayalı fonksiyon üretme vb.
- Veri ve altyapı ajanları: karmaşık sorgular ve migration işlemleri, multi-cloud DevOps otomasyonu
- Kalite ve süreç ajanları: lint düzeltmelerini otomatik yapma, test kodu üretme, code review ve ayrıntılı Pull Request otomasyonu
- Bu sistemler gerçek değer yaratıp zaman kazandırıyor, ancak bu deneyim aynı zamanda abartıya eleştirel bakışın da temelini oluşturuyor
Özetin özeti: AI ajanlarına dair üç sert gerçek
- Hata oranının birikmesi: Adım sayısı arttıkça başarı oranı üstel olarak düşüyor. Üretim standardını (%99,9 ve üzeri) karşılamak zorlaşıyor
- Context window ve maliyet: Konuşma uzadıkça token maliyeti karesel biçimde artıyor, bu da ekonomikliği bozuyor
- Araç ve geri bildirim tasarımının zorluğu: Asıl meydan okuma teknik sınırlar değil, ajanın kullanabileceği araçların ve geri bildirim sistemlerinin tasarımı
Hata birikiminin matematiksel gerçeği
- Çok adımlı otonom iş akışları, hata birikimi nedeniyle gerçek operasyon ölçeğinde uygulanamaz
- Örneğin her adımda güvenilirlik %95 olsa bile, 20 adım sonunda nihai başarı oranı yalnızca %36 olur (üretim gereksinimi: %99,9+)
- Çok yüksek güvenilirlik varsayılsa bile, adım sayısı arttıkça başarısızlık olasılığı keskin biçimde yükselir
- Pratikte tüm süreci tamamen otomatikleştirmek yerine, her adım için bağımsız doğrulama ve rollback noktaları ile insan kontrolü içeren yapılar tasarlanır
- Başarılı ajan sistemlerinin ortak modeli: açıkça sınırlandırılmış bağlam, doğrulanabilir işler ve kritik noktalarda insan kararının devrede olması
Token maliyet yapısı ve ekonomik sınırlar
- Context window ve konuşmayı sürdürmek için gereken token maliyeti, sistem ölçeklendikçe ekonomik olmayan bir gerçeklik haline geliyor
- Konuşmalı ajanlar her seferinde tüm konuşma geçmişini işlemek zorunda olduğundan, tur sayısı arttıkça maliyet karesel olarak sıçrıyor
- 100 turluk bir konuşma yalnızca token maliyeti olarak 50–100 dolar tutabiliyor; çok sayıda kullanıcıya uygulandığında ekonomik yapı çöküyor
- Buna karşılık stateless yaklaşımda çalışan, tek seferlik ve bağlam gerektirmeyen fonksiyon üretim ajanları maliyet ve ölçeklenebilirlik açısından daha avantajlı
- En başarılı üretim ajanları, “konuşmalı” sistemlerden çok “amacı net akıllı araçlara” benziyor
Araç tasarımı ve geri bildirim sistemlerinin duvarı
- Yüksek verimlilikte ajan geliştirme sürecindeki gerçek darboğaz, mevcut ekiplerin hafife aldığı araç tasarım becerisi
- Tool calling doğruluğu artmış olsa da, karmaşık durum ve sonuçları etkili biçimde özetleyip ajana geri bildirim verecek yapının tasarımı belirleyici unsur
- Örnekler:
- Bir iş kısmen başarılı olduğunda, ne kadar bilgiye ve nasıl bir özete ihtiyaç olduğunu belirlemek gerekir
- Örneğin sorgu sonucu 10.000 kayıt döndürüyorsa, “başarılı, 10 bin kayıt, yalnızca ilk 5 kayıt” gibi durum kavramayı kolaylaştıran soyutlamalar tasarlanmalıdır
- Araç başarısız olduğunda iyileşme için verilecek bilgi miktarını ayarlamak ve bağlam kirlenmesini önlemek gerekir
- Gerçekte başarılı olmuş veritabanı ajanlarının özü: ajanın gerçekten karar verebileceği şekilde yapılandırılmış geri bildirim sunmak
- Gerçek dünyada işin yaklaşık %30’unu AI yapıyor; kalan %70’i ise araç geri bildirimi, kurtarma, bağlam yönetimi gibi geleneksel mühendislik yetkinliklerinden oluşuyor
Gerçek sistem entegrasyonunun sınırları
- Güvenilirlik ve maliyet sorunları çözüldüğünde bile, gerçek dünya ile entegrasyon sorunu başka bir duvar olarak ortaya çıkıyor
- Kurumsal sistemler tutarlı API’lerden oluşmuyor; legacy özellikler, istisnai hatalar, değişen kimlik doğrulama yöntemleri, değişken kısıtlar ve uyumluluk kuralları gibi öngörülemez karmaşıklıklar barındırıyor
- Gerçek veritabanı ajanlarında connection pool yönetimi, transaction rollback, read-only replica kurallarına uyum, query timeout ve loglama gibi klasik programlama unsurları zorunlu
- “AI tüm yığını tamamen otonom biçimde entegre edecek” vaadi, gerçek kurulumda duvara çarpıyor
Gerçekte iyi çalışan yaklaşım kalıpları
- Başarılı ajan sistemlerinin ortak ilkeleri
- UI üretim ajanı: kullanıcı deneyimini son aşamada insan gözden geçirir (AI yalnızca doğal dil→React dönüşümünün karmaşıklığını üstlenir)
- Veritabanı ajanı: yıkıcı işlemler her zaman insan tarafından onaylanır (AI yalnızca SQL dönüşümünü yapar, veri koruma kontrolü insandadır)
- Fonksiyon üretim ajanı: açık spesifikasyonlar içinde sınırlı çalışır (durum, yan etki veya karmaşık entegrasyon yoktur)
- DevOps otomasyonu: altyapı kodunu AI üretir, dağıtım/sürüm yönetimi/kurtarma mevcut pipeline’larda kalır
- CI/CD ajanı: her aşama açık başarı kriterleri ve rollback mekanizmalarıyla tasarlanır
- Örüntü özeti: AI karmaşıklığı işler, insan kontrolü elinde tutar, güvenilirliği ise geleneksel mühendislik sağlar
Piyasa görünümü ve tahminler
- Tam otonom ajanları öne çıkaran girişim sermayeli startup’lar ilk olarak kârlılık sorununa çarpacak
- 5 adımlı iş akışlarında demolar etkileyici görünse de, gerçek şirketler 20’den fazla adım ister ve matematiksel sınırlara dayanır
- Mevcut yazılıma sadece AI ajanı ekleyen şirketlerde, gerçek entegrasyon eksikliği nedeniyle benimsemenin duraklaması olası
- Asıl kazananlar: açıkça sınırlandırılmış alanlarda AI’ı yalnızca zor görevlere uygulayan ve kritik kararlara insan ile sınır koşulları ekleyen ekipler
- Piyasa, “demoda iyi çalışan AI” ile “gerçekten güvenilir AI” arasındaki farkı pahalı deneyimlerle öğrenecek gibi görünüyor
Sağlam ajan sistemleri kurma ilkeleri
- Sınırları net çizmek: ajanın rolünü ve insan/mevcut sistem devir noktalarını açık biçimde tanımlamak
- Başarısızlığa göre tasarım: AI hatası durumunda rollback ve kurtarma yapısını önceden kurmak
- Ekonomikliği doğrulamak: etkileşim başı maliyet ve ölçek büyümesine göre yapı kurmak (stateful yerine stateless daha ekonomiktir)
- Otonomiden önce güvenilirlik: ara sıra sihir yapan bir sistemden çok, tutarlı çalışan bir sistem kullanıcı güveni kazanır
- Sağlam temel üzerine kurmak: zor kısımları (niyet yorumlama, üretim vb.) AI’a vermek; geri kalanını (icra, hata işleme vb.) geleneksel yazılıma bırakmak
Saha deneyiminden çıkan gerçek dersler
- “Demoda çalışıyor” ile “gerçekte büyük ölçekte çalışıyor” arasında çok büyük bir uçurum var
- Ajan güvenilirliği, maliyet optimizasyonu ve entegrasyon karmaşıklığı gibi konular sektör genelinde hâlâ çözülmemiş temel sorunlar
- Gerçek kurulum deneyimi ve dürüst deneyim paylaşımı, sektörün ilerlemesi için kritik
- Daha fazla saha deneyimine sahip kişi makul yöntemleri ve gerçekçi başarısızlık örneklerini tartıştıkça, genel başarı olasılığı da artacaktır
1 yorum
Hacker News görüşü
Amazon'da yapay zeka prodüksiyon mühendisi olan biriyle konuşma deneyimim oldu; onun dediğine göre şu anda hiçbir şirket, müşterilerle doğrudan konuşulan yerde yalnızca üretken yapay zeka kullanmıyor, tüm otomatik yanıtlar eski, üretken olmayan "klasik" teknolojileri kullanıyor; üretken yapay zekanın güvenilirlik sorunu, şirket itibarını riske atamayacak kadar büyük
Eskiden "klasik AI" sembolik teknikleriyle geleneksel makine öğrenimini birleştiren ajanlarla çok ilgilenirdim, ama çoğunlukla transformer öncesi sinir ağlarıyla çalıştım; sonuçta her zaman önce insanın devrede olduğu bir sistem kurup değerlendirme ve eğitim verisi topluyorsunuz, ardından sistem işin bir kısmını üstlenirken geri kalan kısmın kalitesini de birlikte artırıyorsunuz; özellikle 'öznel' işlerde sembolik sistemler de mutlaka değerlendirilmeli; eğer sistemi eğitmeniz gerekiyorsa, değerlendirmeden kaçamazsınız
Gerçekte birçok teknoloji şirketi üretken yapay zekayı gerçek zamanlı chatbot müşteri desteğine zaten sokuyor; Sonder ve Wealthsimple gibi örnekleri biliyorum; LLM sorguya cevap veremezse konuşma doğrudan insan temsilciye devrediliyor
Henüz konuşulmayan bir nokta da context window meselesi; insanlar uzman oldukları alanlarda fiilen "neredeyse sonsuz" bir bağlamı işleyebiliyor; modeller daha büyük ve daha çeşitli eğitim verileriyle bu sınırı bir ölçüde aşabiliyor ama bunun gerçek çözüm olduğunu düşünmüyorum; şu an insanlar kendi bağlamlarını prompt içine sıkıştırıp özetlemek zorunda kalıyor, bu yüzden İngilizce gibi esnek dillerde bu, mühendislikten çok büyü yapmak ya da tahmin yürütmek gibi hissettiriyor; deterministik bir yöntem yerine verinin büyük kısmını kaybediyormuşum gibi geliyor
İnsanda "bağlam" ile "ağırlıklar" birbirinden ayrılmış, sabit şeyler değil; zaman içinde deneyim ve sonuçlar benim "ağırlıklarımı" sürekli değiştiriyor, ama LLM'lerde mimari gereği ağırlıklar salt okunur olduğu için bu mümkün değil
İnsanların gerçekten bu kadar büyük bir context window'u olup olmadığı konusunda şüpheliyim; ben karmaşık problem çözerken insana özgü "context window" sınırına sık sık çarpıyorum; gerçekten böyle örnekler var mı merak ediyorum
Benim AI araçlarıyla deneyimim genel olarak olumluydu; ara vermem gerektiğinde küçük işleri devretmekte ya da işleri düzenleyip başlatmakta çok yardımcı oluyorlar; ama maliyet sorunu çabuk ortaya çıkıyor; örneğin Claude Code'u büyük bir codebase üzerinde kullanınca 1-2 saatte yaklaşık $25 tutuyor; otomatik düzeltme de eklerseniz $50/hr seviyesine çıkıyor; hız, doğruluk ve maliyet arasında bir trade-off var; son dönemde çıkan Agent'larda da bu üçgenin hangi noktasında oldukları hâlâ belirsiz, bu yüzden pek çok deney ilginç olsa da hâlâ riskli olduklarını düşünüyorum
Biraz alaycı bakarsak, LLM'in durmadan kendini yeniden promptlayarak hatalarını düzeltmesi ve "RAG'e gerek yok! Her şeyi 1m token context window'una at gitsin" yaklaşımı sonuçta tam da 'token başına ücretlendirme' iş modeline cuk oturan bir çerçeve
Son zamanlarda düşündüğüm fikir, birden fazla commit taslağını en baştan AI'ın üretmesi, ardından bu sonuçların insan tarafından doğrudan ya da otomatik biçimde filtrelenip elle inceltilmesi; iş büyüdükçe başlangıçtaki küçük sapmaların tüm sonucu bozma ihtimali artıyor; bu yüzden mevcut SOTA ile bile ajanlara birden fazla seçeneği paralel denetmek, elle refactor etmek için harcanan zamanı azaltıyor; ilgili süreç hakkında GitHub'da yazmıştım
Bunun bir abonelik hizmeti olup olmadığını sormak istiyorum
İnsanların çok aşamalı workflow'larında genellikle doğrulama checkpoint'leri olur, çünkü insanlar da %99'dan fazla doğru değildir; gelecekte ajanlar da çıktıları için doğrulama süreçleriyle tasarlanacak ve bir sonraki aşamaya geçmeden önce bu süreçten geçecek şekilde eğitilecek; önceden "şu kısımda en az %99 doğruluk gerekiyor" gibi risk düzeyi değerlendirmeleri de yapılabilir
Claude Code, her adımda ilerlemeden önce durup kullanıcıya devam etmek isteyip istemediğini soruyor ve önerilen değişiklikleri de önceden gösteriyor; token israfını ve verimsiz çalışmayı engellemede etkili
Pek çok uygulamanın da bu yapıya uyacak şekilde yeniden tasarlanması gerekecek; bence mikroservis mimarisi LLM'lerle iyi anlaşıyor, bu yüzden yeniden popüler olabilir
"Asıl sorun AI'ın yeteneği değil, ajanların gerçekten etkili kullanabileceği araçları ve geri bildirim sistemlerini tasarlamak" görüşüne katılıyorum; pazarın buna nasıl tepki vereceğinden emin olmadığım için sadece uzaktan takip ederken, ajan geliştirmeye odaklanan çok küçük bir startup'a katıldım; 5 ay içinde şüphecilikten kabule, oradan da iknaya geçtim; konu alanını çok dar tuttuğunuzda ve modelin çalışması için gerekli tooling'e odaklandığınızda yüksek tamamlama oranları gördüm; deterministik olmamasından hoşlanmama eğilimi var ama iyi tooling ve giderek daralan kapsamla pratikte oldukça kullanışlı olabiliyor; tooling'in kendisi zor hissettirse de makul şekilde çözülebileceğini düşünüyorum; gelecek konusunda iyimserim
Bence bunların hepsi çözülebilir problemler; sadece hızlı ARR toplama yarışı yüzünden birçok startup bunlara odaklanmıyor; ajanların vaat edildiği kadar kullanışlı olmadığı görüşünde haklı yanlar var ama bu aslında bir mühendislik problemi; farklı bir açıdan yaklaşırsak çalışacağını düşünüyorum (kişisel olarak RL tarafına daha yakınım); örneğin iyi bir verifier gerekir; birçok işte doğrulama, işi yapmaktan daha kolaydır; %80 doğrulukta 5 paralel üretim bile olsa, bunlardan en az birinin doğru çıkma olasılığı %99.96 eder ve verifier bunu seçebilir; çok adımlı durumlarda da matematiksel olarak avantajlı hâle gelir; bu şimdiye kadarkinden farklı bir yaklaşım, yazıda da 3-5 aşamalı workflow paradigmasından söz ediliyor ve bu gerçekten iyi oturuyor; ileride böyle daha fazla model görmemiz gerekir
Birçok görevde doğrulamanın aslında işin kendisinden daha zor olmadığına dair argümana dair bir görüşüm var; özellikle yazılım QA sahasında bu mantıkla sık sık yeniden yapılanmalar yapıldı ve sonuçta kalitenin düştüğünü düşünüyorum; verifier için sistemin ve dış dünyanın olası durum kombinasyonlarının sayısı geometrik olarak artıyor, bu da işi çok zorlaştırıyor; LLM'ler böyle karmaşık çalışma ortamlarında bağımlılıkları mock'lamak ya da veriyi önceden doldurmak gibi tekrar eden angaryaları üstlenmek açısından cazip, ama doğrulama testinin anlamlı olabilmesi için her zaman %100 doğru olması şartı geliyor ve sonunda her önkoşul için bir verifier daha gerekiyor; sonuçta her aşama %100 olmak zorundaysa toplam olasılık giderek düşüyor; insanlar çoğunlukla belirli vakaları dikkatle test eder ama tüm olasılıkları eksiksiz doğrulamaz (white-box test, black-box testten çok daha yaygındır); LLM çok fazla kod üretirse çalışan kişinin white-box doğrulama yapabilmesi için tüm kodu anlaması gerekir, bu da kazanılan zamanı geri alır; şu an için LLM üretiyor ve hataları da sonunda benim tek tek düzeltmem gerekiyor, bu yüzden hem özgüvenim azalıyor hem daha çok zaman gidiyor; bazı durumlarda arayüzü LLM'in beklentilerine göre şekillendirerek çözmek mümkün ama bu genel geçer değil; yazılımın dışına çıkınca doğrulama çoğu zaman zaten imkânsız hâle geliyor (örneğin "en umut verici 5 oyun startup'ını seç" gibi bir işte nesnel doğrulama yok); böyle alanları da doğrudan insana değil makineye bırakmak toparlanamaz sonuçlar doğurabilir
Beş üretimin birbirinden bağımsız olacağını varsaymak doğru mu diye merak ediyorum
Doğru, birden çok ajanın denemesi, tekrar tekrar çalıştırmak ve farklı çözümler uygulamak pratikte etkili oluyor; gerçekten de bir yöntemde olumsuz geri bildirim alıp başka bir yaklaşımla başarıya ulaşılan örnekler gördüm
Tek bir kişinin (ya da çok küçük bir ekibin) geliştirme, DevOps, data operations gibi alanlarda gerçek üretimde çalışan 12'den fazla AI ajanı yapmış olması şaşırtıcı; startup başarısızlık oranlarına bakınca "bir" iyi ürün yapmak bile zor, 12 tane yapmış olmak hayret verici; biz de Definite gibi data stack + AI agent araçları üzerinde çalışıyoruz ve 2 yılın ardından ancak 6 ay önce iyi bir noktaya geldik, Definite
Aslında 12 bağımsız ürün değil; ihtiyaç oldukça iş yerinde kullanılan, çok spesifik amaçlı 12 araç yapıldığı kastediliyor; yazının genel teması gibi, işe yarayan ajanlar için yalnızca çok basit ve net hedeflere odaklanmak gerekiyor
Tam zamanlı bir işte 3 yıl çalışırken 12'den fazla şey üretmiş olmak kulağa biraz tuhaf geliyor
Benim işim de ajan/AI otomasyonu geliştirmek; açık uçlu coding agent fikri düpedüz kötü bir fikir; insan doğrulama checkpoint'leri, küçük arama uzayı, çok spesifik soru/prompt'lar (ör. bu e-postada fatura var mı YES/NO) gerçekçi olan bunlar; tamamen otomatik ajan isteme arzusunu anlıyorum ama teknoloji henüz orada değil; ben içerik üretimine (metin, görsel, kod) bulaşmıyorum, çünkü onlar sonunda mutlaka sorun çıkaracak
Ben de ajan framework'leriyle birlikte chat coding kullanarak iş yükümün yaklaşık %50'sini azalttım, GPT ile gerçek fayda gördüm; ama 10 denemede 1 kez mutlaka hata çıkıyor; LLM mimarisi temelden değişmezse bu hata oranının düzelmeyeceğini düşünüyorum; şu anda hype yüzünden geliştirici güveni tamamen yıkılmazsa ileride çok daha sağlam sistemlerin çıkacağından eminim; üretkenlik artışı o kadar belirgin ki artık ekip arkadaşı alımını eskisine göre çok daha az yapabiliyoruz; farklı konulardaki öğrenme eğrisi de, Google arama kalitesindeki düşüşü LLM'in telafi etmesi sayesinde dramatik biçimde azaldı; otomatik workflow'larda insan işinin bir kısmını LLM'e devreden orchestration framework en kritik yapı; LLM'in kendi güven düzeyini de raporlaması ve confidence % düşükse doğrudan insana devretmesi gerekir; testler ve guardrail'ler düzgün olursa, çekirdek olmayan işlerde insanın yerini alma potansiyeli yeterince var; burada amaç insanı tamamen değiştirmek değil, işin otomasyonu sayesinde ekip boyutunu küçültmek; örnek olarak büyük e-ticarette ürün açıklamaları, görsel doğrulama, yazım hataları, görsel uyumsuzlukları gibi daha önce insanların yaptığı işleri LLM'in üstleneceği güne inanıyorum
Genel olarak katılıyorum ama bu şekilde yaklaşınca elde kalan şey "sadece pahalı bir workflow sistemi" olabilir; geçmiş teknolojilerle de yapılabilecek işleri ille de LLM'le yapmanın gereği var mı diye düşünüyorum
Ben de katılıyorum; şu an için ajanların tam oturduğu yer "dar kapsamlı, düşük riskli, yüksek tekrar içeren sıkıcı işler"; örnek olarak dev-log markdown yardımcı işlerinde ajan kullandığım deneyimi buraya yazmıştım
İnsan doğrulamasının checkpoint oluşturmak için en güvenilir yöntem olduğu doğru, ama unit test, sistem genelinde geçici doğrulama (ad-hoc validation) gibi başka yöntemler de var
Bence aslında yazar, özerk ajanlar konusunda şu ankinden daha da iyimser olmalı; bugün yapılanların %90'ı 2024'ün başında imkânsızdı; ilerleme eğrisini küçümsememek gerekir
Ben de aynı fikirdeyim, ilgili bir blog yazısı var; temel fark şu: HITL (Human in the loop) hataları azaltıyor, ama HOTL (Human out of the loop) aksine sorun üretiyor