İlk denemelerin %95’i çöp: Claude Code ile bir Staff Engineer’ın yolculuğu

 (sanity.io)
24 puan yazan GN⁺ 2025-09-03 | 5 yorum | WhatsApp'ta paylaş
  • Bir staff engineer, Claude Code kullanarak yapay zekayla birlikte çalışan bir geliştirme iş akışını 6 hafta boyunca denediği deneyimini paylaşıyor
  • Yapay zekayı ‘öğrenmeyen bir junior geliştirici’ olarak görme yaklaşımı, başarılı entegrasyonun anahtarı
  • İlk denemeler çoğunlukla %95 başarısız oluyor; ancak tekrarlar sayesinde kod giderek işe yarar hale geliyor
  • Proje bazlı bağlam dosyaları (Claude.md) ve MCP tabanlı araç entegrasyonu ile yapay zekanın bağlam eksikliği sorunu çözülebiliyor
  • Geliştiricinin rolü kod yazmaktan problem çözme ve mimari tasarıma kayıyor; bu da yapay zeka çağında yeni bir üretkenlik modeli anlamına geliyor

Arka plan ve yaklaşım

  • Yazı sahibi eskiden tüm kodu kendisi yazarken, son dönemde kodun %80’ini yapay zekaya yazdırıyor ve kendisi mimari, inceleme ve çok iş parçacıklı geliştirme yönetimine odaklanıyor
  • Bu yazı, “yapay zeka devrimi yönlendiriyor” gibi pembe bir anlatı değil; yapay zekayı gerçek üretim geliştirme iş akışına entegre ederken yaşanan karmaşa ve gerçekçi yöntemleri paylaşıyor
  • Yapay zekaya “öğrenmeyen bir junior geliştirici” gibi yaklaşmak, başarılı kullanımın kilit noktası

Geliştirme paradigmasının değişim süreci

  • İlk 5 yılda kitaplara ve SDK dokümantasyonuna dayalı geliştirme biçimi sürdü
  • Sonraki 12 yılda arama (google) tabanlı kolektif bilgi kullanımı dönemine geçildi
  • Son 18 ayda Cursor üzerinden yapay zeka destekli kodlama denemeleri yapıldı
  • Hemen önceki 6 haftada ise Claude Code ile bütünsel yapay zeka delegasyonu sayesinde keskin bir değişim yaşandı
  • Claude Code’a uyum sağlamak, yalnızca birkaç saat içinde üretkenlik artışını hissettirdi

Gerçek yapay zeka tabanlı üretim iş akışı

  • Üretime girecek kod üzerinde çalışırken, yapay zeka çoğunlukla “düşünmek için” kullanılıyor
  • Tek seferde kusursuz kod üretmek mümkün değil. Bir mühendisin görevi, probleme en iyi çözümü bulmak
    • İlk deneme (%95 başarısız): Yapay zeka sistem bağlamını toplamaya başlıyor, geliştirici de problemi netleştiriyor; ancak kod neredeyse tamamen yanlış oluyor
    • İkinci deneme (%50 başarısız): Bağlam anlayışı gelişiyor ve yaklaşım somutlaşıyor; ama hâlâ yarısı işe yaramıyor
    • Üçüncü deneme (kullanılabilir kod): Tekrar ve inceleme sonrası gerçekten kullanılabilir bir temel kod ortaya çıkıyor ve sonrasında iyileştirilebiliyor
  • Bu süreç başarısızlık değil; bilinçli olarak planlanmış deneyler ve yinelemeli optimizasyon süreci

Bağlam sorunu ve çözümler

  • Yapay zeka oturumlar arasında belleği koruyamadığı için aynı açıklamaları her seferinde yeniden vermek gerekiyor
  • Çözüm olarak Claude.md dosyası kullanılıyor; burada mimari kararlar, kalıplar ve doküman bağlantıları tutuluyor
  • MCP entegrasyonu sayesinde Linear, Notion, GitHub, kod tabanı ve veritabanına bağlanarak bağlam otomatik sağlanabiliyor
    • Linear ile ticket bağlamı sağlanıyor
    • Notion veya Canvas üzerinden dokümanlara erişiliyor
    • Üretim dışı veritabanı ile veri yapısı kontrol ediliyor
    • GitHub üzerindeki geçmiş PR’ların arka plan bilgileri kullanılıyor

