İşiniz, çalıştığı kanıtlanmış kodu teslim etmektir

• Yapay zeka destekli geliştirme ortamlarında, deneyimsiz mühendislerin doğrulanmamış büyük PR'ler göndermesi giderek daha sık görülüyor
• Geliştiricinin temel görevi yalnızca kod yazmak değil, çalıştığı kanıtlanmış kodu teslim etmektir
• Bunun için manuel test ve otomatik test olmak üzere iki adım mutlaka uygulanmalıdır
• Kodlama ajanları da kendi yaptıkları değişiklikleri kendileri doğrulayacak şekilde yapılandırılmalıdır
• Sonuç olarak sorumluluk insandadır ve yalnızca doğrulama kanıtı içeren kod gerçek değer taşır

---

Doğrulanmamış kod göndermenin sorunu

• LLM araçlarını kullanan junior mühendislerin devasa, doğrulanmamış PR'ler gönderip kod incelemesine bel bağladığı örneklerden söz ediliyor
  • Bunun saygısız, verimsiz olduğu ve geliştirici sorumluluğunu yerine getirmemek anlamına geldiği belirtiliyor
• Yazılım mühendisinin rolü yalnızca kod üretmek değil, çalıştığı kanıtlanmış kod sunmaktır
  • Doğrulanmamış kod, yükü gözden geçirene aktarmak olarak görülüyor

Kodun çalıştığını kanıtlamanın iki adımı

• İlk adım manuel testtir; kodun gerçekten doğru çalıştığını bizzat doğrulamanız gerekir
  • Sistemi başlangıç durumuna getirme, değişikliği uygulama ve ardından sonucu doğrulama süreci gereklidir
  • Terminal komutları ve çıktı sonuçları kod inceleme yorumuna eklenebilir ya da ekran kaydı videosu ile kanıt sunulabilir
  • Normal çalışmanın ardından, sorunları bulmak için uç durum testleri de yapılmalıdır
• İkinci adım otomatik testtir ve LLM araçlarının gelişmesi sayesinde vazgeçilmez bir prosedür olarak vurgulanır
  • Değişikliklerle birlikte otomatik testler de eklenmeli ve uygulama geri alındığında testler başarısız olmalıdır
  • Test yazımı, manuel testle aynı prosedürü izler ve test harness entegrasyonu becerisi önemlidir
  • Yalnızca otomatik testlerin yeterli olduğunu düşünüp manuel testi atlamak yanlış bir yaklaşım olarak gösterilir

Kodlama ajanlarının rolü ve doğrulama

• 2025'te LLM alanındaki ana eğilimlerden biri kodlama ajanlarının hızlı yükselişi; Claude Code ve Codex CLI bunun öne çıkan örnekleri
  • Bunlar kodu çalıştırıp sorunları kendi başlarına düzeltebilir
• Kodlama ajanları da kendi değişikliklerini kanıtlamak zorundadır; manuel ve otomatik test yapmalıdırlar
  • CLI araçlarında, ajan doğrudan çalıştıracak şekilde eğitilebilir ya da Click'in CLIRunner gibi sistemleriyle otomatikleştirilebilir
  • CSS değişikliklerinde sonuçları doğrulamak için ekran görüntüsü yakalama ayarlanabilir
• Projede mevcut testler varsa, ajan bunları genişletir ya da kalıpları yeniden kullanır
  • Test kodunun yapısı ve kalitesi, ajanın ürettiği testlerin kalitesini doğrudan etkiler
  • Test koduna yönelik estetik anlayış, senior mühendisleri ayıran temel yetkinliklerden biri olarak anılır

İnsanın sorumluluğu ve kodun değeri

• Bilgisayarlar sorumluluk üstlenemez; bu rolü insanlar almak zorundadır
  • LLM'lerin büyük yamalar üretmesi artık tek başına değerli bir iş değildir
• Gerçek değer, çalıştığı kanıtlanmış kod sunmaktadır
  • PR gönderirken, kodun doğru çalıştığını gösteren kanıtlar mutlaka eklenmelidir

[ethanhur]

Kesinlikle katılıyorum. Mevcut PR tabanlı süreçte kodun sorumluluğu maintainer ve reviewer’lara devredilen bir yapı var. İncelenmemiş LLM kodunu gönderen kişi için bir dezavantaj yok.

Google kod tabanına katkıda bulununca contributor’ın credit’i gibi şeylerin ölçüldüğünü görüyorsunuz; sanırım diğer açık kaynak projeleri / şirketler de buna benzer şeyleri benimsemeye başlayacak. Güvenin daha da önemli bir varlık haline geleceğini düşünüyorum.

[roxie]

Aa, demek Google böyle bir kavram kullanıyor.

[tested]

> Çalışan kodu teslim etmek senin işin

[GN⁺]

Hacker News görüşleri

