FDE: Perbatasan Baru dalam Peran Rekayasa yang Didorong oleh AI

Dalam sebulan terakhir, saya bertemu empat teman yang bersiap berpindah karier—frontend developer, solusi arsitek, produk manajer, dan insinyur algoritma tradisional—dengan latar belakang, usia, dan kota yang berbeda, tetapi semuanya bertanya tentang singkatan Inggris yang sama: Apakah FDE [2] layak untuk saya?

FDE, singkatan dari Forward Deployed Engineer [2]. Dua tahun lalu, ini masih merupakan istilah gaul di kalangan Palantir, tetapi kini telah diam-diam berubah menjadi kalimat pembuka perekrut, posisi yang sering muncul dalam lowongan kerja, serta salah satu kandidat jawaban di media sosial untuk "posisi paling berharga di era AI". OpenAI pada Mei 2026 secara langsung mendirikan Deployment Company [3] dengan nama ini, dengan investasi awal 4 miliar dolar AS, dan secara jelas menyatakan tujuan untuk mengirim insinyur ke lokasi klien, masuk ke dalam alur kerja klien; tim Applied AI dari Anthropic juga sedang merekrut FDE secara simultan di empat zona waktu. Peristiwa ini, dari istilah gaul internal menjadi kata yang eksplisit, hanya memakan waktu sedikit lebih dari satu tahun.

Artikel sebelumnya penulis, "Untuk Individu Super" [4], membahas "mesin manusia"—rasa ingin tahu, belajar mandiri, motivasi diri, dan kemampuan praktis—bagaimana hal-hal ini dirangsang dalam Closed-loop yang utuh. Namun, manusia tidak mengambang; manusia harus ditangkap oleh sistem koordinat posisi yang konkret. Jika individu super adalah "bahan baku" hubungan produksi di era AI, maka FDE adalah bentuk posisi paling nyata yang muncul di pasar selama tahun ini.

Menurut penulis, FDE tidak berada di kotak konsultasi, juga tidak di kotak outsourching. FDE paling dekat dengan individu super—perbedaannya hanya terletak pada fakta bahwa FDE adalah individu super yang terorganisasi di celah antara "perusahaan model × klien".

Apakah kamu tahu — dari mana asal kata Forward Deployed? Kata ini awalnya berasal dari istilah militer AS, Forward Deployed Forces, yang merujuk pada pasukan yang ditempatkan di luar negeri atau garis depan untuk merespons secara cepat, berbeda dengan pasukan yang tetap berada di basis utama di tanah air. Palantir memperkenalkan istilah ini ke industri perangkat lunak pada akhir 2000-an untuk menggambarkan model kerja “mengirim insinyur keluar dari kantor pusat dan tinggal di lokasi klien”, bahkan tim internal pun dinamai menggunakan fonetik militer, yaitu Delta dan Echo. Sekarang, istilah ini diambil kembali oleh OpenAI dan Anthropic, bukan kebetulan — inti dari mengirim insinyur ke garis depan belum pernah berubah.

Tiga keraguan spesifik yang baru-baru ini ditanyakan oleh keempat teman saya adalah:

Apakah FDE adalah konsultan yang mengenakan pakaian AI? Di mana batasnya dengan konsultasi tradisional?

Apakah FDE adalah outsourcing perangkat lunak yang lebih tinggi? Apa perbedaannya dengan pekerjaan pihak ketiga yang sedang saya lakukan sekarang?

- Apakah saya cocok untuk FDE? Jenis orang seperti apa yang akan diperbesar oleh posisi ini, dan jenis orang seperti apa yang akan hancur?

Sikap penulis adalah optimis dengan hati-hati: FDE memang benar-benar tumbuh, tetapi jauh dari menjadi jalan keluar transformasi bagi semua orang. Lebih penting untuk menjelaskannya dengan jelas daripada membuatnya terdengar ramai.

Jika hanya bisa memilih satu hal untuk menandai titik waktu FDE kembali muncul dalam siklus ini, penulis akan memilih 11 Mei 2026—hari ketika OpenAI mengumumkan pendirian Deployment Company [5], di mana COO Brad Lightcap meninggalkan jalur bisnis sebelumnya dan beralih ke posisi special projects yang langsung melapor ke Sam Altman, bertanggung jawab penuh atas hal ini. Pada minggu yang sama, OpenAI mengakuisisi perusahaan konsultan AI Inggris, Tomoro, secara sekaligus menambahkan 150 Forward Deployed Engineer dan Deployment Specialist ke perusahaan baru tersebut.

Perlu dicatat bahwa halaman rekrutmen OpenAI saat ini sedang membuka lebih dari selusin posisi FDE: di San Francisco, New York, Washington, serta berbagai arah vertikal seperti Life Sciences, Semiconductor, dan Gov, bahkan posisi recruiter FDE [6] itu sendiri sedang dibuka. Para analis memperkirakan tim ini akan berkembang menjadi 2.000–4.000 orang dalam tiga tahun. Ini bukan skala kelompok penelitian, ini adalah pasukan resmi.

