Yapay Zekâ Kullanmak Kolay, Ona İş Teslim Ettirmek Zor

Bir yapay zekâ modelinden cevap almak birkaç saniye sürüyor. Peki ona bir iş verip arkanıza yaslanmak neden hâlâ bu kadar zor?

Bu yazıya ilham veren videoyu izlerken uzun uzun not aldım. Videonun üreticisi, yaklaşık üç yıllık yoğun kullanımının 10.000 saate yaklaştığını tahmin ediyor. Bunun kronometreyle doğrulanmış bir ölçüm değil, kişisel bir tahmin olduğunu baştan söyleyelim. Paylaşılan milyarlarca tokenlık kullanım verileri de tek başına uzmanlık kanıtı sayılmaz. Benim asıl ilgimi çeken rakamlar değil, bu kadar yoğun kullanımın sonunda ortaya çıkan dersler oldu.

Çünkü modelleri yalnızca arada sırada soru sormak için kullanan biriyle, onlara uzun süreli ve paralel işler veren biri aynı problemlerle karşılaşmıyor. İlkinde iyi bir cevap yeterli olabilir. İkincisinde ise modelin saatler sonra hâlâ doğru yönde ilerlemesi, hatasını fark etmesi ve yaptığı işi kanıtlayabilmesi gerekir.

İlk dönemde soru genellikle “Hangi model daha zeki?” oluyor. Kullanım yoğunlaştıkça soru değişiyor: Model neyi görecek, neyi hatırlayacak, yaptığı işi nasıl doğrulayacak, hata aldığında nereden devam edecek ve hangi noktada duracak?

Yapay zekâ kullanmak, modelden bir çıktı almaktır. Yapay zekâya iş teslim etmek ise çıktının doğruluğunu şansa bırakmadan sonuç alabileceğiniz bir sistem kurmaktır.

Ben bu uzun anlatıdan yedi temel ders çıkardım. Şimdi bunları bir araç listesi veya kopyalanacak promptlar olarak değil, kendi çalışma sisteminize uyarlayabileceğiniz basit ilkeler hâlinde anlatacağım.

1. Asıl fark modelde değil, modelin etrafındaki sistemde

İlk dersimizle başlayalım: Yeni bir model çıktığında hemen ona geçmek zorunda değilsiniz. Benchmark puanı daha yüksek diye mevcut çalışma biçiminizi bırakıp her şeyi yeni modele taşıdığınızda birkaç hafta sonra aynı sorunlarla yeniden karşılaşabilirsiniz. Model eksik bilgiyle karar verir, önceki tercihlerinizi bilmez, yaptığı işi yeterince kontrol etmez veya ne zaman durması gerektiğini anlayamaz.

Çünkü model yalnızca sistemin bir parçası. Gerçek sonuç en az dört bileşenin birlikte çalışmasına bağlı:

• Bağlam: Model karar verirken hangi bilgiye erişiyor?
• Hafıza: Önceki kararlar ve öğrenilen dersler nasıl korunuyor?
• Doğrulama: Çıktının doğru olduğu neyle kanıtlanıyor?
• Çalışma sistemi: Görev nasıl başlıyor, ilerliyor, duruyor ve yeniden devam ediyor?

Daha güçlü model bu parçaların kapasitesini artırabilir; fakat eksik olan parçaları kendiliğinden oluşturmaz. Hedef yanlışsa daha hızlı yanlış yöne gider. Bağlam kötüyse daha ikna edici bir hata üretir. Doğrulama yoksa yaptığı işin kalitesi hâlâ insanın dikkatine bağlı kalır.

Bu nedenle model değiştirmeden önce aynı modelle kullandığınız sistemi geliştirmek çoğu zaman daha büyük kazanç sağlar. Modeli tanıdıkça hangi görevlerde iyi olduğunu, nerede fazla özgür davrandığını, nerede talimata körü körüne uyduğunu ve hangi çıktısının ikinci bir göz gerektirdiğini öğrenirsiniz. Bu kalibrasyonu her model değişiminde yeniden ödersiniz.

2. Genel benchmark yerine kendi gerçek görevlerinizi ölçün

