Programlama ve Yazılım Geliştirme

Programlama ajanları CI'yi darboğaz haline getirdi; derleme hatlarını hızlandırmak tam çözüm değil

Makale, programlama ajanlarının artan üretkenliğinin sürekli entegrasyon üzerinde baskı oluşturduğunu, ancak sorunun yalnızca CI hatlarının yavaşlığıyla sınırlı olmadığını savunuyor. Yalnızca depoyu test etmek, dağıtık hizmetler arasındaki etkileşim hatalarını ortaya çıkaramıyor; bu nedenle sistem düzeyindeki doğrulamanın ajanın çalışma döngüsünün içine taşınması gerekiyor.

2026-10-04
4 dk okuma
6 görüntülenme
certi.news Editorial Team
Programlama ajanları CI'yi darboğaz haline getirdi; derleme hatlarını hızlandırmak tam çözüm değil

Programlama ajanlarının kullanımının yaygınlaşmasıyla sürekli entegrasyon (CI) yeni bir darboğaz haline geldi. Bu sonuç, tek bir araç duyurusuna değil, Anthropic, Linear ve Depot'taki mühendislik ekiplerinin eylül ayında aktardığı deneyimlere dayanıyor. Anthropic'te CI işlerinin hacmi altı ay içinde 25 kat artarken mühendisleri, bir çeyrek içinde 2021 ile 2025 arasında gönderdiklerinin yaklaşık sekiz katı kadar kod göndermeye başladı. Linear'da ise test paketinin hacmi ocak ayındaki seviyesinin yaklaşık dört katına yaklaştı; ajanlar artık testlerin çoğunu yazıyor.

Anthropic, yalnızca değişiklikten etkilenmesi muhtemel testleri çalıştırmak için test etkisi analizini kullandı; Linear ise hattını neredeyse tamamen yeniden tasarladı. Bu önlemler bekleme süresini azaltıyor, ancak sorunun yalnızca bir katmanını, yani depo taramasının hızını ele alıyor.

CI hızının neden artık yeterli olmadığı

CI tarihsel olarak insan çalışma biçimine göre tasarlandı: geliştirici haftada sınırlı sayıda birleştirme isteği açıyor, ardından başka bir göreve geçerken hattın sonucunu bekliyor. Ajan ise kodu, testleri ve birleştirme isteklerini paralel olarak oluşturabiliyor; bu da CI işlemlerinin sayısını katlayarak artırıyor. Makale, CI çalıştırıcıları satan bir şirket olan Blacksmith'in çalıştırdığı işlerin sayısında haftalık %5 ile %10 arasında büyüme gözlemlediğini belirtiyor.

İkinci sorun doğrulamanın konumu. Ajan değişikliği yazıyor ve ardından birleştirme isteği oluşturulduktan sonra sonucu bekliyor. Sonuç 20 dakika sonra geldiğinde bağlamını kaybetmiş olabilir; her sorun da yeni bir bekleme döngüsü anlamına geliyor.

Depo sistem değildir

Bağımsız uygulamalarda depo testi, sistem davranışına yakın bir görüntü sunabilir. Ancak bulut-yerel bir ortamda depo, onlarca hizmet içerebilen bir ekosistemdeki tek bir hizmeti temsil eder; sistemin geri kalanı ise çoğunlukla sahte arayüzler veya test verileriyle temsil edilir.

Bu nedenle bir değişiklik birim testlerinde başarılı olabilir, CI'dan geçebilir ve yalıtılmış bir ortamda çalışabilir; ardından hizmet sınırlarını aşan ilk gerçek istekte başarısız olabilir. Örnekler arasında başka bir hizmetin dayandığı bir alan adının değiştirilmesi, bir dizi yeniden denemeye yol açan zaman aşımının kısaltılması, test ortamında bir tablonun kilitlenmesine neden olan şema değişikliği veya tüketici hizmeti gerçekten çağırdığında farklı davranan bir uç nokta bulunuyor.

