Roma mitolojisinde kapılar, eşikler ve başlangıçların tanrısı Janus’un iki yüzü vardı: biri geçmişe, diğeri geleceğe bakardı. Kodlama ajanlarının yazılım geliştirmedeki yaygınlaşmasıyla bu çift yönlü bakışın önemi artıyor. Geçmişe bakmak, sürdürülemez hale gelen kod tabanlarından öğrenilen dersleri; geleceğe bakmak ise henüz var olmayan teknolojilere uyum sağlayabilecek yapıları işaret ediyor.
Bu çerçeveden yazılan makalede, yapay zeka ajanlarıyla hızlıca çalışan bir prototip üretmek ile onu evrilebilen bir sisteme dönüştürmenin iki farklı meyil olduğu vurgulanıyor. Kod artık daha ucuza üretiliyor, daha kolay değiştiriliyor ve daha hızla birleştiriliyor; ancak açık bir yapı olmadan üretilen kodun anlaşılması, sürdürülmesi ve genişletilmesi zorlaşabiliyor.
Makale, bu konuyu önceki yazısında “standardsız hızın kırılgan yapay zeka ürünleri yarattığından” bahsettiği yönüyle devam ettiriyor. Odak şimdi daha pratik bir soruya kayıyor: Evrilebilen yapay zeka uygulamaları kurmamıza yardımcı olabilecek başlangıç yapısı nasıl olmalı? [towards-data-science sitesinde aktarılan bilgilere göre]
Risk yalnızca bugünkü dağınık koddan ibaret değil. Daha derin risk, projenin geçmiş mimari derslerini anmsaması ve geleceğe dair bir odağı olmaması. Bir kodlama ajanı bir fonksiyon ekleyebilir, dosya oluşturabilir veya bir çerçeveyi entegre edebilir; ancak açık yapı yoksa mantığı o anda en kolay görülen yere yerleştirebilir: uç noktanın içine, çerçeve nesnesinin içine, yardımcı bir fonksiyona ya da sorumluluğu olmayan bir dosyaya.
Start Mimarisini Veren Temeller
Temel (baseline), projeye açık bir ilk sürüm verir. Ne bilindiğini, geçerli başlangıç noktasının ne olduğunu ve gelecek yinelemelerin koruması beklenen ilkelerin neler olduğunu tanımlar. Bu referans yoksa ekipler uygulamayı sürekli değiştirebilir ama iyileştirip değiştirdiklerini ayırt edemez.
Bu durum kodlama ajanlarıyla geliştirme yapılıyorda özellikle önem kazanır. Anlaşılmış bir mimari, tanımlanmış sınırlar ve yerleşmiş kalıplar yoksa her yineleme sistemi farklı yöne şekillendirir. Cursor, Claude veya Codex kuralları, beceri dosyaları ya da kodlama yönergeleri gibi araçlar mimari temelin yerine geçmez.
Bu mekanizmalar yerel örf ve adetleri anlamaya ve tutarlı kod üretmeye yardımcı olsa da zaten takip edilecek bir yapı olduğunda daha iyi çalışırlar. Temel hem ajana hem geliştiriciye sorumlulukların nereye ait olduğunu, aşılmaması gereken sınırları ve yeniden kullanılacak kalıpları gösteren istikrarlı bir referans sağlar.
Data bilimcileri için temel, geliştirilen uygulamanın türüne bağlıdır. Ajantılı bir iş akışı araçlar, durum yönetimi, izinler ve denetim için açık sınırlar isteyebilir; belge işleme sistemi sınıflandırma, çıkarma, doğrulama ve insan değerlendirmesini ayırabilir; öngörü hizmeti ise özellik işlemeyi, model çıkarımını, izlemeyi ve yedek mekanizmaları izole edebilir.
Data Bilimcilerinin Bilmesi Gereken Mimari Seçimler
Yazılım sistemini düzenlemenin birçok yolu var ve her mimari seçim farklı bir kaygıyı karşılar. Sorun, uygulama açık sınırlar, sorumluluklar veya bağımlılık kuralları olmadan büyümeye başladığında başlar.
Bu durum not defterinden deney scriptsinden üretim uygulamasına geçişte özellikle yaygındır. Model çıkarımı, ön işleme, doğrulama, API mantığı, veri tabanı erişimi, işletme kuralları ve dış entegrasyonlar çabuca iç içe geçebilir. Uygulama çalışıyor olabilir; ancak bir modeli değiştirmek, veri tabanını değiştirmek veya bileşenleri test etmek giderek zorlaşır.
Bu meyillere yönelik yerleşmiş yazılım mühendisliği ilkeleri mevcuttur: Sorumlulukların ayrılması ve SOLID ilkeleri sorumlulukları düzenler, bağımlılığı azaltır ve bileşenlerin odaklı, genişletilebilir ve değiştirilebilir kalmasını sağlar. Temiz Mimari (Clean Architecture) ve Altıgen Mimari (Hexagonal Architecture) veri tabanı, çerçeveler, model sağlayıcıları ve üçüncü taraf hizmetleri gibi dış bağımlılıklardan uygulama mantığını koruyan yaklaşımlar sunar.
Musluklar (ports), adaptörler ve bağımlılık enjeksiyonu mimari sınırları pratik mekanizmalara çevirir; böylece işletme mantığını değiştirmeden uygulamalar değiştirilebilir. Belirli bir model sağlayıcısına, veri tabanına ve API çerçevesine dayanan öngörü uygulamasında bu bağımlılıklar doğrudan mantığa gömüldüğünde onlardan herhangi biri değiştiğinde uygulamanın her yerinde değişiklik yapılması gerekebilir. Jasny arayüzler ve adaptörlerle temel davranış sabit kalırken dış bileşenler bağımsız gelişebilir.
Aynı ilke ajantılı iş akışlarına da uygulanır. Bir ajan kullandığı her aracın, depolama mekanizmasının veya dış hizmetin uygulama ayrıntılarını bilmek zorunda değildir. Jasny sözleşmeler ve bağımlılık sınırları bu bileşenleri değiştirmeyi, test etmeyi ve sürdürmeyi kolaylaştırır.
Bu mimari ilkeleri pratikte gösteren birkaç uygulama var. AWS Prescriptive Guidance’dan gelen özellikle faydalı bir örnek altıgen mimari üzerine kurulu bir Python uygulaması sağlar. Referans proje alan mantığını, muslukları, adaptörleri, API giriş noktalarını, testleri ve altyapıyı ayırır. Bu örneği kullanmasının nedeni AWS’in hem uygulamayı hem de detaylı yönermeyi sağlamasıdır.
Farklı mimari yaklaşımlar birbirini tamamlayabilir. Pratik bir yapay zeka temeli yetenekleri düzenleyen dikey dilimleme, temel uygulama mantığını koruyan Temiz Mimari, bu mantığı musluklar ve adaptörlerle bağlayan Altıgen Mimari ve uygulamaları değiştirilebilir kılan bağımlılık enjeksiyonunu birleştirebilir.
Amaç belirli bir mimariyi mekanik biçimde takip etmek değil; hangi sorumlulukların sabit kalması gerektiğini ve hangi bileşenlerin özgürce değişebilmesi gerektiğini anlamaktır.
Tasarım Kalıpları: Sınırları Koda Dönüştüren Legolar
Yazılım mimarisi sistemin genel şeklini tanımlar: sorumluluk sınırları, bağımlılık kuralları ve sabite uygulama mantığı ile değişen teknoloji arasındaki ayrım. Ancak mimari kararlar sonunda koda çevrilmelidir. Tasarım kalıpları burada işe yarar.
Tasarım kalıplarını LEGO parçaları gibi düşünün: Tekrarlayan problemler için çözüm icat etmeden mimari kararlara uygulayan yeniden kullanılabilir yapı blokları.
Bir LLM sağlayıcısını uygulama yeniden yazılmadan değiştirmek istiyorsanız Adaptör (Adapter) sağlayıcıya özgü uygulamayı izole eder. Veri tabanına bağlanmadan işletme mantığını test etmek isterseniz Depo (Repository) arayüzü ve Bağımlılık Enjeksiyonu kalıcılığı uygulama davranışından ayırır. Farklı model-seçim stratejileri gerekiyorsa Strateji (Strategy) kalıbı bu alternatifleri değiştirilebilir kılar.
Faktori (Factory) ve Kayıt Defteri (Registry) gibi diğer kalıplar bileşenleri oluşturmak, yapılandırmak ve keşfetmek için kullanılır; her uygulamayı uygulama içine kodlamadan. Şekil 2 mimari ilkeleri somut uygulamalara dönüştüren birkaç tekrarlayan mekanizmayı özetler.
Cockburn (Hexagonal Architecture), [2] GoF (Gang of Four, Design Patterns), [4] Fowler (Patterns of Enterprise Application Architecture), and [5] Fowler (Dependency Injection). AI-generated illustration based on the author’s description.
Bu kalıplar yalnızca yapay zeka geliştirmeye özgü değildir; kodlama ajanlarıyla uygulamalar kurulduğunda özellikle değerli hale gelen yerleşmiş yazılım mühendisliği pratikleridir. Ajana her seferinde yeni bir entegrasyon ya da bileşen yapısı icat etmesini sormak yerine tanıdık kalıplar ve örf ve adetlerle onun uygulamasını yönlendirebiliriz.
Amaç olabildiğince çok sayıda kalıp sokmak değildir. Aşırı soyutlama basit bir uygulamayı gereksiz biçimde karmaşıklaştırabilir. Değer tekrarlayan problemleri tanımaktan ve açık sınırları, test edilebilirliği ve esnekliği korumaya yardımcı olan en küçük kalıp kümesini uygulamaktan gelir.
Mimari Temelden İskele ve Araçlara
Mimari ilkeleri anlamak faydalıdır; ancak onları projeler boyunca tutarlı biçimde uygulamak farklı bir meyildir. Data bilimcileri benzer temellerle uygulamalar geliştirir: API uç noktaları, model çıkarım hizmetleri, yapılandırma yönetimi, günlük kaydı, testler, dış entegrasyonlar ve dağıtım altyapısı. Bu bileşenleri her yeni proje için yeniden oluşturmak zaman alır ve gereksiz tutarsızlıklar doğurabilir.
Mimari temel (baseline) izlenmesi gereken ilkeleri, sınırları ve örf ve adetleri tanımlar. İskele (scaffold) bu kararlara dayanarak önceden tanımlı modüller, arayüzler, yapılandırma, testler ve genişletme noktalarıyla yeniden kullanılabilir bir başlangıç yapısına dönüştürür. Boş bir depodan başlamaktan ya da kodlama ajanından tüm uygulama yapısını icat etmesini istemek yerine geliştiriciler önceden yerleşmiş mühendislik pratiklerini içeren bir temelle başlar.
Cookiecutter, Copier ve Plop gibi araçlar bu süreci otomatikleştirebilir. Şablon motorları önceden tanımlı yapılandırmadan proje yapılarını üretirken uzmanlaşmış oluşturucular uygulama büyüdükçe API uç noktaları, adaptörler, depo ya da testler gibi tekrarlayan bileşenleri ekleyebilir.
Bir üretim öncesi kanca proje adlarını ve yapılandırma seçeneklerini doğrulayabilir; bir üretim sonrası kanca bileşenleri kaydedebilir, bağımlılıkları başlatabilir, kodu biçimlendirebilir veya testleri çalıştırabilir. OpenAPI Generator gibi araçlar skeleti API arayüzleri ve istemci kodunu yerleşmiş sözleşmelerden üreterek tamamlayabilir.
Kodlama ajanları esnekliğe dair başka bir katman ekler. Sabit şablonlarla tam olarak tanımlanamayan alan-ağırlıklı uygulamalar üretebilir: yeni bir dolandırıcılık tespit iş akışı, belge çıkarma bileşeni ya da model çıkarım hizmeti.
Araç mühendisliği (harness engineering) üzerine son araştırmalar bu ortaya çıkan pratiğe ilginç bir bakış açısı sağlar. Galster ve arkadaşları 2.853 GitHub deposunda ajantılı kodlama araçları için yapılandırma mekanizmalarını inceledi; bağlam dosyaları, beceriler ve alt ajanlar gibi yaklaşımları belirledi. Bulguları geliştiricilerin kodlama ajanlarına sunulacak yönerme ve yeniden kullanılabilir yetenekleri biçimlendirmeye başladığını gösteriyor.
Önemli ayrım şudur: Deterministik oluşturucular öngörülebilir yapılar sağlar; kodlama ajanları ise bu yapılar içinde esneklik sağlar. Üretilen değişiklikler mimari bağımlılık kontrolleri, şem doğrulama, linting, tip kontrolü, güvenlik taraması ve otomatik testlerle değerlendirilebilir.
Kod üretiminin ötesinde kodlama ajanı araçları ajana varolan uygulamaları anlamaya ve değiştirmeye yardımcı olacak yeniden kullanılabilir yönerme, beceri, eklenti ve dış araçlar sağlayabilir. Örneğin CodeGraph gibi bir araç MCP üzerinden kod tabanının yapısını, bağımlılıklarını ve değişiklik etkisini ayırarak ajana değişiklik yapmadan önce yapılandırılmış bağlam sunar.
Bu yaklaşım mühendislik kararlarını ortadan kaldırmaz ya da her üretilen bileşenin doğru olacağını garanti etmez. Bunun yerine tekrarlayan kurulumu azaltır ve geliştiricilerin ile kodlama ajanlarının yapay zeka uygulamalarını oluşturabileceği, test edebileceği ve evrilebileceği daha tutarlı bir ortam yaratır.
Sonuç: Mühendislik Daha Da Önemli Hale Gelir
Kodlama ajanları yazılımın nasıl inşa edildiğini değiştiriyor. Bir zamanlar saatler gerektiren görevler artık kod üretebilen, depo değiştirebilen, test çalıştırabilen ve tam çözümler önerebilen sistemlere devredilebilir.
Ancak kodu üretmeyi kolaylaştırmak yazılımı mühendisliği kolaylaştırmaz. Sorumlulukların nasıl ayrılacağı, hangi bağımlılıkların kabul edileceği, neyin değiştirilebilir kalması gerektiği ve sistemin mevcut davranışı bozmadan nasıl evrileceğine dair yine de birinin karar vermesi gerekir.
Bu mimari temeller, yeniden kullanılabilir skeletler ve araçların bir araya geldiği yerdir. Temel mühendislik kararlarını ve öğrenilen dersleri yakalar. Skelet onları pratik bir başlangıç yapısına dönüştürür. Üretim araçları tekrarlayan geliştirme görevlerini otomatikleştirir ve doğrular; kodlama ajanı araçları ise yapay zeka destekli uygulamayı yönlendirecek yönerme, yetenek, araç ve kontrolleri sağlar.
Bu mekanizmalar mimari muhakemeyi yerine koymamalıdır. Onu daha açık, yeniden kullanılabilir ve doğrulaması kolay hale getirmelidir. Aksi halde yalnızca kod üretimini değil, aynı zamanda mimari hataların birikmesini de otomatikleştirme riski alırız.
Janus’a dönersek iyi mühendislik öğrenileni korumak için geçmişe, öngörüleceği tahmin etmek için geleceğe bakmayı gerektirir. Amaç daha çok ya da daha hızlı kod üretmek değil; uygulamaları talep, teknoloji ve ekipler değişirken anlaşılır, sürdürülebilir ve uyumlu kılmaktır.
Kod yazmak ne kadar kolaylaşırsa, inşa ettiğimiz şeyi mühendislik o kadar önem kazanır.
Podyskutuj o tym wydarzeniu w społeczności
Haber hakkındaki düşüncelerinizi, donanım deneyimlerinizi ve teknik sorularınızı topluluk üyeleriyle anlık olarak tartışın.
Twoja kolej.
Podziel się doświadczeniem, pytaniami i uwagami. Twój adres e-mail nie zostanie opublikowany.