FDE: Tiền tuyến mới trong các vai trò kỹ thuật được thúc đẩy bởi AI

Trong tháng qua, tôi đã gặp bốn người bạn đang chuẩn bị chuyển đổi nghề nghiệp—lập trình viên frontend, kiến trúc sư giải pháp, sản phẩm manager, kỹ sư thuật toán truyền thống—với nền tảng, độ tuổi và thành phố khác nhau, nhưng đều hỏi cùng một từ viết tắt tiếng Anh: FDE [2] có đáng để tôi theo đuổi không?

FDE, viết tắt của Forward Deployed Engineer [2]. Hai năm trước, đây vẫn là một thuật ngữ nội bộ trong cộng đồng Palantir, nhưng hôm nay nó đã âm thầm trở thành câu mở đầu của các nhà tuyển dụng, vị trí xuất hiện thường xuyên trong các thông báo tuyển dụng, và là một trong những ứng cử viên cho “chức vụ có giá trị nhất thời đại AI” trên các nền tảng mạng xã hội. OpenAI đã trực tiếp thành lập Deployment Company [3] với tên gọi này vào tháng 5 năm 2026, với khoản đầu tư ban đầu 4 tỷ USD, rõ ràng tuyên bố sẽ cử các kỹ sư đến tận hiện trường khách hàng, thâm nhập vào quy trình làm việc của họ; đội Applied AI của Anthropic cũng đang tuyển dụng FDE đồng thời ở bốn múi giờ. Sự việc này từ một thuật ngữ nội bộ đã trở thành từ ngữ phổ biến chỉ trong hơn một năm.

Bài viết trước của tác giả, “Gửi những cá nhân siêu việt” [4], đã thảo luận về “động cơ của con người” – sự tò mò, tự học, tự thúc đẩy và khả năng thực hành – cách chúng được khơi dậy trong một Closed-loop hoàn chỉnh. Nhưng con người không tồn tại lơ lửng; họ cần được một hệ tọa độ vị trí công việc cụ thể đón nhận. Nếu coi những cá nhân siêu việt là “nguyên liệu” của quan hệ sản xuất trong thời đại AI, thì FDE chính là hình thái vị trí công việc rõ ràng nhất mà thị trường đã phát triển trong năm nay.

Theo quan điểm của tác giả, FDE không nằm trong ô tư vấn, cũng không nằm trong ô outsouring. Nó gần với cá nhân siêu việt nhất—sự khác biệt chỉ nằm ở chỗ, FDE là những cá nhân siêu việt được tổ chức hóa trong khe hở giữa “công ty mô hình × khách hàng”.

Bạn có biết không—từ “Forward Deployed” xuất phát từ đâu? Nó vốn là thuật ngữ của quân đội Mỹ, Forward Deployed Forces, chỉ các lực lượng được triển khai ở nước ngoài hoặc tiền tuyến, có khả năng phản ứng nhanh tại chỗ, đối lập với các lực lượng hậu phương còn lại tại căn cứ trong nước. Palantir đã mang từ này vào ngành phần mềm vào cuối những năm 2000 để mô tả mô hình làm việc “phái kỹ sư rời trụ sở chính và sống tại hiện trường khách hàng”, thậm chí cả các đội nội bộ còn được đặt tên theo bảng âm hiệu quân sự, gọi là Delta và Echo. Lần này, nó được OpenAI và Anthropic tiếp quản lại, không phải là ngẫu nhiên—việc phái kỹ sư lên tiền tuyến, bản chất của nó chưa bao giờ thay đổi.

Bài viết này sẽ trả lời ba nghi vấn cụ thể mà tác giả gần đây đã được bốn người bạn hỏi:

- Liệu FDE có phải là một công ty tư vấn được khoác áo AI không? Giới hạn giữa nó và tư vấn truyền thống nằm ở đâu?

FDE có phải là một hình thức outsourcing phần mềm cao cấp hơn không? Nó khác gì so với công việc bên thứ ba mà tôi đang làm?

Tôi có phù hợp để làm FDE không? Loại người nào sẽ được vị trí này khuếch đại, loại nào sẽ bị nghiền nát?

Quan điểm của tác giả là lạc quan một cách thận trọng: FDE đang thực sự hình thành, nhưng nó chưa phải là lối thoát chuyển đổi cho tất cả mọi người. Việc giải thích rõ ràng về nó quan trọng hơn là làm nó trở nên sôi nổi.

Nếu chỉ được chọn một sự kiện để đánh dấu thời điểm FDE tái xuất hiện trong đợt này, tác giả sẽ chọn ngày 11 tháng 5 năm 2026—ngày OpenAI công bố thành lập Deployment Company [5], COO Brad Lightcap rời khỏi bộ phận kinh doanh cũ để chuyển sang vị trí special projects, trực tiếp báo cáo cho Sam Altman và phụ trách toàn thời gian việc này. Cùng tuần đó, OpenAI đã mua lại công ty tư vấn AI của Anh Tomoro, đồng thời đưa vào công ty mới 150 Forward Deployed Engineer và Deployment Specialist.

Đáng chú ý là trang tuyển dụng của OpenAI đang đăng tuyển cùng lúc hơn chục vị trí FDE: tại San Francisco, New York, Washington, cùng các hướng chuyên sâu theo ngành như Life Sciences, Semiconductor, Gov, ngay cả vị trí tuyển dụng FDE [6] cũng đang được tuyển. Các chuyên gia phân tích ước tính đội ngũ này sẽ mở rộng lên 2.000–4.000 người trong ba năm tới. Đây không phải quy mô của một nhóm nghiên cứu, mà là một lực lượng chính quy.