Makale, yapay zekâ kullanımının artmasını hem yazılım teslim sıklığındaki artışla hem de teslimattaki istikrarsızlıkla ilişkilendiren DevOps Research and Assessment (DORA) verilerine atıfta bulunuyor. Başka bir deyişle, kodu daha hızlı üretmek daha iyi doğrulamayı garanti etmiyor.

Pratikte ne değişiyor?

Önerilen çözüm CI'yi ortadan kaldırmak veya ajanları yavaşlatmak değil; doğrulamanın bir bölümünü ajanın çalışma döngüsünde daha erken bir zamana taşımak ve değişikliği yalnızca depo kopyasına karşı değil, gerçek sistem karşısında test etmek. Cursor gibi araçlar yalıtılmış bulut ortamları kullanıyor; Cursor'un birleştirdiği birleştirme isteklerinin %30'undan fazlası bu şekilde çalışan ajanlardan geliyor. GitHub Copilot cloud agent, Codex, Devin ve Greptile gibi diğer araçlar da kodu geçici ortamlarda çalıştırmanın farklı biçimlerini sunuyor.

Ancak bu ortamlar genellikle dalı, dalın ayarlarını ve kurulum betiğinin yükleyebildiği şeyleri içeriyor; diğer hizmetleri, gerçek mesaj kuyruğunu veya üretim verilerine benzeyen bir veritabanını içermiyor. Bu nedenle makale, döngünün kapandığını, ancak yanlış şeyin etrafında kapanabileceğini savunuyor.

Paylaşılan ortamlar ve kontrollü doğrulama

Makale, Kubernetes kümesi içinde hizmetlerin istikrarlı ve paylaşılan bir sürümünün çalıştırılmasını ve yalnızca değiştirilen hizmeti dağıtan hafif test ortamları oluşturulmasını öneriyor. Etiketlenmiş istekler bu hizmete yönlendirilirken diğer akışlar istikrarlı ve paylaşılan sürümlere bağlanıyor. Böylece çok sayıda ajan, sistemin tamamını her ajan için kopyalamak yerine ortamı paylaşabiliyor; makale, ortam maliyetinin tek bir konteynerin maliyetine yaklaşabileceğini ve çalıştırmanın saniyeler sürebileceğini tahmin ediyor, ancak kaynak bu tahminleri tüm ortamlarda doğrulayan bağımsız ölçümler sunmuyor.

Ortam tek başına yeterli değil. Platform ekiplerinin gönderilecek istekleri, toplanacak günlükleri ve kanıtlanması gereken sözleşmeleri belirleyen onaylı prosedürlere ihtiyacı var. Ayrıca testin temas ettiği hizmetler ve sonuçları kaydedilmeli; böylece kayıt, inceleme araçları ve birleştirme kapıları tarafından okunabilir hale gelmeli. Yazar, ajanların paylaşılan bir küme içinde güvenli olmayan işlemler gerçekleştirmesini önlemek için yönetişimin gerekli olduğunu vurguluyor.

certi.news açısından asıl değişim yalnızca CI'yi hızlandırmak değil, doğrulama «başarısı»nın ne anlama gelmesi gerektiğini yeniden tanımlamak. Depo testi önemini koruyor, ancak ajanların daha yüksek hızla ürettiği dağıtık sistemler için tek başına yeterli değil. Maliyet, yalıtım, veri güvenliği ve doğrulama doğruluğunun ölçülmesine ilişkin sorular açık kalıyor; ayrıca metin, doğrulanmış bir standart veya belirli bir ürün değil, analitik bir tez sunuyor.

Haber kaynağı
The New Stack - Software Development
Özgün kaynağı aç ↗
c
Yazar

certi.news Editorial Team

Aynı kategoride

Bunlar da ilginizi çekebilir

Tüm haberleri gör