Anthropic melakukan tindakan yang hampir mirip. Posisi Forward Deployed Engineer di bawah tim Applied AI [7] dibuka secara bersamaan di enam lokasi: Boston, New York, Seattle, San Francisco, Washington, dan London, dengan persyaratan perjalanan ke lokasi klien sebesar 25%–50%. Salah satu contoh yang baru-baru ini sering dikutip adalah perusahaan fintech FIS—dalam pengumumannya, mereka secara langsung menyatakan: “Tim Applied AI dan forward-deployed engineers dari Anthropic telah terintegrasi ke dalam FIS untuk bersama-sama merancang Financial Crimes AI Agent serta mentransfer pengetahuan kepada FIS agar dapat secara mandiri mengembangkan lebih banyak agent di masa depan.”

Kalimat ini menyembunyikan gambaran sebenarnya dari pekerjaan FDE. Bukanlah arsitek pra-penjualan, bukan SDR, dan bukan pula evangelis yang datang untuk melatih pelanggan. Ia adalah insinyur yang membawa model dan tinggal di dalam repositori kode pelanggan. Brad Lightcap sendiri mengatakannya lebih jelas: “Pelanggan kami memberi tahu kami bahwa mereka membutuhkan kemampuan untuk berpindah dari pilot ke produksi. Deployment Company adalah dengan menempatkan insinyur kami ke dalam tim mereka, memberi sumber daya yang cukup untuk menyelesaikan pengiriman.”

Gambarkan hal ini dalam sebuah gambar, hubungan ketiga pihak akan menjadi sangat jelas:

Perhatikan dua garis paling informatif dalam gambar ini, yaitu umpan balik yang dikirimkan FDE ke kedua arah. Ke arah pelanggan, FDE tidak menjual model sebagai SaaS, tetapi menggabungkan data, izin, kepatuhan, dan sistem internal pelanggan menjadi satu saluran yang dapat menjalankan model; ke arah perusahaan model, FDE membawa kembali masalah nyata pelanggan dan sampel kegagalan ke tim produk dan penelitian, memengaruhi roadmap—pola tool calling yang terus-menerus gagal bisa menjadi abstraksi bawaan berikutnya di SDK.

Inilah mengapa FDE di putaran ini secara bersamaan diaktifkan kembali oleh dua perusahaan model terkemuka, dan bukan sekadar "kita juga ingin belajar dari Palantir untuk melakukan konsultasi." FDE adalah perangkat pengumpulan sinyal bagi perusahaan model—keluhan pelanggan paling padat di garis depan harus diambil langsung oleh orang mereka sendiri, karena permintaan yang diterjemahkan oleh mitra selalu terasa kurang langsung. Anthropic mengambil jalur hibrida: mengelola FDE secara mandiri sekaligus membangun jaringan joint venture dengan perusahaan konsultasi dan raksasa PE. Satu pendekatan lebih mandiri, yang lain lebih berfokus pada ekosistem, tetapi intinya sama: perusahaan model tidak lagi hanya menjadi penyedia API, tetapi harus mengirim insinyur langsung ke dalam produk pelanggan.

Pertanyaan berikutnya yang akan dijawab adalah dua pertanyaan paling umum tentang perbatasan antara FDE dan konsultasi tradisional (seperti McKinsey, Accenture), serta apakah itu sama dengan outsourcing perangkat lunak yang kita kenal.

Banyak orang yang pertama kali mendengar deskripsi pekerjaan FDE, reaksi pertama mereka adalah: “Bukankah ini versi baru McKinsey, Accenture?”

Saya memahami asosiasi ini. Mengenakan jas, berkunjung ke lokasi klien, duduk di ruang rapat klien untuk menggambar di papan putih, dan menyelaraskan dengan eksekutif tingkat C—secara visual, FDE dan konsultan memang terlihat mirip. Namun, sekali Anda melihat lebih dalam, pola kerja keduanya sama sekali berbeda. Konsultan menjual batasan proses, sementara FDE menjual batasan model.

Letakkan keduanya berdampingan dalam satu tabel, perbedaannya langsung terlihat.

Baris yang paling layak untuk dihentikan sejenak di tabel ini adalah "Penyusutan Aset".

Logika paling menguntungkan dalam konsultasi tradisional adalah pemanfaatan ulang aset—satu solusi untuk sebuah bank dapat dimodifikasi sedikit dan dijual lagi ke bank berikutnya; satu playbook digital untuk industri ritel dapat diterapkan berulang-ulang kepada tiga puluh klien. Ini adalah model ekonomi dasar yang mendasari pertumbuhan Accenture, Deloitte, dan McKinsey Digital selama tiga dekade terakhir.

FDE tidak memiliki aset semacam ini. Kemampuan model masih bergerak cepat—hari ini masih memerlukan rantai Prompt yang dirancang secara cermat, tetapi model versi berikutnya mungkin hanya perlu satu kalimat untuk menyelesaikannya. “Pengendapan metodologi” dalam konsultasi akan cepat kehilangan nilainya di hadapan kecepatan ini. Oleh karena itu, FDE tidak bisa menggunakan model pemanfaatan ulang aset, tetapi harus menjalankan ulang seluruh siklus tertutup setiap kali—mengevaluasi ulang batasan model, memilih ulang tumpukan alat, dan menyusun ulang bentuk produk. Terlihat tidak efisien, tetapi ini adalah satu-satunya cara untuk mengikuti kecepatan model.

