Yapay zeka ile yüksek kaliteli kod etkili biçimde nasıl yazılır

• Yapay zeka ile iş birliği yapılan geliştirme ortamlarında, kaliteyi korumak için insanların projenin yönünü ve karar alma süreçlerini net biçimde tanımlaması gerekir
• Doğru dokümantasyon sayesinde hem yapay zekanın hem de diğer geliştiricilerin gereksinimleri ve kısıtları açıkça anlaması sağlanmalıdır
• Debug sistemi ve kod inceleme düzeni kurularak yapay zeka tarafından üretilen kodun güvenilirliği ve doğrulama süreci güçlendirilmelidir
• Güvenlik riski taşıyan fonksiyonların işaretlenmesi, testlerin ayrılması, sıkı linting kuralları gibi uygulamalarla kodun kararlılığı ve tutarlılığı sağlanmalıdır
• İş birimlerini bölmek ve karmaşıklığı en aza indirmek, yapay zekanın ürettiği kod üzerindeki kontrolü korumayı ve verimliliği en üst düzeye çıkarmayı sağlar

---

1. Net bir vizyon oluşturun

• İnsanlar dünyayı, ekibi ve kullanıcı davranışlarını anlar; ancak yapay zekanın deneyimi olmadığı için açık talimatlara ihtiyacı vardır
  • Projede belgelenmemiş kararlar, sonunda yapay zeka tarafından verilmiş olur
• Mimari, arayüzler, veri yapıları ve algoritmalar önceden tartışılmalı, test yöntemleri tanımlanmalıdır
• Uzun vadeli ve değiştirilmesi zor kararlar mutlaka insanlar tarafından doğrudan yönetilmelidir

2. Doğru dokümantasyonu koruyun

• Yapay zekanın amaca uygun kod üretebilmesi için ayrıntılı gereksinim aktarımı zorunludur
• Diğer geliştiriciler de aynı bilgiyi yapay zekaya vermek zorunda olduğundan, standartlaştırılmış biçimde hazırlanmış belgeler kod deposuna dahil edilmelidir
  • Gereksinimler, kısıtlar, mimari, kodlama standartları, tasarım kalıpları vb. ayrıntılı biçimde kaydedilmelidir
  • Karmaşık yapıları görsel olarak ifade etmek için UML diyagramları, akış şemaları ve sözde kod kullanılmalıdır

3. Yapay zekayı destekleyen bir debug sistemi kurun

• Verimli bir debug sistemi hazırlanarak yapay zekanın kod işlevini hızla doğrulaması sağlanmalıdır
  • Örnek: Dağıtık bir sistemde tüm düğümlerin loglarını toplayıp “veri tüm düğümlere iletildi” gibi özet bilgiler sunmak
• Bu sayede komut çalıştırma maliyeti azaltılabilir ve sorun tespit hızı artırılabilir

4. Kod inceleme seviyesini işaretleyin

• Kodun önem derecesine göre inceleme yoğunluğu ayrıştırılmalıdır
  • Örnek: Yapay zekanın yazdığı bir fonksiyonun sonuna //A yorumu ekleyerek insan incelemesinden geçip geçmediğini belirtmek
• Bu sistem, incelenmemiş kodun tanımlanmasını ve yönetilmesini kolaylaştırır

5. Yüksek seviyeli spesifikasyon yazın ve testleri kendiniz oluşturun

• Yapay zeka, testleri geçmek için mock nesneler veya hardcode edilmiş değerlerle hile yapabilir
• Bunu önlemek için özellik tabanlı testleri (property-based testing) doğrudan kendiniz yazmalısınız
  • Örnek: Sunucuyu yeniden başlatıp veritabanı değerlerinin tutarlılığını doğrulamak
• Test kodu, yapay zekanın değiştiremeyeceği şekilde ayrı bir alana ayrılmalıdır

6. Arayüz testlerini ayırın

• Yapay zekanın, diğer kod bağlamını bilmeden arayüz testleri yazması sağlanmalıdır
  • Böylece implementasyonu yazan yapay zekanın etkisi testlere yansımaz ve testlerin nesnelliği korunur
• Bu testler de yapay zekanın keyfi biçimde değiştiremeyeceği şekilde korunmalıdır

7. Sıkı linting ve formatting kuralları uygulayın

