Yazılım fabrikası yaklaşımı (bulutta çalışan kapalı bir ajan döngüsü), popülerliği giderek artan bir yöntem olsa da benimsenmesi göz korkutucu olabilir. Bu yazıda, yerel ve etkileşimli ajanlardan otomatik bulut geliştirmeye geçiş için “sürünme, yürüme, koşma” adımlarını ele alacağım.
Sürünme
Görüşme fırsatı bulduğum birçok mühendislik lideri ve platform mühendisi, bulut ajanları kullanarak basit otomasyonlar oluşturarak bir yazılım fabrikası kurmanın “sürünme” aşamasına çoktan başladı.
Bu otomasyonları Tetikleyici → Ajan Aktivitesi şeklinde düşünün.
Örneğin:
- Sorun yeniden üretimi ve triyajı: Yeni açılan tüm sorunları inceleyen, yeniden üreten ve etiketleyen bir ajan kullanın.
- Kod İncelemesi: Açılan PR’ları otomatik olarak inceleyin ve yorum bırakın.
- İzleme: Sentry uyarısına yanıt veren, sorunu hata ayıklayan ve düzelten bir ajan kullanın.
- Kendini iyileştiren CI: Geri alınacak PR’ları belirleyerek veya çözülecek birleştirme çatışmalarını tespit ederek bozuk CI’yi düzeltin.
- Otomatik doküman güncelleme: Kullanıcıya yönelik dokümantasyonu güncelleyin ve değişiklik günlükleri oluşturun.
- Doğrulama: browser-use ve computer-use ajanları görsel QA yaparak değişiklikleri doğrular.
- Basit hata düzeltmeleri: Ajanlar, kullanıcı tarafından bildirilen basit sorunları tespit edip düzeltir.
Tüm bu yaklaşımların ortak noktası, yazılım yaşam döngüsünün ayrı bir parçasını otomatikleştirmeleridir. Basit otomasyonlarla başlamak düşük riskli ve düşük maliyetli bir yaklaşımdır; ayrıca daha karmaşık, çok aşamalı görevlerde ajanları etkili bir şekilde nasıl kullanacağınıza dair sezgi kazanmanıza yardımcı olur.
Uyarı izleme için örnek otomasyon
Bu otomasyonlar, kendi bünyenizde geliştirilen altyapılarla (örneğin Claude Code SDK’sını bir Docker konteynerine koyup tetiklemek için bir sunucu bağlayarak) kurulabilir veya tetikleyiciler üzerinde ajan çalıştırmak üzere tasarlanmış genel amaçlı bir bulut ajan otomasyon platformu kullanılabilir. Ayrıca döngünün tek bir aşamasına özel bir platform (örneğin özel bir ajan tabanlı kod inceleme aracı veya AI SRE) de tercih edilebilir.
Nokta atışı otomasyonlardan oluşan yamalı bohça tarzı bir yapıyla başlamak sorun değildir, ancak çoğu ekip zamanla bu yaklaşımın sınırlarına ulaşır.
Özellikle:
- Kurulum şekline bağlı olarak, bu otomasyonların bağlamı paylaşmayabilir. Bu da demek oluyor ki bir yönü (örneğin kod incelemesini) iyileştirdiğinizde, bu iyileştirmeler triyaj ve QA gibi diğer aşamalara taşınmaz.
- Tüm bu tek seferlik otomasyonların genel verimliliği gerçekten artırıp artırmadığına dair küresel bir bakış açısı yoktur ve PR başına maliyet, döngü süresi, otomasyon yüzdesi gibi önemsediğiniz üst düzey metrikleri test etmek ve iyileştirmek için sistematik bir yol bulunmamaktadır. Bunları takip etmek için geliştirme aşamaları arasında çalışan bir sisteme ihtiyacınız vardır.
- Nokta çözümlerinin her biri kendi kurulum ve bakım yükünü yaratır. Yönetilmesi gereken daha geniş bir güvenlik yüzeyi oluştururlar. Gözlemlenebilirlik için birleşik bir arayüzleri yoktur. Ekipler zamanla merkezi yapılandırma, denetim ve yönetişim ister.
Yürüme
Tüm bu sorunlar, daha bütüncül bir yaklaşıma olan ihtiyaca işaret ediyor. “Sürünme” aşamasını tamamlayan organizasyonlar kendilerine “Ajan tabanlı geliştirmeyi gerçekten ölçeklendirmek için istediğimiz sistem nedir?” diye soruyor.
Daha spesifik olarak şunları soruyorlar:
- Geliştirme nerede yapılmalı? Yerelde mi yoksa bulutta mı? Hangi arayüzler üzerinden?
- Başarılı bir otomatik geliştirme süreci nasıl görünmeli? Temel metrikler nelerdir?
- Yapay zeka egemenliği duruşumuz ne? Kodlama ajanı verilerimize sahip olmak ne kadar önemli? Model sağlayıcılara ne kadar bağımlı olmalıyız?
- Geliştirme sürecimizi zaman içinde nasıl iyileştirmeyi planlıyoruz? Maliyetleri kontrol ederken teslimat hızımızı nasıl artırırız? İyileştiğimizi nasıl biliriz?
- Modeller ve ajanlar geliştikçe geleceğe nasıl hazırlanıyoruz? Modellere erişimi etkileyebilecek düzenleyici riskleri hesaba katıyor muyuz?
- Mühendisler geliştirme sürecine tam olarak nasıl katılmalı? Tasarımcılar, PM’ler ve diğer üreticiler için durum aynı mı?
- Geliştirmeyi nasıl güvenli hale getiriyoruz? Yazılım üretim sürecimiz tehlikeye girerse planımız ne?
Bu soruları derinlemesine düşünen çoğu mühendislik lideri ve platform ekibi, sonunda bulut yazılım fabrikası yaklaşımına benzer bir noktaya varır. Şunları isterler:
- Varsayılan olarak bulutta geliştirme, çünkü ajanlara sandbox ortamları vermek onları yerelde serbest bırakmaktan daha güvenlidir.
- Kodlama ajanlarının ve bunların eriştiği araç ve sistemlerin merkezi yönetişimi.
- Denetim ve verimlilik analizi için ajanların ne yaptığının eksiksiz izleri.
- Riski en aza indirmek ve performansı optimize etmek için modeller ve iskeletler (harness) konusunda seçenek çeşitliliği.
- Ekibinizin zaten kullandığı tüm araçlara (Slack/Teams, Jira, Github vb.) geliştirmenin entegrasyonu.
- İnsanların devralması için kaçış yolları; ya canlı ajanları yönlendirerek ya da işi iç geliştirme döngüsüne taşıyarak.
- Geliştirmenin tüm aşamalarında ajanlar arasında çalışan paylaşımlı bir bağlam katmanı.
- Ekibinizin sistemin zaman içinde iyileştiğine güven duymasını sağlayan test, değerlendirme ve kıyaslamalar içeren bir yaklaşım.
Bir şirket fabrika yaklaşımına karar verdikten sonra soru şuna dönüşür: Mevcut nokta otomasyonlarınızdan oraya nasıl ulaşırsınız? Bu genellikle şu ikiliye indirgenir: (1) o otomasyonların etrafında daha fazla altyapı mı inşa edersiniz yoksa (2) fabrika altyapısını sağlayan Warp Factories gibi bir platforma mı geçersiniz?
Bunu geleneksel bir “kendi yap vs. satın al” kararı olarak çerçevelemem. Hangi yolu seçerseniz seçin, fabrikanın ekibinizin bağlamı ve iş akışlarıyla derinden entegre olması gerektiğinden, dahili ekibinizin bazı şeyleri inşa etmesini beklemelisiniz. Soru, otomasyon altyapınızı tamamen sıfırdan mı inşa edeceğiniz yoksa size önceden sağlanmış bir başlangıç avantajı sunan kişilerle mi ortaklık kuracağınız meselesidir.
Örneğin, hangi yolu seçerseniz seçin, organizasyona özel yetenekleri (skills) oluşturmayı ve bunları kod tabanınıza göre ayarlamayı beklemelisiniz. Organizasyona özel MCP’leri ve dahili bağlam kaynaklarını ortaya çıkarmayı ve yapılandırmayı beklemelisiniz. Ancak, ajanları çalıştırmak ve yönetmek, onları yönlendirmek, işlerini devretmek, etkinliklerini ölçmek, bilgisayar kullanımı yapmak vb. için bulut altyapısı inşa etmek istemeyebilirsiniz. Genel kural, her organizasyonun ihtiyaç duyduğu değil, sadece sizin organizasyonunuza özgü olan parçalara odaklanarak inşa etmektir.
Hangi yaklaşımı benimserse benimsensin, yürüme aşamasındaki en büyük kilometre taşının, basit bir ürün yüzeyinde uçtan uca ilk fabrikayı dağıtmak olduğunu öneririm. Bu, pazarlama siteniz veya dahili bir uygulamanız olabilir.
Tek bir basit projeyle başlamanın avantajı, düşük risk ve minimum karmaşıklıkla tam bir döngüyü çalıştırmaktır. Daha fazla depo, kod satırı, hizmet bağımlılığı, insan paydaşı vb. eklemek karmaşıklığı artırır ve otomasyona hazır olmadığınız hissine yol açabilir. Önce basit bir döngüyü mükemmelleştirmek daha iyidir.
Hedef, triyaj → spesifikasyon → uygulama → inceleme → doğrulama → izleme aşamalarından geçen çoklu ajan sistemidir. Daha detaylı olarak:
- Sistem yeni bir sorun alır; bu sorun ya bir insan ya da bir izleme ajanı tarafından gelir.
- Triyaj ajanı çalışır ve sorunu anlamaya/yeniden üretmeye çalışır. Görevin otomatikleştirilebilir olduğuna karar verirse → Uygulama ajanına devreder. Kapsam nedeniyle spesifikasyon gerekiyorsa → Spesifikasyon ajanı, bir spesifikasyon oluşturmak için bir insanla iteratif çalışır. Belirsizse → İnsan girdisi alıp tekrar çalıştırın veya sorunu şimdilik rafa kaldırın.
- [Gerekirse] Spesifikasyon ajanı çalışır, insan spesifikasyonları inceler ve ardından uygulama ajanına geçirir.
- Uygulama ajanı kod yazar.
- Kod inceleme ajanı kodu inceler.
- Doğrulama ajanı bilgisayar kullanımı veya diğer doğrulama yöntemlerini uygular.
- İnsan kodu ve doğrulama çıktısını inceler. Gerekirse 2., 3., 4. veya 5. adıma geri dönülür.
- CI / CD
- Yayınla (Ship it).
- İzleme ajanı çalışır ve gerekirse sorunlar oluşturarak döngüyü tamamlar.
Warp’ta dahili olarak yürüme fabrikamız, pazarlama sitemiz olan warp.dev üzerindeki değişikliklerin yaklaşık %75’ini otomatikleştiriyor. Warp Terminal’in aksine (65k GitHub yıldızı, neredeyse bir milyon aktif geliştirici, 1M satır native rust), pazarlama sitemiz oldukça basit bir uygulamadır. Burada “otomatize etmek” ile kastettiğim, istediğimiz değişikliği tarif etmek dışında minimal insan temasıyla (Slack’te veya görev takip sistemimizde), insan girdisinden yayınlanan özelliğe kadar tüm sürecin fabrika üzerinden gerçekleşmesidir.
Koşma
Ancak basit bir projede temel döngüyü kurduktan sonra daha karmaşık projelere doğru ölçeklenmelisiniz. Fabrikaları ölçeklendirmek daha sağlam bir altyapı gerektirir.
Özellikle, ölçeklendikçe belirli darboğazlar ortaya çıkar:
- Büyük projelerde uzak geliştirme ortamlarını çalışır hale getirmek zordur. Daha fazla depo, kod satırı ve hizmet bağımlılığı otomasyonu zorlaştırır.
- Daha fazla yetenek ve kod vb. eklendikçe, fabrikalarınızda yaptığınız değişikliklerin geliştirmeye olumlu etki mi ettiği yoksa sadece gereksiz hareketlilik mi yarattığını bilmek zorlaşır.
- Ajanlar daha karmaşık kod tabanlarında çalıştığında, daha güçlü modellere ihtiyaç duyulması ve ajanların daha uzun süre çalışması nedeniyle doğal olarak daha yüksek maliyet riskleriyle karşılaşırsınız. Model yönlendirme ve iskelet (harness) seçimi daha önemli hale gelir.
- Kritik öneme sahip, kullanıcıya yönelik uygulamalarda fabrika yaklaşımını benimsedikçe güvenlik ve denetim daha da önem kazanır.
- Daha fazla uygulama paydaşı, daha fazla insan koordinasyonu ve onayı demektir. Çok oyunculu girdilere ve denetim izlerine izin veren bir fabrika çözümü isteyeceksiniz.
- Kaçınılmaz olarak PR’lar birikmeye başlayacak, bu nedenle nelerin kod incelemesine gireceğini, ajan tabanlı doğrulama ve QA’yı nasıl kullanacağınızı tanımlayan net bir stratejiye ihtiyacınız olacak.
- Döngüyü kapatmak için daha sağlam araçlar isteyeceksiniz; üretime çıkan değişikliklerin yüksek kalitede olduğundan, çökmediğinden vb. emin olmak için.
Ölçeklenmiş fabrikaların çalışır hale gelmesi, bence önümüzdeki birkaç yılın en ilginç yazılım mühendisliği zorluklarından biri olacak; yazılım mühendisliği fabrika mühendisliğine dönüşüyor. Fabrikalarını sağlam, güvenilir ve kendini iyileştiren hale getirebilen organizasyonlar, daha iyi maliyetlerle daha fazla ürün sunabilecek ve rekabet avantajı elde edebilecek.
Fabrikaların gerçekten tıkır tıkır işlemesi ciddi yatırımlar gerektirir. Warp’ta bunu, fabrika yığınınızı (stack) tamamen inşa etmek olarak görüyoruz:
Bu katmanların her birini bu gönderide detaylı olarak ele alıyorum:
https://x.com/zachlloydtweets/status/2097739116720910619
Bariz olmayan, vurgulamak istediğim birkaç önemli nokta:
- Kod olarak Fabrikalar (Factories-as-code): Yapabileceğiniz anahtar seçimlerden biri, fabrikalarınızı kod olarak tanımlamaktır. Bu, hangilerinin en verimli, en yüksek kaliteli vb. olduğunu görmek için farklı fabrika yapılandırmalarının test edilmesini sağlar.
- Çoklu Model & Çoklu İskelet (Multi-model & multi-harness): Fabrikalarınızın hem sınır (frontier) hem de açık ağırlıklı (open-weight) en son modelleri kullanabildiğinden ve Claude Code ve Codex gibi farklı kodlama ajanı iskeletlerinden faydalanabildiğinden emin olmalısınız.
- Veri Sahipliği: Fabrikadan çıkan tüm verileri sakladığınızdan ve sahiplendiğinizden emin olmalısınız; bu veriler, operasyonlarını iyileştirmek için ham maddedir.
Tamamen tıkır tıkır işleyen bir fabrikada temel özellik, bunun kapalı döngülü, ölçülebilir ve iyileştirilebilir bir sistem olmasıdır. Hedef bu olmalıdır. Böyle bir sistemde herkes aynı bağlamdan, herkese açık bir şekilde, tamamen denetlenmiş ve gözlemlenen bir ortamda çalışır. Ajanların kendileri, sistemi sürdüren yetenekleri ve yapılandırmayı gözlemler ve iyileştirmeler önerir. Platform mühendisleri, sistemi tüm dahili sistemlere entegre etmek için onu genişletebilir. Mühendislik liderleri, verimlilik metriklerini görebilir ve bunları iyileştirmek için yapılan değişiklikleri anlayabilir. Her şey hislere dayalı değil, ampirik verilere dayalı olarak çalışır.
Warp’ta bu vizyona her geçen gün biraz daha yaklaşıyoruz. Her gün herkese açık bir şekilde çalışıyor, fabrikamızı ayarlıyor, maliyetleri düşürüyor ve çıktı ile kaliteyi iyileştiriyoruz.
Misyonumuz, dünyanın en iyi mühendislik ekiplerine, açık altyapı üzerinde herhangi bir altta yatan model ve iskeleti kullanarak kendi iş akışlarını oluşturmak, ölçmek ve optimize etmek için gerekli araçları sağlamaktır. Bu yetenekler, ekiplerin daha iyi yazılımları daha hızlı ve verimli bir şekilde sunmasına yardımcı olacaktır.
Warp Factories şu anda erken erişimde bulunmaktadır. Uygun bulunan şirketler 10.000 $ değerinde fabrika kullanım hakkı elde eder.
