Yazılımcılığın Sonu mu Geldi? Yapay zeka ile bir rönesans yaşanıyor.
Yazan Evren BalYayın tarihi Güncellendi · 5 dk okuma

Sayfayı kopyala
💡 Kısaca
- Yapay zeka, junior geliştiricinin öğrendiği tekrarları da sıkıcı tekrarlarla birlikte ortadan kaldırabilir. Tamamlanan görev, otomatik olarak edinilmiş beceri değildir.
- Risk, yapay zekanın insanları beceriksizleştirmesi değil. Şirketlerin sorgulama, açıklama, geri bildirim ve inceleme gerektiren öğrenme döngülerini kurmadan işi devretmesi.
- Gelecekte kıdemli mühendise ihtiyaç duyacak ekipler bu döngüleri bilinçli biçimde tasarlamalı. Yapay zeka, gerekçeyi açtığında, eleştirdiğinde ve test ettiğinde öğrenmeyi hızlandırabilir.
Yapay zekayla kodlama tartışmasında en yüksek sesle sorulan soru, yazılım üretmek için daha az insana ihtiyaç duyulup duyulmayacağı. Bence daha sessiz bir soru en az bunun kadar önemli: Geleceğin kıdemli mühendisleri nereden gelecek?
Yazılımın giriş seviyesi işleri uzun süre iki iş gördü. Projeyi ilerletti; daha az deneyimli geliştiriciye de gerçek sistemlerin nasıl çalıştığını tekrar tekrar gösterdi. Küçük bir özellik, bozulan bir test, anlaşılmayan bir üretim hatası veya kod incelemesindeki bir yorum yavaş ve yorucu olabilirdi. Ama neden-sonuç ilişkisini de orada öğrenirdiniz.
Yapay zeka bu denklemi değiştiriyor. Kıdemli bir geliştirici bu işlerin bir bölümünü artık daha hızlı tamamlayabiliyor. Junior geliştirici ise kendi varsayımını kurmadan makul görünen bir cevaba ulaşabiliyor. Bunun yararı var. Fakat cevabın hemen görünmediği anlarda sistemin davranışını öğrenme fırsatını da azaltabilir.
Buradaki öneri angaryayı korumak değil. Angaryanın sessizce ne öğrettiğini fark etmek.
Mühendislik kariyerinin eksilen orta kısmı
İyi kıdemli mühendislerin çoğu tek bir eğitimle veya büyük bir sıçramayla yetişmedi. Biriken küçük düzeltmelerle yetiştiler: Varsayımı bozan bir test, sınırın nedenini soran bir inceleme yorumu, hatayı sistemler boyunca izlemeye zorlayan bir olay, ilk çözümün neyi kaçırdığını gösteren bir tasarım konuşması.
Bu deneyimler zihinsel model kurar. Zamanla mühendis, bir işi yalnızca yazılacak satırlar olarak görmez. Sözleşmeleri, hata biçimlerini, veri akışını, kullanıcıyı ve yanlış kararın maliyetini görmeye başlar.
Giriş seviyesi işlerin önemli bölümü yapay zekanın hızlandırabileceği kadar tekrarlıdır. Aynı işler, hatanın yapılıp açıklanabildiği ve düzeltilebildiği kadar da sınırlı olabilir. Şirketler bu görevleri sadece kaldırırsa, junior işe alımını azaltabilir veya geriye prompt yazıp sonucu kabul etmeye dayanan bir iş bırakabilir. Bu iki sonuç da junior geliştiricinin zamanla sistemi tek başına taşıyabilecek bir mühendise dönüşeceğini garanti etmez.
Bu, her junior rolünün ortadan kalkacağına dair bir tahmin değil. İşe alım; şirkete, piyasaya ve işin türüne göre değişecek. Daha dar sorun şu: Bir ekip bugünkü teslimatı hızlandırırken kendi kıdemli mühendislik kapasitesini yenileyen yolu zayıflatabilir.

