Lenny Rachitsky 10 Kasım 2026’da teknoloji iş piyasasıyla ilgili yılın ikinci raporunu yayımladı. Raporda dikkatimi çeken pek çok veri var: mühendislik ilanlarındaki büyüme neredeyse durmuş, ABD’de işe alınan yazılım mühendisi sayısı 2022’nin yarısının altına inmiş, uzaktan çalışma ilanları tarihin en düşük seviyesinde. Ama raporun en çok konuşulacak cümlesinin şu olacağını düşünüyorum: Forward deployed engineer ilanları bir yılda 4,6 kat artmış.

İlk tepkim heyecan değil, bir dejavu oldu. Bence piyasada olan şey yeni bir mühendis türünün ortaya çıkması değil. Aynı mühendis popülasyonuna yeni bir ünvan veriliyor, iş tanımına da birkaç yeni beceri ekleniyor: biraz “LLM”, biraz “Claude”, biraz “MCP”. Çorba aynı çorba, sadece içine birkaç yeni baharat atılmış.

Bu yazıda bu görüşün ne kadarının verilerle desteklendiğini, ne kadarının benim yorumum olduğunu ayırmaya çalışacağım. Çünkü “her şey sadece etiket” demek de en az “her şey yepyeni” demek kadar kolaya kaçan bir yaklaşım.

Rakamlar ne söylüyor?

Önce rapordaki verileri kısaca özetleyeyim. Rapor iki veri kaynağı kullanıyor: açık pozisyonlar için 9.000’den fazla teknoloji şirketini izleyen TrueUp (küresel), işe alımlar için ise Live Data Technologies (yalnızca ABD).

  • Açık mühendislik pozisyonları 2024’te %29, 2025’te %15 büyümüş; son bir yılda ise yalnızca %2,5 civarında. Rapor, serinin tarihinde ilk kez bir duraklamadan söz ediyor.
  • ABD’de Mayıs 2025 – Nisan 2026 arasında yaklaşık 113 bin yazılım mühendisi işe alınmış. 2022’deki zirve 239 bindi ve o zamandan beri her yıl düşüyor.
  • Buna karşılık Ocak 2024’ten bu yana açık mühendislik pozisyonları %44 artmış, işe alımlar %17 azalmış. Yani şirketler hâlâ arıyor ama bulamıyor ya da seçiciliği artırmış.
  • Forward deployed engineer (FDE) ilanları yaklaşık 1.500’e ulaşmış ve bir yılda 4,6 kat artmış. Güvenlik mühendisliği FDE’den sonra en hızlı büyüyen uzmanlık. Mobil ve front-end ilanları ise bir yılda neredeyse yarıya inmiş.
  • Ürün yöneticisi ilanlarında en çok aranan beceri artık “LLM”. “Claude” üçüncü sırada, Cursor, OpenAI ve MCP ilk sekizde. Mühendislik ilanlarında Python hâlâ ilk sırada ama “LLM” Java’yı geçmiş.

Raporun yazarı bu tabloyu, yapay zekâ sayesinde küçük ekiplerin daha geniş sorumluluk alanlarını sahiplenebilmesiyle ve silo uzmanlıkların erimesiyle açıklıyor.

Silo uzmanlık: Bir mühendisin sistemin yalnızca tek bir katmanında ya da teknolojisinde (örneğin yalnızca mobil, yalnızca front-end veya yalnızca veritabanı) uzmanlaşması ve işin geri kalanının başka ekiplere devredilmesi. Bir özellik birkaç uzmanın arasında el değiştirerek ilerler; her biri kendi parçasından sorumludur, ama ortaya çıkan sonucun tamamından kimse sorumlu değildir.

Bu açıklamaya kısmen katılıyorum. Ama aynı verilere başka bir gözle de bakılabileceğini düşünüyorum.

Küçük bir tabandan büyük bir yüzde

4,6 kat artış etkileyici bir başlık. Fakat hangi tabandan büyüdüğüne bakınca tablo değişiyor. Raporun kendi ifadesiyle FDE uzun yıllar boyunca birkaç düzine pozisyondan ibaretti ve neredeyse tamamı Palantir’deydi. Bugün yaklaşık 1.500 ilan var. Aynı raporda açık mühendislik pozisyonu sayısı 65 binin üzerinde. Yani FDE, açık mühendislik pozisyonlarının kabaca %2’si.

