Yapay zekadan yararlanarak programlama yetkinliği nasıl artırılır

• AI kodlama araçlarını kullanarak, bir insanın 1–2 saatte yaptığı dönüşüm işlerini 15–20 dakikalık inceleme düzeyine indirmek istiyorum
• Ancak şu anda AI'ın ürettiği kodun kalitesi, doğrudan kendim yazdığım kodun %90'ına bile ulaşmadığı için pratikte pek yardımcı olmuyor gibi görünüyor
• Bu yüzden, yapay zekayı hem üretkenliği hem de kod kalitesini aynı anda artıracak şekilde nasıl kullanmak gerektiğini merak ediyorum

Yapay zeka ile programlama verimliliğini ve kaliteyi artırmak için pratik ipuçları derlemesi

1. Yapay zekayı yalnızca tekrarlanabilir işlere yoğun biçimde uygulayın

• Yapay zeka, benzer biçimdeki işleri birçok kez tekrar ederken en büyük etkiyi gösterir
• İlkini insan doğrudan en yüksek kalitede uygular ve bunu referans örnek olarak kullanır
• Sonrasında aynı desenli işler toplu olarak yapay zekaya verilir
• Düşünme ve muhakeme gerektiren işlerde beklenen verim hızla düşer

2. Kodlamadan önce mutlaka önce bir plan oluşturun

• Doğrudan kod üretmeyin; önce çözüm planını yazın
• Plan aşamasında belirsiz noktaların ve soruların tamamını görünür hale getirin
• Plan tatmin edici değilse uygulama aşamasına geçmeyin
• Sonuç kalitesi, prompt'tan çok plan belgesinin açıklığına bağlıdır

3. İş birimini son derece küçük parçalara ayırın

• Bir dosya, bir bileşen, birkaç fonksiyon düzeyinde istek verin
• “Tüm refactoring”, “daha idiomatic hale getir” gibi isteklerin başarısız olma olasılığı yüksektir
• Yapısal tasarımı insan yapar, yalnızca tekrarlayan implementasyon yapay zekaya bırakılır

4. Bağlamı biriktirmeyin, sık sık sıfırlayın

• Diyalog uzadıkça kurallara uyum ve kalite hızla düşer
• Bir oturumda yalnızca tek bir iş ele alın
• Yön değişirse yeni bir oturumda yeniden başlayın
• Uzun süreli işlerde durumu belgeyle (plan.md vb.) koruyup yeniden verin

5. Kural belgelerini kısa ve mekanik tutun

• CLAUDE.md / AGENTS.md dosyalarını 500–1000 token içinde tutun
• Bildirim niteliğinde yönergelerden çok somut ve doğrulanabilir kurallar yazın
• Yalnızca sık hata yapılan noktaları asgari düzeyde kaydedin
• Geri kalanını kod ve otomatik kontrollerle zorunlu kılın

6. Test, linter ve build süreçlerini geri bildirim döngüsü olarak kullanın

• “Güzel yap” demek yerine geçiş koşullarını açıkça belirtin
• Hedef olarak testlerin geçmesi, build'in başarılı olması ve linter hatasının 0 olması belirlenir
• Yapay zekanın kendi kendine yakınsaması için bir geri bildirim döngüsü gerekir
• Mevcut davranışı doğrulayan testler, refactoring zorluğunu büyük ölçüde azaltır

7. Çalıştırma sırasında düzeltme yapmayın; planı düzeltip yeniden çalıştırın

• Sonuç beğenilmediyse kod düzeltme isteğini tekrar tekrar vermeyin
• Plan belgesini düzelttikten sonra yeni bir oturumda yeniden çalıştırın
• Uygulama aşamasında yön değişirse kalite hızla bozulur

8. Stili örnek tabanlı öğretin

• Soyut “iyi kod” talimatları neredeyse hiç etkili değildir
• Birlikte Before / After örnekleri verin
• İyi ve kötü örnekleri açıkça ayırarak gösterin
• Kuralları örnekleri merkez alarak genişletin

9. Anlamayı bırakmayın ve sorumluluk sınırlarını netleştirin

• Yapay zekanın ürettiği kod mutlaka insan tarafından anlaşılmalı ve gözden geçirilmelidir
• Prototipler ve düşük riskli kod dışında incelemesiz kullanım yasaktır
• Güvenlik, operasyon ve uzun vadeli bakım kodlarında anlama, kalitenin ön koşuludur

10. Önce bu işin yapay zekaya uygun olup olmadığını kontrol edin

• Doğru cevabı olmayan, estetik ve yapısal muhakemenin ağır bastığı işler yapay zeka için elverişsizdir
• Görsel sonucu otomatik olarak doğrulamanın zor olduğu UI refactoring işleri özellikle zahmetlidir
• Gerekirse:
  • 1. aşama: davranışı korumaya yönelik mekanik dönüşüm
  • 2. aşama: kalite refactoring'inin insan tarafından yapılması

