- GenAI(LLM), kodu otomatik üretme ve destekleme yetenekleriyle geliştiricilerin üretkenliğini artırıyor
- Geçmişte de “kodlama gerektirmeyen araçlar” vardı, ancak gerçek yazılım mühendisliği sürecinde kendine özgü karmaşıklıklar hâlâ varlığını sürdürüyor
- ChatGPT’nin çıkışından sonra yapay zeka araçlarının hızlı gelişim hızı dikkat çekiyor, ancak tüm süreci kökten değiştirmektense, verilen bir problemde bazı adımları büyük ölçüde kısaltan bir rol oynuyor
Geliştiricilerin gerçek kullanım biçimleri iki kola ayrılıyor
- Bootstrappers
- Bolt, v0, Screenshot-to-code gibi araçlarla yeni projeleri ya da MVP’leri hızla hayata geçiriyorlar
- Tasarımdan (Figma vb.) veya kaba bir konseptten başlayarak yapay zeka tam bir başlangıç kod tabanı üretiyor
- Günler yerine saatler içinde çalışan bir prototip oluşturuyorlar
- Üretim seviyesinde eksik olsa da, fikir doğrulamada güçlü tarafları var
- Hızlı doğrulama ve iterasyona önem veriyorlar
- Iterators
- Cursor, Cline, Copilot, WindSurf vb. araçları günlük geliştirme sürecinde kullanıyorlar
- Kod otomatik tamamlama, karmaşık refactoring, test ve dokümantasyon üretimi gibi işlerde yapay zekadan yararlanıyorlar
- Karmaşık test, dokümantasyon ve refactoring gibi işleri yapay zekaya bırakırken sonuçları sürekli kontrol ediyorlar
- Bir “pair programmer” gibi birlikte problem çözen bir yardımcı olarak kullanıyorlar
- Geliştirici, yapay zekanın önerilerini seçme, düzeltme ve tamamlama sürecini tekrarlayarak kodu en iyi hâline getiriyor
%70 problemi: “Son %30”un zorluğu - yapay zekanın öğrenme eğrisi paradoksu
- Yapay zeka kodun yaklaşık %70’ini hızla üretebiliyor, ancak son %30 ciddi şekilde işleri tıkıyor
- Küçük bir bug düzeltilince başka bir kısmın bozulduğu bir kısır döngü oluşabiliyor
- Özellikle alan dışından gelenler veya junior geliştiriciler, yapay zekanın önerdiği kodu tamamen kabul ederken zincirleme sorunlar üretmeye daha yatkın oluyor
- Yapay zekanın önerdiği değişikliklerin neden sorun çıkardığını anlamakta zorlanıyorlar
- Deneyimli senior geliştiriciler ise bug nedenlerini hızlıca çıkarım yaparak buluyor, kodu yeniden yapılandırıyor ve güvenlik ile performans gibi yapay zekanın kaçırdığı noktaları tamamlıyor
- Yapay zekayı aktif biçimde kullanırken sürekli review ve refactoring yaparak kodu “bakımı yapılabilir” hâle getiriyorlar
- Juniorların veya geliştirici olmayanların yapay zekanın ürettiği kodu düşünmeden kabul etmesi, gerçek üretim ortamında kolayca çöken bir “house-of-cards code” riski yaratabiliyor
- Bilgi paradoksu
- Seniorlar zaten bildikleri problemleri yapay zekayla birlikte hızlıca hayata geçirebiliyor
- Juniorlar yapay zekayla öğrenmek zorunda, ancak temel bilgi eksikse debugging ve doğrulama süreçlerinde büyük zorluk yaşıyorlar
Etkili kullanım kalıpları
- Yapay zeka taslağından sonra ayrıntılandırma
- Yapay zeka ilk implementasyonu yaptığında, insan bunu doğrudan gözden geçiriyor, refactor ediyor ve test ediyor
- Hata işleme ve istisna durumları manuel olarak ekleniyor; otomatik test ve review süreçleri güçlendirilerek güvenilirlik artırılıyor
- Modülerlik, hata işleme, tip tanımları ve mimari tasarım güçlendirilerek bakım yapılabilirlik sağlanıyor
- İş birimi bazında konuşmayı sürdürme
- Tek seferde büyük bağlam vermek yerine, her küçük problem için bağımsız prompt’lar kullanılarak daha odaklı yanıtlar alınıyor
- Değişiklikler sık sık review edilip commit ediliyor, geri bildirim kısa döngülerle yansıtılıyor
- “Güven ama doğrula” yaklaşımı
- Yapay zeka taslağı hazırlıyor, ancak kritik mantık, hata işleme ve güvenlik konularını insan doğrudan üstleniyor
- Her zaman test case’ler yazılıyor; performans, güvenlik ve yapısal doğruluk dikkatle denetleniyor
Geliştiriciler için çıkarımlar
- Küçük başlayın
- İyi tanımlanmış küçük işler ve kapsamı net problemlerle yapay zekayı kullanmayı deneyin, ardından üretilen kodu dikkatle inceleyin
- Daha büyük özelliklere geçmeden önce test ve dokümantasyonu titizlikle ele alın. Sonra kapsamı aşamalı olarak genişletin
- Modüler yapıyı koruyun
- Kod tabanını uygun şekilde ayırarak, yapay zekanın ürettiği kodun yapısal olarak birbirine karışmasını önleyin
- Dosyaları ve işlevleri küçük birimlere bölün; arayüzleri ve bağımlılık akışını net biçimde tanımlayın
- Deneyime güvenin
- Yapay zekayı yardımcı olarak kullanın, ancak son kararı kendi deneyiminize göre verin
- Şüpheli kod ve tasarımlara temkinli yaklaşmak, mühendislik standartlarını korumak daha iyidir
Agentic yazılım mühendisliğinin yükselişi
- Daha önce yapay zeka araçları komutlara yanıt verip kod üretme seviyesindeydi; bundan sonra ise Agentic kavramına doğru evriliyor
- Agentic yapay zeka hedefleri kendi başına planlayıp uygular, doğrular ve daha otonom çalışır
- Claude(Anthropic), Cline vb. artık basit otomatik tamamlama seviyesinin ötesine geçerek tarayıcıyı otomatik açıp test çalıştırabiliyor
- Debugging süreci de değişiyor
- Bir ajan potansiyel sorunları kendi başına bulabilir, test setlerini çalıştırabilir, hatta UI durumunu kontrol ederek düzeltme önerileri sunabilir
- Geleceğin araçları yalnızca kodla ilgilenmeyecek
- UI ekran görüntüleri, diyagramlar, sesli konuşmalar gibi birden çok giriş kanalını anlayıp birleştirebilecekler
- Bu akış içinde geliştiricinin yapması gerekenler
- Yapay zekanın yaratıcı biçimde çalışmasına izin verirken, insan rehberliği almasını ve sağlıklı bir mimari içinde işlemesini sürdürmek
- İnsan ile yapay zeka arasında güçlü bir geri bildirim döngüsü kurmak
- İnsanın genel çerçeveyi ve hedefleri belirlediği, ajanın ise ayrıntılı işleri üstlendiği bir işbirliği modeli ortaya çıkması bekleniyor
- “En önemli programlama dili İngilizcedir” sözünde olduğu gibi, gereksinimleri açık ve doğru doğal dille ifade etme becerisi daha önemli hâle geliyor
Yazılım zanaatkârlığı geri dönebilir mi?
- Yapay zeka sayesinde prototipler ve demolar hızlıca üretilebiliyor
- Ancak gerçek kullanıcılar yazılımı farklı ortamlar ve edge case’lerle kullanmaya başladığında sorunlar ortaya çıkıyor
- Kullanıcının anlayamadığı hata mesajları
- Çakışma yaratan özel ortamlar (edge case’ler)
- Accessibility’nin hiç düşünülmediği tasarımlar
- Yavaş cihazlarda görülen performans sorunları
- UI/UX gibi ayrıntılar kaliteyi belirliyor
- Tüketici açısından gerçekten iyi cilalanmış bir ürün olmak için ayrıntılara özen ve insani dokunuş gerekiyor
- Yapay zeka tekrarlayan işleri azaltırsa, geliştiriciler bu tür ince tamamlanmışlığa daha çok odaklanabilir
- Kullanıcı deneyimi, edge case’ler, anlamlı hata işleme gibi hem insani hem de profesyonel alanlara daha fazla zaman ayırabilirler
Ek düşünceler
- Yazılım mühendisliği süreci planlama, tasarım, implementasyon, doğrulama, izleme ve bakım gibi birçok alanı kapsıyor; bugün yapay zeka özellikle “kod yazma” bölümünde büyük verimlilik sağlıyor
- Geçmişte de COBOL, Visual Basic, no-code platformları vb. ile “geliştirici olmayanların da kolayca yazılım üretebilmesi” yönünde girişimler oldu, ancak karmaşıklık arttığında yine deneyimli geliştiricilere ihtiyaç duyuldu
- LLM araçları üretilen kod miktarını patlama düzeyinde artırdıkça, karmaşık projelerde daha fazla senior mühendise ihtiyaç duyulacağı öngörülüyor
- Yapay zeka kullanma becerisine sahip deneyimli geliştiriciler kendi değerlerini daha da artırabilir
- Sonuç olarak yapay zeka araçlarının geliştiricileri tamamen değiştirmektense, içgörü ve deneyim sahibi geliştiricileri daha da güçlendirecek şekilde evrilmesi bekleniyor
Ek düşünceler (Gergely’nin yorumları dahil)
- Yazılım mühendisliğinde kodlamanın kendisinin payı geçmişten beri aslında o kadar büyük değildi
- Geçmişte Fred Brooks, yazılım çalışmalarında zamanı kabaca şöyle sınıflandırmıştı
- ⅓ planlama
- ⅙ kodlama
- ¼ bileşen ve sistem testi
- ¼ sistem testi (tüm bileşenler elde)
olarak
- Günümüz bakışında kodlamaya ayrılan süre (test dahil) artsa da, planlama, code review, monitoring ve rollout hâlâ önemli paya sahip
- %20 planlama
- %40 kodlama (kod + test)
- %20 code review (başkalarının kodu)
- %20 production hazırlığı + rollout + bu süreçte küçük düzeltmeler + monitoring + alerting
- İyi yazılım üretme süreci
- 1. What: Ne yapılacağına karar verme
- Brainstorming, tasarım, kullanıcı testi, ürün yöneticileri ve iş paydaşlarıyla işbirliği gibi unsurları içerir
- Startup’larda bu aşama çok kısa olabilir (“yapalım, tepkisine bakalım” yaklaşımı gibi)
- Oturmuş şirketlerde ise mevcut müşterileri şaşırtmamak için ne yapılacağına karar vermek daha uzun sürebilir
- 2. How: Nasıl yapılacağını planlama
- Ürün, özellik ya da servisin nasıl uygulanacağını somut biçimde tasarlama
- Mimari etkiler, bağımlılıklar ve test stratejileri üzerine düşünme
- Startup’lar bu süreci atlayıp doğrudan uygulamaya geçebilir, ancak büyük organizasyonlarda ön tasarımın ihmal edilmesi ileride daha büyük sorunlara yol açabilir
- Çoğu ekip bir ölçüde planlama için Design doc, RFC, ADR vb. kullanır
- 3. Build: Gerçek implementasyon
- İstenen özellik ya da ürünü kodla yazıp düzgün çalıştığını doğrulama
- 4. Verify: Doğrulama
- Production’a almadan önce beklenildiği gibi çalıştığını dikkatle doğrulama
- Özellikle finansal servisler gibi yanlış çalışmanın kritik sonuçlar doğurabileceği alanlarda QA süreci çok sıkıdır
- 5. Ship it: Dağıtım
- Değişiklikleri merge edip müşterilere release etme
- Production’a dağıtım yöntemleri oldukça çeşitlidir
- 6. Monitoring and oncall: İzleme ve nöbet
- Üründe sorun olduğunda bunu hemen fark edip çözme
- Aynı arızanın tekrar etmemesi için sonrasındaki önlemleri de alma
- 7. Maintain: Bakım
- Kullanıcı şikâyet ve geri bildirimlerini toplayıp hangi bug’ların düzeltileceğine ve hangi özellik iyileştirmelerinin önceliklendirileceğine karar verme
- Görmezden gelinebilecek geri bildirimleri ayıklama süreci de buna dahildir
- 8. Migrate: Migrasyon
- Ürünün kendisi büyük ölçüde değiştiğinde veya teknoloji yığını değiştiğinde geniş çaplı bir migrasyon gerekebilir
- Yapay zeka araçları şu anda özellikle “Build” aşamasında büyük katkı sağlıyor, ancak yukarıdaki diğer 7 başlıkta ne kadar yararlı olacağı da ayrıca düşünülmeli
- 1960’lardan bu yana “geliştirici olmayanların geliştirici olmadan yazılım üretebilmesi” hayali sürüyor
- COBOL, Visual Basic, no-code bunun örnekleri
- Basit web siteleri neredeyse hiç kod yazmadan yapılabilir, ancak karmaşık ürünlerde mühendislik çalışması hâlâ gerekiyor
- İfade gücü arttıkça, “nasıl çalışması gerektiğini” yapay zekaya daha ayrıntılı tarif etmek gerektiğinden karmaşıklık da artıyor
- Yapay zeka daha çok kod ürettikçe, bunu bakım altında tutacak ve mimariyi yönetecek uzman mühendis ihtiyacının artması daha olası görünüyor
- Günümüzde LLM ile çalışmayı öğrenmiş senior geliştiriciler daha üretken oluyor ve şirketler için daha yüksek değer yaratabiliyor
AI ajanları: Büyük bir vaat, ama 2025 için hâlâ 'bilinmeyen bölge'
- LLM’lerin çıkışından iki yıl sonra, pek çok geliştirici LLM’leri kodlama ve yazılım mühendisliğinde nasıl kullanacağını öğrenmiş durumda
- Prototip üretimi, bilinmeyen dillere geçiş, çıktı doğruluğunu kontrol etme ve yanlış yanıtları (halüsinasyonları) yakalama gibi işlerde LLM’ler büyük katkı sağlıyor
- Ancak AI ajanları hâlâ erken aşamada
- Şu anda genel kullanıma sunulmuş ajan olarak öne çıkan örnek Devin; aylık 500 dolar gibi yüksek bir maliyete sahip ve değerlendirmeleri karışık
- Venture sermayesinin akmasıyla birlikte daha fazla AI coding agent aracı ortaya çıkacak gibi görünüyor
- Fiyatların zamanla düşmesi de muhtemel
- GitHub Copilot’un 2025’te ajan tabanlı Copilot Workspace’i genel kullanıma sunması bekleniyor
- Stripe’ın eski CTO’sunun kurduğu /dev/agents gibi girişimlerin de çıkış yapması bekleniyor
- AI ajanları, daha yavaş yanıt verme (“düşünme” süreci) ve daha yüksek maliyet karşılığında doğruluğu artırmayı hedefliyor
- Gerçekte bu yaklaşımın doğruluğu ne kadar artıracağı ve hangi mühendislik senaryolarında büyük üretkenlik kazancı sağlayacağı henüz belirsiz
Deneyimli yazılım mühendislerine talep artabilir
- Deneyimli (senior ve üzeri) yazılım mühendislerine bugün olduğundan daha fazla ihtiyaç duyulabilir
- Bu kişiler AI araçlarını daha etkili kullanabilir, “mükemmel sonucun” nasıl görünmesi gerektiğini bilir ve doğru biçimde “komut” verebilir
- Hatalı kod üretimi tespit edildiğinde üretim sürecini durdurup kaynak kodu doğrudan düzeltme noktasını ayırt edebilirler
- AI araçlarının yardımıyla çok daha fazla kod yazılacak ve daha fazla birey ile şirket kendi çözümlerini geliştirecek gibi görünüyor
- Ancak karmaşıklık büyüdükçe, bunu kontrol altında tutabilecek deneyimli mühendislere ihtiyaç da artacak
- Mevcut teknoloji şirketlerinin de AI nedeniyle büyüyen karmaşıklığı yönetecek insan kaynağına ihtiyaç duyması muhtemel
- Yazılım mühendisleri AI ile birlikte çalışma becerisini geliştirirse daha üretken ve daha değerli mühendisler olabilir
- Araçları gerçekten ustalıkla kullanmayı öğrenmek zaman aldığından, hızla değişen araç ortamında aktif biçimde denemek ve öğrenmek önemlidir
11 yorum
Gerçekten çok güzel bir yazı.
Son paragraf olan "Nitelikli yazılım mühendislerine olan talebin artma olasılığı" kısmına çok katılıyorum. Sanırım mesele, ne kadar biliyorsan o kadar iyi yazıyorsun, değil mi? ^^
Expo 52 gibi, yakın zamanda büyük değişimlerin yaşandığı alanlarda akıllı Claude da pek yardımcı olmadı.
Sürekli eskiyip ortadan kalkmış kodlar önerdiği için, aksine sadece köstek olduğunu deneyimledim.
Sonuçta yapay zekayı doğru kullanmak için, insanın gerçekten "ayırt edecek gözü"nün eğitilmiş olması gerekiyor gibi görünüyor.
Küçük bir nokta ama bildiğim kadarıyla /dev/agents bir kodlama ajanı değil. Henüz piyasaya sürülmedi, ancak kendisini "AI ajanları için bir işletim sistemi" olarak tanımlıyor.
Ben şahsen gelecekte (ya da bakış açısına göre orta vadede) tüm mühendislerin rolünde kodlayıcı tarafının küçülüp TPM rolünün büyüyeceğini düşünüyor ve buna yatırım yapıyorum.
Kodu Cursor daha iyi yazdığı için bunu ona devrederiz; insanlar da çoğu işi onun üstündeki daha soyut katmanda yapar diye düşünüyorum.
Paylaşım için teşekkürler. Ben de yakın zamanda ilgili bir yazı yazmıştım, biraz benzer yönleri var gibi. https://www.stdy.blog/can-junior-beat-coding-agent/
Özet: Yapay zeka nedeniyle geliştiricilerin geleceği (iyimser senaryo)
?? : artık geliştiriciye gerek yok (merdiven altı şirketler versiyonu)
Hayatımda böyle bir şey görmedim hahahaha
1+ hahaha
haha 100 puan