2025 GitHub contribution grafiğim iki farklı geliştiriciye aitmiş gibi görünüyor. Yılın ilk yarısı neredeyse boş. İkinci yarıda ise 4.000’den fazla commit var.
Bir anda daha fazla boş zamanım olmadı. Full-time işimi side project’lerle birlikte yürütmeye devam ediyordum. Değişen şey, fikir ile çalışan bir sürüm arasındaki friction oldu: AI coding araçlarını çok daha ciddi biçimde kullanmaya başladım.
Bu sayıyı doğru yorumlamak önemli. Commit sayısı tek başına bir productivity metriği değildir. Dört bin commit, dört bin anlamlı iyileştirme yaptığımı veya kodun iyi olduğunu kanıtlamaz. Ama grafik çalışma biçimimde gerçek bir değişim olduğunu gösteriyor: eskisine göre çok daha düzenli biçimde build ediyor, iterate ediyor ve çalışan sürümler çıkarıyordum.
Asıl darboğaz deneyi başlatmak için gereken enerjiydi
Side projectlerde aynı problem tekrar tekrar karşıma çıktı: ilk faydalı sürüm genellikle bir rutin iş duvarının arkasında. Routing, validation, scripts, tests, configuration ve cleanup, fikrin devam etmeye değer olup olmadığını görmeden momentum’u tüketebiliyor.
Eskiden ilk çalışan sürüm birkaç akşam setup gerektiriyor gibi görünüyorsa deneyi erteliyordum. AI coding tools bu işi ortadan kaldırmadı, ancak first pass’in maliyetini düşürdü ve test edilebilir sürüme daha hızlı ulaşmamı sağladı.
Bu yüzden en büyük kazanç daha hızlı yazmak değildi. Daha düşük activation energy idi: daha fazla fikir gerçekten test edilip evidence üretebilecek noktaya geldi.
Node.js workflow’um nasıl değişti
Development process’i bir chat penceresiyle değiştirmedim. Node.js side projectlerinde DeepSeek’i dar kapsamlı işler için ikinci bir çift el gibi kullandım: ilk implementation taslağı, bilmediğim code’u okumak, test önermek, stack trace analiz etmek, büyük refactor’ları bölmek ve deployment varsayımlarını kontrol etmek.
- Scaffolding: handler, validation, script veya test’in sıkıcı ilk sürümünü hazırlamak.
- Code reading: edit’ten önce request veya value akışını izlemek.
- Refactoring: mekanik değişiklikleri küçük review edilebilir diff’lere bölmek.
- Debugging: loglardan birden fazla hypothesis üretmek.
- Verification: happy path çalıştıktan sonra edge case ve regression aramak.
Input, output, constraint ve mevcut convention ne kadar netse sonucu doğrulamak o kadar kolaydı. Vague task’ler daha sık mantıklı görünen ama yanlış abstraction üretiyordu.
Bu nedenle AI output’u final answer değil candidate patch olarak gördüm. Type checking, tests, build ve gerçek flow evidence idi; kendinden emin açıklama değildi.
DeepSeek en çok nerede yardımcı oldu — nerede olmadı
DeepSeek somut programming task’lerinde tekrar tekrar kullanmak için pratikti. First pass isteyebiliyor, bir kısmını reddedebiliyor, gerçek error’u geri verip scope’u daraltarak hızlı iterate edebiliyordum.
Bunu benchmark olarak sunmuyorum. Her rakip modelle controlled study yapmadım ve model lineup’ları hızla değişiyor. Savunabileceğim iddia daha dar: DeepSeek workflow’uma yeterince iyi uydu ve AI assistance’ı çok daha sık kullanmaya başladım.
Function, tests ve gerçek error olduğunda en güçlüydü. Yazılmamış product context veya ince architecture trade-off gerektiğinde daha zayıftı. Böyle durumlarda akıcı bir cevap kötü bir assumption’ı bitmiş çözüm gibi gösterebilir.
AI deney yapmanın maliyetini değiştirdi
En büyük değişim “AI kod yazıyor, o halde development otomatik” değildi. Birçok küçük parçayı denemenin maliyeti yeterince düştü. Önceden fazla setup gerektiriyor gibi görünen bir side-project feature’ı, fikir hâlâ ilgimi çekerken prototype’a dönüşebiliyordu.
Bu ayrım önemli. AI, test edilebilir bir sürüme ulaşmanın maliyetini düşürdü. Architecture, product judgment, deployment veya correctness ortadan kalkmadı. Generated implementation yanlış olabilir; başarılı build runtime’da bozulabilir; deploy edilmiş prototype hâlâ kötü bir ürün olabilir.
Benim için pratik fayda momentum’du. Tüm sistemin çalıştığını gördüğüm anda, onu geliştirmeye devam etmek çok daha kolay oluyordu.
Daha güçlü bir benchmark ne gerektirirdi
Reproducible benchmark için exact model versions, fixed programming tasks, repository snapshots, prompts, raw outputs, elapsed time, accepted/rejected patches, review time, test results ve rework kaydederdim.
Commit dışında idea’dan verified version’a geçen süre, defects, rollbacks ve yeniden yazılan iş de ölçülmeli. Bu context olmadan 4.000 commit activity ve davranış değişikliğini gösterir, software quality’yi kanıtlamaz.
Benim için ne değişti
2025, her side project’i elle tırmanmam gereken dev bir setup dağı gibi görmeyi bıraktığım yıl oldu. AI, ilk çalışan sürümün maliyetini yeterince düşürdü ve ürün kararlarının gerçekten önemli olduğu aşamaya daha sık ulaşmamı sağladı.
GitHub grafiğimin ikinci yarısının bu kadar farklı görünmesinin nedeni bu. AI bana gün içinde daha fazla saat vermedi ve üretilen her satır da iyi değildi. Daha önce fikirleri gerçek olmadan öldüren friction’ı azalttı.
2026’da odağım denklemin daha az gösterişli tarafında: workflow’u iyileştirmek, quality’yi daha ciddi ölçmek ve daha hızlı development’ın yalnızca daha fazla commit değil, daha iyi software üretmesini sağlamak.