Son bir ayda, ön uç, çözümler mimarı, ürün yöneticisi ve geleneksel algoritmik mühendis olmak üzere dört farklı arkadaşı tanıştım — arka planları, yaşları ve şehirleri farklıydı, ancak hepsi aynı İngilizce kısaltmayı sordu: FDE [2] gitmeye değer mi?
FDE, tam adıyla Forward Deployed Engineer [2]. İki yıl önce hâlâ Palantir çevresinde kullanılan bir iç dil ifadesiydi, bugün ise kariyer danışmanlarının açılış cümlesi, iş ilanlarındaki sıklıkla geçen pozisyon ve sosyal medyada “AI çağındaki en değerli pozisyon” adaylarından biri haline geldi. OpenAI, 2026 Mayıs'ta doğrudan bu isimle bir Deployment Company [3] kurdu, ilk yatırımını 4 milyar dolar olarak belirledi ve mühendislerini müşterilerin ofislerine göndererek müşterilerin iş akışlarına dahil olmayı açıkça hedefledi; Anthropic'ın Applied AI ekibi de dört farklı saat diliminde FDE işe alımını aynı anda başlattı. Bu kavram, iç dil ifadesinden açıkça kullanılan bir terime dönüşmek için sadece bir yıl kadar sürdü.
Yazarın önceki makalesi olan “Süper Bireylere” [4], “insan motoru” olarak bilinen merak, kendi kendine öğrenme, kendi kendini yönlendirme ve pratik becerilerin tam bir Closed-loop içinde nasıl uyandırıldığına dairdi. Ancak insanlar asılı değildir; insanlar belirli bir pozisyon koordinat sistemiyle tutulmalıdır. Eğer süper bireyler, AI çağı üretim ilişkilerinin “ham maddesi” ise, FDE bu yıl piyasada ortaya çıkan en belirgin “pozisyon biçimidir”.

Yazarın görüşüne göre, FDE danışmanlık kategorisinde değil, dış kaynak kategorisinde de değil. FDE, son zamanlarda süper bireylerle en yakın ilişkiye sahip; fark ise FDE'nin “model şirketi × müşteri” arasındaki boşlukta organize edilmiş bir süper birey olması.
Biliyor musunuz—Forward Deployed kelimesi nereden geliyor? Bu terim, orijinal olarak ABD ordusunun Forward Deployed Forces terimi olup, ana üslerde kalan arka plan birliklerine karşı, yurt dışına veya cepheye yerleştirilmiş ve yakından tepki verebilen birlikleri ifade eder. Palantir, 2000’lerin sonunda bu terimi yazılım sektörüne taşıyarak “mühendisleri merkezden çıkarıp müşteri sahalarında yaşamalarını sağlamak” anlamında kullanmaya başladı ve dahili ekipleri bile askeri fonetik alfabeye göre Delta ve Echo olarak adlandırdı. Bu kez OpenAI ve Anthropic tarafından yeniden ele alınması tesadüf değil—mühendisleri ön çizgiye göndermek, temel olarak hiçbir zaman değişmedi.
Yazara göre, son zamanlarda dört arkadaşın sorduğu üç spesifik soruyu bu makale cevaplayacaktır.
FDE, AI giymiş bir danışmanlık firması mı? Geleneksel danışmanlıkla arasındaki sınır nerede?
FDE, daha üst düzey bir yazılım dış kaynaklama mı? Şu anda yaptığım tarafla ne farkı var?
Ben FDE olmaya uygun muyum? Bu pozisyon hangi tür insanları büyütür, hangi tür insanları ezar?
Yazarın tutumu dikkatli iyimserlik: FDE gerçekten büyüyor, ancak herkesin dönüşüm çıkış yolu değil. Onu gürültülü hale getirmekten ziyade, açıkça anlatmak daha önemlidir.
OpenAI'nin Dağıtım Takımı'ndan başlayarak
FDE bu tur yeniden ortaya çıkışının tek bir noktayı işaretlemek için, yazar 11 Mayıs 2026 tarihini seçerdi—o gün OpenAI, Deployment Company [5] kurduğunu duyurdu, COO Brad Lightcap, eski ticari biriminden ayrılarak özel projelere geçti ve Sam Altman'a doğrudan rapor vermek üzere bu işi tam zamanlı olarak yürüttü. Aynı hafta, OpenAI, İngiliz AI danışmanlık firması Tomoro'yu satın aldı ve 150 Forward Deployed Engineer ve Deployment Specialist'i yeni şirkete dahil etti.
Dikkat edilmesi gereken nokta, OpenAI'nin istihdam sayfasında aynı anda San Francisco, New York, Washington dışında Life Sciences, Semiconductor, Gov gibi sektör bazlı dikey alanlarda onlarca FDE pozisyonu ilan edilmiş olması; hatta FDE istihdam sorumlusu [6] pozisyonu bile açıktır. Analistler, bu ekibin üç yıl içinde 2.000–4.000 kişiye ulaşacağını tahmin ediyor. Bu, bir araştırma grubunun boyutu değil, düzenli bir ordu.
Anthropic tarafında neredeyse tamamen yansıma hareketi gerçekleşiyor. Applied AI ekibinin Forward Deployed Engineer pozisyonu [7], Boston, New York, Seattle, San Francisco, Washington ve Londra'da aynı anda ilan edildi ve %25–50 müşteri bazlı seyahat gerektiriyor. Son zamanlarda sıkça alıntılanan bir örnek, finansal teknoloji şirketi FIS'tir—ilanında doğrudan “Anthropic’in Applied AI ekibi ve forward-deployed mühendisleri, FIS’e entegre edilerek Financial Crimes AI Agent’ını birlikte tasarladı ve bilgi transferi yaparak FIS’in daha fazla agent’ı bağımsız olarak genişletmesini sağladı” yazıyor.
Bu metin, FDE işinin gerçek yüzünü gizliyor. Bu, ön satış mimarı, SDR ya da müşterilere eğitim veren bir evangelist değil. Modelle birlikte müşterinin kod deposuna yerleşen bir mühendistir. Brad Lightcap daha açık sözlü: “Müşterilerimiz bize, pilot aşamasından üretim aşamasına geçme yeteneği istediğini söylüyor. Deployment Company, mühendislerimizi takımlarına dahil edip, teslimat için gerekli kaynakları sağlıyor.”
Bu olayı bir grafik haline getirirseniz, üçlü ilişki çok daha net hale gelir:

Bu grafikte en bilgilendirici iki çizgi, FDE'nin iki yöne verdiği geri bildirimdir. Müşteri yönünde, FDE modeli SaaS olarak satmıyor; müşterinin verilerini, yetkilerini, uyumluluğunu ve dahili sistemlerini bir modeli çalıştıran bir boru hattına dönüştürüyor. Model şirketleri yönünde, FDE müşterilerin gerçek sorunlarını ve başarısız örnekleri product ve research e geri taşıyarak roadmap'i etkiliyor—bir dizi hata yapan tool calling kalıbı, SDK'nın bir sonraki yerleşik soyutlaması haline gelebilir.
Bu, neden FDE'nin bu turda iki büyük model şirketinin aynı anda yeniden devreye alındığını açıklıyor; arka planda sadece “Biz de Palantir gibi danışmanlık yapalım” diye bir şey yok. Bu, model şirketlerinin bir sinyal toplama cihazı—öncü çizgideki en yoğun müşteri sorunları, kendi insanlarının orada olmasıyla ancak yakalanabilir; ortaklardan gelen talepler her zaman bir katmanla aralanır. Anthropic, karışık bir yol izliyor: FDE'yi hem kendi başına yürütüyor, hem danışmanlık firmalarıyla hem de PE devleriyle ortaklık kurarak dağıtım ağı oluşturuyor. Birisi daha çok kendi başına, diğeri daha çok ekosistem odaklı, ancak içsel çekirdek aynı: Model şirketleri artık sadece API sağlayıcıları değil, mühendislerini doğrudan müşteri ürünlerine gönderiyorlar.
Sonraki cevap, en yaygın iki karşılaştırmalı sorudur—FDE ile geleneksel danışmanlık (McKinsey, Accenture gibi) arasındaki sınır nerededir? Bu, tanıdık olduğumuz yazılım dış kaynaklama ile aynı şey midir?
FDE, McKinsey değil: Model sınırı vs. Süreç sınırı
FDE'nin iş tanımını ilk kez duyan birçok kişi, ilk tepkisi olarak: “Bu, yeni nesil McKinsey ya da Accenture değil mi?” diyor.
Yazar, bu bağlantıyı anlıyor. Piyasada elbise giymek, müşteri yerinde seyahat etmek, müşteri toplantı odasında beyaz tahta çizmek, C seviyesi yöneticilerle uyum sağlamak — görsel olarak FDE ve danışmanlar gerçekten benzer görünüyor. Ancak bir kat daha içeri girdiğinizde, ikisinin çalışma dokusu tamamen farklı. Danışmanlık süreç sınırlarını satıyor, FDE ise model sınırlarını.
İkisini bir tabloda yan yana koyduğınızda fark hemen ortaya çıkar.