Apakah Anda tahu—apa itu Product Overhang? Penulis telah menjelaskan istilah ini di artikel sebelumnya, "Untuk Individu Super" [4]: kemampuan model telah melampaui bentuk produk saat ini, tetapi belum ada pintu masuk produk, izin, atau konteks untuk mewujudkannya. Nilai posisi FDE pada dasarnya adalah mewujudkan Overhang yang menggantung dalam skenario pelanggan menjadi produk nyata yang dapat dijalankan. Pelanggan tidak membeli kuota panggilan API model, melainkan kemampuan "seseorang yang benar-benar dapat mewujudkan kumpulan Overhang ini dalam bisnis saya".

Ini juga menjelaskan perbedaan pada baris "struktur proyek". Struktur standar untuk proyek konsultasi adalah SOW (Statement of Work) + WBS (Work Breakdown Structure) + penerimaan tahapan: dalam kontrak, harus dijelaskan secara jelas apa yang akan diserahkan, kapan diserahkan, dan dengan standar apa penerimaannya. Dasar dari struktur ini adalah bahwa tujuan telah didefinisikan dengan jelas sebelum kontrak ditandatangani.

Proyek FDE tidak mengikuti pendekatan ini. Kalimat paling sering diucapkan klien adalah: "Saya tahu AI seharusnya bisa membantu saya melakukan sesuatu, tapi saya tidak tahu apa itu." Tujuan itu sendiri adalah bagian dari proyek. Oleh karena itu, FDE tidak menerima SOW, melainkan mission—arah yang relatif kabur; kemudian menggunakan iterasi secara bertahap untuk memperjelas arah tersebut; akhirnya, di salah satu iterasi, pemahaman model yang telah terakumulasi diwujudkan menjadi bentuk produk.

Baris "hasil akhir" juga layak dijelaskan lebih lanjut. Setelah FDE pergi, yang tetap ada di sistem klien adalah sebuah fungsi yang berjalan—mungkin kecil, mungkin jelek, mungkin tidak memiliki antarmuka pengguna, tetapi setiap hari benar-benar dipanggil, diubah, dan dikritik. Hasil akhir konsultasi adalah PPT dan laporan manajemen perubahan; meskipun dalam proyek tersebut pernah ditulis kode atau dikonfigurasi ERP, yang tetap di tangan eksekutif klien tetaplah dokumen metodologis.

Baris "moat" paling halus. Moat FDE adalah sensasi real-time terhadap batasan kemampuan model—berapa banyak skenario pelanggan nyata yang Anda jalankan bulan ini, itulah yang membuat Anda lebih tahu mana yang bisa dilakukan Claude 4.7 dan mana yang harus menunggu Claude 5. Sensasi ini tidak bisa ditulis ke dalam PPT atau dimasukkan ke dalam basis pengetahuan; ia hanya tumbuh di dalam pikiran insinyur yang telah aktif bekerja dalam 90 hari terakhir.

Jadi, jika ada yang mengatakan "FDE itu kan versi baru Accenture", Anda bisa menjawab: Insinyur Accenture mendesain ulang proses klien, sementara FDE mendalami ulang batasan model. Aset milik yang pertama bisa bertahan selama sepuluh tahun, sementara aset yang kedua harus tumbuh kembali setelah 90 hari.

Jika "FDE adalah versi baru Accenture" adalah salah paham tingkat pertama, maka "FDE adalah outsourcing perangkat lunak mahal" adalah tingkat kedua. Tingkat ini lebih menyesatkan, karena bukti permukaannya tampak sangat kuat: FDE benar-benar pergi ke lokasi klien untuk menulis kode, benar-benar menyesuaikan fitur sesuai bisnis klien, dan benar-benar dapat dihubungi selama jam kerja klien. Secara sekilas, tidak berbeda dengan insinyur outsourcing.

Tetapi sekali melihat umpan baliknya, perbedaannya tidak bisa disembunyikan.

Perbedaan paling kunci dalam gambar ini bukanlah seberapa sederhananya bagian atas gambar, melainkan adanya rantai umpan balik yang memanjang ke perusahaan model di bagian bawah gambar. Rantai ini bukan sekadar hiasan; ini adalah alasan sejati keberadaan posisi FDE. Dengan memecah perbedaan ini, setidaknya ada empat pasangan perbandingan.

Yang diterima berbeda. Outsourcing menerima SOW—daftar kebutuhan yang sudah didefinisikan jelas sebelum kontrak ditandatangani: fitur apa yang harus dibuat, teknologi apa yang digunakan, standar apa untuk penerimaan, dan bagaimana kompensasi jika terjadi pelanggaran. FDE menerima mission—klien sendiri belum jelas apa yang mereka inginkan, hanya tahu bahwa “AI seharusnya bisa membantu saya melakukan sesuatu”. Dasar SOW adalah kepastian, sedangkan dasar mission adalah eksplorasi. Keduanya memiliki sikap awal proyek yang sama sekali berbeda.

Lingkupnya berbeda. Pekerjaan outsourcer adalah pengiriman sebagian—satu modul, satu situs web, satu pipeline data, setelah selesai dikemas dan pergi, lalu ke klien berikutnya. FDE melakukan end-to-end—mulai dari masalah bisnis, pemilihan model, desain bentuk produk, hingga retensi dan churn pengguna nyata setelah peluncuran.

