Claude Code ile Mac uygulaması geliştirmek

• Claude Code ile 20 binden fazla satırlık bir macOS uygulamasının neredeyse tüm kodu üretilip yayımlandı; elde yazılan kod 1.000 satırın altındaydı
• Yapay zeka kodlama ajanlarının ortaya çıkışıyla birlikte, geleneksel IDE yerine prompt merkezli bir geliştirme deneyimi oluşuyor
• Swift ve SwiftUI kod üretiminde bazı sınırlar olsa da, priming, bağlam mühendisliği ve geri bildirim döngüsü tasarımıyla kalite artırılabiliyor
• Otomasyon, dağıtım, dokümantasyon ve testlerin büyük kısmını Claude üstlenerek tekrarlayan manuel işleri ve zaman kaybını çarpıcı biçimde azaltıyor
• Geleceğin IDE’si, kod editörü yerine ajan kullanımı ve bağlam yönetimini merkeze alan yeni bir UX’e evrilecek

---

Yalnızca Claude Code ile bir macOS uygulaması yayımlama deneyimi

Projeye genel bakış

• Kısa süre önce Context adlı yerel bir macOS uygulaması yayımlandı. Bu, MCP sunucusu hata ayıklaması için bir geliştirici aracı
• Bu uygulama neredeyse %100 Claude Code ile yapıldı. Yaklaşık 20 bin satırın içinde doğrudan yazılan kod 1.000 satır bile değil
• Claude ile yazılım üretmek için hâlâ geliştirici becerisi, yinelemeli çalışma ve iyi prompt yazma yetkinliği gerekiyor
• Bu yazı, Claude Code kullanarak uygulama geliştirmenin tüm sürecini, araç seçimini, artılarını-eksilerini ve yüksek kaliteli kod üretme yöntemlerini ayrıntılı biçimde anlatıyor

1. Copilot’tan Claude Code’a ve geliştirme ortamındaki değişim

• Kullanılan ilk yapay zeka kodlama aracı GitHub Copilot’tu ve basit otomatik tamamlama bile geliştirme verimini ciddi ölçüde artırdı
• Sonrasında Cursor’un ajan modu, Windsurf gibi kod tabanından bağlam toplayan ve derleme-test tekrarını otomatikleştiren ajan tipi araçlar hızla çoğaldı
• Claude Code, klasik editörlerden (ör. VS Code) farklı olarak yalnızca terminalde çalışan, prompt girişi odaklı saf bir ajan ortamını hedefliyor
• Geleneksel IDE özelliklerinin çoğu çıkarılmış; geriye yalnızca bir prompt kutusu ve sonuçları gösteren basit bir UX kalmış durumda
• Kodlama ajanı mevcut IDE’yi desteklemekle yetinmiyor, onu tamamen değiştirmeyi deniyor
• Arayüz ve kullanım deneyimi mevcut araçlardan farklı olduğu için UX konusunda başlangıçta şüphe vardı, ancak bu yeni yaklaşım ilgi çekici bulunduğu için denemeye karar verildi

2. Yan projeye yeniden başlamak

• İş hayatını sürdürürken birçok geliştiricide olduğu gibi, bitmemiş yan projeler birikmeye devam ediyor
• Prototipler hızla hazırlanıyor, ancak son %20’lik tamamlama aşamasında zaman ve enerji eksikliği yüzünden gerçek bir yayına ulaşılamıyor
• MCP sunucularını test etme deneyimi sırasında yerel bir uygulamaya ihtiyaç olduğu düşünülerek uygulamayı doğrudan geliştirmeye karar verildi
• Bu süreçte Claude Code ciddi biçimde kullanılmaya başlandı ve yapay zeka ajanlarının pratikte ne kadar büyük yardım sağlayabildiği doğrudan görüldü

3. Claude Code’un güçlü kod üretme yeteneği