İkinci derste benchmarklarla aramıza sağlıklı bir mesafe koyacağız. Benchmarklar bir modeli ilk kez değerlendirirken yararlıdır. Çok zayıf bir modeli erkenden elemenizi veya belirli bir alandaki ilerlemeyi görmenizi sağlar. Fakat laboratuvar skoru, modelin sizin işinizde en iyi seçenek olduğunu kanıtlamaz.

Bir yazılımcının ihtiyacı yalnızca test geçen kod olmayabilir. Mevcut mimariye uyum, okunabilirlik, güvenlik, gereksiz değişiklik yapmama ve doğru dosyalara dokunma da önemlidir. İçerik üreticisi için akıcılık kadar kaynak doğruluğu, tekrar oranı ve editoryal ton önem taşır. Her mesleğin kabul edilebilir iş tanımı farklıdır.

Burada size basit bir yöntem önereyim: Küçük bir kişisel eval seti kurun. Her hafta gerçekten yaptığınız işlerden 10–20 örnek seçin ve modelleri aynı koşullarda karşılaştırın:

Böyle bir eval seti kurduğunuzda model yarışını izlemek yerine kendi üretim sisteminizi yönetmeye başlarsınız. Yeni model çıktığında bütün düzeninizi bozmaz, önce gerçek görevleriniz üzerinde sınarsınız.

3. Ucuz token, ucuz sonuç anlamına gelmez

Üçüncü ders maliyet hesabıyla ilgili. Model fiyatlarını karşılaştırırken çoğunlukla bir milyon tokenın ücretine bakıyoruz. Oysa satın almak istediğimiz şey token değil, tamamlanmış iş. Daha ucuz model aynı görevi üç kez deniyor, daha fazla yönlendirme istiyor ve sonunda insan tarafından yeniden yazılıyorsa gerçek maliyeti daha yüksek olabilir.

Bir yapay zekâ görevinin maliyetini şöyle düşünmek daha doğru:

Gerçek maliyet =
model ve araç maliyeti
+ insanın brief süresi
+ takip ve doğrulama süresi
+ başarısız denemeler
+ hatalı çıktının oluşturduğu risk

Aynı nedenle en yüksek düşünme seviyesini her görevde açmak da verimli değildir. Basit bir biçimlendirme işiyle üretim veritabanına dokunan bir migrasyon aynı miktarda akıl yürütme, kontrol ve model çeşitliliği gerektirmez. Daha fazla düşünme bazen yalnızca cevabı yavaşlatır, bağlam önbelleğini bozar ve modelin basit problemi gereksiz yere büyütmesine yol açar.

Doğru yaklaşım, eforu görevin riskine göre ayarlamaktır. Geri döndürülebilir ve kolay ölçülen işlerde hızlı model yeterli olabilir. Para, güvenlik, kişisel veri veya üretim sistemi söz konusuysa daha güçlü model, bağımsız denetçi ve birden fazla doğrulama turu anlamlı hâle gelir.

4. Bağlam ve hafıza birer prompt değil, altyapıdır

Dördüncü ders bağlam ve hafıza üzerine. Önce şu basit gerçeği kabul edelim: İyi bir model bile bilmediği proje kararlarını tahmin etmek zorunda kalır. Kullanıcı tercihleri, mimari sınırlar, daha önce denenmiş çözümler ve bilinen hatalar yalnızca sizin kafanızda duruyorsa her yeni oturum aynı keşfi tekrarlar.

Bu bilgi modelin düzenli okuyabileceği yerlere taşınmalıdır: proje notları, karar kayıtları, testler, talimat dosyaları, issue’lar, commit geçmişi veya kontrollü bir hafıza sistemi. Böylece model veya kullandığınız araç değişse bile biriktirdiğiniz çalışma bilgisi kaybolmaz.

Fakat daha fazla bağlam her zaman daha iyi değildir. Eski kararlar, çelişkili talimatlar ve ilgisiz dosyalar modelin dikkatini dağıtabilir. Bağlamı dört filtreden geçirmek yararlıdır:

1. Otorite: Bu bilgi kimden veya hangi kaynaktan geliyor?
2. Güncellik: Hâlâ geçerli mi?
3. İlgi: Mevcut görev için gerçekten gerekli mi?
4. Yoğunluk: Modelin karar verebilmesi için ne kadar ayrıntı yeterli?

