Tóm tắt nhanh: Nếu đã dùng coding agent để xây ứng dụng, phần bạn cần học thêm để trở thành Forward Deployed Engineer (FDE) thường nằm ngoài việc viết code: hiểu quy trình doanh nghiệp, kết nối hệ thống và đưa giải pháp vào production. Cách bắt đầu thực tế là chọn một vấn đề có người đang xử lý thủ công, đo hiện trạng, xây bản chạy thử rồi kiểm chứng kết quả. Portfolio (hồ sơ năng lực) nên thể hiện kết quả đo được, thay vì chỉ liệt kê những công cụ AI bạn biết dùng.
Bạn có thể dùng coding agent dựng giao diện, viết API (Application Programming Interface) và sửa lỗi trong một phiên làm việc. Khi đưa phần mềm vào doanh nghiệp, bạn còn phải giải quyết chuyện dữ liệu nằm ở đâu, ai chịu trách nhiệm nếu hoá đơn sai và công việc tiếp tục thế nào khi hệ thống hỏng.
Một tin tuyển FDE Applied AI cụ thể của Anthropic, đã gỡ ngày 18/6/2026, yêu cầu kinh nghiệm production và làm việc với khách. Nguồn: Anthropic trên Built In. Trong khoảng 1.000 tin tuyển FDE được Henley Wing Chiu phân tích, công bố ngày 18/11/2025 và cập nhật 25/1/2026, 60% số tin có ghi kinh nghiệm yêu cầu từ 3 đến 5 năm. Nguồn: Bloomberry.
Con đường đào tạo chính thức như Claude Frontier Academy, được Anthropic công bố ngày 2/10/2026, hiện theo hình thức đề cử, lứa đầu gồm kỹ sư từ các hãng tư vấn và tập đoàn lớn. Nguồn: Anthropic. Với người đang làm software engineer hoặc vibe coding (dùng AI viết phần lớn code từ mô tả bằng lời), mình nghiêng về cách tự học từ một bài toán kinh doanh có thật.
FDE là người đưa công nghệ vào giải quyết vấn đề trong môi trường vận hành của khách hàng. Bạn có thể đọc bài 1: Forward Deployed Engineer (FDE) là gì? để hiểu vai trò và bài 2: FDE hay tư vấn đổi tên? để phân biệt triển khai kỹ thuật với tư vấn.
Người đã dùng coding agent còn thiếu gì để làm FDE?
Bạn cần bù những năng lực nằm giữa code và kết quả kinh doanh, chứ không nhất thiết phải học thêm một coding agent. Nguyễn Phi Vân chia năng lực FDE thành năm nhóm: công nghệ, AI, doanh nghiệp, kết nối hệ thống và làm việc với con người. Nguồn: Nguyễn Phi Vân, 6/10/2026.
Bảng dưới đây là nhận định của mình về khoảng cách thường gặp ở người đã dùng coding agent:
| Nhóm năng lực | Thường đã có gì, còn thiếu gì? |
|---|---|
| Công nghệ | Biết tạo ứng dụng, nhưng cần đọc, debug và chịu trách nhiệm với code agent viết, database và deploy. |
| AI | Biết dùng prompt, nhưng cần hiểu LLM (Large Language Model), RAG (Retrieval-Augmented Generation), agent, MCP (Model Context Protocol) và eval, đặc biệt là khi nào không cần AI. |
| Doanh nghiệp | Biết nhận yêu cầu, nhưng cần tìm vấn đề thực, người chịu trách nhiệm và KPI (chỉ số đo hiệu quả). |
| Kết nối hệ thống | Biết gọi API, nhưng cần làm việc với dữ liệu và các hệ thống đang vận hành như CRM (Customer Relationship Management) hay ERP (phần mềm quản lý vận hành như kế toán, kho, mua hàng). |
| Con người | Biết trao đổi yêu cầu, nhưng cần quan sát, nghe, giải thích rủi ro và dám nói khi đang giải sai vấn đề. |
Bạn có thể bù các năng lực này qua một bài toán thử gồm năm bước: quan sát hiện trạng, quyết định chỗ nào cần AI, dựng bản chạy thử, viết eval và đặt điểm con người kiểm tra, cuối cùng đo trước sau và bàn giao.
Bước 1: chọn một bài toán thật và quan sát trước khi xây
Hãy chọn một quy trình nhỏ đang được làm thủ công, có người chịu trách nhiệm và có thể đo trước khi thay đổi. Mình dùng xuyên suốt bài một tình huống giả định, chưa được triển khai hay đo kết quả: một công ty phân phối nhỏ có nhân viên mất nhiều giờ mỗi tuần đối chiếu hoá đơn giữa Excel, phần mềm kế toán và ảnh gửi qua Zalo.
Bạn cần tìm hiểu quy trình trước khi quyết định xây gì. Việc có thể dùng AI đọc ảnh hoá đơn chưa chứng minh được rằng công ty cần một hệ thống AI.
Tìm hiểu bài toán với khách
Bước đầu tiên là discovery (tìm hiểu bài toán với khách). Bạn nên quan sát người trực tiếp xử lý hoá đơn, sau đó hỏi:
- Công việc bắt đầu khi nào và kết thúc ở trạng thái nào?
- Ai thực hiện từng bước và ai xác nhận kết quả?
- Dữ liệu nằm ở đâu, ai có quyền truy cập?
- Mỗi lần xử lý mất bao lâu và một tuần có bao nhiêu lần?
- Lỗi nào thường xảy ra, được phát hiện ở bước nào?
- Một lỗi bị bỏ sót gây hậu quả gì?
- KPI nào cần thay đổi để công ty xem đây là cải tiến đáng giữ lại?
Bạn nên ghi thời điểm bắt đầu và kết thúc một lần xử lý, đồng thời quan sát trường hợp nhân viên phải kiểm tra lại. Những ghi nhận đó tạo cơ sở để so sánh sau này.
Chia bài toán đến mức có thể kiểm chứng
Palantir gọi năng lực này là "technical decomp": nhận một vấn đề kinh doanh ở mức cao, chia nhỏ và thiết kế giải pháp xuống đến từng dòng code. Người làm FDE cần hiểu mục tiêu kinh doanh và tự chủ khi gặp công nghệ chưa biết. Nguồn: Palantir, "Dev versus Delta", 8/4/2019.
Với quy trình hoá đơn, bạn có thể phân rã như sau:
| Việc trong quy trình | Dữ liệu cần có | Điều kiện hoàn thành |
|---|---|---|
| Nhận hoá đơn | Ảnh hoặc tệp hoá đơn | Xác định chứng từ cần xử lý |
| Trích xuất thông tin | Các trường trên hoá đơn | Có dữ liệu để đối chiếu |
| Đối chiếu | Hoá đơn và dữ liệu kế toán | Phân biệt khớp và không khớp |
| Xử lý chênh lệch | Trường sai khác và chứng từ gốc | Nhân viên xác nhận cách xử lý |
| Ghi nhận kết quả | Trạng thái đã xác nhận | Có thể truy lại quyết định |
Những chỗ chưa biết nên được ghi riêng thay vì lấp bằng suy đoán. Đây cũng là cách tiếp cận trong Fable 5 và bài toán unknowns: sửa bản đồ trước khi code.
Xong bước này khi: Bạn mô tả được workflow hiện tại, có dữ liệu mẫu được phép sử dụng, biết cách đo hiện trạng và thống nhất điều kiện thành công với người phụ trách.
Điểm dễ sai: Bạn chỉ nghe quản lý mô tả rồi xây theo, trong khi nhân viên đang xử lý ngoại lệ theo cách khác.
Khi đã hiểu quy trình, bạn cần xác định phần nào thực sự cần AI.
Bước 2: quyết định có cần AI hay không
Hãy dùng tự động hoá thông thường cho phần có quy tắc rõ, chỉ cân nhắc model ở phần cần đọc hiểu thông tin khó chuẩn hoá.
Nguyễn Phi Vân đưa khả năng biết khi nào không cần AI vào nhóm năng lực FDE. Colin Jarvis, Head of Forward Deployed Engineering tại OpenAI, cũng nhấn mạnh nguyên tắc dao cạo Occam: trong phần lớn trường hợp phát triển LLM, giải pháp đơn giản nhất thường tốt nhất. Nguồn: Nguyễn Phi Vân, Colin Jarvis, OpenAI.
Phân ranh giới trong quy trình hoá đơn
| Phần việc | Cách xử lý đề xuất | Lý do |
|---|---|---|
| Đọc Excel | Code thông thường | Dữ liệu đã có cấu trúc |
| Lấy dữ liệu kế toán | Kết nối hệ thống hiện có | Không cần model để đọc dữ liệu có cấu trúc |
| Đọc ảnh hoá đơn | Cân nhắc model | Bố cục chứng từ có thể khác nhau |
| So sánh số tiền | Quy tắc xác định | Có điều kiện kiểm tra rõ ràng |
| Xử lý chênh lệch | Nhân viên xác nhận | Có hậu quả nghiệp vụ nếu quyết định sai |
| Lưu kết quả | Code thông thường | Cần thao tác có thể kiểm chứng |
Bạn nên kiểm tra xem thông tin trên ảnh đã tồn tại trong phần mềm kế toán hay chưa. Nếu dữ liệu đã có sẵn, đọc lại từ ảnh có thể chỉ làm tăng độ phức tạp.
Một LLM có thể là một lựa chọn để trích xuất thông tin từ ảnh. Dù vậy, kết quả vẫn phải qua bước kiểm tra. RAG (cho model tra tài liệu trước khi trả lời) và agent (chương trình tự gọi tool và lặp bước để làm xong một việc) chỉ cần xuất hiện khi yêu cầu thực sự đòi hỏi những cơ chế đó.
Ghi lại quyết định kỹ thuật
Trước khi viết code, bạn nên ghi:
- Phần không dùng AI: Những bước có quy tắc rõ.
- Phần cân nhắc AI: Công việc đọc hiểu mà phương án đơn giản chưa đáp ứng được.
- Dữ liệu đầu vào: Những trường model được phép nhận.
- Đầu ra: Cấu trúc có thể kiểm tra bằng code.
- Điểm con người kiểm tra: Trường hợp thiếu hoặc mâu thuẫn dữ liệu.
- Phương án dự phòng: Cách tiếp tục công việc khi model không hoạt động.
Xong bước này khi: Mỗi phần việc có phương án xử lý, lý do lựa chọn và cách xử lý khi thất bại.
Điểm dễ sai: Bạn dùng model để thực hiện phép so sánh chính xác hoặc biến một tác vụ đơn giản thành nhiều agent nối nhau, làm tăng chi phí token và độ trễ.
Đến đây, coding agent đã có bản yêu cầu đủ rõ để bắt đầu xây.
Bước 3: dựng bản chạy thử bằng coding agent, nhưng giữ quyền phán đoán
Dùng coding agent để xây nhanh một đường xử lý hoàn chỉnh, nhưng bạn phải hiểu và chịu trách nhiệm với code được tạo ra. Nguyễn Phi Vân nhấn mạnh rằng chỉ biết vibe coding rồi chép code AI đưa ra chưa đủ để làm FDE; bạn còn cần khả năng đọc code, debug và hiểu hệ thống đang vận hành. Nguồn: Nguyễn Phi Vân.
Xây một đường xử lý hoàn chỉnh trước
Bản chạy thử có thể nhận dữ liệu mẫu, trích xuất những trường cần thiết, đối chiếu và tạo danh sách chênh lệch cho nhân viên. Bạn chưa cần tự động sửa dữ liệu kế toán hay hỗ trợ mọi loại chứng từ.
Dữ liệu hoá đơn được phép sử dụng
|
v
Đọc và chuẩn hoá
|
v
Kiểm tra dữ liệu
|
v
Đối chiếu số liệu
|
+-----+------+
| |
v v
Khớp Không khớp
| |
v v
Ghi nhận Nhân viên
kết quả kiểm tra
|
v
Ghi nhận quyết địnhTrước khi giao việc, bạn cần chốt với người phụ trách nghiệp vụ: khoá dùng để ghép hai bên (ví dụ số hoá đơn), những trường cần so, định dạng từng trường và cách xử lý dữ liệu thiếu hoặc trùng. Agent không nên tự đoán những quy tắc này. Sau đó bạn có thể giao coding agent xây từng phần với đầu vào, đầu ra và điều kiện lỗi cụ thể. Ví dụ, với số liệu giả định:
Bối cảnh:
Xây bản chạy thử đối chiếu hoá đơn.
Nhiệm vụ:
Nhận dữ liệu hoá đơn đã chuẩn hoá
và so sánh với dữ liệu kế toán mẫu.
Điều kiện:
- Ghép theo số hoá đơn.
- So sánh: ngày hoá đơn (YYYY-MM-DD), mã số thuế,
tổng tiền (số nguyên, VND).
- Ví dụ: HĐ 0001234, 2026-10-01, 0101234567, 5500000
so với kế toán 5000000 -> tổng tiền không khớp.
- Không tự sửa dữ liệu nguồn.
- Trả về từng trường khớp hoặc không khớp.
- Phân biệt dữ liệu thiếu và dữ liệu khác nhau.
- Không tự xác nhận trường hợp chênh lệch.
- Viết kiểm thử cho đầu vào hợp lệ và không hợp lệ.
Trước khi viết code:
Nêu những giả định về cấu trúc dữ liệu
và trường hợp chưa được định nghĩa,
rồi dừng lại chờ mình xác nhận.Sau mỗi phần, bạn cần đọc đường đi của dữ liệu và chạy kiểm thử. Nếu agent tạo một API ghi dữ liệu mà bạn chưa giải thích được điều kiện gọi, phần đó chưa sẵn sàng để đưa vào production.
Tích hợp với hệ thống hiện có
Ứng dụng chạy được với dữ liệu mẫu chưa bảo đảm kết nối được với workflow của doanh nghiệp. Excel có thể đang được sửa thủ công, ảnh nằm trong Zalo và phần mềm kế toán có cơ chế truy cập riêng.
Bạn cần làm rõ hai vấn đề trước khi tích hợp:
- Nguồn dữ liệu: Có thể lấy và cập nhật dữ liệu theo cách nào được doanh nghiệp cho phép? Hệ thống hiện có hỗ trợ phương thức kết nối nào?
- Quyền truy cập: Ai được đọc hoặc ghi dữ liệu? Quyền đó có được giới hạn đúng phạm vi công việc không?
Nếu chưa có quyền kết nối, bạn có thể dùng dữ liệu mẫu hoặc bản xuất hợp lệ. Phần quyền truy cập cần được giải quyết với người phụ trách, thay vì tìm cách đi vòng qua giới hạn của hệ thống.
Khi nào đóng gói thành skill hoặc MCP server?
Khi một thao tác đã ổn định và có khả năng lặp lại, bạn có thể đóng gói để tái sử dụng.
MCP, giao thức nối model với dữ liệu và công cụ bên ngoài, cho phép kết nối tới những công cụ được cung cấp. MCP server có thể đưa các thao tác đã kiểm soát vào workflow, còn skill chứa hướng dẫn thực hiện công việc. Sub-agent (agent con được agent chính giao việc) phù hợp khi một phần việc cần được tách riêng.
Trong một tin tuyển FDE Applied AI, Anthropic nêu MCP server, sub-agent và agent skill như những sản phẩm kỹ thuật cho production. Nguồn: Anthropic trên Built In.
Colin Jarvis mô tả cách đội OpenAI chuyển những ứng dụng riêng thành plugin và skill trên một harness (lớp điều khiển hành vi agent) dùng chung lấy Codex làm lõi. Theo số liệu OpenAI tự công bố cho trường hợp triển khai được mô tả, cách tổ chức này loại bỏ khoảng 90% code tuỳ biến mỗi dự án; khi mở rộng sang đội mới, họ thay connector hoặc MCP server và xây eval mới. Nguồn: Colin Jarvis, OpenAI.
Với bài toán hoá đơn, bạn có thể giữ phần chuẩn hoá dữ liệu thành một thành phần dùng lại sau khi đã kiểm chứng. Palantir cũng chỉ ra đánh đổi giữa đưa tính năng vào nền tảng lõi và xây bản tuỳ biến để giao nhanh cho nhu cầu trước mắt. Nguồn: Palantir.
Xong bước này khi: Bản chạy thử xử lý trọn một luồng dữ liệu hợp lệ, tạo kết quả có thể kiểm tra và không tự thay đổi dữ liệu ngoài phạm vi thống nhất.
Điểm dễ sai: Bạn xây nhiều lớp tái sử dụng khi chưa biết workflow cần gì, hoặc chỉ kiểm thử bằng dữ liệu sạch.
Bản chạy thử hoạt động được vẫn cần chứng minh kết quả đúng và an toàn.
Bước 4: viết eval và đặt điểm con người kiểm tra
Hãy tạo bộ eval và xác định những quyết định phải được con người xác nhận trước khi cho hệ thống chạy trong production.
Eval (tập tình huống có đáp án để đo chất lượng mỗi lần sửa) giúp bạn phát hiện thay đổi prompt, model hoặc code có làm chất lượng giảm đi hay không. Colin Jarvis mô tả một trường hợp đội FDE OpenAI ngồi cùng kỹ sư của khách hàng trong ngành bán dẫn để xây eval theo công việc thực tế. Nguồn: Colin Jarvis, OpenAI.
Biến tình huống nghiệp vụ thành eval
Bạn có thể bắt đầu bằng các tình huống sau và nhờ người phụ trách xác nhận đáp án:
| Tình huống | Kết quả mong đợi |
|---|---|
| Hoá đơn và dữ liệu kế toán khớp | Báo khớp |
| Số tiền khác nhau | Báo đúng trường chênh lệch |
| Thiếu số hoá đơn | Báo thiếu, không tự điền |
| Ảnh không đọc được | Yêu cầu kiểm tra thủ công |
| Nhiều bản ghi có thể trùng | Không tự chọn để xác nhận |
| Dữ liệu ngoài phạm vi được phép | Từ chối xử lý |
| Hệ thống kế toán không phản hồi | Không giả định đã thành công |
Mỗi trường hợp cần có đầu vào và đáp án được người hiểu nghiệp vụ xác nhận. Bạn lưu cả phiên bản prompt, code và bộ eval để kiểm tra lại sau mỗi thay đổi.
Đừng chỉ đếm số trường hợp hệ thống trả về kết quả. Một đáp án sai được trình bày tự tin có thể gây hậu quả lớn hơn việc hệ thống báo không đọc được.
Đặt điểm con người kiểm tra
Gartner, trong nhận định ngày 29/9/2026 của Mukul Saha, nhấn mạnh việc xác định quyền ra quyết định và ranh giới giữa tự động hoá với giám sát của con người. Nguồn: Gartner.
Với quy trình hoá đơn, mình sẽ bắt đầu bằng hai điểm kiểm tra.
Điểm thứ nhất: xác nhận dữ liệu không chắc chắn. Khi ảnh mờ hoặc thiếu trường, hệ thống chuyển chứng từ cho nhân viên thay vì tự điền giá trị.
Điểm thứ hai: xác nhận trước khi thay đổi dữ liệu nghiệp vụ. Hệ thống có thể tạo danh sách chênh lệch, nhưng người được phân quyền phải xác nhận trước khi sửa số liệu kế toán.
Bạn chỉ nên mở rộng mức tự động khi có bằng chứng kiểm chứng phù hợp với hậu quả của thao tác.
Kiểm soát rủi ro khi chạy thật
Nguyễn Phi Vân lưu ý những tình huống như AI bịa thông tin, API lỗi, agent làm nhầm, chi phí tăng và hệ thống bị tấn công. Nguồn: Nguyễn Phi Vân.
Trước production, bạn cần có cách trả lời sáu câu hỏi:
- Thông tin sai: Hệ thống phát hiện và xử lý dữ liệu model tạo sai như thế nào?
- Thao tác nhầm: Điều gì ngăn agent sửa dữ liệu trước khi được xác nhận?
- Lỗi API: Nếu một bước thất bại giữa chừng, hệ thống khôi phục trạng thái ra sao?
- Chi phí: Ai theo dõi token và giới hạn số lần gọi model?
- Tấn công: Đầu vào độc hại có thể khiến model làm việc ngoài phạm vi không?
- Thay đổi hệ thống: Database hoặc API đổi cấu trúc có được phát hiện trước khi dữ liệu sai lan sang bước sau?
Bạn cần phân biệt eval với guardrail (hàng rào an toàn). Eval kiểm tra chất lượng đầu ra; guardrail kiểm soát các thao tác và giới hạn thực thi. Cách tổ chức các lớp kiểm soát trong coding agent được trình bày thêm ở bài về cơ chế hook và các lớp cấu hình trong Claude Code. Các lớp đó bảo vệ lúc viết code; ứng dụng đã deploy vẫn cần tự kiểm tra quyền của chính nó.
Xong bước này khi: Bạn có bộ eval chạy lại được, đáp án được người nghiệp vụ xác nhận, điểm con người kiểm tra rõ ràng và cách xử lý khi hệ thống thất bại.
Điểm dễ sai: Bạn để model tự xác nhận toàn bộ đáp án của mình hoặc dùng kết quả kiểm thử trên dữ liệu mẫu làm căn cứ duy nhất để cho phép ghi dữ liệu thật.
Khi chất lượng đã được kiểm chứng, bạn cần đo tác động lên công việc.
Bước 5: đo trước và sau, rồi bàn giao
Hãy đo cùng một quy trình trước và sau khi áp dụng giải pháp, sau đó bàn giao để người trong công ty tự vận hành.
Nguyễn Phi Vân cho rằng portfolio FDE nên thể hiện quy trình nào được cải tiến, thời gian thay đổi ra sao và con người kiểm tra ở đâu. Nguồn: Nguyễn Phi Vân.
Đo kết quả có thể so sánh
| Chỉ số | Trước khi triển khai | Sau khi chạy thử |
|---|---|---|
| Thời gian xử lý một hoá đơn | [Điền số đo] | [Điền số đo] |
| Số hoá đơn xử lý trong kỳ | [Điền số đo] | [Điền số đo] |
| Tỷ lệ lỗi được xác nhận | [Điền số đo] | [Điền số đo] |
| Số trường hợp cần kiểm tra thủ công | [Điền số đo] | [Điền số đo] |
| Chi phí vận hành liên quan | [Điền số đo] | [Điền số đo] |
Các ô trong bảng là chỗ để bạn tự điền số liệu đo được.
Bạn cần giữ điều kiện đo có thể so sánh. Nếu trước đó nhân viên xử lý chứng từ đơn giản, còn sau đó bản chạy thử chỉ nhận các chứng từ khó, thời gian trung bình sẽ bị ảnh hưởng bởi độ phức tạp công việc.
Việc giảm thời gian thao tác cũng chưa đủ để kết luận thành công nếu tỷ lệ lỗi tăng hoặc khối lượng kiểm tra bị chuyển sang người khác. Với phần dùng AI, bạn nên tính cả chi phí token và thời gian chờ.
Bàn giao để doanh nghiệp tự vận hành
Gartner, trong nhận định ngày 29/9/2026 của Mukul Saha, cho rằng hợp đồng FDE thường thất bại về cấu trúc trước khi thất bại về kỹ thuật. Một tiêu chí thành công là khả năng doanh nghiệp tự quản lý, tối ưu và mở rộng hệ thống sau khi đội triển khai rời đi. Nguồn: Gartner.
Người nhận bàn giao cần biết cách vận hành, nhận diện lỗi và chuyển về quy trình thủ công khi cần. Bạn nên chuẩn bị:
- Sơ đồ workflow: Các bước và hệ thống liên quan.
- Hướng dẫn vận hành: Cách bắt đầu, kiểm tra và kết thúc một lượt xử lý.
- Quyền truy cập: Ai được xem hoặc thay đổi dữ liệu.
- Bộ eval: Những trường hợp cần chạy lại khi hệ thống thay đổi.
- Xử lý sự cố: Cách tạm dừng và quay lại quy trình thủ công.
- Người phụ trách: Ai tiếp nhận vận hành và quyết định thay đổi.
Nếu chỉ bạn biết cách khôi phục một lỗi thông thường, việc bàn giao chưa hoàn tất. Ranh giới giữa giao sản phẩm kỹ thuật và tạo sự phụ thuộc dài hạn cũng được phân tích trong FDE hay tư vấn đổi tên?.
Mẫu portfolio một trang
Bạn có thể dùng bảng sau làm khung hồ sơ năng lực:
| Mục | Cần ghi gì |
|---|---|
| Bài toán | Quy trình cần cải tiến và loại doanh nghiệp |
| Hiện trạng | Người thực hiện, cách làm thủ công, số đo ban đầu |
| Phạm vi | Dữ liệu được phép sử dụng và giới hạn triển khai |
| Giải pháp | Phần tự động hoá, phần dùng AI, hệ thống tích hợp |
| Quyết định kỹ thuật | Vì sao chọn phương án này, phương án nào bị loại |
| Kiểm chứng | Bộ eval, điều kiện đạt và điểm con người kiểm tra |
| Kết quả | Số đo trước sau, chi phí và giới hạn của phép đo |
| Bàn giao | Người nhận, tài liệu vận hành và cách xử lý sự cố |
Bạn cần ghi đúng trạng thái thực tế của dự án, kể cả khi chưa đo được kết quả sau triển khai. Với dữ liệu doanh nghiệp, chỉ công bố những nội dung đã được cho phép, đồng thời giữ lại đủ thông tin về cách kiểm chứng để người đọc hiểu công việc của bạn.
Xong bước này khi: Bạn có số đo có thể so sánh, giải thích được giới hạn kết quả và có người trong công ty nhận vận hành.
Điểm dễ sai: Bạn chỉ báo thời gian tiết kiệm mà bỏ qua chi phí kiểm tra và vận hành, hoặc coi bản demo như một hệ thống production đã được chứng minh.
Một portfolio nhỏ vẫn có giá trị nếu phản ánh đúng công việc và bằng chứng.
Câu hỏi thường gặp
Bạn có thể bắt đầu từ nhiều nền tảng khác nhau, nhưng cần phân biệt khả năng tự học với yêu cầu của những vị trí FDE đang tuyển.
Không phải software engineer thì có làm FDE được không?
Có thể, nhưng bạn vẫn cần nền tảng kỹ thuật đủ để chịu trách nhiệm với giải pháp đưa vào production.
Nguyễn Phi Vân nhìn nhận người xây sản phẩm lấy AI làm trung tâm có thể phát triển theo hướng FDE, đồng thời nhấn mạnh khả năng đọc code và hiểu rủi ro vận hành. Nguồn: Nguyễn Phi Vân.
Trong khoảng 1.000 tin tuyển FDE từ dữ liệu Revealera được Henley Wing Chiu phân tích, công bố ngày 18/11/2025 và cập nhật 25/1/2026, Python xuất hiện ở 66% tin, TypeScript 35%, AWS 32%, GCP 22% và Azure 18%. Về AI, agent xuất hiện ở 35%, kinh nghiệm LLM 31% và RAG 12%. Trong nhóm tin có ghi số năm kinh nghiệm, 60% yêu cầu từ 3 đến 5 năm và 12% yêu cầu từ 0 đến 2 năm; 68% vị trí trong tập dữ liệu yêu cầu đi lại. Nguồn: Bloomberry.
Một tin tuyển FDE Applied AI cụ thể của Anthropic, đã gỡ ngày 18/6/2026, yêu cầu từ 3 năm ở vai trò kỹ thuật làm việc với khách, lập trình Python tốt và kinh nghiệm production với LLM, gồm prompt engineering (kỹ thuật tối ưu câu lệnh gửi vào model) nâng cao, phát triển agent và framework eval.
Công việc gồm xây ứng dụng Claude trong hệ thống khách hàng, giao các thành phần như MCP server, sub-agent và agent skill, rồi đưa các mẫu triển khai lặp lại về đội Product và Engineering. Tin ghi mức lương 200.000 đến 300.000 USD/năm và ước tính đi lại khoảng 25%, áp dụng cho chính vị trí đó. Nguồn: Anthropic trên Built In.
Theo mình, người xuất phát từ vibe coding có thể bắt đầu bằng một workflow nhỏ, đồng thời học cách đọc, kiểm thử và debug code AI tạo ra. Khả năng tự xây chỉ là điểm khởi đầu; khả năng giải thích và xử lý khi hệ thống sai mới giúp bạn tiến gần hơn đến công việc FDE.
Có cần học thêm chứng chỉ AI không?
Không có chứng chỉ AI cụ thể nào trong các nguồn được sử dụng ở đây được xác định là điều kiện bắt buộc để làm FDE.
Nguyễn Phi Vân khuyên bắt đầu từ một vấn đề kinh doanh thật thay vì học nhiều khoá. Lộ trình bà đề xuất đi qua hiểu quy trình, tìm dữ liệu, thiết kế giải pháp, xây dựng, tích hợp, kiểm thử, đo và triển khai. Nguồn: Nguyễn Phi Vân.
Ngày 2/10/2026, Anthropic công bố Claude Frontier Academy với cam kết 100 triệu USD và mục tiêu 10.000 Frontier Deployed Engineers đến cuối năm 2027. Chương trình theo đề cử, gồm giai đoạn mô phỏng triển khai trực tiếp nhiều ngày và 12 tuần nội trú dẫn một dự án Claude thật tại công ty người học. Lứa đầu có kỹ sư từ Accenture, Bain, Capgemini, Deloitte, McKinsey, Morgan Stanley và một số tổ chức khác. Nguồn: Anthropic.
Với người không tham gia những chương trình đó, mình sẽ ưu tiên một bài toán có người nghiệp vụ xác nhận kết quả. Bạn có thể học kiến thức cần thiết ngay khi gặp vấn đề cụ thể, thay vì đợi hoàn thành nhiều khoá học mới bắt đầu thực hành.
Ở Việt Nam tìm bài toán thử ở đâu?
Hãy tìm trong chính công việc của bạn hoặc một doanh nghiệp nhỏ quen biết, nơi có người sẵn sàng giải thích workflow và cho phép đo kết quả.
Về bối cảnh, khảo sát Hopes and Fears 2025 của PwC Việt Nam với hơn 1.000 người lao động ghi nhận 38% sử dụng AI tạo sinh hằng ngày, so với mức trung bình toàn cầu 14%, cho thấy AI tạo sinh đã quen thuộc với một bộ phận người lao động được khảo sát. Nguồn: PwC Việt Nam.
Mình sẽ ưu tiên một quy trình có thể tiếp cận người trực tiếp làm việc và có người chịu trách nhiệm tiếp nhận kết quả. Với bài toán đối chiếu hoá đơn, bạn cần được doanh nghiệp cho phép quan sát, sử dụng dữ liệu phù hợp và thống nhất cách kiểm chứng trước khi xây.
Một bài toán nhỏ có người nghiệp vụ tham gia cho phép bạn thực hành cả kỹ thuật lẫn cách làm việc của FDE.
Khi nào nên dừng một bài toán thử?
Bạn nên dừng hoặc thu hẹp bài toán thử khi không thể đo giá trị, không có người tiếp nhận vận hành hoặc phần AI làm tăng độ phức tạp mà không cải thiện công việc.
Không đo được trạng thái trước
Nếu không biết thời gian xử lý thủ công và cách xác định lỗi, bạn chưa có cơ sở để đánh giá kết quả. Bạn có thể thu hẹp phạm vi đến một bước có thể đo trước khi tiếp tục phát triển.
Phần code đã viết không tạo ra bằng chứng thay cho số liệu hiện trạng.
Không có người nhận lại hệ thống
Nếu doanh nghiệp không chỉ định người xác nhận kết quả và xử lý sự cố, bạn chưa có điều kiện để bàn giao. Việc tiếp tục thêm tính năng có thể khiến hệ thống phụ thuộc nhiều hơn vào người xây.
Bạn nên giữ nó ở phạm vi bản chạy thử cho đến khi có người chịu trách nhiệm vận hành.
Tự động hoá thông thường đã giải quyết đủ
Nếu dữ liệu đã có cấu trúc và quy tắc đối chiếu rõ ràng, một script có thể thực hiện công việc mà không cần model. Thêm agent có thể làm tăng số lần gọi API, chi phí token và độ trễ, đồng thời tạo thêm trường hợp lỗi phải giải thích cho nhân viên.
Mình sẽ chấp nhận bỏ phần code đã viết hoặc hạ hệ thống từ agent xuống một script chạy định kỳ khi phương án đó đủ giải quyết công việc và dễ kiểm chứng hơn. Đánh đổi khả năng tự động xử lý linh hoạt lấy một workflow dễ hiểu, có thể dự đoán và sửa lỗi là hợp lý khi điều đó giữ được niềm tin của người làm nghiệp vụ.
Dùng bài này trong agent của bạn
Lấy API keyChép đoạn dưới, dán vào Claude Code, Codex hay agent bạn đang dùng. Agent đọc bài rồi đối chiếu với repo đang mở.
Đọc bài "Lộ trình trở thành FDE với AI coding: kỹ năng cần có và bài toán thử đầu tiên" trên modernEngineer rồi áp dụng vào repo này.
1. Gọi tool content_get của MCP server modernengineer với locale "vi", slug "lo-trinh-tro-thanh-fde". Nếu chưa nối MCP hoặc bị từ chối quyền, đọc thẳng trang https://modernengineer.dev/vi/library/lo-trinh-tro-thanh-fde.
2. Tóm tắt các bước chính của bài, chỉ ra bước nào áp dụng được cho repo này.
3. Đề xuất thay đổi cụ thể và hỏi tôi trước khi sửa file.Nối MCP cho Claude Code (một lần)
claude mcp add --transport http modernengineer \
https://api.modernengineer.dev/mcp \
--header "Authorization: Bearer <API key>"Bài mở cho mọi người: chưa nối MCP thì agent vẫn đọc được thẳng từ link bài.
- Phiên bản
- v1.0.0
- Cập nhật
- 29/10/2026
- Giấy phép
- Bảo lưu mọi quyền
- Slug
- lo-trinh-tro-thanh-fde
