Seorang insinyur Anthropic mengajarkan kursus pengantar FDE
https://www.youtube.com/watch?v=KwhgfwOSToQ
Kevin Bai saat ini berada di tim Applied AI di Anthropic. Sebelumnya, ia merupakan anggota pendiri tim FDE di Rippling, dan sebelum itu ia bekerja selama beberapa tahun di Palantir. Belakangan ini, ia membuat presentasi tentang FDE 101, menjelaskan dengan sangat jelas peran sebagai engineer yang dikerahkan ke lini depan. Ini layak dirangkum.
Pertama, lihat satu data: di perusahaan SaaS yang sudah go public, jika diurutkan berdasarkan nilai kontrak rata-rata, Palantir berada di angka 4 juta dolar AS, ServiceNow 1,2 juta, Workday 600 ribu, dan tidak ada perusahaan lain yang bisa melewati 500 ribu. Palantir berhasil mencapai nilai per pelanggan setinggi itu hanya dengan beberapa ribu orang—yang mana tidak bisa dilakukan oleh perusahaan lain yang memiliki puluhan ribu karyawan. Kuncinya adalah model FDE.
Lalu, FDE sebenarnya menyelesaikan masalah apa?
Produk Palantir, Foundry, adalah platform untuk membangun aplikasi—ambang teknologinya tinggi. Namun, pembelinya adalah eksekutif non-teknis dari industri seperti minyak bumi dan barang konsumsi. Anda tidak bisa begitu saja melempar platform teknologi yang rumit kepada orang yang tidak bisa menulis kode, lalu mengharapkan ia bisa memahami sendiri cara menggunakannya.
Maka pendekatan Palantir adalah: yang dibeli klien bukanlah produk perangkat lunak maupun layanan konsultasi, melainkan sebuah “hasil”. Anda mengirim engineer ke lokasi, benar-benar memahami konteks bisnis klien, lalu membangun “sesuatu” di atas platform tersebut. Yang klien pedulikan adalah berapa banyak produk yang bertambah di rak, atau seberapa efisien lini produksi meningkat. Mereka tidak peduli—dan memang tidak seharusnya peduli—bagaimana data diorganisasikan.
Apa bedanya FDE dengan pengembangan berbasis outsourcing?
Kevin menekankan satu hal khusus: jika engineer Anda setiap kali menulis kode kustom dari nol untuk klien, maka itu bukan FDE—melainkan outsourcing development. Agar model FDE bisa berjalan, prasyaratnya adalah Anda memiliki platform yang dapat digunakan ulang. Engineer merakit dan menyesuaikan berdasarkan kemampuan dasar yang sudah ada di platform, bukan menciptakan roda dari awal setiap kali. Tanpa platform, biaya pemeliharaan akan menghabiskan semua profit, dan engineer juga akan kabur karena harus memelihara puluhan basis kode yang sama sekali tidak saling terkait.
Perlu atau tidak melakukan FDE? Dua pertanyaan ini bisa menjawab.
Pertama, apakah Anda benar-benar harus menjual sesuatu yang kompleks secara teknis kepada pembeli yang non-teknis? Jika pelanggan Anda sendiri adalah engineer—misalnya jika Anda menjual GitHub atau Datadog—maka tidak perlu FDE. Jika produk Anda memang “siap pakai” seperti Slack atau Jira, juga tidak perlu. FDE baru perlu jika produk Anda sangat kompleks, sementara pelanggan tidak paham teknis.
Kedua, apakah Anda punya platform yang bisa digunakan ulang? Atau apakah Anda bersedia menginvestasikan waktu dan biaya untuk membangunnya? Tanpa komponen dasar yang bisa dibagi bersama, FDE tidak akan berkelanjutan.
Perubahan apa yang terjadi di tahun 2026?
Penilaian Kevin sangat menarik: cara industri perangkat lunak dalam berbisnis juga berubah. AI membuat pembuatan software jadi sangat mudah, sehingga hampir semua platform bergerak menuju model Agent. Artinya, hampir semua platform menjadi sangat bisa dikustomisasi. Konsekuensinya adalah makin banyak pelanggan yang tidak bisa memahami dengan jelas apa yang sebenarnya bisa dilakukan produk Anda. Memberikan keberhasilan produk kepada pelanggan untuk “menemukannya sendiri” di era Agent akan semakin sulit.
Ini membuat FDE yang sebelumnya hanya “gaya” khas dan niche milik Palantir, kini menjadi hal yang perlu dipertimbangkan serius oleh lebih banyak perusahaan software.
Pertanyaan terakhir: tipe orang seperti apa yang cocok untuk menjalankan FDE?
Jawaban Kevin sangat singkat: FDE adalah sebuah bentuk di mana Anda mempercayai seorang engineer sedemikian rupa hingga ia bisa langsung berhadapan dengan klien. Kemampuan teknis adalah basisnya, tetapi Anda juga harus merasa nyaman agar ia bisa mewakili perusahaan saat berinteraksi dengan klien.
https://www.youtube.com/watch?v=KwhgfwOSToQ
Kevin Bai saat ini berada di tim Applied AI di Anthropic. Sebelumnya, ia merupakan anggota pendiri tim FDE di Rippling, dan sebelum itu ia bekerja selama beberapa tahun di Palantir. Belakangan ini, ia membuat presentasi tentang FDE 101, menjelaskan dengan sangat jelas peran sebagai engineer yang dikerahkan ke lini depan. Ini layak dirangkum.
Pertama, lihat satu data: di perusahaan SaaS yang sudah go public, jika diurutkan berdasarkan nilai kontrak rata-rata, Palantir berada di angka 4 juta dolar AS, ServiceNow 1,2 juta, Workday 600 ribu, dan tidak ada perusahaan lain yang bisa melewati 500 ribu. Palantir berhasil mencapai nilai per pelanggan setinggi itu hanya dengan beberapa ribu orang—yang mana tidak bisa dilakukan oleh perusahaan lain yang memiliki puluhan ribu karyawan. Kuncinya adalah model FDE.
Lalu, FDE sebenarnya menyelesaikan masalah apa?
Produk Palantir, Foundry, adalah platform untuk membangun aplikasi—ambang teknologinya tinggi. Namun, pembelinya adalah eksekutif non-teknis dari industri seperti minyak bumi dan barang konsumsi. Anda tidak bisa begitu saja melempar platform teknologi yang rumit kepada orang yang tidak bisa menulis kode, lalu mengharapkan ia bisa memahami sendiri cara menggunakannya.
Maka pendekatan Palantir adalah: yang dibeli klien bukanlah produk perangkat lunak maupun layanan konsultasi, melainkan sebuah “hasil”. Anda mengirim engineer ke lokasi, benar-benar memahami konteks bisnis klien, lalu membangun “sesuatu” di atas platform tersebut. Yang klien pedulikan adalah berapa banyak produk yang bertambah di rak, atau seberapa efisien lini produksi meningkat. Mereka tidak peduli—dan memang tidak seharusnya peduli—bagaimana data diorganisasikan.
Apa bedanya FDE dengan pengembangan berbasis outsourcing?
Kevin menekankan satu hal khusus: jika engineer Anda setiap kali menulis kode kustom dari nol untuk klien, maka itu bukan FDE—melainkan outsourcing development. Agar model FDE bisa berjalan, prasyaratnya adalah Anda memiliki platform yang dapat digunakan ulang. Engineer merakit dan menyesuaikan berdasarkan kemampuan dasar yang sudah ada di platform, bukan menciptakan roda dari awal setiap kali. Tanpa platform, biaya pemeliharaan akan menghabiskan semua profit, dan engineer juga akan kabur karena harus memelihara puluhan basis kode yang sama sekali tidak saling terkait.
Perlu atau tidak melakukan FDE? Dua pertanyaan ini bisa menjawab.
Pertama, apakah Anda benar-benar harus menjual sesuatu yang kompleks secara teknis kepada pembeli yang non-teknis? Jika pelanggan Anda sendiri adalah engineer—misalnya jika Anda menjual GitHub atau Datadog—maka tidak perlu FDE. Jika produk Anda memang “siap pakai” seperti Slack atau Jira, juga tidak perlu. FDE baru perlu jika produk Anda sangat kompleks, sementara pelanggan tidak paham teknis.
Kedua, apakah Anda punya platform yang bisa digunakan ulang? Atau apakah Anda bersedia menginvestasikan waktu dan biaya untuk membangunnya? Tanpa komponen dasar yang bisa dibagi bersama, FDE tidak akan berkelanjutan.
Perubahan apa yang terjadi di tahun 2026?
Penilaian Kevin sangat menarik: cara industri perangkat lunak dalam berbisnis juga berubah. AI membuat pembuatan software jadi sangat mudah, sehingga hampir semua platform bergerak menuju model Agent. Artinya, hampir semua platform menjadi sangat bisa dikustomisasi. Konsekuensinya adalah makin banyak pelanggan yang tidak bisa memahami dengan jelas apa yang sebenarnya bisa dilakukan produk Anda. Memberikan keberhasilan produk kepada pelanggan untuk “menemukannya sendiri” di era Agent akan semakin sulit.
Ini membuat FDE yang sebelumnya hanya “gaya” khas dan niche milik Palantir, kini menjadi hal yang perlu dipertimbangkan serius oleh lebih banyak perusahaan software.
Pertanyaan terakhir: tipe orang seperti apa yang cocok untuk menjalankan FDE?
Jawaban Kevin sangat singkat: FDE adalah sebuah bentuk di mana Anda mempercayai seorang engineer sedemikian rupa hingga ia bisa langsung berhadapan dengan klien. Kemampuan teknis adalah basisnya, tetapi Anda juga harus merasa nyaman agar ia bisa mewakili perusahaan saat berinteraksi dengan klien.