Uzayan ve defalarca yön değiştiren oturumlarda bağlam zehirlenebilir. Model aynı başarısız yaklaşımın etrafında dönmeye başladığında daha fazla düzeltme istemek yerine elde edilen dersleri kısa bir rapora çevirip temiz bir oturum açmak daha etkili olabilir.

Hafıza her şeyi saklamak değil, bir sonraki doğru karar için gerekli olanı erişilebilir tutmaktır.

5. Üretim hızlandıkça doğrulama asıl darboğaza dönüşür

Beşinci ders bence yazının en önemli noktalarından biri: Üretim hızlandıkça doğrulama asıl darboğaza dönüşür. Bir ajan bir saat içinde insanın günlerce yazacağı kadar kod üretebilir. Fakat aynı işi sizin satır satır kontrol etmeniz gerekiyorsa toplam sistem hızlanmış sayılmaz. Üretim ucuzlarken güvenilir doğrulama kıt kaynak hâline gelir.

İlk kural, üreten ajanın kendi işinin tek denetleyicisi olmamasıdır. Aynı modeli bile temiz bir bağlamda yalnızca hata bulma göreviyle çalıştırmak farklı sonuç verir. Üretici “işi tamamla” hedefiyle, denetçi ise “hangi koşulda başarısız olur?” hedefiyle bakar.

İkinci kural, mümkün olan her yerde model görüşünü deterministik kanıtla desteklemektir:

• Kod için testler, type-check, lint, build ve güvenlik taraması
• Arayüz için uygulamayı gerçekten kullanma ve görsel kontrol
• Veri işi için satır sayıları, toplamlar ve şema doğrulamaları
• İçerik için kaynak kontrolü, kelime sayısı ve kırık bağlantı taraması
• Geri dönüşü zor eylemler için insan onayı

Başarı tanımı işe başlamadan önce verilmelidir. “Bu özelliği yap” yerine hangi testlerin geçeceği, hangi alanların değişmeyeceği ve sonucun nasıl kanıtlanacağı belirtilmelidir. Böylece ajan yalnızca iş yaptığını söylemez; teslim koşullarını geçtiğini gösterir.

6. Uzun görevlerde küçük hata farkları devasa sonuçlar üretir

Altıncı derste küçük hata oranlarının neden küçümsenmemesi gerektiğini öğreneceğiz. Kısa görevlerde iki model arasındaki güvenilirlik farkı önemsiz görünebilir. Ancak ajan yüzlerce veya binlerce adımdan oluşan bir işi gece boyunca yürüttüğünde her adım bir sonraki adımın temelini oluşturur.

Şimdi bunu küçük bir hesapla birlikte görelim. Bir ajanın her adımda doğru karar verme ihtimali yüzde 99,99 olsun. Bu oran ilk bakışta kusursuza yakın görünüyor. Fakat görev 1.000 adımdan oluştuğunda bütün adımların hatasız tamamlanma ihtimali yaklaşık yüzde 90,5’e düşer. Adım başına başarıyı yalnızca yüzde 99,9’a indirdiğimizde ise temiz koşu ihtimali yaklaşık yüzde 36,8 olur.

0,9999¹⁰⁰⁰ ≈ %90,5
0,999¹⁰⁰⁰  ≈ %36,8

Buradaki dersi netleştirelim: Tek bir adımda yalnızca yüzde 0,09 gibi görünen fark, uzun görevde başarılı koşu ihtimalini üçte bire yaklaştırıyor. Bu nedenle uzun süre çalışan ajanlarda yalnızca zeki bir model seçmek yetmez; hatayı erken yakalayan ve güvenli noktaya dönebilen bir sistem kurmanız gerekir.

Görev görünür ve devam edilebilir biçimde tasarlanmalıdır:

• Küçük ve anlamlı checkpoint’ler oluşturun.
• Çalışan kodu düzenli commit’lerle koruyun.
• Yapılanları, kalanları ve başarısız denemeleri kaydedin.
• Token, süre ve yeniden deneme bütçesi belirleyin.
• Hata geldiğinde en son güvenilir noktaya dönebilmeyi sağlayın.
• Yetkileri kanıtlanan güvenilirliğe göre kademeli olarak artırın.

