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

Özet

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. Bu yazı, Aristoteles’ten ödünç alınan bir çerçeveyle bu iki beceriyi temiz biçimde ayırıyor. Sonrasında Mario Zechner, Addy Osmani, Kent Beck, Simon Willison, METR ve Steve Yegge’nin bu çerçeve üzerinden okunduklarında aslında ne söylediklerini gösteriyor. Argüman bir tarafı tutuyor: Zechner, Yegge’den daha yakın bir noktada 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 beceri. İlginç tartışma hız göstergesi hakkında değil. İkinci beceri hakkında.

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üşürdü. Phronesis bir milim bile hareket etmedi. Hiçbiri model ağırlıklarında değil. Hiçbiri bir CLAUDE.md dosyasına ya da “skill”e tam olarak kodlanamaz. Bu yazı, Claude Code ya da Cursor’u her gün kullanan, onlarla gerçek özellikler ship etmiş ve en az bir kez ajanın kendinden emin biçimde yanlış yaptığı bir şeyle başı belaya girmiş geliştirici için. Argüman ş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.

Uzmanlar Neden Birbirleriyle Çelişiyor Görünüyor

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 mükemmel, son yüzde 30’unu (güvenlik, edge case’ler, sürdürülebilirlik, uyum) kötü yapacak. Çerçeve üzerinden okuyun: ilk yüzde 70 techne, artık ucuz. Son yüzde 30 phronesis, hâlâ pahalı. Aynı ayrım, farklı sözcükler.
• 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. Çerçeve üzerinden okuyun: test, dışsallaştırılmış phronesis. Ajan, phronetic bir şartnameye karşı techne öğütüyor. “Ajanlar testleri siler” hatası, techne’ye kendi başarı kriterleri üzerinde yetki verildiğinde olan şey.
• Simon Willison’ın “telefonundan ship ediyor” durumu. Willison işi telefonundan merge ediyor; çünkü repoları hızlı testlere, sıkı linter’lara, type check’lere, preview ortamlarına ve korumalı branch’lere sahip. Çerçeve üzerinden okuyun: o daha hızlı koşmuyor. Scaffolding’i phronesis’i onun adına tutuyor, böylece techne’yi ajana verebiliyor. Hız satın alınmış, bedava değil.
• 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). Çerçeve üzerinden okuyun: algı boşluğu, akıcı techne hissini phronesis sonucu sanmaktan kaynaklanır. Zaten sahip olduğunuz phronesis, ajanların artırmayı değil yerini almayı tehdit ettiği şeydir.
• Mario Zechner’in “yavaşla” çağrısı. 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. Çerçeve üzerinden okuyun: phronesis’in techne’nin bolluğuna karşı kendini savunması.
• Steve Yegge’nin “kod bir sıvıdır” pozisyonu. Yegge’nin 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. Çerçeve üzerinden okuyun: Yegge phronesis’in tooling katmanına taşınabileceğine bahse giriyor. Yukarıdaki herkes taşınamayacağına bahse giriyor. 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.

Bu Yazı Nerede Duruyor

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 bunu context olmadan bakacak junior takım arkadaşını göremez. Kod değişikliğinin sonuçları orkestratörün görünürlüğünün altında akar ve modelin eğitim verisinden daha hızlı değişen yerlerde akar.

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.

Yazının pozisyonu ş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. Akışı değil, sonuçları takip edin.

Bu olay alışılmadık değil. METR verisinin tek bir kişiye olduğunda nasıl bir doku olduğunun tarifi. Hız göstergesi yanlış yerde. Dashboard “hızlı” diyor çünkü techne hızlı. Üretim sistemi olan yol farklı bir zaman ölçeğinde.

Hızı Değil Phronesis’i Kök Alan Bir Karar Çerçevesi

