Phronesis ve AI Kodlama Ajanları: Modelin Size Veremeyeceği Beceri

AI kodlama ajanları kod yazma maliyetini neredeyse sıfıra indirdi. Ne kadar kod yazılması gerektiğini ve ne zaman yazılması gerektiğini bilmenin maliyeti ise kıpırdamadı. Bugünkü “AI verimliliği” tartışmasının büyük kısmı, insanların bu iki beceriyi birbirine karıştırarak birbirlerini yanlış anlamasından ibaret. Aristoteles’ten ödünç alınan bir çerçeve bu iki beceriyi temiz biçimde ayırıyor; Mario Zechner, Addy Osmani, Kent Beck, Simon Willison, METR ve Steve Yegge bu çerçeve üzerinden okunduğunda görünürdeki çelişkiler tek bir anlaşmazlığa iniyor. O anlaşmazlıkta Zechner doğruya Yegge’den daha yakın duruyor; ama Yegge’nin karşıt pozisyonu argümanı körleştirmek yerine keskinleştiriyor.

Tartışmanın Sürekli Karıştırdığı İki Beceri#

Birden 300 km/s yapabilen bir araba, sizi o hızda sürmeye zorlamaz. 300 km/s’te ince manevra yapamazsınız. Dar, kıvrımlı yollarda kontrolü kaybedersiniz. Ne zaman hızlı, ne zaman yavaş olunacağını bilmek başlı başına bir beceridir ve bu beceri arabanın içinde değildir.

AI kodlama ajanları hız limitini kaybetmiş bir araba gibi. Artefakt üretmek, fonksiyonu yazmak, çalışan implementasyonu çıkarmak artık neredeyse bedava. Ama o kodu bu codebase’de, bu on-call rotasyonuyla, bu müşteri profili için üretip üretmemek farklı ve değişmeyen bir beceridir; hız sorusu artık kapandığına göre, tartışmaya değer olan bu ikinci beceridir.

Aristoteles’in bunun için temiz bir adı vardı. Nikomakhos’a Etik’in VI. Kitabı’nda üç entelektüel erdemi ayırır: episteme (matematik gibi değişmez bilgi), techne (zanaat, bir çömlekçinin ya da bir React geliştiricinin sahip olduğu üretme bilgisi) ve phronesis (pratik bilgelik; bu durumda, bu kısıtlarla, bu amaç için ne yapılacağına dair müzakere). Yaşanmış vakaların deneyimini gerektiren erdem phronesis’tir. Aristoteles bunu açıkça söyler: bir genç parlak bir geometrici (episteme) ya da yetenekli bir zanaatkâr (techne) olabilir; ama phronesis sahibi olamaz, çünkü phronesis sonuçları görülmüş gerçek vakalardan biriken yargıdan inşa edilir.

Çerçeve bu. Ajanlar techne’nin marjinal maliyetini düşürüyor; phronesis’in gerektirdiği hiçbir şey ise ne model ağırlıklarında yaşıyor ne de bir CLAUDE.md dosyasına ya da “skill”e tam olarak kodlanabiliyor. Claude Code ya da Cursor’u her gün kullanıyorsanız, onlarla gerçek özellikler ship ettiyseniz ve en az bir kez ajanın kendinden emin biçimde yanlış yaptığı bir şeyle başınız belaya girdiyse, önemli olan iddia şu: “AI’ı daha çok kullan” ve “AI ile yavaşla” çelişkili tavsiyeler değil. İki farklı sorunun cevapları ve yukarıdaki çerçeve hangi soruya baktığınızı anlamanın yolu.

Uzman Görüş Ayrılıklarının Kökü#

Bu alandaki en gür sesleri yan yana okuduğunuzda çelişkili görünürler. Değiller. Hepsi aynı tek ayrımdan, farklı yanlardan bahsediyor.