Cara penagihan berbeda. Ini yang paling tidak intuitif. Sebuah perusahaan model mengirim FDE ke lokasi klien, yang secara utama tidak hanya peduli berapa biaya konsultasi yang diperoleh dari proyek ini, tetapi juga: berapa banyak token yang akan dikonsumsi klien ini selanjutnya? Apakah klien ini akan menjadi pelanggan retention? Apakah akan diperluas ke lebih banyak lini bisnis? KPI sejati FDE adalah kurva konsumsi token jangka panjang model, bukan angka yang tercantum di dokumen penerimaan proyek.

Umpan baliknya berbeda arah. Ini adalah kelompok paling dalam di antara keempat kelompok tersebut. Dalam proyek outsourcing, umpan balik dari klien hanya sampai pada perusahaan outsourcing dan tidak memengaruhi produk yang akan dijual perusahaan outsourcing di masa depan. Sebaliknya, umpan balik FDE mengalir kembali ke roadmap perusahaan model—setiap tantangan, kegagalan Prompt, dan bug pemanggilan alat yang dihadapi klien dalam skenario nyata menjadi masukan untuk data pelatihan versi berikutnya, desain alat versi berikutnya, dan fitur produk versi berikutnya. Dengan kata lain, setiap klien yang menerapkan FDE bagi perusahaan model sekaligus berperan sebagai mitra desain alami.

Inilah alasan sebenarnya mengapa perusahaan model bersedia membayar gaji tinggi untuk merekrut FDE. Mereka tidak hanya menjual sebuah layanan, tetapi juga mengumpulkan sinyal bentuk produk dunia nyata di lokasi klien. Sinyal-sinyal ini tidak bisa dibeli, tidak bisa ditangkap, dan tidak bisa diungkap melalui survei—hanya bisa dibawa pulang oleh seorang insinyur nyata, setelah mengalami beberapa kali tabrakan langsung dalam alur kerja klien tertentu.

Apakah Anda tahu—berapa total kompensasi FDE untuk OpenAI dan Anthropic? Berdasarkan data publik dari insinyur perangkat lunak Anthropic di Levels.fyi [8], median total kompensasi untuk SDE senior sudah mencapai $710K. Posisi FDE memiliki risiko lebih tinggi—harus menghadapi ketidakpastian kemampuan model, ketidakpastian bisnis klien, serta ketidakpastian bentuk produk, sehingga menurut ringkasan industri [9], total kompensasi FDE tingkat menengah hingga lanjut di laboratorium AI mutakhir umumnya berkisar antara $350K - $550K, sementara level Staff ke atas bisa mencapai $630K+. Harga ini bukan dibayar untuk "waktu kerja outsourcing", melainkan sebagai kompensasi bagi mereka yang menanggung gabungan tiga risiko: "produk + klien + model". > Ingatlah tahun 2006, ketika saya baru memulai karier di sebuah BUMN, saat itu sedang menjalani transformasi digital; pada masa itu, konsultan Accenture yang diundang grup kami tinggal di lokasi, dan grup kami harus membayar biaya konsultasi sebesar 3.500 yuan per hari, bertahan selama beberapa tahun, dan disebut oleh media saat itu sebagai "gold collar". Saya kemudian bergabung dengan perusahaan Jerman SAP, yang justru menciptakan istilah dalam industri konsultasi—konsultan SAP menjadi simbol "gold collar". Dari sini terlihat, gaji FDE setidaknya akan terus meningkat selama 24–36 bulan ke depan, dengan permintaan yang juga terus meningkat stabil.

Outsourcing adalah arbitrase tenaga kerja, FDE adalah sensor garis depan. Mencampuradukkan kedua hal ini akan membuat klien salah mengira bahwa FDE dapat direkrut dengan cara SOW, dan juga membuat kandidat memperlakukan FDE dengan sikap kerja outsourcing. Kedua belah pihak akan segera menabrak dinding.

Banyak orang salah mengira bahwa istilah FDE diciptakan oleh OpenAI. Sebenarnya tidak. FDE memiliki dua akar sejarah: satu berasal dari Palantir, dan satu lagi dari perusahaan model generasi baru setelah 2023. Dengan membandingkan kedua akar ini secara berdampingan, kita dapat memahami lebih jelas apa sebenarnya yang dilakukan oleh posisi FDE.

Lihat terlebih dahulu garis waktu.

Akar pertama adalah Palantir.

Palantir didirikan pada tahun 2003 oleh Peter Thiel, Alex Karp, Joe Lonsdale, dan lainnya, dengan klien pertamanya adalah lembaga intelijen Amerika Serikat. Karp sendiri tidak memiliki latar belakang CS—ia menempuh doktor filsafat di Frankfurt bersama filsuf Jürgen Habermas, dan baru bergabung sebagai CEO setelah diundang oleh Thiel kembali ke Amerika. Posisi FDE justru muncul akibat kombinasi "CEO non-typikal + klien sangat rahasia" seperti Karp: dalam tinjauan 36Kr [10], disebutkan dengan jelas bahwa Palantir awalnya sering dikritik keras oleh lembaga intelijen karena insinyur tidak bisa mengakses skenario bisnis nyata, sehingga kebutuhan yang diterjemahkan secara bertahap sudah menyimpang. Kemudian, Palantir berhasil menyelesaikan satu hal—mengizinkan insinyur mereka langsung bekerja di lokasi klien bersama analis intelijen. Model ini kemudian disistematisasi oleh Shyam Sankar dan menjadi cikal bakal FDE.

