Hataları Düzelten AI Ajanı: Önce Hatayı Yeniden Üreten Bir Sistem Kurun

Kendi başına hata düzelten bir yapay zeka ajanı tek bir kurala uyduğunda işe yarar: yeniden üretilmeyen hata düzeltilmez. Ajan, hata raporunu bugün başarısız olan bir teste dönüştürür, kodu izole bir branch'te yamalar, hem o testi hem de tüm test paketini yeniden çalıştırır ve her şey yeşile döndüğünde rapor verir. Birleştirme (merge) işlemini yine de bir insan yapar. Hatayı yeniden üretemezse sessiz kalır.

DeepSeek Harness ekibi bu fikri 1 Kasım 2026'da süper-ajan tasarımı üzerine yazdığı bir makaleyle geniş bir kitleye sundu. Bu rehber, o fikri bu hafta içinde kurabileceğiniz bir pipeline'a dönüştürüyor; burada yeniden üretim (repro), ajanınızın oluşturduğu ve terminalden çalıştırdığı bir API testi olarak yazılıyor.

Repro olmadan “ajan, bunu düzelt” neden başarısız olur

Bir kodlama ajanından bir hata raporunu düzeltmesini isterseniz genellikle kendinden emin bir diff alırsınız. Bunun sizin hatanızı mı, uydurduğu bir hatayı mı ya da hiçbir şeyi mi düzelttiğini bilemezsiniz.

Yeniden üretme adımı olmadığında üç şey ters gider:

• Ajan nedenseli tahmin eder. Hata mesajından en olası satırı seçer ve onu düzenler.
• “Düzeltildi”nin tanımı yoktur. Tek kanıt, ajanın kendi özetidir.
• Geriye dönük hatalar (regression) sızar. Paylaşılan bir validator'a yapılan bir yama, bir endpoint'i düzeltirken dört tanesini bozabilir.

Başarısız bir test üçünü de çözer: hatayı sabitler, “bitti” tanımını belirler ve suite'inizde regression kontrolü olarak kalır.

“Sessizce yeniden üret ve düzelt” fikri nereden geliyor?

“Exploring Super-agent Design” başlıklı yazıda DeepSeek Harness ekibi, kendi kullanıcı gruplarından bir politika anlatıyor: biri hata bildirdiğinde bir ajan bunu arka planda yeniden üretmeyi dener. Yalnızca doğrulanmış ve basit bir düzeltmeyle birleştiğinde ses çıkarır. Aksi halde hiçbir şey söylemez.

Makale buna spekülatif yürütme (speculative execution) diyor ve burada yeniden kullanacağınız iki bileşenle birleştiriyor. Worker'lar her görev için izole bir oturum, tam yetkili araçlar ve en güçlü modeli alır ve insanlarla konuşmak yerine bir router'a rapor verir. Watchdog, her worker'ın ilerleyip ilerlemediğini ya da sapıp sapmadığını kontrol eden ayrı bir oturumdur.

Bir uyarı: makale bir mimariyi anlatıyor, yayınlanmış DeepSeek Harness özelliklerini değil. Bunun bir kısmı, yazarların resmi bir DeepSeek ürünü olmadığını söylediği dsh-superagent-prototype adlı prototip bir eklentide bulunuyor. Router ve worker yapısı için süper-ajan nasıl kurulur yazısına bakabilirsiniz.

Beş adımlı hata düzeltme ajanı pipeline'ı

Kendi kendine düzeltme yapan bir ajan her seferinde iki kapılı (gate) aynı döngüyü çalıştırır:

1. Intake (Giriş): raporu, başarısız olan isteği ve aldığı yanıtı topla.
2. Reproduce (Yeniden üret): bildirilen nedenle başarısız olan bir test yaz. Başarısız test yoksa, düzeltme de yok.
3. Fix (Düzelt): kodu izole bir branch ya da worktree üzerinde yama yap.
4. Re-run (Yeniden çalıştır): yeni test geçmeli; mevcut suite de geçmeli.
5. Deliver (Teslim et): kanıtla birlikte bir pull request aç ya da sessiz kal.

Adım 1: Hata raporunu girişte yapılandır

Ajanınız “checkout yine bozuldu” ifadesini yeniden üretemez. Giriş adımına sabit bir biçim verin:

Alanlar eksikse ajan bir kez sorar veya isteği loglardan çeker. RFC 9457 problem details standardına uyan hata gövdeleri işe yarar, çünkü hata türü öngörülebilir bir biçimde gelir.

Adım 2: Hatayı başarısız bir API testi olarak yeniden üret

