Yeni Mühendislik İş Akışı: Agent'lar, Review'lar ve Daha Hızlı Yayına Almak

Bir coding agent artık dört dakikada 600 satırlık bir pull request üretebiliyor. Derleniyor. Testler geçiyor. Açıklaması düzgün, commit geçmişi temiz ve bütünüyle makul ölçüde doğru görünüyor. Peki bunu kim okuyor?

Bütün hikaye işte tam olarak bu soruda. Yazılımın tarihinin büyük bölümünde kıt olan kaynak, kod yazma eylemiydi: niyeti çalışan bir söz dizimine çevirmek yavaştı ve sürecimizdeki her şey — pair programming, kod sahipliği, “10x mühendis” efsanesi — yazmanın darboğaz olduğunu varsayıyordu. Agent’lar bu varsayımı sessizce ortadan kaldırdı. Kısıt kaybolmadı; yer değiştirdi. İşin birimi artık “yazılan satırlar” değil, “review edilen ve merge edecek kadar güvenilen değişiklikler.” Bu kaymayı bir kez içselleştirdiğinizde, ekibinizin pek çok alışkanlığı anlamını yitirir ve ihmal ettiğiniz birkaç tanesi de aniden taşıyıcı kolon haline gelir.

Yazmaktan yönlendirmeye

Agent kullanan kıdemli bir mühendisin gündelik işi, yazmaktan çok, hızlı, lafı düz anlayan ve biraz fazla özgüvenli bir avuç junior’dan oluşan küçük bir ekibi yönetmeye benziyor. Fonksiyonu siz yazmıyorsunuz; onu tarif ediyor, denemeyi izliyor ve denemenin doğru olup olmadığına karar veriyorsunuz. Önem taşıyan beceriler de buna göre değişiyor: bir problemi doğrulanabilir parçalara ayırmak, net bir kabul kriteri yazmak, yanlış bir yaklaşımı bir diff’in son 30 saniyesinde değil ilk 30 saniyesinde fark etmek.

Bu, tasarım ve review konusunda zaten güçlü olanlar için gerçekten iyi bir haber; değeri ham üretim hızı olanlar içinse can sıkıcı bir sürpriz. Bir agent yazma hızında herkesi geçer. Güvenilir biçimde yapamayacağı şey ise, üç makul tasarımdan hangisinin gelecek çeyreğin gereksinimleriyle temas ettiğinde ayakta kalacağını bilmek ya da o “temiz” refactor’ın, üç servis ötede yaşayan ve kendisine gösterilen kodun hiçbir yerinde bulunmayan bir invariant’ı az önce bozduğunu fark etmektir.

İş hiçbir zaman yazmak değildi. Agent’lar bunu sadece görünür — ve biraz da utandırıcı — hale getirdi.

Bizim için işe yarayan zihinsel model şu: agent’ı muhakemenizin yerine geçen bir şey olarak değil, onu kat kat artıran bir çarpan olarak görün. Bir değişiklik hakkındaki muhakemeniz bulanıksa, agent o bulanıklığı da çarpar. Tam olarak yanlış olan şeyi, son derece güzel bir biçimde, büyük bir özgüvenle inşa eder ve neden doğru olduğunu açıklayan bir paragrafla size sunar.

Review darboğazı yeni kısıt

İşte rahatsız edici aritmetik. Üretim 5 kat hızlanıp review aynı hızda kalıyorsa, ekibi 5 kat hızlandırmış olmazsınız. Aynı reviewer’ın önüne daha büyük bir iş yığını koymuş olursunuz. Throughput’u en yavaş aşama belirler ve artık en yavaş aşama güvenilir biçimde review’dur.

Daha kötüsü, review kalitesi hacim altında, görmesi zor bir biçimde bozulur. Bir öğleden sonrada on iki agent PR’ını onaylayan bir reviewer, on ikinciyi birinciyi review ettiği gibi review etmiyordur. Pattern eşleştiriyordur: testler yeşil, diff diğerlerine benziyor, LGTM. Bu review değil, üstüne birkaç adım eklenmiş bir lastik damgadır ve ince bir hatası olan bir değişikliğin, onay kısmında bir insanın adıyla yayına alınmasının tam da yoludur.