Anthropic gần như thực hiện hành động tương tự. Vị trí Forward Deployed Engineer dưới đội Applied AI [7] đang được tuyển dụng đồng thời tại sáu địa điểm: Boston, New York, Seattle, San Francisco, Washington và London, với yêu cầu đi công tác tại khách hàng từ 25%–50%. Một ví dụ gần đây được trích dẫn thường xuyên là công ty fintech FIS—trong thông báo của mình, họ viết trực tiếp: “Đội Applied AI và các kỹ sư forward-deployed của Anthropic đã được tích hợp vào FIS để cùng thiết kế Financial Crimes AI Agent và chuyển giao kiến thức cho FIS, giúp họ có thể tự độc lập mở rộng thêm nhiều agent sau này.”

Câu này tiết lộ thực tế công việc của FDE. Nó không phải là kiến trúc sư tiền bán hàng, không phải SDR, cũng không phải nhà truyền giáo đến huấn luyện khách hàng. Đó là kỹ sư mang theo mô hình và sống trong kho mã của khách hàng. Brad Lightcap nói rõ hơn: “Khách hàng của chúng tôi cho biết họ cần khả năng từ pilot chuyển sang production. Deployment Company là việc đưa kỹ sư của chúng tôi vào đội ngũ của họ, cung cấp đầy đủ nguồn lực để giao deliverable.”

Vẽ việc này thành một biểu đồ, mối quan hệ giữa ba bên sẽ trở nên rất rõ ràng:

Lưu ý hai đường có nhiều thông tin nhất trong hình này là phản hồi mà FDE truyền đi hai hướng. Về phía khách hàng, FDE không bán mô hình như một dịch vụ SaaS, mà kết hợp dữ liệu, quyền truy cập, tuân thủ và hệ thống nội bộ của khách hàng thành một đường ống có thể chạy mô hình. Về phía các công ty mô hình, FDE mang về những vấn đề thực tế và mẫu lỗi của khách hàng để ảnh hưởng đến lộ trình sản phẩm và nghiên cứu—một mẫu gọi công cụ bị lỗi lặp đi lặp lại có thể trở thành một trừu tượng tích hợp tiếp theo trong SDK.

Đó là lý do tại sao FDE được hai công ty mô hình hàng đầu cùng tái sử dụng trong đợt này, và đằng sau nó không đơn giản chỉ là “chúng ta cũng cần học Palantir làm tư vấn”. Đó là một thiết bị thu thập tín hiệu của các công ty mô hình – những điểm đau cấp bách nhất từ phía khách hàng tuyến đầu chỉ có thể được nắm bắt khi có người của chính công ty ở đó; các nhu cầu được truyền đạt qua đối tác luôn mang tính gián tiếp. Anthropic theo đuổi con đường lai tạo: vừa tự vận hành FDE, vừa xây dựng mạng lưới triển khai liên doanh với các công ty tư vấn và các ông lớn PE. Một bên thiên về tự vận hành, một bên thiên về hệ sinh thái, nhưng cốt lõi đều giống nhau: các công ty mô hình không còn chỉ là nhà cung cấp API, mà sẽ trực tiếp cử kỹ sư tham gia vào sản phẩm của khách hàng.

Câu trả lời tiếp theo sẽ giải đáp hai câu hỏi so sánh phổ biến nhất—ranh giới giữa FDE và tư vấn truyền thống (như McKinsey, Accenture) nằm ở đâu? Nó có phải là một chuyện khác với việc thuê ngoài phần mềm mà chúng ta quen thuộc không?

Nhiều người lần đầu nghe mô tả công việc của FDE đều phản ứng ngay: “Đây không phải là phiên bản mới của McKinsey hay Accenture sao?”

Tôi hiểu sự liên tưởng này. Mặc áo vest, đi công tác đến địa điểm khách hàng, ngồi trong phòng họp của khách hàng để vẽ bảng trắng, đồng bộ với các nhà quản lý cấp C — về mặt hình ảnh, FDE và tư vấn viên trông thật giống nhau. Nhưng chỉ cần đi sâu hơn một chút, bản chất công việc của hai bên hoàn toàn khác biệt. Tư vấn bán ranh giới quy trình, còn FDE bán ranh giới mô hình.

Đặt hai thứ này cạnh nhau trong một bảng, sự khác biệt sẽ lập tức hiển hiện.

Dòng đáng để bạn dừng lại một chút trong bảng này là “khấu hao tài sản”.

Logic kiếm lợi nhuận cao nhất trong tư vấn truyền thống là tái sử dụng tài sản — một giải pháp dành cho một ngân hàng có thể được chỉnh sửa nhẹ và bán lại cho ngân hàng tiếp theo; một playbook số hóa dành cho ngành bán lẻ có thể được áp dụng lặp lại cho ba mươi khách hàng. Đây là mô hình kinh tế cốt lõi đã giúp Accenture, Deloitte và McKinsey Digital phát triển lớn mạnh trong ba thập kỷ qua.

FDE không có tài sản này. Khả năng của mô hình đang thay đổi nhanh chóng—ngày hôm nay vẫn cần các chuỗi Prompt được thiết kế cẩn thận, nhưng phiên bản mô hình tiếp theo có thể giải quyết chỉ bằng một câu. Việc “tích lũy phương pháp luận” trong tư vấn sẽ nhanh chóng mất giá trước tốc độ này. Do đó, FDE không thể sử dụng mô hình tái sử dụng tài sản, mà phải chạy lại toàn bộ quy trình đóng mỗi lần—đánh giá lại ranh giới mô hình, chọn lại bộ công cụ và lắp ráp lại hình thái sản phẩm. Dù trông có vẻ kém hiệu quả, nhưng đây thực sự là cách duy nhất để theo kịp tốc độ của mô hình.

