Netlify Agent Runners Nedir? Claude, Codex ve Gemini ile Kullanım

Netlify Agent Runners, Claude Code, OpenAI Codex ve Google Gemini gibi kodlama agent’larını bir Netlify projesinin gerçek deploy bağlamında çalıştırmaya yarayan yönetilen bir geliştirme akışıdır. Agent’a “bu erişilebilirlik hatasını düzelt”, “form doğrulamasına test ekle” veya “bu Deploy Preview’daki build problemini araştır” gibi bir görev verirsiniz. Agent izole bir ortamda repoyu inceler; Build modunda dosya değiştirir, test ve build çalıştırabilir, ardından değişiklikleri inceleyebileceğiniz bir Deploy Preview akışına taşır.

Bu özellik, insan review’unu ortadan kaldıran otonom bir yazılım mühendisi değildir. Agent’ın ürettiği diff, test sonucu ve açıklaması kanıt değil öneridir. Sağlıklı kullanım modeli; küçük görev, sınırlı izin, secret içermeyen bağlam, otomatik test, Deploy Preview, insan incelemesi ve gerektiğinde rollback zinciridir.

Öne Çıkanlar

• Agent Runners iki temel çalışma biçimi sunar: dosya değiştirebilen Build ve salt okunur Ask.
• Build için Git deposuna continuous deployment ile bağlı mevcut bir Netlify projesi gerekir.
• Dosya değişikliği üreten bir run, inceleme için Deploy Preview oluşturur.
• Her run izole bir sandbox ortamında yürütülür; buna rağmen repository, environment ve izin kapsamı dikkatle sınırlandırılmalıdır.
• Ağustos 2026 tarihli Netlify dokümanında Build modu kredi hesabı çalışma süresinin 2,5 katı, Ask modu ise 0,1 katı olarak açıklanır. Fiyatlandırma yayın günü yeniden kontrol edilmelidir.

Netlify Agent Runners Nedir?

Agent Runners, kodlama agent’ı ile hosting/deploy platformu arasındaki eksik bağlamı kapatmaya çalışır. Genel amaçlı bir agent yalnız repository dosyalarını görebilir; fakat gerçek projede build command, framework algılama, environment context, deploy logları ve preview davranışı da önemlidir. Agent Runners bu görevi Netlify projesi içinde başlatır ve sonucu Netlify deploy akışıyla ilişkilendirir.

Bu sayede tipik süreç şöyle işler:

``text Görev tanımı ↓ Agent seçimi ve mod ↓ İzole run ortamı ↓ Repo analizi / kod değişikliği / test / build ↓ Git değişikliği + Deploy Preview ↓ İnsan review’u ↓ Merge veya düzeltme isteği ↓ Production deploy / rollback ``

Değer yalnız “agent kod yazdı” noktasında değildir. Asıl değer; agent çıktısının mevcut Git ve Deploy Preview inceleme modeline girmesidir. Böylece ekip, değişikliği canlı siteye körlemesine göndermek yerine URL üzerinde test edebilir.

Build ve Ask Modları Arasındaki Fark

Build modu

Build modu repository dosyalarında değişiklik yapabilir. Küçük bir bug fix, test ekleme, refactor, dependency güncelleme veya UI düzeltmesi gibi görevler için kullanılır. Agent komutları çalıştırabilir, build sonucunu değerlendirebilir ve değişiklik ürettiğinde preview akışını başlatabilir.

Build modunu şu soruyla değerlendirin: “Bu görev sonunda review edilmesi gereken bir diff çıkacak mı? ” Cevap evetse Build uygundur.

Ask modu

Ask modu read-only çalışır. Kod tabanının nasıl işlediğini açıklamak, belirli bir dosyanın sorumluluğunu bulmak, build hatasının muhtemel nedenlerini sıralamak veya değişiklik yapmadan mimariyi analiz etmek için kullanılır.

Ask modu özellikle şu durumlarda daha güvenlidir:

• yeni ve yabancı bir repository’yi anlamak,
• değişiklik planı istemek,
• riskli migration öncesi etki analizi yapmak,
• “hangi dosyalar değişmeli?” sorusunu yanıtlatmak,
• doğrudan kod yazdırmadan önce kapsamı küçültmek.

İyi bir pratik, belirsiz görevi önce Ask modunda çözüm planına dönüştürmek; yalnız kapsam netleşince Build moduna geçmektir.

Hangi Agent’lar ve Proje Context’i Desteklenir?