• Addy Osmani’nin 70/30 ayrımı. Osmani’nin iddiası şu: AI ajanları bir görevin ilk yüzde 70’ini (techne, artık ucuz) mükemmel, son yüzde 30’unu (güvenlik, edge case’ler, sürdürülebilirlik, uyum; phronesis, hâlâ pahalı) kötü yapacak.
• Kent Beck’in ajanlarla TDD’si. Beck, ajanlarla eşleştirildiğinde TDD’ye “süper güç” diyor ve ajanların testi geçirmek için testi silmeye hazır olduğu konusunda uyarıyor. Test, dışsallaştırılmış phronesis: ajan, phronetic bir şartnameye karşı techne öğütüyor.
• Willison işi “telefonundan ship ediyor”; çünkü repoları hızlı testlere, sıkı linter’lara, type check’lere, preview ortamlarına ve korumalı branch’lere sahip. O daha hızlı koşmuyor; scaffolding’i phronesis’i onun adına tutuyor, böylece techne’yi ajana verebiliyor. O hız önceden satın alınmış.
• METR’in yüzde 19 yavaşlama bulgusu. METR’in 2025 randomize çalışması, tanıdık repolarda AI ajanları kullanan deneyimli geliştiricileri ölçtü. Katılımcılar yaklaşık yüzde 24 daha hızlı olacaklarını tahmin ettiler. Yaklaşık yüzde 19 daha yavaş oldular; ve deneyden sonra bile yaklaşık yüzde 20 daha hızlı hissettiler. METR’in Şubat 2026 takip yazısı örnekleme uyarılarını kabul ediyor (deneyimli geliştiriciler, tanıdık kod; AI yardımı için en kötü senaryo). Algı boşluğu, akıcı techne hissini phronesis sonucu sanmaktan kaynaklanır.
• Zechner’in argümanı: ajanlar hataları insanların yakalayabileceğinden hızlı biriktiriyor; disiplin, görevleri dar kapsamlamak ve her gün diff okumaktır.
• Yegge’nin “kod bir sıvıdır” pozisyonu, kısaca, orkestrasyon katmanının yargıyı emeceği, darboğazın organizasyonun ajan çıktısını absorbe edebilme becerisi olduğu ve koda bakmayı bırakmanız gerektiği yönünde. Yegge phronesis’in tooling katmanına taşınabileceğine bahse giriyor; yukarıdaki herkes taşınamayacağına. Gerçek anlaşmazlık burada.

Yani altı pozisyon, iki uçlu tek bir eksene indirgenir. Bir uçta: phronesis insanda kalır. Diğer uçta: phronesis tooling katmanına göçer. Zechner, Osmani, Beck, Willison ve METR birinci uçta (farklı operasyonelleştirmelerle) toplanıyor. Yegge ikinci uçta duruyor.

Tartışmanın Sentezi#

Yegge’den çok Zechner’e yakın; ama Yegge’nin gerçekte savunduğu şeye saygıyla. Nedeni şu.

Phronesis sonuç-biçimlidir. Bu kodun bu durumda, bu sisteme ship edilip edilmeyeceğine dair yargı, sonra ne olacağına dair bir yargıdır ve orkestratörün göremediği yerlerde gerçekleşir. Bir model diff’i görebilir. Bir model on-call rotasyonunu, az önce migrate edilen müşteriyi, bu çeyrek yeni sorular soran regülatörü, gelecek sprint’teki yarım kalmış refactor’ü, altı ay sonra context olmadan bunun bakımını üstlenecek junior takım arkadaşını göremez. Kod değişikliğinin sonuçları orkestratörün görüş alanının ötesinde, akışın aşağısında yaşar; üstelik modelin eğitim verisinden daha hızlı değişen yerlerde.

Yegge’nin argümanının gerçek bir versiyonu ve zayıf bir versiyonu var. Gerçek versiyon: spec’ten yürütmeye olan döngü artık olağanüstü ucuz; “koda bakmayı” mühendisliğin merkezi eylemi saymak yakında “delikli kart okuyucuyu beslemeyi” merkezi saymak kadar anakronik olacak. Bu döngü hakkında haklı. Zayıf versiyon ise bunun “koda bakmana gerek yok”a genellemesi. Genellemiyor; çünkü spec’ten yürütmeye olan döngü tek döngü değil. Bir de sonuçtan spec’e döngü var ve o döngü orkestratörün hiçbir bilgisi olmayan bir geleceğe dair insan yargısından geçiyor.

