# İyi bir Forward Deployed Engineer nasıl olmalı?

Müşteri problemini çalışan, ölçülen ve devredilebilen bir çözüme dönüştürmek: FDE yetkinlikleri, değerlendirme ve gelişim için kaynaklı bir rehber.

Watt2Work · 2026-11-03 · 9 dakika okuma
Canonical: https://watt2work.com/tr/blog/iyi-bir-forward-deployed-engineer/
Language: tr

Bir bakım yöneticisi “Bize bir yapay zekâ asistanı lazım” dediğinde mühendislik işi henüz tanımlanmış değildir. Asıl ihtiyaç geçmiş kayıtları bulmak, yanlış ekipman eşleşmesini önlemek veya rapor hazırlama süresini azaltmak olabilir. İyi bir Forward Deployed Engineer, bu belirsizliği müşterisiyle birlikte çalışılabilir bir probleme dönüştürür.

> Güçlü bir FDE’nin başarısı; doğru problemi seçmesi, çözümü geliştirmesi, gerçek kullanımda sonucunu ölçmesi ve müşterinin sürdürebileceği biçimde devretmesiyle görünür olur.

3 Kasım 2026 tarihli FDE yetkinlik raporundan blog için uyarlanmıştır. İşveren ilanları kurumların beklentilerini gösterir. Bu yazıdaki değerlendirme ve gelişim önerileri, doğrulanmış bir sektör standardı veya Watt2Work’ün tamamladığı müşteri işleri değildir.

## Müşterinin işine yakın, teslimin tamamından sorumlu

Forward deployed, mühendisin müşterinin iş akışına ve çalışma koşullarına yakın çalışmasını anlatır. Bu bazı projelerde sahada bulunmayı, bazılarında düzenli ortak geliştirmeyi gerektirir. Rolün özü; problem, kod, veri, kullanıcı ve işletim arasında teknik sahiplik kurmaktır.

Komşu rollerin tipik ağırlık merkezleri

| Rol | Başlıca sorumluluk |
| --- | --- |
| Ürün yazılım mühendisi | Birçok müşterinin kullandığı ürünün teknik kalitesi ve gelişimi |
| Çözüm mimarı | İhtiyaç ve kısıtları savunulabilir bir mimariye çevirmek |
| Satış mühendisi | Satın alma öncesi teknik uygunluğu göstermek |
| Uygulama mühendisi | Tanımlı kurulum ve entegrasyon kapsamını teslim etmek |
| Müşteri başarı yöneticisi | Benimsenme, ilişki ve müşteri sürekliliği |
| Forward Deployed Engineer | Müşteri problemini çalışan, kullanılan, ölçülen ve devredilen çözüme taşımak |