Herhangi bir ajan görevinden önce sorulmaya değer sorular phronetic, teknik değil. Hız, başlangıç noktası değil, cevapların bir sonucu.

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	Çarpışma yarıçapı sizsiniz
İç araç, küçük etki alanı	Ajan taslağı, insan incelemesi	Başarısızlık can sıkıcı, kayıp değil
Müşteri yüzlü, geri alınabilir	Ajan destekli, eşli inceleme	Başarısızlık rollback’tir
Müşteri yüzlü, 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 üstünde hızlanmak değil, 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, gösterişten ibaret değil. Scaffolding, Mermaid konusunda daha hızlı ship etme hakkını kazandı.

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:

• Code review’da değil, 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 diff’e değil, ç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 şu: insan, makinenin kontrol edemediği şeyi incelemeye odaklanabilir; makinenin yakalaması gerekeni yeniden kontrol etmek zorunda kalmaz. Willison’ın setup’ının ona aslında satın aldığı şey bu.

Çerçeveyi Operasyonelleştiren Pratikler

Beş somut alışkanlık, her biri yukarıdaki uzmanlardan birine bağlı. Ekibinize uyanları seçin; amaç beşini de benimsemek değil, 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

Bu, yirmi dakikalık techne’den önce yirmi saniyelik phronesis. Oran bütün hile.

Önce başarısız bir testle yargıyı dışsallaştır (Beck). Başarısız testi elle yazın. Ardından 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. Ajanın güçleri ajanın güçleri; 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.

Gün sonu diff incelemesi (Zechner). Ajanın özetini değil, günün diff’ini kendiniz okuyun. Özet techne raporudur. Diff, gelecek maintainer’ın okuyacağı artefakttır. Günde otuz dakika. 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.

Sık Karşılaşılan Hatalar

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, bir kısıt değil. Kısıt; test, type check, CI gate’dir. CLAUDE.md yararlıdır; ama yargının gerçekten yaşadığı yer değildir.
• 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. İnsan gözünün amacı throughput değil; sonuç-biçimli phronesis’in yaşadığı yer olmaktır.
• “Bunu ajanla yapabilirim”i “bunu ajanla yapmalıyım” ile karıştırmak. Birincisi techne. İkincisi phronesis. Bu karıştırma, problemin kendisi.
• 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 Ödünleşimler

Yukarıdaki pozisyonun üç dürüst maliyeti.

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. Tüm bağlamlar için tek bir doğru ajan hızı olduğunu söyleyen, size bir şey satıyordur.

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 gerçek bir maliyet, bedava bir alışkanlık değil. 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; ama dürüst durum bu. 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 Nerede Geçerli, Nerede Değil

Bu yazının savunduğu varsayılan: ajanları techne’yi bedava kılmış olarak ele alın; phronesis’i bilinçli olarak tahsis ettiğiniz kıt kaynak olarak ele alın; phronesis’inizin mümkün olduğu kadarını build’e ve inceleme loop’una kodlayın; sonuç merdiveninin altında, hatanın bedelini başkalarının ödediği yerde yavaşlayın. Bu, 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. Bu yazının okurlarının çoğu için doğru varsayılan.

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. Durumu okuyun, sonra hızı seçin. Çerçeve yazılım mühendisliğinden eski; ajanlar sadece soruyu yeniden aciliyetle gündeme getirdi.

Tek bir sonraki eylem önerilecekse: bugün sadece kafanızda yaşayan tek bir phronesis parçası seçin ve build’e taşıyın. Bir CI gate, bir şema, bir pre-commit hook. O hareketin bileşik faizi, Willison’ın setup’ının aslında yapıldığı şey.

Kaynaklar

• Thoughts on slowing the fuck down (Mario Zechner) - 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) - 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) - 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) - 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) - METR’in orijinal çalışmadaki örnekleme uyarılarını kabul etmesi; iyi niyetli okuma için.
• Agentic Engineering Patterns (Simon Willison) - “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) - Yukarıda atıfta bulunulan “telefondan PR merge ediyor” detayının kaynağı.
• TDD, AI Agents and Coding with Kent Beck (The Pragmatic Engineer) - 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) - 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) - 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) - 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) - 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) - 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. Bu yazı, seviyeler arasında seçim yapan phronesis eksenidir.