Birebir mentorluk görüşmelerinde son üç yılın değişmeyen sorusu şu: "Bu işe girmek için geç mi kaldım?" Soran bazen ikinci sınıf öğrencisi, bazen kariyer değiştirmeye çalışan bir makine mühendisi, bazen de on yıllık deneyimiyle kendini yeniden konumlandırmaya çalışan bir geliştirici. Aynı sorunun bir de işveren versiyonu masama geliyor: "Yapay zekâ bu kadar kod yazabiliyorsa, yazılım ekibini küçültebilir miyiz artık?"

İkisine de aynı cevabı veriyorum: yapay zekâ yazılımcının yerini almıyor, işin bileşimini değiştiriyor. Kod yazmanın işteki payı küçülürken problemi doğru tanımlama, üretilen çözümü doğrulama ve sistemi bütün olarak görme becerilerinin payı büyüyor. Kasım 2022'den bu yana kaybolan şey meslek değil; mesleğin eski tarifi.

Üç buçuk yılda neyin gerçekten değiştiği

Değişimin hızını tarihlerle koymak yerinde olur. Kasım 2022'de ChatGPT çıktığında yapay zekâ, yazılımcı için akıllıca bir arama motoruydu. 2023-2024'te editörün içine girdi ve satır tamamlamaktan fonksiyon yazmaya terfi etti. 2025'ten bu yana ajan tabanlı araçlar bir görev tarifinden yola çıkıp dosyaları değiştiriyor, testleri koşturuyor ve değişiklik önerisini önünüze getiriyor. Üç buçuk yılda "kod yazan araç"tan "iş yapan araç"a geldik.

Bunun ekonomik anlamı net: bir kod satırı üretmenin maliyeti hızla sıfıra yaklaşıyor. Ama dikkat — hatalı kodu üretime göndermenin maliyeti bir kuruş bile düşmedi. Yanlış hesaplanan bir fatura, sızdırılan bir kişisel veri, gece üçte çökerten bir sınır durumu bugün de dün kadar pahalı. Üretim ucuzlayıp hata sabit kalınca, değerin yeri de kaydı: iş artık yazmakta değil, ne yazılacağına karar vermekte ve yazılanın doğru olduğunu göstermekte.

Bir o kadar önemlisi, değişmeyenlerin listesi: üretim ortamının gerçekleri aynı kaldı. Sistemler hâlâ birbirine beklenmedik yerlerden bağlı, veriler hâlâ kirli, gereksinimler hâlâ konuşma sırasında değişiyor ve "demoda çalıştı" ile "altı aydır sorunsuz çalışıyor" arasındaki uçurum hâlâ yerinde. Araçların en parlak gösterileri boş sayfada; kurumsal yazılımın asıl işi ise hiç boş sayfada başlamaz.

Bu yüzden "yapay zekâ kod yazıyor, yazılımcıya gerek kalmadı" cümlesi, "traktör tarlayı sürüyor, çiftçiye gerek kalmadı" cümlesiyle aynı hatayı yapıyor. Aracın devraldığı şey mesleğin en görünür kısmı; en zor kısmı değil.

İşverenin sorusu: personelin yerini mi alıyor?

Soruyu görev düzeyine indirince cevap netleşiyor. Bugün güvenle otomatikleşen işler belli:

  • Tekrarlı kalıp kod: form, CRUD ekranı, veri dönüşümü, entegrasyon iskeleti
  • Test taslakları ve dokümantasyonun ilk sürümü
  • Bir dilden veya çatıdan diğerine mekanik çeviri
  • Hata mesajından şüpheli satıra giden ilk teşhis turu

Otomatikleşmeyenler de belli: müşterinin gerçekte neye ihtiyacı olduğunu çıkarmak, sistemin sınırlarını ve başarısızlık senaryolarını tasarlamak, üretilen çözümün işin kurallarına uyduğunu doğrulamak ve canlıdaki sistemin sorumluluğunu taşımak. Bu liste, bir yazılımcının haftasının küçümsenmeyecek bir bölümüdür — ve işin para kazandıran kısmı tam olarak burasıdır.

Yakın zamanda DijitalAI'de bir müşterimizin belge ağırlıklı bir arka ofis sürecini otomatikleştirdik. İşletme sahibinin ilk sorusu tam da bu yazının sorusuydu: "İki kişiyi çıkarabilir miyim artık?" Çıkarmadı — aynı iki kişi, otomasyonun çıktısını denetleyip istisnaları yönetmeye ve asıl ihmal edilen işe, müşteriyle ilgilenmeye geçti. Birkaç ay sonra telefonda söylediği cümleyi not etmiştim: "İş kaçırmıyoruz artık."

