- Yapay zeka ajanlarının basit tekrar eden işleri otomatikleştirmesi, build bekleme sürelerinin ortadan kaldırılması ve paralel worktree sistemi kurulması gibi geliştirme altyapısı iyileştirmeleri sayesinde commit sayısının hızla arttığı 6 haftalık deneyimin özeti
/git-pr becerisiyle PR oluşturma sürecini otomatikleştirerek bağlam değiştirme maliyetini ortadan kaldırma ve ajanın doğrudan daha ayrıntılı PR açıklamaları yazması- Build aracını SWC'ye geçirerek sunucu yeniden başlatma süresini 1 saniyenin altına indirme ve akışın bölünmediği bir geliştirme ortamı sağlama
- Claude Code'un preview özelliği ile ajanın arayüzü kendi kendine doğrulamasını sağlayarak, geliştiricinin tüm değişiklikleri bizzat kontrol etmesi şeklindeki darboğazı kaldırma
- Her sürtünme noktası sırayla kaldırıldığında bir sonraki darboğazın ortaya çıktığı Kısıtlar Teorisi (Theory of Constraints) deseninin olduğu gibi uygulanması
- Artık özellik geliştirmekten çok ajanın verimli çalışacağı altyapıyı kurmaya ve döngü hızını artırmaya odaklanma
Basit tekrar eden işlerin otomasyonu
- Başlangıçta değişiklikleri stage etme, commit mesajı yazma, PR açıklaması yazma, push etme ve GitHub PR oluşturma dahil tüm süreçler manuel olarak yürütülüyordu
- Bunun basit tekrar eden bir iş (grunt work) olduğunun fark edilmesi ilk dönüm noktası oldu; rol de uygulayıcıdan ajanları yöneten bir yöneticiye dönüştü
- İlk Claude Code becerisi olan
/git-pr yazılarak PR oluşturma sürecinin tamamı otomatikleştirildi
- Ajan tüm diff'i okuyup değişiklikleri düzgün özetlediği için, elle yazılandan daha ayrıntılı PR açıklamaları ortaya çıkıyor
- Kod tabanındaki
CLAUDE.md dosyası Graphite kullanımını belirtse de, kişisel olarak plain git tercih edildiği için süreç /git-pr ile yürütülüyor
- Zaman tasarrufunun kendisinden daha büyük etki zihinsel yükün ortadan kalkması oldu: PR yazarken her seferinde yaşanan “kod üzerine düşünme → kodu açıklama üzerine düşünme” şeklindeki küçük bağlam geçişi kayboldu
Bekleme süresini ortadan kaldırma
- Yerel preview almak için üzerinde çalışılan işten çıkıp dev sunucusunu kapatma ve yeni branch'te yeniden başlatma süreci tekrar tekrar yaşanıyordu
- Sunucu build'inin yaklaşık 1 dakika sürmesi, odağı bozacak kadar uzun ama başka bir işe geçmeyecek kadar kısa bir süreydi
- Build sistemi SWC'ye geçirilerek sunucu yeniden başlatma süresi 1 saniyenin altına indirildi
- Dosya kaydedilir kaydedilmez sunucu zaten ayağa kalkmış oluyor ve dikkatin dağılacağı boşluk ortadan kalkıyor
- Bu durum, “garip sessizlikler içeren bir sohbet” ile “doğal akan bir sohbet” arasındaki farka benzetiliyor
Ajanın kendi UI doğrulaması
- Önceden tüm UI değişikliklerinin yerel preview ile tek tek kontrol edilmesi gerektiğinden geliştirici tüm işlevlerin darboğazı haline geliyordu
- Chrome uzantısı sürekli çöktükten sonra Claude Code'un preview özelliğine geçildi
- Ajan preview'ı kurup oturum verisini koruyarak UI'ın gerçekte nasıl göründüğünü doğrudan kontrol edebiliyor
- Bu akış iş akışına entegre edilerek, ajan UI'ı bizzat doğrulamadan “tamamlandı” sayılmıyor
- Doğrulama devredilebildiği için yalnızca son inceleme aşamasında devreye girmek yetiyor ve ajan daha uzun süre otonom çalışabiliyor
- Ajanın hatalarını kendi kendine yakalaması, beklenenden çok daha önemli bir etki yaratıyor
Paralel worktree sistemi
- Hızlı rebuild ve otomatik preview sağlandıktan sonra ortaya çıkan bir sonraki sürtünme: aynı anda rahatça yalnızca tek iş yapılabilmesi
- Başka bir ajanın ya da ekip arkadaşının PR'ını incelemek için main'den PR branch'ine checkout edip rebuild ve test yapmak gerekiyor, ancak bu durum commit edilmemiş değişikliklerle çakışıyor
stash → checkout → rebuild → test → switch back → pop stash ya da worktree'yi elle oluşturup port çakışmalarıyla uğraşmak gerekiyor
- Uygulama, frontend ve backend için ayrı portlar gerektiriyor ve tüm worktree'ler aynı environment variable'ları paylaştığı için aynı portlara bind etmeye çalışıyor
- Bunu çözmek için, worktree oluşturulurken her sunucuya benzersiz port aralıklarını otomatik atayan bir sistem kuruldu
- Aynı anda 10 preview bile çalıştırılabiliyor
- İki paralel branch karşısında bile bunalan durumdan, aynı anda 5 worktree işletilen bir düzeye geçildi
- Birden fazla ajan ayrı worktree'lerde farklı özellikler geliştirecek şekilde çalıştırılıyor ve UI kendi kendine doğrulanana kadar otonom şekilde ilerliyor
- Planlama aşamasına derin şekilde dahil olup, kod inceleme anına kadar müdahale etmeme modeli benimsendi
- İnceleme süreci de çok daha akıcı hale geldi: kurulum işleri, rebuild ve port çakışmaları olmadan okuma, kontrol etme ve merge etme akışı
Asıl mesele yapay zeka değil, altyapı
- Rol değişti: karmaşık problemleri doğrudan çözmek ve kusursuz UI yapmak için zaman harcamak yerine, ajanları etkili hale getiren altyapıyı kurmak daha ilgi çekici hale geldi
- Bu, tek başına çalışan bir geliştiriciden çok 10 kişilik bir ekibin yöneticisi olmaya benziyor
- Gösterişli olmayan bu plumbing işi, flow halinde kalıp kalmayacağınızı ya da ortamla boğuşacağınızı belirliyor
- Tano'da en yüksek kaldıraç etkisine sahip iş, özellik geliştirme değil; commit akışını sel gibi hızlandıran altyapıyı kurmak oldu
Döngü: Kısıtlar Teorisi'nin uygulanması
- Her adım farklı türden bir sürtünmeyi ortadan kaldırıyor:
/git-pr: kod değişikliklerini PR'a dönüştürürken oluşan formatlama sürtünmesini kaldırıyor- SWC: değişiklikten sonra sonucu görene kadar geçen bekleme sürtünmesini kaldırıyor
- preview özelliği: değişiklikleri kontrol ederken yaşanan doğrulama sürtünmesini kaldırıyor
- worktree sistemi: birden fazla iş akışı arasındaki bağlam değiştirme sürtünmesini kaldırıyor
- Biri kaldırıldığında bir sonraki darboğazın hemen görünür hale geldiği, Kısıtlar Teorisi (Theory of Constraints) için tipik bir desen
- İşin doğası değişiyor: artık mesele “kod yazmak için araç kullanmak” değil; işi başlatma → ajanın kod yazması → preview kontrolü → diff okuma → geri bildirim veya merge → bir sonraki işe geçişten oluşan sıkı bir geri bildirim döngüsü
- Döngü yeterince hızlı olduğunda dikkatin kaçacağı bir boşluk kalmıyor ve hız artışının kendisi oyuna dönüşüyor
- Sonuçta geliştirmenin hedefi özellik geliştirmekten çıkıp, döngü hızını daha ne kadar artırabileceğine kayıyor
- Hızın kendisinin mühendislik keyfine dönüştüğü aşamaya ulaşılıyor
2 yorum
Bir reviewer olarak, makinenin yazdığı PR Description'ı gördüğümde deneyim pek de iyi olmuyor. Sadece prompt tuning'i iyi yapmak yeterli olur mu diye de düşünüyorum ama..
Hacker News yorumları
90’lardaki “haftalık kod satırı sayısı” metriği geri dönmüş gibi geliyor
“Daha fazla PR açıyorum” demek, AI’nın iyi çalıştığının kanıtı değil; sadece daha fazla şey merge edildiği anlamına geliyor
Kod kalitesi, bug’lar ve bakım yükünü hesaba katmadan performansı sadece çıktı miktarıyla değerlendirmek, eskiden yöneticilerin dayattığı kötü metriklerden farksız
Sonuçta sanki biz kötü metriklere değil, ölçülüyor olmanın kendisine karşıymışız gibi duruyor
Asıl amaç, basit kodla etkili sonuçlar üretmek
Aynı anda birden fazla agent çalıştırıp farklı implementasyonlar denemelerini sağlıyor, sonra içlerinden iyi fikirleri birleştirmeyi deniyorum
Ayrıca dokümantasyonu ve gereksinimleri toplayıp agente sorular yöneltiyor, kod inceleme geri bildirimlerini genelleyerek bir checklist haline getirip sonraki incelemelere yansıtıyorum
Hasta olacak kadar çalışmak bir övünç değil, sistemin yanlış kurulduğunun işaretidir
Örneğin COCOMO modeli mahkemelerde bile sistem değerini tahmin etmek için kullanılacak kadar güven görüyor
Çoğu geliştirici kendini sayısallaştırmak istemiyor
Ama AI savunucuları, iyileşmeyi kanıtlamak için ölçüm gerektiğini düşünüyor
LLM’leri bilişsel yükü azaltacak şekilde kullanmak gerektiğini düşünüyorum
İnsanlar multitasking konusunda zayıf ve LLM’ler bunu telafi etmiyor
Ben Claude’a implementasyonu tamamen yaptırmak yerine, implementasyon sürecinde bana rehberlik etmesini sağlıyorum
Böylece tüm süreci anlayarak hem ayrıntıları hem de büyük resmi aynı anda görebiliyorum
Tekrarlayan ve mekanik kısımları Claude’a bırakmak yeterli
LLM’e problemi anlaması için sorular soruyor, temel kodu kendim yazdıktan sonra kalan implementasyon planını ona çıkarttırıyorum
LLM kod okuma, açıklama ve basit işlerde güçlü; ben ise problem çözme yönünü seçmeye odaklanıyorum
LLM’in benim yerime verdiği kararları takip etmek için “varsayım listesi oluştur” ya da “planda olmayan kararları sırala” gibi prompt’lar deniyorum
Claude’un özelliklerini anladıkça doğrulama verimi de artıyor, deneyim biriktikçe kalite yönetimi kolaylaşıyor
Birden fazla agent çalıştırıp büyük özellikler geliştirince sonunda inceleme süresinin aşırı artması gibi bir sorun çıkıyor
Çünkü başkasının (ya da AI’nın) yazdığı kodu okumak, kodu doğrudan yazmaktan daha zor
Test otomasyonu bunu bir yere kadar kapsayabilir ama tam güven duymak zor
Kapsamı, testleri ve dokümantasyon planını netleştiriyor; kod inceleme botları (Sourcery, CodeRabbit, Codescene) ve güçlü lint kuralları uyguluyorum
BDD, property testing, e2e testleri, kod denetimi ve mutation/fuzzing testlerine kadar kullanıyorum
Agent tabanlı kodlamanın avantajı, böyle kalite kontrollerine zaman ayırabilmek
100 PRs a day benzeri yaklaşımlarla kademeli dağıtımı deniyorlar
İşi küçük parçalara bölüp testlere güveniyorsanız, AI kod incelemesi de hafifliyor
Test case’lere daha dikkatli bakıyor, kod incelemesini hızlıca bitiriyorum
Birden fazla agent’ı paralel çalıştırmıyorum ama AI sayesinde üretkenliğimin kesinlikle arttığını gördüm
PR yazma süreci basitçe otomatikleşirse kendini doğrulama fırsatı ortadan kalkıyor
Ben çoğu zaman PR açıklamasını yazarken kendi kodumdaki tuhaflıkları fark ettim
İngilizce açıklama yazdığım o an, son sanity check oluyordu
worktree sistemi sayesinde bağlam değiştirmek kolaylaştı ama aynı zamanda zihinsel yorgunluk arttı
Küçük parçalara ayırıp inceleme döngüsünü kısa tutarsanız kaliteyi yönetmek kolaylaşıyor
Akışım bozulmadan ertesi gün geri döndüğümde bile ilerleme kaydedilmiş olması hoşuma gidiyor
Claude’un kodu yüksek olgunlukta tamamladığı varsayımına şüpheyle yaklaşıyorum
Gerçekte birden çok geri bildirim ve düzeltme gerekiyor; birden fazla işi aynı anda paralel yönetmek ise aksine verimsiz olabiliyor
Claude Code öğrenme aracı olarak devrim niteliğinde ama kod üretim kalitesi tutarsız
Flutter/Dart öğrenirken Claude’a kavramlar sormak üzerinden çalıştım ve kitap olmadan bir haftada uygulama yapabildim
Adeta etkileşimli bir ansiklopedi gibi hissettiriyor
“Bu dilde X yapmanın idiomatik yolu nedir?” gibi sorulara anında faydalı cevap veriyor
Ama dünyayı değiştiren bir varlıktan çok çok iyi bir araç sadece
Ama aşırı pazarlama genel ekonomi üzerinde olumsuz etki yaratıyor
AI’nın işleri tamamen devralacağı yanılsaması yüzünden genç kuşakların mesleklerden vazgeçmesi de endişe verici
“SWC’ye geçtikten sonra build sonrası sunucu yeniden başlatma süresi 1 saniyenin altına indi” deniyordu,
SWC Speedy Web Compiler anlamına gelir ve type check yapmadan hızlı transpile eden bir araçtır
NestJS dokümantasyonu da aynı şeyi açıklıyor
LLM kullanmak, üretkenliğin patladığını övünerek anlatılacak bir şey değil
Herkes aynı araçları kullanırsa sadece taban seviye yükselmiş olur
Üstelik AI’nın ürettiği büyük hacimli kod düzgün incelenmezse uzun vadeli kalite belirsiz kalır
LLM’ler üretkenliği artırıyor olabilir ama bunu commit sayısı grafiğiyle ölçmek anlamsız
LOC üzerinden kalite yargılamak kadar saçma
Kodu kendim yazarak anlıyor, Claude’dan ise işleri parçalara ayırma ve review partneri olarak büyük fayda görüyorum
Karmaşık kodu basit soyutlamalarla değiştirebilmek, gerçek üretkenlik budur