Yapay Zeka Mühendislerin Yerini Almayacak, Ama 'Kıdemli' Olmanın Anlamını Değiştiriyor

Birkaç ay önce, mühendislerimizden biri bir asistanın yaklaşık on iki saniyede doğru, deyimsel ve iyi test edilmiş bir fonksiyon implementasyonu ürettiğini izledi. Aynı fonksiyon onun bir saatini alırdı. Tepkisi rahatlama değildi. Sessiz ve çok belirgin bir endişeydi: eğer model bunu yapabiliyorsa, ben tam olarak ne için para alıyorum?

Bu soru gerçek bir cevabı hak ediyor, içi rahatlatan bir slogan değil. Dürüst versiyonu şu: işin bir özgeçmişte tarif etmesi en kolay olan kısmı — “Go ve TypeScript’te temiz kod yazar” — en hızlı sıradanlaşan kısım. Bu, ayağınızın altındaki zeminin kayması gibi hissettiriyor. Oysa daha çok tavanın yükselmesine benziyor. Geriye kalan iş, zaten her zaman asıl işin kendisi olan iş; biz onu sadece klavyeye basmanın içine gizlemeye alışmıştık.

Kaygıyı adlandırın, sonra ona doğrudan bakın

Korku mantıksız değil, o yüzden öyleymiş gibi yapmayalım. Son yirmi yılın büyük kısmında üstü kapalı anlaşma şuydu: sözdizimini öğren, standart kütüphaneyi ezberle, bir ticket’ı çalışan koda çevirmekte hızlan, işte bir kariyerin var. Günlük mühendisliğin büyük bir bölümü hatırlama ve kopyalama idi — bir tarih biçimlendirme hatasının formülünü anımsamak, bir API istemcisini bağlamak, kariyerinin kırk yedinci CRUD endpoint’ini yazmak.

Asistanlar tam olarak bu işte son derece iyi. Boilerplate, sözdizimi hatırlama, ilk taslaklar, yapıştırıcı (glue) kod, “Y kütüphanesinde X’i nasıl yaparım” aramaları — bugün iyi otomatikleştirilen işin özü tam olarak bu ve yalnızca daha da iyileşecek. Eğer mesleki değer hissiniz bu tuş vuruşlarını üretmeye demir atmışsa, kaygınız doğru kalibre edilmiş demektir. Hata, tuşa basmanın hiçbir zaman değerin kendisi olduğunu sanmaktır. O, değerin görünür bir vekiliydi sadece.

Model fonksiyonu yazabilir. Fonksiyonun var olup olmaması gerektiğine karar veremez.

Asıl değer kazanan ne

Klavye yazımını çıkarın ve geriye kalana bakın. Bunların her biri zaten her zaman kıdemli işin içinde vardı; yapay zeka yalnızca onları kamufle eden angaryayı ortadan kaldırdı.

Problemi çerçeveleme. Bulanık bir talep — “kullanıcılar checkout’un yavaş olduğundan şikâyet ediyor” — bir spesifikasyon değildir. Bunu çözülebilir, yanlışlanabilir bir mühendislik problemine dönüştürmek en zor ve en az otomatikleştirilebilir adımdır, çünkü işi, kullanıcıları ve hangi “yavaş”ın gerçekten önemli olduğunu bilmeyi gerektirir. Bir asistan, yanlış şeyi seve seve kusursuz bir biçimde optimize eder.

Sistem tasarımı ve sınırlar. State nerede yaşıyor? Bu bağımlılık çöktüğünde failure mode ne? Ekip üç katına çıktığında, on sekiz ay sonra hangi dikiş yerlerine pişman olacağız? Modeller makul yerel kod üretir; sizin sisteminizin kısıtlarını, geçmişini ve tradeoff’larını, o pager’ı bir yıl boyunca taşımış bir insanın yaptığı gibi kafalarında tutarlı bir model olarak tutmazlar.

Aşikâr olmayanı debug etmek. Asistanlar diff’te görünen hatada harika, üç servisin etkileşiminden, yanlış yapılandırılmış bir timeout’tan ve bir artık saniye (leap-second) köşe durumundan ortaya çıkan hatada zayıftır. O çetrefilli, çoklu sistem, “bu yalnızca prod’da yük altında oluyor” türü arızalar hâlâ sağlam biçimde insan toprağıdır ve itibarların kazanıldığı yer de orasıdır.

