Critter Stack sürüm günü: AI agent'ları, CI kuyrukları ve Marten bellek sorunu
Jeremy D. Miller, Critter Stack araçlarında bir sürüm gününü baştan sona kayıt altına alıyor: birden fazla repoda Claude agent'ları, GitHub Actions kuyrukları, yerel test gating ve bir müşterinin bildirdiği Marten bellek sorunu. Yazı, AI destekli geliştirmenin getirdiği darboğazları ve bunlara karşı kullandığı frenleri gösteriyor.
Kilit noktalar
- Wolverine'de 46, Marten'de 30 civarı GitHub Actions test workflow'u var; bu yüzden tek bir Wolverine PR'ı yoğun saatlerde runner kuyruğunda iki saati aşabiliyor.
- Miller CI'ı gün içinde tamamen kapattı ve yalnızca NuGet sürümü öncesi kalite kapısı olarak geri açtı; doğrulamanın büyük kısmı yerel CommitGate/PushGate script'lerine taşındı.
- Stoat, ağır stress testlerinden önce çalışan işlerin bitmesini bekleyecek ve CI'ın açık olup olmadığını anlayacak şekilde geliştirildi.
- Müşteriden gelen Marten bellek sorunu stress testiyle yeniden üretildi; deadlock riski taşıyan topluluk yaklaşımının yerine geçen bir PR açıldı.
- Microsoft Testing Platform üzerine kurulu Bobcat Supervisor, uzun süren testleri görünür kılıyor, flaky testleri işaretliyor ve bazı hatalarda Docker'ı sıfırlıyor.
- Topluluk PR'ları dört kategoride değerlendiriliyor; Wolverine'in zamanlanmış mesajlaşma tablosuna eklenen partial index, eklemeli olduğu için opt-in flag olmadan kabul edildi.
Jeremy D. Miller, bir Critter Stack sürüm gününü adım adım kaydederek 6-7 JasperFx reposunda ve yaklaşık 100 NuGet paketinde Claude agent'larını nasıl yönettiğini gösterdi. Planı, geliştirme aşamasındaki agent orkestrasyon aracı Stoat içinde tutuyor; ama asıl darboğaz GitHub Actions: tek bir Wolverine pull request'i runner kuyruğunda iki saate kadar bekleyebiliyor, bu yüzden CI gün boyunca kapatılıp yalnızca sürüm öncesi kalite kapısı olarak kullanıldı.
Günün somut çıktısı da var: bir müşteriden gelen bellek kullanımı raporları, deadlock riski taşıdığı düşünülen topluluk yaklaşımının yerine stress testinden geçirilmiş bir Marten değişikliğine dönüştü. Topluluk pull request'leri dört yoldan değerlendiriliyor: olduğu gibi merge, hemen ardından düzeltme, yeni bir PR ile değiştirme ve reddetme. Gelen katkılara test ekleme işi de agent'lara bırakılıyor.
Gerçek dünyada kullanımı
- Onlarca repoyu yöneten bir OSS bakımcısı, runner kuyrukları ve maliyetler büyürken pull request doğrulamasını hızlı tutmak istediğinde.
- Agent'ların her commit'te bulut CI'ını beklemeden ilerlemesi için yerel test gating script'i tutan bir ekip.
- Marten/PostgreSQL tabanlı yüksek hacimli bir sistemde rollout sırasında bellek sıçramaları görülüp önce/sonra ölçümü yapan stress testi gerektiğinde.
- Tek bir geliştirici makinesinde iki ağır test paketini aynı anda başlatmaması gereken bir supervisor agent kurulumu.
Neden önemli
Agent'larla geliştirme, CI sürelerini ve makine belleğini katlayarak büyüttüğü için asıl mesele agent sayısı değil, doğru frenler: yerel gating, sadece sürümde çalışan CI ve kaynak kullanımının farkında olan agent'lar.