Bir ajanı otonomlaştırmak ona ilk günden bütün sistemi teslim etmek değildir. Önce okuma, sonra sınırlı yazma, ardından güvenli otomasyon ve en son yalnızca kanıtlanmış alanlarda daha geniş yetki verilmelidir.

7. Paralellik agent sayısı değil, bağımlılık tasarımıdır

Yedinci ve son dersimiz paralellik üzerine. Burada en sık yapılan yanılgıyı baştan düzeltelim: On ajan çalıştırmak işi otomatik olarak on kat hızlandırmaz. Aynı dosyalara ve aynı özelliğe dokunan ajanlar birbirlerinin varsayımlarını bozabilir. Sonuç; merge çatışmaları, tekrar edilen araştırmalar ve düzeltilmesi gereken daha fazla hata olabilir.

En güvenli paralellik alanlarından biri keşiftir. Birden fazla ajan kodu, kaynakları veya olası çözümleri yalnızca okuyarak inceleyebilir. Ardından tek bir sentezci çelişkileri bulur, kanıtları birleştirir ve uygulama planını çıkarır. Uygulama paralelleştirilecekse işler bağımlılık grafiğine göre birbirinden gerçekten bağımsız alanlara ayrılmalıdır.

Zayıf paralellik:
10 ajan → aynı alan → çatışan değişiklikler

Güçlü paralellik:
keşif ajanları → ortak kanıt → sentezci
                              ↓
                 bağımsız uygulama alanları
                              ↓
                    test ve entegrasyon

Aynı mantık tekrar eden işler için de geçerlidir. Her gün aynı promptu yazıyor, aynı dosyaları gösteriyor ve aynı kontrolleri istiyorsanız bu iş otomasyonu hak etmiştir. Talimatı bir skill’e, komuta, teste veya pipeline’a dönüştürmek modelin her seferinde sıfırdan yönlendirilmesini engeller.

Buradaki amaç çok sayıda ajan çalıştırmak değil, insanı tekrarlanan koordinasyon işinden çıkarmaktır. İnsan hedefi, kalite eşiğini ve sınırları belirler; sistem keşif, üretim, doğrulama ve raporlama döngüsünü yürütür.

Yarın uygulamak için kısa bir başlangıç

Şimdi bu yedi dersi pratiğe çevirelim. Bütün sistemi bir günde kurmanız gerekmiyor. Gerçek işinizden tek bir tekrar eden görev seçin ve şu sırayla ilerleyin:

1. İşin bittiğini gösteren ölçülebilir sonucu yazın.
2. Modelin ihtiyaç duyduğu güncel bağlamı tek yerde toplayın.
3. Üç gerçek örnekten küçük bir eval seti oluşturun.
4. Çıktıyı kontrol edecek test veya bağımsız denetçi ekleyin.
5. Bir hata tekrarlandığında onu kalıcı kurala ya da teste dönüştürün.
6. Ancak akış güvenilir hâle geldikten sonra otomatik ve paralel çalıştırın.

Bu yaklaşımın amacı mükemmel promptu bulmak değildir. Her çalışmada biraz daha güvenilir hâle gelen bir üretim sistemi kurmaktır.

Son söz

Yeni modelleri denemek yanlış değil. Modeller arasındaki gerçek kapasite farkları bazen büyük olabilir. Fakat sürdürülebilir avantaj, her yeni model duyurusunda bütün düzeni değiştirmekten gelmez. Modelden bağımsız olarak taşıyabileceğiniz bağlam, eval, hafıza, doğrulama ve çalışma sistemi kurmaktan gelir.

Benim videodan çıkardığım en önemli sonuç şu: Yapay zekâ çağının güçlü kullanıcısı en uzun promptu yazan veya en fazla token harcayan kişi olmayacak. Hedefi tanımlayabilen, doğru bağlamı sağlayan, çıktıyı kanıtlayan ve her hatayı sistemin bir sonraki sürümüne dönüştüren kişi olacak.

Geleceğin farkı yapay zekâyı kullanabilmek değil, ona güvenilir biçimde iş teslim edebilmek olacak.

Kaynak

• YouTube — Yoğun yapay zekâ kullanımından çıkarılan dersler