Pratikte gördüğüm örüntü ikame değil, kapasite artışı: aynı ekip daha çok iş bitiriyor. Bunun sebebi duygusal değil yapısal — kurumlarda yazılım talebi her zaman arzın önündeydi. Backlog'u hiç biten bir şirket görmedim. Araçlar arzı artırınca boşalan kapasiteyi bekleyen iş çoktan hazır. Ekibi küçültmeden önce sorulacak doğru soru "kaç kişi eksiltebiliriz" değil, "hangi görevlerin bileşimi değişti ve boşalan kapasiteyi hangi işe yönlendireceğiz" sorusudur; kurumsal tarafta yapay zekâ danışmanlığı çalışmalarının önemli bir bölümü tam olarak bu görev analizidir.

İşe alım tarafında da ölçüt güncellenmeli: "dakikada kaç satır" hiç iyi bir ölçüt değildi, artık anlamsız da. Mülakatta adaya araç kullandırıp üretilen koddaki hatayı buldurmak, beş yıl önceki algoritma sorusundan çok daha ayırt edici. Aradığınız kişi kodu en hızlı yazan değil, yanlış kodu en erken yakalayandır.

Asıl risk de burada saklı: tasarruf hevesiyle doğrulama kapasitesini kesmek. Üretilen kod çoğaldıkça onu okuyup sorgulayacak insan azalırsa, teknik borç görünmez biçimde birikir — faturası da genellikle en yoğun güne denk gelir.

Yazılımın dışında: hangi roller nasıl kayıyor

"Personelin yerini mi alıyor" sorusu yalnızca yazılım ekibi için sorulmuyor; aynı görüşmelerde müşteri hizmetleri, raporlama ve arka ofis de masada. Örüntü her yerde aynı: otomatikleşen şey rol değil, rolün içindeki görev demeti.

Müşteri hizmetlerinde sık sorulan soruların ilk cevabını artık bir asistan veriyor; ama kızgın müşteriyi sakinleştiren, istisnai durumda inisiyatif alan ve asistanın verdiği yanlış cevabın faturasını görmeden yakalayan kişi hâlâ insan. Raporlama tarafında "geçen ayın satış özetini çıkar" işi dakikalara indi; hangi metriğin neden saptığını yorumlayıp karara bağlayan analist ise daha değerli hâle geldi. Veri girişi ve belge işleme gibi tamamı tarif edilebilir işlerde ise daralma gerçek — bu dürüstçe söylenmeli. Oradaki doğru hamle, o rollerdeki insanları sistemin çıktısını denetleyen ve istisnaları yöneten katmana taşımak; çünkü otomasyon yaygınlaştıkça en kıt kaynak, çıktıya "bu yanlış" diyebilen çalışan oluyor.

Yönetici için pratik sonuç şu: dönüşümü meslek listesi üzerinden değil görev envanteri üzerinden planlayın. "Hangi pozisyonlar gidecek" sorusu hem yanlış hem de ekibe korku pompalayan bir soru; "hangi görevler otomatikleşecek ve denetim katmanını kim kuracak" sorusu ise bütçe, eğitim ve işe alım planına doğrudan çevrilebiliyor.

Junior paradoksu: mesleğin giriş katı daralıyor mu?

Dönüşümün bence en az konuşulan ve en kritik yüzü bu. Yapay zekânın en iyi yaptığı işler — kalıp kod, basit hata ayıklama, küçük düzeltmeler — tam olarak junior geliştiricinin yetiştiği işlerdi. Şirketler "bu işleri artık araç yapıyor" diye giriş seviyesi alımı keserse kısa vadede bütçe kazanır, üç yıl sonra mid-level bulamaz. 2029'un tecrübeli mühendisi, 2026'da işe alınmayan junior'dır.

Mentorluk yaptığım geliştiricilerde iki ayrı eğri görüyorum. Araca işi tamamen devredenler ilk haftalarda uçuyor, üçüncü ayda duvara çarpıyor: üretilen kodu savunamıyor, mülakatta beyaz tahta önünde sessiz kalıyor, canlıda ilk ciddi hatada kayboluyorlar. Aracı hızlı ama güvenilmez bir stajyer gibi yönetenler — her çıktıyı okuyup, sorgulayıp, kendi kararını vererek ilerleyenler — ise eski kuşağın beş yılda kat ettiği yolu belirgin biçimde kısaltıyor. Aradaki fark araç değil, çalışma disiplini.