Netlify’nin güncel ürün ve dokümantasyon sayfaları Claude Code, OpenAI Codex ve Google Gemini gibi desteklenen agent’ları listeler. Desteklenen agent kümesi ve her agent’ın erişebildiği özellikler değişebileceği için dashboard’daki güncel seçenekler yayın günü doğrulanmalıdır.

Build modu için temel proje koşulları şunlardır:

• Netlify üzerinde mevcut bir proje,
• Git sağlayıcısındaki bir repository’ye continuous deployment bağlantısı,
• çalışabilir bir build ayarı,
• review edilebilir branch/Deploy Preview akışı,
• görevi başlatan kullanıcı için gerekli ekip ve proje izinleri.

Agent’ın proje context’ini görmesi, her secret’ı görmesi gerektiği anlamına gelmez. Özellikle ilk denemede production API anahtarları, müşteri verisi, private package token’ları veya deployment credential’ları bulunmayan bir demo repository kullanmak daha güvenlidir.

Dashboard’dan Görev Nasıl Başlatılır?

Arayüz adları zamanla değişebilse de akış şu mantığı izler:

1. Netlify dashboard’da ilgili projeyi açın. 2. Agent Runners alanına gidin. 3. Build veya Ask modunu seçin. 4. Desteklenen agent’lardan birini seçin. 5. Görevi, kabul kriterlerini ve yasakları açıkça yazın. 6. İzin ve proje kapsamını kontrol edin. 7. Run’ı başlatın. 8. Log, açıklama, diff, test ve Deploy Preview sonucunu inceleyin.

Kötü görev:

> Siteyi daha iyi yap.

Daha iyi görev:

> ContactForm. tsx içinde boşluklardan oluşan mesajın geçmesini engelle. Mevcut davranışı değiştirmeden trim edilmiş değeri en az 10 karakter şartıyla doğrula. Vitest ile üç test ekle: geçerli mesaj, yalnız boşluk, 9 karakter. Başka dependency ekleme. Production environment variable’larına dokunma.

İyi görev tanımı şu parçaları içerir:

• dosya veya bileşen kapsamı,
• beklenen davranış,
• kabul testleri,
• değiştirilmemesi gereken alanlar,
• dependency ve secret kısıtları,
• maksimum diff beklentisi,
• başarı ölçütü.

Agent ne kadar güçlü olursa olsun belirsiz brief, belirsiz değişiklik üretir.

Agent Değişikliği Nasıl Deploy Preview’a Dönüşür?

Build run dosya değişikliği ürettiğinde Netlify bu değişikliği Git ve Deploy Preview akışına taşır.

1. Diff

Gerçekten istenen dosyalar mı değişti? Agent gereksiz refactor yaptı mı? Lockfile, config, dependency veya build script’i beklenmedik biçimde değişti mi?

2. Otomatik test

Test komutunun çalışması, testlerin anlamlı olduğu anlamına gelmez. Yeni test yalnız agent’ın kendi yanlış davranışını onaylıyor olabilir. Testin başarısız senaryoyu gerçekten yakaladığını kontrol edin.

3. Build ve log

Build başarıyla tamamlandı mı? Warning sayısı arttı mı? Bundle büyüdü mü? Environment farklılığı nedeniyle yalnız agent sandbox’ında geçen bir davranış var mı?

4. Deploy Preview

Preview URL’de masaüstü ve mobil akışı, form gönderimi, erişilebilirlik, yönlendirme, API endpoint’i ve browser console incelenmelidir. Görsel diff veya e2e test varsa review’a eklenebilir.

Deploy Preview, değişikliğin güvenli olduğunu garanti etmez. Yalnız production öncesi gözlemlenebilir bir deney ortamı sağlar.

İzinler, İzole Ortam ve Audit Nasıl Çalışır?

Netlify her Agent Runner run’ını izole bir sandbox içinde çalıştırdığını belirtir. İzolasyon, bir run’ın çalışma ortamını diğerlerinden ayırır; fakat yanlış izin verilmiş bir agent’ın erişebildiği repository içeriğini veya secret’ı sihirli biçimde güvenli yapmaz.

Uygulanması gereken en az ayrıcalık yaklaşımı:

• Agent Runners erişimini yalnız gerekli ekip üyelerine verin.
• İlk run’ları düşük riskli projelerde yapın.
• Production secret’larını agent görevi için zorunlu değilse sağlamayın.
• Auto-approval seçeneklerini varsayılan kolaylık olarak açmayın.
• Package install, dış ağ, dosya yazma ve komut çalıştırma yetkilerini değerlendirin.
• Her run’ın kim tarafından, hangi görevle, hangi agent ve modla başlatıldığını kaydedin.
• Git commit, PR yorumu, Deploy Preview ve merge geçmişini audit zinciri olarak koruyun.