• En yeni Sonnet 4 ve Opus 4 modellerini kullanan Claude Code, gerçekten iyi kodu hızlı biçimde üretebiliyor
• Proje bağlamını okuyup kod stilini kavrıyor, ilgili dokümanları ve spesifikasyonları inceleyerek özellik geliştiriyor, ayrıca test kodunu da otomatik yazıyor
• Derleme, test tekrarı, konsol logları ve ekran görüntüsü analizi, hata düzeltme gibi işler de büyük ölçüde otomatikleşiyor
• Geliştiricinin bizzat kod yazdığı sürenin çok küçük bir kısmıyla yüksek kaliteli çıktılar üretebiliyor
• Adeta hiçbir bağlam bilmeyen yeni bir çalışanın projeye dahil olup birkaç dakika içinde özellik tamamlaması düzeyinde bir üretkenlik sergiliyor

4. Swift ve SwiftUI desteğinin gerçek kalitesi

• Swift 6.1, macOS 15.5 ve en güncel SwiftUI kullanıldı
• Claude, Swift 5.5’e kadar olan konularda genelde başarılı, ancak concurrency gibi daha yeni değişikliklerde zayıf kalabiliyor
• Modern API’lerle legacy API’leri, Objective-C ile SwiftUI’yi karıştırıp hata yaptığı durumlar da olabiliyor
• SwiftUI kodunda ilk taslak biraz eksik veya kaba olabiliyor, ancak yinelemeli yönlendirmeyle yeterince iyi hâle getirilebiliyor
• UI kodu karmaşıklaştığında derleyici hataları (ör. tür çıkarımı başarısızlığı) oluşabiliyor; Claude bunları otomatik olarak daha küçük fonksiyonlara refactor edebiliyor
• CLAUDE.md dosyasına talimatlar eklenirse Claude’un kod kalitesi bir kademe daha yükseltilebiliyor
  • Örnek: Önceliği SwiftUI’ye verme, Apple Human Interface Guideline’a uyma, en yeni macOS ve Swift6 özelliklerini aktif kullanma
• Buna ek olarak agent-rules deposundaki yönergeler kullanılırsa daha da yüksek kaliteli kod üretmek mümkün

5. "Bunu daha güzel yap" demek mümkün

• Claude’a "daha güzel/daha zarif/daha kullanışlı yap" gibi basit prompt’larla UI tasarımı iyileştirilebiliyor
• UI hataları veya iyileştirme noktaları için ekran görüntüsünü Claude’a yapıştırıp yinelemeli geri bildirim vermek anında sonuç veriyor
• Daha sistematik bir yaklaşım olarak önce "UI’ı nasıl daha güzel hâle getirebileceğini öner" denilip, ardından istenen değişiklikler seçilerek uygulatılabiliyor

6. Bağlam mühendisliğinin önemi

• Güncel yapay zeka modelleri eksik prompt’ları veya dilbilgisi hatalarını bile oldukça iyi anlayabiliyor
• Asıl önemli olan, sınırlı bağlam penceresi içinde (200k token) gerçekten gerekli bilgiyi en verimli şekilde yerleştirmek
• Claude, konuşma bağlamı dolduğunda otomatik özetleme (compaction) yapıp bağlamı sıfırlıyor; bu süreçte ayrıntı kaybı veya kalite düşüşü gibi bilgi kaybı riskleri doğabiliyor
• Bu nedenle, sınırlı bağlam içinde mümkün olan en yüksek kaliteyi üretmeye yönelik "context engineering", yapay zeka ajanı kullanımının temel konusu hâline geliyor

7. Ajan priming’i

• Bu compaction sürecinde önemli bağlam eksilebildiği için, gerekirse manuel özetletmek veya ek bilgileri önceden yüklemek (priming) etkili olabiliyor
• CLAUDE.md dışında belirli kaynak kodları, spesifikasyon dokümanları vb. önceden okutup özetletmeye yönelik prompt’lar hazırlamak çıktı kalitesini artırıyor
• Yeni kütüphaneler ya da Claude’un bilgi cutoff tarihinden sonra çıkan güncel API’ler için de, ilgili dokümanlar belirli araçlarla (Context7, llm.codes vb.) Claude’un daha kolay anlayacağı biçime dönüştürülebiliyor
• Priming, "Bu kaynak dosyaları, dokümanları ve spesifikasyonları okuyup özetle" gibi komutlarla Claude’un önce bağlamı tam olarak kavramasını sağlama süreci