Bu tabloda durup düşünmeye değer olan, "varlık amortismanı" satırıdır.
Geleneksel danışmanlığın en karlı mantığı, varlık yeniden kullanımıdır—bir bankaya sunulan bir çözüm, bir sonrakiye hafifçe değiştirilerek tekrar satılır; bir perakende sektörü dijital playbook'u, otuz müşteriye tekrar uygulanabilir. Bu, son otuz yılda Accenture, Deloitte ve McKinsey Digital'in büyümesinin temel ekonomik modelidir.
FDE'nin böyle bir varlığı yok. Model yetenekleri hızla ilerliyor—bugün hala dikkatle tasarlanmış bir Prompt zinciri gerekiyor, ancak bir sonraki model versiyonunda belki bir cümleyle iş çözülüyor. Danışmanlığın “yöntemsel birikimi” bu hız karşısında hızla değerini kaybediyor. Bu nedenle FDE, varlık yeniden kullanım modelini kullanamaz; her kapalı döngüyü tekrar çalıştırmalı—model sınırlarını yeniden değerlendirmeli, araç yığınını yeniden seçmeli ve ürün formunu yeniden birleştirmelidir. Görünüşte verimsiz gibi görünse de, bu, model hızıyla eş zamanlı kalmanın tek yolu.
Biliyor musunuz—Product Overhang nedir? Yazar, önceki "Süper Bireylere" [4] makalesinde bu terimi açıkladı: Model yetenekleri, mevcut ürün formlarını aşmış olsa da, bunları gerçekleştirmek için bir ürün girişi, izin ve bağlam yoktur. FDE pozisyonunun değeri, temelde müşterinin senaryolarında asılı kalan Overhang'leri, çalışır hale gelen somut bir ürüne dönüştürmektir. Müşteriler, model API çağrısı kotası değil, "bu Overhang yığınınn gerçekten benim işime entegre edilebilmesi" yeteneğini satın alırlar.
Bu, "Proje Yapısı" satırındaki farklılığı da açıklıyor. Danışmanlık projelerinin standart yapısı, Çalışma Tanımı (SOW) + Çalışma Bölümleme Yapısı (WBS) + Aşama Kabuludur: Sözleşmede neyin, ne zaman ve hangi standartlara göre teslim edileceği açıkça belirtilir. Bu yapı, hedefin sözleşme imzalanmadan önce net şekilde tanımlanmış olduğunu varsayar.
FDE'nin projesi bu yöntemi takip etmiyor. Müşterilerin en sık söylediği cümle: "AI'nın bana bir şey yapmasını bekliyorum, ama ne yapacağını bilmiyorum." Hedef, projenin kendisinin bir parçasıdır. Bu nedenle FDE, SOW değil, misyon kabul eder — nispeten belirsiz bir yön; ardından iterasyonlarla bu yönü adım adım netleştirir; ve nihayetinde, bir iterasyonda birikmiş model anlayışını bir ürün formuna dönüştürür.
“Teslim edilecekler” satırı da genişletilerek açıklanmalı. FDE’nin ayrıldıktan sonra müşteri sisteminde kalan, küçük olabilir, çirkin olabilir, kullanıcı arayüzü az olabilir ama her gün gerçekten çağrılan, değiştirilen ve eleştirilen bir işlevdir. Danışmanlık teslim edilecekleri PPT ve değişim yönetimi raporudur; projede kod yazılmış olsa veya ERP yapılandırılmış olsa, sonunda müşteri yöneticilerinin elinde hâlâ bir yöntem belgesi kalır.
“Korumalı alan” satırı en ince olanıdır. FDE'nin korumalı alanı, model yeteneklerinin sınırında gerçek zamanlı bir hissedir—bu ay kaç gerçek müşteri senaryosu çalıştırdıysanız, Claude 4.7'nin ne yapabileceğini ve ne için Claude 5'in beklenmesi gerektiğini o kadar iyi bilirsiniz. Bu his, PPT'ye yazılamaz, bilgi tabanına eklenemez; sadece son 90 günde elini harekete geçiren mühendislerin zihninde büyür.
Bu yüzden biri bir daha "FDE, Accenture'un yeni versiyonu değil mi?" diye sorarsa, şöyle cevap verebilirsiniz: Accenture'in mühendisleri müşterilerinin süreçlerini yeniden tasarlar, FDE ise modelin sınırlarını yeniden keşfeder. İlk者的 varlıkları on yıl boyunca birikir, ikincisinin varlıkları 90 gün sonra yeniden büyümelidir.
FDE yazılım dış kaynak değildir: Ortak keşif vs. ihtiyaç realizasyonu
"FDE, Accenture'in yeni versiyonudur" demek birinci derece yanlış yorumlama ise, "FDE, pahalı yazılım dış kaynaklama" demek ikinci derece yanlış yorumlamadır. Bu düzey, görünür kanıtların çok güçlü olması nedeniyle daha yanıltıcıdır: FDE gerçekten müşterilerin yerinde kod yazar, müşterilerin iş süreçlerine göre özellikler özelleştirir ve müşterilerin çalışma saatlerine uygun şekilde çağrılır. İlk bakışta, dış kaynaklı mühendislerden farklı görünmez.
Ancak geri bildirim döngüsüne bir bakmakla fark ortaya çıkar.
Bu resimdeki en önemli fark, üst kısmının ne kadar basit olduğu değil, alt kısmında model şirketine uzanan bir geri bildirim zincirinin eklenmesidir. Bu zincir dekoratif bir öğe değil, FDE pozisyonunun var olmasının gerçek nedenidir. Bu farkı ayrıntılı şekilde incelediğimizde, en az dört karşılaştırma grubu ortaya çıkar.
Bağlanan şeyler farklı. Dış kaynak, SOW — sözleşme imzalanmadan önce net olarak tanımlanmış bir ihtiyaç listesi: hangi fonksiyonlar yapılacak, hangi teknoloji yığını kullanılacak, hangi standartlarla kabul edilecek, ihlal durumunda nasıl tazminat ödenecek. FDE, misyon — müşteri kendisi ne istediğini tam olarak bilmiyor, sadece “AI bana bir şeyler yapabilir” diye biliyor. SOW’un temelinde kesinlik, misyonun temelinde keşif yatıyor. İkisi tamamen farklı projeler başlatma tutumu.
Yapılan kapsam farklı. Dış kaynakla yapılan iş, yerel teslimatır—bir modül, bir web sitesi, bir veri pipeline, tamamlandıktan sonra paketlenip gider, bir sonraki müşteriye geçilir. FDE, uçtan uca yapar—işletme sorunlarından başlayarak, model seçimi, ürün tasarımı ve canlı kullanıcıların tutulum ve kaçış oranlarına kadar.
Faturalandırma yöntemi farklıdır. Bu en az beklentilere uygun olan noktadır. Bir model şirketi, FDE'yi müşteri sahasına gönderir ve sadece bu projeden ne kadar danışmanlık ücreti alacağından ziyade şunları önemser: Bu müşteri sonraki süreçte kaç token tüketecektir? Kalıcı bir müşteri haline gelir mi? Daha fazla iş hattına genişler mi? FDE'nin gerçek KPI'sı, proje onay belgesindeki rakam değil, model token'larının uzun vadeli tüketim eğrisidir.
Geri bildirimler farklı yollara sahiptir. Bu, dört gruptan en derin olanıdır. Dış kaynaklı projelerde, müşteri geri bildirimleri dış kaynaklı şirkete kadar ulaşır ve şirketin başkalarına satacağı ürünlerini etkilemez. FDE'nin geri bildirimleri ise model şirketinin yol haritasına geri akar—müşterilerin gerçek senaryolarda karşılaştığı her bir engel, her bir Prompt başarısızlığı ve her bir araç çağrısı hatası, bir sonraki eğitim verisi, bir sonraki araç tasarımı ve bir sonraki ürün fonksiyonunun girdisi haline gelir. Yani, her FDE dağıtım müşterisi, model şirketi için aynı zamanda doğal bir tasarım ortağıdır.
Bu, model şirketlerinin FDE'ye yüksek maaş vermek için gerçek nedenidir. Sadece bir hizmet satmıyorlar, müşterilerinin saha ortamlarında gerçek dünya ürün formu sinyalleri topluyorlar. Bu sinyaller satın alınamaz, yakalanamaz, anketlerle çıkarılamaz—sadece bir mühendis, belirli bir müşteri iş akışında birkaç kez duvara çarpıp getirebilir.
Biliyor musunuz—OpenAI ve Anthropic’in FDE toplam paketleri ne kadar olabilir? Levels.fyi üzerinde Anthropic yazılım mühendislerinin açık verilerine göre [8], deneyimli SDE’nin toplam paket medyanı zaten 710.000 $’a ulaşmış durumda. FDE pozisyonu daha yüksek risk taşır—model kapasitesinin belirsizliğiyle, müşteri işinin belirsizliğiyle ve ürün formatının belirsizliğiyle yüzleşmek zorundadır; bu nedenle endüstri özetlemelerine göre [9], öncü AI laboratuvarlarındaki orta ve üst düzey FDE toplam paketleri genellikle 350.000 $ - 550.000 $ arasında yer alırken, Staff seviyesinden yukarıları 630.000 $+’a ulaşabilir. Bu maaş, “dış kaynak saatleri” için değil, “ürün + müşteri + model” üçlü riskinin birleştirilmiş sorumlusu için ödeniyor. > 2006 yılında, ben yeni işe başlamıştım ve bir devlet kurumunda çalışıyordum; o dönemde kurumumuz bilgi teknolojisi dönüşümü geçiriyordu ve grubumuzun davet ettiği Accenture danışmanları, her gün 3.500 Yuan’lık danışmanlık ücreti karşılığında yıllarca orada kalmıştı; o dönemde medya onlara “altın yakalı” diyorlardı. Daha sonra Alman SAP şirketine geçtim; SAP, danışmanlık sektöründe bir isim tanımladı ve SAP danışmanları “altın yakalı” sembolü haline geldi. Buna göre, FDE maaşları en az 24-36 ay boyunca artmaya devam edecek ve talep de istikrarlı bir şekilde artacak.
Outsourcing, işgücü arbitrajıdır, FDE ise ön hat algılayıcısıdır. Bu iki şeyi karıştırmak, müşterilerin FDE'yi SOW yoluyla alıma alabileceğini düşünmesine ve adayların FDE'yi dış kaynak işi gibi işlemesine neden olur. Her iki taraf da kısa sürede duvara çarpar.
Yabancı FDE'nin iki kökü: Palantir ve yeni nesil model şirketleri
Çok sayıda kişi, FDE teriminin OpenAI tarafından icat edildiğini yanlış bir şekilde düşünüyor. Aslında değil. Bu terimin iki kök hattı var: biri Palantir'den, diğeri 2023 sonrası nesil model şirketlerinden. Bu iki kök hattı yan yana görmek, FDE pozisyonunun gerçekten ne yaptığını daha iyi anlamayı sağlar.
Bir zaman çizelgesine bir göz atın.
İlk kök Palantir'dir.
Palantir, 2003 yılında Peter Thiel, Alex Karp, Joe Lonsdale vb. tarafından kuruldu ve ilk müşterileri ABD istihbarat kurumlarıydı. Karp'ın CS arka planı yoktu—Frankfurt'ta filozof Jürgen Habermas ile doktora yaptı ve ABD'ye döndükten sonra Thiel tarafından CEO olarak getirildi. FDE pozisyonu, tam olarak bu "tipik olmayan CEO + yüksek derecede gizli müşteri" kombinasyonundan doğdu: 36Kr'nin geriye dönük analizinde [10] açıkça belirtildiği gibi, Palantir'in erken dönemlerinde istihbarat kurumları mühendislerin gerçek iş senaryolarına erişememesi nedeniyle sert eleştirilerde bulundu; gereksinimler katmanlı çevirilerden geçtikten sonra bozulmuştu. Daha sonra Palantir, kendi mühendislerinin müşterinin mekanına girip istihbarat analistleriyle birlikte çalışmasını sağlayacak bir anlaşma yaptı. Bu model daha sonra Shyam Sankar tarafından sistematikleştirildi ve FDE'nin temelini oluşturdu.
2009 yılına kadar FDE, ticari alana genişledi. JPMorgan, Palantir'in Metropolis platformunu kurduğunda, 120 FDE, iç tehdit izleme için yerleştirdi. Bundan itibaren, FDE sadece “mühendisleri seyahate göndermek”ten öteye geçti ve bir sistemli müşteri entegrasyon stratejisi haline geldi: Foundry/Gotham'u müşterinin iş akışına gerçekten entegre etmek, sadece bir lisans verip gitmek yerine.
Palantir'in FDE iş ilanında tersine bir kriter var — CS diploması istenmiyor. Bu bilgi "Biliyor muydun?" bölümüne eklenebilir.
Biliyor musunuz—Palantir FDE, Bilgisayar Bilimi diploması istemiyor? SkillScouter tarafından derlenen Palantir iş ilanı kriterleri [11] ve Palantir resmi kariyer sayfası [12]’ye göre, Palantir, Bilgisayar Bilimi dışındaki adayları açıkça karşılıyor; son dönemdeki FDE alımları, Makine Mühendisliği, Ekonomi, Felsefe gibi alanlardan geliyor. Gerçekten önemsediği iki şey: eksik bilgilerle harekete geçebilmek ve doğrudan C-seviyesi müşterilerle iletişim kurabilmek. Bilgisayar Bilimi diploması bir artı, giriş hakkı değil. Karp kendisi bu kritere en erken örnek—felsefe okumuş bir CEO, fizik, matematik ve felsefe okuyan FDE’lerden oluşan bir ekip kurdu.
İkinci kök, 2023 sonrası nesli model şirketleridir.
ChatGPT, 2022 yılının sonunda piyasaya sürüldükten sonra OpenAI, bir şeyin farkına vardı: model API'lerini belgelere asıp müşterilerin kendi başlarına entegre etmesini beklemek mümkün değildi. Müşteriler kullanmak istemiyordu değil, nasıl kullanacaklarını bilmiyordu—iş problemleri vardı ama ürün formatları yoktu. Bu nedenle OpenAI, Anthropic, Cohere, Scale, Glean, Sierra, Hebbia ve Decagon gibi şirketler, FDE'leri büyük ölçekli olarak istihdam etmeye başladı.
Bu FDE dalgası, Palantir'in işleyiş modelini öğreniyor—mühendisleri müşteri sahalarına göndererek bir iş akışını uçtan uca tamamlıyor. Ancak ürün taşıyıcısı tamamen farklı: Palantir dönemi FDE'si veri entegrasyonu ve UI özelleştirmesi yapıyor, yeni nesil FDE'ler ise Prompt tasarımı, Agent düzenlemesi, araç çağrısı ve iş akışları entegrasyonu yapıyor.
Pragmatic Engineer'in FDE ile ilgili makalesinde [13] bu yeni sürümü, "Claude'un gerçek, spesifik ve yüksek değerli sorunları çözebilmesi için işletmelere entegre edilmesi" olarak tanımlıyor—ifade ediliş biçimi, Palantir'in yıllar önceki yaklaşımıyla neredeyse aynı, sadece "veri" yerine "model" kullanılıyor.
Bu iki kökü birlikte incelediğinizde, net bir benzerlik ve fark kümesi görebilirsiniz.
Ortak nokta: Müşteriler yazılım değil, “sorunumu çözebilecek mühendis + araç kombinasyonu” satın alıyor. Bu durum, son otuz yılın kurumsal yazılım tarihinde istisnai. SAP, Oracle, Salesforce yazılımı kendileri satıyor—mühendisler, “müsterinin bu yazılımı kullanabilmesini sağlamak” amacıyla var olan destek kaynakları. Palantir tam tersi: Araçlar, “FDE’nin müşteride sorunu çözebilmesi” için var olan bir kuvvetlendirici. Yeni nesil model şirketler bu ters ilişkiyi miras alıyor—OpenAI, GPT-4 lisansını değil, “FDE’lerimizin GPT-4’ü kullanarak müşteriye müşteri hizmetlerini otomatikleştirmeyi sağlamasını” satıyor.
Fark: Palantir dönemi OPS entegrasyonuna odaklanıyor—ana vurgu veri entegrasyonu, ontoloji modellemesi ve erişim yönetimidir. Yeni nesil model yeteneklerinin uygulanmasına odaklanıyor—ana vurgu Prompt tasarımı, Agent düzenlemesi ve koruma optimizasyonudur. İlkisi sistem entegratörünün ilerlemiş bir versiyonu, ikincisi ürün mühendisinin uzantısı gibidir.
Son olarak ilginç bir gerçek: Palantir’in erken dönem FDE’leri sonrasında birçokları girişimci oldu ya da doğrudan yeni nesil model şirketlerine katıldı. Anthropic, OpenAI, Sierra, Hebbia’nın erken dönem ekiplerinde, bir dizi eski Palantir çalışanı sayılabilir. Bu tesadüf değil—FDE pozisyonu, bir kişinin ürün riski, müşteri riski ve mühendislik riskini aynı anda üstlenmesini zorunlu kılıyor; neredeyse bir girişimci eğitimi gibi. Yazar, Palantir’i gizli bir girişimci eğitim merkezi olarak görmeyi tercih eder: Burada sadece mühendisler değil, eksik bilgiler içinde bir şeyi sıfırdan birliğe taşımayı bilen insanlar yetiştirilir. İki kök, 2023’ten sonra birleşir.
Yerel FDE: Çözüm mimarıdan AI uygulama mühendisine
İki kökün birleşmesi çoğunlukla yurt dışında gerçekleşir. Yurt içinde FDE terimi uzun süre kullanılmamıştır, ancak bu terimle ilişkili iş içerikleri tamamen ortaya çıkmamıştır. Yurt içi FDE'yi anlamak için önce yerel iki öncülünü, ardından ABD versiyonuyla olan üç farklılığı net bir şekilde görmek gerekir.
İki yerel öncül
İlk önce bulut sağlayıcısının çözümler mimarıydı. Alibaba Cloud, Tencent Cloud ve Huawei Cloud, son on yılda müşterilere mimari anlatan, POC yazan, göçüm planları hazırlayan ve teslimata kadar işbirliği yapan tam bir Solution Architect (SA) ekibi yetiştirdi. Huawei'nin dahilinde projeleri müşterinin veri merkezine uygulamakla görevli özel bir "Teslimat Mühendisi" dizisi bile var. Bu sistem, FDE işlerinin %80'ini zaten yapıyor, ancak odak noktası hâlâ önsatış ve dağıtım üzerinde: Ürünün tam döngüdeki iyileştirme sorumluluğu SA'nın elinde değil; ihtiyaç değiştiğinde değişiklik sürecinden geçmek gerekiyor, model değiştirildiğinde ise merkezden planlama bekleniyor.
İkinci öncül, bir AI girişim şirketinde yeni ortaya çıkan bir dizi. MiniMax, BOSS Doğrudan İşte "AI Öncü Satış Çözüm Uzmanı" ilan ediyor; Moonshot, Zhipu, Tongyi ve Hunyuan gibi model şirketleri de benzer pozisyonları ilan ediyor. İsimler biraz farklı olsa da, iş tanımı içerikleri yüksek oranda benzer: Müşteri senaryolarını anlama, demo oluşturma, Prompt ayarlama, RAG çalıştırma, teslimat planları yazma ve müşteri mühendislik takımıyla上线'e kadar iş birliği yapma. Bu pozisyonlar, gerçek anlamda "ülkemizdeki FDE"lerdir.

