"Disiplin ölçeklenmez": Effect'in yaratıcısı, ajan çağında neden korkuluk gerektiğini anlattı

Disiplin ölçeklenmez

Effect’in ne olduğunu Effect 4.0 yazımızda anlatmıştık: Hataları, yeniden denemeleri ve bağımlılıkları TypeScript’in tip sistemine taşıyan bir kütüphane. Bu kez Syntax, kütüphaneyi yazan Michael Arnaldi’yi konuk etti ve ona “Bizi ikna et” dedi.

Arnaldi’nin çıkış noktası tanıdık bir his. Her proje temiz başlıyor, birkaç ay sonra dağınık bitiyor. Gereksinimler baştan belli değil. Üretimde uç durumlar çıkıyor. Biri “yavaş” diyor, sen nedenini bilmiyorsun. Ona göre yazılımın iyi bir yere evrilmesi için tek gereken özellik şu: Kodu her zaman rahatça yeniden düzenleyebilmek (refactor).

Bunu da disipline bırakamazsın. Arnaldi, Effect’i Vercel’de savunan bir arkadaşının sözünü aktarıyor: Disiplin ölçeklenmez. Tek kişi disiplinli olabilir, ama ekip büyüdükçe iş dağılır.

Ajanlar için daha da geçerli

Bölümün en çok akılda kalan cümlesi bu: İnsanı uzun süre disiplinli tutamıyorsan, bir yapay zekâyı bağlam penceresinin ötesinde disiplinli tutma şansın yok.

Wes Bos tanıdık bir sorunu anlatıyor. Ajan yeni bir durum gördüğünde fonksiyonu kopyalıyor ya da araya bir if daha ekliyor. Altı ay sonra kod, üst üste dizilmiş bir iskambil kulesine dönüyor. Arnaldi’ye göre Effect bunu tek başına çözmüyor ama zemin sağlıyor. Tipler daha çok şey anlattığı için üstüne kendi kurallarını yazabiliyorsun. Önerdiği akış da basit: Kötü bir kalıp görünce ajana “bunu yapma, bunun için bir lint kuralı yaz” diyorsun.

Bir teknik ayrıntı da var. Normal bir Promise oluşturulduğu anda çalışmaya başlar. Onu kodda başka bir yere taşırsan, iş daha erken başlayabilir ve yeni bir hata doğabilir. Bir Effect ise sen çalıştırana kadar sadece bir tarif. Yerini değiştirmek davranışı değiştirmiyor. Bu da yeniden düzenlemeyi hem sana hem ajana kolaylaştırıyor.

Sıfır bağımlılık: Postgres sürücüsünü kendileri yazdılar

Effect 4’te ana paketin hiç çalışma zamanı bağımlılığı yok. Arnaldi’ye göre bir paketi kullanmak, o paketin geçmişte verdiği bütün kararları da satın almak demek. Örnek olarak Postgres bağlantısını veriyor. Önce bir sürücüye, sonra başkasına dayandılar. İkisinde de hatalar çıktı, sorgu ardışıklama (pipelining) işlemleri bozdu. Sonunda sürücüyü spesifikasyona göre kendileri yazdılar. Arnaldi’nin anlattığına göre bu, yapay zekâ ile üç gün sürdü.

Bunun bir de güvenlik tarafı var. Her bağımlılık, LiteLLM’de gördüğümüz türden bir tedarik zinciri saldırısı için yeni bir kapı. Yine de Arnaldi kesin bir kural koymuyor. Bir paketten gerçekten değer alıyorsan kullan, diyor. Kütüphanenin sadece küçük bir parçasına ihtiyacın varsa ve kendi yazacağın kodun doğru çalıştığından emin olabiliyorsan, kendin yaz.

Paket boyutundaki küçülme ise hafif Micro modülünden doğdu. Arnaldi’nin yorumu ilginç: Ona göre bu, yaptıkları en gereksiz optimizasyondu.

Kendiliğinden gözlemlenebilir kod

Arnaldi, Effect’ten önce bir projeye elle izleme (tracing) eklemeye çalıştığını anlatıyor. Kod öyle karıştı ki sonunda izlemeyi geri söktü.

Ona göre doğru yaklaşım şu: Bir fonksiyon yazdığında, ondan otomatik olarak bir izleme kaydı (span) çıkmalı. Hata ayıklarken “keşke şuraya log koysaydım” demek zorunda kalmamalısın. Bunun ajanlara da faydası var. Arnaldi’ye göre ajanlar izleme verisiyle çok iyi çalışıyor: “Şu yavaş, hızlandır” deyip veriyi verdiğinde ellerinden geleni yapıyorlar. Anlattığına göre OpenCode da kod tabanını Effect’e taşıdı ve izleme verisini yerelde toplayıp ajanın kullanımına açıyor. Sentry’nin de Effect için alfa aşamasında bir SDK’sı var.

Eski fikirler: Effect Cluster ve dayanıklı iş akışları

Arnaldi’nin en heyecanlı olduğu kısım ise az konuşulan Effect Cluster. Fikir yeni değil, Erlang’dan geliyor. Ericsson’un telefon santralleri için geliştirdiği bu modelde, işi yapan parçalar (aktörler) bellek paylaşmıyor, birbirlerine mesaj gönderiyor. Arnaldi bunun ajanlar için de ideal bir model olduğunu söylüyor, çünkü ajanlar da mesajla konuştuğun bağımsız birimler.

Bunun yanında Effect Workflow geliştiriliyor. İki ayrı sisteme istek attığında, ikisini tek bir veritabanı işlemine (transaction) bağlayamazsın. Biri başarılı olur, diğeri yarıda kalabilir. Dayanıklı iş akışları (durable workflows) bu sorunu, her adımı kaydedip yarıda kalınca kaldığı yerden devam ederek çözüyor. Aynı fikrin Postgres içindeki bir örneğini pg_durable yazısında anlatmıştık. Ama dikkat: Arnaldi açıkça söylüyor, bu kısım beta. Üretimde kullanma.

Topluluktan iki proje de öne çıktı: Uygulama durumunu tek yerde tutan arayüz framework’ü Foldkit ve altyapıyı TypeScript ile tanımlatan Alchemy.

Düşün

• Kodunun ne kadarını ajanlar yazıyor? Kalitesini neyle denetliyorsun: kendi gözünle mi, kurallarla mı?
• Projende sadece küçük bir parçasını kullandığın bir bağımlılık var mı? Onu kendin yazmak mı daha riskli, tutmak mı?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.