• Son zamanlarda sıkça görülen moral bozucu bir anekdot var. LLM araçlarıyla güçlenen junior mühendisler, devasa ve test edilmemiş PR’ları ekip arkadaşlarına ya da açık kaynak ana bakımcılarına fırlatıp kod incelemesinin gerisini halledeceğini bekliyor. Daha da kötüsü, bu davranışın sadece junior’lardan değil senior geliştiricilerden de gelmesi

  • Dün ve bugün ben de tam olarak bunu yaptım. Ekibimiz bir hata raporu aldı ve bunun harici bir vendor sorunu olduğunu düşündü. Ama vendor geri çevirip sorunun bizde olduğunu söyledi. Ben de Codex’e baktırdım; problemi bulup bir PR hazırladı. Ben doğrudan inceleme ya da test yapmadan doğrulamayı ekibe bıraktım. Bu süreç, ekibin LLM’i iş aracı olarak kullanmayı öğrenmesine yardımcı oldu
  • Son iki günde geliştirici olmayan iki ekip üyesi, AI ajanına mobil hatayı nasıl düzelteceklerini sordu ve aldığı yanıtı ticket’ın ana içeriği olarak ekledi. Sonunda hepsini okuyup gerçek gereksinimi yeniden çıkarmam gerekti
  • “Senior” unvanı taşıyıp junior gibi davranan çok insan var. Sanırım artık mezuniyetin üzerinden 2 yıl geçince bile senior denmesi bunun nedeni
  • Kuralları yok sayabilen ya da etrafından dolaşabilen geliştiriciler en tehlikelisi. Bana geçmişte gördüğüm 10x geliştiricileri hatırlatıyor. Kuralları umursamayıp sadece özellik çıkarırlarsa, sonunda temizliği başkaları yapmak zorunda kalıyor
  • Kod incelemesi sırasında junior geliştiricilerin nerede olduğunu merak ediyorum. İncelemeye katılmıyorlarsa, kendi kodlarının kalitesine karşı sorumluluk hissetmeleri zor

• İyi PR yazma yöntemi sadece AI üretimi kod için değil, her durumda geçerli. Ben PR açıklaması yazarken mevcut davranışın ne olduğunu, neden değişiklik gerektiğini ve neyin değiştiğini sırayla anlatıyorum. İnceleyenin yükünü azaltmak için test yöntemi, ekran görüntüleri ve hatta E2E test komutları da ekliyorum. Bu yaklaşım asenkron iş birliğinde ya da farklı saat dilimlerindeki ekiplerde de işe yarıyor

  • İnceleme istemeden önce kendim bir kez daha gözden geçiriyorum. Küçük yazım hatalarını ya da log temizliğini önceden yapmak, inceleyenin zamanını kurtarıyor. Copilot incelemesi de bu tür şeyleri iyi yakalıyor
  • Açıklamayı ne kadar özenli yazsam da çoğu zaman kimse okumuyor. Yine de yazmaya devam etmemin nedeni sorumluluk duygum
  • İster AI yardımıyla hazırlanmış PR olsun ister olmasın, test kanıtı ve doğrulama içermeli
  • Eskiden açıklamaları uzun yazardım ama kimsenin okumadığını fark ettim. Temel noktaları madde işaretleriyle özetlemek daha etkiliydi
  • Ekibimizin PR şablonunda ticket numarası, talep açıklaması, mevcut durum, değişiklik sonrası durum ve hatta bir ‘mood gif’ bile var

• Mühendisin özü, gereksinimleri anlamak, onları mantıksal akışa dönüştürmek, trade-off’ları dengelemek ve sonucun sorumluluğunu almaktır. Kod üretmek ya da rastgele PR göndermek, bu temellerin eksikliğinin belirtisi. Kodlama ajanları ise tam tersine mühendisliğin özünü yeniden hatırlatıyor

  • Şu yazıda, tek satırlık kodun 60 milyon dolarlık kayba yol açtığı bir örnek var. Kodu anlamadan AI’ın ürettiği 10 bin satırlık bir PR, potansiyel bir felaket
  • Gerçekte şirketler kalite yerine pazarlama ve kârlılığı öne koyuyor. Yüksek kaliteli üründen çok, üstünde ‘premium’ etiketi olan ürün daha iyi satıyor. Sonuçta mühendislikten çok ‘satan şey’ öncelik kazanıyor
  • Ama organizasyon “AI kullan, özelliği 3 gün içinde bitir, yoksa HR görüşmesi var” diye baskı kuruyorsa, ideal mühendislik ilkelerini korumak zorlaşıyor