Bu, iş piyasasını yeniden şekillendiren bir dalga değil. Bir ünvanın moda olduğunu gösteren bir sinyal.

Daha da önemlisi, raporun yazarı da bu büyümenin bir kısmının yeniden adlandırılmış satış mühendisi pozisyonlarından gelebileceğini kabul ediyor. Benim görüşümün özü tam olarak bu: Pozisyon sayısı artmıyor; aynı pozisyonun etiketi değişiyor.

İş ilanı da bir pazarlama metnidir

Nisan ayında yazdığım AI Etiketli Ürünler Gerçekten Ne Sunuyor? yazısında, birçok ürün için “AI” ifadesinin bir teknoloji bileşeni değil bir pazarlama zorunluluğu haline geldiğini tartışmıştım. Ürünü değiştirmeden üzerine “AI-powered” yazmak hem kolaydı hem de satış ve yatırım konuşmalarında işe yarıyordu.

İş ilanlarında da aynı örüntüyü görüyorum.

Bir iş ilanı yalnızca “bu işi yapacak birini arıyoruz” demiyor. Aynı zamanda adaylara, yatırımcılara ve rakiplere “biz yapay zekâ çağının şirketiyiz” mesajı veriyor. Bir ilana “LLM” ya da “MCP” kelimesini eklemenin maliyeti sıfır. Ama o kelime ilanı daha güncel, şirketi daha iddialı gösteriyor.

Bu yüzden iş ilanlarındaki anahtar kelime istatistiklerini, işin kendisinin nasıl değiştiğinin doğrudan ölçüsü olarak okumamak gerekiyor. Bu veriler işe alım uzmanlarının ve işe alım yöneticilerinin ne yazdığını gösteriyor. İşin gerçekten neyi gerektirdiğini değil.

“LLM” kelimesinin Java’yı geçmesi, şirketlerin Java ile yazılmış sistemlerini bıraktığı anlamına gelmiyor. O sistemler büyük ihtimalle yerinde duruyor ve bakımını yine aynı insanlar yapıyor. Değişen, ilanın hangi kelimeyle dikkat çekmeye çalıştığı.

Bu ilk kez olmuyor

Yazılım sektörünün ünvan geçmişine bakınca bu döngüyü birkaç kez yaşadığımızı görüyoruz.

Sistem yöneticileri bir dönem DevOps engineer oldu, sonra bir kısmı SRE, şimdi bir kısmı platform engineer. Veri analistlerinin bir kısmı data scientist oldu, sonra ML engineer, şimdi AI engineer. Kurumsal yazılımda yıllardır var olan implementation consultant, professional services engineer, solutions engineer ve customer engineer rolleri ise bugün forward deployed engineer etiketiyle yeniden karşımıza çıkıyor.

Bu geçişlerin hepsinde gerçek bir değişim de vardı. DevOps, geliştirme ve operasyon ekiplerini gerçekten birbirine yaklaştırdı. Ama aynı zamanda her geçişte işin önemli bir kısmı aynı kaldı, aynı insanlar aynı işi yeni bir ünvanla yapmaya devam etti, değişen çoğu zaman yalnızca ücret beklentisi oldu.

Özellikle endüstriyel yazılım tarafında çalışanlar bunu çok iyi bilir. Fabrika sahasında makineye bağlanan, devreye alma yapan, müşterinin süreçlerini öğrenen ve ürünü o sahaya uyarlayan mühendis on yıllardır var. Ona saha mühendisi, devreye alma mühendisi, uygulama mühendisi dedik. Bugün aynı profilin Silikon Vadisi’ndeki adı forward deployed engineer.

Peki hiç mi gerçek bir değişim yok?

Var. Bu noktada kendi görüşümü de sınamak istiyorum, çünkü “sadece etiket” demek işin kolay tarafı.

Bence etiketin arkasında iki gerçek değişim var.

Birincisi, mühendisin kime hesap verdiği değişiyor. Klasik bir ürün ekibinde mühendis backlog’a, sprint’e ve kapanan ticket’a göre değerlendirilir. Müşterinin yanında çalışan bir mühendis ise müşteride ortaya çıkardığı değere göre değerlendirilir: Fabrikadaki duruş süresi azaldı mı, finans ekibinin ay sonu kapanışı kısaldı mı, entegrasyon gerçekten canlıya çıktı mı? Bu, aynı kişinin yaptığı işin anlamını değiştiriyor. Ama bu bir işletim modeli değişikliği, yeni bir insan türü değil.

