- “Kodu okumamak”, satır satır inceleme yerine spesifikasyonlar, testler, statik analiz ve prodüksiyon sinyallerine dayanmak anlamına geliyor; belirli risk alanlarında kod incelemesine eskalasyon yapılabilir
- OpenAI’nin Harness Engineering yaklaşımı ve OpenClaw örneği, kodun kendisi yerine test, gözlemlenebilirlik ve otomatik doğrulama altyapısına odaklanan bir yaklaşımı gösteriyor
- Kara kutu, güvenlik ve hata birikimi gibi şüpheciliklere verilen yanıtlarda, soyutlama katmanlarının tarihsel örüntüsü ve otomatik doğrulama araçlarının önemi vurgulanıyor
- Kod okumayı tamamen dışlamıyor; güvenlik, emniyet ve mimari kararlar söz konusu olduğunda doğrudan incelemenin gerekli olduğunu söyleyen dengeli bir tutum sunuyor
- Kod giderek uygulama detayı haline geliyor; asıl yükselen çıktıların spesifikasyon, mimari ve doğrulama katmanları olduğu yöne bahis oynanması gerektiğini savunuyor
“Kodu okumamak” tam olarak ne demek?
- Önceki yazıdaki “Artık kod okumuyorum” ifadesi, Hacker News’te 200’den fazla hararetli yoruma yol açtı
- Bunun tam anlamı, ürün kodunun büyük kısmı için satır satır incelemeyi varsayılan doğrulama yöntemi olarak kullanmamak
- Spesifikasyonlar ve testler, değişen diff’in seçmeli incelenmesi ve prodüksiyon sinyalleri hâlâ kontrol ediliyor; belirli risk alanlarında kod okuma seviyesine eskalasyon yapılabiliyor
- Kodun okunmama nedeni, kodun daha az önemli olması değil; özellikle büyük ölçekli ortamlarda satır satır okumanın doğruluğu garanti etmenin en etkili yolu olmaması
Dayanak oluşturan örnekler
-
OpenAI’nin Harness Engineering yaklaşımı
- OpenAI, Harness Engineering blog yazısında, yazılım mühendisliği ekiplerinin merkezî rolünün kod yazmaktan ortam tasarımı, niyetin spesifikasyonu ve geri bildirim döngülerinin kurulmasına kaydığını anlatıyor
- 3 mühendis, yalnızca Codex ajanlarıyla 1 milyon satır kod üreterek yüzlerce iç kullanıcının kullandığı bir ürün inşa etti
- Kodun kendisinden çok onu çevreleyen harness’e — dokümantasyon, bağımlılık kuralları, linter’lar, test altyapısı, gözlemlenebilirlik sistemi — yatırım yapıldı
- Satır bazlı kod incelemeye ayrıca yatırım yapılmadı
-
OpenClaw
- Ekip olmadan tek kişi tarafından geliştirilen OpenClaw, son birkaç ayın en hızlı büyüyen açık kaynak projelerinden biri haline gelerek 100 binden fazla GitHub yıldızı topladı
- 5-10 ajanın paralel çalıştığı bir yapı; bunu tasarlayıp işleten kişi acemi değil, deneyimli bir mühendis
- “Okumadığım kodu deploy ediyorum” başlıklı röportajda, refaktöring, mimari, testler ve AI coding etrafındaki harness’e yatırım yaptığını söylüyor
-
Coder’dan Orchestrator’a
- ESLint’in yaratıcısı ve birden fazla O'Reilly kitabının yazarı olan deneyimli bir mühendis, yakın tarihli bir yazısında, yazılım mühendisliğinin geleceğinde merkezde kod yazmanın değil AI ajanı orkestrasyonunun olacağını öne sürüyor
- Temel yetkinlikler sözdizimi ve implementasyondan mimari tasarıma, spesifikasyon yazımına ve geri bildirim döngüsü tasarımına kayıyor
Şüpheciliklere verilen yanıtlar
-
Kara kutu eleştirisi
- “İnsanlar isteyerek kara kutu yaklaşımını seçer mi?” eleştirisine karşı, kodun çıktısının kodun kendisi değil ürün olduğu vurgulanıyor
- Bu, bir fotoğrafçının fotoğrafa bakmaması değil; fotoğrafı üreten kameranın iç yapısına bakmaması benzetmesine daha yakın
- Sistemleri, doğrudan içine bakmadığımız soyutlama katmanlarının üzerinde kurma biçimi, yazılım dahil birçok mühendislik alanında zaten yaygın bir pratik
-
Güvenlik kaygıları
- AI tarafından üretilen koda arka kapı yerleştirilebileceği endişesi için, bunun “insan her satırı okumalı” meselesi değil, tooling ve doğrulama sistemi meselesi olduğu söyleniyor
- Statik analiz, bağımlılık taraması ve güvenlik linter’ları, insanlar da zafiyetli kod yazdığı için var; çözüm daha güçlü otomatik doğrulama sistemleri, yani harness merkezli yaklaşımla aynı yönde
- Yine de özellikle güvenliğe duyarlı alanlarda insan incelemesi hâlâ gerekli
-
Hata birikimi sorunu
- “Kod başarısız olursa insanların parası kaybolur, uçaklar durur, arabalar bozulur. Kodu okuyun” eleştirisi en sık gelenlerden biri
- CodeRabbit verilerine göre AI tarafından üretilen kod, genel yazılım kalitesinde 1,7 kat daha fazla kusur üretiyor
- Ancak AI coding biçimleri çok çeşitli; spesifikasyon, katmanlı test ve mimari kısıtlar içeren harness merkezli geliştirme, basit vibe coding’den temelden farklı
- Bir yorumda önerilen yaklaşım: spesifikasyon, testler ve statik analize dayanmak; %85 ve üzeri test kapsamını korumak; kapsamı kademeli genişleten entegrasyon testleri olan testing ladders kurmak; benchmark ve yoğun dogfooding ile hataları erken açığa çıkarmak
- Asıl soru, “AI kodu ortalamada daha mı hatalı?” değil; “İyi tasarlanmış bir harness içinde aynı hızla geliştirildiğinde, alternatiflere kıyasla daha fazla hata mı üretiyor?”
- Greg Brockman (OpenAI kurucu ortağı) da insan tarafından yazılan kodla aynı standartların uygulanması gerektiğini savunuyor
Gerçek sistemin nasıl kurulduğu
- Kariyerinin büyük bölümünde kod yazdı; çoğu iç araç olsa da gerçek kullanıcıların dayandığı sistemlerdi
- Kodun biçimini ve yapısını anlıyor ama onu doğrudan okumamayı seçiyor
-
Spesifikasyon tabanlı iş akışı
- Ajan kod yazmadan önce, AI ile yapılan konuşmalar üzerinden çok somut ve ayrıntılı bir spesifikasyon önce hazırlanıyor
- Gereksinim ID’leri sayesinde ürün spesifikasyonundan yürütme planına kadar izlenebilir bir yapı kuruluyor
- Yürütme planındaki her görev, doğrulama yöntemini açıkça belirten kabul kriterleri içeriyor
- Otomatik testler için (TEST)
- Görsel doğrulama için (BROWSER:DOM)
- Yalnızca başka yol olmadığında (MANUAL) kullanılıyor; o durumda bile önce mümkünse curl veya bash tabanlı otomatik kontrol üretmeye çalışılıyor
- Somut doğrulama metaverisi olmayan görevler, audit becerisi tarafından işe başlamadan engelleniyor
-
AI Coding Toolkit (harness)
- Prompt, skill, hook ve script’lerden oluşan bir araç takımı ajanın çalışma biçimini kısıtlıyor; 35’ten fazla skill, yapılandırılmış ajan yönergeleri ve katmanlı doğrulama altyapısı içeriyor
- Ajan yönergeleri altyapı olarak yönetiliyor
- AGENTS.md, ana kural seti işlevi görüyor: muhafazakâr değişiklikler, mevcut arayüzlerin korunması, TDD’ye uyum, tahminde bulunmama, git geçmişini yeniden yazmama
- VISION.md, stratejik sınırları tanımlıyor
- Katmanlı bir doğrulama sistemi işletiliyor
- Her aşama sonunda checkpoint skill’i; type checking, linting, testler, build, mutation testing ve güvenlik taramasını içeren çok katmanlı geçitler çalıştırıyor
- Tarayıcı araçları uygunsa otomatik tarayıcı doğrulaması yapılıyor
- Değişen diff, farklı bir AI modele (Codex CLI) gönderilerek ikinci görüş incelemesi alınıyor
- Modeller arası doğrulama, tek bir modelin kör noktalarını telafi ediyor
- Bazı durumlarda kod doğrudan okunuyor ama yalnızca istisnai senaryolarda
- Tüm testler geçtiği halde ürün davranışı tuhaf geldiğinde
- Büyük bir mimari karar verilmesi gerektiğinde
- Birden fazla ajanın çözemediği bir arıza debug edilirken
- Bu durumlarda bile amaç kodun kendisini analiz etmek değil, harness’te hangi boşluğun soruna izin verdiğini anlayıp tekrarını önlemek
Kodu ne zaman okumak gerekir?
- Doğrudan emniyetle ilgili sistemlerde, güvenliğe duyarlı servislerde ve önemli mimari kararlarda, yazılım mühendisliği gerçekten mühendisliktir; kodun kitlesel üretildiği bu dönemde önemi daha da artıyor
- Havacılıktaki "Children of the Magenta" benzetmesi, pilotların navigasyon ekranındaki macenta renkli uçuş yoluna aşırı bağımlı hale gelmesini anlatır
- Buradaki ders “otopilotu kullanmayın” değil, gerektiğinde müdahale edebilme becerisini koruyun
- Sorun çıktığında otomasyon seviyesini düşürüp temellere dönebilmek gerekir; ama her uçuşu sürekli elle yapmak talebi verimsiz ve daha risklidir
- Esas olan, otomasyondan yararlanırken müdahale kabiliyetini kaybetmemektir
Yönün nereye gittiğine bahis oynayın
- Bilişimdeki her soyutlama katmanı ortaya çıktığında dirençle karşılaştı; bunun temsilî örneklerinden biri Dennis Ritchie ve Ken Thompson’ın 1973’te Unix’i C ile yeniden yazmasıydı
- O dönemde bunun sistemi yavaşlatacağı, donanım üzerindeki kontrolü azaltacağı ve karmaşıklığın bakımı zorlaştıracağı eleştirileri yapıldı; ancak C’nin soyutlaması Unix’i yüksek taşınabilirliğe ve etkiye sahip bir işletim sistemi haline getirdi
- Tekrarlayan örüntü şu: soyutlanan katmanda uzmanlığı olan kişiler, o katmanı anlamanın önemini vurgular; bu bazı durumlarda haklıdır ama zamanın çoğu daha yüksek soyutlama katmanlarında düşünmeye ve tasarlamaya ayrılır
- Kodu okumamayı seçmek, araçların kusursuz olduğunu ilan etmek değil; birçok kullanım senaryosunda bunun zaten yeterince geçerli olduğu ve hızla iyileştiği yönündeki gidişata dair bir yargı
- Kod ortadan kalkmıyor; giderek implementasyonun detayı haline geliyor ve onun yerine spesifikasyon, mimari ve doğrulama katmanları ana çıktılar olarak öne çıkıyor
3 yorum
Yapay zeka ile programlama, soyutlama ya da otomasyondan çok dışsallaştırma/outsourcing’e daha yakınmış gibi görünüyor.
Tasarım ve doğrulamanın da gelişmişlik ve hassasiyet için gereken unsurlar olmaktan çok, düşük güvenli bir toplumu zar zor bir arada tutan düzenlemeler gibi devreye sokulduğu hissi veriyor.
Gerçekten isabetli bir analiz.
AI ile programlamanın temelde olasılıksal olması önemli bir nokta gibi görünüyor.
Yapay zeka ile kütüphane geliştiriyorum; sanırım refaktöring, kod kalitesini artırma ve kusur kontrolünü de yapay zekaya yaptırmak gerekiyor.