Dolayısıyla bir mühendislik lideri için kaldıraç sorusu artık “nasıl daha çok kod üretiriz” değil. O elinizde var. Soru şu: “değişiklikleri nasıl review etmesi ucuz ve güvenmesi emin hale getiririz.” Aşağıdaki her şey bunun hizmetinde.

Değişiklikleri review etmesi ucuz hale getirin

En yüksek etkili tekil hamle, diff’i küçültmektir. 600 satırlık bir agent PR’ı, onu kim ya da ne yazmış olursa olsun bir review yükümlülüğüdür; gerçekten kimsenin okumadığı 600 satırlık bir agent PR’ı ise gelecekteki bir incident’tır. Boyuta tıpkı insan bir yazara yaptığınız gibi karşı çıkın; ancak artık elinizde işi tek büyük PR yerine üç küçük PR olarak seve seve baştan yapan bir araç var — yani buna direnmemek için bahane yok.

• Bir PR, bir niyet. Açıklamada “ayrıca” kelimesine ihtiyaç varsa, ikiye bölün.
• Kabul kriterleri, diff’ten geriye dönük çıkarılarak değil, agent başlamadan önce yazılmış olmalı.
• Yetkin bir reviewer’ın tek bir oturuşta kafasında tutabileceği bir diff.
• Akıl yürütme (“neden bu yaklaşım”) PR gövdesinde yer almalı ki review yalnızca söz dizimi hakkında değil, karar hakkında olsun.

Testler ve CI güven katmanıdır

Review darboğazsa, otomatik doğrulama da her bir değişikliğin daha azını elle review ederek güvenle ilerlemenizi sağlayan şeydir. Bu, ekiplerin yeterince yatırım yapmayıp sonra pişman olduğu kısımdır.

Bir insan kod yazdığında, testler yazarın problemi anladığının kanıtıdır. Bir agent kod yazdığında ise testler, “çalıştığını iddia ediyor” ile “çalışıyor” arasında duran tek şeydir — ve agent, az önce eklediği bug’ı doğrulayan testleri de neşeyle yazar. Bu yüzden güvenilir desen, kontratı yazmayı insanlarda tutup agent’ın onu karşılamasını sağlamaktır. Önce davranışı belirtin, ideal olarak bir test ya da kesin bir kabul kriteri olarak, sonra agent’ın onu geçmesine izin verin:

# Human writes the contract:
def test_refund_rejects_amount_over_original_charge():
    order = make_order(charge_cents=5000)
    with pytest.raises(RefundExceedsCharge):
        refund(order, amount_cents=5001)

# Agent makes it pass. The test is the thing you actually review.

CI pipeline’ınız, her zamankinden daha çok önem taşıyan merge kapısı haline gelir: type check’ler, gerçek bir test suite’i, linting ve ideal olarak agent’ın oyunla kolayca geçemeyeceği bir katman — integration testler, property-based testler, gerçek şemalara karşı kontrat testleri. Güçlü CI’a sahip bir repo, agent çıktısına orantılı biçimde güvenmenizi sağlar. Kırılgan testlere ve %30 coverage’a sahip bir repo ise size hiçbir sinyal vermez; bu da her agent değişikliğinin tam bir elle okumayı gerektirdiği, dolayısıyla hiçbir şey kazanmadığınız anlamına gelir.

İşte bu yüzden agent dostu ve insan dostu repolar aynı repolardır. İyi dokümantasyon, net modül sınırları, hızlı ve deterministik testler, invariant’ları belirten okunabilir bir README — bunlar hem agent’ın işi ilk seferde doğru yapmasına hem de reviewer’ın bunu hızla doğrulamasına yardım eder. Buraya yapılan yatırım iki kez geri öder.

İnsanların sağlam biçimde döngüde kaldığı yerler

Her şey delege edilmemeli ve aksini varsaymak, ekiplerin canının yandığı yoldur. Çizdiğimiz sınır şu: agent’lar yerleşik bir tasarımın içindeki iyi tanımlanmış değişikliklerde mükemmeldir, tasarımın kendisinde ise güvenilmezdir.

Mimari, servis sınırları, veri modelleri ve auth, para, migration ya da silme işlemlerine dokunan her şey konusunda insanları yetkili tutun. Bunlar, o an yanlış yapması ucuz ama sonradan geri sarması yıkıcı derecede pahalı olan kararlardır — tam da agent’ın özgüveninin en tehlikeli olduğu kategori, çünkü gelecek yılın on-call nöbetinde onun bir derdi yok. Burada seçenekleri keşfetmek için agent’ları kullanın (“bu şema değişikliği için üç yaklaşım taslağı çıkar”) ama seçimin sahibi bir insan olsun.

