AI Agent'lar yazılım dünyasını neden değiştiriyor?

Tez#

Kod tamamlama araçları yazılım geliştirmenin hızını artırdı ama doğasını değiştirmedi: girdi belirli, çıktı belirli, test edilebilir. Ajan sistemleri bu sözleşmeyi bozuyor. Bir ajan, aynı girdi için farklı adım dizileri izleyebiliyor; başarı, çıktının bir dizeye eşit olmasıyla değil hedefin sağlanmasıyla tanımlanıyor. Yazılım mühendisliği bu noktada determinist sistem inşasından olasılıksal sistem yönetimine kayıyor.

Bu kayma, ekiplerin en bilindik araçlarını yetersiz bırakıyor. Birim testi, girdi-çıktı eşleşmesi varsayar. Kod incelemesi, davranışın kaynakta okunabilir olduğunu varsayar. Hata ayıklama, aynı girdinin aynı yolu izlediğini varsayar. Ajan sistemlerinde bu üç varsayımın hiçbiri tam olarak geçerli değil.

Bağlam: üç dalga#

Üçüncü dalganın ayırt edici özelliği yetki. Bir sohbet arayüzü yanlış cevap verdiğinde kullanıcı bunu okur ve reddedebilir. Bir ajan yanlış karar verdiğinde eylemi çoktan gerçekleştirmiş olabilir: kaydı güncellemiş, e-postayı göndermiş, dosyayı silmiş olabilir. Hata maliyeti okunabilir bir metinden geri alınamaz bir işleme dönüşüyor.

Kanıt: nerede kırılıyor?#

Saha gözlemlerinde ajan arızaları model kalitesinden çok üç yerde toplanıyor: araç şemasının belirsizliği, uzun oturumlarda kısıtların kaybı ve hata sonrası yeniden planlama eksikliği. Bu üçü de mimari sorun, model sorunu değil.

• Araç şeması belirsizliği: aynı işi yapan iki araç varsa model tutarsız seçer. Çözüm: araç sayısını azaltmak, isimleri ve açıklamaları ayırt edici yazmak.
• Kısıt kaybı: oturumun başında verilen "asla üretim veritabanına yazma" kısıtı, yirmi adım sonra bağlamdan düşebilir. Çözüm: kısıtı istemde tekrar etmek yerine araç katmanında zorlamak.
• Yeniden planlama eksikliği: başarısız adımdan sonra model aynı adımı tekrar dener. Çözüm: hata mesajını yapılandırılmış biçimde geri vermek ve deneme sayısını sınırlamak.
• Doğrulanamaz hedef: "müşteriyi memnun et" gibi bir hedef ölçülemez. Çözüm: hedefi denetlenebilir son duruma çevirmek.

1. 1Hedefi daralt

   Ajanın kapsamını tek bir doğrulanabilir sonuca indir.

2. 2Yetkiyi kıs

   Yalnızca o sonuç için gereken araçları, en dar kapsamda ver.

3. 3Onay kapısı koy

   Geri alınamaz eylemleri insan onayına bağla.

4. 4İzle

   Her araç çağrısını, hedefle ilişkilendirilmiş bir izde kaydet.

5. 5Genişlet

   Tamamlama oranı stabilleşince kapsamı bir adım aç.

Karşı görüş#

Bu analizin karşısında duran iki ciddi iddia var. Birincisi: ajan mimarilerinin çoğu, modeller daha yetenekli hale geldiğinde gereksizleşecek geçici iskeleler. Bu iddianın güçlü bir tarafı var — planlama ve hata kurtarma için yazdığımız kodun bir kısmı gerçekten modelin içine taşınıyor. İkincisi: çok adımlı ajanlar, aynı işi yapan basit ve determinist bir iş akışından hem pahalı hem kırılgan. Bu da çoğu durumda doğru.

Bir işi kurallarla yazabiliyorsanız, ajanla yazmayın. Ajan, kuralların yazılamadığı belirsizlik için bir araçtır.

Bu iki eleştiri, tezi çürütmüyor ama sınırını çiziyor: ajan mimarisi bir varsayılan değil, bir tercih. Girdinin yapısız, adımların duruma bağlı ve kuralların önceden yazılamadığı işlerde kazandırıyor; diğer her yerde gereksiz karmaşıklık üretiyor.

Sonuç#

Yazılım ekipleri için asıl değişim, teslim ettikleri şeyin tanımında. Eskiden bir özellik "çalışıyor" ya da "çalışmıyor"du. Şimdi bir ajan akışı "görevlerin şu kadarını, şu maliyetle, şu yan etki profiliyle tamamlıyor". Bu, kalite güvencesinin istatistiksel bir disipline dönüşmesi demek — ve bu disiplin çoğu ekipte henüz kurulmuş değil.

Ne yapmalı?#

1. 01Bir ajan yazmadan önce gerçek işten alınmış 20 görevi, beklenen son durumuyla yazın.
2. 02Araç sayısını beşin altında tutarak başlayın; her araç için açık bir şema tanımlayın.
3. 03Geri alınamaz her eylemi ya onay kapısına ya da dar kapsamlı bir servis hesabına bağlayın.
4. 04Tamamlama oranını, adım verimliliğini ve yan etki sayısını birlikte raporlayın.
5. 05Aynı işi determinist bir akışla yazmanın maliyetini de hesaplayın; karşılaştırın.