Pada tahun 2009, FDE diperluas ke bidang bisnis. Saat JPMorgan menerapkan platform Palantir Metropolis, 120 FDE ditempatkan untuk memantau ancaman internal. Sejak saat itu, FDE tidak lagi sekadar "mengirim insinyur ke lokasi pelanggan", tetapi menjadi pendekatan terstruktur untuk menanamkan diri ke dalam pelanggan: memasukkan Foundry/Gotham secara nyata ke dalam alur bisnis pelanggan, bukan hanya memberikan lisensi lalu pergi.

Palantir memiliki standar yang tidak intuitif dalam rekrutmen FDE—tidak memerlukan latar belakang CS. Hal ini bisa dimasukkan ke dalam "Apakah Anda Tahu?"

Apakah kamu tahu—Palantir FDE tidak memerlukan latar belakang CS? Menurut standar rekrutmen Palantir yang disusun oleh SkillScouter [11] dan halaman karier resmi Palantir [12], Palantir secara jelas menyambut kandidat dari luar bidang CS, dengan baru-baru ini para FDE yang direkrut berasal dari jurusan teknik mesin, ekonomi, filsafat, dan lainnya. Dua hal yang benar-benar menjadi penentu adalah: kemampuan bertindak meskipun informasi tidak lengkap, serta mampu berkomunikasi langsung dengan klien tingkat C. Gelar CS adalah nilai tambah, bukan syarat masuk. Karp sendiri adalah contoh pertama dari standar ini—seorang CEO lulusan filsafat yang memimpin sekelompok FDE dengan latar belakang fisika, matematika, dan filsafat.

Akar kedua adalah perusahaan model generasi baru setelah 2023.

Setelah ChatGPT dirilis akhir tahun 2022, OpenAI segera menyadari satu hal: menghubungkan API model ke dokumen dan membiarkan klien mengintegrasikannya sendiri sama sekali tidak berhasil. Klien bukan tidak ingin menggunakannya, tetapi tidak tahu cara menggunakannya—mereka memiliki masalah bisnis, tetapi tidak memiliki bentuk produk. Oleh karena itu, perusahaan-perusahaan seperti OpenAI, Anthropic, Cohere, Scale, Glean, Sierra, Hebbia, dan Decagon mulai merekrut FDE dalam skala besar.

Gelombang FDE kali ini belajar dari playbook Palantir—mengirim insinyur ke lokasi klien untuk menjalankan alur kerja secara end-to-end. Namun, media produknya sudah sama sekali berbeda: FDE era Palantir fokus pada integrasi data dan kustomisasi UI, sementara FDE generasi baru fokus pada desain Prompt, pengaturan Agent, pemanggilan alat, dan penyisipan alur kerja.

Dalam artikel khusus Pragmatic Engineer tentang FDE [13], versi baru ini disebut sebagai "embedded with enterprises to make Claude solve real, specific, high-value problems"—formulasi yang hampir identik dengan yang digunakan Palantir pada masa itu, hanya saja kata "data" diganti dengan "model".

Melihat kedua akar ini bersama-sama, Anda dapat melihat serangkaian kesamaan dan perbedaan yang jelas.

Titik bersama: Klien tidak membeli perangkat lunak. Klien membeli "rekayasa + kombinasi alat yang dapat menyelesaikan masalah saya." Hal ini sebenarnya tidak biasa dalam sejarah perangkat lunak perusahaan selama tiga dekade terakhir. SAP, Oracle, dan Salesforce menjual perangkat lunak itu sendiri—insinyur ada sebagai sumber daya pendukung agar klien dapat mengakses perangkat lunak tersebut. Palantir justru sebaliknya: alat-alat tersebut ada sebagai tuas agar FDE dapat menyelesaikan masalah di sisi klien. Perusahaan model generasi baru mewarisi hubungan terbalik ini—OpenAI tidak menjual lisensi GPT-4, tetapi "FDE kami dapat menggunakan GPT-4 untuk membantu Anda mengotomatisasi layanan pelanggan."

Perbedaan: Era Palantir lebih berfokus pada integrasi OPS—fokus utama pada integrasi data, pemodelan ontologi, dan tata kelola izin. Generasi baru lebih berfokus pada penerapan kemampuan model—fokus utama pada desain Prompt, pengaturan Agent, dan optimasi retensi. Yang pertama seperti versi lanjutan dari sistem integrator, yang kedua seperti perpanjangan dari insinyur produk.

Fakta menarik terakhir: Banyak FDE awal Palantir kemudian menjadi pengusaha, atau langsung bergabung dengan perusahaan model generasi baru. Di tim awal Anthropic, OpenAI, Sierra, dan Hebbia, Anda bisa menyebutkan daftar panjang nama-nama mantan karyawan Palantir. Ini bukan kebetulan—peran FDE secara alami memaksa seseorang untuk menanggung risiko produk, risiko pelanggan, dan risiko teknis sekaligus, hampir seperti pelatihan pengusaha. Penulis lebih suka melihat Palantir sebagai kamp pelatihan pengusaha tersembunyi: ia tidak hanya melatih insinyur, tetapi juga sekelompok orang yang tahu cara mendorong suatu hal dari nol menjadi satu dalam kondisi informasi yang tidak lengkap. Dua akar ini akhirnya bergabung setelah tahun 2023.

