Yapay zekâ programlama ajanları, yazılım ekiplerinin yalnızca kod yazmanın ötesine geçen mimari sorunları ele almasına yardımcı olabilir; ancak faydaları, ekibin belirlediği hedeflerin ve kısıtların açıklığına bağlıdır. Pierre Pureur, Kurt Bittner ve Todd Miller tarafından hazırlanan ve Daniel Bryant tarafından gözden geçirilen InfoQ makalesi, ajana yalnızca işlevsel gereksinimler sağlamanın ölçeklenebilir, güvenli veya bakımı kolay bir mimariyi garanti etmediği konusunda uyarıyor.
Önerilen yaklaşım; performans, güvenlik ve ölçeklenebilirlik gibi kalite niteliği gereksinimlerine (Quality Attribute Requirements veya QARs) ve ajanın dikkate alması gereken ödünleşimlerin açıklığa kavuşturulmasına dayanıyor. Makale ayrıca ajanın ürettiği çıktının yalnızca kod incelenerek veya önerilerine güvenilerek değil, açık ölçümlerle test edilmesi gerektiğini vurguluyor.
1. Eski hizmetleri kullanmadan önce belgelemek
Modern bir mimari, IMS veritabanı üzerine kurulmuş eski bir sistemden sigorta poliçesi verilerini alma gibi belirli bir işlevi yerine getiren eski bir hizmete dayanabilir. Sorun şu ki bu hizmetler doğru belgelendirmeden yoksun olabilir; bu da veri akışlarını anlamayı veya geliştirmenin ilerleyen aşamalarında ya da üretime geçildikten sonra ortaya çıkabilecek mantıksal ve güvenlik kusurlarını keşfetmeyi zorlaştırır.
Ajan, hizmetin tasarımını çıkarabilir ve veri akışlarını belgeleyebilir; ardından kodu inceleyip hizmetin anlaşılması ve bakımının zor olması durumunda düzeltmeler veya yeniden yapılandırma önerebilir. Ancak bu kullanım, hizmetin korunabilir olup olmadığına veya risklerinin değiştirilmesini gerektirip gerektirmediğine ilişkin insan mühendislik kararının gerekliliğini ortadan kaldırmaz.
2. Mimari kusurları aramak
Ajan, mimari standartların ihlallerini, bozulmuş yazılım uygulamalarını veya yeniden yapılandırılması gereken bölümleri bulacak şekilde yönlendirilebilir. İnceleme örnekleri arasında API tasarımı, karmaşık, güvensiz veya verimsiz arayüzler ve alan odaklı tasarım (DDD) sınırlarının ihlalleri yer alır.
Makale, ajanın genellikle çok sayıda iyileştirme bulacağını belirtiyor; bu nedenle ekip, önemli sorunlarla düşük değerli önerileri birbirinden ayırmalıdır. Mühendisler, yalnızca gerekli işlevleri tanımlamakla yetinmek yerine ölçülebilir hedefler, bilinen alternatifler ve açık ödünleşimler belirlediğinde sonuçların kalitesi artar.
3. Ajanı izole ederek güvenlik denetimi yapmak
Ajan; veri akışlarını çıkarmak, yüksek riskli dosyaları belirlemek, karmaşık mantıksal kusurları incelemek, istismar girişimlerini taklit eden testler veya betikler oluşturmak ve ardından keşfedilen sorunlar için yamalar önermek amacıyla kullanılabilir. Makale, güvenlik riski oluşturduğu sınıflandırılan npm paketlerini kapsayan bir deneyi sunuyor; iki paket güncellenmiş, bir paket değiştirilmiş ve başka bir paket için uyarının yanlış alarm olduğu değerlendirilerek paketin korunmasına karar verilmiştir.
Ancak bu kullanım açık operasyonel kısıtlar gerektirir: ajanın erişimini onaylanmış dosyalarla sınırlamak, veritabanı parolalarını ve gizli bilgileri gizlemek, testleri yalıtılmış bir ağda çalıştırmak ve herhangi bir değişiklik birleştirilmeden önce insan incelemesini zorunlu kılmak.
4. Prototipler için mimari temel oluşturmak
Ajanların hızı hızlı bir prototip oluşturmayı mümkün kılar; ancak mimari hedefler belirlenmezse ortaya çıkan prototip geçici ve kullanılamaz olabilir. Makale; kod yazma tarzını, veritabanı tasarımını, arayüzleri, tercih edilen platformları ve çerçeveleri içeren önceden yapılandırılmış uygulamaların yanı sıra Markdown biçiminde yazılmış QARs hazırlanmasını öneriyor.
Uygulamaların ilk yapısını standartlaştırmak ve ekip standartlarını başlangıçtan itibaren dahil etmek için GitHub şablonları da kullanılabilir. En iyi yaklaşım, ajana önceden ayrıntılı bir çözüm dayatmak yerine hedefi, kısıtları ve bunların karşılandığının nasıl doğrulanacağını açıklamaktır.
5. Test edilebilir ilk mimariler oluşturmak
Makale, ajanın Minimum Viable Architectures veya MVAs oluşturmak için kullanılmasını öneriyor. Bunlar yalnızca işlevleri kanıtlayan kodla sınırlı kalmamalı, aynı zamanda QARs'ı doğrulamak için gerekli testleri, test verilerini ve çalışma ortamını da içermelidir. Ajan test araçları ve konteyner yapılandırmaları oluşturabilir; ancak ekip, testlerin gerçekten gerekli nitelikleri ölçtüğünden emin olmalıdır.
Ayrıca MVA'nın mimari değişim senaryolarını karşılayabilme kapasitesi değerlendirilmelidir; çünkü otomatik olarak oluşturulmuş bir mimari, gelişime uygun tasarlanmadıysa genişletilmesi maliyetli hale gelebilir.
Pratikte ne değişiyor?
Makalenin temel mesajı, programlama ajanlarının kod üretimini hızlandırdığı; ancak gereksinimlerin, kısıtların ve testlerin ifade edilmesinin önemini artırdığıdır. Kod yazmayla ilgili beceriler ortadan kalkmıyor; fakat neyin inşa edilmesi gerektiğini, kabul edilebilir kalitenin ne olduğunu ve bunun nasıl ölçüleceğini belirlemek daha kritik hale geliyor. Bu nedenle ajan, mühendislik muhakemesinin yerine geçen bir araç olarak değil, mimari gözetim altındaki bir araç olarak ele alınmalıdır.