Yapay Zeka Ortakları ile Laravel Paketi Oluşturma ve Savaş Testi Yapma

Bu makalede, Laravel için oluşturduğum laravel-fluent-validation paketinin geliştirilmesi sürecini ve bu süreçte edindiğim deneyimleri paylaşacağım. Magic string’ler olan 'required|string|max:255' benim için her zaman bir sorun olmuştur. Laravel’ın akıcı API’sine yaptığı küçük eklemelerin kapandığını gördükten sonra, bunu bir paket olarak yayınlamaya karar verdim.

Ayrıca bu süreçte, wildcard validation ile ilgili bir performans sorununu çözmeyi ve otomatik göç için bir Rector companion oluşturmayı başardım.

Burada ilginç olan, paketin kendisi değil, onu geliştirmek ve güçlendirmek için uyguladığım iş akışıydı.

Dört Claude Code oturumu kullandım. Bir oturum paket üzerinde çalışırken, diğer üçü bu paketi uygulayan gerçek Laravel kod tabanları üzerinde çalışıyordu. Kod tabanı arkadaşları birbirlerinin çalışmalarını claude-peers aracılığıyla gözden geçirdi. Kod tabanı arkadaşları testi gerçekleştirdi, uç durumları denedi ve geri bildirimde bulundu. Paket arkadaşı ise sorunları çözüp, bir sürüm serisi etiketledi; ardından kod tabanı arkadaşları bunu tekrar doğruladı. Bu süreç, yayınlama ve geri bildirim döngülerini günlerden dakikalara sıkıştırdı.

Rector companion bu şekilde yaklaşık 24 saatte sekiz fonksiyonel güncelleme geçirdi. Bir kod tabanında 108 dosya dönüştürüldü, net -1,426 satır kod çıkarıldı ve dönüşüm sonrası 566 test başarılıydı, herhangi bir davranış gerilemesi gözlemlenmedi. Ancak Rector döngüsü sadece en sıkıştırılmış örnekti. Aynı yöntem performans kıyaslamalarını, Livewire entegrasyonunu, hata mesajlarını ve dokümantasyonu da şekillendirdi.

Aşağıdaki örnekler Laravel’e özgü olsa da, kullanılan yöntem evrenseldir. İzole edilmiş AI ajanları, gerçek ortamlara karşı değişiklikleri gözden geçirdiğinde çok daha kullanışlı hale gelir.

İş Akışı

claude-peers, Claude Code için bir MCP sunucusudur. Her makinede çalışan bir örnek, diğer örnekleri keşfedebilir, onların üzerinde ne çalıştığını görebilir ve mesaj gönderebilir. Hiçbiri bağlam paylaşmaz. Her biri, tam kod tabanına erişimle kendi konuşmasına sahiptir.

Pratikte şöyle çalışıyor: Paket arkadaşı yeni bir sürüm etiketler. Üç kod tabanı arkadaşına “0.4.5 etiketlendi, paralel işçi yarışını düzeltir, lütfen yeniden doğrulayın” diye bir mesaj gönderir. Her kod tabanı arkadaşı gelen mesajı alır, yeni sürümü çeker, göçü gerçekleştirir, testlerini çalıştırır ve sonuçları geri gönderir. Eğer bir sorun çıkarsa, yanıt tam hata, dosya ve genellikle nedenine dair bir teori içerir. Paket arkadaşı bunu okur, gerekirse takip soruları sorar, sorunu çözer ve döngü devam eder.

Beklemediğim bir şey ise, arkadaşların kendi inceleme dinamiklerini ne kadar hızlı geliştirdiğiydi. Birbirlerinin varsayımlarını sorguluyor, kanıt talep ediyor ve bazen öneri ile geri dönmeden önce uzlaşmaya varıyorlardı.

Dört terminalim açıktı:

• Paket repo, özellikler geliştiriyor, testler yazıyor, sürümler yayınlıyordu.
• Üç üretim kod tabanı, her biri kendi doğrulama kalıpları, çerçeve entegrasyonları ve test setleri ile gerçek bir Laravel uygulamasıydı.

Her şey yerel olarak çalışıyor. Claude Code, her kod tabanının yerel kopyalarında çalışır; terminalinizde sahip olacağınız aynı dosya sistemi erişimine sahiptir. Üretim sunucuları yok, uzak ortamlar yok, AI’ya maruz kalan gizli bilgiler yok.

Neden Gerçek Kod Tabanları Sentez Fiksörlerinden Üstün

Birden fazla kod tabanı üzerinde çalışmak, yedeklilik meselesi değil, her birinin kodun farklı bir kısmını zorlamasıdır.