Üç farklı toprak ve su durumu
Özel dağıtım + veri uyumluluğu, yalnızca model çağırma modelini bastırıyor. Yerel B türü müşteriler, verilerin sınırlar dışına çıkmaması, model ağırlıklarının kontrol edilebilirliği ve denetlenebilirlik taleplerini ABD pazarından çok daha yüksek seviyede tutuyor. Bir FDE projesinde, yalnızca API çağırarak Prompt çalıştırmak için harcanan çaba belki %30'u oluşturuyor; kalan %70'i modeli müşteri veri merkezine taşımak, yetkilendirme işlemini çalıştırmak, veri ortamına entegre olmak ve uyumluluk beyanını tamamlamak için harcanıyor.
Model yetenekleri hâlâ SOTA'ya yetişmeye çalışıyor ve kullanım alanı mühendislik katmanına daraldı. ABD'deki OpenAI ve Anthropic, model yeteneklerini doğrudan müşterilere sunabiliyor; ancak Çin'deki Tongyi, DouBao, Kimi, GLM ve DeepSeek'in yetenekleri arasındaki farklar o kadar belirgin değil. Müşterilerin karar verme kriterleri artık Agent düzenlemesi, RAG arama kalitesi, araç entegrasyonu ve Workflow tasarımı gibi mühendislik becerilerine odaklanıyor. Çin'de FDE'ler "modelim ne kadar güçlü" değil, "bu işi gerçekten çalıştırabilir miyim" üzerine rekabet ediyor.
B tarafının ödeme isteği ve fiyatlandırma ritmi ABD ile uyumlu değil. Palantir'in "önce FDE'yi yerleştirmek, ardından yüksek birimli abonelik ücreti almak" modeli doğrudan kopyalanamaz. Yerel müşterilerin bütçesi yıllık satın alımlara bağlıdır ve ödeme yapma eğilimi projeye dayalıdır; FDE'nin ticari modeli genellikle abonelik + özel lisans + proje teslimi karışımı şekildedir.
Benzersiz bir konum: Dahili FDE
Büyük şirketlerin birçok iç AI ekibi, FDE modelini kullanarak “iç müşterilere” hizmet vermeye başlamıştır. Alibaba Cloud PAI, mühendisleri Taobao’ya gönderirken, Tencent Hunyuan da benzer bir mekanizma ile WeChat ve reklam iş birliklerini desteklemektedir. JD’de “sektör uygulama mühendisi”, “AI uygulama mühendisi”, “akıllılaştırma iş uzmanı” gibi pozisyonlar yer almakta olup, bunlar temelde iç FDE’lerdir—modellerin yeteneklerini uçtan uca iş birliklerine taşımaktadır. Bu durum, büyük şirketlerin liderlerine yeni bir fikir sunmaktadır: birkaç iç FDE’nin iş birliklerinde sabitlenmesi, ilk demo’nun oluşturulması ve ROI verilerinin iş birlikleri liderlerine sunulması, on kez hizmet içi uyum toplantısı açmaktan daha hızlı şekilde departman duvarlarını ortadan kaldırır.
FDE için kim uygun, kim uygun değil
Yazar, önceki makalede olan “Süper Bireylere Mektup” [4]’te süper bireylerin beş motorunu anlatmıştı: güçlü merak, keşif ve yenilikçilik ruhu, güçlü özöğrenme becerisi, güçlü içsel motivasyon ve güçlü uygulama becerisi. Bu beş özellik, FDE için giriş biletidir, ancak hepsi değildir. FDE pozisyonu, bu beş motorun dışında çok spesifik ek özelliklere de sahiptir ve bazı kişilik tipleri açıkça uygun değildir. Yazar, çok sayıda iyi mühendisin FDE’ye geçtikten sonra uyum sorunları yaşadığını görmüştür; sorunlar çoğunlukla yeteneklerde değil, karakterde ve çalışma tercihlerindedir.
FDE için beş özellik
Satış ve iletişimden kaçınmayın. FDE'nin günlük işi kapalı kapılar ardında kod yazmak değil, müşterilerin CTO'ları, iş birim liderleri, satın alma ekibi, uyumluluk ve IT departmanlarıyla doğrudan iletişim kurmaktır. Tipik bir ritim: Müşteri CTO'su, demo sırasında sizi keser; FDE'nin tepkisi “Bir sonraki hafta yeniden geliriz” olmamalı, aksine hemen IDE'yi açıp Prompt'u değiştirip yeniden çalıştırmalıdır. “Müşteri burada, ben değiştiriyorum” FDE'nin normal halidir.
Bulanık alanın tadını çıkarın. FDE, net bir PRD yerine “AI ile bir şey yapmak istiyoruz” gibi bir ifade alır. Müşteri kendi kendine ne istediğini açıklayamaz; FDE, bu bulanık beklentiyi somut bir biçime dönüştürmek için onunla birlikte yol alır. Sadece net bir ihtiyaç olduğunda harekete geçebiliyorsanız, FDE her gün sizi endişelendirecektir.
Mühendislik becerisi güçlü ancak 10x gerektirmez. FDE, sizin şirketin en temiz kodu yazan veya en derin algoritmalarına sahip olan kişi olmanızı gerektirmez; gereken,端到端 çalışır hale getirmektir: ön uçta tıklanabilir bir sayfa oluşturmak, arka uçta çalışır bir hizmet kurmak, modeli iş veri kaynaklarına bağlamak. FDE dünyasında, “yaklaşık olarak yeterli” eksiklik değil, bir övünçtür.
Geri bildirimlerle geliştirilmeyi sever. FDE'nin işinde, müşterilerden "Bunu istemedim" diyerek geri gönderilmek ve yeniden yapmak sık görülür: Bugün sunduğunuz demo, yarın iş birimi tarafından "Bu benim istediğim şey değil" diye reddedilir; geçen hafta birleştiğiniz çözüm, bu hafta müşteri tarafından yeni bir yöneticiyle yeniden yapılandırılır. FDE için uygun olan kişi, bu geri bildirimleri yakıt olarak kullanır, tüm süreci sorumlu bir şekilde yürütür ve "İhtiyaçları açıkça belirtmeyenler" gibi nedenleri göstererek sorumluluğu reddetmez.
Model sınırlarına duyarlıdır. Bu, en teknik ve en gizli kuraldır. FDE, hangi görevlerin LLM için uygun olduğunu, hangilerinin olmadığını ve nasıl geri dönüş yapılacağını bilebilir — bu duyarlılık makalelerden değil, başarısız durumlarla kazanılır. Başarısız örnekler biriktiğinde, FDE model sınırları için kas hafızası geliştirir: hangi senaryoda RAG kullanılmalı, hangi senaryoda kural tabanlı yol izlenmeli, hangi senaryoda insan için mutlaka bir geri dönüş noktası sağlanmalı.
FDE için uygun olmayan dört grup
Kodun içinde saklanmayı seven sadece teknik biri. FDE, yaklaşık %50 zamanını kod yazmak yerine müşteri toplantıları, iç koordinasyon, ürün tartışmaları ve sözleşme ilerlemeleriyle geçiriyor. Eğer mutluluğunuz dört saat boyunca kimseyle kesintiye uğramadan kod yazmaksa, FDE sizi uzun süreli zihinsel tükenmişlik durumuna sokar.
OKR olmadan harekete geçemeyen kişiler. FDE'nin hedefleri performans tablonuzda değil, müşterilerinizde yer alır. Çalışma ilerlemesi, müşterilerinizin proje düğüm noktaları, model kapasitesindeki değişiklikler ve sahada kendi yargılarınız tarafından belirlenir. "Önce OKR olmalı, sonra ne yapacağımı bilmeliyim" alışkanlığına sahip olanlar bir tutunma noktası bulamaz.
İşlevsel geliştirici (FDE) pozisyonunda, eserlerden daha çok terfiyi ön planda tutanlar. FDE, büyük şirketlerdeki terfi sistemlerinde avantajlı değildir—müşteri memnuniyeti, proje kazanımı, yeniden kullanım oranı gibi göstergeler, kod miktarı ve canlıya alma sıklığına kıyasla terfi değerlendirmelerinde daha az etkilidir. Eğer iş motivasyonunuzda terfi birincil hedeftir, FDE iyi bir seçim değildir.
Ticari bağlamı reddeden kişiler. FDE, müşterilerinin kar-zarar durumunu, ROI'sini, satın alma süreçlerini ve uyumluluk gereksinimlerini anlamalıdır. Eğer para, sözleşme ve ticari mantık hakkında konuşmaktan doğal olarak kaçınıyorsanız, FDE işi sizi teknik ideallerinizi satıyormuş gibi hissettirebilir.
Kendinizi Kontrol Listesi
7 soru, her biri FDE'nin gerçek bir çalışma senaryosuna karşılık gelir. 5'ten fazlasına "evet" diyorsanız FDE'yi ciddiye alabilirsiniz, 3'ten azına "evet" diyorsanız dikkatli olmanızı öneririz.
Günlük zamanınızın %50'sini kod yazmaktan müşteri toplantılarına, mesajlara ve telefonlara aktarmak ister misiniz?
2. Müşteri size "Bu çalışmıyor, nedenini de tam olarak açıklayamıyorum" dediğinde, ilk tepkiniz merak mı, yoksa sinirlenme mi?
3. Kimse size PRD yazmadı, bir hafta içinde Claude Code ile bir müşteriye gösterilebilir prototip çalıştırabilir misiniz?
4. Aynı teslimat için müşteri 8 versiyon değiştirdi, siz hâlâ mekanik olarak uygulamak yerine yargı gücünüzü koruyabiliyor musunuz?
5. Model yanlış cevap verdiğinde ilk tepkiniz fallback tasarlamak mı, yoksa modelin başarısız olduğunu mı şikayet etmek mi?
6. Sözleşme imzalamak, rapor yazmak, müşteri onayını almak ve yasal uygunluk maddeleri için hukukla görüşmek ister misiniz?
7. Hızlı prototipleme ve hızlı başarısızlık kabul edebiliyor musunuz?
Beş özellik, dört tür ters görsel, yedi adet kendinizi test etme sorusu; sonunda aynı soru: Ürün duygusunu, mühendislik gücünüzü ve ticari yargılarınızı aynı iş akışında aynı anda geliştirmeye hazır mısınız?
Sonuç: Süper Bireyden Süper Pozisyona
Önceki makalede, "insan motoru" olarak adlandırdığım merak, keşif ruhu, kendi kendine öğrenme becerisi, içsel motivasyon ve pratik becerilerin büyük şirketlerde nasıl tam bir döngüyle uyandırıldığını tartıştım. Bu makalede ise başka bir konuya odaklanıyorum: pozisyon şekli. FDE, ismi, maaş aralığı, iş ilanı ve müşteri ödeme doğrulamasına sahip olan AI endüstriyel devriminin ilk yeni pozisyon şeklidir. Bu, "süper birey" kavramının eş anlamlısı değildir; bu yeniden yapılandırma dalgasında, soyuttan somuta doğru ilk gerçekleşen koordinattır.
FDE son nokta değil. Yazarın görüşüne göre, FDE yeni iş bölümü içinde adını ilk veren formdur. Ardından Forward Deployed PM, Forward Deployed Designer, Forward Deployed Researcher gibi, müşteri senaryolarıyla sıkıca ilişkili ve belirsiz alanlarda ürünün şekillenmesini gerektiren tüm meslekler, kendi “ön dağıtılmış” versiyonlarını ortaya çıkaracaktır. Görev isimleri değişecektir, ancak temel mantık aynı kalacaktır: Model yetenekleri önde ilerler, ürün formatı arkadan yetişmeye çalışır ve görev yapısı iş akışına göre yeniden bölünür.
Üç okuyucu grubu için her birine bir cümle bırakın.
Teknik kişilere: FDE, sizin şirketinizde en iyi kod yazan kişi olmanızı gerektirmez, ancak kod yazma zamanınızın yarısını müşterilere ayırmaya hazır olmanızı ister. Cevabınız “evet” ise, pazar penceresi hemen açıldı; ülkenin önde gelen model şirketleri, bulut sağlayıcıları ve büyük şirketlerin dahili AI ekipleri istihdam hızlandırıyor. Cevabınız “hayır” ise, sorun değil; yeni iş bölümü içinde sizin için başka pozisyonlar ortaya çıkacaktır.
HR ve OD için: "İsim ile gerçekliğin ayrılması" konusunda dikkatli olun. Şirketinizde zaten bir dizi FDE çalışıyor olabilir, ancak pozisyon kodları "Çözüm Uzmanı", "Sektör Mimarısı", "AI Uygulama Mühendisi" olarak kayıtlı. Bunları tanımlayın, yeniden sınıflandırın ve iş içerikleriyle uyumlu bir gelişim yolu sağlayın; bu, sıfırdan yeni personel almaktan daha verimlidir.
Yöneticilere: FDE modeli yalnızca dışa yönelik olmakla kalmaz, içe yönelik de olabilir. Şirket içine birkaç “iç FDE” yerleştirip, model ekibinin yeteneklerini doğrudan iş süreçlerine entegre etmek, yeni bir AI departmanı kurup on kez arapça ekip uyum toplantısı yapmaktan çok daha verimli olabilir. Departman duvarları, organizasyon tasarımıyla değil, çalışır hale getirilmiş bir demo ile ortadan kalkar.
AI çağındaki mesleki dönüşüm başlamıştır, FDE ilk sinyaldir ve bize model yeteneklerindeki değişim hızının, yeni pozisyonların ortaya çıkmasına neden olacak kadar hızlı olduğunu söylüyor. Yazar, okuyucuya şu spesifik soruyu bırakmak istiyor: Üç yıl sonra şirketinizin organizasyon şemasına üç yeni pozisyon eklendiyse, bunların hangi üçü olduğunu tahmin edersiniz? Bu soruyu düşünmek, bu makaleyi okumaktan daha faydalıdır.
👦🏻 Yazar: Henry (DeerFlow Ekibi) [1]