Pozisyon şu: Yegge bir döngünün hızı hakkında haklı, hangi döngünün yük taşıyan olduğu hakkında yanlış. Zechner yük taşıyan döngü hakkında haklı, diğer döngünün ne kadar ucuzladığını biraz hafife alıyor. Sentez, Osmani’nin 70/30’u, Beck’in TDD ritmi ve Willison’ın scaffolding’i; üçü de phronesis’i farklı yerlerde kurumsallaştırarak techne’nin güvenli olduğu yerlerde özgür koşmasına izin veriyor.

Algı Boşluğu#

Bu codebase’de ajanlarla çalışmaktan kısa bir not. Hızlı hisseden bir refactor vardı. Ajan yaklaşık yirmi dakikada çalışan bir diff üretti, testler geçti, preview deploy doğru göründü; kısa süre sonra “merge”in o tatmin edici tıkı geldi. İki gün sonra, şartnamede olmayan küçük bir phronesis parçası (belirli bir Astro content collection edge case’inde build-time davranışı) hiçbir testin izlemediği bozuk bir sitemap girdisi olarak yüzeye çıktı. Düzeltme, orijinal “hızlı” değişiklikten daha uzun sürdü. Orijinal değişiklik hızlı hissettirdi çünkü techne kısmı hızlıydı. Birisinin boşluğu fark ettiği kısmı dahil, tüm operasyon hızlı değildi. METR bulgusu genelleşir: akıcı kod üretme hissi, doğru kodu üretme sonucuyla aynı sinyal değildir.

Bu olay alışılmadık değil; METR verisinin tarif ettiği şeyin, tek bir kişinin başına geldiğinde aldığı doku. Dashboard “hızlı” diyor çünkü techne hızlı, ama üretim sistemi farklı bir zaman ölçeğinde çalışıyor.

Phronesis Temelli Bir Karar Çerçevesi#

Herhangi bir ajan görevinden önce sorulmaya değer sorular phronetic sorular. Hız, cevapların bir sonucu olarak ortaya çıkar.

Ağacın kökünde iki phronetic soru var. Görevi kapsamlayabilir misin? Bozulursa bedelini kim öder? Hız ancak ikisi cevaplandıktan sonra devreye giriyor. Bir hız seçip sonra görevin o hızda güvenli olup olmadığını kontrol etmiyorsunuz. Durumu okuyorsunuz; durum hızı belirliyor.

Dallar kabaca bir sonuç merdivenine karşılık geliyor:

Bağlam	Önerilen hız	Neden
Atılabilir prototip, kullanıcı yok	Tam ajan otonomisi	Zararı yalnızca siz görürsünüz
İç araç, küçük etki alanı	Ajan taslağı, insan incelemesi	Başarısızlık can sıkıcı, kayıp değil
Müşteriye dönük, geri alınabilir	Ajan destekli, eşli inceleme	Başarısızlık rollback’tir
Müşteriye dönük, geri alınamaz (ödeme, veri migration, auth)	Elle yazılmış ya da yakından denetlenmiş	Başarısızlık haberlere düşer
Public API, kütüphane, altyapı	Phronesis-önceliği; ajan sadece boilerplate için	Hata bedelini başkaları öder

Dikkat edilmesi gereken asimetri: birinci satırda fazla temkinli olmanın bedeli küçüktür (gereğinden fazla dikkat harcadınız). Beşinci satırda fazla hızlı olmanın bedeli, sizin hızınıza onay vermeyen insanlar tarafından ödenir. Bu asimetri, güvenli varsayılanın tablonun altında yavaşlamak olmasının nedenidir.

Scaffolding’e Kodlanmış Phronesis#

Willison’ın “telefonundan ship eder” durumu bu alandaki en yararlı operasyonel iddia; çünkü tercihin aslında “insan ya da ajan” olmadığını gösteriyor. Tercih, “phronesis nerede yaşıyor”dur. Sadece kafanızda yaşıyorsa, her merge’de orada olmak zorundasınız. Scaffolding’de yaşıyorsa (testler, type’lar, lint’ler, CI gate’leri, build-time kontroller, korumalı branch’ler, preview deploy’lar), ajan scaffolding’in çizdiği rayların içinde hızla hareket edebilir.