• Tutarlı kod stili ve linting kuralları, kaliteyi korumak ve hataları erken bulmak için zorunludur
• Hem yapay zeka hem de insanlar kod kalitesini daha kolay denetleyebilir

8. Bağlama özel kod ajanı prompt'larından yararlanın

• Projeye özel CLAUDE.md gibi prompt dosyaları kullanarak yapay zekanın ilk anlama maliyetini azaltın
• Kodlama standartları, tasarım kalıpları ve gereksinimleri dahil ederek yapay zekanın kod üretim kalitesini ve verimliliğini artırın

9. Güvenlik riski taşıyan fonksiyonları tanımlayın ve işaretleyin

• Kimlik doğrulama, yetkilendirme, veri işleme gibi güvenlik açısından hassas fonksiyonlar açıkça işaretlenmelidir
  • Örnek: //HIGH-RISK-UNREVIEWED, //HIGH-RISK-REVIEWED yorumlarını kullanmak
• Yapay zeka bu fonksiyonları değiştirirse inceleme durumunun otomatik olarak değişmesi sağlanmalıdır
• Geliştiriciler her zaman bu durumun doğru olduğunu doğrulamalıdır

10. Kod karmaşıklığını en aza indirin

• Gereksiz tek bir satır kod bile, yapay zekanın bağlam penceresinde yer kaplar ve maliyeti artırır
• Mümkün olduğunca basit yapılar korunarak hem yapay zekanın hem de insanların anlayışı geliştirilmelidir

11. Deneyler ve prototiplerle problemi keşfedin

• Yapay zekayla kod üretiminin düşük maliyetli yapısı sayesinde farklı çözüm yolları denenebilir
• Minimum spesifikasyonla birden fazla prototip üretip en uygun yaklaşımı keşfedin

12. Kontrolsüz büyük ölçekli üretimden kaçının

• Karmaşık işler küçük parçalara bölünmeli ve yapay zekanın bunları adım adım işlemesi sağlanmalıdır
  • Örnek: Tüm proje yerine tek tek fonksiyonlar veya sınıflar üretmek
• Her bileşenin spesifikasyona uyup uymadığı doğrulanmalı ve
  kod karmaşıklığı kontrol edilemez hale gelirse proje başlangıç durumuna geri döndürülmelidir

[GN⁺]

Hacker News yorumları

• Ben hâlâ kodu bizzat yazıp düşüncelerimi bu süreçte netleştirmenin önemli olduğunu düşünüyorum
  Kod, benim için ayrıntıları inceltmeye zorlayan bir araç gibi
  Sadece spesifikasyon yazmakla o derinliğe ulaşılamıyormuş gibi geliyor

  • Ben de aynı fikirdeyim. Küçüklüğümden beri bir şeyi bizzat yaparak öğrenme süreci temel oldu
    Bu süreci LLM'ye bırakınca, sanki uçak stol olmuş gibi zihinsel olarak duruyorum
    Problem çözmenin stresi azalıyor ama düşünme ve yaratma motivasyonu da kayboluyor
    Çevremde AI'nın kodu benim yerime yazmasını sevenler var ama ben o grupta değilim
  • Ben de benzer hissediyorum.
    Kahve içerken 5 agent çalıştırıp SaaS yaptığını söyleyen insanlara inanmak zor
    İyi kaliteli kod istiyorsan koda bizzat derinlemesine dalma süreci gerekiyor diye düşünüyorum
    Yine de test yazma ya da yapılandırma sorunlarını çözme gibi basit tekrar eden işler için AI epey faydalı oldu
    Örneğin 5 yıl önce bıraktığım bir projeyi Claude ile yeniden canlandırdım; birkaç saat içinde yarısına gelmişim gibi hissettirdi
  • Ben hâlâ kodu bizzat gözden geçirip test ediyorum
    Ama bugünlerde sanki yeniden spesifikasyon merkezli yaklaşıma dönmüş gibiyim
    Agent'lar sayesinde deneme ve vazgeçme hızlı tekrarlandığı için hâlâ iteratif geliştirme akışını koruyabiliyorum
    Spesifikasyonları ve testleri asıl çıktı olarak görüyor, onların içinde sürekli değişiklik yaparak düşüncelerimi netleştiriyorum
  • “Kod ayrıntıları inceltmeye zorluyor” sözüne tamamen katılıyorum
    Yalnızca spesifikasyonlarla gerçek dünyanın karmaşıklığını tamamen yakalamak mümkün değil
    LLM'nin yazdığı kod çoğu zaman gereksiz uzun ve tuhaf yönlere kayan bir şey oluyor, bu yüzden doğrudan kontrol etmek gerekiyor
    Buna karşılık LLM, fikirleri tartışıp rafine etmek için bir partner olarak oldukça iyi
  • Geçmişte yazılım mühendisliğini montaj hattı gibi görmeye çalışan çok oldu ama gerçekte bu, yaparken tasarlama süreciydi
    Artık kod yazmak ucuzlayıp hızlandığına göre, belki de tam tersine resmî tasarım aşamasını güçlendirmeliyiz