Bạn có biết không—Product Overhang là gì? Trong bài viết trước “Gửi đến những cá nhân siêu việt” [4], tôi đã giải thích thuật ngữ này: năng lực mô hình đã vượt quá hình thái sản phẩm hiện tại, nhưng chưa có lối vào sản phẩm, quyền hạn và ngữ cảnh để biến nó thành hiện thực. Giá trị của vị trí FDE về bản chất là biến những Overhang treo lơ lửng trong bối cảnh khách hàng thành một sản phẩm cụ thể có thể vận hành. Khách hàng không mua quyền gọi API của mô hình, mà là khả năng “có người có thể biến những Overhang này thành hiện thực trong doanh nghiệp của tôi”.

Điều này cũng giải thích sự khác biệt ở dòng “cấu trúc dự án”. Cấu trúc tiêu chuẩn của một dự án tư vấn là SOW (Statement of Work) + WBS (Work Breakdown Structure) + nghiệm thu theo giai đoạn: trong hợp đồng phải nêu rõ sẽ giao gì, giao khi nào và nghiệm thu theo tiêu chuẩn nào. Hệ thống cấu trúc này dựa trên giả định rằng mục tiêu đã được xác định rõ ràng trước khi ký hợp đồng.

Dự án của FDE không áp dụng được cách làm này. Câu khách hàng hay nói nhất là: “Tôi biết AI nên giúp được tôi làm gì đó, nhưng tôi không biết đó là gì.” Mục tiêu chính bản thân đã là một phần của dự án. Vì vậy, FDE không nhận SOW, mà nhận mission — một hướng đi tương đối mơ hồ; sau đó dùng iteration từng vòng để làm rõ hướng đi; cuối cùng, trong một vòng nào đó, biến những hiểu biết về mô hình đã tích lũy thành một hình thái sản phẩm.

Hàng “giao deliverable” cũng đáng để mở rộng. Sau khi FDE rời đi, những gì còn lại trong hệ thống khách hàng là một chức năng hoạt động được—có thể rất nhỏ, có thể xấu xí, có thể không có giao diện người dùng, nhưng nó thực sự được gọi, được sửa đổi và bị chỉ trích mỗi ngày. Giao deliverable của tư vấn là PPT và báo cáo quản lý thay đổi, dù trong dự án đã từng viết mã hay cấu hình ERP, cuối cùng những gì còn lại trong tay các nhà quản lý cấp cao của khách hàng vẫn là một tài liệu phương pháp luận.

Hàng “hào sâu” là tinh tế nhất. Hào sâu của FDE là cảm nhận thực tế về giới hạn năng lực của mô hình—bạn đã chạy bao nhiêu kịch bản khách hàng thực tế trong tháng này, thì bạn sẽ hiểu rõ hơn người khác những việc gì Claude 4.7 có thể làm và những việc gì phải chờ Claude 5. Cảm nhận này không thể viết vào PPT, cũng không thể đưa vào kho tri thức; nó chỉ tồn tại trong đầu những kỹ sư đã từng thực hành trong 90 ngày gần đây.

Vì vậy, lần sau nếu ai đó nói “FDE chẳng phải là phiên bản mới của Accenture”, bạn có thể trả lời: Các kỹ sư của Accenture đi tái thiết kế quy trình của khách hàng, còn FDE đi tái khám phá ranh giới của mô hình. Tài sản của người前者 có thể tích lũy trong mười năm, còn tài sản của người sau phải tái sinh lại sau 90 ngày.

Nếu việc nói “FDE là phiên bản mới của Accenture” là sự hiểu lầm cấp độ một, thì việc nói “FDE là dịch vụ外包 phần mềm đắt đỏ” chính là cấp độ hai. Cấp độ này mang tính gây hiểu lầm cao hơn, vì các bằng chứng bề ngoài dường như rất đầy đủ: FDE thực sự đến tận nơi khách hàng để viết mã, thực sự tùy chỉnh chức năng theo nghiệp vụ của khách hàng, và thực sự tuân thủ giờ làm việc của khách hàng. Nhìn bề ngoài, nó chẳng khác gì các kỹ sư外包.

But just by looking at the feedback loop, the difference cannot be hidden.

Sự khác biệt quan trọng nhất trong hình này không phải là phần trên hình đơn giản đến mức nào, mà là phần dưới hình có thêm một chuỗi phản hồi kéo dài đến các công ty mô hình. Chuỗi này không phải là yếu tố trang trí, mà chính là lý do thực sự tồn tại của vị trí FDE. Khi phân tích sự khác biệt này, ít nhất có bốn cặp so sánh.

Cái được tiếp nhận là khác nhau. Ngoại gói tiếp SOW – một danh sách yêu cầu đã được xác định rõ ràng trước khi ký hợp đồng: cần làm những chức năng nào, dùng công nghệ gì,验收 tiêu chuẩn ra sao, vi phạm thì bồi thường thế nào. FDE tiếp nhận mission – khách hàng cũng chưa rõ mình cần gì, chỉ biết “AI nên giúp tôi làm được điều gì đó”. SOW dựa trên sự chắc chắn, mission dựa trên sự khám phá. Hai cách khởi động dự án hoàn toàn khác nhau.

Phạm vi thực hiện khác nhau. Các nhà thầu ngoài thực hiện giao deliverables cục bộ — một mô-đun, một trang web, một đường ống dữ liệu, hoàn thành xong thì đóng gói và rời đi, chuyển sang khách hàng tiếp theo. FDE thực hiện toàn bộ quy trình từ đầu đến cuối — bắt đầu từ những điểm đau của doanh nghiệp, lựa chọn mô hình, thiết kế hình thái sản phẩm, đến việc duy trì và tỷ lệ rời bỏ của người dùng thực tế sau khi triển khai.

Cách tính phí khác nhau. Điều này trái với trực giác nhất. Một công ty mô hình gửi FDE đến khách hàng tại chỗ, điều họ quan tâm không chỉ là dự án này thu bao nhiêu phí tư vấn, mà còn là: Khách hàng này sẽ tiêu thụ bao nhiêu token trong tương lai? Liệu họ có trở thành khách hàng giữ chân không? Liệu họ có mở rộng sang nhiều dòng sản phẩm hơn không? KPI thực sự của FDE là đường cong tiêu thụ token dài hạn của mô hình, chứ không phải con số trên biên bản nghiệm thu dự án.