8. Ajanın açık bir spesifikasyona ihtiyacı var

• Claude’a bir özelliği geliştirtebilmek için istenen sonucu almak adına mutlaka somut ve ayrıntılı bir spesifikasyon vermek gerekiyor
• Sıkça gösterilen "tek cümlelik prompt ile uygulama yapma" örnekleri gerçekte en fazla prototip seviyesinde kalabiliyor
• Spesifikasyon kusursuz olmak zorunda değil; sesli anlatım, yazı yazarak açıklama gibi rahat bir yöntemle aktarılması yeterli

9. "Ultrathink and Make a Plan"

• Claude düşünmeden doğrudan implementasyona geçtiğinde çıktı kalitesi düşebildiği için, önce 'think' veya 'ultrathink' gibi genişletilmiş düşünme modu ile plan yapmasını istemek etkili bir strateji
• Adım adım ilerleyip uygulama öncesinde planı gözden geçirtmek ve geri bildirimden sonra işe başlatmak kaliteyi artırıyor
• Anthropic’in Claude Code: Best practices for agentic coding dokümanı özellikle okunması önerilen bir kaynak

10. Geri bildirim döngüsü kurmak

• Claude Code’un asıl gücü, geri bildirim döngüsünü bağımsız biçimde çalıştırabildiğinde en üst düzeye çıkıyor
• Yani Claude’un kodu kendisinin değiştirip, derleyip, başarısızlık nedenini analiz ederek yeniden yinelediği otomatik bir döngü kurmak kilit nokta
• Bu döngü ne kadar iyi tasarlanırsa Claude da o kadar özerk biçimde yüksek kaliteli kod üretebiliyor
• 1. Build (Derleme)
  • Claude’un uygulamayı kendi başına derleyebilmesi gerekir
  • Swift paketlerinde swift build komutuyla derleme kolayca yapılabiliyor ve Claude bunu doğal biçimde yönetebiliyor
  • Ancak macOS uygulama hedeflerinde (ör. Xcode projesi) hangi xcodebuild komutunun kullanılacağı konusunda Claude zaman zaman karışıklık yaşıyor
  • Bu sorunu çözmek için XcodeBuildMCP adlı araç kullanıldı; bu araç Claude’a uygulama derleme ve çalıştırma için daha basit bir arayüz sunuyor
• 2. Test (Test)
  • Claude, kodu derledikten sonra testleri otomatik çalıştırıp sonuçları analiz edebilmelidir
  • Swift paketlerinde swift test ile testler doğal biçimde yürütülüyor ve Claude bu süreci iyi yönetiyor
  • Henüz tüm uygulama testlerini veya UI testlerini Claude’un doğrudan çalıştırması denenmedi, ancak bunun için de XcodeBuildMCP benzeri araçların gerekeceği düşünülüyor
  • Test sonuçları (başarılı/başarısız logları) temel alınarak kod düzeltme döngüsü sürdürülüyor
• 3. Fix Bugs (Hata düzeltme)
  • Claude, debug için log ekleme yöntemiyle sorunları takip edebiliyor
  • Ancak Claude’un uygulamayı doğrudan kullanıp log ürettirmesi mümkün değil
  • Bunun için kullanıcının uygulamayı manuel olarak çalıştırıp konsoldaki logları kopyalayarak Claude’a yapıştırması gerekiyor
  • Bu yöntem pratikte işe yarasa da, önceden yeterince unit test veya UI testi yazılmadıysa tam otomatik hata düzeltme zorlaşıyor
  • Web uygulamalarında playwright-mcp gibi tarayıcı otomasyon çözümleri varken, yerel uygulamalarda henüz net bir alternatif bulunmuyor
