AI'ın Otomatikleştiremeyeceği 4 Developer Becerisi

METR'in 2025 başında yürüttüğü kontrollü deneyde 16 deneyimli açık kaynak geliştirici, kendi büyük projelerinden 246 gerçek görev üzerinde çalıştı. Geliştiriciler AI ile yüzde 24 hızlanmayı bekliyordu; iş bittikten sonra bile yüzde 20 hızlandıklarını düşündüler. Ölçülen sonuç ise görevlerin yaklaşık yüzde 19 daha uzun sürmesiydi. 2025 sonundaki tekrar deneyde ise bu kez hafif bir hızlanma işareti çıktı, ama METR sonucu güvenilir bulmadı: AI olmadan çalışmayı kabul etmeyen geliştiriciler ve AI'sız yapılmak istenmeyen görevler örneklemden düşüyordu.

Güven tarafı daha net. Stack Overflow 2025 anketinde yüzde 66 'neredeyse doğru' çözümlerden şikâyetçiydi ve yüzde 45 AI kodunu ayıklamanın kendi yazmaktan uzun sürdüğünü söylüyordu. 2026 anketinde ise güvenin koşula bağlandığı görülüyor: doğrulayabildiğinde güvenen yüzde 48, önemli kararlarda güvenen yüzde 6,6.

Bu veriler aynı şeyi söylüyor: üretim kapasitesi arttı, ama neyin üretileceğine karar vermek, çıkanı kontrol etmek ve sisteme yerleştirmek hâlâ insan işi. Aşağıdaki dört beceri tam da bu boşlukta duruyor; hepsi ölçülebilir, antrenmanı yapılabilir mühendislik becerileri.

Son 12 ayda tartışmanın ağırlık merkezi 'AI bizi hızlandırıyor mu' sorusundan 'neyi doğruluyoruz ve ne öğreniyoruz' sorusuna kaydı. Stack Overflow'un 6 Ekim 2026'da yayımladığı ankete 169 ülkeden 30 binden fazla yanıt geldi: yanıt verenlerin yüzde 66'sı coding assistant ya da coding Agent kullanıyor, yüzde 26'sı otomatik Agent iş akışları çalıştırıyor, günlük kullanıcıların yaklaşık üçte biri günde dört saat ve üstü AI ile çalışıyor. Buna karşın önemli iş kararlarında AI'a güvenen yalnızca yüzde 6,6; AI'dan uzak duranların en sık gerekçesi de yüzde 17,1 ile beceri kaybı endişesi.

METR Şubat 2026'da deney tasarımını değiştirdi, çünkü artık AI'sız çalışmayı kabul eden geliştirici bulmak zorlaştı. Anthropic'in Ocak 2026'da yayımladığı 52 kişilik deneyde AI ile yeni bir kütüphane öğrenen grup kavrama testinde yüzde 50, elle yazan grup yüzde 67 aldı; en büyük fark debugging sorularındaydı. DORA'nın Mart 2026 analizi de buna 'verification tax' diyor: kod yazarken kazanılan zamanın önemli kısmı inceleme ve denetime gidiyor.

Bir AI ajanına 'kullanıcı yorumlarına filtre ekle' dersen, sana çalışan bir filtre verir. Ama asıl soru çoğu zaman başka yerdedir: kullanıcı neden filtrelemek istiyor, spam mı görüyor, yoksa kendi deneyimine benzeyen yorumları mı arıyor? Çerçeveleme, talebin arkasındaki gerçek ihtiyacı, başarı ölçütünü ve kapsam dışını yazıya dökmektir.

Model, verilen çerçevenin içinde çok iyi çalışır; çerçeveyi sorgulamaz. Yanlış problemi hızla çözmek, eskiden iki hafta sürerdi, şimdi iki saat sürüyor. Kayıp aynı, sadece daha hızlı geliyor.

Somut bir eşik: kod yazmadan önce talebi en fazla beş cümlelik bir problem tanımına indirebiliyor musun? 'Kim, hangi durumda, neyi yapamıyor, bunu nasıl ölçeceğiz, neyi bilerek yapmıyoruz.' Bu beş soruya cevap veremiyorsan, ajana verdiğin prompt da bulanık olacak ve çıktı 'neredeyse doğru' kategorisine düşecek.

AI sana Postgres'te bir kuyruk tablosu, Redis Streams ya da SQS ile üç farklı çözüm yazabilir. Hangisinin senin ekibine, bütçene ve 18 ay sonraki trafiğine uygun olduğunu bilemez. Çünkü bu karar kodda yazmaz: ekibin kaç kişi olduğu, kimin gece nöbet tuttuğu, hangi teknolojide operasyon tecrübesi olduğu gibi bağlamlara dayanır.

Ödünleşim kararı, bir seçeneği seçerken neyden vazgeçtiğini açıkça söylemektir. Örneğin günde 10 bin işlik bir arka plan kuyruğu için ayrı bir broker kurmak, tek bir Postgres tablosu ve SKIP LOCKED ile çözülebilecek bir işi operasyonel yüke çevirir. Bu yargıyı veren kişi, AI'ın ürettiği şık ama gereksiz karmaşık mimariyi reddedebilen kişidir.