İlk araştırmalar ne söylüyor, ne söylemiyor?
Yapay zekanın yazılım öğrenmeye etkisine ilişkin kanıt henüz yeni. Anthropic'in 2026 tarihli rastgele kontrollü deneyinde, geliştiriciler bilmedikleri bir Python kütüphanesiyle çalıştı. Araştırmanın tamamı burada. Yapay zeka kullanan katılımcılar, az önce kullandıkları kavramlarla ilgili hemen yapılan testte kodu kendi yazanlara göre yüzde 17 daha düşük puan aldı. Çalışma küçük bir örneklemle yapıldı ve kısa süreli anlamayı ölçtü. Bu nedenle yıllar içindeki kariyer gelişimi veya her yapay zeka iş akışı hakkında hüküm vermiyor.
Araştırmanın daha kullanışlı bulgusu kullanım biçimiyle ilgili. Yapay zekaya takip soruları soran, açıklama isteyen veya kavramsal sorularla çalışan katılımcılar daha güçlü bir kavrayış gösterdi. Ekiplerin buradan çıkarabileceği ayrım açık: Yardım öğrenmeyi destekleyebilir. İş devri ise öğrenmenin gerçekten olup olmadığını gizleyebilir.
Yapay zeka sabırlı bir eğitmen olabilir. Bilinmeyen kodu açıklayabilir, karşı örnek üretebilir, test önerebilir, yaklaşımları karşılaştırabilir ve geliştiriciyi kararını anlatmaya zorlayabilir. Bu biçimde kullanıldığında junior bir geliştiriciye, yoğun bir ekibin başka türlü veremeyeceği kadar geri bildirim sağlayabilir. Sorun araçta değil. Anlamadan sorumluluğu araca bırakmakta.
Kolay işlerin azalması yalnızca bireyi etkilemiyor
Bu sorunun bireysel biçimini görmek kolay. Bir geliştirici çözümü kopyalar, hata o an kaybolur ve bir sonraki benzer durumda nedenini açıklayamaz. Kurumsal biçimi daha sonra ortaya çıkar.
Junior geliştiriciler hata ayıklama, tasarım ödünleri ve kod inceleme konuşmalarıyla daha az karşılaşırsa ekip, bugün kıdemli mühendislerin taşıdığı işleri üstlenmeye hazırlanacak daha az insan yetiştirir. Görünen kazanç, küçülen iş listesi olabilir. Görünmeyen bedel ise olay müdahalesi, mimari kararlar, kod incelemesi ve halefiyet için daha zayıf bir kadro olur.
Ben buna kapasite borcu diyorum. Bu, Önceki Vibe Coder Dönemi Başlıyor yazısındaki teknik borç meselesiyle aynı değil. Oradaki sorun, hızla üretilen sistemlerin bakım maliyetinin sonradan büyümesi. Yapay Zeka Kod Yazmayı Ucuzlattı, Doğrulamayı Değil yazısındaki inceleme kapasitesi sorunuyla da aynı değil. Orada kıdemli mühendislerin, üretmediği kodlar için kuyruğa dönüşmesi tartışılıyor. Buradaki soru daha erken başlıyor: Ekip, bu kararları bir gün kendi başına alıp savunabilecek mühendisler yetiştiriyor mu?
Bu borç ilk anda hiçbir tabloda görünmez. Ekip teslim hedeflerini tuttururken kırılgan bir alt sistemi açıklayabilen veya riskli bir değişikliği tartabilen tek kişiler kıdemli mühendisler olarak kalabilir. İşaret, biri ayrıldığında, alışılmadık bir hata çıktığında veya inceleme kapasitesine yetiştirilenden daha hızlı ihtiyaç duyulduğunda belirir.
Öğrenme döngülerini bilinçli olarak kurmak
Çözüm, her basit işi insanlara bırakmak değil. Hızlanan işin içinde öğrenme döngüsünün kaldığından emin olmak.
Junior geliştirici yapay zekayla bir uygulama taslağı çıkarabilir, sonra kod incelemesinden önce seçtiği yaklaşımı anlatabilir. Modele varsayımları ve hata durumlarını listeletebilir, testleri üretilen koddan değil gereksinimden türetebilir, sonucu kod tabanındaki mevcut bir örüntüyle karşılaştırabilir. İnceleyen kişi de değişikliği sessizce baştan yazmak yerine önemli bir kararı konuşabilir.
Ekipler bazı işleri öğrenene bilerek yakın tutabilir: Rehberlikle gerçek bir hatayı ayıklamak, küçük bir servisi uçtan uca sahiplenmek, olay sonrası incelemeye sırayla katılmak veya ajan büyük bir değişiklik üretmeden önce tasarım kararını birlikte tartışmak. Uygulama sistemden sisteme değişir. Ortak ihtiyaç, muhakemeye, geri bildirime ve sonuca temas etmektir.
Bunun anlık bir zaman maliyeti var. Yapay zekadan önce ustalık da zaman istiyordu. Şimdi bu yatırımı atlamak daha kolay, çünkü araç kabul edilebilir görünen cevabı hemen üretebiliyor.

Kod yazmak değişiyor. Ustalığın hâlâ bir yola ihtiyacı var.
Kodu elle yazmak, yazılım işinin bazı alanlarında daha küçük bir pay tutacak. Bu, mühendislik bilgisini gereksizleştirmiyor. Problemi doğru kurma, kötü varsayımı fark etme, cevabı sınama ve sistemin sorumluluğunu taşıma becerisini daha değerli kılıyor.
Bir ekibin sorması gereken soru, yapay zekanın junior işini alıp almadığı değil. Geriye kalan işin, junior geliştiriciyi beş yıl sonra ihtiyaç duyacakları mühendise dönüştürecek inandırıcı bir yol sunup sunmadığı.
Bu yazıyı faydalı bulduysanız
Web sitenizde ilgili bir içerikten bu yazıya bağlantı vermeniz ya da sosyal medyada paylaşmanız, daha fazla kişiye ulaşmasına gerçekten yardımcı olur. Desteğiniz için teşekkür ederim.
Bağlantı ve marka kullanım rehberi →