Bu sınırlar şirketten şirkete değişir. Databricks’in Haziran 2026 duyurusu FDE yaklaşımını Professional Services içinde ele alır; Vercel’in ilanı da bu organizasyonda yer alır. Aday değerlendirmesinde ekip adından çok gerçek uygulama ve teslim sorumluluğu sorulmalıdır. [Databricks · Forward Deployed Engineering: Delivering Business Outcomes with AI](https://www.databricks.com/blog/forward-deployed-engineering-delivering-business-outcomes-ai), [Vercel · Forward Deployed Engineer](https://job-boards.greenhouse.io/vercel/jobs/5752684004).

## Güncel beklenti: üretim kalitesi ve müşteri sonucu

OpenAI’nin rol tanımı, geliştirmeyi üretimde benimsenme ve iş akışı etkisiyle birlikte ele alıyor. Anthropic’in Staff FDE ilanı, mimari yönlendirme ve müşterinin işletebileceği sistemlerin devrini vurguluyor. Palantir açık uçlu problemleri ayrıştırma ve teknik kararların kullanıcı üzerindeki etkisini düşünme beklentisini öne çıkarıyor. [OpenAI · Forward Deployed Engineer](https://openai.com/careers/forward-deployed-engineer-%28fde%29-sf-san-francisco/), [Anthropic · Staff Forward Deployed Engineer](https://job-boards.greenhouse.io/anthropic/jobs/5449229008), [Palantir · Forward Deployed Software Engineer](https://jobs.lever.co/palantir/a2e9ab0f-4dd1-4744-92b9-edc7ae393c58).

Bu kaynaklardan çıkardığımız sonuç: güçlü aday bir alanda derinleşmeli, müşteri ortamında uçtan uca çalışabilecek kadar da geniş düşünmelidir. Her teknolojide uzmanlık beklemek yerine kendi sınırını bilmesi ve doğru uzmanı zamanında işe katması aranmalıdır.

Anthropic’in 2 Ekim 2026 tarihli Claude Frontier Academy duyurusu, simüle edilmiş kurumsal uygulama, uygulamalı sınama ve gerçek projeyle çalışma dönemini bir araya getiriyor. Programın kullandığı Frontier Deployed Engineer unvanı, genel Forward Deployed Engineer rolüyle birebir standart eşdeğerlik anlamına gelmez. Bu örnekler nitel işveren sinyalleridir; sektörün ücretini veya büyümesini ölçen bir araştırma değildir. [Anthropic · Claude Frontier Academy](https://www.anthropic.com/news/claude-frontier-academy).

## Güçlü bir FDE’de aranacak 11 yetkinlik

- **Problemi tanımlamak:** İşi kimin, ne sıklıkta ve hangi veriyle yaptığını gözler. Mevcut süreç, başlangıç ölçümü, veri sahibi ve kapsam dışıyla birlikte bir problem tanımı yazar. “Chatbot yapalım” talebini doğrudan özellik listesine dönüştürmez.
- **Alanı öğrenmek:** Terimleri ve istisnaları konu uzmanıyla öğrenir. Ölçüm, hesaplama ve yorumu ayırır. İlk varsayımının hangi müşteri gözlemiyle değiştiğini açıklayabilir.
- **Kod yazmak ve hata ayıklamak:** Kendi yazdığı veya AI aracıyla ürettiği kodu açıklar. İstemci, uygulama, veri ve dış servis katmanlarını ayırarak hatayı daraltır. Çalışan örneğin yanında anlamlı test ve hata teşhisi kanıtı sunar.
- **Veri ve entegrasyonu sahiplenmek:** Eksik, yinelenmiş ve gecikmiş kayıtları; birim, zaman dilimi ve kimlik farklılıklarını yönetir. Bağlantının kurulmasıyla verinin doğru yorumlanmasını ayrı sınar.
- **Uygun mimariyi seçmek:** Kural tabanlı işlem, klasik yazılım, model, kaynak destekli LLM ve araç kullanan ajan seçeneklerini karşılaştırır. Kalite, gecikme, bakım ve maliyet gerekçesiyle karar verir.
- **Kaliteyi değerlendirmek:** Temsilî görevler, başarısızlık örnekleri ve geliştirmeden ayrı kabul kümesi hazırlar. Model veya veri değiştiğinde eski başarının korunduğunu sınar. İnsan değerlendirmesiyle ölçümün uyumunu kontrol eder.
- **Sistemi işletilebilir kılmak:** İzleme, sürümleme, yeniden deneme, geri alma ve kurtarmayı tasarlar. Kesinti sırasında kimin ne yapacağı bellidir. Hizmet hedefini kullanıcının ihtiyacıyla ilişkilendirir.
- **Yetki ve güvenliği uygulamak:** Müşteri ayrımı, en az yetki, sır yönetimi ve kayıtları uygulama katmanında kurar. Yetkisi kaldırılmış bir kullanıcının önbellekten belgeye erişemediğini de test eder.
- **Kapsamı ve maliyeti yönetmek:** Veri erişimi, altyapı, uzman zamanı ve satın alma bağımlılıklarının sahiplerini belirler. İnsan incelemesi, başarısız denemeler ve işletim emeği maliyete dahildir. Süre kazanımını gerçekleşen nakit tasarrufundan ayırır.
- **Anlaşılır ve dürüst iletişim kurmak:** Bildiğini, varsaydığını ve henüz ölçmediğini açıkça söyler. Gecikmenin etkisini ve seçenekleri zamanında paylaşır. Karar notlarına sorumlu ve tarih ekler.
- **Müşteriyi bağımsızlaştırmak:** Kurulum ve olağan değişiklikleri başka birinin yapabildiğini gösterir. Tekrarlanan ihtiyaçları uygun ortak bileşenlere dönüştürür. Teslim, aynı mühendisin sürekli yanında bulunmasına bağımlı kalmaz.

Bunları değerlendirmek için en yararlı kanıtlar; problem tanımı, çalışan kod, veri kalite kontrolü, başarısız örnek analizi, karar kaydı ve devir provasıdır. Sertifika ve deneyim yılı bu kanıtları yorumlamaya yardımcı olur. Hizmet hedefleri için Google’ın SLO rehberi, kullanıcı ihtiyacından hareket eden bir yaklaşım sunar. [Google SRE · Implementing SLOs](https://sre.google/workbook/implementing-slos/).

## AI araçlarını kullanmak, üretilen işin sorumluluğunu almak

AI araçlarıyla hızlı geliştirmek değerlidir; FDE yine de çıkan kodu incelemeli, yanlış davranışı teşhis etmeli ve tasarımını savunabilmelidir. Anthropic’in ajan rehberi, önceden tanımlanmış iş akışlarıyla modelin dinamik yönettiği ajanları ayırır. İhtiyacı karşılayan en basit yaklaşım iyi bir başlangıçtır; bu 2024 rehberi değişen araç listesinden çok mimari ilkeleri için kullanılmalıdır. [Anthropic · Building effective agents](https://www.anthropic.com/research/building-effective-agents).

Doğru kaynakları, araç tanımlarını ve talimatları modele ulaştırmak ayrı bir mühendislik işidir. Bağlam yönetimi; kaynak sürümü, konuşma geçmişi, maliyet ve erişim sınırlarıyla birlikte düşünülmelidir. Çalıştırma ortamı ve yürütme yaşam döngüsü de model çağrısından ayrı sorumluluklar taşır. [Anthropic · Effective context engineering for AI agents](https://www.anthropic.com/research/effective-context-engineering-for-ai-agents), [Anthropic · Scaling Managed Agents](https://www.anthropic.com/research/managed-agents).

Güvenlik yalnızca sistem talimatına bırakılamaz. Modelin bir aracı çağırmak istemesi, o işlemi yapma yetkisi olduğu anlamına gelmez. OWASP’nin LLM ve ajan riskleri; araç izinleri, veri sızıntısı ve aşırı yetkiyi inceler. MCP kullanıldığında da bağlantının çalışmasının yanında kimlik, onay ve erişim kapsamı sınanmalıdır. [OWASP · Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/), [OWASP · Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/), [OWASP · Top 10 for Agentic Applications for 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/), [Model Context Protocol · Security Best Practices](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices).

## Teslimi yedi görünür çıktıyla takip etmek

- **Keşif:** Problem, kullanıcı, mevcut süreç ve başlangıç ölçümü.
- **Veri incelemesi:** Kaynaklar, veri sözlüğü, erişim hakları ve kalite sorunları.
- **Kapsam ve tasarım:** Mimari, kabul ölçütleri, bağımlılıklar ve ilk teslim sınırı.
- **İlk çalışan sürüm:** Dar kapsamlı uçtan uca iş akışı ve kullanıcı geri bildirimi.
- **Pilot değerlendirme:** Temsilî görevler, hata analizi, maliyet ve ilerleme koşulları.
- **Kontrollü kullanım:** İzleme, sınırlı açılış, kurtarma planı ve kullanım kanıtı.
- **Devir:** İşletim sorumlusu, eğitim, kabul kaydı ve tekrar kullanılabilir bilgi.

Veri sahibi, kabul kararı veya işletim sorumlusu eksikse kalan iş açıkça yazılmalıdır. NIST’in Generative AI Profile belgesi, değerlendirmeyi yaşam döngüsü boyunca ele almak için gönüllü bir çerçevedir; tek başına sertifika ya da uygunluk sonucu değildir. [NIST AI 600-1 · Generative Artificial Intelligence Profile](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence).

## Başarıyı demo sayısıyla ölçmeyin

Güçlü bir değerlendirme; kaliteyi, gerçek kullanımı, maliyeti ve devir sonrası bağımsızlığı birlikte görür. Hedefler, başlangıç düzeyi ve işin riski görüldükten sonra belirlenir.

Proje için birlikte seçilecek başarı göstergeleri

| Gösterge | Ne ölçülmeli? |
| --- | --- |
| İlk kabul edilen değere kadar süre | Başlangıçtan kullanıcının kabul ettiği ilk işe yarar çıktıya kadar süre; erişim gecikmeleri ayrıca |
| Görev başarısı ve kritik hata | Kapsamdaki tüm denemeler; dil, görev türü ve risk düzeyine göre hata dağılımı |
| Benimsenme | Sistemle tamamlanan uygun işler; yalnızca giriş yapan kullanıcı sayısı değil |
| İşlem süresi | İnceleme ve düzeltme dahil, benzer görevlerin önceki ve yeni süreleri |
| Kabul edilmiş çıktı başına maliyet | Model, altyapı, insan incelemesi, işletim ve başarısız denemeler |
| Devir ve tekrar kullanım | Müşterinin bağımsız yaptığı olağan değişiklikler; sonraki işte gerçekten kullanılan bileşenler |

İyi bir ortalama, nadir fakat önemli bir hatayı gizleyebilir. Değerlendirme farklı görev türlerini, tekrar çalıştırmaları ve sürüm değişikliklerini içermelidir. Aynı dönemdeki personel veya süreç değişikliği de sonucu etkileyebilir; birlikte değişen iki ölçü tek başına nedensellik göstermez. [Anthropic · Demystifying evals for AI agents](https://www.anthropic.com/research/demystifying-evals-for-ai-agents).

## Adayı işin kendisine benzeyen örneklerle değerlendirmek

Önerilen değerlendirme üç parçalıdır: eksik tanımlı bir problemle keşif görüşmesi, küçük bir uygulama ve hata incelemesi, ardından mimari ve devir tartışması. Başlangıç tasarımı olarak yaklaşık 40, 90 ve 45 dakika düşünülebilir. Bunlar doğrulanmış işe alım süreleri değildir.

- **Problemi nasıl değiştirdi?:** Müşterinin ilk istediği çözümden hangi kanıt üzerine vazgeçtiğini sorun.
- **Hatanın nedenini nasıl buldu?:** Üretimdeki veya gerçekçi bir örnekteki arızayı hangi adımlarla daralttığını inceleyin.
- **Yetki geri alınınca ne olur?:** Veri, önbellek ve araç erişiminin nasıl etkilendiğini göstermesini isteyin.
- **Müşteri onsuz ne yapabilir?:** Doküman tesliminin yanında kurulumu ve olağan değişikliği başka birinin denediğine bakın.

AI araçları kullanılabilir; aday üretilen işi açıklamalıdır. Şirketin gerçek müşteri işini ücretsiz tamamlaması beklenmemeli, uzun uygulamalar ücretli ve açık kapsamlı olmalıdır. Kanıt bulunmayan alanı yetersizlikle karıştırmayın. Değerlendiriciler aynı davranış ölçütlerini kullanmalı; ağırlıklar göreve göre belirlenmelidir. Tek bir genel FDE puanı, güvenlik veya mühendislik açığını gizlememelidir.

## Kıdem, çözülebilen belirsizliğin kapsamıyla artar

Önerilen sorumluluk düzeyleri; şirket unvan standardı değildir

| Düzey | Beklenen sorumluluk |
| --- | --- |
| Gelişen FDE | Gözetimle tanımlı bir entegrasyon veya değerlendirme akışını tamamlama |
| Bağımsız FDE | Tek kullanım senaryosunun keşif, uygulama, pilot ve devrini yürütme |
| Senior FDE | Birden çok bağımlılığı, zor kapsam kararlarını ve paydaşları yönetme; mentorluk |
| Staff / Lead FDE | Hesap veya ekipler arasında mimari yön, tekrar kullanım ve kalite sorumluluğu |

Deneyim yılı bağlam sağlar; belirleyici soru kişinin hangi belirsizliği artık bağımsız çözebildiğidir. Anthropic’in Staff ilanında birden çok iş kolu ve diğer FDE’lerin tasarımları üzerinde mimari sorumluluk tarif edilmesi bu ayrımın bir örneğidir. [Anthropic · Staff Forward Deployed Engineer](https://job-boards.greenhouse.io/anthropic/jobs/5449229008).

## İlk 90 günde bir teslim hikâyesi oluşturmak

Bu gelişim planı yazılım temeli bulunan biri içindir. Sıfırdan başlayan bir kişinin 90 günde bağımsız üretim yetkinliği kazanacağını vaat etmez. Müşteri ve veri izinleri takvimi değiştirebilir.

- **İlk 30 gün: problemi ve ilk sürümü kur:** Bir alan ve dar iş akışı seç. Süreci gözle, başlangıcı ölç, veri sözlüğünü hazırla ve uçtan uca küçük bir sürüm geliştir. Gerçek veri yoksa açık veya sentetik veri kullandığını belirt.
- **31–60. gün: başarısızlığı görünür yap:** İstisnaları, yetki sınırlarını, izlemeyi ve sürüm değişimini test et. Alternatif yaklaşımı aynı görevlerde karşılaştır. Kalite, gecikme ve maliyeti ölç; geri alma veya kurtarma provası yap.
- **61–90. gün: değerlendir ve devret:** İzinli kullanıcı değerlendirmesi yap. Başka bir mühendis kurulumu ve olağan değişikliği denesin. Bilinen sınırları ve kalan bağımlılıkları yaz. Gerçek saha izni yoksa bunu saha doğrulaması olarak anlatma.

Portföyde problem, çalışan örnek, izin verilen teknik inceleme, ölçüm ve bir başarısızlık analizi birlikte bulunmalıdır. Gizli müşteri kaydı yerine temsilî örnek kullanıldığında bu durum açıkça etiketlenmelidir.

## Enerji ve endüstride kanıtın sınırını bilmek

Endüstriyel FDE, ekipman hiyerarşisini, birimleri, zaman damgalarını ve bakım kayıtlarının sınırlarını öğrenmelidir. Bir sinyali okuyabilmek, fiziksel anlamını doğru yorumlamak değildir. NIST SP 800-82 Rev. 3, OT güvenliğini performans, güvenilirlik ve fiziksel güvenlikle birlikte ele alır. Kaynak kesim tarihinde Rev. 4 ilk kamu taslağı da bulunuyordu; taslak kesinleşmiş sürüm değildir. [NIST SP 800-82 Rev. 3 · Guide to Operational Technology Security](https://csrc.nist.gov/pubs/sp/800/82/r3/final).

> Örnek senaryo: bakım mühendisi, izinli geçmiş kayıtları ve teknik dokümanları kullanarak kaynaklı bir inceleme ve rapor taslağı hazırlar. Bu açıklayıcı örnek gerçek tesis verisi veya tamamlanmış pilot içermez. Önerilen başlangıç yalnızca izinli okumadır; fiziksel işletme kararı yetkili insanlarda kalır.

Böyle bir işte ekipman kimliği ve kaynak sürümü eşleştirilir; hesaplamalar test edilebilir kodda tutulur. Eksik kayıt, çelişkili not, eski doküman ve yanlış ekipman gibi durumlar sınanır. Model metni fiziksel hesaplama otoritesine veya kesin arıza teşhisine dönüşmemelidir.

Her kanıt, yalnızca sınandığı kapsamı destekler

| Kanıt | Gösterebileceği şey |
| --- | --- |
| Sentetik test | Tanımlanmış yazılım senaryosundaki davranış |
| Geçmiş kaydın yeniden oynatılması | Seçilen tarihsel koşullardaki davranış |
| Uzman incelemesi | İncelenen çıktının alan açısından uygunluğu |
| İzinli saha pilotu | Belirli saha, süre ve kullanım kapsamındaki gözlem |
| Operasyonel kabul | Yetkili tarafların tanımlı kapsamı kabul etmesi |

Sentetik başarı gerçek tesis başarısı değildir. Bir sahadaki kabul başka tesislere otomatik genelleme sağlamaz; kontrol yetkisi de vermez. Watt2Work açısından bu ayrım, ölçülen değer, hesaplanan sonuç ve yorumu ayrı göstermenin temelidir.

## İyi FDE’nin çalışabileceği koşulları kurmak

Kurum; karar verebilen iş sahibini, teknik muhatabı, veri erişimini ve konu uzmanı zamanını sağlamalıdır. FDE teknik teslimi sahiplenir; alan uzmanı teknik yorumları, veri sorumlusu erişimi, iş sahibi ise iş kabulünü değerlendirir. Aynı kişiden bütün uzmanlıkları ve karar yetkilerini üstlenmesi beklenmemelidir.

Kapasite planına geliştirme, müşteri görüşmesi, dokümantasyon, seyahat ve destek birlikte girer. Tekrarlanan müşteri ihtiyaçları, yeniden üretilebilir örnek ve etki bilgisiyle ürün ekibine taşınmalıdır. Her müşteri isteğinin ortak ürüne girmesi gerekmez; kararın gerekçesi görünür kalmalıdır.

Bir FDE’yle çalışmayı değerlendirirken son tesliminden bir örnek isteyin: hangi problemi seçti, ne geliştirdi, neyin çalışmadığını nasıl gördü ve müşteri sistemi onsuz nasıl sürdürüyor? Bu sorulara verilen somut yanıtlar, rolün niteliğini görünür kılar.

## Kaynaklar

Kaynak kesim ve erişim tarihi: 3 Kasım 2026. Tarihsiz ilanların erişim tarihi, yayın tarihi değildir; ilanlar sonradan değişebilir. Şirket duyuruları bağımsız başarı kanıtı sayılmamıştır. Teknik rehberler farklı tarihlere aittir; tümü yeni bir 2026 yayını olarak sunulmamaktadır.

1. [Palantir · Forward Deployed Software Engineer](https://jobs.lever.co/palantir/a2e9ab0f-4dd1-4744-92b9-edc7ae393c58)
2. [OpenAI · Forward Deployed Engineer](https://openai.com/careers/forward-deployed-engineer-%28fde%29-sf-san-francisco/)
3. [Anthropic · Staff Forward Deployed Engineer](https://job-boards.greenhouse.io/anthropic/jobs/5449229008)
4. [Vercel · Forward Deployed Engineer](https://job-boards.greenhouse.io/vercel/jobs/5752684004)
5. [Databricks · Forward Deployed Engineering: Delivering Business Outcomes with AI](https://www.databricks.com/blog/forward-deployed-engineering-delivering-business-outcomes-ai)
6. [Anthropic · Claude Frontier Academy](https://www.anthropic.com/news/claude-frontier-academy)
7. [Anthropic · Building effective agents](https://www.anthropic.com/research/building-effective-agents)
8. [Anthropic · Demystifying evals for AI agents](https://www.anthropic.com/research/demystifying-evals-for-ai-agents)
9. [Anthropic · Effective context engineering for AI agents](https://www.anthropic.com/research/effective-context-engineering-for-ai-agents)
10. [Anthropic · Scaling Managed Agents](https://www.anthropic.com/research/managed-agents)
11. [OWASP · Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/)
12. [OWASP · Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)
13. [OWASP · Top 10 for Agentic Applications for 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/)
14. [Model Context Protocol · Security Best Practices](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices)
15. [NIST AI 600-1 · Generative Artificial Intelligence Profile](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence)
16. [Google SRE · Implementing SLOs](https://sre.google/workbook/implementing-slos/)
17. [NIST SP 800-82 Rev. 3 · Guide to Operational Technology Security](https://csrc.nist.gov/pubs/sp/800/82/r3/final)