Bu sitenin build pipeline’ından somut bir örnek. Blog yazılarındaki Mermaid diyagramları build zamanında SVG’ye render ediliyor, içerik hash’iyle cache’leniyor ve statik markup olarak ship ediliyor. Bir diyagram parse edilemezse build yüksek sesle başarısız oluyor. Bu sofistike bir mühendislik parçası değil; bir rehype plugin’i ve bir cache dizini. Yaptığı şey, bir phronesis parçasını (“bu diyagram, sürprizler olmadan, production runtime’da gerçekten render edilebilmeli” yargısını) reviewer’ın kafasından çıkarıp build’e taşımak. Bir ajan artık Mermaid diyagramı önerebilir; build ya kabul eder ya reddeder; tasarruf edilen insan zamanı gerçek.

Aynı ilke bir kademe yukarıda da geçerli. Astro Content Collections, frontmatter şemalarını build zamanında zorluyor; yani category alanını halüsinasyon eden ya da bozuk bir date üreten ajan bunu repoya geçiremiyor. Phronesis (“yazılarda geçerli frontmatter olmalı, yoksa build başarısız”) reviewer’da değil, şemada. Pattern genelleşiyor:

• Build’de şema doğrulaması. “Ajan bir alanı unuttu”yu insan yakalamasından makine yakalamasına taşıyın.
• CI gate olarak test sayısı regresyonu. Beck’in uyarısı. Test sayısı commit’ler arasında düşüyor ve diff bir özelliği silmemişse build başarısız olsun.
• En sıkı ayardaki type check’ler. TypeScript’in strict modu kodlanmış phronesis. Kullanın.
• Zorunlu inceleme isteyen korumalı branch’ler. Ajan kendini merge edemez. Reviewer in-the-loop phronesis’in mümkün en küçük parçası ve opsiyonel olmamalı.
• PR başına preview ortamı. Reviewer’ın phronesis’i çalışan bir artefakta uygulamasını sağlar.
• Token bütçesi şişmesi için pre-commit hook. Bir ajanın yüklediği CLAUDE.md ve skill seti de phronesis ister: sıkı bir set seçin, “awesome list” değil. (Bu konuda daha fazlası: Why Copying Others’ Claude Code Skills Doesn’t Work.)

Her biri, reviewer’ın kafasından kaldırılıp bir check’e dondurulmuş bir phronesis parçası. Bileşik etki: insan makinenin kontrol edemediği şeyi inceler, makinenin yakalaması gerekeni yeniden kontrol etmek zorunda kalmaz.

Çerçeveyi Pratiğe Döken Alışkanlıklar#

Aşağıdaki her alışkanlık yukarıdaki uzmanlardan birine bağlı. Ekibinize uyanları seçin; amaç phronesis’i loop’unuzda bir yerde açık kılmak.

Önce kapsamla, sonra serbest bırak (Zechner). Ajanı çalıştırmadan önce sınırlı görevi, kabul testini ve rollback planını yazın. Görevi üç cümleye sığdıramıyorsanız, görev delege edilemeyecek kadar büyük.

# Ajan görev kapsamı
- Ne: POST /orders için idempotency key işlemi ekle
- Bittiği koşul: testteki 100 yinelenen istek 1 sipariş üretir, aynı yanıtı döner
- Rollback: tek commit'i geri al; bu kapsamda schema migration yok

Beck’in pratiği şu: yargıyı önce başarısız bir teste dışsallaştırın, ajan koda dokunmadan önce elle yazılmış olsun. Ajanın ona karşı implement etmesine izin verin, sonra commit’ler arasında test sayısı düşerse başarısız olan bir CI gate ekleyin. Gücü ajan getirir; test ise ray.

Otonomiden önce scaffolding’e yatırım yap (Willison). Ajanın izinlerini yükseltmeden önce build’in katılığını yükseltin. Lint’i, type check’i, şema doğrulamayı, preview deploy’u ekleyin. Ajanın güvenli hızı, scaffolding’in onun hatalarını yakalama becerisiyle sınırlıdır. Build’in neyi yakaladığını ifade edemiyorsanız, ajanın o hızda güvenli olmasının nedenini de ifade edemezsiniz.

Zechner’in bir başka alışkanlığı, günün diff’ini kendiniz okumak; her gün, günde otuz dakika. Özet techne raporudur; diff, gelecek maintainer’ın okuyacağı artefakttır. Testlerin kapsamadığı küçük, kendinden emin yanlış seçimleri yakalar; algı boşluğu birikmeden önce yüzeye çıkarır.