Agent’ın bir komut için onay istemesi rahatsızlık değil güvenlik kontrolüdür. Çok geniş auto-approval listesi, bu kontrolü görünmez hale getirebilir.

Review, Düzeltme ve Merge Akışı

Agent çıktısına doğrudan “approve” vermek yerine küçük bir review şablonu kullanın:

Kontrol	Soru
Kapsam	Yalnız istenen sorun çözüldü mü?
Güvenlik	Secret, auth veya input validation zayıfladı mı?
Test	Negatif ve sınır senaryoları var mı?
UI	Deploy Preview’da beklenen davranış görüldü mü?
Performans	Gereksiz dependency veya request eklendi mi?
Geri dönüş	Değişiklik kolayca revert edilebilir mi?
Sahiplik	İnsan reviewer diff’i anlayabiliyor mu?

Git sağlayıcısındaki yorum veya review mekanizması üzerinden ek değişiklik istenebilir. Örneğin:

> Doğrulama doğru, ancak yeni regex Türkçe karakterli isimleri reddediyor. Regex eklemek yerine mevcut schema yaklaşımını kullan. Dependency ekleme ve yalnız ilgili testi güncelle.

Agent’ın ikinci turda verdiği yanıt da sıfırdan incelenmelidir. İlk sorunu düzeltirken başka bir alanı bozabilir.

Merge kararı insanda kalmalıdır. Özellikle authentication, ödeme, veri silme, migration, infrastructure config veya dependency major update değişikliklerinde ikinci reviewer mantıklıdır.

Rollback Nasıl Planlanır?

Rollback, agent kullanmaya özel bir özellik değildir; fakat agent değişikliğinin üretime hızlı ulaşabilmesi nedeniyle daha önemlidir.

Güvenli geri dönüş planı:

1. Değişikliği küçük ve tek amaçlı tutun. 2. Merge öncesi son başarılı production deploy’u kaydedin. 3. Feature flag mümkünse kullanın. 4. Database migration’ı geriye uyumlu tasarlayın. 5. Production gözlem süresi ve hata eşiği belirleyin. 6. Sorunda Git revert veya Netlify deploy rollback yöntemini kullanın. 7. Revert sonrası cache, function ve veri şeması etkisini doğrulayın.

Yalnız site dosyasını eski deploy’a döndürmek, agent’ın yaptığı irreversible veri migration’ını geri almaz. Bu nedenle Agent Runners ilk kullanım alanı olarak veri kaybı riski taşıyan görevler seçilmemelidir.

Kredi Tüketimi Nasıl Hesaplanır?

Ağustos 2026’da Netlify dokümanındaki hesaplama mantığı şöyledir:

• Build mode: çalışma süresi × 2,5 kredi
• Ask mode: çalışma süresi × 0,1 kredi

Örneğin 12 dakikalık bir Build run teorik olarak 30 kredi; 12 dakikalık Ask run ise 1,2 kredi tüketir. Bu örnek yalnız çarpanı açıklamak içindir. Yuvarlama, dahil kullanım, ek build/AI maliyetleri ve plan kuralları için güncel billing ekranı esas alınmalıdır.

Kullanım kontrolü için:

• görevi küçük parçalara ayırın,
• önce Ask ile plan çıkarın,
• sonsuz retry veya belirsiz görevden kaçının,
• aynı sorunu üç agent’a sürekli göndermeyin,
• run süresi ve kredi kaydını tutun,
• ekip bütçe alarmı ve limitlerini kullanın,
• başarısız run’ı tekrar başlatmadan önce logu okuyun.

Ucuz run, doğru run demek değildir. Agent daha hızlı bitirip daha çok insan düzeltmesi gerektiriyorsa toplam maliyet daha yüksek olabilir.

Claude, Codex ve Gemini Nasıl Karşılaştırılmalı?

“En iyi agent hangisi? ” sorusunu tek bir demo prompt’la cevaplamak yanıltıcıdır. Aynı küçük bug fix iki desteklenen agent ile, aynı repo commit’i ve aynı kabul kriterleri altında denenmelidir.

Örnek test görevi:

> Vite + TypeScript demo uygulamasında iletişim formu boşluklardan oluşan mesajı kabul ediyor. En küçük diff ile düzelt, üç Vitest testi ekle, dependency ekleme ve UI metinlerini değiştirme.