• 4. Fix UX Issues (UX sorunlarını düzeltme)
  • UI/UX sorunlarını iyileştirmek için ekran görüntülerini doğrudan Claude’a yapıştırıp yinelemeli geri bildirim vermek mümkün
  • Peekaboo gibi araçlarla ekran görüntüsü otomasyonu yapılabilse de, önce uygulamayı istenen duruma manuel getirip sonra ekran görüntüsü alma gerekliliği hâlâ bir sınırlama
  • Yani UX ile ilgili otomasyonda da kullanıcı müdahalesi hâlâ gerekiyor

11. Claude Code, kod yazmanın ötesinde işler de yapıyor

• Claude Code genel amaçlı bir büyük dil modeli (LLM) üzerine kurulu olduğu için, kod yazmanın dışında çeşitli geliştirme dışı işlerde de kullanılabiliyor
• Örneğin uygulama içi metinleri düzenleme, sürüm planı hazırlama, özellik geliştirme yönü önerme gibi yazılım dışı görevler de doğal biçimde Claude’a verilebiliyor
• Özellikle faydalı bulunan noktalardan biri, gerçek veri olmayan erken aşamalarda mock veriyi otomatik üretebilmesi oldu
  • Context uygulaması geliştirilirken, Swift için MCP istemci kütüphanesi henüz tamamlanmamış olsa da UI prototipi üzerinde çalışmak isteniyordu
  • Normalde gerçekçi görünen mock veriyi elle üretmek çok zahmetli ve zaman alıcı olduğundan, muhtemelen hiç denenmeyecekti
  • Ancak Claude, birkaç saniye içinde son derece inandırıcı mock veriler üreterek neredeyse gerçek sistemden ayırt edilemeyen UI durumları oluşturdu
  • Hatta UI arkadaşlarla paylaşılırken, bu mock verilerle hazırlanmış ekran görüntüleri kullanıldı ve neredeyse gerçek ürün düzeyinde bir izlenim verildi
  • MCP sunucuları tarafında o dönemde resmî spesifikasyonun yalnızca bazı özellikleri uygulanmış olduğundan gerçek veri elde etmek zor bir durumdu
  • Buna rağmen Claude’un ürettiği mock verilerle tüm UI akışı ve işlev davranışları doğrulanabildi

12. Yüksek kaliteli otomasyonun (neredeyse) bedavaya geldiği dönem

• Yazılımı yayımlamanın son %20’sindeki en sancılı konulardan biri, uygulama sürümleme sürecinin otomasyonu
• Özellikle macOS uygulamalarında kod imzalama, notarization ve paketleme (DMG oluşturma) gibi karmaşık dağıtım süreçleri nedeniyle manuel işlemler veya kararsız script’ler yüzünden yayınlar sık sık gecikiyordu
• Eskiden fastlane gibi otomasyon araçları zorla kuruluyor ya da en azından temel Python script’leri elde yazılıyordu
• Bu projede ise birkaç saatlik yinelemeli prompt ve debugging ile Claude eksiksiz bir sürüm otomasyon script’i üretti
• Bu script’in üstlendiği başlıca işler:
  • Ortam kurulumu kontrolü: Gerekli araçların doğru kurulu olup olmadığını denetleme
  • Değişiklik günlüğünü otomatik oluşturma: git commit’lerinden değişiklik geçmişini çıkarıp elle yazılan maddelerle birleştirerek HTML release note üretme
  • Uygulamayı derleme ve paketleme: Derleme → kod imzalama → notarization → DMG paketleme sürecinin tamamını otomatikleştirme
  • Sparkle güncelleme akışı (appcast) üretme: Mevcut kullanıcılara otomatik güncelleme sağlama
  • Release etiketi ve dağıtım: GitHub’a etiket ekleme ve release yayımlama
  • Sentry sembol yükleme: Çökme raporlarını analiz etmek için debug sembollerini otomatik yükleme