Phản hồi có hướng đi khác nhau. Đây là nhóm sâu nhất trong bốn nhóm. Trong các dự án outsourced, phản hồi từ khách hàng chỉ dừng lại ở công ty outsourced và không ảnh hưởng đến sản phẩm mà công ty outsourced sẽ bán cho người khác trong tương lai. Ngược lại, phản hồi từ FDE sẽ quay ngược trở lại vào lộ trình của công ty mô hình – mỗi vấn đề, mỗi thất bại trong Prompt, mỗi lỗi gọi công cụ mà khách hàng gặp phải trong môi trường thực tế đều trở thành đầu vào cho bộ dữ liệu huấn luyện phiên bản tiếp theo, thiết kế công cụ phiên bản tiếp theo và tính năng sản phẩm phiên bản tiếp theo. Nói cách khác, mỗi khách hàng triển khai FDE đối với công ty mô hình đều đồng thời là một đối tác thiết kế tự nhiên.

Đây mới là lý do thực sự khiến các công ty mô hình sẵn sàng trả lương cao để tuyển FDE. Họ không chỉ bán một dịch vụ, mà còn thu thập tín hiệu về hình thái sản phẩm thực tế tại địa điểm khách hàng. Những tín hiệu này không thể mua được, không thể thu thập được, cũng không thể tìm ra thông qua khảo sát bảng hỏi—chúng chỉ có thể được mang về bởi một kỹ sư cụ thể, sau khi trực tiếp va chạm vài lần với quy trình làm việc của khách hàng cụ thể.

Bạn có biết không—tổng gói lương của FDE tại OpenAI và Anthropic có thể lên tới bao nhiêu? Dựa trên dữ liệu công khai từ Levels.fyi về kỹ sư phần mềm tại Anthropic [8], mức trung vị tổng gói của SDE cấp cao đã đạt 710.000 USD. Vị trí FDE có rủi ro cao hơn—phải đối mặt với sự không chắc chắn về năng lực mô hình, sự không chắc chắn về nghiệp vụ khách hàng, và cả sự không chắc chắn về hình thái sản phẩm, do đó theo tổng hợp ngành [9], tổng gói lương của FDE cấp trung đến cao tại các phòng thí nghiệm AI tiên tiến thường nằm trong khoảng 350.000 - 550.000 USD, còn cấp Staff trở lên có thể đạt trên 630.000 USD. Mức lương này không phải trả cho “thời gian làm việc外包”, mà là trả cho người chịu trách nhiệm tổng hợp ba yếu tố rủi ro: “sản phẩm + khách hàng + mô hình”. > Nhìn lại năm 2006, khi tôi vừa bắt đầu công việc, làm việc tại một doanh nghiệp nhà nước Trung Quốc, lúc đó chúng tôi đang trong quá trình chuyển đổi số, khi ấy các chuyên gia tư vấn từ Accenture được mời đến làm việc tại chỗ, tập đoàn phải trả cho Accenture 3.500 nhân dân tệ mỗi ngày, và họ ở lại suốt vài năm, được giới truyền thông thời đó gọi là “kim lĩnh”. Sau đó tôi chuyển sang làm tại công ty SAP của Đức, SAP còn định nghĩa luôn một danh xưng trong ngành tư vấn—chuyên gia tư vấn SAP chính là biểu tượng của “kim lĩnh”. Như vậy, có thể thấy mức lương của FDE ít nhất trong vòng 24–36 tháng tới sẽ tiếp tục tăng, và nhu cầu cũng đang ổn định gia tăng.

Ngoại gói là khai thác lợi thế lao động, còn FDE là cảm biến tiền tuyến. Lẫn lộn hai việc này sẽ khiến bên giao làm sai lầm khi nghĩ có thể tuyển FDE theo cách SOW, đồng thời khiến ứng viên đối xử với FDE như một công việc ngoại gói. Cả hai phía đều sẽ nhanh chóng đụng phải tường.

Nhiều người nhầm tưởng rằng thuật ngữ FDE do OpenAI sáng tạo ra. Thực tế không phải vậy. Nó có hai nguồn gốc, một xuất phát từ Palantir, một từ các công ty mô hình thế hệ mới sau năm 2023. Khi đặt hai nguồn gốc này cạnh nhau, bạn sẽ hiểu rõ hơn về thực chất công việc của vị trí FDE.

Hãy xem một dòng thời gian trước.

Cây rễ đầu tiên là Palantir.

Palantir được thành lập năm 2003 bởi Peter Thiel, Alex Karp, Joe Lonsdale và những người khác, với khách hàng đầu tiên là các cơ quan tình báo Mỹ. Bản thân Karp không có nền tảng về khoa học máy tính—ông từng theo học tiến sĩ triết học cùng nhà triết học Jürgen Habermas tại Frankfurt, và mới được Thiel mời về làm CEO sau khi trở về Mỹ. Vị trí FDE chính là được hình thành từ sự kết hợp “CEO phi truyền thống + khách hàng cực kỳ bí mật” của Karp: Bài viết tổng quan của 36Kr [10] viết rất rõ ràng rằng, Palantir đã bị các cơ quan tình báo chỉ trích nặng nề trong giai đoạn đầu vì các kỹ sư không thể tiếp cận các bối cảnh thực tế, dẫn đến yêu cầu bị chuyển đổi qua nhiều tầng lớp và biến dạng. Sau đó, Palantir đã đạt được một thỏa thuận—cho phép kỹ sư của họ trực tiếp làm việc tại địa điểm khách hàng, cùng làm việc với các nhà phân tích tình báo. Mô hình này sau đó được Shyam Sankar hệ thống hóa, trở thành tiền thân của FDE.