• Bence kod kalitesine en büyük etkiyi, statik analiz araçlarını sistemli şekilde kurmam yaptı
  TypeScript tarafında tsc, eslint, sonarjs, knip, jscpd, dependency-cruiser, semgrep gibi araçları birleştirip pnpm check komutunda topladım
  Bunu pre-commit hook ile otomatik çalışacak şekilde ayarlayarak LLM'nin kaçırdığı sorunları önlüyorum
  Bu sayede LLM takıldığında elle düzeltmek de kolay oluyor

  • Bana da katı lint kuralları uygulamak çok daha kolaylaştı gibi geliyor
    Kod stili tutarlı olduğunda review çok daha rahat oluyor ve AI koduyla insan yazımı kod karışsa bile kafa karışıklığı azalıyor
  • Ben de benzer bir kurulum kullanıyorum. pre-commit hook şart
    Ama lint ve testlerin hepsi geçse bile niyet edilenden farklı çalışan kod çıkabiliyor
    Mesela 404 yerine boş dizi dönen bir API gibi; sözdizimi olarak doğru ama anlam olarak yanlış durumlar
    Bu tür davranışsal doğruluk değerlendirmesi hâlâ en zor kısım
  • LLM'nin bazen sonucu yanlış biçimde raporladığı da oldu
  • Güzel kurulum. Ama maksimum satır uzunluğu sınırının neden gerekli olduğunu merak ediyorum. Üçlü operatör yüzünden mi?
  • Bana kalırsa asıl sorun, kodun yeterince açık olmaması ve aşırı savunmacı kodlama
    Bazen lint kurallarından çok bakım yapılabilirliği önceliklendirmek gerektiğini düşünüyorum

• Ben her özellik eklediğimde düzenli olarak refactor yapıyorum
  Her birkaç özellikte bir tüm kod tabanını gözden geçirip toparlıyorum
  40 yıldır kod yazıyorum ama şu anki kodumdan en memnun olduğum dönem bu

  • Eskiden “çalışıyor, o zaman deploy edelim” kültürü çok baskındı
    Ama LLM sayesinde refactor maliyeti neredeyse sıfıra indi
    Artık kötü kodu olduğu gibi bırakmak için bir sebep yok
    Verimliliği artıran araçları kaliteyi yükseltmek için kullanmanın asıl değer olduğunu düşünüyorum
  • Ben de benzer bir ders çıkardım
    Her commit'te kod satırlarını iyi (yeşil)/refactor gerekli (sarı)/yeniden yazım gerekli (kırmızı) diye işaretleyen dahili bir araç yaptım
    “TODO refactor” yorumlarından daha temiz ve sistemli, yakında open source olarak yayımlamayı planlıyorum

• Şu anda AI ile çalışmak için spesifikasyon tabanlı geliştirmenin en güvenli yaklaşım olduğunu düşünüyorum
  Spesifikasyonları ince ayrıntısına kadar iyileştirmeye, ekip ve AI ile fikir alışverişi yapmaya daha fazla zaman harcıyorum
  Spesifikasyon eksikse AI alakasız kod üretiyor
  Alan bilgisini derinlemesine kavradığında, baştan tekrar implemente ettirmenin daha iyi olduğunu hissediyorsun

  • Böyle şeyler duyunca 90'lardaki UML, 4GL, Rational hayalleri yeniden aklıma geliyor
    O zamanlar “gereksinimleri tanımlarsan sistem geri kalanını kendi yapar” vizyonu vardı
    Sonunda başarısız olup agile baskın hâle geldi ama şimdi teknoloji o hayali yeniden mümkün kılıyor gibi görünüyor