• Script tamamlandıktan sonra, "CLI çıktısını daha güzel yap" şeklindeki tek satırlık bir prompt ile CLI arayüzünde iyileştirme de yapıldı
• Nihai sonuç yaklaşık 2.000 satırlık Python kodu oldu; elde yapılsaydı muhtemelen yalnızca zorunlu işlevler tamamlanacakken, Claude sayesinde yüksek kaliteye ulaşıldı
• Bu otomasyon script’i sayesinde her sürümde tekrar eden onlarca dakikalık işten tasarruf etmek mümkün oldu
• Spesifikasyonu doğal dille anlatıp, çalışma sırasında görülen hataları Claude’a geri bildirim olarak vermek çoğu zaman işin tamamlanması için yeterliydi

13. Geleceğin IDE’si tamamen farklı olacak

• Bu proje boyunca gerçekten baştan sona kullanılan araçlar yalnızca Claude Code ve GitHub Desktop (diff görüntülemek için) oldu
• Geleneksel IDE’lerin temel özellikleri olan dosya ağacı, kod editörü, eklentiler ve plugin’ler neredeyse hiç gerekmedi
• Nadiren Xcode açılıp kod doğrudan düzenlense de, Xcode’a özgü işlevler (ör. SwiftUI Previews, View Debugger vb.) de neredeyse hiç kullanılmadı
• İçinde bulunduğumuz dönem, yapay zeka kodlama ajanlarının yeteneklerinin aslında en düşük olduğu an olduğu için, IDE’lerin gelecekte tamamen yeni bir biçime evrileceği düşünülüyor

• Copilot, Cursor, Windsurf gibi araçların hepsi VS Code çıkışlı ve üzerine ek özellikler koyan yapılar olsa da, VS Code’un kendisi 20 yıl önceki JetBrains IDE’lerinden çok da farklı değil
• Warp gibi projeler terminali modernleştirip onu ajan merkezli geliştirme ortamına dönüştürmeye çalışıyor, ancak terminal merkezli UX’in de geleceğin nihai cevabı olmayacağı düşünülüyor

• Geleceğin IDE’sindeki asıl odak, geliştiricinin ajan bağlamını etkili biçimde hazırlamasını (priming) ve geri bildirim döngülerini tasarlayıp yönetmesini sağlamak olacak
• Yani merkezde kod editörü değil, ajan kullanımı ve bağlam yönetimi odaklı bir UX yer alacak

14. Yan projeleri yeniden yayımlayabilmek

• Bu yolculuğun en etkileyici yanı, harika bir uygulama üretmiş olmaktan da öte, yeniden kendi yan projelerini gerçekten yayımlayabilir hâle gelmekti
• Sanki her gün fazladan 5 saat kazanılmış gibi, üstelik bunun bedeli ayda yalnızca $200
• Claude Code gibi yapay zeka kodlama ajanları sayesinde, uzun süredir ertelenen fikirleri gerçeğe dönüştürmek için gerekli motivasyon ve güven yeniden kazanıldı

[geek12356]

Bol bol yap.

[GN⁺]

Hacker News görüşü