Đến năm 2009, FDE mở rộng sang lĩnh vực thương mại. Khi JPMorgan triển khai nền tảng Metropolis của Palantir, 120 FDE được bố trí để giám sát mối đe dọa nội bộ. Kể từ thời điểm này, FDE không còn chỉ là “phái kỹ sư đi công tác”, mà trở thành một chiến lược nhúng khách hàng có hệ thống: tích hợp Foundry/Gotham thực sự vào luồng hoạt động kinh doanh của khách hàng, thay vì chỉ cấp giấy phép rồi rời đi.

Palantir có một tiêu chuẩn phản trực giác trong tuyển dụng FDE—không yêu cầu bằng cấp về Khoa học Máy tính. Điều này có thể đưa vào phần “Bạn có biết?”

Bạn có biết không—Palantir FDE không yêu cầu bằng ngành CNTT? Theo các tiêu chí tuyển dụng của Palantir được tổng hợp từ SkillScouter [11] và trang careers chính thức của Palantir [12], Palantir rõ ràng chào đón các ứng viên không đến từ ngành CNTT, với những người được tuyển dụng gần đây đến từ các lĩnh vực như kỹ thuật cơ khí, kinh tế học, triết học. Hai điều thực sự quan trọng là: có khả năng hành động trong điều kiện thông tin không đầy đủ, và có thể nói chuyện trực tiếp với khách hàng cấp C. Bằng cấp CNTT là điểm cộng, không phải vé vào cửa. Chính Karp là mẫu người đầu tiên thể hiện tiêu chuẩn này—một CEO tốt nghiệp triết học, dẫn dắt đội ngũ FDE gồm những người tốt nghiệp vật lý, toán học và triết học.

Cây rễ thứ hai là các công ty mô hình thế hệ mới sau năm 2023.

Sau khi ChatGPT được phát hành vào cuối năm 2022, OpenAI nhanh chóng nhận ra một điều: việc gắn API mô hình lên tài liệu và để khách hàng tự kết nối là hoàn toàn không khả thi. Khách hàng không phải không muốn sử dụng, mà là không biết phải làm thế nào — họ có các vấn đề kinh doanh, nhưng chưa có hình thái sản phẩm. Vì vậy, các công ty như OpenAI, Anthropic, Cohere, Scale, Glean, Sierra, Hebbia, Decagon bắt đầu tuyển dụng hàng loạt FDE.

Đợt FDE này học theo playbook của Palantir—gửi kỹ sư đến tận địa điểm khách hàng để triển khai toàn bộ quy trình từ đầu đến cuối. Nhưng phương tiện sản phẩm đã hoàn toàn khác biệt: FDE thời Palantir tập trung vào tích hợp dữ liệu và tùy chỉnh giao diện người dùng, trong khi FDE thế hệ mới lại tập trung vào thiết kế Prompt, sắp xếp Agent, gọi công cụ và nhúng quy trình làm việc.

Trong bài viết chuyên sâu về FDE của Pragmatic Engineer [13], phiên bản mới này được gọi là “embedded with enterprises to make Claude solve real, specific, high-value problems”—cách diễn đạt gần như giống hệt với Palantir ngày xưa, chỉ thay “dữ liệu” bằng “mô hình”.

Khi xem hai gốc này cùng nhau, bạn có thể nhận ra một loạt điểm tương đồng và khác biệt rõ ràng.

Điểm chung: Khách hàng không mua phần mềm. Khách hàng mua là “kỹ sư + bộ công cụ có thể giải quyết vấn đề của tôi”. Điều này thực sự là bất thường trong lịch sử phần mềm doanh nghiệp 30 năm qua. SAP, Oracle, Salesforce bán chính là phần mềm — kỹ sư chỉ là tài nguyên hỗ trợ để “giúp khách hàng tiếp cận được phần mềm này”. Palantir thì ngược lại: công cụ tồn tại như một đòn bẩy để “giúp FDE giải quyết vấn đề cho khách hàng”. Các công ty mô hình thế hệ mới kế thừa mối quan hệ đảo ngược này — OpenAI không bán giấy phép GPT-4, mà bán “chúng tôi có thể dùng GPT-4 cùng FDE để giúp bạn tự động hóa dịch vụ khách hàng”.

Sự khác biệt: Thời kỳ Palantir thiên về tích hợp OPS—trọng tâm là tích hợp dữ liệu, mô hình hóa ontology và quản trị quyền truy cập. Thế hệ mới thiên về triển khai năng lực mô hình—trọng tâm là thiết kế Prompt, sắp xếp Agent và tối ưu hóa tỷ lệ giữ chân. Thế hệ trước giống phiên bản nâng cao của nhà tích hợp hệ thống, thế hệ sau giống phiên bản mở rộng của kỹ sư sản phẩm.

Một sự thật thú vị khác: Nhiều FDE đầu tiên của Palantir sau này đã trở thành doanh nhân hoặc trực tiếp gia nhập các công ty mô hình thế hệ mới. Trong đội ngũ ban đầu của Anthropic, OpenAI, Sierra, Hebbia, có thể liệt kê ra một danh sách dài những cái tên từng làm việc tại Palantir. Đây không phải là sự ngẫu nhiên—vị trí FDE bản thân nó buộc một người phải đồng thời gánh vác rủi ro sản phẩm, rủi ro khách hàng và rủi ro kỹ thuật, gần như là một khóa huấn luyện dành cho doanh nhân. Tác giả thích xem Palantir như một trung tâm huấn luyện doanh nhân ẩn danh: nó không chỉ đào tạo ra các kỹ sư, mà còn là những người biết cách thúc đẩy một ý tưởng từ con số không đến bước đầu tiên trong điều kiện thông tin không đầy đủ. Hai nhánh gốc cuối cùng đã hội tụ sau năm 2023.

