Yazılım fabrikaları son birkaç haftadır büyük bir trend haline geldi. Ben de bir tane yaptım.
İşte öğrendiklerim, nasıl çalıştığı ve bir öğleden sonra nasıl bir tane yapabileceğiniz.
Hedeflerim
Gerçekten basit, kendi kendine çalışan ve sürekli ilgilenmeyi gerektirmeyen bir şey olması gerekiyordu. İdeal olarak, mevcut Claude aboneliğimle tamamen çalışabilmeliydi.
Kulağa safça gelebilir, ancak temelde mevcut iş akışıma kolayca entegre olmazsa, kalıcı olacak bir şey olmayacak. Bunu inşa edip sadece bu yeni sistemi kullanmak için tüm mevcut alışkanlıklarımı değiştirmek istemiyorum. Deneyimlerimden biliyorum ki, eğer bu olursa, uzun vadede benim için çalışmayacak ve önemsiz hale gelecek.
Bu yüzden, tek bir büyük çaba olarak saldırmak yerine, iki ayrı aşamaya ayırdım:
- Ön triyaj - yapılacak "şeyleri" belirleme
- Uygulama - aslında "şeyleri" yapma
Merkezde ise, yapılması gereken işin gerçeğin kaynağı olan Linear var.
Her yazılım fabrikasının, GitHub issue'ları, Linear veya başka bir şey olsun, yapılacak işlerin bu merkezi deposuna sahip olması gerekir. Halihazırda kullandığınız şey olmalı, böylece herhangi bir sistemin, ajanların veya insanların daha sonra alıp tamamlaması için iş eklemesi kolayca genişletilebilir.
Linear'da, Sistem Sağlığı Kontrol döngüsü aracılığıyla otomatik oluşturulmuş bir issue
Bor hattı, bir yazılım fabrikası oluşturma sürecini gerçekten yönetilebilir kılan, kasıtlı olarak tanımlanmış dikişlere sahiptir:
- İş oluştur (MCP'lerle döngüler)
- İşi depola (Linear)
- İşi tamamla (SDLC ajanı)
Bölerek, hem ön triyaj hem de uygulama taraflarını aynı anda inşa etmek zorunda kalmazsınız (ve aşırı mühendislikten kaçınmak için aslında buna karşı tavsiyede bulunurum). Linear, "ne yapılacağı" ile şu anda "ne yaptığımız" arasındaki arayüzü iyi tanımlanmış ve genişletilmesi kolay hale getirir.
Ön Triyaj Adımı
Yukarıdaki diyagramda, iş soldan sağa doğru ilerler. Sol taraf, işin oluşturulduğu ve yapılması gerekenlere ekleyen herhangi bir sayıda sistemi (insanlar, ajanlar veya API'ler) içerir. Bu ön triyaj adımında oluşturulan tüm çıktılar Linear'ımıza konur.
Bir Claude bulut ortamında çalışan birkaç döngü
Bu adımda, üç ana döngümüz var:
- Sistem Sağlığı Kontrol Döngüsü (yani bir hata bulucu) - bu döngü her gün sabah 5'te çalışır ve birkaç MCP sunucusuna bağlıdır: hata takibi için Posthog; sistem teşhisi için Vercel; ve issue oluşturmak için Linear.
- Kullanıcı Deneyimi İyileştirmeleri ve Müşteri Geri Bildirimi Döngüsü - bu döngü her hafta Pazartesi sabah 9'da çalışır ve her yeni geri bildirimi, Intercom/Fin'den gelen her müşteri destek sohbetini ve tüm Posthog oturum tekrarlarını tarar. Oturum tekrarları bir altın madenidir. Öfke tıklamalarının nerede olduğunu veya kullanıcıların nerede zorlandığını ve kafasının karıştığını görebilirsiniz.
- Kayıp Analizi Döngüsü - bu döngü her gün sabah 6'da çalışır ve son 24 saat içinde iptal'e tıklayan her müşteriyi araştırır. Stripe'dan ödeme ve kullanıcı verilerini (e-posta/konum dahil) çeker ve ardından iptal etmeden önce ne yaptıklarını görmek için bu müşterinin Posthog'daki oturum tekrarına bakar. Kullanımlarını Supabase'den çekerek, yanlış ICP olup olmadığını, o "vay be" anını hiç yaşayıp yaşamadıklarını veya hatalarla karşılaşıp karşılaşmadıklarını görürüz. Rapor Slack'e gönderilir ve ajan, müşteri kaybıyla ilgiliyse, önceliği artırmak için issue'lar oluşturur (veya yorum yapar).
Bu ajanları tutarlı bir şekilde çalıştırmak için, işleri basit tuttum ve Claude Code Cloud Routines kullandım.
Bir Hetzner VPS, kafeinli bir mac mini vb. ile aşırı mühendislik yok. Mevcut Claude Code aboneliğinizden yararlanmanın ve bir programa veya webhook etkinliği aracılığıyla tetiklenebilen her zaman açık ajanlar oluşturmanın şimdiye kadar bulduğum en kolay yolu bu. "Peki ya satıcıya bağımlılık!!" diyen herkese - bu sadece bir metin. İstediğiniz yere kopyalamaktan çekinmeyin, ben sadece güvenilir bir şekilde çalışan, kurulumu en kolay ve en ucuz şeyi istedim.
Claude Code Cloud Routines kullanmanın bir başka nedeni de Anthropic'in bulut ortamlarının, Claude'u yerel olarak çalıştırmaya çok yakın olmasıdır.
Bulut Claude Routines
Açıkçası, sizin env değişkenlerine sahip değiller (gerekirse bulut ortamı kurulumuna eklenebilir), ancak Masaüstü Uygulamasının bağlayıcıları aracılığıyla bir MCP bağlantısı kurarsanız, hem yerel Claude cli'niz hem de uzak Claude bunları Codex'ten farklı olarak kullanabilir. Bu benim için en önemli özellikti ve bu ön triyaj ajan döngülerinin bu kadar iyi çalışmasını sağlayan şey. Ayrıca, dizüstü bilgisayarınızın belleği konusunda endişelenmeden paralel olarak birçok oturum çalıştırmayı kolaylaştırır.
Sadece bu ön triyaj adımını uygularsanız, işin tamamlandığı bir sonraki adımı inşa etmeseniz bile yine de çok fazla avantaj elde edersiniz.
Tek bir döngüyle küçük başlayın, deneyin, iyileştirin, ardından daha fazlasını ekleyin. Bugün mevcut issue takipçinize yeni, kaliteli işler koyan rutinler oluşturabileceğinizi ve ardından uygulama için bugün ne yapıyorsanız onu yapmaya devam edin.
Uygulama Adımı
İkinci adımın en temel versiyonu, ajanınıza bir issue ID'si verip "git bunu tamamla" demektir. Çoğu insanın ajanlarla çalışırken bugün yaptığı şey budur, ancak bunu okuyorsanız muhtemelen istediğiniz şey bu değildir, çünkü artık döngüdeki darboğaz sizsiniz, bir oturumda doğrudan bir ajanı başlatıyorsunuz.
Bunun yerine yaptığım şey, doğrudan Linear'dan uzak Claude Code oturumlarını tetiklemenin bir yolunu oluşturmaktı.
Linear issue'sundan Claude'a geçiş
Şu şekilde çalışır:
- İlk olarak, yeni bir Claude oturumunu nasıl tetiklemek istediğinizi belirleyin. Bizim için, bu yeni görevi başlatan bir Linear issue'suna 'auto' etiketi ekliyoruz.
- Ardından, Linear, dahili webhook API hizmetimize (yeni oluşturulmuş bir dahili Hono uygulaması) bir webhook etkinliği gönderir; bu hizmet etkinliği ayrıştırır ve ardından doğru bilgileri Claude Routine'e iletir.
- Son olarak, bu hafif API hizmeti, bir başlangıç prompt'u ile Claude rutinini tetikleyen bir POST isteği yapar.
Tetikleyici olarak 'auto' etiketi kullanmak, yeni Claude oturumlarının otomatik yürütülmesini kontrol etmemizi sağlar.
Varsayılan olarak, ön triyaj adımlarına bu 'auto' etiketlerini dahil etmiyoruz ve ajanı çalışmaya başlatacak etiketi eklemesi için bir insanın (insanın döngüde kalmasını) olmasını gerektiriyoruz. Bu nedenle 1. adıma ön triyaj adımı diyoruz, çünkü bir şey hâlâ üzerinde ne çalışılacağını buluyor, ya insan müdahalesiyle ya da bir ajanın döngü yapması ve yeni issue'ların eklendiğini izlemesi ve yeni uygulama oturumları başlatmasıyla.
Bununla birlikte, bir etiket eklemek bir ajan tarafından da kolayca yapılabildiğinden, ön triyaj döngülerinin varsayılan olarak 'auto' etiketiyle yeni issue'lar oluşturmasını sağlayabiliriz, bu da yeni bir Claude oturumu başlatır. Bir etiket kullanmak, ister bir ajan tarafından otomatik olarak ister biz insanlar tarafından olsun, yeni uygulama çalışmalarını başlatmak için çok esnek bir yol haline gelir.
Claude oturumlarını başlatmak için hafif bir yönlendirme hizmeti
Linear webhook'ları desteklediğinden, "bir etiket eklendiğinde gönderme" olayının tamamı çalışır. Tek dezavantajı, bu webhook'ları kabul eden, etkinlikleri ve payload verilerini Claude Code'u tetiklemek için biçimlendiren genel bir API'ye ihtiyacımız olmasıdır. Bu yeni hizmet ayrıca doğru kimlik doğrulama başlıklarını ekler, bu nedenle Linear'ın rutini doğrudan tetiklemesini sağlayamazsınız.
Alternatif olarak, belirli aralıklarla başlayan ve 'auto' etiketiyle devam etmeyen yeni issue'ları uygulamaya çalışan zamanlanmış bir rutininiz olabilir.
Gerçek rutin prompt'u için, tüm SDLC'yi adım adım anlatan, /implement veya /do gibi bir isimle yeniden kullanılabilir bir beceri oluşturmanızı öneririm. Bu, sadece "/do ISSUE-NNN" demeyi kolaylaştırır ve issue bağlamını getirme, işi uygulama, tarayıcıda doğrulama, PR oluşturma ve yorumları izleme adımlarını doğru bir şekilde nasıl yapacağınızı belgeler.
Ardından, Linear etkinliği tarafından tetiklenen Claude rutin prompt'u çok basit bir prompt'a sahip olabilir. İşte benimki:
Sağlanan issue'yu alın ve istenen değişikliği uygulamak ve bir çekme isteği oluşturmak için /do becerisini kullanın. Yalnızca sağlanan tam issue'yu getirin. Zaten tamamlanmış veya devam ediyorsa durun.
Issue referansı bu mesajda görünmüyor — aynı oturumda, bu mesajdan hemen sonra gönderilen, bir \
<routine-fire-payload>\etiketiyle sarılmış ayrı bir takip mesajı olarak gelir. Bir issue sağlanıp sağlanmadığına karar vermeden önce bu mesajı bekleyin. Yalnızca \<routine-fire-payload>\mesajında bunu kontrol ettikten ve başvurulan issue'nun gerçekten var olmadığını onayladıktan sonra issue'nun mevcut olmadığı veya hiçbirinin verilmediği sonucuna varın.Çalışmaya başladığınızda, issue'ya yorum yapın, durumunu "Devam Ediyor" olarak ayarlayın ve ilerledikçe issue'yu anlamlı herhangi bir şeyle güncelleyin. Linear issue yorumlarına her zaman [Claude] ön eki ekleyin.
Yani bu noktada, API aracılığıyla tetiklenen, issue'ları uygulayan, PR'ler açan (ve umarız Playwright veya Agent Browser aracılığıyla çalışmalarını doğrulayan) paralel Claude Remotion oturumlarınız var.
Temelde, tamamen gözlemlenebilir, siz uyurken çalışan ve tamamen Claude Code aboneliğinizle çalışan eksiksiz bir yazılım fabrikası.