• Test gerekli ama yeterli değil. Kodu mantıksal olarak doğrulamak gerekir. Testler yalnızca belirli girdiler ve ortamlar altında doğru çalıştığını gösterir

  • Ben de aynı fikirdeyim. İyi çalışan kod yine de berbat olabilir
  • “Kanıtlamak” yerine “göstermek (demonstrate)” demek daha doğru. Testler sadece belirli vakalara dair kanıt sunar
  • Sadece testlere güvenmek yerine, uygulamayı farklı şekillerde bizzat bozmaya çalışıyorum. Bu süreçte kodu daha iyi hale getiriyorum
  • Kodların çoğu biçimsel olarak kanıtlanamaz; bu yüzden property-based testing gibi yaklaşımlar faydalı olabilir
  • %100 test kapsamına ulaşmak bile, kod sağlam değilse bir anlam ifade etmez

• Ben testleri zorunluluk olduğu için yapmıyorum. Sadece kodun gerçekten çalıştığını görmek istediğim için yapıyorum. Kodun çalıştığını görmek seni heyecanlandırmıyorsa, bu meslek sana göre olmayabilir

• LLM yüzünden junior’ların devasa PR’lar attığına dair şeyler duydum ama bizim organizasyonda henüz böyle bir durum yok

  • Devasa PR’lar değil belki ama geliştiricinin anlamadığı LLM üretimi kodu sık görüyorum
  • Bizim organizasyonda da böyle örnekler var. Sorunlar şunlar:
    • Ajan önceki geri bildirimi geri alıyor
    • Kod tabanı standartlarına uymuyor
    • Var olan çözümü yeniden icat ediyor
    • PR geri bildirimine ajan çıktısıyla yanıt veriyor
    • 10–20 satırlık değişiklik yeterliyken 50 bin satırlık PR gönderiyor
    • Test az, hata işleme zayıf
  • Eskiden de düşük kaliteli PR gönderen kişiler, LLM sayesinde artık bunu sadece daha hızlı yapıyor
  • WireGuard Android PR #82, #80 örneklerine bakınca, AI’dan kopyala-yapıştır yapılmış yanıtların olduğu gibi kaldığı görülüyor. “files changed” sekmesi kafa karıştırıcı
  • Bir arkadaşım 11 kişilik bir startup’ta çalışıyor; CTO sabah 3’te 10 bin satırlık kodu doğrudan main’e push’luyor. Keşif aşamasında kabul edilebilir olabilir ama istikrar aşamasında korkunç bir risk

• “İşin, kanıtlanmış durumda kod teslim etmek” olduğu sözüne katılmıyorum. Asıl iş iş problemini çözmek. Elbette çoğu durumda bu kodla sonuçlanıyor ama ayrım önemli

  • Ama kodun doğruluğunu kanıtlamak da iş problemini çözmenin bir parçası. Ayrı bir iş değil
  • Gereksinimleri karşılamayan kod teslim ederek iş problemi çözülemez
  • Önemli olan problemi çözerken yeni problemler yaratmamak. Bu yüzden güvenlik ve kararlılık gerekli
  • Muhtemelen kariyerimde henüz çok başta olduğum için, doğrulanmamış kodla bir problemin nasıl çözülebileceğini anlayamıyorum
  • Sonuçta bütün işler problem çözmeye dayanır. Biz sadece bunu bilgisayarlar aracılığıyla yapıyoruz

• Önceki iş yerimde Japonya’daki yüksek kaliteli bir donanım üreticisinde çalışıyordum. QA departmanı bir hata bulursa ürün lansmanı durduruluyordu. Bu yüzden her geliştirme departmanı kendi QC ekibini kurup ön testleri güçlendirdi. Sonuç olarak yazılım son derece titiz biçimde doğrulanıyordu

  • “get dinged” ifadesinin ne anlama geldiğini merak ediyorum. Bu yapı insanları değişiklik yapmaktan korkutur hale de getirebilir

• Bugünlerde işin özü ticket kapatmak haline geldi. Kod kalitesi metriklere yansımadığı için önemsizleşiyor. Ben böyle bir sistemin parçası olmuyorum. Artık zanaatkârlık kayboldu; herkes ucuz kontrplak ve tutkal istiyor

  • LLM’ler tamamen benimsenip herkesin kullanması beklendiği anda, yazılım mühendisliği artık ciddi bir mühendislik olmaktan çıkıyor
  • Böyle bir tutumu eleştirenlere “O zaman sen devlet desteğiyle mi yaşıyorsun?” diye soranlar da var

• Buradaki sorun “kanıtlanmış kod”un ne anlama geldiği. LLM’in yazdığı testleri ekleyip devasa PR gönderenler de var. Ben kişisel projelerde vibe coding yapıyorum ama ekip düzeyinde bunu yapmak kötü bir alışkanlık. Mühendisleri işe alma nedenimiz, onların uzmanlığını satın almak

  • Bu yüzden ben manuel testi vurguluyorum. Ekran görüntüsü ya da video ile gerçek davranışı göstermek bile büyük güven sağlayabilir