İlk uygulama 108 FormRequest’e sahip ve rules()‘u hem Eylemler hem de Koleksiyonlar için adlandırma kuralı olarak kullanıyor. Rector’un atlama kaydı 2,988 girdi ve 777KB’ye ulaştı. Paket yazarı neredeyse boş bir kayıt bekliyordu. 108 dosyada, bu kullanılamaz hale geldi. Daha küçük bir kod tabanında bunu asla fark etmezsiniz. Bu uygulama aynı zamanda Filament’i Livewire ile birlikte çalıştırıyor ve bileşenlerinden beşi Filament’in InteractsWithForms trait’ini kullanıyor; bu trait kendi validate() metodunu tanımlar. Paket’in trait’inin eklenmesi, formun ilk renderı sırasında fatal bir metod çakışmasına yol açacaktır. Doğru çözüm, bırakmak ve bu sınıfları manuel incelemeye işaret etmek oldu; çünkü Rector, geliştiricinin akıcı doğrulamayı mı yoksa Filament’in form doğrulamasını mı öngördüğünü bilemez.

İkinci uygulama, 15 paralel Rector işçisi çalıştırıyor. Atlama kaydının “ilk yazıda kısma” bayrağı işlem bazında olduğundan, her işçi bunu ilki olarak düşünüp diğerlerinin girdilerini silerken, sentez test fiksörleri tek süreçte çalışıyor. Bu hatanın orada olmayacağı anlamına gelir.

Üçüncü uygulama zaten akıcı doğrulama kullanıyordu ve yalnızca dönüştürülecek 7 dosya kaldı. Pint kod tarzı düzeltici sayımlarını her sürümde kabul metrikleri olarak takip ettiler ve 7 Livewire dosyasının 5’inin #[Validate] niteliklerinin açık validate([...]) aramaları ile birlikte var olduğunu buldular. Bu, paket yazarının öngörmediği ölü kod nitelikleriydi ve bu da yeni bir hibrit tespit yolunu yönlendirdi.

Bu hataların hiçbiri muhtemelen bir fiksör tabanlı test setinde ortaya çıkmayacaktı.

Otomatik Testlerin Hala Kaçırdığı

İlk uygulama, her sürümde kaç tane her bir Rector kuralının çalıştığını takip etti. Bir sürümde, trait ekleme rector’ları sıfır kez çalıştı. Rector, “108 dosya değişti” şeklinde rapor etmeye devam etti çünkü dönüştürücü kurallar düzgün çalışıyordu. Çıktıyı kontrol eden bir testçi bunu yayımlamış olacaktı. Arkadaşların takip sayımlarını kontrol etmeleri, “108’den 0’a trait rector’ları”nın bir gerileme olduğunu ortaya çıkardı. Düzeltme aynı gün geldi ve beklenen sayımlar kalıcı bir test haline geldi.

Bir arkadaş bir retro değerlendirmesinde şöyle bir soru sordu: “Rector çıktısının ayrıştırılabildiğini test ettin. Peki, çalışma zamanı anlamsal olarak eşleşiyor mu?” Daha önce dokuz sürüm boyunca hiç kimse bunu sormamıştı. Bu, FluentRule ve string-form kurallarının aynı hata mesajlarını ürettiğine dair 16 parametrik test cases’ine neden oldu. Tüm 16’sı geçti. Ancak bu testler, kodu yazmayan bir arkadaşın “kanıtla” sorusunu sorması sayesinde ortaya çıktı.

Tasarım Düzeyinde Neler Değişti

Bir sürüm öncesinde, paket arkadaşı, kurallar dizisi içindeki new Password() yapıcı çağrılarının tespitini genişletip genişletmeme konusunda düşündü. Mantıklı görünüyordu, daha eksiksiz bir dönüşüm, 30-60 dakika çalışma gerektiriyordu. Ancak bir kod tabanı arkadaşı, dönüştürücünün bağlamdan bağımsız olduğunu gözlemleyerek bunu reddetti. Dönüşümler rules() metotlarında ve öznitelik argümanlarında çalışır. Herhangi bir genişleme her iki bağlamda da tetiklenecek ve geliştiricinin kasıtlı olarak seçtiği yapıcı formu sessizce yeniden yazacaktı. Hiçbir test başarısız olmuyordu. Özellik, tasarlandığı dar durumda işe yarıyordu. Arkadaş, yazarın düşünmediği bir hata modunu adlandırarak durumu engelledi.

Tüm üç kod tabanı, neredeyse sıfır ternary kuralı ($condition ? 'required' : 'nullable') rapor etti ve bu da özelliği talep üzerine ekleme için yeterliydi. Fakat bir arkadaş bir yeniden çerçeveleme ekledi: Kural dizilerinde ternary’lere yönelen geliştiriciler, kısalık için optimize olduklarını belirtiyor; ve closure-form akıcı versiyon yapısal olarak bu eksende kötü sonuç veriyor. Talep olsa bile, özellik hedef kitlenin kodunu kötüleştirebilir. Bu, “ertelendi” durumundan “düzeltmeyecek” durumuna taşıdı.

Bunu Ne Başardı