Sự hội tụ của hai nhánh chủ yếu xảy ra ở nước ngoài. Trong nước, thuật ngữ FDE chưa xuất hiện lâu, nhưng nội dung công việc mà nó tương ứng không phải là xuất hiện một cách bỗng dưng. Để hiểu FDE ở trong nước, cần trước tiên nhìn rõ hai tiền thân bản địa của nó, sau đó nhận ra ba sự khác biệt về điều kiện địa phương giữa nó và FDE phiên bản Mỹ.

Hai tiền thân bản địa

Người tiền nhiệm đầu tiên là kiến trúc sư giải pháp của nhà cung cấp đám mây. Trong thập kỷ qua, Alibaba Cloud, Tencent Cloud và Huawei Cloud đã đào tạo ra một đội ngũ kiến trúc sư giải pháp (SA) hoàn chỉnh, chuyên thuyết trình kiến trúc cho khách hàng, viết POC, lập kế hoạch di chuyển và phối hợp triển khai đến khi đưa vào vận hành. Bên trong Huawei còn có một chuỗi chuyên biệt “kỹ sư triển khai” chịu trách nhiệm thực hiện dự án tại trung tâm dữ liệu của khách hàng. Hệ thống này đã đảm nhận 80% công việc của FDE, nhưng trọng tâm vẫn tập trung vào giai đoạn trước bán hàng và triển khai — trách nhiệm lặp lại sản phẩm toàn diện không nằm trong tay SA; nếu yêu cầu thay đổi, phải đi qua quy trình thay đổi, nếu thay đổi mô hình, phải chờ lịch trình từ trụ sở chính.

Tiền thân thứ hai là một chuỗi mới xuất hiện trong các công ty khởi nghiệp AI. MiniMax đang đăng tuyển “Chuyên gia giải pháp bán hàng AI” trên BOSS Zhipin, và các công ty mô hình như Moonshot, Zhipu, Tongyi, Hunyuan cũng đều đăng tuyển các vị trí tương tự. Tên gọi có chút khác biệt, nhưng nội dung JD có mức độ tương đồng cao: hiểu bối cảnh khách hàng, thực hiện demo, điều chỉnh Prompt, chạy RAG, viết phương án giao hàng, phối hợp với đội kỹ thuật khách hàng để đưa lên sản phẩm. Những vị trí này mới thực sự là “FDE trong nước” theo nghĩa đúng đắn.

Ba sự khác biệt về thủy thổ

Việc triển khai nội bộ và tuân thủ dữ liệu đã làm suy yếu mô hình chỉ gọi mô hình thuần túy. Khách hàng doanh nghiệp trong nước có yêu cầu cao hơn nhiều so với thị trường Mỹ về việc dữ liệu không ra khỏi phạm vi, kiểm soát được trọng số mô hình và khả năng audit có thể truy xuất nguồn gốc. Trong một dự án FDE, khối lượng công việc chỉ gọi API và chạy Prompt có thể chỉ chiếm 30%, còn 70% còn lại là di chuyển mô hình đến phòng máy khách hàng, thiết lập xác thực, kết nối với nền tảng dữ liệu và thực hiện đăng ký tuân thủ.

Khả năng mô hình vẫn đang cố gắng theo kịp SOTA, không gian phát huy bị thu hẹp xuống cấp độ kỹ thuật. Các công ty Mỹ như OpenAI và Anthropic có thể thuyết phục khách hàng bằng chính khả năng của mô hình; trong khi đó, các mô hình trong nước như Tongyi, DouBao, Kimi, GLM và DeepSeek có sự khác biệt về khả năng không quá lớn, nên điểm đánh giá của khách hàng tập trung nhiều hơn vào các năng lực kỹ thuật như sắp xếp Agent, chất lượng truy vấn RAG, tích hợp công cụ và thiết kế Workflow. Tại Trung Quốc, FDE cạnh tranh không phải ở chỗ “mô hình của tôi mạnh đến đâu”, mà ở chỗ “tôi có thể thực sự triển khai được nghiệp vụ này hay không”.

Sự sẵn sàng chi trả và nhịp độ định giá của phân khúc B không nhất quán với Mỹ. Mô hình của Palantir “trước tiên cử FDE đến hiện trường, sau đó thu phí đăng ký cao” khó có thể sao chép trực tiếp. Ngân sách của khách hàng trong nước thường theo chu kỳ mua sắm hàng năm, thiên về hình thức theo dự án, và mô hình kinh doanh của FDE thường là sự pha trộn giữa đăng ký, cấp phép riêng tư và giao dự án.

Một vị thế độc đáo: FDE nội bộ

Nhiều đội ngũ AI trong các tập đoàn lớn đang bắt đầu sử dụng mô hình FDE để phục vụ "khách hàng nội bộ". Alibaba Cloud PAI đã cử kỹ sư đến làm việc tại Taobao, trong khi Tencent Hunyuan cũng có cơ chế tương tự để kết nối với WeChat và các bộ phận quảng cáo. Trên JD, các vị trí được đăng tải là "Kỹ sư triển khai ngành", "Kỹ sư ứng dụng AI", "Chuyên gia kinh doanh thông minh"—về bản chất đều là các FDE nội bộ, giúp đưa năng lực của đội ngũ mô hình chạy end-to-end đến phía kinh doanh. Điều này mang đến cho các nhà lãnh đạo tập đoàn một hướng đi mới: chỉ cần vài FDE nội bộ駐点 tại phía kinh doanh, tạo ra demo đầu tiên và cung cấp dữ liệu ROI cho quản lý kinh doanh, những rào cản giữa các phòng ban sẽ tan biến nhanh hơn nhiều so với việc tổ chức mười cuộc họp đồng bộ.