• AI'nın asıl değeri hızında ve belirsizlikle başa çıkabilmesinde
  Ama bütün prosedürleri eksiksiz uygularsan sonunda yine waterfall kadar yavaş hissediliyor
  Bence kodu doğrudan kendin yazıp AI'yı ilk review yapan taraf olarak kullanmak daha iyi
  Küçük parçalarda hızlı doğrulama yaparak ilerlemek hâlâ agile bir yaklaşım

  • Deneyimli geliştiriciler için bile faydalı çok fikir vardı
    Özellikle güvenlikle ilgili fonksiyonları işaretleme önerisi iyiydi. Sonraki kod değişikliklerinde bağlamı korumaya yardımcı olabilir
    “Küçük parçalara bölmek” temel bir şey ama yeni başlayanların sık kaçırdığı bir nokta
  • “Bunların hepsini yaparsan waterfall'a dönersin” sözüne şaka yollu “sıradaki herhâlde vibe tabanlı beyin ameliyatı” diye eklemiş

• İnsanların bugünlerde AI sayesinde temel best practice'leri yeniden keşfetmesi komik
  Aslında bunlar zaten eskiden beri yapılması gereken şeylerdi

  • Ama pratikte yayına çıkma baskısı yüzünden bunlara uymak her zaman zordu
    Şimdi kodlama süresi azaldıkça bu işlere ayıracak alan doğuyor
    Üstelik AI dokümantasyonu gerçekten kullandığı için iyi dokümantasyon yazmak doğrudan değer üretmeye başladı
    Eskiden doküman yazsan da görmezden gelinirdi, ama LLM hepsini okuyor
  • Bu tür korumalar aslında sadece berbat programcılar (ya da papağanlar) için gerçekten gerekli

• Eskiden kodlamadan önce ayrıntılı spesifikasyonlar yazardım, ama sonra doğrudan koda girmenin daha hızlı olduğunu fark ettim
  Şimdi yeniden spesifikasyon merkezli bir döneme mi dönüyoruz?
  Sorunu tamamen anlamadan spesifikasyon yazarsan, sonunda yine kodlarken öğreniyorsun
  Şu anda sanki ikisinin arasında bir yerdeyiz

  • Spesifikasyonu atlarsan sık sık tamamen yanlış bir program yapıyorsun
    Ama artık AI sayesinde yanlış kodun maliyeti neredeyse sıfır olduğu için, spesifikasyonun değeri azalmış gibi geliyor
  • AI kodu ucuza ürettiği için, önce spesifikasyonsuz deneyip öğrenme, sonra yeniden tasarlama yaklaşımı mümkün hâle geliyor
    Bu, Joe Armstrong'un anlattığı programlama tarzına benziyor
    Artık bunun pratikte mümkün olduğu bir dönemdeyiz
  • “Plan yapıp spesifikasyon çıkarıp sonra kod yazmalısın” sözü her zaman doğruydu

• Lead pozisyonundayken ticket'ları çok ayrıntılı yazardım
  Bu kısmen junior'lar içindi ama asıl olarak kendi detayları unutmamam içindi
  Ama yönetim bunu “zaman kaybı” diye reddetti ve sonunda bu alışkanlığımı kaybettim
  Şimdiyse tam tersine, bundan da ayrıntılı spesifikasyonları daha hızlı yazmam bekleniyor

• AI agent kullanırken Markdown ile kod oranının ve ortaya çıkan işin okunabilirliğinin nasıl olduğunu merak ediyorum
  Review süresi, kodu doğrudan yazmaktan daha uzun sürmüyor mu diye de düşünüyorum

• Günümüzde geliştiricilerin, kendilerini ikame edebilecek AI'yı büyük bir hevesle savunması ironik
  İlgili tweet bağlantısı bu durumu tiye alıyor

  • “AI'yı veriyle kirletip sabote edelim” diyen Underground Resistance tartışması da var
  • Claude'un performans sorunlarını düzeltememelerine bakınca, IPO öncesi pazarlamayı artırıyorlar gibi görünüyor
    “Claude kullanmazsan geride kalırsın” mesajı belki de bu yüzden veriliyor
  • Birçok geliştirici “AI sayesinde verimliliğim arttı” diyor ama
    bunun gerçekte geliştirici talebinin ve ücretlerin düşmesine yol açma ihtimali yüksek
    Özellikle sadece NPM paketlerini birleştirme düzeyinde geliştirme yapanlar için risk daha büyük