Paralel Claude örnekleri kullanımı ve temel stratejiler

  • Birden fazla Claude örneği paralel yürütülüyor; yaklaşım, “her gün hafızasını kaybeden küçük bir geliştirme ekibini” yönetmek gibi
  • Aynı problem alanında paralelleştirmeden kaçınma, tüm işleri Linear gibi proje yönetim araçlarına kaydetme ve insanın doğrudan düzenlediği kodu net biçimde işaretleme gibi stratejiler uygulanıyor
  • Sadece kod yazımında değil, kod incelemesinde de yapay zeka yoğun biçimde kullanılıyor: eksik testler, açık hatalar ve iyileştirme noktaları hızla bulunarak tekrar eden işler azaltılıyor
  • Yazarın şirketi Sanity’nin politikası gereği, yapay zekanın ürettiği kodda bile nihai kalite sorumluluğu mühendise ait
  • Yapay zeka ve insanın ayırt edilmediği bir kod üretim ortamında, duygusal bağlılık azalıyor ve daha eleştirel, daha nesnel kod incelemesi mümkün oluyor

3 aşamalı kod inceleme süreci

  • Kod yazmak işin bir parçasıysa, kodu incelemek de aynı ölçüde işin parçası
    1. inceleme: Claude’un ilk kontrolü
    • Test kapsamı eksikleri ve bariz hataların tespiti
    • İyileştirme önerileriyle ekip arkadaşlarının inceleme süresinden tasarruf sağlanması
    1. inceleme: Benim incelemem
    • Bakım kolaylığı, mimari, iş mantığı ve entegrasyon kontrolü
    • Kod yapay zeka üretimi olsa bile nihai sorumluluk mühendiste
    1. inceleme: Ekibin standart incelemesi
    • Hangi bölümlerin yapay zeka üretimi olduğu bilinmiyor. Aynı kalite standardı uygulanıyor
    • Duygusal bağlılık olmadan nesnel inceleme yapılabiliyor
  • Yapay zekanın yazdığı koda karşı duygusal bağlılığın azalması, daha nesnel incelemeyi mümkün kılıyor

Slack tetiklemeli agent ve iş otomasyonu denemeleri

  • Cursor ile Slack bağlantılı bir agent pilot olarak denendi: basit iş mantığı değişikliklerinde başarılı oldu, karmaşık CSS yerleşimlerinde ise başarısız kaldı
  • Şu anda özel NPM paketlerini desteklememe, imzasız commit’ler, resmi takip mekanizmalarını baypas etme gibi sınırlamalar bulunuyor
  • Yine de gelecekte agent’ların gece saatlerinde basit ve tekrar eden ticket’ları çözebileceği bir senaryo heyecan verici görülüyor

Maliyet ve ROI

  • Claude Code kullanım maliyeti, şirketin mühendise ödediği ücret içinde kayda değer bir kalem
  • Buna karşın bu yatırımın üretkenlik getirisi var
    • Özellik yayınlama hızı 2-3 kat artıyor
    • Birden fazla geliştirme akışı aynı anda yönetilebiliyor
    • Tekrarlayan ve boilerplate kodu elde yazma ihtiyacı ortadan kalkıyor
  • Yapay zekaya geçişin ilk döneminde senior mühendis başına aylık $1000-1500 bütçe gerekebiliyor; beceri arttıkça maliyet verimliliğinin iyileşmesi bekleniyor

Yapay zeka destekli geliştirmenin süregelen sorunları ve sınırları

  • Öğrenme sorunu: Yapay zeka hatalarından ders çıkaramadığı için aynı yanlış anlamaları tekrarlayabiliyor; çözüm, zengin dokümantasyon ve açık talimatların güçlendirilmesi
  • Güven sorunu: Yapay zeka yanlış kodu bile özgüvenle sunabiliyor; bu yüzden özellikle karmaşık durum yönetimi, performans ve güvenlik alanlarında mutlaka doğrulama gerekiyor
  • Bağlam sınırı sorunu: Büyük kod tabanları yapay zekanın bağlam penceresini aştığı için problemi küçük parçalara bölmek ve net bağlam vermek şart

Koddan probleme duygusal geçiş

  • Koda takılı kalmak yerine problem çözme odaklı düşünceye geçiş
  • Hatalı kodu hızla silme, daha nesnel inceleme ve refactoring konusundaki yükün azalması = olumlu değişim
  • Daha iyi yapay zeka araçları çıkarsa bunları hemen değiştirmeye istekli
  • Esas mesele “kodun kendisi” değil, çözülmesi gereken problemin değeri