Mentorluk verdiğim bir mentee bunu bana net biçimde gösterdi: iki ayda, araç desteğiyle etkileyici bir uygulama çıkarmıştı — ama ilk teknik mülakatında kendi kodundaki bir fonksiyonun neden öyle yazıldığını açıklayamadı. Programı değiştirdik; her hafta tek kural, teslim ettiği kodun her satırını sesli savunması. Yaklaşık üç ay sonra aynı soruya beyaz tahtada cevap verebiliyordu.

Bugün yola çıkan birine tavsiyem üç maddede toplanıyor: her gün en az bir kez aracın ürettiği kodu satır satır okuyup "burada neden bu tercih edilmiş" sorusunu cevaplamak; küçük de olsa bir projeyi üretime taşıyıp orada yaşatmak — dağıtım, izleme ve gece gelen hata dahil; ve bir alanı (ödeme sistemleri, rezervasyon, lojistik, ne olursa) gerçekten öğrenmek. Bu üçü, araçların veremediği şeyin tam listesi.

Vazgeçilmeyen dört beceri

Sistem düşüncesi. Araçlar dosya ölçeğinde güçlü, sistem ölçeğinde zayıf. Parçaların birbirini nasıl etkilediğini, bir değişikliğin üç servis ötede neyi kıracağını görmek hâlâ insan işi — ve giderek daha değerli, çünkü parça üretimi ucuzladıkça bütünün tutarlılığı darboğaz hâline geliyor.

Doğrulama disiplini. Okumadan onaylamamak, test etmeden güvenmemek, "çalışıyor görünüyor" ile "doğru" arasındaki farkı bilmek. Yapay zekâ çağının kod incelemesi, insan yazısına yapılandan daha sıkı olmak zorunda; çünkü üretilen kod kendinden emin görünür, özür dilemez.

Alan bilgisi. Havacılıkta rezervasyon kuralları, telekomda faturalama mantığı, e-ticarette stok davranışı… Model bunların genel hâlini bilir, sizin kurumunuzdaki istisnaları bilmez. İstisnaları bilen geliştirici, aracın çıktısındaki makul görünen yanlışı yakalayan tek kişidir.

Yazılı iletişim. Araca iş tarif etmek de ekibe karar anlatmak da aynı kasla yapılıyor: belirsizliği azaltan net yazı. "İstediğimi yapmıyor" şikâyetlerinin çoğu, aslında ne istediğini yazılı olarak netleştirememenin faturasıdır.

Pratik yol haritası

Yazılımcıysanız: araçları günlük akışınıza alın ama teslim ettiğiniz her satırı savunabilecek kadar anlayın; bir alanda (sektör veya problem sınıfı) bilinçli olarak derinleşin; portfolyonuzu "ürettiğim kod" değil "doğruladığım ve canlıda yaşattığım sistem" hikâyeleri üzerine kurun. İşe girişte fark yaratan artık hız değil, güvenilirlik. Somut bir başlangıç: önümüzdeki 90 günde bir yan projeyi araç desteğiyle ama her satırını savunabilir hâlde üretime taşıyın ve bu süreci yazıya dökün — bu tek egzersiz, çoğu eğitim müfredatından daha öğreticidir.

İşverenseniz: işten çıkarma refleksinden önce görev bileşimi analizi yapın — hangi işler otomatikleşiyor, boşalan kapasite nereye akacak; bu çerçeveyi kurmak için şirkette yapay zekâya nereden başlanacağını anlatan karar rehberi iyi bir başlangıçtır. Ekibe araçları verirken kullanım çerçevesini de verin; tekrarlı işlerin otomasyonunun pratikte neye benzediğini görmek için uçtan uca bir iş akışı otomasyonu örneğine bakın. Ve junior alımını kesmeyin — giriş katını kapatan şirket, üç yıl sonra orta katı dışarıdan pahalıya satın alır.

Sık sorulan sorular

Yapay zekâ yazılımcıların işini elinden alacak mı?

