Kod yazma ve okuma devri bitti dedik.

Peki testler ne olacak?

İyi niyet taşıyarak ajanların her kod parçası için test yazmaya başlamaları çok büyük problemlerin habercisi olabilir.

Bunlar:

– CI/CD süreçlerinin uzaması.

– Ajanların kapsama alanı geniş (code coverage) testleri her defasında okumalarının gereksiz token harcamalarını tetiklemesi.

– Testlerin mevcut implementasyona çok sıkı bağlanarak refactoring’i zorlaştırması.

– Ajanın kodu değiştirdikten sonra asıl problemi çözmek yerine yüzlerce kırılan testi tamir etmekle uğraşması.

Çözüm ne olabilir?

Sadece E2E testleri yeterli mi? Birim testlerini silebilir miyiz?

Sadece E2E testleri uçtan uca senaryoları test ederler. Bu testlerin kırılmaları problemin nerede olduğunu doğrudan göstermez. Bu yüzden ince ayar yapabilen birim testlerine de ihtiyacımız vardır.

Her ikisine de ihtiyacımız var, ama testin sağladığı değer ile maliyeti — özellikle CI süresi ve token tüketimi — arasında bir denge kurulması gerekiyor.

“Ne kadar çok testimiz var?” ya da “Code coverage ne kadar yüksek?” yerine şu soruyu sormamız gerekiyor:

Bu test hangi sistem gerçeğini koruyor?

Burada “invariant” kavramı devreye giriyor.

Invariant, sistem içerisinde hangi değişiklik yapılırsa yapılsın doğru kalması gereken bir kuraldır.

Örneğin bir ödeme sisteminde:

Yapılan iadelerin toplamı, müşteriden tahsil edilen miktardan hiçbir zaman fazla olamaz.

Bu bir invariant’tır.

Ajan bütün sistemi refactor edebilir.

Ama sonunda bu kural hala geçerli olmak zorundadır.

İşte testin görevi burada değişiyor.

Test artık ajana:

“PaymentRepository.save() metodunu çağırmadın.”

demek yerine:

“PAYMENT-001 invariant’ını ihlal ettin. 100 TL tahsil edildi ama sistem 120 TL iade yapılmasına izin verdi.”

demelidir.

İki hata mesajı arasında çok büyük bir fark var.

Birincisi implementasyonu koruyor.

İkincisi sistemin doğrusunu koruyor.

Bu bakış açısıyla testler, mevcut kodu donduran mekanizmalar olmaktan çıkıp ajanlara sınırları gösteren sensörlere dönüşüyorlar.

Ajan istediği kadar refactoring yapabilir, sınıfları bölebilir, birleştirebilir, mimariyi değiştirebilir.

Ama invariant’ları ihlal edemez.

Böylece yapay zeka ajanına iki şeyi aynı anda vermiş oluyoruz:

Özgürlük ve sınır.

Özgürlük implementasyonda.

Sınır ise sistemin değişmez doğrularında.

Bu yüzden gelecekte önemli olanın %90 ya da %100 code coverage olacağını düşünmüyorum.

Daha önemli bir soru var:

İşletmemiz ve uygulamamız için kritik olan gerçeklerin yüzde kaçını invariant olarak tanımladık ve bunların yüzde kaçını otomatik olarak doğrulayabiliyoruz?

Belki de yeni metriğimiz “Code Coverage” değil, “Invariant Coverage” olmalı.

Amaç, mümkün olan en düşük maliyetle ajana mümkün olan en yüksek kalitede geri bildirim vermektir.

Bizim yazılımcı olarak görevimiz ajanları doğru yönlendirebilmek. Bunun için kodun nasıl yazılması gerektiğine dair fikir beyanı yani sıra ınvariantlar kullanarak sistem spesifikasyonunu iyi tanımlamamız gerekiyor.