İkincisi, sorumluluk alanı genişliyor. Mobil ve front-end ilanlarının yarıya inmesi ile “LLM” becerisinin her rolde aranır hale gelmesi aynı hikâyenin iki yüzü. Yapay zekâ ile çalışan bir mühendis eskiden üç ayrı uzmanın yaptığı işi tek başına sahiplenebiliyor. 2030’a Giderken Yazılım Mühendisliği yazısında tartıştığım gibi değer kod yazmaktan neyin yazılacağına karar vermeye, doğrulamaya ve sistem düşüncesine kayıyor.

İlginç olan şu: Gartner bu değişimi bir ünvan olarak değil, bir sorumluluk kümesi olarak tarif etmişti. AI ile Küçülmek yazısında ele aldığım Gartner araştırması Internal Forward-Deployed Engineer‘ı Product Engineer, AI Engineer ve Platform Engineer ile birlikte dört rol arketipinden biri olarak sayıyor ve bunların yeni iş ünvanları olmadığını özellikle vurguluyordu.

Arketip: Bir şeyin temel, tipik örneği; benzerlerinin ortak özelliklerini taşıyan ilk örnek ya da kalıp.

Piyasa ise bu sorumluluk kümelerini hızla ünvanlara çevirdi. Bence sorunun kaynağı tam olarak burada.

Ünvan değişince ne kaybolur?

Bir sorumluluk kümesini ünvana çevirmek masum bir dil tercihi gibi görünebilir. Ama sonuçları var.

Anahtar kelimeye göre işe alım yapmaya başlarız. CV’sinde “forward deployed” ya da “LLM” yazmayan ama on yıldır müşteri sahasında ürünü çalıştıran mühendisi eleme riskine gireriz. Buna karşılık son altı ayda birkaç ajan demosu yapmış ve ünvanını güncellemiş adayı daha uygun görebiliriz.

Tek bir kişiden bütün rolleri bekleriz. Bir FDE’den beklenenleri yan yana koyduğumuzda satış mühendisinden, ürün mühendisinden, AI mühendisinden ve proje yöneticisinden beklenen becerilerin aynı listede toplandığını görüyoruz. Bu bir rol tanımından çok bir dilek listesi. Aynı kişinin hem müşteri sahasında hem ürün mimarisinde hem de model değerlendirmesinde derinlik taşıması istisnai bir durum.

Ürün şirketi farkında olmadan hizmet şirketine dönüşebilir. Müşterinin yanında çalışan mühendisin sahada öğrendikleri ürüne geri dönmüyorsa, her müşteri için ayrı bir kod tabanı birikir. AI ile Küçülmek yazısında “şirket tipini fark etmeden değiştirmek” diye tarif ettiğim risk bu. FDE modelini Palantir için anlamlı kılan şey ünvan değildi; sahadan gelen öğrenmenin sistematik biçimde platforma geri taşınmasıydı. Ünvanı alıp bu geri besleme döngüsünü kurmadan uygulamak, müşteri başına özel geliştirmeyi daha havalı bir isimle sürdürmek anlamına gelir.

Giriş kapısı daha da daralır. AI Çağında Junior Geliştiricileri Kaybetmemeliyiz yazısında giriş seviyesi ilanlarda artık kıdemli mühendislerden beklenen yetkinliklerin istendiğini anlatmıştım. Her yeni ünvan, iş tanımına birkaç yeni beceri daha ekliyor. Senior bir mühendis için bu birkaç ek araç öğrenmek demek. İlk işini arayan biri için ise aşılması gereken listeye yeni maddeler eklenmesi demek.

Bir yönetici olarak ben ne yapardım?

Bu tartışmayı bir işe alım kararına indirdiğimde vardığım sonuç şu: Kimseyi yeniden adlandırmaya gerek yok. İşi tarif etmek gerekiyor.