Anti-pattern: modelin önerdiği ilk mimariyi 'mantıklı görünüyor' diye kabul etmek. Mantıklı görünmek, senin kısıtlarına uygun olmak demek değildir.

Stack Overflow 2025 anketinde geliştiricilerin yüzde 45'i AI'ın yazdığı kodu ayıklamanın, kodu kendilerinin yazmasından daha uzun sürdüğünü söylüyor. Bu, doğrulama becerisinin değerini doğrudan gösteren bir sayı. Kod üretimi ucuzladıkça darboğaz, üretilen kodun gerçekten doğru olduğuna dair kanıt toplamaya kayıyor.

Doğrulama üç katmanda yapılır: kodu okuyup niyetle karşılaştırmak, sınır durumları için test yazmak ve çalışan sistemde gözlemlemek. Örneğin bir ödeme ekranında AI'ın yazdığı yuvarlama fonksiyonu tüm testleri geçebilir, ama 0,005 gibi bir değerde kuruş kaybedebilir. Bunu yakalayan, 'bu fonksiyon hangi girdide bozulur' diye soran insandır.

Hata ayıklamada da benzer: model bir stack trace'e bakıp makul bir açıklama uydurabilir. Hipotez kurup onu deneyle çürütmeye çalışmak, yani bilimsel yöntem, devredilemeyen kısımdır. Modelin açıklaması ikna edici olabilir; ikna edici olmak doğru olmak değildir.

Bir lojistik yazılımında 'teslim edildi' durumunun depo için, müşteri için ve faturalama için üç farklı anlamı olabilir. Bu ayrımı kodda değil, operasyon ekibiyle yapılan bir toplantıda öğrenirsin. Alan bilgisi, işin kurallarını ve istisnalarını bilen insanlarla konuşarak birikir; modelin eğitim verisinde senin şirketinin istisnaları yoktur.

İletişim burada iki yönlü çalışır. Birincisi, paydaşlardan doğru bilgiyi çekmek: belirsiz bir talebi soru sorarak netleştirmek. İkincisi, teknik bir kararı teknik olmayan birine anlatmak: 'Bu özelliği iki haftada çıkarabiliriz ama raporlama bir sprint gecikir' cümlesini kurabilmek.

Somut gösterge: ürün ekibiyle yaptığın bir toplantıdan sonra, kararları ve açık soruları beş madde hâlinde yazıp paylaşabiliyor musun? Bu yazı aynı zamanda AI ajanına verilecek en iyi bağlamdır, çünkü modelin tahmin etmek zorunda kaldığı boşlukları doldurur.

Çerçeveleme için: her yeni iş için kod yazmadan önce beş cümlelik problem tanımı yaz ve bir ekip arkadaşına okut. Bir ay sonra, hangi tanımların sonradan değiştiğine bak; en çok nerede yanıldığını göreceksin.

Tasarım için: haftada bir kısa bir mimari karar kaydı (ADR, Architecture Decision Record, yani bir kararın gerekçesini ve alternatiflerini anlatan kısa belge) yaz. AI'dan üç alternatif iste, ama seçimi ve gerekçeyi sen yaz.

Doğrulama için: AI'ın yazdığı her fonksiyon için önce bozacak bir girdi bulmaya çalış. Haftada bir kez bir hatayı AI'a sormadan, sadece log ve debugger ile çöz.

İletişim ve alan bilgisi için: ayda iki kez müşteri destek kaydı oku ya da bir operasyon çalışanıyla 30 dakika konuş. Öğrendiğin istisnaları bir sözlük dosyasına ekle; bu dosya hem yeni ekip üyeleri hem de ajanlar için bağlam olur.

Navigasyon uygulamasıyla yıllarca araç kullanan biri, bir gün telefonu kapandığında şehri tanımadığını fark eder. Aynı şey geliştirici becerileri için de geçerli. Her hatayı modele yapıştırıp çözümü kopyalayan biri, birkaç ay sonra bir stack trace'i okuma refleksini kaybedebilir.

Körelmenin erken işaretleri ölçülebilir: bir PR'daki kodu kendi cümlelerinle açıklayamamak, model önerisi olmadan bir tasarım seçeneği düşünememek, bir hatanın kök nedenini değil sadece semptomunu düzeltmek. Junior geliştiriciler için risk daha yüksek, çünkü bu kasları hiç kurmadan araçla başlıyorlar.

Çözüm aracı bırakmak değil, kasıtlı sürtünme eklemektir. Örneğin ekipte bir kural: AI ile yazılmış bir PR'ı açan kişi, açıklamaya 'bu kod neden doğru' sorusunun cevabını kendi cümleleriyle yazar. Bu kural hem kod incelemesini hızlandırır hem de yazarı kodu gerçekten anlamaya zorlar.