Claude ile Gerçek Kodu Prod’a Alırken Edinilen Saha Notları

 (diwank.space)
77 puan yazan GN⁺ 2025-06-09 | 7 yorum | WhatsApp'ta paylaş
  • Bir yapay zeka aracı olan Claude’u gerçek bir hizmete uygularken, geliştirme üretkenliğinde 10 kat artış etkisini gerçekçi biçimde nasıl elde edebileceğimizi ve buna dair uygulama birikimini derli toplu anlatıyor
  • “vibe-coding”, basit bir akım değil somut bir metodoloji; doğru geliştirme alışkanlıkları ve altyapı kurulduğunda yapay zekanın güçlü yanları en üst düzeye çıkarılıp zayıf yanları telafi edilebiliyor
  • Yapay zekanın rolü “ilk taslak yazarı”, “pair programmer” ve “kod gözden geçiren” olmak üzere üç moda net biçimde ayrılıyor; her aşama için uygun dokümantasyon ve guardrail’ler şart
  • Kilit nokta, her projede CLAUDE.md dosyasını kullanarak konvansiyonları, mimariyi, kalıpları, yasakları vb. açıkça belgelendirmek ve kod içindeki “anchor comment”lerle yapay zekayı etkili biçimde yönlendirmek
  • Test kodu mutlaka insan tarafından yazılmalı; ayrıca yapay zekanın test, migration, güvenlik, API sözleşmeleri, secret’lar gibi kritik alanları değiştirememesi için sınırlar çok sıkı çizilmeli
  • Doğru sınırlar ve alışkanlıklarla yapay zeka destekli kodlamayı benimseyen ekipler, deployment sıklığını, kararlılığı ve geliştirme hızını aynı anda büyük ölçüde iyileştirebilir; gerçek operasyon birikimi ve kalıp paylaşımı da yapay zeka geliştirme kültürünün çekirdeği haline geliyor

Vibe Coding Sadece Bir Vibe Değil

  • Bu yazı, yapay zeka destekli yeni bir yazılım geliştirme biçimi için sahadan bir rehber; yalnızca nasıl kullanılacağını değil, gerçekte etkili yapay zeka geliştirmesinin ‘neden’ini de açıklıyor
  • Efsane gibi görülen 10 kat üretkenlik artışının bile ancak yapay zekanın güçlü yönlerini en üst düzeye çıkaran ve zayıf yönlerini telafi eden pratik alışkanlıklarla mümkün olduğunu gerçek örneklerle gösteriyor
  • Gerçek hizmet veren Julep kod tabanında kullanılan CLAUDE.md şablonları, commit stratejileri ve operasyonel felaketleri önleyen guardrail’ler gibi sahada denenmiş altyapı ve işletim bilgisini paylaşıyor
  • Özellikle test kodunun mutlaka doğrudan geliştirici tarafından yazılması gerektiğini, yapay zekaya aşırı bağımlılığın ciddi kesintilere ve kâbusa dönen debug süreçlerine yol açabileceğini vurguluyor
  • Yapay zeka ile geliştirmede üç mod (ilk taslak, pair programming, gözden geçiren) bulunuyor; duruma göre inisiyatifin yapay zekaya verildiği ya da insanın doğrudan yönettiği ritim ve ilkeler değişiyor
  • Ana mesaj: Yapay zeka ancak iyi geliştirme alışkanlıkları ve net sınırlar olduğunda yetkinliği büyüten bir çarpana dönüşür; gerçek araştırmalar da “disiplinli geliştirme alışkanlıklarına sahip ekiplerin hem deployment hızında hem de kalitede açık ara öne geçtiğini” gösteriyor

Bu Yazı Neden Yazıldı: Meme’den Method’a

  • Kodu yapay zekaya bırakıp geliştiricinin “sadece vibe’a girdiği” kavramı (“vibe-coding”), aslında Andrej Karpathy’nin şaka amaçlı bir tweet’iyle başlayan bir akımdı
  • O dönemde geliştirici topluluğu bunu, “işi yapay zeka halleder, biz de kahvemizi içeriz” türü nihai bir fantezi olarak görüp gülüp geçiyordu
  • Ancak Anthropic’in Sonnet 3.7 ve Claude Code’u yayımlamasından sonra bu şaka, gerçekten mümkün bir gerçeğe dönüşmeye başladı. Cursor gibi araçlar zaten vardı ama Claude Code gerçekten “vibe coding” hissi vermeye başladı
  • Yazarın içinde bulunduğu Julep, büyük bir kod tabanı, çeşitli tasarım kalıpları ve teknik borçla birlikte yaşıyor. Kod kalitesi ve dokümantasyon titizlikle korunuyor ama her parçanın niyetini ve geçmişini kavramak bile haftalar sürebilecek kadar karmaşık
  • Claude guardrail olmadan kullanıldığında, her yerde hata yapan aşırı hevesli bir stajyerin yarattığı karmaşaya benzer bir durum ortaya çıkıyor
  • Bu yazı, işte bu deneme-yanılmaları, sabaha karşı 3’te yapılan debug seanslarını ve gerçek üretim ortamında ayakta kalan hakiki saha kalıplarını ve pratik bilgileri toparlayıp paylaşıyor