Her Claude örneği tam kod tabanı erişimine ve kendi konuşma geçmişine sahiptir. Paket arkadaşı iç bilgileri bilir. Kod tabanı arkadaşları uygulama desenlerinin, test setlerinin ve entegrasyonların farkındadır. Hiçbiri bağlam değiştirmek zorunda kalmaz.

Kod tabanları gerçek, değil deneme fiksörleridir. Yukarıda belirtilen her hata, test senaryolarında bulunmayan üretim düzeyinde karmaşıklık gerektiriyordu.

Otomatik doğrulama döngüyü nesnel hale getirdi. Paket her değişiklikte PHPStan’ı maksimum seviyede, Rector’ü ve Pint’ı çalıştırıyor ve 616 test ve 1,235 iddia içeriyor. Her kod tabanı arkadaşı aynı yığını çalıştırıyor. Bir arkadaş “PHPStan temiz, 566 test yeşil, Pint düzeltici sayısı 3’ten 2’ye düştü” dediğinde, sonucu güvenle kabul edersiniz.

Geri dönüşler hızlıydı çünkü aynı oturumda kalıyordu. Bir güncellemeyi etiketle, üç kod tabanı doğrula, sorunlar tam hatalar ve hipotezlerle geri dönülsün, düzeltme yayımlansın, yeniden doğrulansın. Tüm döngü 15-30 dakika içinde gerçekleşti. GitHub sorunları, mesajlar arasında bağlam kaybeder. Bu arkadaşlar, her sürümde alan bilgilerini korudular.

Ve arkadaşlar kapsamı sorgulama yetenekleri de vardı, yalnızca hataları bildirmekle kalmadılar. new Password() konuşması ve ternary kuralı yeniden çerçeveleme, teknik bir sebep ile “Bunu inşa etmemelisin” diyebilen arkadaşların katkılarıydı.

Bu İş Akışının Maliyeti

Dört Claude Code oturumunu paralel çalıştırmak, haftalık kullanım limitlerinizi ve oturum kapasitelerini gözlerinizin önünde yakmak demektir. Hızlı bir yayın döngüsü için buna değiyor, ancak maliyetini hissediyorsunuz. Tek bir katkıcı için aynı süreç, ardışık oturumlar arasında çalışır. Senkron döngüyü kaybedersiniz ama bilgi bağlamını korursunuz.

İş akışının bir de kör noktası var: Eğer tüm test kod tabanları aynı mimari varsayımları paylaşıyorsa, arkadaşlar aynı hata kategorisini birlikte gözden kaçırabilirler. Üç kod tabanı modelinin burada çalışması, her uygulamanın gerçek anlamda farklı desenlere sahip olmasıydı: ölçek, paralel yürütme, hibrit Livewire nitelikleri. Üçü de küçük Livewire uygulamaları olsaydı, atlama logu hacmi ve paralel işçi hataları yakalanmamış olarak kalacaktı.

Bunu Ne Zaman Kullanırım ve Kullanmam

Paketler veya diğer insanların kodunu değiştiren araçlar için bu iş akışını kullanırdım: Rector kuralları, kod oluşturucular, göç araçları, linter’lar. Sessiz yeniden yazım hatasının maliyeti yüksek ve yazmadığınız kod tabanlarına karşı çalışmak, bunları yayınlanmadan önce yakalamanın en güvenilir yoludur.

Ayrıca, herhangi bir çerçeveyle entegrasyon yüzeyine sahip paketler için de kullanırım. Livewire, Filament ve Inertia’nın kendi tuhaflıkları vardır. Filament + Livewire birlikte kullanan bir kod tabanında çalışan bir arkadaş, test setinizin yakalayamayacağı trait çakışmalarını ve metod çakışmalarını bulacaktır.

Daha dar bir API yüzeyine sahip basit bir yardımcı paket için, bunu daha küçültmek isterim. Üç yerine bir proje arkadaşı. Yine de, başka birinin kod tabanında “bu gerçekten çalışıyor mu” sinyalini alırsınız, ancak tam çoklu arkadaş kurulumunun yükünü kaybetmeden.

Beklenmeyen kısım, her biri farklı gerçek kod tabanına dayanmış olan çok sayıda izole arkadaşın, iç tasarım ve QA döngüsü gibi davrandıklarının ortaya çıkmasıydı. Bu, inşa edilen şeyi, kesilen şeyi ve test edilen şeyi değiştirdi.

Paket: laravel-fluent-validation — akıcı doğrulama kuralı oluşturucular, %160’a kadar wildcard performans artışı, tam Laravel paritesi, Livewire ve Filament desteği.

Rector companion: laravel-fluent-validation-rector — string kurallardan otomatik geçiş. Bir üretim kod tabanında 108 dosya dönüştürüldü, -1,426 LOC, 566 test yeşil.

Aşama mesajlaşması: claude-peers

Laravel paketleri için AI yetenekleri: package-boost — paketinizi oluştururken, her arkadaşın manuel ayar gerektirmeden bağlam edinmesi için göç kılavuzları, optimizasyon ipuçları ve çerçeveye özgü tuzaklar sunar.