Kayıt tablosu:

Metrik	Agent A	Agent B
Run süresi	Ölçülecek	Ölçülecek
Tüketilen kredi	Ölçülecek	Ölçülecek
Değişen dosya	Ölçülecek	Ölçülecek
Eklenen/silinen satır	Ölçülecek	Ölçülecek
Test sonucu	Ölçülecek	Ölçülecek
Build sonucu	Ölçülecek	Ölçülecek
İnsan düzeltme turu	Ölçülecek	Ölçülecek
İstenmeyen değişiklik	Not edilecek	Not edilecek
Deploy Preview kontrolü	Not edilecek	Not edilecek

Başarı puanı yalnız hızdan oluşmamalıdır. Örnek ağırlıklandırma:

• doğruluk ve kabul kriteri: %35,
• test kalitesi: %20,
• diff sadeliği: %15,
• güvenlik/kapsam disiplini: %15,
• insan düzeltme ihtiyacı: %10,
• süre ve kredi: %5.

> Editör notu — zorunlu özgün test: Bu taslak hazırlanırken Claude, Codex veya Gemini ile gerçek Agent Runners run’ı çalıştırılmadı. Yayından önce secret içermeyen tek bir demo repository, sabit commit, aynı prompt ve aynı kabul kriterleriyle en az iki desteklenen agent test edilmelidir. Run ID, tarih, agent sürümü/etiketi, mod, süre, kredi, diff, test, build, Deploy Preview ve insan düzeltme sayısı gerçek değerlerle eklenmelidir. Sonuç çıkmazsa bu da açıkça yazılmalıdır.

Agent Runners Ne Zaman Kullanılmamalı?

Şu görevlerde ilk tercih olmamalıdır:

• production database’i doğrudan değiştiren migration,
• ödeme veya kimlik doğrulama altyapısı,
• yüksek yetkili secret gerektiren işlem,
• belirsiz “tüm mimariyi düzelt” görevi,
• test ve review sahibi olmayan ekip,
• lisans veya hukuki etkisi anlaşılmayan kod üretimi,
• kritik incident sırasında kontrolsüz geniş değişiklik,
• repository içinde müşteri verisi veya gizli dosya bulunan proje.

Bu alanlarda agent önce Ask modunda analiz, checklist veya küçük PoC üretebilir. Nihai değişiklik deneyimli geliştirici ve güvenlik review’u gerektirir.

Küçük Ekipler İçin Önerilen Çalışma Politikası

Başlangıç politikası şu kadar basit olabilir:

1. Yalnız low-risk repository. 2. Önce Ask, sonra gerektiğinde Build. 3. Tek görev, tek PR, küçük diff. 4. Production secret erişimi yok. 5. Otomatik test zorunlu. 6. Deploy Preview manuel kontrolü zorunlu. 7. En az bir insan approval. 8. Migration ve auth değişikliğinde ikinci reviewer. 9. Merge sonrası gözlem ve rollback sahibi. 10. Aylık süre, kredi ve düzeltme oranı raporu.

Bu politika, agent kullanımını yavaşlatmak için değil ölçülebilir hale getirmek için vardır.

Resmî Kaynaklar

• Netlify Agent Runners ürün sayfası
• Agent Runners overview
• Agent Runners ile değişiklik yapma
• AI özellikleri için güvenlik ve gizlilik
• Kredi tabanlı planlar için billing FAQ
• Agent Runners video referansı

Sonuç

Netlify Agent Runners, Claude, Codex ve Gemini gibi kodlama agent’larını gerçek Git, build ve Deploy Preview bağlamına taşıdığı için sıradan bir sohbet arayüzünden daha operasyonel bir model sunar. Yine de güvenli sonuç; doğru agent adından değil, küçük görev, Ask/Build ayrımı, en az ayrıcalık, izole run, test, diff review, Deploy Preview ve rollback disiplininden gelir. Agent’ın hızı insanın sorumluluğunu azaltmaz; yalnız iyi kurulmuş bir review sürecini hızlandırabilir.

Agent Runners workflow’unu secret içermeyen bir demo repoda değerlendirmek için ücretsiz hesap oluşturabilirsiniz: https://join. netlify. com/wmkqymu1heo2. Bu bir iş ortaklığı bağlantısıdır; bağlantı üzerinden kayıt olmanız veya ücretli plana geçmeniz halinde Ortak Alan komisyon kazanabilir.