Vibe-Coding’in Özü

  • Steve Yegge’nin CHOP (Chat-Oriented Programming) terimini ortaya atması gibi, “vibe coding” de yapay zekayla konuşarak kodu tamamlama temelli yeni bir geliştirme biçimi
  • Geleneksel kodlama, mermeri yontar gibi satır satır dikkatle inşa edilen bir işse,
    • vibe coding bir orkestrayı yönetmeye daha yakın; yapay zeka ise ham malzemeyi (temel kod yazma yeteneğini) sağlayan icracı
    • Geliştirici genel yönü ve yapıyı tasarlıyor, yapay zeka da bu akışı izleyerek koda döküyor
  • Vibe coding’in 3 yaklaşımı (Postures)
    • 1. Yapay zekayı ilk taslak yazarı olarak kullanmak (First-Drafter)
      • Mimarî ve tasarıma odaklanılırken, tekrar eden işler (CRUD, boilerplate vb.) yapay zeka tarafından hızla üretiliyor
      • Düşündüğünüz hızda kod yazan junior bir mühendise sahip olmak gibi, ama sürekli yönlendirme gerekiyor
    • 2. Yapay zekayla pair programming yapmak (Pair-Programmer)
      • En pratik ve en etkili mod
      • Geliştirici ile yapay zeka fikir alışverişi yapıyor; büyük resmi insan çiziyor, ayrıntılı implementasyonu yapay zeka dolduruyor
      • Çok sayıda programlama bilgisi olan ama gerçek deployment deneyimi bulunmayan bir iş arkadaşıyla eşli programlama yapıyormuşsunuz gibi
    • 3. Yapay zekayı doğrulayıcı/kod gözden geçiren olarak kullanmak (Validator)
      • İnsan tarafından yazılan kodu yapay zeka inceliyor, bug’ları, iyileştirme noktalarını ve kaçırılmış kalıpları öneriyor
      • Asla yorulmayan ve her zaman dikkatli bir reviewer rolü
  • Temel içgörü: Geliştiricinin rolü “yazar”dan “editör”e kayıyor. Artık her satırı bizzat yazmak yerine, yapay zekanın ürettiği çıktıyı gözden geçiriyor, düzeltiyor ve yön veriyor.
  • Ancak genel mimari ve bağlamın liderliği mutlaka insanda kalmalı; yapay zeka yalnızca “ansiklopedik bilgiye sahip bir stajyer”, bizim hizmetimizin ve işimizin bağlamını bilmiyor

Vibe Coding’in 3 Pratik Modu: Çerçeve

Aylar süren deneyler ve gerçek deployment kazalarının ardından, vibe coding’in farklı ritimleri, guardrail’leri ve ideal kullanım alanları olan 3 modu olduğu görülüyor

  • Mod 1: Playground (deney/prototip/kişisel proje)

    • Ne zaman kullanılır: Hafta sonu hack’leri, kişisel script’ler, PoC’ler, anlık fikir testleri vb.
    • Özellik: Tasarım, dokümantasyon veya guardrail olmadan, kodun %80-90’ını yapay zeka yazar. Fikirden sonuca dakikalar içinde gidilir
    • Risk: Gerçek hizmette/önemli kodda uygun değil. Yalnızca eğlence ve deney için kullanılmalı. Hatta mühendislik ilkeleri daha da önemli hale gelir

  • Mod 2: Pair Programming (gerçek kullanım/küçük ölçekli servis)

    • Ne zaman kullanılır: 5.000 satırın altındaki projeler, gerçek kullanıcısı olan yan projeler, demolar, küçük modüller vb.
    • Çekirdek fikir: Projenin teamüllerini, mimarisini, kalıplarını ve test kılavuzlarını CLAUDE.md içinde tek seferde net biçimde tanımlamak
    • Avantaj: Tıpkı yeni bir geliştiriciyi onboard eder gibi, Claude’a bir kez anlattığınızda tutarlı biçimde kod üretebiliyor
    • Sahadaki kritik nokta:
      • Kodun çeşitli yerlerinde anchor comment’lerle (AIDEV-NOTE, AIDEV-TODO, AIDEV-QUESTION vb.) Claude’un bağlamı kaybetmemesi sağlanıyor
      • Bu yorumlar hem yapay zeka hem insan için yol gösterici oluyor; yönetim ölçütleri ve örnekleri de CLAUDE.md içinde belirtiliyor

  • Mod 3: Production/Monorepo Scale (büyük ölçekli servis)

    • Ne zaman kullanılır: Onlarca ila yüzlerce geliştiricinin çalıştığı, gerçek kullanıcılı büyük hizmetler; tek bir hatanın büyük zarara yol açabileceği ortamlar
    • Uyarı: Şu anki durum itibarıyla (Haziran 2025), büyük ölçekli toplu vibe coding henüz kusursuz biçimde ölçeklenmiyor
    • İlke: Vibe coding’i tek tek servisler veya alt modüller bazında devreye almak; tüm entegrasyon noktalarında (API, DB vb.) net sınırlar ve versiyon yönetimi kurmak; kritik arayüzler ve API’ler için değişiklik uyarı yorumlarını zorunlu kılmak
    • Sahadan örnek:
      • # AIDEV-NOTE: API Contract Boundary - v2.3.1
      • # Changes require version bump and migration plan
      • Bu sınırlar olmazsa Claude kendi başına “iyileştirme” yapmaya kalkıp tüm gerçek hizmeti bozabilir
  • Sonuç: Büyük projelerde vibe coding kademeli olarak, ayrıştırılmış servisler bazında devreye alınmalı; güvenilirlik için dokümantasyon, kılavuzlar ve review gibi geleneksel ilkeler mutlaka birlikte uygulanmalı