• Daha 2 yıl önce kendimi gerçekten çok iyi bir Python mühendisi olarak görüyordum; şimdi ise native mobil uygulamalar, Slack ile iletişim kuran masaüstü uygulamaları, Go ile yazılmış API’ler ve React tabanlı tam teşekküllü web uygulamalarını birkaç gün hatta birkaç saat içinde yapabilir hale gelmiş durumdayım
  Sanki süper güç kazanmış gibi hissediyorum; üretkenlik, hız ve yaratıcılık taşıyor, ama bir yandan da tuhaf bir hüzün duyuyorum
  Mesleğim, tutkum ve uzun zaman harcayıp fedakarlık ederek öğrendiğim her şey artık büyük ölçüde makineler tarafından ikame ediliyor
  Bu araçları yapan şirketler daha yolun başında
  Bunun gelecek nesil mühendisler için ne anlama geleceğini ve bu gidişin nereye kadar süreceğini merak ediyorum
  Benzer duygular yaşayan var mı diye de merak ediyorum

  • Bir Python mühendisi olarak yazılım geliştirme deneyimim sayesinde native, mobil, Go, React gibi farklı araçları çeşitli platformlarda verimli biçimde kullanabilir hale geldim
    LLM’lerin ikame ettiği şey, her platforma özgü küçük ayrıntıları ezberleme zorunluluğu
    Go’da for döngüsünün söz dizimini ezbere bilmiyor olsam da hemen işe yarar Go kodu yazabiliyorum
    Yine de döngüleri, Go kavramlarını, yapısal programlamayı, derleyicileri, build ve test script’lerini gibi temel ilkeleri anlamak hâlâ şart
    Programlama geçmişi olmayan insanlarda eksik kalan kısım büyük ölçüde burası
    LLM’ler bana, uzun kariyerim boyunca biriktirdiğim bulanık bilgiyi farklı dillere ve platformlara anında uygulayabilmemi sağlayan bir yükselteç ve hızlandırıcı gibi geliyor
    Eskiden her sorunu Python, JavaScript ve SQL ile çözmeye çalışmamın sebebi, yeni dil ve platformların ufak farklarını yeniden öğrenmenin gözümde büyümesiydi
    Şimdi ise Go, Bash, AppleScript, jq, ffmpeg gibi araçları da isteyerek kullanıyorum; hatta Swift projelerini de değerlendirmeye başladım

  • Alan dışından insanların LLM kullanarak bir şeyler yaptığını gördüm; çoğu zaman ya çok daha yavaş ilerliyorlar ya da neredeyse tamamen başarısız oluyorlar
    Teknik beceri nihayetinde zorunlu olmayabilir ama açık ve net iletişim kurabilme kesinlikle gerekli
    Sadece HTML’i anlayacak kadar bilgi bile metni temiz biçimde yerleştirip LLM’in daha net anlamasını sağlamaya yetiyor
    Teknik geçmişin hâlâ önemli bir avantaj olduğunu düşünüyorum

  • Sanayi Devrimi öncesindeki zanaatkarların da benzer duygular hissettiğini düşünüyorum
    Ama onların çoğunun doğru düzgün eğitim almadığını, çocuklarından 1-2’sinin basit hastalıklar yüzünden 10 yaşına gelmeden öldüğünü ve elektriksiz, musluk suyu olmadan, iç tesisatsız ve buzdolapsız yaşadığını da hesaba katmak gerek
    Aletleri doğrudan elle yapmak romantik gelebilir (tıpkı Python kodunu elde yazmak gibi), ama çağ ilerledikçe daha soyut katmanlarda yaşamanın atalarımız için de aslında daha faydalı olacağını düşünüyorum
    Kimse insanları Python kodunu bizzat yazmaktan alıkoymuyor; tıpkı kurşun kalem ucu işçiliği gibi bunu hobi olarak yapanlar mutlaka çıkacaktır

  • Kurduğum kariyerin, tutkunun ve becerilerin artık makineler tarafından devralındığı fikrine katılmakta zorlanıyorum
    Makineler deneyim, öngörü, öz değerlendirme, planlama yeteneği ya da yaratıcılık olmadan sadece talimatları izler
    Fikir, yaratıcılık, hedef ve empati yeteneğine sahip olan; iyi fikirlerle başkalarını ikna edebilen ve bağlama göre durumu değerlendirebilen yalnızca insandır
    Programcılık mesleğinin ortadan kalkmasından ziyade çok daha yüksek bir soyutlama seviyesine taşındığını düşünüyorum
    Eskiden bitleri, baytları ya da assembly satırlarını bilmeden de geliştirici olunabiliyordu; bir zamanlar assembly’nin zorunlu olduğu dönemler de vardı
    Şimdi ise programlama dillerini hiç bilmeden, yalnızca İngilizceyi ve gereksinimleri iyi anlayarak program üretilebilen bir dönemdeyiz
    Yine de bellek yapısını, assembly’yi ve düşük seviye kavramları bilenler arka planda neler olduğunu hâlâ daha iyi anlıyor ve gerektiğinde bunu daha “iyi” yapabiliyor
    Ama bu, üst soyutlama katmanlarının işe yaramaz hale geldiği ya da ortadan kalkacağı anlamına gelmiyor

  • Ben de tamamen aynı şeyi hissediyorum
    20 yılı aşkın süredir profesyonel olarak yazılım geliştiriyorum ve bu işten gerçekten keyif alıyordum
    Şu anda Claude Code’dan %100 faydalanıyorum ve üretkenliğimin belirgin biçimde arttığı açık; ama eskiden süreç bana bir sanat gibi gelirken, şimdi daha çok sanayileşmiş seri üretim hissi veriyor
    Bu yeni gerçeklik içinde beni yazılıma derinden bağlayan o şeyi yeniden bulmak istiyorum ve eski eğlencenin büyük kısmının azaldığı kesin

