Yazılım geliştirmede yapay zekâ araçlarından yararlanmak artık tek bir istem yazıp yanıtı beklemekle sınırlı değil. Geliştiriciler giderek tekrarlanan çalışma döngülerinden, çoklu ajanlardan ve modeli çevreleyip yönlendiren sistemlerden söz ediyor. GitHub Blog, Cassidy Williams’ın 2 Eylül 2026’da yayımladığı ve Marlene Mhangami ile GPS’in katıldığı GitHub Podcast’teki bir tartışmaya dayanan rehberinde bu kavramları düzenlemeye çalışıyor.
Bu terimlerin bazıları yeni pratikleri tanımlarken bazıları zaten var olan fikirlere güncel adlar veriyor; diğerlerinin anlamları ise hâlâ şekilleniyor. Bu nedenle rehber, bu kelimeleri nihai standartlar olarak değil, yazılım geliştirme ekipleri arasındaki süregelen tartışmayı anlamanın bir yolu olarak sunuyor.
Tek bir istemden döngü mühendisliğine
Döngü mühendisliği, bir ajandan her seferinde tek bir görevi elle gerçekleştirmesini istemek yerine, ajanların etrafında tekrarlanabilir sistemler tasarlamak anlamına geliyor. Verilen örnek; yeni proje sorunlarını alan, bunları özetleyip düzeltmeler öneren bir ajana ileten, ardından çıktıyı doğrulayan ve çözülemeyen durumları başka bir akışa yükselten zamanlanmış bir süreç oluşturmak.
Bu anlamda döngü, yapay zekâ için yapılandırılmış bir cron işlemine benziyor; ancak zamanlamadan daha fazla unsura ihtiyaç duyuyor. Rehber; belirli becerilere, davranış izlemeye, çıktıları doğrulamaya, görevleri yönlendirmeye ve müdahale ya da incelemenin yapılabileceği duraklama noktalarına işaret ediyor.
Ralph döngüleri ise döngü fikrinin daha basit ve doğrudan bir uygulaması. Ajana, çoğu zaman gereksinimlerden veya bir spesifikasyondan yola çıkan ayrıntılı bir görev tanımı veriliyor ve ajan görevin tamamlandığını düşünene kadar çalışmayı sürdürüyor. Bu yöntem, çalışmayı planlama, uygulama ve incelemeden oluşan tekrarlı döngülere ayırmaya yardımcı olabilir; ancak her döngü daha fazla belirteç, bağlam ve işlem gücü tüketirse maliyetli ve verimsiz hâle gelebilir.
Ekipler, filolar ve harness’ler arasındaki fark
Squad’ler ve filolar, çalışmanın birden fazla ajan arasında nasıl dağıtıldığını tanımlar. Ekip, farklı rollere sahip ajanlardan oluşur: biri planlar, diğeri planı inceler, üçüncüsü uygulamayı gerçekleştirir, dördüncüsü test eder ve beşincisi sonucu gözden geçirir. Filo ise aynı anda görevler üzerinde paralel çalışan ajanları ifade eder. Tam bir ekip paralel bir filo içinde çalıştırılabilir veya rolleri art arda düzenlenebilir.
Buradaki pratik fikir, her şeyi tek bir ajana vermek yerine uzmanlaşma ve paralellikten yararlanmak. Ancak birden fazla ajanın bulunması otomatik olarak daha yüksek kaliteyi garanti etmiyor; yazının kendisi de faydayı ekibin rolleri dağıtma, denetleme ve çıktıları doğrulama becerisine bağlıyor.
Çalışma paketi veya harness, modeli bir iş akışı içinde kullanılabilir hâle getiren ve onu çevreleyen her şeyi ifade ediyor: araçlar, izinler, bellek, bağlam ve görevler arasındaki koordinasyon. Rehber, GitHub Copilot’ı modelleri kod tabanlarına, düzenleyicilere, çekme isteklerine ve terminale bağlayan bir sisteme örnek olarak sunuyor. Çalışma paketi mühendisliği ise modelin çevresindeki bu sistemi tasarlamak ve iyileştirmek anlamına geliyor.
Geri bildirim yoluyla iyileştirme
Hill climbing terimi, geri bildirime dayanarak ajanları ve çalışma paketlerini kademeli biçimde iyileştirmeyi tanımlamak için kullanılıyor. Ekip, ajanın performansını değerlendirme testleriyle ölçerek başlayabilir; sonuçlar yeterince doğru olmadığında araçları, bağlamı veya yönlendirme mekanizmasını değiştirebilir.
Örneğin çekme isteklerini incelerken ölçüm, ajanın yalnızca bir yorum üretebilme becerisiyle sınırlı kalmaz; anlamlı hataları bulup yararlı öneriler sunup sunmadığını da kapsar. Buradaki pratik çıkarım şu: bir ajanı iş akışına eklemek son nokta değildir; bunun ardından sürekli bir ölçme ve düzenleme döngüsü başlar.
Roller ve modellerle ilgili terimler
Sahaya gönderilen mühendis, yapay zekâ dalgasından önce de var olan bir rolü tanımlar; örneğin müşterilerle doğrudan çalışan yazılım mühendisi, satış mühendisi veya çözüm mühendisi. Yapay zekâ bağlamında bu rol, ekiplerin araçları, iş akışlarını ve ajanları mevcut sistemlerine uyarlayıp entegre etmelerine yardımcı olur.
Kapalı modeller, kullanıcıya ağırlıklar, eğitim verileri veya eğitim yöntemi sunulmadan bir API ya da barındırılan ürün aracılığıyla kullanıma açılır. Açık ağırlıklı modeller, ağırlıkların indirilmesine ve yerel olarak ya da kullanıcının altyapısında çalıştırılmasına izin verir; ancak bu, verilerin ve eğitim yönteminin de mutlaka erişilebilir olduğu anlamına gelmez. Açık kaynak modellerinde ise erişim düzeyi daha ileri giderek modelin, kodun, verilerin ve eğitim sürecinin incelenmesini, yeniden kullanılmasını ve değiştirilmesini kapsar.
Bu rehber neden önemli?
Asıl değişim yalnızca yeni bir sözlüğün ortaya çıkmasında değil, tartışmanın “Model ne üretebilir?” sorusundan “Modelin etrafında tekrarlanabilir ve ölçülebilir bir sistemi nasıl kurarız?” sorusuna geçmesinde yatıyor. Bu, iş süreçlerinde ajan çalıştırmayı düşünen geliştirme ekipleri için önemli; çünkü terimi seçmek, izinlerin, doğrulama mekanizmalarının, insanların müdahale noktalarının ve tekrarlama maliyetinin belirlenmesinin yerini tutmuyor.
Bununla birlikte kaynak, terimlerin istikrarlı olmadığını kabul ediyor; bazıları yerleşebilir, bazıları ise ortadan kalkabilir veya daha kesin ifadelerle değiştirilebilir. Bu nedenle en önemli sorular pratik olmaya devam ediyor: İş akışı güvenilir biçimde tekrarlanabilir mi? Sonuçlar nasıl inceleniyor? İnsan ne zaman müdahale ediyor? Modele ne ölçüde güvenmek kabul edilebilir? Yazıya göre bu sorular, popüler hâle gelen her kelimeye ayak uydurmaktan daha önemli.