Altyapı merkezli sürdürülebilir bir yapay zeka geliştirme ortamı kurmak

  • CLAUDE.md: Yapay zeka ve insanlar için tek doğru kaynak (The Single Source of Truth)

    • CLAUDE.md, tüm proje kurallarını, mimariyi, dikkat edilmesi gereken noktaları, kod stilini, yasaklı unsurları ve alan sözlüğünü sistemli biçimde toplayan bir “anayasa” görevi görür
    • Yapay zeka ve yeni ekip üyelerinin paylaşacağı “bilgi iskeleti” olarak işlev görür; örneklerle birlikte somut yönergeler ve yasaklar emek yoğun şekilde yönetilir
    • İyi bir CLAUDE.md’ye yatırım yapan ekipler daha iyi sonuçlar üretir
    • Bizim production CLAUDE.md dosyamıza göz atın
    • Kod tabanı büyüdükçe yalnızca CLAUDE.md yeterli olmaz; kodun farklı yerlerine anchor comment (AIDEV-NOTE/TODO/QUESTION vb.) ekleyerek yerel bağlamı açıkça aktarmak gerekir
    • Kod tabanını bir şehre benzetirsek, anchor comment’ler hem yapay zekanın hem de insanların yolunu kaybetmemesini sağlayan tabelalardır
    • Bu yorumlar, basit kod açıklamasının ötesine geçerek neden böyle çalıştığının hikayesini bırakır

  • Git iş akışı: Yapay zeka kodunu sistemli biçimde yönetmek

    • Yapay zekanın kod üretim hızı arttıkça, kötü yönetilirse git geçmişi kirlenebilir
    • git worktree yöntemi gibi yaklaşımlarla ana branch’ten ayrılmış yapay zeka deney alanları kurun; kod özgürce üretilebilsin ama kayıtlar sistemli biçimde ayrılsın ve yönetilsin
    • Commit mesajlarında yapay zeka müdahalesi mutlaka belirtilmeli ([AI] etiketi kullanmak gibi); böylece reviewer ek dikkatle inceleme yapabilir

Yazısız kural: Test kodunu mutlaka insan yazmalı

  • Yapay zeka destekli geliştirmede en önemli ilke: “Test kodunu asla yapay zekaya bırakmayın”
  • Test, yalnızca çalışmayı doğrulayan bir kod değildir
    • Gerçek problem bağlamını, edge case farkındalığını, iş gereksinimlerinin yorumunu ve alana dair insan anlayışı ile deneyimini barındıran çalıştırılabilir bir spesifikasyondur
    • Hem hızdan hem de kararlılıktan ödün vermeyen güçlü ekipler, işte bu testleri tamamen insan kontrolünde tutar
  • Yapay zekanın otomatik ürettiği testler genelde yalnızca yüzeysel akışları (happy path) doğrular ve beklenmedik ciddi sorunları (ör. memory leak) kaçırır
  • Bizim ekipte yapay zeka test dosyalarına dokunursa PR otomatik reddedilir (istisnasız)
  • Testler, kodun spesifikasyonu ve güvenlik ağıdır; birikmiş tüm bug’ların ve edge case’lerin bilgeliğini taşır
  • Mutlaka insan eliyle yazılmalı ve yapay zekanın dokunamayacağı şekilde güçlü biçimde korunmalıdır

Ölçekleme ve bağlam yönetimi: Token ekonomisi ve context optimizasyonu

  • Yapay zeka ile kod geliştirmede sık yapılan hata:
    “Token tasarrufu” yapmak için bağlamı (prompt, gereksinimler, ortam vb.) en aza indirmek, aslında tekrar işlerini artırır ve toplam token tüketimini yükseltir
  • Uygun bağlam sağlamak uzun vadede daha verimlidir
    • Önemli olan “minimum” değil, en baştan “ilgili ve yeterli bağlam” vermektir
  • Kötü örnek: Bağlamı yetersiz prompt "Add caching to the user endpoint"
    • Claude basit bir in-memory cache kurar; invalidation stratejisi yoktur, monitoring yoktur, multi-server senaryosu düşünülmemiştir, cache stampede için önlem yoktur
    • Sonuçta 3 kereden fazla tekrar düzeltme gerekir ve toplamda 4 kattan fazla token harcanır
  • İyi örnek: Bağlamı zengin prompt 
    Add Redis caching to the GET /users/{id} endpoint.  