Mesleği değil, mesleğin eski tarifini ortadan kaldırıyor. Kod üretimi ucuzlarken problemi tanımlama, çözümü doğrulama ve sistem sorumluluğu taşıma işleri insanda kalıyor ve değerleniyor. Kaybolan rol, yalnızca tarif edilen kodu yazan geliştirici rolü; büyüyen rol, üretimi yöneten ve doğrulayan mühendislik rolü.

Şirket olarak yazılım ekibimizi küçültmeli miyiz?

Önce görev bileşimi analizi yapın: hangi görevler otomatikleşiyor, boşalan kapasite hangi bekleyen işe akacak. Kurumlarda yazılım talebi neredeyse her zaman arzın önündedir; kapasite artışı çoğu şirkette küçülme değil, backlog'un erimesi anlamına gelir. Doğrulama kapasitesini kesmek ise en pahalı tasarruftur.

Hâlâ junior yazılımcı işe almalı mıyız?

Evet — ama junior'ın işi değişti. Kalıp kodu araç yazacak; junior'dan beklenen, üretilen kodu okuyup sorgulamayı erken yaşta öğrenmesi. Giriş seviyesi alımı kesen şirket üç yıl sonra mid-level bulamaz; 2029'un tecrübeli mühendisi 2026'da işe alınan junior'dır. Alımı kesmek yerine yetiştirme programını araç çağına uyarlayın.

Yazılım öğrenmeye başlamaya değer mi hâlâ?

Değer — hedefi doğru koymak şartıyla. "Syntax bilen kişi" olarak farklılaşamazsınız; o bilgi araçlarda. Sistemleri anlayan, çıktıyı doğrulayabilen ve bir alanın gerçek problemlerini bilen kişi olarak girerseniz, araçlar sizi yavaşlatan değil beş yıllık yolu kısaltan bir kaldıraç olur. Öğrenme hedefi kod yazmak değil, yazılanı yargılayabilmektir.

Hangi işler önce otomatikleşiyor?

Girdi ve çıktısı net tarif edilebilen işler: kalıp kod, form ve CRUD ekranları, test taslakları, dokümantasyonun ilk sürümü, diller arası mekanik çeviri, hata teşhisinin ilk turu. Belirsizliğin yüksek olduğu işler — gereksinim çıkarma, mimari sınırlar, üretim sorumluluğu, kurum içi istisnalar — insan tarafında kalıyor.

Ekibimizi bu dönüşüme nasıl hazırlarız?

Üç adım: araçları resmî olarak ekibe verin ve kullanım çerçevesini yazılı kurun; kod incelemesini gevşetmek yerine sıkılaştırın, çünkü üretilen hacim büyüyor; öğrenme hedeflerini "daha çok satır" değil "daha iyi doğrulama" üzerine koyun. Dönüşümü bireysel merak yerine ekip standardı hâline getiren şirketler farkı altı ayda görüyor.

Araç kullanımını serbest mi bırakmalıyız, kural mı koymalıyız?

İkisi de değil: resmî kanal açın ve çerçeve koyun. Tam serbestlik kurumsal veriyi kişisel hesaplara taşır; tam yasak ise kullanımı görünmez kılar, ortadan kaldırmaz. İşleyen model, kurumsal hesaplarla tanımlı araç seti artı yazılı kullanım sınırları — hangi veri girebilir, çıktı hangi kontrolden geçer.

Sonuç: meslek bitmiyor, tarifi değişiyor

Yazılımcılık, daktilonun gitmesiyle biten yazarlık kadar bitiyor — yani bitmiyor; aracı değişiyor. Üç buçuk yılda kod üretimi metalaştı, doğrulama ve sistem düşüncesi değerlendi. Bu denklemde geliştiricinin görevi vazgeçilmez olan tarafta durmak, işverenin görevi de kapasiteyi kesmek yerine yeniden yönlendirmek.

Yapay zekâ destekli geliştirmede hızla mühendislik disiplinini birlikte kurmayı pratikte öğrenmek isterseniz, vibe coding eğitimi tam olarak bu dengeyi çalışıyor: aracın ürettiğini okuyabilen, sorgulayabilen ve canlıya güvenle taşıyabilen bir ekip refleksi.

Bu yazıyı, havacılık ve telekomünikasyon sektörlerinde yazılım ekipleri kurup büyütürken ve DijitalAI bünyesinde yürüttüğüm birebir mentorluk görüşmelerinde edindiğim gözlemlerle yazdım. Hakkımda daha fazlası: Ufuk Aytaş kimdir.