Mühendis bakış açısından yapay zeka benimseme önerileri

  • 1. Farklı yapay zeka çözümlerinin denenmesine izin verin: Ekiplerin çeşitli araçları bizzat kullanarak pratik yetkinlik kazanması gerekir
  • 2. Yapay zekayı tekrar eden ve basit işlerden başlatarak uygulayın: Hızlı etki görmek mümkün
  • 3. Deneme-yanılma için bütçe ayırın: İlk ayın kaotik geçeceğini kabul etmek gerekir
  • 4. İnceleme sürecini yeniden tasarlayın: Yapay zeka koduna uygun denetimleri güçlendirin
  • 5. Titiz dokümantasyon yapın: Güçlü bağlam üretkenliği katlıyor
  • Yeni yapay zeka iş akışına uyum sağlayan mühendisler, araç kutularına yeni ve çok keskin bir bıçak eklendiğini fark edecek
  • Yapay zeka iş akışını benimseyen mühendisler, birden fazla yapay zeka agent’ını orkestre edip mimari, inceleme ve karmaşık problem çözümüne odaklanan yeni bir role evriliyor

Sıradaki adımınız

  • Küçük ama iyi tanımlanmış tek bir özellik seçin,
  • Yapay zekaya bu özelliği uygulaması için üç şans verin,
  • Ve sonucu, tıpkı junior bir geliştiriciye mentorluk yapıyormuş gibi inceleyin
  • Hepsi bu. Büyük bir değişime ya da süreç dönüşümüne gerek yok
  • Sadece tek bir özellik, üç deneme ve dürüst bir inceleme yeterli
  • Gelecek, yapay zekanın geliştiricilerin yerini alması değil
    • Geliştiricilerin daha hızlı çalışması, daha iyi çözümler geliştirmesi ve en iyi araçları kullanması

İlgili okumalar

5 yorum

 
helio 2025-09-05

"Böyle incelikli bir prosedürse, kişinin kodu doğrudan kendisinin yazmasının daha iyi olacağını düşünüyorum"
 
skageektp 2025-09-05

Takım üyelerine iş vermeyip işi bizzat halleden ekip liderinin tavrı hahaha
 
greenbhj 2025-09-05

Öyle gibi görünse de hiç de öyle değil.
Son 6 ayda küçük ve büyük ölçekte bunu defalarca denedim.
 
iolothebard 2025-09-05

Küçük ama iyi tanımlanmış tek bir özellik seçin,
yapay zekaya bu özelliği uygulaması için üç fırsat verin ve
ortaya çıkan sonucu sanki acemi bir geliştiriciye mentorluk yapıyormuş gibi inceleyin
Ben olmadan bunu yapabiliyorsa “kazanç”tır ama... benim olmam gerekiyorsa... o zaman bunu kendim yapmam daha “kazanç”.
 
