Yapay Zeka Kodlama Ajanı Eklediğinizde Goulot Nereye Gitti?

Destek kuyruk dokuz dakikada bilet açıp, sonra dört saat kuyrukta bekletiyordu; kimse dokunmadan kalmıştı. Şu anda mühendislik takımlarında aynı hikaye tekrarlaniyor: kod dakikalar içinde yazılıyor, sonra kuyruk oluşuyor. Yapay zeka kodlama ajanı eklediyseniz ve takım throughput'u hemen hemen hiç hareket etmemişse, kırık bir araç bulmadınız. Gerçek kısıtlamanızı buldunuz ve o kısıtlama aradığınız yerde değil.

Bu yönü okumak 2026 mühendislik organizasyonlarında neler olup bittiğini anlamak için yararlıdır. Bir yapay zeka kodlama ajanı (sınırlı insan istemeden kodu planlayan, yazan ve genellikle test eden yazılım, aksine otomatik tamamlama tarzı yardımcılar), yazma adımındaki engeli kaldırır. Ancak yazma nadiren bir yazılım pipeline'ının poste limitant'ı (goulot adımı, bütün hattın throughput'unu belirleyen) değildir. Review, CI ve deployment genellikle öyledir. Kısıtlama olmayan adımı hızlandırdığınızda, daha fazla bitmemiş iş almazsınız. Sıradaki her şeyin önüne daha büyük bir kuyruk alırsınız.

Yapay Zeka Kodlama Ajanı Eklediğinizde Goulot Nereye Gitti?

2026 yılının iki endüstri veri seti aynı yönü göstermektedir. CircleCI'nin State of Software Delivery raporunda, ortanca takımdaki feature-branch throughput yıl içinde yüzde 15 arttı, ancak main-branch throughput (gerçekten üretim'e ulaşan değişikliklerin sayısı) aynı dönemde yüzde 7 düştü. Hattın başına giren daha fazla iş, arkasından çıkan daha az iş.

Ayrı olarak, GitLab'ın InfoQ tarafından kapsanan geliştirici araştırmasında, yanıtlayanların yüzde 85'i yapay zekanın goulotu kodu yazma adımından review ve doğrulama adımına kaydırdığını kabul etti; yüzde 79'u genel delivery sürecinin kodlama hızının arkasında kaldığını söyledi. Bu bir araç sorunu değil, ölçüm yapılmayan ve hareket eden bir kısıtlamadır.

Little's Law Kodun Daha Hızlı Yazılmasıyla İlgilenmez

Little's Law, bunun neden olduğunu ve bunun yazılıma özgü olmadığını söyler. Bir fulfillment merkezi'nin pick kuyruğu ya da hastane'nin taburcu süreciyle aynı matematiktir:

WIP = Throughput × Cycle Time

WIP devam eden iştir (açık PR'lar, review'da olan biletler, packed bekleyen siparişler). Throughput birim zaman başına tamamlanan birimlerdir. Cycle Time bir birimin başından sonuna kadar ne kadar sürdüğüdür.

Review kapasitesi değişmeden kod üretimini hızlandırın; başına daha fazla birim saati geri koyarsınız ve throughput değişmeyen bir aşamaya. WIP'in gitmesi gerekir. Açık-PR birikintisi, büyüyen merge kuyruğu ya da reviewer'lar farkları daha hızlı tarayor ve daha fazlasını kaçırıyor olarak yığılır. Bunların hiçbiri bedavaya değildir. Üç gün fazlasına bekleyen bir pull request hiçbir şey maliyeti değildir, bağlam maliyeti: yazar ilerlemişti, reviewer bütün değişimi yeniden yüklemek zorundadır ve rework bekleme uzarsa daha pahalı olur.

"Yapay Zeka Ajanı" Sadece Kodlama Adımında Görülmez

Bir şeyi ayırmak gerekir: "yapay zeka kodlama ajanı" altında karma yapılanlar. Bazı araçlar dar şekilde bir repo içindeki kodu yazmak ve değiştirmek için yapılmıştır. Diğerleri birden çok tasarlanmıştır: tek prompttan araştırma, tarayıcı ve belge oluşturmaya yanı sıra kod yazma modu ekleyerek.

Genspark ikinci tip: web'de tarama, slayt ya da belge oluşturma ve tek promptdan kod yazıp çalıştırabilen bir hiçbir kod "Süper Ajan" değildir. Bu çok yönlülük bir generalist için yararlıdır, ancak CI pipeline'ınızın içinde yaşayan ve gerçek kod tabanınıza karşı pull request açan amaca yönelik tasarlanmış araçlardan farklı bir araçtır. Aracın tasarımını araç'ını değil, pipeline'ınızın hangi aşamasında engelini açmaya çalıştığınız ile eşleştirin.