Pertemuan dua akar terutama terjadi di luar negeri. Di dalam negeri, istilah FDE belum lama muncul, tetapi pekerjaan yang sesuai dengannya bukan muncul begitu saja. Untuk memahami FDE di dalam negeri, kita harus terlebih dahulu melihat dua pendahulu lokalnya, lalu memahami tiga perbedaan kontekstualnya dengan versi FDE Amerika.

Dua pendahulu lokal

Pendahulunya adalah solusi arsitek dari penyedia cloud. Dalam sepuluh tahun terakhir, Alibaba Cloud, Tencent Cloud, dan Huawei Cloud telah membentuk tim Solution Architect (SA) yang lengkap, yang menjelaskan arsitektur kepada pelanggan, menulis POC, membuat rencana migrasi, serta berkolaborasi dalam proses pelaksanaan hingga peluncuran. Di dalam Huawei, terdapat serangkaian khusus "Engineer Pelaksana" yang bertanggung jawab untuk menerapkan proyek di ruang server pelanggan. Sistem ini telah menangani 80% pekerjaan FDE, tetapi fokusnya masih berada pada tahap pra-penjualan dan penempatan—tanggung jawab iterasi produk end-to-end tidak berada di tangan SA; jika ada perubahan kebutuhan, harus melalui proses perubahan, dan jika model diganti, harus menunggu jadwal dari kantor pusat.

Warisan kedua adalah urutan baru yang muncul di perusahaan startup AI. MiniMax memasang lowongan "Spesialis Solusi Pra-Penjualan AI" di BOSS Zhipin, dan perusahaan model seperti Moonshot, Zhipu, Tongyi, dan Hunyuan juga memasang posisi serupa. Nama posisinya sedikit berbeda, tetapi konten JD sangat seragam: memahami skenario pelanggan, membuat demo, menyesuaikan prompt, menjalankan RAG, menyusun rencana pengiriman, dan berkoordinasi dengan tim teknis pelanggan hingga peluncuran. Gelombang posisi ini benar-benar merupakan "FDE domestik" dalam arti sebenarnya.

Tiga perbedaan tanah dan air

Deploymen privat + kepatuhan data menghancurkan model murni berbasis panggilan. Pelanggan B-domestik di Tiongkok memiliki persyaratan yang jauh lebih tinggi terkait data tidak keluar dari wilayah, kendali atas bobot model, dan audit yang dapat dilacak dibandingkan pasar AS. Dalam sebuah proyek FDE, pekerjaan yang hanya melibatkan panggilan API dan menjalankan Prompt mungkin hanya menyumbang 30%, sedangkan 70% sisanya melibatkan pemindahan model ke ruang server klien, mengaktifkan otorisasi, mengintegrasikan dengan pusat data, serta melakukan pendaftaran kepatuhan.

Kemampuan model masih mengejar SOTA, ruang pengembangan terbatas pada tingkat teknis. OpenAI dan Anthropic di AS dapat menarik pelanggan dengan kemampuan model itu sendiri; sementara kemampuan Tongyi, DouBao, Kimi, GLM, dan DeepSeek di Tiongkok tidak terlalu berbeda, penilaian pelanggan lebih banyak berfokus pada kemampuan teknis seperti pengaturan Agent, kualitas pencarian RAG, integrasi alat, dan desain Workflow. Di Tiongkok, FDE tidak bersaing dengan “model saya sekuat apa”, tetapi “apakah saya bisa benar-benar menjalankan bisnis ini”.

Kehendak membayar dan ritme penetapan harga di B-end tidak konsisten dengan Amerika Serikat. Model seperti Palantir, yang “mengirim FDE terlebih dahulu, baru mengenakan biaya langganan tinggi”, sulit untuk langsung direplikasi. Anggaran pelanggan domestik mengikuti pembelian tahunan, dengan kecenderungan pembayaran berbasis proyek, sehingga model bisnis FDE sering kali berbentuk campuran antara langganan, lisensi privat, dan pengiriman proyek.

Sebuah posisi unik: FDE internal

Banyak tim AI di perusahaan besar mulai menggunakan model FDE untuk melayani "klien internal". Alibaba Cloud PAI mengirim insinyur ke Taobao, sementara Tencent Hunyuan juga memiliki mekanisme serupa untuk berkoordinasi dengan WeChat dan bisnis iklan. Di JD, posisi yang tercantum adalah "Insinyur Implementasi Industri", "Insinyur Aplikasi AI", dan "Ahli Bisnis Berbasis Intelijen"—pada dasarnya adalah FDE internal—yang membawa kemampuan tim model secara end-to-end ke sisi bisnis. Ini memberi para pemimpin perusahaan besar ide baru: beberapa FDE internal yang ditempatkan di sisi bisnis, menghasilkan demo pertama, dan menyerahkan data ROI kepada manajer bisnis, akan lebih cepat menghilangkan dinding departemen daripada mengadakan sepuluh pertemuan koordinasi.

Penulis telah membahas lima mesin individu super dalam artikel sebelumnya, "Surat untuk Individu Super" [4]: rasa ingin tahu yang tinggi, semangat eksplorasi dan inovasi yang kuat, kemampuan belajar mandiri yang tinggi, motivasi diri yang kuat, dan keterampilan praktis yang baik. Kelima hal ini adalah tiket masuk untuk FDE, tetapi bukan satu-satunya. Posisi FDE juga memiliki serangkaian ciri khusus di luar lima mesin tersebut, serta beberapa tipe kepribadian yang jelas-jelas tidak cocok. Penulis telah melihat terlalu banyak insinyur hebat yang beralih ke FDE namun kesulitan beradaptasi; masalahnya kebanyakan bukan pada kemampuan, melainkan pada kepribadian dan preferensi kerja.