Zevk ve muhakeme. Belli bir soyutlamanın erken olduğunu bilmek. Bir PR’ın teknik olarak doğru ama bir bakım kâbusu olacağını sezmek. “Zekice”nin ne zaman bir yük olduğunu fark etmek. Zevk, sıkıştırılmış deneyimdir ve modellerin en bariz biçimde eksik olduğu şeydir — oyunda kaybedecekleri bir şey yoktur ve bu desenin son üç kez nasıl patladığına dair hiçbir hafızaları yoktur.

Doğrulama (verification). Bir makine bir dakikada on makul çözüm üretebildiğinde, darboğaz üretmekten ayırt etmeye kayar. Kıt beceri, doğruyu ikna edici-ama-yanlış olandan güvenilir biçimde ayırt etmek olur — üretilen kodu eleştirel bir gözle okumak, neyi test edeceğini bilmek, asistanın düşünmediği durumun kokusunu almak.

Neyin inşa edilmeyeceğini bilmek. En pahalı kod, var olmaması gereken koddur. Ucuz üretim bunu daha az değil, daha fazla tehlikeli kılar: inşa etmek neredeyse bedava olduğunda, “buna ihtiyacımız yok, ticket’ı sil” diyebilme disiplini bir süper güce dönüşür.

Junior’ın yeni ikilemi

İşte hiç kimsenin tam olarak çözemediği ve dürüst olmamız gereken kısım. Muhakemeye giden geleneksel merdiven, angaryanın içinden geçiyordu. Bin tane sıkıcı fonksiyon yazardın ve bir yerlerde, bu desenin neden ötekinden daha iyi olduğunu, bu veritabanının çekişme (contention) altında gerçekte nasıl davrandığını, iyi bir arayüzün nasıl hissettirdiğini özümserdin. Angarya, ödenen okul ücretiydi. Şimdi o ücret otomatikleştirilip ortadan kaldırılıyor ve bir asistanı çalışan bir özelliğe yönlendirebilen ama yalan söylediğini ne zaman anlayacağına dair sezgiyi hiç geliştirmemiş mühendisler üretmenin gerçek bir riski var.

Önümüzdeki beş yılın asıl problemi bu. Üretilen kodu eleştirmeden kabul eden bir mühendis junior mühendis değildir — kendinden emin bir otomatik tamamlamaya sahip çok hızlı bir daktilografdır. Merdiven hâlâ duruyor, ama artık ona kazara değil, bilinçli olarak tırmanmanız gerekiyor; çünkü iş artık dersleri size zorla dayatmayacak.

Bu çağda gerçekten nasıl gelişilir

İyi haber: yol kulağa geldiğinden daha net. Bileşik faiz gibi birikerek büyüyen beceriler, yapay zekanın en kötü olduğu becerilerdir; o yüzden zamanınızı kasıtlı olarak bunlara doğru optimize edin.

• Yazdığınızdan çok daha fazla kod okuyun. Üretmek ucuz; kavramak kısıttır. Üretilen diff’leri, biraz fazla özgüvenli bir yabancının PR’ını review ediyormuş gibi okumayı alışkanlık hâline getirin — çünkü öyle yapıyorsunuz.
• Acımasızca doğrulamayı öğrenin. Asistanın yazmadığı testi siz yazın. Düzeltmeye güvenmeden önce hatayı yeniden üretin. “Derleniyor ve happy path çalışıyor” ifadesini sorunun sonu değil, başlangıcı olarak görün.
• Temellere derinlemesine inin. Eşzamanlılık (concurrency), veri yapıları, veritabanları ve ağların gerçekte nasıl davrandığı, belleğin nasıl çalıştığı. Bunlar trend olmaz; makul bir cevabı doğru olandan ayırt etmenizi sağlayan ana zemin bunlardır. Asistan, temelleri uygulamanın daha hızlı bir yoludur, temellere sahip olmanın bir yedeği değil.
• Ticket’ları değil, sonuçları sahiplenin. İşinizi, kullanıcının probleminin gerçekten çözülüp çözülmediğine ve çözülmüş kalıp kalmadığına bağlayın. Sonuç sahipliği, hiçbir modelin sahip olmadığı kastır, çünkü hiçbir model hesap verebilir değildir.