Context:  
* 엔드포인트 트래픽 5만 req/분, 12대 API 서버, 데이터 변동 적음  
* 기존 Redis 인프라 위치, 표준 키 패턴, Prometheus 기반 메트릭 요구  
* 캐시 어사이드 패턴, TTL 1시간, 캐시 스탬피드 방지(확률적 조기 만료)  
* 캐싱 가이드 문서 참조
    • Baştan verilen somut bağlam, tekrar gerektirmeden doğru implementasyonu mümkün kılar
  • Sonuç:
    • “Token, iyi araçlara yapılan bir yatırım gibidir”
    • Bağlamı baştan yeterince verirseniz, uzun vadede tekrar ve düzeltmeler azalır, maliyet düşer
  • Pratik ipucu: Her projede, kod değiştikçe Claude’dan kod tabanındaki değişiklikleri ve ilgili bağlamı CLAUDE.md içinde güncellemesini isteyin

Oturum yönetimi ve bağlam kirlenmesini önleme

  • Her iş için Claude oturumunu yeniden başlatmak önemlidir
    • Tek bir uzun konuşmada birden fazla işi (ör. DB migration, frontend tasarımı vb.) karıştırırsanız, bağlamlar birbirine girer ve istenmeyen sonuçlar doğurur
  • Kural: Bir iş = bir oturum; iş bitince yeni oturum başlat
    • Claude’un “zihinsel modelini” her zaman temiz ve odaklı tutar
    • Tıpkı çiğ tavuk ve sebze için ayrı kesme tahtası kullanmak gibi, bağlamı ayırır

Gerçek örnek: Hata işleme yapısının dönüşümü

  • Gerçek bir vakada, 500’den fazla endpoint’te kullanılan ad-hoc hata işleme yaklaşımı yapılandırılmış bir hata hiyerarşisiyle (hierarchy) değiştirildi
  • İnsan (mimar) önceden temel tasarımı (SPEC.md/gereksinimler/hata sınıflandırması) yazar; Claude ise gerçek kodun büyük ölçekli dönüşümünü yapan uygulayıcı rolünü üstlenir
  • Mimari ilkeler ve somut spesifikasyon, tasarım belgesi örnekleri/kavram çıkarımı -> yapay zekaya açık görev talimatı -> toplam refactor’ın tam 4 saat içinde bitirilmesi deneyimi

Yapay zeka çağında liderlik ve organizasyon kültürü

  • Kıdemli mühendislerin rolü, doğrudan kod yazmaktan; bilgi kürasyonu, sınır koyma ve hem yapay zekayı hem insanları yönlendirmeye evriliyor
  • Lean yönetim, sürekli deployment gibi modern geliştirme kültürü, yapay zeka iş birliğini yönetirken de aynı derecede önemlidir

  • Yeni çalışan onboarding kontrol listesi (insan + yapay zeka iş birliğini ayırarak)

    • 1. hafta: Temelleri oturtma
      • Ekibin CLAUDE.md dosyalarını (ortak/servis bazlı) oku
      • Geliştirme ortamını kur
      • İlk PR’ı gönder (%100 elle kodlama, yapay zeka yasak)
    • 2. hafta: Yapay zeka ile çalışma pratiği
      • Claude’a ekip şablonunu uygula, ayarları yap
      • “Oyuncak problem”i yapay zekayla birlikte çöz
      • Prompt kalıpları çalış
      • Yapay zeka destekli ilk PR’ı gönder (mentor/kıdemli ile birlikte)
    • 3. hafta: Bağımsız uygulamalı çalışma
      • Yapay zeka desteğiyle ana özellik geliştir ve prod’a al
      • Ekip arkadaşının yapay zeka kodu için testleri bizzat yaz
      • Bir kod review oturumuna liderlik et

Şeffaf kültür kurmak: Yapay zeka kullanımını aktif biçimde açık etmek

  • Yapay zeka kullanılan tüm commit’lerde, aşağıdaki gibi commit mesajı etiketleriyle açıkça belirtilir 
    feat: add Redis caching to user service \[AI]  
# \[AI] - %50’den fazla yapay zeka üretimi, \[AI-minor] - %50’den az, \[AI-review] - yalnızca review için yapay zeka kullanıldı  
# Cache/client kodunu yapay zeka yazdı; cache key tasarımı, test ve doğrulamayı insan yaptı
  • Etkileri
    1. Reviewer’lar yapay zeka koduna özellikle dikkat eder
    2. Debug sırasında kodun kaynağını anlamak kolaylaşır
    3. Yapay zeka kullanımına dair utanma/gizleme kültürü ortadan kalkar, “yapay zekayı sorumlu biçimde kullanırız” takım kültürü yerleşir
  • Herkesin rahatça yapay zekadan yararlanabilmesi ve yüksek performans kültürüne katkı sağlayabilmesi için aktif açıklık ve kültürel mekanizmalar önemlidir