Trong bài viết trước của tôi, “Gửi đến các cá nhân siêu việt” [4], tôi đã đề cập đến năm động cơ của cá nhân siêu việt: tò mò mạnh mẽ, tinh thần khám phá và sáng tạo mạnh mẽ, khả năng tự học cao, động lực tự thân mạnh mẽ và khả năng thực hành tốt. Năm đặc điểm này là vé vào cửa của FDE, nhưng không phải tất cả. Vị trí FDE còn yêu cầu một tập hợp các đặc tính bổ sung rất cụ thể, đồng thời có một số kiểu tính cách rõ ràng không phù hợp. Tôi đã chứng kiến quá nhiều kỹ sư xuất sắc chuyển sang FDE nhưng gặp khó khăn trong thích nghi — vấn đề thường không nằm ở năng lực, mà ở tính cách và sở thích công việc.

Năm đặc điểm phù hợp với FDE

Đừng ngại bán hàng và giao tiếp. Công việc hàng ngày của FDE không phải là đóng cửa lập trình, mà là trực tiếp làm việc với CTO, người phụ trách kinh doanh, người mua hàng, chuyên viên tuân thủ và IT của khách hàng. Một nhịp điệu điển hình: CTO khách hàng ngắt bạn giữa buổi demo, phản ứng của FDE không thể là “Tôi về sửa lại phiên bản khác, tuần sau quay lại”, mà phải ngay lập tức mở IDE để chỉnh Prompt và chạy lại ngay trước mặt họ. “Khách hàng đang ở đây, tôi đang sửa” là trạng thái bình thường của FDE.

Hãy tận hưởng vùng mờ. FDE không nhận được một PRD rõ ràng, mà chỉ là một câu: “Chúng tôi muốn làm gì đó với AI.” Chính khách hàng cũng không rõ họ muốn gì, và cần FDE đồng hành cùng họ để biến những kỳ vọng mơ hồ này thành hình thái cụ thể. Nếu bạn chỉ có thể hành động khi có nhu cầu rõ ràng, thì mỗi ngày FDE sẽ khiến bạn lo lắng.

Có nền tảng kỹ thuật vững chắc nhưng không yêu cầu 10x. FDE không cần bạn là người viết mã sạch nhất hay có thuật toán sâu nhất công ty, mà cần bạn có thể triển khai hoàn chỉnh từ đầu đến cuối: frontend tạo được một trang web có thể tương tác, backend xây dựng được một dịch vụ chạy được, và mô hình kết nối được với nguồn dữ liệu nghiệp vụ. Trong thế giới FDE, “gần được là được” không phải là điểm yếu, mà là một đức tính.

Thích được phản hồi rèn giũa. Trong công việc của FDE, có rất nhiều lúc “bị khách hàng mắng rồi phải làm lại”: hôm nay demo, ngày mai bộ phận kinh doanh nói “Đây không phải cái tôi muốn”; phương án đã thống nhất tuần trước, tuần này khách hàng thay giám đốc mới lại phải làm lại. Người phù hợp với vai trò FDE sẽ coi những phản hồi này như nhiên liệu, chịu trách nhiệm toàn diện từ đầu đến cuối, không đổ lỗi cho “yêu cầu không được nêu rõ”.

Nhạy cảm với ranh giới mô hình. Đây là điểm kỹ thuật nhất và ẩn nhất. FDE cần có khả năng phán đoán nhiệm vụ nào phù hợp để LLM thực hiện, nhiệm vụ nào không nên, và nên fallback như thế nào — sự nhạy cảm này không thể thấy qua các bài báo, mà chỉ có thể học được từ những trường hợp thất bại. Khi tích lũy đủ các mẫu thất bại, FDE sẽ hình thành trí nhớ cơ bắp về ranh giới mô hình: tình huống nào dùng RAG, tình huống nào áp dụng quy tắc, và tình huống nào bắt buộc phải cung cấp lối fallback cho con người.

Bốn nhóm người không phù hợp với FDE

Người đam mê kỹ thuật muốn ẩn mình trong mã nguồn. FDE dành khoảng 50% thời gian không phải để viết mã — mà là trong các cuộc họp khách hàng, phối hợp nội bộ, thảo luận sản phẩm và đẩy tiến hợp đồng. Nếu niềm vui của bạn đến từ việc viết mã liên tục bốn giờ mà không bị làm phiền, FDE sẽ khiến bạn rơi vào tình trạng kiệt sức tinh thần lâu dài.

Người cần OKR mới có thể hành động. Mục tiêu của FDE nằm ở phía khách hàng, không nằm trên bảng đánh giá hiệu suất của bạn. Tiến độ công việc được xác định bởi các mốc dự án của khách hàng, sự thay đổi năng lực mô hình và phán đoán cá nhân về bối cảnh. Người quen với việc “phải có OKR mới biết phải làm gì” sẽ không tìm được điểm neo.

Những người coi trọng việc thăng tiến hơn là tác phẩm. FDE không có lợi thế trong hệ thống thăng tiến của các công ty lớn — các chỉ số như mức độ hài lòng của khách hàng, số lượng dự án ký kết, tỷ lệ tái sử dụng không có trọng số bằng lượng mã nguồn và tần suất triển khai trong đánh giá cấp bậc. Nếu động lực công việc của bạn là thăng tiến đứng đầu, thì FDE không phải là lựa chọn tốt.

Những người phản cảm với bối cảnh thương mại. FDE phải hiểu P&L, ROI, quy trình mua hàng và yêu cầu tuân thủ của khách hàng. Nếu bạn tự nhiên cảm thấy khó chịu khi nói đến tiền bạc, hợp đồng và logic kinh doanh, công việc FDE sẽ khiến bạn cảm thấy mình đang bán rẻ lý tưởng công nghệ.

Danh sách tự kiểm tra

7 câu hỏi, mỗi câu tương ứng với một tình huống thực tế trong công việc của FDE. Nếu trả lời “có” cho hơn 5 câu, bạn nên cân nhắc nghiêm túc về FDE; nếu trả lời “có” cho ít hơn 3 câu, hãy cân nhắc kỹ lưỡng.