Sevdiğimiz somut bir alışkanlık: önemsiz olmayan, üretilmiş bir değişikliği kabul etmeden önce kendinizi üç soruyu yazılı olarak cevaplamaya zorlayın.

1. What would break this? (the input the model didn't consider)
2. Would I have designed it this way myself? If not, why not?
3. What does this make harder to change later?

Bunları cevaplayamıyorsanız, kodu review etmemişsinizdir — onu aklamışsınızdır. Bunu birkaç yüz kez yapmak, eski angarya merdiveni olmadan muhakemenin yeniden inşa edilme biçimidir.

Pangaea artık kıdemli bir mühendiste ne arıyor

İşe alım çıtamız değişti ve bunun nasıl olduğunu açıkça söylemekte fayda var. Birinin ezberden ne kadar hızlı doğru bir implementasyon üretebileceğini eskisi kadar önemsemiyoruz, çünkü bu giderek iyi bir asistanın sağladığı bir asgari koşul hâline geliyor. Çok daha fazla önemsediğimiz şey ise ikincil dereceden beceriler:

Belirsiz bir iş problemini alıp doğru teknik şekle oyabiliyor musunuz? Size cilalı, üretilmiş bir çözüm verildiğinde onu kabul mü ediyorsunuz yoksa sorguya mı çekiyorsunuz — ve onun yanlış yaptığı o ince şeyi yakalıyor musunuz? Yazmadığınız bir sistem hakkında, arıza altında, sabahın ikisinde akıl yürütebiliyor musunuz? Doğru hamlenin daha az kod yazmak ya da hiç yazmamak olduğu anı biliyor musunuz? Ve bir tradeoff’u, mühendis olmayan bir kurucuya, gerçekten kararı verebileceği şekilde anlatabiliyor musunuz?

Bunların hiçbirinin klavye hızıyla ilgili olmadığına ve hepsinin belirsizlik altında muhakemeyle ilgili olduğuna dikkat edin. Bu bir tesadüf değil. Asistan çıktının zeminini yükseltti; muhakemenin tavanına ise hiçbir şey yapmadı ve ikisi arasındaki boşluk, tam olarak kıdemli değerin bugün yaşadığı yer.

Kıdem hiçbir zaman kodu ne kadar hızlı yazdığınızla ilgili olmadı. Hangi kodun yazılmaya değer olduğuna ne kadar güvenilir biçimde karar verdiğinizle ve önünüzdeki kodun gerçekten doğru olup olmadığıyla ilgili.

Bunun sizin için anlamı

Eğer ayağının altındaki zeminin kaydığını hisseden kıdemli bir mühendisseniz, hamle makineyi klavyede geçmek değil — kaybedersiniz. Hamle, makinenin yapamadığı muhakeme işine sıkıca yaslanmaktır: çerçeveleme, tasarım, doğrulama, zevk ve sonuçlar. Asistanı sıradanlaşan katman için agresif biçimde kullanın ve kazandığınız saatleri bileşik biçimde büyüyen kısımlara yeniden yatırın.

Eğer kariyerinizin daha başındaysanız, asistanın okul ücretinizi sizden çalmasına izin vermeyin. Onu kullanın, ama size verdiği her şeyi sorguya çekin. Ürettiğinizden çok okuyun, güvendiğinizden çok doğrulayın ve onun sığ kaldığı yerde derine inin. Muhakemeyi kasıtlı olarak inşa edin, çünkü iş artık onu sizin yerinize kazara inşa etmeyecek.

Ve eğer işe alım yapıyor ya da bir ekibe liderlik ediyorsanız: mühendisleri sevk edilen satırlarla ölçmeyi bırakın ve iyi verilen kararlarla ölçmeye başlayın. Gereksiz özelliği silen, makul-ama-yanlış PR’ı yakalayan ve imkânsız ticket’ı sevk edilebilir bir hâle yeniden çerçeveleyen mühendis, artık her zamankinden daha değerli — çünkü araçlar herkesi hızlandırdı ve bu da hızı nereye yönlendireceğini bilmeye daha yüksek bir prim koydu.

Yapay zeka mühendislerin yerini almayacak. Sessizce ve kalıcı olarak, muhakemenin fiyatını yükseltiyor. Bu, bu işe klavye yazımı için değil, mühendislik için girmiş herkes için iyi haber.