Claude için yasaklar: Yapay zeka burada kesinlikle el sürmemeli

  • test dosyaları/veritabanı migration’ları/güvenlik açısından kritik kod/API sözleşmeleri(sürüm yönetimi hariç)/ortam yapılandırması ve secret’lar gibi alanlarda AI otomasyonunun kullanılması kesinlikle yasak olmalı
  • Hataları risk seviyelerine göre ayırıp (format ve bağımlılıklardan iş açısından kritik alanlarda veri tahribatına kadar), yüksek riskli alanlarda ek zorunlu guardrail’ler uygulanmasının altı çiziliyor
  • AI hatalarının risk hiyerarşisi (Hierarchy of AI Mistakes)
    • Level 1: Can sıkıcı ama ölümcül değil
      • Format hataları (linter yakalar)
      • Gereksiz derecede uzun kod (sonradan refactor edilir)
      • Verimsiz algoritmalar (profiling sırasında fark edilir)
    • Level 2: Maliyeti yüksek hatalar
      • İç API uyumluluğunun bozulması (ekip koordinasyonu gerekir)
      • Mevcut pattern’lerin değiştirilmesi (karmaşaya yol açar)
      • Gereksiz bağımlılık eklenmesi (kod tabanını şişirir)
    • Level 3: Kariyer açısından yıkıcı (Career-Limiting)
      • Test sonucunu tutturmak için testin kendisini değiştirmek
      • API sözleşmesini bozmak
      • Secret/kişisel veri sızıntısı
      • Veri migration’ını bozmak
    • Hatanın seviyesine göre guardrail seviyesi de değişmeli; Level 3 hatalar ise kariyer için ciddi bir tehdit oluşturur

Geliştirmenin geleceği: Önümüzdeki değişimler ve yönelim

  • 2025 itibarıyla AI destekli geliştirme, ergenlik çağındaki bir genç gibi güçlü ama hâlâ sakar ve pürüzlü
  • Ancak büyüme eğrisi net biçimde ivmeleniyor
  • İyi dokümantasyon (Documentation), AI çağında DevOps uygulamasının temel altyapısı
    • Dokümanlar artık bir "referans materyali" olmanın ötesinde, insan niyeti ile AI icrası arasındaki doğrudan "arayüz"
    • Yüksek performanslı ekipler, testler kadar CLAUDE.md gibi dokümanların yönetiminde de titiz davranıyor

  • Bundan sonra beklenen değişimler

    • Kodun tüm bağlamını anlayan AI
      • Dosya düzeyiyle sınırlı kalmayıp servis/sistem seviyesini de kavrayacak
    • Oturumlar ve projeler arasında kalıcı hafıza
      • Konuşmaları ve iş bağlamını uzun vadeli olarak hatırlayıp kullanacak
    • Proaktif iyileştirme önerileri sunan AI
      • Talep gelmeden sorunları ve iyileştirme noktalarını önceden teşhis edecek
    • Her ekibin pattern ve tercihlerini öğrenen AI
      • Kuruma özgü stil ve teamüllere uygun kodu otomatik üretecek
  • Ancak temel değişmiyor:
    • Yönü insan belirler, icra ve kaldıraç etkisini AI sağlar
    • Araçlar ne kadar güçlenirse güçlensin, biz hâlâ "araç kullanan kişileriz"

Sonuç: Şimdi, burada başlayın

  • Buraya kadar okuduysanız heyecanın yanında biraz korku da hissediyor olabilirsiniz
    • Bu tepki normal; AI destekli geliştirme güçlüdür ama "kasıtlı ve sistematik uygulama" şarttır

  • Bugün hemen uygulanabilecek eylem planı

    • Bugün
      • 1. Mevcut projenizde bir CLAUDE.md dosyası oluşturun
      • 2. En karmaşık olduğunu düşündüğünüz koda kendi elinizle 3 anchor comment ekleyin
      • 3. Net sınırlar (rehberler) altında AI destekli tek bir özelliği deneyin
    • Bu hafta
      • 1. Ekipçe AI commit message kuralları belirleyin
      • 2. Junior bir geliştiriciyle birlikte bir AI kodlama oturumu düzenleyin
      • 3. AI’nin ürettiği kod için test kodlarını bizzat siz yazın
    • Bu ay
      • 1. AI kullanımından önce ve sonra deployment sıklığındaki değişimi ölçün
      • 2. Ekip içindeki tekrar eden işler için bir prompt pattern kütüphanesi oluşturun
      • 3. Tüm ekibin katıldığı bir AI iş birliği retrospektif toplantısı yapın
  • Ana fikir şu: "hemen şimdi, küçük başlayın, dikkatli olun, ama mutlaka başlayın"
  • Bu akımı erken ustalaşan geliştiriciler bunu daha zeki oldukları için değil,
    • daha erken başlayıp daha çok hata yaparak öğrendikleri için başarıyor
  • Yazılımı production’a çıkarma performansı, doğrudan organizasyon performansını belirler
    • Hız ve kalitenin rekabet avantajı olduğu bir çağda, AI destekli geliştirme bir seçenek değil, "zorunlu bir yetkinlik"
    • Ancak buna doğru yöntemle yaklaşmak gerekir
  • Vibe coding kulağa oyun gibi gelebilir,
    • ama insan kapasitesini büyüten ciddi bir geliştirme yaklaşımıdır
    • Araçlar ve pattern’ler zaten yeterince hazır
    • Artık kimin orkestrayı yöneteceğine, kimin tüm enstrümanları tek başına çalacağına karar verme zamanı

Pratik materyaller ve önerilen kaynaklar

İlgili okumalar

7 yorum

 
softychoco 2025-06-16

Bugün yazdığım gönderi de buna benzer bir bakış açısına sahip.
Sonuçta asıl mesele, yapay zeka aracılığıyla üretkenliği artırırken, düşen istikrarı yükseltecek bir organizasyon yapısına dönüşmekti.

https://softycho.co/57
 