Hızı sonuca eşle. Durumu okuyun; hızı seçin. Hata, dünün hızının bugünkü göreve sonuç profilinin değişip değişmediğini kontrol etmeden taşınmasına izin vermek.

Phronesis’in Atlandığı Yerler#

Tekrarlayan birkaç hata modu, bu araçları kullanan diğer ekiplerle yapılan sohbetlerde ne sıklıkta görüldüklerine göre sıralı.

• Hız hissini gerçek hızla karıştırmak. METR bulgusu kanonik örnek; ama genelleşir. Tek sinyaliniz “bu hızlı hissettirdi” ise techne’yi ölçüp verimlilik diyorsunuzdur. İş akışı başına en az bir sonuç metriği takip edin.
• Phronesis’i CLAUDE.md’ye kodlamak ve uyulacağını varsaymak. Dosya modele bir ipucu. Asıl kısıt test, type check ve CI gate’dir; yargının yaşadığı yer orasıdır.
• Ajanların testleri geçirmek için silmesine izin vermek. Beck bunu doğrudan işaret etti. Test sayısı regresyonunda başarısız olan bir pre-commit hook ya da CI gate ekleyin. Ajan baskı altında en az direnç gösteren yolu seçer; başarısız testi silmek en az direnç gösteren yoldur.
• Diff incelemesini başka bir ajana havale etmek. Ajanların ajanları incelemesi, aynı kör noktayı iki yönde birden büyütür. Merge edilen her değişiklik için en az bir insan gözü, üstünkörü bile olsa, ayda yalnızca bir hata yakalasa bile.
• “Bunu ajanla yapabilirim”i “bunu ajanla yapmalıyım” ile karıştırmak.
• Birisi öyle yapıyor diye 12 MCP sunucu, 50 skill’lik bir setup kurmak. Bu cargo cult’tur ve kendisi bir phronesis yokluğudur: bir ajanın neyi yüklediğine karar vermek, işinizin neye gerçekten ihtiyacı olduğuna dair bir yargıdır. Token bütçesi matematiği için bkz. Why Copying Others’ Claude Code Skills Doesn’t Work.
• Sadece techne metrikleri takip etmek. Satır sayısı, PR throughput’u, “AI kabul oranı” hepsi techne metrikleri. En az bir phronesis nitelikli sinyal ekleyin: ajan yazımı PR’larda ilk olaya kadar geçen süre, otuz gün içindeki rework oranı, ship edilen özellik başına on-call çağrısı. Sayıların kesin olması gerekmiyor; konuşmada olması gerekiyor.

Adı Konması Gereken Trade-off’lar#

Yukarıdaki pozisyonun gerçek maliyetleri var.

Yavaşlamak eşit dağılmıyor. Bir MVP ship eden solo founder ile regüle bir bankadaki mühendis aynı ajan hızında çalışmamalı. Yukarıdaki karar çerçevesi tasarım gereği bağlamsal.

Phronesis zaman ister. Gün sonu diff incelemesi, eskiden harcamadığınız günde otuz dakikadır. Savunması bunun olaydan, rework’ten ve maintainer’ın direncinden ucuz olduğudur; ama yine de gerçek bir maliyet. Ekibiniz pratiği benimsiyorsa, maliyeti sesli olarak adlandırın; sıfır gibi davranmayın.

Tavsiye kısa vadede temiz biçimde ölçülemez. “Yavaşlamak nasılsa olacak olan olayı önledi mi” diye A/B test yapamazsınız. Argüman ilk ilkeler ile birikmiş örüntüler üzerinden yapılmak zorunda; tek bir benchmark üzerinden değil. Her tavsiyenin bir grafikle desteklenmesini isteyen bir kültürde bu rahatsızdır. METR çalışması alanın sahip olduğu en yük-taşıyan veri noktasına yakın bir şey ve METR bile yayımlandığından beri kendi uyarılarını güncellemiş durumda.

Varsayılanın Sınırları#

Varsayılan, gerçek kullanıcıların bağımlı olduğu yazılımı ship eden bir ekipteki çalışan mühendis için geçerli: phronesis’in mümkün olduğu kadarını build’e ve inceleme loop’una kodlayın, hatanın bedelini başkalarının ödediği sonuç merdiveninin altında yavaşlayın.

