AI tarafından bakımı yapılan bir trading bot, zamanlayıcısı yeşil kalırken 18.000 traceback kaydetti

dev.to'da yayımlanan bir postmortem, gözetimsiz otomasyon çalıştıran herkesin bilmesi gereken bir hata modunu ele alıyor: içindeki program neredeyse her döngüde çökerken, zamanlanmış bir görevin üç haftadan uzun süre her çalışmada başarı bildirmesi. Yazar, Claude Code'un kodu yazıp bakımını yaptığı tek kişilik bir şirket işletiyor; bu koda, Windows Task Scheduler üzerinde çalışan ve bir broker API'sini günün her saati beş dakikada bir yoklayan trading botlar da dahil — hiç kimse gerçek zamanlı izlemiyor.

Zamanlayıcının hiç görmediği hata

Gönderiye göre botlardan birinin zamanlanmış görevi üç haftadan uzun süre her beş dakikalık çalışmada çıkış kodu 0 döndürdü ve zamanlayıcının kendi loglarında başarıdan başka bir şey görünmüyordu. Görevin içinde ise Python süreci, broker API'sinin döndürdüğü ele alınmayan bir kimlik doğrulama hatası nedeniyle neredeyse her döngüde başarısız oluyordu. Dış bir process wrapper'ı bu çökmeleri yakalıyor ve wrapper'ın çalışıp düzgün şekilde çıktığını bildiriyordu — wrapper açısından doğru, bot açısından ise işe yaramaz bir tanımlama. Üç haftalık süre zarfında bot 8.000'den fazla deneme yaptı ve 18.000'den fazla traceback biriktirdi, çünkü birkaç kod yolu yeniden denemeye ve başarısız olmaya devam ediyordu. Bu整个 dönem boyunca kaydedilen tek bir gerçek işlem bile yoktu. Yazar sorunu yalnızca ham log dosyasını doğrudan açarak fark etti; izleme kurulumundaki hiçbir şey bu kontrolü tetiklemedi.

Daha sessiz bir hata: eski verilerden kendinden emin sonuçlar

Gönderi, farklı şekilde seyreden ikinci, daha hafif bir olayı daha anlatıyor. Circuit breaker ile donatılmış — kümülatif paper zarları bir eşiği aştığında tüm pozisyonları zorla kapatan bir mekanizma — bir bot gerçekten tetiklendi. Kapanış doğrudan broker'ın kendi API'sinden teyit edildi, ancak raporlama sisteminin okuduğu işlem geçmişi dosyasına hiç yazılmadı. Yazarın günlük durum raporu — her botun loglarını toplayıp bir AI modeline özetleten bir script — bu nedenle bir pozisyonu, gerçekten kapandıktan günlerce sonra hâlâ açık olarak tarif etmeye devam etti ve botun çökmüş olabileceğini öne sürdü. Bot tam olarak tasarlandığı gibi davranmıştı; özet, eski verileri güncel durum olarak yanlış okuyordu.

Standart izleme kategorileri neden yeşil kaldı

Yazar, zaten bildikleri araçların bu iki sorunu da neden yakalayamayacağını adım adım anlatıyor. Deneyimlerine göre LLM observability ürünleri, bir geliştirici aktif olarak geliştirme yaparken tekil model API çağrılarını izliyor — tek bir prompt'un neden çok pahalıya mal olduğu gibi sorulara uygun — kimsenin bakmadığı bir arka plan işini gözetlemekten çok. Bir iş check-in yapmayı bıraktığında uyarı veren dead-man's-switch servisleri de üç hafta boyunca yeşil görünürdü, çünkü wrapper process hiç durmadan çalışmayı ya da ping atmayı sürdürdü.

Gönderiye göre ortak nokta şu: iki hata da, yalnızca bir sürecin 0 ile çıkıp çıkmadığını ya da bir log'a düz bir stringin düşüp düşmediğini kontrol eden her şeye görünmezdi. İki durumda da dürüst olmayan kod yoktu: wrapper gerçekten çökmedi ve pozisyon bir noktada gerçekten açık olmuştu. Boşluk, işin kabuğunun sağlıklı görünmesi ile işin, varoluş amacını gerçekten yerine getirip getirmesi arasındaydı.

Yazarın çıkarımı

Gönderi dersi şöyle çerçeveliyor: izlerken iyi performans gösteren bir agent ile izlemeyi bıraktığınızda başarısızlıklarını gerçekten fark edeceğiniz agent arasındaki ayrım — bu, yazarın daha önce anlattığı, write erişimi olan bir agent'ın işleri bozduğu ancak farklı bir hata şekliyle seyreden olaylarla ilgili. Uptime izleme bir şeyin canlı olup olmadığını yanıtlar; arka planda çalışan bir agent için ise asıl yararlı soru, yapısı olan işini hâlâ yapıp yapmadığıdır — ki bu, bir HTTP 200 döndürmekten daha katı bir iddiadır. Sonraki adım olarak yazar, gözetimsiz AI agent çalıştıran solo geliştiricilere ve küçük ekiplere yönelik küçük bir izleme katmanı inşa ediyor: schedule-farkındalığı olan ve "process 0 ile çıktı" ile "agent işini yaptı" iddialarını iki farklı iddia olarak ele alıp, process tamamen ölmesini beklemeden aralarındaki boşluğu işaretleyen bir katman. Ayrıca gözetimsiz scraper, bot veya pipeline çalıştıran okurları, bu örüntünün bu iki veri noktasının ötesine genelleşip genelleşmediğini test etmek için kendi "her şey yeşil dedi ama değildi" hikâyelerini paylaşmaya davet ediyorlar.

Neden önemli

AI agent'lar arka plan otomasyonunu yazma ve çalıştırma işini üstlendikçe, geleneksel operasyonlardan devralınan sağlık kontrolleri yanlış şeyi ölçüyor. Bir çıkış kodu bir wrapper'ın sonlandırdığını söyler; bir heartbeat bir sürecin canlı olduğunu söyler; hiçbiri işin yapıldığını söylemez. Çıktısı basit bir yanıt değil de yapılandırılmış kayıtlar olan işler için, önemli olan kontrol sonuç seviyesindedir: beklenen işlem, satır veya dosyaların gerçekten ortaya çıkıp çıkmadığı ve sayıların zamanlamanın ima ettiği şekilde ilerleyip ilerlemediği. Bu postmortem, "iş çalıştı" ile "iş işini yaptı" ifadelerinin tek bir kırmızı bayrak olmadan haftalarca ayrışabileceğinin kompakt bir kanıtı — ve AI ile işletilen bir stack'te, ham logları periyodik olarak elle okumak hâlâ son çare kontrolü.