kimjoin2 2025-06-09

Yapay zeka destekli kodlamayı ifade eden vibe coding'deki "vibe"ın tam olarak neyi kastettiğini hâlâ anlamıyorum.
Atmosfer mi? His mi? Uyum mu? Yapay zekayla da bir ilgisi yok gibi.
Sanki 퉁퉁퉁 사후르 seviyesinde, bağlamdan tamamen kopuk hissettiriyor.
 
analogstar 2025-06-11

Namuwiki'ye göre
"Vibe Coding, geliştiricinin üretken yapay zekanın yardımıyla kod yazmasını ifade eden yeni bir terimdir; programlama yaparken önceden sıkı bir mantık ya da tasarıma dayanmaktan ziyade sezgiye ve hislere güvenildiği anlamını taşıdığı için buna 'vibe' coding adı verilmiştir." deniyor. haha
 
hohemian 2025-06-09

Kafanızı boşaltın ve akışa bırakın.
Tüm mantığı yapay zeka yazıyor.
Tam bir tab tuşu bağımlısı oluyorsunuz!
 
secret3056 2025-06-09

> look and feel👀🎵🎷. Anlamaya çalışmayın🧠, hissedin!😊

Aynı his, değil mi
 
humblebee 2025-06-09

Aa öyle mi? Ben tam duyduğum anda o "hissi" almıştım..
Siz söyleyince.. bugünlerde geliştirici olmayan alanlardakilerin de gayet iyi anladığı "hard-coding" terimi aklıma geliyor.
Bu kelime de aslında ilk başta sözcüğün kendisinden ne anlama geldiğini kavraması zor ama, yazılım geliştirmeyi öğrenmeye başlayınca sonunda neyi ifade ettiğini ve niyetinin ne olduğunu herkesin iyi anladığı türden bir "his" gibi, değil mi? haha
 