1. Bạn có sẵn sàng chuyển 50% thời gian mỗi ngày từ mã nguồn sang các cuộc họp khách hàng, trả lời tin nhắn và điện thoại không?

2. Khi khách hàng nói với bạn “Cái này không được, tôi cũng không thể giải thích tại sao”, phản ứng đầu tiên của bạn là sự tò mò hay sự bực bội?

3. Không ai viết PRD cho bạn, bạn có thể cùng Claude Code hoàn thành một bản mẫu có thể hiển thị cho khách hàng trong vòng một tuần không?

4. Cùng một đợt giao hàng, khách hàng yêu cầu bạn chỉnh sửa 8 phiên bản, bạn vẫn có thể giữ được khả năng phán đoán, thay vì thực hiện một cách máy móc?

5. Khi mô hình đưa ra câu trả lời sai, phản ứng đầu tiên của bạn là thiết kế fallback hay phàn nàn rằng mô hình không tốt?

6. Bạn có sẵn sàng ký hợp đồng, viết báo cáo, đi nghiệm thu khách hàng và trao đổi với bộ phận pháp lý về các điều khoản tuân thủ không?

7. Bạn có thể chấp nhận nguyên mẫu nhanh và thất bại nhanh không?

Năm đặc điểm, bốn loại hình ảnh ngược, bảy câu hỏi tự kiểm tra — cuối cùng đều hướng đến cùng một câu hỏi: Bạn có sẵn sàng để cảm giác sản phẩm, năng lực kỹ thuật và phán đoán kinh doanh của mình được đồng thời rèn luyện trong cùng một quy trình làm việc không?

Bài trước, tác giả đã thảo luận về “động cơ con người”: sự tò mò, tinh thần khám phá, khả năng tự học, động lực tự thân và kỹ năng thực hành, làm thế nào để những yếu tố này được kích hoạt một cách trọn vẹn trong các tập đoàn lớn. Bài này bàn về một vấn đề khác – hình thái vị trí công việc. FDE là hình thái vị trí công việc mới đầu tiên trong cuộc cách mạng AI có tên gọi, mức lương cụ thể, mô tả công việc tuyển dụng và xác thực từ khách hàng trả tiền. Nó không phải là đồng nghĩa với khái niệm “cá nhân siêu việt”, mà là tọa độ đầu tiên trong đợt tái cấu trúc này được hiện thực hóa từ ảo sang thực.

FDE không phải là điểm cuối. Theo nhận định của tác giả, FDE chỉ là hình thái đầu tiên trong phân công mới được đặt tên. Sau đó sẽ xuất hiện Forward Deployed PM, Forward Deployed Designer, Forward Deployed Researcher—tất cả các vai trò gắn chặt với bối cảnh khách hàng và cần phát triển sản phẩm trong vùng mờ sẽ đều có phiên bản “tiền triển khai” riêng của mình. Tên vị trí sẽ thay đổi, nhưng logic cốt lõi thì giống nhau: năng lực mô hình đi trước, hình thái sản phẩm theo sau, và cấu trúc vị trí được tái phân chia theo luồng công việc.

Dành một câu cho ba nhóm độc giả.

Dành cho những người kỹ thuật: FDE không yêu cầu bạn là người viết code giỏi nhất trong công ty, nhưng nó yêu cầu bạn sẵn sàng dành một nửa thời gian từ code chuyển sang phía khách hàng. Nếu câu trả lời của bạn là “sẵn sàng”, thì cửa sổ thị trường vừa mở, các công ty mô hình hàng đầu trong nước, nhà cung cấp đám mây và các đội AI nội bộ của các tập đoàn lớn đều đang tăng tốc tuyển dụng. Nếu câu trả lời là “không sẵn sàng”, thì cũng không sao, trong phân công mới sẽ xuất hiện những vị trí khác dành cho bạn.

Gửi đến HR và OD: Hãy cảnh giác với “sự tách biệt giữa tên gọi và thực tế”. Công ty bạn có thể đã có một nhóm FDE đang hoạt động, nhưng trên mã vị trí lại ghi là “Chuyên gia giải pháp”, “Kiến trúc sư ngành”, “Kỹ sư ứng dụng AI”. Hãy nhận diện họ, phân loại lại và tạo cho họ một con đường phát triển phù hợp với nội dung công việc của họ — điều này hiệu quả hơn nhiều so với việc tuyển dụng nhân sự mới từ đầu.

Đối với người quản lý: Chế độ FDE không chỉ có thể áp dụng bên ngoài, mà còn có thể áp dụng bên trong. Việc thiết lập vài “FDE nội bộ” tại các bộ phận nghiệp vụ, đưa năng lực của đội ngũ mô hình chạy xuyên suốt vào quy trình nghiệp vụ, có thể hiệu quả hơn nhiều so với việc thành lập một bộ phận AI mới và tổ chức mười cuộc họp phối hợp giữa các đội nhóm. Những bức tường bộ phận không bị xóa bỏ bởi thiết kế tổ chức, mà bị xóa bỏ bởi một demo có thể vận hành được.

Sự chuyển đổi nghề nghiệp trong thời đại AI đã bắt đầu, FDE là tín hiệu đầu tiên, cho chúng ta thấy: tốc độ thay đổi của năng lực mô hình đã nhanh đến mức tạo ra những vị trí công việc mới. Tác giả muốn gửi đến độc giả một câu hỏi cụ thể—nếu ba năm nữa, sơ đồ tổ chức công ty của bạn thêm ba vị trí mới, bạn đoán đó sẽ là ba vị trí nào? Câu trả lời cho câu hỏi này còn hữu ích hơn cả việc đọc xong bài viết này.

👦🏻 Tác giả: Henry (Đội ngũ DeerFlow) [1]