Otonom yazılım geliştirme hakkındaki çoğu konuşma, ajanların kod yazmasıyla başlar. Bir ajan bir sorunu alır, bir özellik uygular, bir pull request açar. Demo çalışır. İnsanlar heyecanlanır.
Herhangi bir otonom teslimatın güvenilir bir şekilde çalışabilmesi için, birinin özerkliğin içinde çalışacağı mühendislik sistemini tasarlaması gerekir. Proje yapısı, teknoloji seçimleri, mimari sınırlar, tasarım yönü, mühendislik kuralları, doğrulama mekanizmaları, uzman roller, onay sınırları. Bunların hiçbiri, paralel olarak tahmin yürüten bağımsız ajanların bir koleksiyonundan ortaya çıkmamalıdır.
Benim yaklaşımım, farklı bir sorumluluk dağılımıyla başlar. İnsanlar mühendislik sistemini tasarlar. Uzmanlaşmış ajanlar işi yürütür. Eşzamansız döngüler, bu işin ne zaman gerçekleşeceğini ve sonrasında ne olacağını düzenler.
Amaç, insanları yazılım geliştirmeden çıkarmak değildir. Amaç, insan katılımını muhakeme, bağlam ve ürün anlayışı gerektiren kararlara yoğunlaştırmak, aynı zamanda yürütmenin daha fazlasının kendi kendine devam edebileceği bir ortam inşa etmektir.
Bunlar, benim izlemeden de çalışmasını amaçladığım bir projeye her başladığımda uyguladığım altı adımdır.
Adım 1: İnsan mühendislik sistemini tasarlar
Bir projeye başladığımda, temellerini otonom bir ajana icat ettirmem.
Önce önemli kısımlara ben karar veririm: deponun nasıl organize edileceği, hangi teknolojilerin kullanılacağı, ana mimari sınırların nasıl çalışacağı, tasarım yönünün ne olduğu, hangi mühendislik kurallarına uyulması gerektiği ve özerkliğin nerede durması gerektiği. Bu kararlar, sonraki her şeyin temelini oluşturur.
Ardından, bunları depoya kodlamak için opencode-onboard kullanırım.
/make-engineer, projenin ihtiyaç duyduğu uzman AI mühendislerini oluşturur. Ön yüz, arka uç, altyapı, test, güvenlik, veri, mobil, ürün ne talep ediyorsa. Bunlar, farklı etiketlere sahip genel ajanlar değildir. Her birinin tanımlı bir uzmanlığı, bir dizi yeteneği ve mühendislik iş akışında net bir yeri vardır.
/make-architecture, teknik yapıyı ve sınırları ARCHITECTURE.md dosyasına kaydeder. /make-design, görsel dili, tasarım token'larını ve bileşen kalıplarını DESIGN.md dosyasına kaydeder. /make-guardrails, tüm bu kararları her ajanın saygı duyması gereken somut kurallara dönüştürür. Mimari sınırlar, adlandırma kuralları, test beklentileri, kod stili, güvenlik kısıtlamaları, Git uygulamaları. Bunlar, yalnızca orijinal geliştirici tarafından bilinen bilgiler olmaktan çıkar ve çalışma ortamının bir parçası haline gelir.
Depo, yalnızca belgelerden daha fazlasını içerir. İçinde kodlanmış bir mühendislik organizasyonu ve içinde çalışacak her ajan için ortak bir doğruluk kaynağı barındırır.
İnsan önce sistemi tanımlar. Ancak o zaman otonom yürütme faydalı hale gelir.
Adım 2: Etkileşimli temel, özerklikten önce gelir
Mühendislik sistemi tanımlandıktan sonra, ilk proje temelini etkileşimli olarak inşa ederim.
Bu noktada normalde /plan-quick ve /plan-apply kullanırım. /plan-quick, odaklanmış bir hedefi analiz eder ve onu somut, sıralı bir görev dizisine dönüştürür. Eksiksiz bir spesifikasyon iş akışından kasıtlı olarak daha hafiftir. İş net olduğunda ve görünürlüğü veya kontrolü kaybetmeden hızlı hareket etmek istediğimde kullanırım. /plan-apply, bu görevleri uygular ve sonucu doğrular.
Projenin temel altyapısını bu şekilde kurarım. Depo yapısı, uygulama iskeleti, veritabanı kurulumu, kimlik doğrulama temelleri, tasarım sistemi, test altyapısı, CI/CD yapılandırması, dağıtım temelleri.
Bir projenin erken aşamaları, daha sonra inşa edilen her şeyi etkileyen kararlar içerir. Zayıf bir soyutlama, tutarsız bir klasör yapısı, belirsiz bir test stratejisi. Bunlardan herhangi biri, otonom ajanlar çalışmaya başladığında yüzlerce kez tekrarlanabilir. Bunun olduğunu gördüm. Hiç hoş değil.
Bu nedenle, bu aşama hızlı ve AI destekli kalır, ancak denetimlidir.
Amaç, mümkün olduğunca erken özerkliği en üst düzeye çıkarmak değildir. Amaç, projeyi, özerkliğin daha sonra güvenle içinde çalışabilmesi için yeterince istikrarlı, anlaşılır ve öngörülebilir kılmaktır.
Adım 3: İnsan katılımı bir proje politikası haline gelir
Temeller hazır olduktan sonra, teslimat sisteminin ne kadar özerkliğe sahip olması gerektiğine ben karar veririm.
Bu, manuel geliştirme ile tam otomasyon arasında ikili bir seçim değildir. İnsan katılımı, yaşam döngüsünde farklı noktalarda var olabilir ve doğru yapılandırma projeye bağlıdır.
Tamamen denetimli bir proje, bir insanın sorunu iyileştirmesini, uygulama planını onaylamasını, pull request'i incelemesini, birleştirmeyi onaylamasını ve dağıtıma yetki vermesini gerektirebilir.
Kısmen otonom bir proje, AI'nın iyileştirme ve uygulama yapmasına izin verirken, insanların cevaplanmamış soruları yanıtlamasını, önemli pull request'leri incelemesini veya nihai birleştirme üzerinde kontrolü elinde tutmasını sağlayabilir.
Yüksek düzeyde otonom bir proje, gerekli güvenlik korkulukları, testler ve kalite kontrolleri geçtiğinde, sistemin değişiklikleri otomatik olarak iyileştirmesine, uygulamasına, incelemesine ve birleştirmesine izin verebilir.
Kararsız gereksinimleri olan yeni bir ürün, olgun bir iç araçtan daha fazla insan katılımına ihtiyaç duyar. Düzenlemeye tabi bir sistem, küçük bir deney için gereksiz olacak açık onay kapıları gerektirir. Ve aynı proje, mimarisi, testleri ve teslimat mekanizmaları olgunlaştıkça zamanla daha otonom hale gelebilir.
Önemli olan nokta, özerkliğin kasıtlı olarak tanımlanmasıdır. Sorun iyileştirme, soru çözümü, plan onayı, pull request incelemesi, birleştirme onayı, dağıtım onayı. Bunlar tesadüfi kesintiler değildir. Bunlar, mühendislik sisteminde yapılandırılabilir kapılardır.
Her proje farklı bir özerklik seviyesi seçer ve bu sınırlar projeyle birlikte evrilir.
Adım 4: Fikirler kalıcı backlog öğelerine dönüşür
Etkileşimli konsol hala fikirleri araştırdığım yerdir.
Bir fikir eksik olduğunda, /plan-explore kullanırım. Bu bir uygulama komutu değildir. İşbirlikçi bir keşif sürecidir. Ajan depoyu inceler, ilgili bileşenleri haritalar, mevcut kalıpları belirler, varsayımları sorgular, bağımlılıkları izler, riskleri değerlendirir ve aslında neyin inşa edilmesi gerektiğini belirlemeye yardımcı olur.
Birçok geliştirme sorunu başlangıçta kodlama görevi gibi görünür, ancak aslında anlama sorunlarıdır. Belirsiz bir fikri doğrudan otonom bir uygulama iş akışına göndermek genellikle belirsiz bir uygulama üretir. Keşif, bir çözüme erken bağlanmadan fikre eyleme geçirilebilir olacak kadar yapı kazandırır.
Yön netleştikten sonra, GitHub, Azure DevOps veya Jira'da yapılandırılmış bir iş öğesi oluşturmak için /ops-backlog kullanırım. İş öğesi, etkileşimli düşünme ile eşzamansız yürütme arasında kalıcı bir aktarım noktası haline gelir. İş akışının sonraki aşamaları için gereken bağlamı, kapsamı, kabul kriterlerini, riskleri, cevaplanmamış soruları ve bağımlılıkları içerebilir.
Bu noktada backlog artık yalnızca görevlerin depolandığı bir yer değildir. İnsanlar, ajanlar ve döngüler arasında paylaşılan bir koordinasyon katmanı haline gelir.
İnsanlar fikirler oluşturur, soruları yanıtlar ve kararlar alır. Döngüler, sorun durumlarını gözlemler ve uygun işleri seçer. Ajanlar, yürütmek için gereken bağlamla birlikte odaklanmış görevler alır.
Backlog, etkileşimli bir konuşmayı, o konuşma sona erdikten sonra da devam eden kalıcı işe dönüştürür.
Adım 5: loop-task eşzamansız işi düzenler
Proje, mühendisler, güvenlik korkulukları, backlog ve onay politikası hazır olduğunda, loop-task'ı yerel bir makine veya VM içinde yapılandırırım.
loop-task, dış düzenleme döngülerini çalıştırır. Bu döngüler sürekli olarak backlog'u inceler, uygun işleri belirler, ilgili mühendislik iş akışını başlatır ve her sorunun durumunu günceller.
Bir iyileştirme döngüsü, yeni bir sorunu seçebilir, onu araştırabilir, spesifikasyonunu iyileştirebilir ve bilgi eksik olduğunda sorular ekleyebilir. Bir insan kararı gerektiğinde, sorun bekleme durumuna geçer. Bir kişi müsait olduğunda yanıt verir ve bilgi göründüğünde döngü devam eder.
Sorun yeterince netleştiğinde, uygulamaya hazır durumuna geçer. Uygulama döngüsü onu alır ve otonom mühendislik iş akışını başlatır.
Bir inceleme döngüsü, pull request geri bildirimlerini inceleyebilir, düzeltmeleri koordine edebilir, gerekli iş akışını yeniden çalıştırabilir ve değişikliği kabul durumuna doğru geri taşıyabilir. Bir tamamlama döngüsü, kabul edilen işi birleştirebilir, ilgili sorunu kapatabilir ve bir sonraki uygun öğenin sisteme girmesine izin verebilir.
Döngülerin birbirleriyle doğrudan iletişim kurması gerekmez. Kalıcı backlog durumları aracılığıyla koordine olurlar. Tipik bir sorun, şu şekilde bir yaşam döngüsünden geçer:
Yeni, İyileştiriliyor, Yanıt bekleniyor, Uygulamaya hazır, Uygulanıyor, Pull request, İnceleniyor, Tamamlandı.
İnsanlar, proje politikası gerektirdiğinde sürece herhangi bir noktada girebilir, ancak sistem birinin sürekli olarak bir terminali izlemesine bağlı değildir. Geliştirici çevrimdışı olsa bile, VM backlog'u kontrol etmeye ve uygun işleri ilerletmeye devam eder.
Loop mühendisliğinin merkezindeki ayrım budur:
Ajanlar işi yürütür. Döngüler, işin ne zaman var olduğuna, ne zaman başlaması gerektiğine, hangi iş akışının onu yürütmesi gerektiğine ve sonrasında ne olacağına karar verir.
Adım 6: /plan-goal bir sorunu baştan sona yürütür
Uygulama döngüsü, hazır olan bir sorunu bulduğunda, /plan-goal'ı başlatır.
Bu komut, ürün yönüne karar vermekten veya proje mimarisini icat etmekten sorumlu değildir. Bu kararlar zaten alınmış ve depoya kodlanmıştır. Onun sorumluluğu, mevcut mühendislik sistemi içinde yeterince iyileştirilmiş bir iş öğesini yürütmektir.
/plan-goal, sorunu okur, kod tabanının ilgili kısımlarını keşfeder, bir OpenSpec teklifi oluşturur, yapılandırılmış görevler üretir, spesifikasyon veya test boşluklarını belirler, uygun uzman mühendisleri seçer, model katmanları atar, bağımlılıkları hesaplar ve uygulama çalışmasını paralel yürütme dalgaları halinde organize eder.
Bağımsız olan ve deponun ayrı alanlarını değiştiren görevler, farklı mühendislere aynı anda atanabilir. Önceki çalışmaya bağlı olan veya aynı dosyalara dokunan görevler, gerekli sırayla yürütülür.
Lider ajan, çalışmayı koordine eder, her sonucu toplar, odaklanmış commit'ler oluşturur, testleri, lint'leri, tip kontrollerini ve derlemeleri çalıştırır. Doğrulama başarıyla tamamlanamadığında, değişikliği göndermek yerine durur.
Uygulama geçerli olduğunda, dal gönderilir ve gerekli bağlam ve kanıtlarla birlikte bir pull request oluşturulur.
Yapılandırılan proje politikası daha sonra ne olacağını belirler. Bir insan pull request'i inceleyebilir. Başka bir AI sistemi incelemeyi gerçekleştirebilir. Yüksek düzeyde otonom bir proje, gerekli her kontrol geçtiğinde otomatik olarak birleştirebilir. Diğer projelerde, nihai karar açıkça insana aittir.
Bu, sistemdeki iki düzenleme katmanını ortaya çıkarır. loop-task, dış düzenleme katmanıdır. Backlog yaşam döngüsünü yönetir ve iyileştirme, uygulama, inceleme veya tamamlamanın ne zaman gerçekleşmesi gerektiğine karar verir. /plan-goal ve diğer opencode-onboard komutları, iç mühendislik iş akışını oluşturur. Belirli bir değişikliğin nasıl keşfedileceğini, planlanacağını, atanacağını, uygulanacağını, doğrulanacağını ve teslim edileceğini anlarlar.
Konuşmadan sağ çıkan bir sistem
Prompt tabanlı geliştirmenin sınırlamalarından biri, çok fazla durumun geçici bir konuşmanın içinde yaşamasıdır.
Mimarinin tekrar açıklanması gerekir. Önceki kararlar unutulur. Yarıda kalan bir uygulamaya devam etmek zordur. Bir geliştiricinin, her adımdan sonra ajanın ne yapması gerektiğine karar vermek için orada bulunması gerekir.
Bu iş akışı, bu durumu kalıcı sistemlere taşır. Depo, mimariyi, tasarım kurallarını, mühendisleri ve güvenlik korkuluklarını içerir. OpenSpec, planlanan değişikliği ve görevlerini içerir. Git, uygulama geçmişini ve kurtarma noktalarını içerir. Backlog, teslimat durumunu ve insan kararlarını içerir. Yerel makine veya VM, döngülerin çalışmaya devam ettiği kalıcı ortamı sağlar.
Sonuç, bütün bir yazılım organizasyonu gibi davranmaya çalışan tek bir otonom ajan değildir. Farklı bileşenlerin farklı sorumluluklara sahip olduğu koordineli bir sistemdir.
İnsanlar yönü, kısıtlamaları ve sorumluluk sınırlarını tanımlar. Uzmanlaşmış ajanlar, odaklanmış mühendislik işini yürütür. Döngüler, yaşam döngüsünü eşzamansız olarak koordine eder. Backlog onları birbirine bağlar.
En önemli değişiklik, ajanların daha fazla kod üretebilmesi değildir. Daha büyük değişim, yalıtılmış AI etkileşimlerinden kalıcı mühendislik sistemlerine doğrudur.
Her görevden önce depoyu açıklamak yerine, proje kendi mimarisini ve güvenlik korkuluklarını taşır. Her şeyi uygulaması için genel bir ajana sormak yerine, iş uzmanlara atanır. Her adımdan sonra ne olması gerektiğine manuel olarak karar vermek yerine, döngüler kalıcı iş akışı durumlarına tepki verir. Tüm süreci bir konuşmanın içinde tutmak yerine, ilerleme sorunlarda, spesifikasyonlarda, commit'lerde, pull request'lerde ve yerel durumda varlığını sürdürür.
İnsan rolü ortadan kalkmaz. Otonom yürütmenin çalışmasına izin verilen ortamı tasarlamaya doğru kayar.
Şu anda inşa etmekte olduğum model budur: geliştiricinin önce mühendislik ortamını ve özerklik sınırlarını belirlediği, ardından eşzamansız döngülerin uzmanlaşmış ajanları backlog odaklı bir teslimat yaşam döngüsü aracılığıyla koordine ettiği, insan tarafından tasarlanmış bir AI SDLC'si.
Sıfırdan, kendi kendine çalışan döngülere. Altı adım, her biri bir öncekinin üzerine inşa edilir, her biri biraz daha fazla durumu konuşmanın dışına ve unutmayan sistemlere taşır.
PS: loop-task, opencode-onboard ve bu araçların geri kalanını ckgrafico.com adresinde bulabilirsiniz.