Lima kualitas yang cocok untuk FDE

Tidak menghindari penjualan dan komunikasi. Keseharian FDE bukanlah menulis kode di balik pintu tertutup, melainkan berinteraksi langsung dengan CTO klien, pemimpin bisnis, pembeli, kepatuhan, dan TI. Ritme tipikal: CTO klien menghentikan demo di tengah jalan, reaksi FDE bukanlah “Saya akan kembali dan memperbaikinya, datang lagi minggu depan,” tetapi langsung membuka IDE, mengubah Prompt, lalu menjalankannya ulang di depannya. “Klien hadir, saya sedang memperbaiki” adalah keadaan normal FDE.

Nikmatilah zona abu-abu. FDE tidak menerima PRD yang jelas, melainkan hanya satu kalimat: “Kami ingin melakukan sesuatu dengan AI.” Klien sendiri pun tidak bisa menjelaskan apa yang mereka inginkan, sehingga FDE perlu menemani mereka mengubah harapan yang kabur ini menjadi bentuk yang konkret. Jika Anda hanya bisa bergerak ketika ada kebutuhan yang jelas, FDE akan membuat Anda cemas setiap hari.

Kemampuan teknis kuat, tetapi tidak memerlukan 10x. FDE tidak memerlukan Anda menjadi orang dengan kode paling bersih atau algoritma paling mendalam di perusahaan, yang dibutuhkan adalah mampu menjalankan sistem secara end-to-end: frontend bisa membuat halaman yang bisa diklik, backend bisa membangun layanan yang berjalan, dan model bisa terhubung ke sumber data bisnis. Di dunia FDE, "cukup baik sudah cukup" bukanlah kelemahan, melainkan kebajikan.

Menyukai penyempurnaan melalui umpan balik. Dalam pekerjaan FDE, ada banyak momen “dikritik klien dan harus dikerjakan ulang”: demo hari ini besok dikatakan oleh tim bisnis “Ini bukan yang saya inginkan”; solusi yang sudah disepakati minggu lalu, minggu ini harus dikerjakan ulang karena klien mengganti manajer tingkat atas. Orang yang cocok untuk peran FDE akan menjadikan umpan balik semacam ini sebagai bahan bakar, mampu menanggung tanggung jawab penuh dari awal hingga akhir, dan tidak melempar kesalahan kepada “kebutuhan yang tidak dijelaskan dengan jelas”.

Sensitif terhadap batasan model. Ini adalah yang paling teknis dan paling tersirat. FDE harus mampu menilai tugas mana yang cocok dilakukan oleh LLM dan mana yang tidak, serta bagaimana cara fallback yang tepat—sensitivitas semacam ini tidak bisa dipahami hanya dengan membaca paper, melainkan hanya bisa dipelajari melalui kegagalan nyata. Dengan akumulasi sampel kegagalan, FDE akan mengembangkan ingatan otot terhadap batasan model: kapan harus menggunakan RAG, kapan harus mengandalkan aturan, dan kapan harus menyediakan jalur fallback untuk manusia.

Empat jenis orang yang tidak cocok untuk FDE

Teknisi murni yang ingin bersembunyi di dalam kode. FDE sekitar 50% waktunya tidak menulis kode—melainkan berada di rapat klien, koordinasi internal, diskusi produk, dan pengembangan kontrak. Jika sumber kebahagiaan Anda adalah menulis kode selama empat jam berturut-turut tanpa gangguan, FDE akan membuat Anda mengalami kelelahan mental dalam jangka panjang.

Orang yang butuh OKR untuk mulai bergerak. Tujuan FDE tertanam pada pelanggan, bukan pada tabel kinerja Anda. Kemajuan kerja ditentukan oleh tahapan proyek pelanggan, perubahan kemampuan model, dan penilaian Anda terhadap skenario. Orang yang terbiasa “baru tahu apa yang harus dilakukan setelah ada OKR” akan kehilangan titik tumpu.

Orang yang mengutamakan "promosi" daripada "karya". FDE tidak memiliki keuntungan dalam sistem promosi perusahaan besar—indikator seperti kepuasan pelanggan, penandatanganan proyek, dan tingkat pemanfaatan ulang tidak sekuat jumlah kode atau frekuensi peluncuran dalam penilaian tingkat jabatan. Jika promosi adalah prioritas utama dalam motivasi kerja Anda, FDE bukan pilihan yang tepat.

Orang yang menolak konteks bisnis. FDE harus memahami P&L klien, ROI, proses pengadaan, dan persyaratan kepatuhan. Jika Anda secara alami membenci pembicaraan tentang uang, kontrak, atau logika bisnis, pekerjaan FDE akan membuat Anda merasa seperti mengkhianati idealisme teknis Anda.

Daftar Periksa Diri

7 pertanyaan, masing-masing terkait dengan satu skenario kerja nyata FDE. Jawab "ya" lebih dari 5 kali untuk mempertimbangkan FDE secara serius, jawab 3 kali atau kurang disarankan untuk berhati-hati.