Varsayılanın geçerli olmadığı yer: atılabilir kod, kişisel script’ler, tek kullanıcısı siz olan prototipler. O bağlamda Yegge’nin çerçevesi daha doğru; orkestratör yargının çoğunu absorbe edebilir ve “kodu hortumdan sıkmak” modu sorun değil çünkü hataların sonuçları sizinle sınırlı. Hata, o modda işe yarayan ajan hızının, işe yaramadığı bağlamlara taşınmasına izin vermek.

Tek bir sonraki eylem önerilecekse: bugün sadece kafanızda yaşayan tek bir phronesis parçasını seçin ve build’e taşıyın; bu bir CI gate, bir şema ya da bir pre-commit hook olabilir.

Kaynaklar#

• Thoughts on slowing the fuck down (Mario Zechner) (yeni sekmede açılır) - Tohum yazı; ajanların hataları insanların yakalayabileceğinden hızlı biriktirdiğini savunur, dar kapsamlı görevler ve günlük diff incelemesi önerir.
• The 70% Problem: Hard Truths About AI-Assisted Coding (Addy Osmani) (yeni sekmede açılır) - Mühendisler için yeniden ifade edilmiş techne/phronesis ayrımı; “iskambil evi gibi kod” (house of cards code) terimini ortaya attı.
• The 80% Problem in Agentic Coding (Addy Osmani) (yeni sekmede açılır) - Osmani’nin ajanlar daha yetenekli hale geldikçe teşhisi sıkılaştıran 2026 takibi.
• Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (METR) (yeni sekmede açılır) - Yüzde 19 yavaşlama randomize çalışması; algı boşluğu yük taşıyan bulgudur.
• We Are Changing Our Developer Productivity Experiment Design (METR, Şubat 2026) (yeni sekmede açılır) - METR’in orijinal çalışmadaki örnekleme uyarılarını kabul ettiği takip yazısı.
• Agentic Engineering Patterns (Simon Willison) (yeni sekmede açılır) - “Telefondan ship eder” karşı görüş; model yerine scaffolding ve CI’yi över.
• Highlights from My Conversation About Agentic Engineering on Lenny’s Podcast (Simon Willison) (yeni sekmede açılır) - Yukarıda atıfta bulunulan “telefondan PR merge ediyor” detayının kaynağı.
• TDD, AI Agents and Coding with Kent Beck (The Pragmatic Engineer) (yeni sekmede açılır) - Ajan-tahmin-edilemez-cin metaforu; TDD’nin dışsallaştırılmış phronesis loop’u oluşu.
• Steve Yegge on AI Agents and the Future of Software Engineering (The Pragmatic Engineer) (yeni sekmede açılır) - 8-seviyeli çerçeve ve orkestrasyonun-her-şeyi-absorbe-edeceği argümanı; yazının birincil karşıt pozisyonu.
• Steve Yegge Wants You to Stop Looking at Your Code (O’Reilly Radar) (yeni sekmede açılır) - Yukarıda atıfta bulunulan “Formula 1” çerçevesi ve “kod bir sıvıdır” ifadesinin birincil kaynağı.
• The End of the curl Bug-Bounty (Daniel Stenberg) (yeni sekmede açılır) - Maintainer’dan birincil kaynak; AI üretimi gürültünün maliyetleri.
• Novice Developers Produce Larger Review Overhead for Project Maintainers while Vibe Coding (arXiv 2602.23905) (yeni sekmede açılır) - 1.719 vibe coder’ın 22.953 PR’ı üzerinde ampirik çalışma; 4,52 kat inceleme yorumu ve yüzde 31 daha düşük kabul.
• Phronesis (Wikipedia) (yeni sekmede açılır) - Nikomakhos’a Etik VI. Kitap’taki episteme/techne/phronesis ayrımının erişilebilir özeti.
• Why Copying Others’ Claude Code Skills Doesn’t Work (SPH) - İç bağlantı; cargo-cult-konfigürasyon sorunu başlı başına bir phronesis yokluğudur.
• The AI Assistance Spectrum (SPH) - İç bağlantı; yardım-seviyesi çerçevesi techne eksenidir; seviyeler arasında seçimi yapan eksen phronesis’tir.