Burası kapıdır. Ajan, giriş kaydını iki doğrulama içeren bir test senaryosuna dönüştürür — beklenen durum kodu ve yanıtın içermesi gereken bir alan — ve bunu gerçek ortamda çalıştırır. Üç sonuç mümkündür:

• Bildirilen nedenle başarısız olur. Bir repro'nuz var demektir. Devam edin.
• Geçer. Hata, anlatıldığı şekilde yeniden üretilemiyor demektir. Loglayın ve durun.
• Başka bir nedenle başarısız olur (kimlik doğrulama hatası, eksik veri, zaman aşımı). Bu bozuk bir repro'dur, doğrulanmış bir hata değil. Durun.

Yalnızca ilk sonuç düzeltmenin önünü açar. “Sessizce” ifadesinin pratikteki anlamı budur: diğer iki sonuç, kuyruğu inceleyen kişi için bir log kaydı üretir; kullanıcının sohbetine mesaj göndermez.

Repro'yu birim test değil API testi olarak yazın: ajan, kullanıcının kullandığı arayüze vurur, böylece yanlışlıkla farklı bir hatayı yeniden üremez.

Adım 3: Kodu izole bir branch'te düzelt

Repro kırmızıya dönünce worker, kodun kendi kopyasını alır. Bir git worktree en hafif seçenektir: yeni bir branch üzerinde ikinci bir çalışma dizini; böylece ajanın düzenlemeleri asla sizin checkout'unuza dokunmaz. Servisi oradan çalıştırın ve test ortamını oraya yönlendirin.

İki kısıtı sıkı tutun. Düzeltme küçük olmalı: 3 dosya ya da 50 değişen satır gibi bir sınır koyun ve daha büyük olan her şeyi insana rapor edilecek bir vaka olarak değerlendirin. Ve düzeltme repro'yu hedeflemeli: hiçbir refactoring, yeniden adlandırma veya düzenleme yok — çünkü her ek değişiklik, inceleyen kişinin kontrol etmek zorunda olduğu bir şeydir.

Adım 4: Repro'yu ve tüm suite'i yeniden çalıştır

İkinci kapının iki parçası var. Birincisi, ajan 2. adımdaki aynı test senaryosunu hiç değiştirmeden yeniden çalıştırır ve geçmelidir. Ajan bu hedefe ulaşmak için doğrulamaları düzenlediyse düzeltme başarısız sayılır; pipeline'ınız bunu, test dosyasının önce ve sonraki halini karşılaştırarak (diff) yakalar.

İkincisi, mevcut suite yeşil kalmalı. Bir testi yeşile çevirip üçünü kırmızıya düşüren bir düzeltme, 3. adıma geri döner. Döngüye bir zaman sınırı koyun, örneğin 3 deneme ya da 20 dakika, sonra durun ve denenenleri loglayın. Watchdog'un asıl değeri burada ortaya çıkar: aynı satırı düzeltmeye devam eden ya da repro'nun hiç dokunmadığı dosyalara sapıb giden bir worker'ı sonlandırabilir.

Adım 5: Yalnızca doğrulanmış ve basit düzeltmeleri teslim et

Her iki kapı da yeşile döndüğünde ajan, hikâye değil kanıt içeren bir pull request açar: rapor, başarısız çalıştırma, diff ve suite sonuçlarıyla birlikte geçen çalıştırma. İncelemeyi ve birleştirmeyi bir insan yapar. Korumalı branch'ler, ajanın token'ının bir branch push edebileceğini ama asla main içine birleştiremeyeceğini garanti eder. Herhangi bir kapı başarısız olursa raporu bildiren kişi hiçbir şey duymaz; ajan bir log satırı yazar ve yoluna devam eder.

Kendi kendine düzelten bir yapay zeka ajanı için güvenlik önlemleri

İlk insansız çalıştırmadan önce bu bariyerleri koyun:

En kritik olanı kimlik bilgileridir: bir repro API'ye gerçekten vurur, bu yüzden staging ya da tohumlanmış (seeded) yerel veri kullanın.

Kodlama ajanınızın repro'yu Apidog CLI ile oluşturmasına izin verin

2. adım pipeline'ın kalbidir ve Apidog CLI tam olarak bunun için tasarlanmıştır. Kodlama ajanınız (Claude Code, Codex, Cursor ya da OpenCode) test senaryosunu JSON olarak yazar, Apidog projenizde oluşturur ve terminalden çalıştırır. Siz tek bir prompt yazarsınız.

Bir kez kurulum yapın:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # istendiğinde ajanınızı seçin