Manus daha ileri gider ve bir sanal bilgisayar (tarayıcı, terminal, dosya sistemi) içinde çalışır, multi-adımı görevleri uçtan uca planlar ve yürütür ve bitmiş bir sonuç geri verir. Ops takımı için bu yararlı bir zihinsel model: tüm bir iş birimini bitiren, adımın sadece hızlı bir kısmını değil, bitiren bir ajan, throughput'u gerçekten hareket ettiren olanıdır.

PCE: Ajanın Yardımcı Olduğunu Söyleyen Tek Sayı

Process Cycle Efficiency (PCE), value-added zamanın toplam cycle time'a oranıdır ve bir yapay zeka kodlama ajanının pipeline'ınızı iyileştirip goulotu hareket ettirip ettirmediğini kontrol etmenin en dürüst yoludur:

PCE = Value-Added Time / Total Cycle Time

Bir yapay zeka kodlama ajanı benimsemeden önce, mevcut bölünmeyi ölçün: tipik bir değişikliğin yaşam döngüsünün, ilk commit'ten production'da merge'e kadar ne kadarı aslında kod yazma ya da review'e harcandığından versus kuyrukta beklemeye karşı. Çoğu takım bu numarayı hiç çekmedi ve bunu bulduğunda şaşırıyor. PCE % 25 altında yazılım pipeline'larında yaygındır, bir değişikliğin toplam yaşam süresinin dörtte üçünün beklemede, çalışılmamada olduğunu anlamına gelir.

Rollout'tan 30 ila 60 gün sonra aynı ölçümü çalıştırın. PCE arttıysa, ajan gerçek kapasiteyi serbest bıraktı ve takımınız onu kullanıyor. Eğer PCE düz kaldı ya da düştüyse, ajan zaten hızlı bir adımı hızlandırdı ve ekstra çıktı kuyrukta oturuyor, bir Cuma'da biri açık PR'ları sayana kadar görünmez. Bu tam da bir yapay zeka analiz katmanının değerini kazanması gereken yer: PCE'nin hareket ettiğini bilmek yeterli değildir, hangi aşamanın farkı absorbe ettiği gereken verdict'i, ve bu Kanban panosunun bakış üzerine yavaş okur.

Review, Değil Ajanın Goulot Olduğunun Üç İşareti

Takımlar varsayım yerine ölçüm yapmaya başladıktan sonra tutarlı olarak beliren birkaç patern vardır:

• Açık PR sayısı arttı ancak merge sayısı düz kalıyor. Hatta giren daha fazla birim, aynı sayı çıkıyor. Değişmeyen bir kısıtlama önünde klasik WIP birikintisi.

• Ortalama PR boyutu arttı. Bir yapay zeka kodlama ajanı, tek bir geçişte tam bir özellik üreten, insan gibi artırarak yazandan daha büyük diff üretir. Daha büyük diff'ler PR başına review'de daha uzun alır ve bu, headcount ve satır başına review hızı aynı kalırsa bile reviewer throughput'unu küçültür.

• Zamanı ilk review'e tırmanış, approval'dan sonra merge'e kadar süre ile daha hızlı tırmanıyor. Bekleme çoğunlukla birinin bakışına başlamadan önce ise, bu bir queueing sorunu (yeterli review kapasitesi değil ya da review'ler önceliklendirilmemiş), review kalitesi sorunu değildir.

Bunların hiçbiri egzotik araç takip etmeyi gerektirmez. Git hosta'nın (GitHub, GitLab, Bitbucket) API'sından haftalık veri çekme, basit grafikler çizilmiş. Ajanı kullandığınız hafta ile karşılaştırıp trendi görmek yeterlidir. Veri tutarlı şekilde toplanıyorsa trend açık görülür.

Destek Kuyruğu Mühendislik Pipeline'ları Genellikle Kaçırıyor

Destek ve fulfillment operasyonları bu tam sorununun için AI kodlama ajanlarından daha uzun süredir savaşıyor ve düzeltme temiz şekilde genelleşir. Dokuz dakikada ilk-contact bilet cevaplayan ancak özel tier'a ulaşmak dört saat alan bir kuyruk, uzmanların yavaş olduğunu söyleyen bir resourcing hikayesi değildir. Bu hızlı tier'ın aşağı akışa göre aşırı kaynaklandığının, ve hızlı tier'dan daha fazla bilet çekmenin arkaya tier'ın kapasitesi değişene kadar yardımcı olmadığının işareti.