• Yazı çok iyi kaleme alınmış; sadece okumak bile keyif veriyor
  Geleceğin IDE’leri bugünkülerden tamamen farklı olacak
  Ben de Cursor ile başladım, sonra VS Code tabanlı güçlendirilmiş IDE’ler kullandım ve sonunda Claude Code’a geçtim
  Bunun sonucunda terminalin önemi arttı ve iş akışımı iTerm’den Ghostty’ye (hızlı, hafif ve modern), Tmux, Tmuxinator ve NeoVim’e taşıdım
  Dosyaları cat ya da bat komutuyla kontrol ediyorum, ara sıra yalnızca metin düzenliyorum ve ağır işlerin çoğunu Claude Code üstleniyor
  NeoVim ya da Emacs içinde daha çok sadece spesifikasyon ve prompt yazıyorum; bu iş akışını çok seviyorum
  Sadece kod üretiminde değil, zsh, neovim, ghostty gibi config dosyalarını düzenlerken de Claude Code’a görev veriyorum
  Yapılandırma dosyası refactor işlemleri bile birkaç dakikada bitiyor
  Kod tabanı hakkında soru sorma, kod refactor etme, kod dokümantasyonu ve commit mesajı oluşturma gibi işleri de tamamen ona bırakıyorum; tam anlamıyla müthiş

  • Sonunda kod tabanı soruları, refactor, kod dokümantasyonu ve anlamlı commit’ler oluşturduğundan bahsedilmiş; ben de CC ile çok iyi commit mesajları ürettirdim ve Conventional Commits bilgileriyle örnekleri CLAUDE.md dosyasına koymuştum

  • CC, .zshrc gibi kişisel yapılandırma dosyalarını değiştirmeden önce otomatik yedek alıyor mu, merak ediyorum

• Terminal + Claude Code + proje klasörü
  Gerçekten de sadece bunların yeterli olduğunu artık fark ettim
  Tam IDE kurulumları bana baştan beri zahmetli geliyordu; işletim sistemleri arasında cross-compile yapmak için QT ayarları da karmaşıktı, bu yüzden editör + terminal kombinasyonunun her zaman en mantıklısı olduğunu düşünüyordum
  Şimdi Claude Code da ayrı bir açık terminal penceresi olarak isteklere yardımcı olunca, geliştiriciden proje liderine “level atlamışım” gibi hissediyorum
  Üstelik çalışan yönetme stresi de yok
  Martta Claude çıktığından beri, eskiden yapmak isteyip ertelediğim tüm yan projeleri birkaç ay içinde tamamladım

