Yazılım fabrikası nedir? Kodu değil, kodu yazan makineyi kurmak

Herkesin başka bir şey anladığı kelime

Syntax’ın 1049. bölümünde Wes Bos ve Scott Tolinski, Swamp Club’ın CEO’su Adam Jacob’la “software factory” yani yazılım fabrikası kavramını konuştu. Jacob, Chef’in kurucu ortaklarından ve DevOps hareketinin ilk isimlerinden. Kendisi de bu konuda beş kişiye sorarsan beş farklı tanım duyacağını kabul ediyor.

Onun tanımı şöyle: Bir ürünün geliştirme döngüsünü düşün. Neyin yapılacağına karar vermek, işi parçalara bölmek, kodu yazmak, mimariye uyuyor mu diye bakmak, eski özellikleri bozmadığından emin olmak ve canlıya çıkarmak. Yazılım fabrikası, bu döngüde giriş ve çıkış dışındaki adımların olabildiğince çoğunu ajanların yürütmesi. Her ürünün kararları farklı olduğu için iki fabrika birbirine benzemiyor. Yani indirip kuracağın hazır bir ürün değil, ekibin kendi kurduğu bir sistem.

Fabrika mı, çöp fabrikası mı?

Çoğu geliştiricinin bu kelimeye soğuk bakmasının bir sebebi var. Jacob’a göre süreci değiştirmeden sadece ajan eklersen aynı toplantılar, aynı iş akışı sürerken kimsenin tam anlamadığı binlerce satırlık PR’lar yağmaya başlıyor. Bunu yaşayan biri “Hadi bunu daha da hızlandıralım” önerisine elbette hayır der. Jacob’ın cevabı ters köşe: Çıkış yolu daha az değil, daha fazla otomasyon. Ama rastgele değil, tasarlanmış otomasyon.

Büyük şirketler için önerisi de küçük başlamak: Beş kişilik bir ekibe gerçek bir problem ver, bu ekibe “bütün kuralları bozabilirsiniz” izni ver, uçtan uca güvendikleri bir fabrika kursunlar. Sonra bu deneyimi şirketin geri kalanına onlar taşısın.

Güveni nasıl kurarsın?

Bölümün en pratik kısmı burası. Jacob üç şey öneriyor.

1. Kara kutu testleri. Black box test, ürünü içini bilmeden, bir kullanıcının kullanacağı gibi dışarıdan dener: Özellikler hâlâ söylendiği gibi çalışıyor mu? Eskiden bu kadar kapsamlı kabul testleri yazmak her özelliğin maliyetini katlıyordu, o yüzden çoğu ekip bıraktı. Ortada hiçbir insanın satır satır okumadığı bir üretim süreci varsa, bu testler yeniden anlam kazanıyor. Jacob’a göre fabrikaya giden yolda ilk iş bu: Güvenle refactor yapabileceğin bir dış test seti.

2. Yazılı bir mimari. Kendi hâline bırakılan ajan, her seferinde o an aklına yatanı seçiyor. Vibe coding ile büyüyen projelerin her yeni özellikte daha kırılgan hâle gelmesinin sebebi bu. Elinde bir mimari yoksa Jacob domain driven design (alan odaklı tasarım) öneriyor, çünkü ajan bu kavramların sözlüğünü zaten biliyor. Örneğin anti-corruption layer: İki sistem arasına konan bir çeviri katmanı. Bir taraf değişince diğer taraf etkilenmesin diye var. Bu desenleri kendi kodundan örneklerle bir skill’e yaz, sonra üretilen her kodu bu skill’e göre incelet. Skill’in ne olduğunu agent skill yazımızda anlattık.

3. Rakip incelemeler. Mimari dışındaki şartlar için ayrı bir “denetçi” kur. Jacob’ın örneği erişilebilirlik: WCAG kurallarını ve ekibine özel ekleri (iki renk tonu birbirine çok yakın olmasın gibi) bir skill’e koy, her değişikliği buna göre değerlendirt, geçemeyen iş geri dönsün. Jacob, Swamp Club’ın sitesinin Lighthouse’ta tam puan almasını, puanın düşmesine izin vermeyen böyle bir skill’e bağlıyor. Bir hata türü kaçtığında ajanı suçlamıyorsun, fabrikayı düzeltiyorsun. Claude Code ekibinin benzer katmanlı düzenini kod inceleme yazımızda anlattık.

Unit testler hâlâ gerekli mi?

Jacob burada temkinli: Kara kutu testleri kesin değerli, entegrasyon testleri muhtemelen hâlâ değerli, unit testler ise açık soru. TypeScript ve Rust gibi güçlü tipli dillerde, eskiden unit testlerin yakaladığı hataların çoğunu tip denetleyicisi yakalıyor.

Bölümde anılan bir deney de bu soruya ışık tutuyor. Thoughtworks’ten Birgitta Böckeler, ajana test-driven development (önce test, sonra kod) yaptırmanın sonucu iyileştirip iyileştirmediğine baktı. Küçük örneklemli denemede kalite açısından belirgin bir fark çıkmadı, TDD’li çözümler çoğu zaman biraz geride kaldı ve yaklaşık 3 ila 8,5 kat daha fazla token harcadı. Böckeler, ajanlara önce test yazmalarını söylemeyi bıraktığını yazıyor. TDD’yi yaygınlaştıran Kent Beck’in ajanlarla çalışma biçimini Kent Beck yazımızda anlattık.

Deterministik çekirdek, gerektiğinde zekâ

Swamp Club da bu fikrin bir uygulaması. Jacob’ın anlattığına göre bir işi her seferinde skill ile yaptırırsan model aynı döngüyü her çalıştırmada sıfırdan icat ediyor ve token yakıyor. Swamp, isteği tipli girdileri ve çıktıları olan modüllere ve iş akışlarına çeviriyor. Ortaya çıkan kod her seferinde aynı şekilde çalışıyor, modeli sadece karar gereken adımda çağırıyor. Jacob buna “döngüyü ters çevirmek” diyor: Dış döngüyü model değil, deterministik kod yönetiyor. Karar adımında Jev gibi sadece karar veren modeller kullanılabiliyor. Bölüme göre Swamp kullanıcı başına aylık ücretli, model erişimini ise sen getiriyorsun.

Jacob’ın kapanış mesajı da şu: Mühendisin işi kaybolmuyor, bir kat yukarı çıkıyor. Artık programı değil, programı yapan makineyi tasarlıyorsun.

Düşün

• Projende güvendiğin bir kara kutu test seti olsaydı, ajana hangi işi gönül rahatlığıyla bırakırdın?
• Ekibinin mimari kararları bir yerde yazılı mı, yoksa sadece insanların kafasında mı?

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