11. Beklentiyi “%10 iyileşme” düzeyinden başlatın

• En baştan 10x beklemeyin
• Küçük iyileştirmeleri biriktiren strateji uzun vadede daha etkilidir
• Asıl önemli olan, tasarım ve kalite standartlarından vazgeçmemektir

[GN⁺]

Hacker News görüşleri

• Ben Claude Code ekibinden Boris. Birkaç ipucu paylaşayım

  1. Claude’un sık sık yanıldığı veya anlamadığı kısımlar varsa bunları CLAUDE.md içine yazmak faydalı olur. Claude bu dosyayı otomatik olarak okur
  2. Plan modu (Shift+Tab iki kez) özelliğini aktif biçimde kullanıp önce plan çıkarıp sonra uygulatırsanız zor işlerde 2–3 kat daha iyi sonuç alabilirsiniz
  3. İşin doğrulanma yöntemini vermek faydalı olur. Örneğin Svelte’de Puppeteer MCP sunucusunu kullanarak sonucu tarayıcıda kontrol etmesini sağlayabilirsiniz
  4. Model olarak Opus 4.5’i tavsiye ederim. Sonnet 4.5’e göre gerçekten bir seviye yükseltilmiş gibi hissettiriyor
     Umarım yardımcı olur
  • Ben de Plan modu sayesinde büyük bir üretkenlik artışı yaşadım. Ama son sürümde Plan modunun oturumdaki ilk plana takılı kalıp onu referans almaya devam ettiği bir bug çıktı ve iş akışımı bozdu. Acaba ben mi alışılmadık bir şekilde kullanıyorum diye merak ediyorum
  • İş sırasında Claude’u düzelttikten sonra self-reflection prompt çalıştırmak faydalı oluyor. Bu süreç, elle toparladığınız şeyleri otomatik olarak CLAUDE.md’ye yansıtıyor
  • Bu tavsiyelere katılıyorum. Özellikle (3) numaradaki geri bildirim döngüsü kritik. Modelin kendi düzeltmelerini yapıp sonucu kontrol edebilmesi gerekiyor. Log dosyası bırakmasını sağlamak veya pseudocode planı çıkarttırmak karmaşık problemleri bile hızlı çözdürüyor
  • Opus 4.5 gerçekten tam bir oyun değiştirici. Eski bir React projesini refactor ederken çok yardımcı oldu. Prompt’u özenli yazıp CLAUDE.md dosyasını iyi kurunca etkisi büyük oluyor
  • CLAUDE.md yaklaşık 4–5 kez iyi çalışıyor, sonrasında ise talimatları unutuyor. Örneğin bana “Mr. bcherny” diye hitap etmesini söylesem bile hemen unutuyor
  • Google Jules ile kıyaslayınca Claude Code bana çok daha profesyonel bir geliştirici gibi geldi. Yalnız Claude Code Web’de proje özelliği olmadığı için .clinerules dosyasını kullanmam söylendi; bunun CLAUDE.md ile farkını merak ediyorum
  • CLAUDE.md’deki kullanışlı özelliklerden biri @import. Dosya adının başına @ koyunca onu zorla context içine dahil edebiliyorsunuz. Ama fazla kullanılırsa verimsizleşiyor

• Sesli girdi kullanınca model niyeti daha doğru anlıyor. Yaklaşık 500 kelimelik prompt’ları konuşarak veriyorum. Yazmaya kıyasla konuşurken düşünce akışı daha doğal ilerliyor.
  “Bir plan yap ve soruların varsa sor” dediğimde Claude gerçekten soru soruyor. Önceki kod stilini taklit etmesini söylemek de etkili oluyor

  • Ben de laboratory.love’u sesle neredeyse baştan sona yaptım. Kısayol olarak sık sık “Kod yazmadan önce problemi ve gereksinimleri analiz et, belirsiz noktaları sor” cümlesini kullanıyorum
  • Hızlı konuşmak düşünmeden konuşmak demek değil. Hatta asıl sorun bazen daha az düşünüp konuşmak olabilir
  • Birileri duyarken AI ile konuşmak biraz tuhaf geliyor ama uzun cümleleri ben de sesle giriyorum
  • Hangi speech-to-text servisini kullandığını merak ediyorum

• Prompt’a loop condition eklemek gerekiyor. Örnek: “yarn test geçene kadar tekrar et”.
  Sonuçta LLM, araçları tekrar tekrar çalıştıran bir ajan olduğundan ona bu şekilde yaklaşmak gerekiyor
  Referans: Prompting the Agent Loop

• Benim hazırladığım nori-profiles yapılandırmasını tavsiye ederim.
  4 aylık deneylerin sonucunda Claude Code performansında gözle görülür bir iyileşme oldu.
  İlgili yazı: Averaging 10 PRs a Day with Claude

  • Bunu Claude Code’un skills özelliğiyle karşılaştırınca farkın ne olduğunu merak ediyorum