Mühendislik takımları bunu sürekli atlar çünkü kod review bir dashboard'daki bilet sayısı gibi bir kuyruk görülmüyor. Sessiz "review bekliyor" durumundaki açık PR'lar, somun fark edilene kadar fark edilmesi kolay değildir. Theory of Constraints (bir sistemin genel çıktısının, her adımın ayrı hızı toplamı değil, tek bir goulot adım tarafından sınırlandığı fikri) der ki, düzeltme hiçbir zaman "hızlı kısmı hızlandır" değil. Bu gerçek goulot bul, kapasitesini koru ve o zaman da hızlı kısmın daha çok hız gerektirip gerektirmediğine karar ver.

AI kodlama ajanı birkaç ay sonra daha fazla kod, daha hızlı gönderdiğinde göründüğü sessiz bir ikinci kısıtlama vardır: dokümantasyon sürüklemesi. Kimse yeni bir mühendise onboarding iki kat sürünceyene kadar fark etmez çünkü docslar üç sprint önce değişen bir sistemi tanımlar. GitBook gibi docs-as-code platform, ajanın commit ettiği repo'ya karşı senkronize olur, kâğıt izi kodun kendisinden daha geride düşmesini en azından engeller. Bu review goulutunu düzeltmez, ancak bir saniye birini karanlıkta oluşmasını durdurur.

Yapay Zeka Kodlama Ajanını Kasıtlı Olarak Yavaşlatmalı mısınız?

Bazen evet, ve bu herkesin heyecan duyduğu araç hakkında popüler bir şey söylemek değildir. Eğer review kapasitesi sonraki iki quarter için sabitlenmişse (headcount dondurulmuş, reviewer'lar zaten kapasitede), bir ajanın gelen PR'lerin oranını üçe katlaması, daha fazla bitmemiş, deploy özelliği oluşturmaz. Daha uzun bir kuyruk oluşturur ve yukarıda CircleCI verisine göre, düşük bir main-branch success oranı çünkü ses baskısı altında reviewer'lar daha az yakalar.

O durumda dürüst hamle, bir ajanın ne kadarını cycle başına oluşturmasını sınırlamak ya da çıktısını bir insan reviewer'a ulaşmadan önce bir pre-review pasına kapı tutmaktır (linting, otomatik test kapsamı kontrolleri, daha küçük diff politikası). Bu bir anti-AI konumu değil. Bu, hattınız yavaşlayıcı istasyonun absorbe edebileceğinden daha fazla birimi planlamadığı gibi bir mantıktır.

Gerçek kısıtlama reviewer dikkat değil headcount ise, Lindy AI gibi triage ve routing için yapılan workflow ajanları, inbox ve notification overload'u takımın gün boyunca işlediği, insan reviewer içinde gerçek review saatleri serbest bırakabilirler. Düzeltmenin "daha fazla reviewer işe al" ya da "daha fazla ajan koltuğu satın al" olduğunu varsaymadan önce test etmeye değer.

Ölçüm ve İyileştirme Döngüsü

Döngü şu şekildedir: Önce WIP ve cycle time'ı ölçün. Açık PR sayısı, review zamanı ortalaması, deployment sıklığı ve main-branch merge oranını izleyin. Bunu yapmak için git host'unuzun API'sinden (GitHub, GitLab, Bitbucket) haftalık veri çekin; çoğu zaten bu metrikler sunmaktadır. Ajanı pilot gruba 30 gün için dağıtın. Günlük ya da haftalık metrikler toplayın. 30 günün sonunda PCE'yi yeniden hesaplayın. Value-added time payı arttıysa, ajan etkili olmuş ve takımın gerçek goulot'u review kapasitesidir, o zaman review araçlarına, reviewer sayısına ya da automated approvals'e yatırım yapın. Eğer PCE düz kalırsa, throughput'u hareket ettirmek için goulot başka yerdedir. Ölçümün hiçbiri subjektif değildir; bu çok basit rakamlar, her hafta otomasyonla toplanır.

Sonra Gerçekten Nereye Yatırım Yapmalı?

Agent kullanımını daha da genişletmeden önce PCE hesaplamasını çalıştırın, sonra değil. Eğer value-added zamanın toplam cycle zamanı payı rollout'dan beri hareket etmemişse, daha fazla ajan koltuğu satın almayın henüz. Sonraki bütçe satırını review kapasitesine, CI throughput'una ya da merge-queue otomasyonuna koyun, veri sırasında gösterilen her şeyden hangisine ve 30 gün içinde numarayı yeniden çalıştırın.

Eğer PCE iyileşti ve review tempo tutarsa, bu ajanın scope'unu genişletmek için sinyal olur. Hızlıyı çalıştırmadan önce. AI kodlama ajanından gerçek throughput kazanımlar alan takımlar, onu en hızlı benimseyenler değil. Bunlar gerçek goulot'larını bulup oradaki kapasitesi düzeltip hızlı kısmı daha hızlı çalıştırma izni verenleridir.