1. Apakah Anda bersedia mengalihkan 50% waktu harian Anda dari kode ke rapat klien, membalas pesan, dan panggilan telepon?

2. Ketika pelanggan memberi tahu Anda, "Ini tidak bisa, saya juga tidak bisa jelaskan mengapa," reaksi pertama Anda adalah rasa ingin tahu atau kesabaran?

3. Tidak ada yang menulis PRD untukmu, bisakah kamu menjalankan prototipe yang bisa ditunjukkan ke klien dalam satu minggu bersama Claude Code?

4. Untuk pengiriman yang sama, klien meminta Anda mengubahnya sebanyak 8 versi, apakah Anda masih bisa mempertahankan daya juang, bukan hanya melaksanakan secara mekanis?

5. Ketika model memberikan jawaban yang salah, reaksi pertama Anda adalah merancang fallback, atau mengeluh bahwa modelnya buruk?

6. Apakah Anda bersedia menandatangani kontrak, menulis laporan, mengurus penerimaan klien, dan berkoordinasi dengan hukum terkait ketentuan kepatuhan?

7. Apakah Anda dapat menerima prototipe cepat dan kegagalan cepat?

Lima ciri, empat jenis gambaran sebaliknya, tujuh pertanyaan self-assessment—pada akhirnya semuanya mengarah pada satu pertanyaan: apakah Anda bersedia memperbaiki rasa produk, kekuatan teknis, dan penilaian bisnis Anda secara bersamaan dalam satu alur kerja?

Pada artikel sebelumnya, penulis membahas "mesin manusia": rasa ingin tahu, semangat eksplorasi, kemampuan belajar mandiri, motivasi intrinsik, dan keterampilan praktis—bagaimana semuanya dapat diaktifkan secara utuh dalam lingkungan perusahaan besar. Artikel ini membahas hal lain—bentuk pekerjaan. FDE adalah bentuk pekerjaan baru pertama dalam revolusi AI yang memiliki nama, rentang gaji, deskripsi pekerjaan resmi, dan validasi pembayaran dari klien. Ini bukan sinonim dari konsep "individu super", melainkan koordinat pertama yang benar-benar terwujud dari abstrak menjadi nyata dalam gelombang restrukturisasi ini.

FDE bukanlah titik akhir. Menurut penulis, FDE hanyalah bentuk pertama dalam pembagian kerja baru yang mendapatkan nama. Di belakangnya akan muncul Forward Deployed PM, Forward Deployed Designer, Forward Deployed Researcher—semua peran yang terkait erat dengan skenario pelanggan dan memerlukan pengembangan produk di wilayah ambigu akan memiliki versi “forward deployed” sendiri. Nama posisi akan berubah, tetapi logika dasarnya tetap sama: kemampuan model berjalan di depan, bentuk produk mengejar di belakang, dan struktur posisi dibagi ulang mengikuti alur kerja.

Berikan satu kalimat untuk masing-masing dari tiga kelompok pembaca.

Untuk para teknisi: FDE tidak mengharuskan Anda menjadi orang dengan kode terbaik di perusahaan, tetapi mengharuskan Anda bersedia mengalihkan setengah waktu dari kode ke klien. Jika jawaban Anda adalah “bersedia”, jendela pasar baru saja terbuka, dan rekrutmen oleh perusahaan model terkemuka di Tiongkok, penyedia cloud, dan tim AI internal perusahaan besar sedang dipercepat. Jika jawaban Anda adalah “tidak bersedia”, tidak masalah—peran baru akan muncul dalam pembagian tugas baru yang cocok untuk Anda.

Untuk HR dan OD: Waspadai "ketidaksesuaian antara nama dan realitas". Perusahaan Anda mungkin sudah memiliki sejumlah FDE yang sedang bekerja, hanya saja kode jabatannya tercatat sebagai "Spesialis Solusi", "Arsitek Industri", atau "Insinyur Aplikasi AI". Kenali mereka, klasifikasikan ulang, dan berikan jalur pengembangan yang sesuai dengan isi pekerjaan mereka, lebih efisien daripada merekrut karyawan baru dari nol.

Untuk manajer: Mode FDE tidak hanya bisa diterapkan ke luar, tetapi juga ke dalam. Di dalam perusahaan, tempatkan beberapa "FDE internal" di garis depan bisnis, dan jalankan kemampuan tim model secara end-to-end ke dalam proses bisnis—ini mungkin jauh lebih efisien daripada membuat departemen AI baru dan mengadakan sepuluh pertemuan koordinasi lintas tim. Dinding departemen tidak dihilangkan oleh desain organisasi, tetapi oleh sebuah demo yang bisa berjalan.

Transformasi karier di era AI telah dimulai, dan FDE adalah sinyal pertama yang memberi tahu kita: kecepatan perubahan kemampuan model sudah begitu cepat hingga menciptakan posisi baru. Penulis ingin meninggalkan pembaca dengan satu pertanyaan spesifik—jika tiga tahun lagi ada tiga posisi baru di bagan struktur organisasi perusahaan Anda, menurut Anda apa ketiganya? Memikirkan jawaban atas pertanyaan ini lebih bermanfaat daripada sekadar menyelesaikan artikel ini.

👦🏻 Penulis: Henry (Tim DeerFlow) [1]