• 1-2 yıl önce aklıma gelen fikir şuydu: LLM’ler deneyimli geliştiriciler için harika bir yardımcı, deneyimli geliştiricilerin yerine geçmeye kalktığında berbat ve deneyimsiz geliştiriciler için tehlikeli bir yardımcı
  Bizzat deneyimleyince bunun çoğu zaman doğru çıktığını gördüm
  Bugün artık LLM’lerin deneyimsiz geliştiriciler için iyi bir mentor da olabileceğini düşünüyorum; ama pratikte daha çok, kodun neden çalıştığını anlamadan rastgele değişiklikler yapıp bir şekilde çalışana kadar denemeyi tekrar eden kişiler görüyorum
  Bu yüzden böyle durumlarda LLM’in tehlikeli bir yardımcı olduğu yönündeki ilk düşüncem daha da güçlenmiş durumda
  Böyle anlarda ince bug’lar ve sorunlar fark edilmeden kodun içine sinsice yerleşiyor; fark edilseler bile neden kaynaklandıklarını anlamak çoğu zaman mümkün olmuyor

• LLM yardımcıları sayesinde yan projelerde son %20’lik tamamlama kısmının ciddi biçimde kısaldığı sonucu özellikle etkileyici geldi
  Benim için bu yolculuğun en heyecan verici yanı yeni uygulamalar değil, yeniden kod yazma isteği duymam ve temiz yan projeleri yüksek tamamlanmışlıkla yayına alabiliyor olmam
  Sanki günde fazladan 5 saat kazanmışım gibi ve bunun için ayda 200 dolar yeterli

• Ben daha çok küçük yardımcı araçlar yaparken kullanıyorum ve gerçekten fantastik derecede iyi çalışıyor
  launchctl/launchd görev durumlarını (çalışıyor / unload edilmiş / başarısız vb.) OrbStack menü simgesi gibi gösteren bir yardımcı aracı Claude ile birkaç saat içinde tam istediğim gibi yaptım

  • Ben de kendi keyfim için bir iOS uygulaması ve bir Wordpress eklentisi yaptım, bundan gerçekten çok memnun kaldım
    Bundan sonra daha çok insanın bunu yapacağını düşünüyorum; acaba herkes kodunu github’da paylaşmalı mı

• 2008’den beri Mac için yazılım geliştiren biri, Claude’un nerede hata yaptığını muhtemelen hızla fark edip düzeltebilirdi diye düşünüyorum

  • Claude Code gibi araçlar mevcut beceri ve deneyimi büyüten araçlardır
    Asla uzmanlığın yerini tutamazlar

  • Sonunda yazının sonunda bu işin ayda 200 dolara mal olduğu ortaya çıkıyor; ben ana hobim için kesinlikle gerekli olan Autodesk’e bile 50 dolar vermeye zor ikna oluyorum
    Bu tür yapay zeka şirketleri henüz kârlı değil ve yatırımcılar gelir aramaya başladığında maliyetlerin sıçraması ya da hizmet kalitesinin düşmesi kaçınılmaz olacak diye düşünüyorum
    Bu modeller eğitim için izinsiz kullandıkları kodlar yüzünden davaları kaybederse Claude’un Swift üretme becerisi de anında düşer
    Disney’nin yapay zeka davalarında kaybedeceğine gerçekten güvenmek gerekir mi, emin değilim
    Açıkçası yorumumun özel bir ağırlığı yok ama yapay zeka yorgunluğu gerçekten ciddi boyutta
    Bu noktada HN’de ve diğer teknoloji forumlarında bu tür paylaşımların yasaklanması gerektiğini düşünüyorum
    Birisi Google ya da StackOverflow kullanarak kolayca kod yazdığını anlatsa herkes bunun bayağı olduğunu söyleyip küçümserdi; bence bu paylaşımlar da temelde aynı şey
    Yapay zeka ile hobiye ya da mesleğe “beleşten ortak olmak” hikayelerinden bıktım

• Windsurf gibi araçlar ve CLI araçlarıyla kendi özel araçlarımı yapmak artık eskisinden çok daha kolay
  Gerçekten heyecan verici bir dönemdeyiz

• Yakında birileri LLM kullanarak macOS’un kendisini bile kopyalayacakmış gibi bir his var

• Birkaç hafta önce LLM araçlarını kullanarak retro68 ve c++ ile system 6 (klasik Mac) uygulamasında çalışan bir 6DOF wireframe renderer’ı ayağa kaldırmayı başardım