GN⁺ 2025-09-03
Hacker News görüşleri

  • Ajanların bilişsel sınırlarını hesaba katarak komut vermenin önemli olduğu hissediliyor; örneğin büyük değişiklikler istemek yerine önce bir plan yapıp küçük adımlarla ilerlemesini söylemek ve her adımı test ederek devam etmek gerekiyor. Karmaşık aşamalarda problem ile çözüm yolunu görselleştiren kod yazdırmak faydalı olabiliyor. Bir adımda başarısız olursa koda logging ekletip logları kaydettirdikten sonra test edip logları inceleyerek sebebi bulma sürecini tekrarlamak etkili oluyor. Mevcut kodun tasarım yaklaşımı üzerinden modelin nereleri değiştirmesi gerektiğini anlamasını sağlarsanız, yapay zekanın her şeyi tek dosyaya yığmasını önleyebilirsiniz. Birçok kişinin bu tür ipuçlarını paylaştığı bloglar gördüm; hâlâ kusursuz değil ama en azından sonuçların %95’i çöp çıkmıyor

    • Ben bunların hepsini zaten deniyorum ama yine de çoğu zaman işe yaramaz kod üretiyor; düzgün çalıştığında bile sonunda kullanılabilir hâle getirmek için kendim müdahale etmem gerekiyor. Gerçekten iyi çalıştığı anlar oluyor, o zaman heyecan verici, ama kişisel olarak verimlilikte büyük bir artış hissetmiyorum
    • Büyük ölçekli ve karmaşık işlerde "şu anda hemen kod yazmayın. Her adımı ayrıntılı biçimde açıklayacağım" diye talimat vermenin etkili olduğunu düşünüyorum. Örneğin girdi okuma, aday üretme, aday puanlama, önceliklendirme ve sıralama, çıktı veri yapısı oluşturma, DB'ye kaydetme gibi aşamalı bir taslak veriyorum. Claude bu aşamaları TODO listesi ve doküman olarak düzenliyor, böylece sonra kaldığı yerden devam etmek kolay oluyor. Gerçekten de bir saat çalışıp bırakınca, “tamamlanan stage’ler için kod üret ve yorum bırak, sonra buradan devam edelim” dediğimde sürekliliği kolayca koruyabildim
    • Çeşitli LLM/ajanları uzun süre kullansanız bile hâlâ faydalı sonuç almak zor. Boş ve gereksiz çıktılardan kaçınmak için, çoğu zaman işi kendiniz yapmaktan daha fazla enerjiyi prompt yazmaya harcamanız gerekiyor. Prompt ifadesine, tonuna ve istenmeyen çağrışımlar oluşmamasına dikkat ettikçe insan gereksiz bir tedirginlik hissediyor. Keşke ayrı bir frontend framework gibi LLM prompt’larını yönetmeye yarayan araçlar olsa; genel prompt yapılarını düzenlese veya en iyi uygulamaları varsayılan olarak uygulasa da kod içinde bir şey ararken, yeni özellik tasarlarken ya da test yazarken düşünme yükünü azaltsa
    • Bu kadar incelikli bir süreçse, insanın kodu doğrudan kendisinin yazması daha iyi gibi geliyor
    • Kişisel projelerde yapay zeka ve vibe coding denediğimde, test güdümlü geliştirme yaklaşımının vibe coding ile oldukça iyi anlaştığını gördüm. Problemi küçük ve test edilebilir birimlere bölüp, önce yapay zekaya unit test’leri yazdırdıktan sonra gerçek kodu yazdırmayı tavsiye ederim

  • Artık bu tür yazıların sadece basit refactoring işleri ya da React boilerplate’leri değil, gerçekten "ajanın dağıtık şekilde iş yaptığı" somut görev örneklerini içermesi gereken bir noktadayız gibi geliyor. Sanity’de uzun süredir istenen bazı özellikler olduğu söyleniyor ve ajanların önemli miktarda işi paralelleştirdiği iddia ediliyor. Ama "kodun %80’ini öğrenmeyen bir junior developer yazdı" tarzı iddialara inanmak zor

    • Bana göre "öğrenmeyen junior developer" benzetmesi yanlış. Claude daha çok, gerçek saha deneyimi olmayan ama literatürdeki doğru cevapları bilen, yüksek eğitimli bir senior’a benziyor. Ansiklopedik bilgisi çok güçlü ama pratik sezgisi zayıf. Son dönemde Claude ile ticari bir codebase kuruyorum; verdiğim girdilerin çoğu 'kodun tadı'na ve başarının ne olduğuna odaklanıyor, kodun kendisi ise tek kullanımlık gibi kalıyor
    • Yapay zeka ile yazılan kod bu kadar artıyorken open source dünyasında hâlâ çözülmemiş issue’ların birikiyor olması gerçekten ironik
    • Yapay zekaya gerçekten verilen iş örnekleriyle sonuçlar gösterilse, abartılı beklentileri sorgulama fırsatı olurdu. Ama ortada gerçek kullanım örnekleri olmadan Claude Code’un ne kadar harika olduğuna dair yazılar durmadan çıkıyor
    • Satışçılaşmış bir mühendisin teknik blogunda "lesson" yerine "learnings" gibi ifadeler kullandığını görünce, benim yıllar içinde Google aramaya daha az bağımlı hâle gelip yalnızca dokümantasyona daha çok yönelen yolumla bunun ters düştüğünü hissediyorum

  • Yazar üretkenlik artışı olduğunu söylemiş olsa da, sık dile getirilen sınırlamaları da aynen tekrar ettiği için pratikte çok şey söylememiş gibi geldi; kimsenin temel ürün özelliklerinin geliştirilmesini Claude Code’a emanet edeceğine inanmıyorum

  • Boilerplate’ten kaçınmak geliştiricinin işidir; bu aynı zamanda gelecekteki kendinize kolaylık sağlayan bir abstraction’dır. AI ile boilerplate üretirseniz, ileride tüm örnekleri tek tek değiştirmeniz gerektiğinde işler daha da zorlaşır; üstelik farklı yerlere dağılmış boilerplate kodlar tutarsızlaşırsa sorun daha da büyür

    • Framework’lerin ya da araçların çoğunda zaten boilerplate otomatik üreticileri varken, buna ayrıca AI token’ı ve maliyet harcamanın ne kadar değerli olduğu şüpheli

  • İlginç olan şu ki bu kişi yapay zekayla temel implementasyonu deniyor, ben ise tam tersine temeli mutlaka önce kendim kuruyorum. Böylece yapıyı ve çalışma mantığını tam olarak anlayabiliyorum; sonrasında yapay zekaya sadece tekrar eden boilerplate işleri bırakıyorum. Yapay zeka taklit ederek yazmakta iyi ama mimari tasarımda oldukça zayıf

    • LLM’ler sürdürülebilir bir mimari planlamada çok zayıf. Kod geliştikçe yapıyı refactor edemiyorlar; bağlamı anlama sınırları nedeniyle burada ciddi bir tavan olabilir

  • Zaten maaşlar yüksekken, üstüne aylık 1.000-1.500 dolar daha harcayıp verimliliği artıp artmayacağı bile belli olmayan ufak sorunlara yatırım yapılması gerektiği iddiası bana şüpheli geliyor; en azından benim yöneticim bundan hoşlanmazdı

    • Donanım şirketleri, geliştirici maaşlarından bile pahalı olan türlü EDA tool lisanslarını her yıl satın alıyor. Eğer verimlilik gözle görülür biçimde artıyorsa 1.000 doların lafı bile olmaz
    • Geliştirici maaşları bu kadar pahalıysa, aslında yatırım yapmamak daha irrasyonel olur. Aylık 1-1.5k dolar karşılığında verimlilik gerçekten anlamlı biçimde artıyorsa bunu tereddütsüz yapmak gerekir; bu açıdan sadece yapay zeka maliyetine bakmak aşırı indirgemeci bir yaklaşım. Yapay zekayla geliştirici sayısını azaltabiliyorsanız bu da gerçek bir tasarruftur
    • Ben IntelliJ Pro AI için ayda 20 doları bile zor harcıyorum; Claude gerçekten o kadar pahalı mı diye bakınca bunun mümkün olabildiğini gördüm. Her hâlükârda bir yerlerdeki bütçeye AI abonelik ücretinin eklendiği bir gerçek ve şirketlerin yüksek hızlı internet için ödeme yapması gibi AI gideri de giderek temel kalem hâline geliyor
    • Ve bu fiyatların aslında sübvansiyon temelli olduğunu da hatırlamak gerekiyor
    • Şirketlerin bundan sonra nasıl değişeceğini izlemek ilginç olacak. Kesin olan şu ki asıl mesele sonunda geliştiricilerin hangi ölçütlerle değerlendirileceği. AI kullanımının performans değerlendirmesi/işten çıkarma gibi süreçlerde aleyhe dönme riski artacak mı ve başarının asıl öznesinin LLM değil kişinin kendisi olduğunu nasıl kanıtlayacağı önemli bir konu

  • Metinde geçen MCP(Multi-Channel Processor) kullanım biçimini pek anlamadım. Claude Code ile curl veya gh gibi araçlarla shell içinden neredeyse tüm üçüncü taraf servisler çağrılabiliyor; MCP kullanınca hatta sorun çıkabilir (örneğin linear MCP server, issue çok uzunsa kesiyor ama API’yi doğrudan çağırınca böyle bir sınırlama yok). Acaba benim kaçırdığım bir nokta mı var?

  • Anthropic, Boris Cherny (Claude Code’un yaratıcısı) ile bir röportaj yayımladı; Claude Code’un ajan tabanlı kodlamadaki geleceği ve kullanım yöntemlerine dair fikirler de paylaşıyor https://youtu.be/iF9iV4xponk

  • "Aylık $1000-1500 bütçe" ifadesini görünce, acaba sadece API key kullanıp claude MAX gibi sabit ücretli planları bilmiyor olabilir mi diye düşündüm; ayda $100-200, sorguları kontrolsüzce tekrar tekrar atmıyorsanız, bence yeterince karşılar

    • $1k-1.5k gerçekten fazla görünüyor. 20x Max planı bile ayda $200’a oldukça yüksek kullanım sunuyor ve kullanım hakkı her 5 saatte bir yenileniyor. Buna rağmen her gün limite takılıyorsanız, o noktada token bazlı ödeme muhtemelen daha bile pahalıya gelebilir

  • Claude ya da başka ajanlar kullanacaksanız logging’i kesinlikle tavsiye ederim. Tüm log dosyasını yapay zekaya verdiğinizde, sorunu toparlayıp yanıt üretme ya da bir sonraki adıma geçme olasılığı yükseliyor; logging gerçekten her şeydir