• İş yerinde büyük bir Golang kod tabanıyla uğraşıyorum. Cursor, Claude Code, Gemini CLI gibi birçok araç denedim ama çoğu kod miktarı karşısında bocalıyor.
  Buna karşılık aider çok daha kolay kontrol edildi ve doğruluğu yüksekti. Dosya eklemek manuel ama neredeyse %100 isabetli.
  En güncel Claude Sonnet veya Gemini 2.5 Pro ile birlikte kullanınca en doğru sonuçları veriyor

  • aider’ın avantajı, tam teşekküllü bir ajan olmaması. Context’i elle yönettiğiniz için yanlış dosyalara dokunmuyor. Token tasarrufu ve hız açısından da avantajlı

• Cursor ile çalışırken önce bir route’u refactor ettirip kural dosyası oluşturmasını sağlıyorum. Sonra diğer route’larda sadece “refactor” demem yetiyor

  • Uzun prompt’lardan korkmayın. Buna zaten context engineering deniyor. Konuşma geçmişinin kendisi context’i zenginleştiriyor.
    Kalan context kapasitesini hep takip etmek ve gerekirse erkenden context clear yapmak iyi oluyor

• Ajana ekip arkadaşı gibi davranma bakış açısı önemli. Birbirinizin güçlü ve zayıf yanlarını gözlemleyip işbirliği biçimini buna göre ayarlamak gerekiyor.
  Ben ajanın gücünü doğrulanabilir problemler veya deneysel kod üzerine yoğunlaştırıyorum.
  Svelte’i çok bilmiyorum ama yeniden yazımı TDD tarzı disposable testler ile yönlendirmek iyi olabilir.
  Bazen önceki yanlış bağlamı bırakıp yeni bir workspace’te yeniden başlamak en iyi seçenek oluyor

  • O “bilişsel stil ve takım çalışması” ile ilgili metnin özetini paylaşırsanız sevinirim

• Ben LLM’i bir searcher olarak görüyorum. Soruları küçük ve somut tuttuğunuzda arama kolaylaşıyor; eğitim verisinden uzaklaştıkça hata olasılığı artıyor.

  1. Projeyi Zed’de aç
  2. Gemini CLI, Qwen code veya Claude’dan birini bağla
  3. Dosyayı değiştirmesini iste ve test et
  4. Olmazsa Grok veya Gemini 3 Chat’te dene
  5. Yine olmazsa elle çöz
     Yeni projelerde one-shot prompt bile yeterli olabilir
  • Ama fazla küçük prompt’lar underspecification sorununa yol açıyor. Hesaplama maliyetini düşürse de kalite açısından dezavantajlı

• Sık kullandığım Claude Code araç seti superpowers

  1. Önce bir beyin fırtınası oturumunda özelliği anlatıyorum
  2. Claude, tasarım dokümanı ve uygulama planı yazıp diske kaydediyor
  3. Yeni bir Claude penceresinde Execute Plan komutuyla adım adım uygulayıp commit atıyor
  4. Her üç adımda bir kendi kendine review yaptırarak kod kalitesini yükseltiyorum
     İki haftadır kullanıyorum ve neredeyse hiç başarısız olmadı

• Benim AI ile programlama ilkelerim basit

  1. One-shot ile her şeyi tek seferde çözmek başarısız olur
  2. İşi doğrulanabilir parçalara böl
  3. Genel planı bir Markdown dosyasına yaz
  4. Her adımı yeni bir oturumda çalıştır, gözden geçir ve ardından commit at
     Kilit nokta “Less is more”. Context penceresi ne kadar tazeyse o kadar iyi; 500–750 kelime civarı ideal. Her adım doğrulanabilir olmalı

• Java ile ilgili işlerde Claude sürekli yön değiştiriyor veya birbiriyle çelişen öneriler sunuyor. ChatGPT bana çok daha iyi geliyor

  • Prompt’ta daha somut talimatlar verilirse daha iyi olabilir
  • Acaba Claude Code sürümünü denediniz mi?

• Eğer idiomatic code istiyorsanız önce sizin için bunun ne anlama geldiğini ayrıntılı biçimde tanımlamanız gerekiyor. İyi/kötü örnekleri küçük parçalara bölüp bunları Opus 4.5’in Plan moduna vererek plan çıkarttırıyor, sonra uygulatıyorum. İlk seferde kusursuz olmazsa plan dokümanını düzenleyip tekrar deniyorum. Bir junior geliştiriciyi mikroyönetir gibi fazla ayrıntılı yönlendirmek ters tepebiliyor

  • Bir başkası da “Artık modellerde her seferinde yeni oturum açmak şart değil” diyerek, inline refactoring ile de yeterince stabil sonuç aldığını paylaştı