Ardından ajanınıza hata raporunu ve şu promptu verin:

Here is a bug report for POST /orders in Apidog project <projectId>.
Turn it into an Apidog test case that fails today: assert status 201
and that $.id exists. Run it against staging and confirm it fails for
the reported reason. If it does, fix the handler on a new worktree
branch until the same test passes, run the endpoint's other cases, and
open a PR with both JSON reports. If it doesn't reproduce, stop and log why.

Ajan, payload'u hafızadan üretmez. Şemayı okur, bir kategori bulur, dosyasını doğrular ve ancak ondan sonra senaryoyu oluşturur:

apidog cli-schema get test-case-create
apidog test-case category --project <projectId>
apidog cli-schema validate test-case-create --file repro-orders.json
apidog test-case create --project <projectId> --file repro-orders.json

Yazdığı dosya şöyle görünür (ID'ler sizin projenizden gelir):

{
  "name": "Repro: POST /orders with null coupon returns 500",
  "apiDetailId": 123456,
  "categoryId": 1,
  "method": "post",
  "path": "/orders",
  "parameters": {},
  "commonParameters": {},
  "requestBody": {
    "type": "application/json",
    "data": "{\"items\":[{\"sku\":\"A-100\",\"qty\":1}],\"coupon\":null}"
  },
  "postProcessors": [
    { "type": "assertion", "defaultEnable": true, "enable": true,
      "data": { "name": "status is 201", "subject": "httpCode", "comparison": "equal", "path": "", "value": "201" } },
    { "type": "assertion", "defaultEnable": true, "enable": true,
      "data": { "name": "order id exists", "subject": "responseJson", "comparison": "exists", "path": "$.id" } }
  ]
}

Hatayı kanıtlayan kırmızı çalıştırma şimdi şu şekilde:

apidog run --test-case <caseId> --project <projectId> -e <stagingEnvId> -r cli,json --out-file repro-before

CLI raporlayıcısı, bir 500 üzerinde durum doğrulamasının başarısız olduğunu gösterir ve repro-before.json dosyası apidog-reports/ klasörüne düşer. Düzeltmeden sonra ajan, --out-file repro-after ile aynı komutu çalıştırır ve her iki doğrulama da geçer. Bu iki dosya, pull request'teki kanıttır. 4. adım için endpoint'teki tüm senaryoları çalıştırır, böylece düzeltme komşu bir işlevi sessizce bozamaz:

apidog test-case run --project <projectId> --endpoint <endpointId> -e <stagingEnvId> -r cli,json

Çalıştırmayı Apidog uygulamasında görmek için --upload-report ekleyin. Birleştirmeden sonra repro senaryosu projenizde bir regression testi olarak kalır ve aynı apidog run komutu, bir CI/CD pipeline'ında Apidog CLI çalıştırma yazısında gösterildiği gibi -r junit ile CI'a sızar. Daha fazla kurulum için Apidog CLI ajan iş akışı ve Claude Code'da Apidog CLI yazılarına bakın. Apidog Free 4 kullanıcıya kadar kapsar, böylece ücretli bir plana geçmeden tüm döngüyü deneyebilirsiniz.

SSS

Bir yapay zeka ajanı gerçekten insan olmadan hataları düzeltebilir mi?

Birçok basit hatayı kendi başına yeniden üretebilir, yamalayabilir ve kanıtlayabilir; ancak birleştirme işlemini yapmamalıdır. Birleştirmede bir insan bulundurun ve bunu branch korumasıyla dayatın.

Ajan hatayı yeniden üretemezse ne olur?

Durur ve denediklerini loglar. Yeniden üretemediği bir hata, doğrulayamayacağı bir düzeltmedir; her yama bir tahmin olur. Daha sonra bir insan rapora detay ekler ya da kapatır.

Ajanın testi geçecek şekilde düzenlemesini nasıl engellerim?

Test senaryosu ilk kez başarısız olduğunda bir kopyasını ya da hash'ini kaydedin ve düzeltmeyi kabul etmeden önce karşılaştırın. Test dosyasını, worker'ın düzenleyebileceği yolların dışında tutun.

Bunu kurmak için DeepSeek Harness'a ihtiyacım var mı?

Hayır. Makale bir tasarımı anlatıyor ve prototip eklentisi resmi bir DeepSeek ürünü değil. Shell komutları çalıştırabilen herhangi bir kodlama ajanı işe yarar; buna GitHub Actions içindeki Claude Code da dahildir. Orada denemek isterseniz DeepSeek Harness'ın ne olduğuna bakın.