Pratik kural: değişiklik ne kadar geri döndürülemezse, satır başına o kadar çok insan muhakemesi. Bir kez kullanılıp atılacak iç bir script %95 agent güdümlü olabilir. Müşteri ödeme token’larını nasıl sakladığınıza dair bir değişiklik ise, agent’ın yakın gözetim altında uygulamaya yardım edebileceği, ama kararını bir insanın verdiği bir karardır.

Yeni tuzaklar

Eski hata biçimleri ortadan kalkmaz; üzerine yenileri gelir ve çıktı bu kadar bitmiş göründüğü için bunlar daha sinsidir.

Review yorgunluğu en büyüğü — yukarıda ele alındı ve bunu bir disiplin sorunu değil, bir kapasite sorunu olarak açıkça adlandırmaya değer. Sınırsız sayıda diff’i iyi review etmeye kendinizi irade gücüyle zorlayamazsınız.

Sessiz scope kayması. Bir agent’tan bir bug’ı düzeltmesini isteyin; bu arada üç değişkeni yeniden adlandırabilir, alakasız bir fonksiyonu “iyileştirebilir” ve import’ları yeniden düzenleyebilir. Her değişiklik tek başına savunulabilir; toplamda ise gerçekten önem taşıyan o tek diff’i, review etmesi sıkıcı ve göz yumması kolay bir gürültünün altına gömerler.

Özgüvenli yanlış yollar. Hedefi yanlış okuyan bir agent durup sormaz — eksiksiz biçimde commit eder ve yanlış probleme tutarlı bir çözüm üretir. Ne kadar erken bakarsanız, düzeltme o kadar ucuz olur. Bir agent’ın planının ilk birkaç adımını izlemek, bir yanlış anlamaya dikilmiş bitmiş 500 satırlık anıtı review etmekten iyidir.

Gerçekten kimsenin okumadığı diff’ler. Sessiz olan. Onay bir refleks haline gelir, ikna işini yeşil tikler yapar ve üç hafta sonra bir postmortem’de, hiçbir insanın aslında gerçekten anlamadığı ortaya çıkan bir fonksiyonu okuyor olursunuz. Onayınız “bunu anladım ve savunurum” anlamına gelmiyorsa, hiçbir anlama gelmiyordur.

Bunun sizin için anlamı

Agent’ları gerçek bir ekipte benimsiyorsanız, iş “herkese bir coding agent verin” değildir. İş, iş akışını review ve güven etrafında yeniden tasarlamaktır:

• Gerçek bir Definition of Done yazın ve onu agent’ın brief’i yapın: kabul kriterleri, gereken testler, güncellenen dokümanlar. Diff öncelikli değil, spec öncelikli.
• Küçük PR’ları zorunlu kılın. İşi bölmek artık neredeyse bedava olduğuna göre, büyük diff’ler bir tercihtir — genellikle de kötü bir tercih.
• Güven katmanı olarak CI’a ve testlere yatırım yapın. Coverage ve determinizm artık birer hijyen değil; daha hızlı review’u güvenle yapmanızı sağlayan şeylerdir.
• İnsanları mimaride ve riskli yüzeylerde tutun. Implementasyonu delege edin, tasarımın ve geri döndürülemez kararların sahibi olun.
• Reviewer dikkatini bir bütçe gibi ele alın, sınırsız bir kaynak gibi değil. Üretim review’u geçiyorsa, elinizde bir hız kazancı yoktur — büyüyen bir kuyruk ve bir kalite uçurumu vardır.
• Repoyu okunabilir kılın. Dokümanlar, sınırlar ve invariant’lar agent’a ve reviewer’a eşit ölçüde yardım eder.

Agent’larla kazanan ekipler, en çok kodu üreten ekipler olmayacak. “Bir agent bunun çalıştığını iddia ediyor”dan “yayına alacak kadar güveniyoruz”a giden en ucuz yolu inşa eden ekipler olacak. Klavyedeki hız çözüldü. Yeni oyun, güvenle gelen hız ve bu hâlâ büyük ölçüde insana ait bir oyun.