Bir pozisyon açmadan ya da mevcut bir ekibi yeniden yapılandırmadan önce şu sorulara cevap vermek, hangi ünvanı kullanacağımızdan çok daha önemli:

  • Bu kişi hangi kararları kendi başına verecek?
  • Başarısı neyle ölçülecek: kapanan iş kalemiyle mi, müşteride ortaya çıkardığı değerle mi?
  • Müşteri sahasında yapılan bir değişikliğin ürüne mi gireceğine yoksa o müşteriye özel mi kalacağına kim karar veriyor?
  • Sahada öğrenilenler hangi mekanizmayla ürüne ve platforma geri dönüyor?
  • Bu iş için gerçekten hangi beceriler gerekiyor ve bunlardan hangileri ilana sadece güncel görünmek için ekleniyor?

Bu sorulara net cevap verebilen bir organizasyon, pozisyona ister “yazılım mühendisi” ister “forward deployed engineer” desin, doğru kişiyi bulma ihtimali daha yüksek. Cevap veremeyen bir organizasyon ise ünvan ne olursa olsun yanlış beklentiyle işe alım yapacak.

Benzer şekilde mevcut ekipteki mühendislere yeni ünvanlar vermek yerine çalışma biçimini değiştirmek daha değerli. Bir mühendisi müşteride ortaya çıkardığı değerden sorumlu tutmak, sahada öğrendiklerini ürün kararlarına taşıyacak bir kanal açmak ve yapay zekâ araçlarıyla daha geniş bir alanı sahiplenebilmesi için ona zaman ve platform desteği vermek gerçek değişimdir. Kartvizitteki ünvanı değiştirmek değil.

Sonuç: Ünvan ucuz, işletim modeli pahalı

Lenny’nin raporu yazılım mühendisliği iş piyasası hakkında önemli bir şey söylüyor: Şirketler daha az mühendis işe alıyor, ama aradıkları mühendisler hâlâ zor bulunuyor ve beklentiler genişliyor. Bu tespite katılıyorum.

Ancak “forward deployed engineer” gibi yükselen ünvanları yeni bir mühendis popülasyonunun doğuşu olarak okumanın yanıltıcı olduğunu düşünüyorum. Benim okumam şu: Piyasa aynı insanları yeni bir dille anlatıyor, iş tanımına birkaç yeni beceri ekliyor ve bunu bir dönüşüm gibi sunuyor.

Bunun altında gerçek bir değişim de var: mühendisin kime hesap verdiği ve ne kadar geniş bir alanı sahiplendiği değişiyor. Ama bu değişimi bir ünvanla satın alamayız. Yeni bir ünvan bulmak bir toplantı sürer. Yeni bir çalışma biçimi kurmak ise yıllar.

Belki de önümüzdeki dönemde sorulması gereken soru “bize bir forward deployed engineer lazım mı?” değil:

Mühendislerimiz müşterinin gerçek problemine ne kadar yakın çalışıyor ve oradan öğrendiklerini ürüne geri taşıyabiliyorlar mı?

Kaynaklar

  1. Lenny Rachitsky, State of the tech job market: late 2026, Lenny’s Newsletter, 10 Kasım 2026.
  2. Gartner, The Future of the Software Engineer Role in the Age of AI, Neha Agarwal, Brian Minning, Luke Parker, Nitish Tyagi, 5 Mayıs 2026, ID G00842471.
  3. Ali Özgür - AI Etiketli Ürünler Gerçekten Ne Sunuyor?
  4. Ali Özgür - AI Çağında Junior Geliştiricileri Kaybetmemeliyiz
  5. Ali Özgür - 2030’a Giderken Yazılım Mühendisliği: Kod Yazmanın Ötesinde
  6. Ali Özgür - AI ile Küçülmek: Maliyet Azaltırken Kabiliyeti de Kaybediyor muyuz?

Not: Raporun açık pozisyon verileri küresel, işe alım verileri ise yalnızca ABD kapsamındadır; Türkiye pazarını doğrudan temsil etmez. Raporun son bölümü ve bazı grafikleri ücretli abonelik arkasında olduğu için bu yazıda yalnızca herkese açık bölümdeki veriler kullanılmıştır. Pozisyonların yeniden adlandırılmasına ilişkin değerlendirmeler benim yorumumdur.

Bu yazıyı beğendiyseniz Twitter’da takipçilerinizle paylaşabilir veya beni Twitter’da takip edebilirsiniz.