GN⁺ 2025-06-09
Hacker News görüşleri

  • Yazara göre: Son zamanlarda Claude koduyla ilgili yazılar ortalığı kaplamışken, bizim keşfettiğimiz birkaç kilit noktayı—özellikle de Anchor Comments’i—paylaşmaya değer bulmuş
    Anchor Comments yaklaşımı, kod tabanının farklı yerlerine özel formatlı yorumlar bırakıp ihtiyaç duyulan bilgiyi doğrudan grep ile bulunabilir hale getiren bir yapı
    Örnek olarak AIDEV-NOTE:, AIDEV-TODO:, AIDEV-QUESTION: gibi önekler kullanılıyor
    Dosya aramasından önce mevcut AIDEV-… kayıtları olup olmadığını mutlaka grep etme kuralı var
    İş bittikten sonra ilgili anchor’ın güncellenmesi zorunlu
    Bir kod dosyası ya da kod parçası fazla karmaşıksa, çok kritikse ya da hata içerebileceği düşünülüyorsa her zaman anchor yorumu bırakılıyor
    Örnek için buraya bakılabilir

    • Çok deneyimli bir mühendis olarak LLM’leri sistematik değil de ara sıra kullanan biri açısından, gerçek projelerde LLM’in production’da nasıl uygulandığını bu kadar ayrıntılı görmek oldukça faydalı geldi
      Başkalarının neden bu kadar olumsuz baktığını pek anlayamıyorum
      Kendi iş akışımda LLM kullanımını biraz daha artırma motivasyonu verdi
      Elbette proje anahtarları LLM’in elinde değildi ama belirli işleri verip başarılı olduğumuz örnekler epey vardı

    • Bu aralar benzer yazı çok var ama bu yazı oldukça pratik ve bana da uygulayabileceğim sistem fikirleri verdi
      aider gibi araçları kullanmakla bu tür bir iş akışı arasında ne fark olduğu merak ediyorum—yazarın görüşü varsa duymak isterim

    • Harika bir makale; LLM’leri büyük ölçekte kullanma biçimini anlamama çok yardımcı oldu
      “AI testlere asla dokunmamalı” denmiş ama ardından 500’den fazla endpoint’in 4 saat içinde refactor edildiği örneği verilmesi dikkat çekiciydi
      Bu 4 saatin test refactor’ünü de içerip içermediğini, yoksa sadece prompt harcanan süre mi olduğunu merak ediyorum

    • Testler AI tarafından güncellendiyse PR’ı reddetme kuralından bahsedildiğini gördüm; peki bunun gerçekten AI tarafından üretildiği veya değiştirildiği nasıl anlaşılıyor, merak ettim
      Yazıda git commit message kurallarıyla bunun tespit edildiği söylenmiş ama bu da yalnızca commit düzeyinde çalışıyor

    • Yazının hazırlanmasında Claude Code kullanılıp kullanılmadığını merak ettim
      Ben son zamanlarda yazılarımın %100’ünü Claude Code ile yazıyorum; agent’ın markdown dosyasını doğrudan düzenlemesi, claude.ai artifacts ya da chatgpt.com canvas’a kıyasla çok daha verimli geliyor
      Bu sayede araştırma materyallerini ve ilgili dosyaları belgeye derinlemesine birleştirmek çok kolaylaştı

  • AI agent’ların ilginç tarafı şu: Normalde önemli olduğunu düşündüğümüz ama gerçek sistem dağıtımı karşısında önceliği sürekli düşen süreçleri gerçekten uygulamaya koyduruyorlar
    AI’ın kendi yerime bir şey yapmasından ne kadar rahatsız olduğumu, “sistematik doğrulamaya ne kadar zaman ayırmalıyım” göstergesi olarak kullanma gibi faydalı bir yöntemim var
    Linkteki gibi bir veri migrasyonu doğrulama sistemi kurarsanız, ilgili tüm değişiklikleri de doğal olarak AI kullanım kapsamına alabilirsiniz
    Soyut “teknik borç” söylemlerine kıyasla bunu dışarıya açıklamak çok daha somut ve kolay oluyor

    • Buna kesinlikle katılıyorum; ama benim keşfettiğim bir başka faydalı numara da Claude Code’a “kod tabanını dolaş, kafanı karıştıran, tuhaf gelen ya da sezgiye aykırı olan yerlerde AIDEV-QUESTION: yorumu bırak” demek
      Beklenmedik derecede karmaşık ve unutulmuş kodlar sayesinde önemli noktaları yeniden keşfettiğim oldu

    • Sezgim şu yönde: daha yüksek soyutlama seviyesindeki doğrulama araçlarını—örneğin acceptance test, property test, formal verification—daha sık kullanmaya başlayacağız
      Çünkü LLM kullanımıyla boilerplate maliyeti görece ciddi biçimde düştü

  • Okurken yeni şeyler öğrendim
    Son zamanlarda Sonnet 4’ü Cursor ve Web’de denedim ama sürekli bir şeyleri baştan savma yapması ya da sonuçları yanlış anlayıp raporlaması yüzünden şaşkına döndüm
    Hatta programlama dışı alanlarda bile patolojik biçimde yanlış şeyler söylüyor gibi geldi
    Anthropic raporunda gördüğüm “sileceğim” tarzı uyarılar da işe yaramadı ve kullanım sonrası mobil uygulamada geri bildirim bile gönderemedim
    Başkalarında Claude ile ilgili sorun yokmuş gibi görünüyor; acaba bu durumda yalnız olan ben miyim diye merak ediyorum

    • Son güncellemelerde AI’ın yetenekleri fazla budanmış gibi geliyor
      3.5 sürümüne kadar metin analizi, özetleme, kısa yazı yazma gibi basit işlerde iyiydi ama 4 ve üstü sürümlerde aynı context içinde 3-4 turdan fazla komutları düzgün takip edemiyor
      “Kısa ol dedim, neden yine uzun uzun açıklıyorsun” diye sorunca, varsayılan ayarlar nedeniyle komutları görmezden geldiğini ve “zararlı bilgi” saydıklarından özellikle kaçınmaya çalıştığını söylüyor
      Mantık hatalarını birkaç kez gösterince bazen kendisi de güvenilirliğinin düşük olduğunu kabul ediyor
      Hatta bazen fazla akıllanıp sorun çıkarmaya başlamış gibi geliyor; Anthropic bunu gerçekten yanlış yöne götürdüyse üzücü olur

    • Yukarıda söylenen sorunların hepsini bizzat yaşadım
      Web tarafında çok spesifik istekler verince biraz daha iyi oluyor ama yine de üretilen kodun yarısında hata kalıyor

  • Dokümantasyon ipuçlarını okurken fark ettim ki, aslında bu kurallar sadece AI için değil, genel yazılım geliştirme için de geçerli
    CLAUDE.md yerine CONVENTIONS.md, AI için notlar yerine OKUYUCU için notlar bıraksanız da aynı derecede faydalı olur
    Yabancı bir kod tabanına yeni katkı verirken böyle yorumlar görmek epey hoşuma giderdi

    • aider ile gerçekten denedim ve oldukça iyi çalıştı
      Uçağı beklerken PDF görüntüleyici ve çizim özelliği eklenmiş bir kodu 30 dakikada tamamladım

    • Orijinal yazının yazarı değilim ama Claude’a yardımcı olan yorumlarla insanlara yardımcı olan yorumların tarzı gerçekten belirgin biçimde farklı
      İnsanlar için stil rehberi genelde 100 satır kadar olur ve “input değiştiren fonksiyonlara mutlaka ! ekle” gibi basit kurallardan oluşur
      Claude için hazırladığım rehber ise 500 satırdan uzundu; her kural için “bunu yap, şunu yapma” türünde çok sayıda örnek koymadan pek etkili olmuyordu

  • Yazı için teşekkürler
    Birçok geliştiricinin, işin kontrolünü kısmen LLM’lere devrederken hissettiği tedirginlikle; bunun mevcut resmi ve katı geliştirme metodolojileri yerine deneysel ya da yapısız bir yaklaşım gibi görünmesi arasındaki gerilimi çok iyi yansıtıyor
    Yine de LLM’lerle çok daha hızlı problem çözmeye çalışan bu “hedef odaklı optimizasyon”, gerçekten uygulanabilir bir orta yol yaratıyor
    Çoğu zaman implementasyon detaylarına takılıp asıl hedefi kaçırıyoruz; LLM kullanımı bunun gibi hataları azaltmaya yardımcı olabilir

    • Kesinlikle doğru
      Ben LLM’leri henüz tamamlanmamış bir kaldıraç gibi görüyorum; hâlâ pürüzlü ve hata yapıyorlar ama öğrenerek kullanmaya fazlasıyla değerler
      Kötü mühendisliği meşrulaştıran bir bahaneye dönüşmediği sürece, gerçekten işe yarayan bir araca evrilmeleri için çaba göstermek önemli

  • Yazının en üstündeki 2.3MB’lık görsel, Wi‑Fi’da bile şaka gibi yavaş yüklendi

  • Birkaç düşünce

    • LLM ile ilgili prompt’ları ya da spesifikasyonları kod tabanında daha rafine biçimde düzenlemenin yolu var mı diye merak ediyorum
      CLAUDE.md, SPEC.md ve AIDEV yorumları çoğalınca yönetmesi zorlaşacak gibi

    • Bu günlerde vibe-coding tam olarak ne anlama geliyor, merak ediyorum
      Karpathy’nin “kovboy modu” gibi koda bakmadan tüm diff’leri kabul etmekten, artık neredeyse tüm LLM iş akışlarını kapsayan bir anlama kaymış gibi görünüyor

    • Başkalarının LLM’lerine kod gönderirken kaynak kodu obfuscate edip etmediğinizi de merak ediyorum

    • Yorumlar arttıkça kodun çok hızlı karmaşıklaştığı kesin
      Bu yüzden bunları görselleştirip gutter’da küçük göstergeler halinde gösteren bir VS Code eklentisini kendim geliştiriyorum
      vibe-coding herkes için farklı şey ifade ediyor ama benim deneyimimde kusursuz bir çözüm değildi ve çeşitli sorunlarla karşılaştım
      3.7 Sonnet ile Codex yaklaşık %60 verim sağladı ama Opus 4 gerçekten çok etkili hissettirdi
      Kod obfuscation konusuna gelince, yazıdaki örneklerin hepsi zaten open source olduğu için büyük bir sorun yoktu

  • Çok ilginç buldum; kendi CLAUDE.md dosyama da uygulamayı düşünüyorum
    “Token tasarrufu yapmak için context’ten kısmak aslında ters etki yaratıyor” şeklindeki bu paradoksal AI geliştirme dersine katılıyorum
    Daha büyük projelerde ve daha karmaşık kodlarda Claude Opus ile Sonnet arasındaki farkın gerçekten belirgin olduğunu ben de doğrudan hissediyorum
    Sonnet çoğu zaman gereksiz denemeleri tekrar edip dururken durumu daha da kötüleştiriyordu
    Sonuçta Max aboneleri için Opus ve Sonnet’i bu kadar ayırmaya gerçekten gerek var mı diye düşünmeden edemiyorum
    Sonnet’in 10-20 turda yapacağını Opus bazen 2-3 turda bitiriyor; uzun vadede bu da Sonnet’in kullanım maliyetini fiilen daha yüksek hale getiriyor

    • Max aboneliğin iki farklı katmanı var; $100 olan Pro’ya göre 5 kat, $200 olan ise 20 kat token veriyor
      Token hesabını yapmak kolay değil ve hibrit mod, Opus token’ları %20 seviyesine düşünceye kadar Opus kullanıp sonra otomatik olarak Sonnet’e geçiyor

  • Yazı iyi yazılmış ama “testleri asla AI’a bırakmayın” kısmına katılmıyorum
    Ben artık tüm testleri AI’a yazdırıp sonrasında kendim dikkatle inceliyorum
    Yeni kod için yüksek özerklik istiyorsanız testleri de AI’a yaptırmanız gerekiyor
    AI’a testleri yazmasını ve geçirmesini açıkça söylüyorum; o geliştirme yaparken ben de anında review edip eksik test senaryolarını ekliyorum

  • İçeriğin çoğuna katılıyorum ama Claude’un testlere ya da migrasyonlara hiç dokunmaması gerektiği yönündeki politikaya katılmıyorum
    Test yazmak benim en sevmediğim iş; LLM’in en azından kaba bir taslak çıkarması bile büyük yardım oluyor
    Asıl önemli nokta, kim üretmiş olursa olsun nihai sahipliğin ve sorumluluğun her zaman insanda kalması
    Mesajın tonundan, yazarın Claude’a yeterince güvenmemesi ya da çalışanların AI çıktısını eleştirel süzgeçten geçirmeden kabul etmesini istememesi gibi bir neden seziliyor
    Ya da testler ve migrasyonlar için katı kurallar olmazsa gerçek kodun bozulması veya veri kaybı yaşanmasının çok gerçek bir risk olduğunu düşünüyor olabilir

    • Bu da doğru ama benim deneyimimde ciddi sorun yaşadığımız örnekler oldu
      1. Üretilen testleri daha sonra insanların elle düzeltmesi gerektiğinde gerçekten ciddi tuzaklar çıkıyordu
      2. Claude bağlamsal context’i iyi bilmediği için neredeyse her şeyi mock’layıp servisimizden ve build ortamımızdan tamamen kopuk testler üretiyordu
      3. Ve daha büyük sorun şu: ekip genelinde testlere karşı aşırı bir rehavet oluşuyor
        Sonuçta production’daki bug sayısı gerçekten belirgin şekilde arttı