# Khi AI viết code hàng loạt, FDE được trả tiền để chịu trách nhiệm

> Salesforce đã ghi vào tin tuyển FDE rằng code có thể do công cụ AI sinh ra, nhưng người chịu trách nhiệm cho kết quả vẫn phải là kỹ sư.

Bản gốc: https://fdetimes.net/vi/phan-tich/fde-khi-ai-viet-code-gia-tri-nam-o-dau/

Tin tuyển FDE cho Agentforce và Data Cloud mà Salesforce đăng giữa tháng 6/2026 có một chi tiết hiếm gặp. FDE phải chịu trách nhiệm chất lượng sản phẩm bàn giao, dù code do một đồng nghiệp sinh ra bằng công cụ AI hay do chính họ viết.

Với nhà tuyển dụng này, điều quan trọng không còn là ai gõ code mà là ai chịu trách nhiệm cho nó.

Chuyện này không chỉ có ở một công ty. CEO Infosys cho biết các đội của họ đã sinh ra hơn 28 triệu dòng code bằng AI. Khi code được làm ra với số lượng như thế, khả năng gõ code không còn hiếm, và người muốn làm FDE phải trả lời được một câu rất thực tế: còn lý do gì để người ta thuê bạn?

Đọc tin tuyển dụng của Salesforce và Anthropic, rồi nghe trưởng bộ phận FDE của OpenAI, câu trả lời khá giống nhau. Giá trị của FDE giờ nằm ở việc chịu trách nhiệm với kết quả, ở những phần của dự án không thuộc về mô hình, và ở chỗ giúp khách tự vận hành được hệ thống.

Nếu bạn có 2-8 năm kinh nghiệm, đó là những điều CV của bạn cần chứng minh. Số commit không nói lên những điều đó.

## Code rẻ đi thì người chịu trách nhiệm đắt lên

Salesforce mô tả FDE senior là người có thẩm quyền kỹ thuật cao nhất trong phòng họp với khách, có nhiệm vụ giữ sản phẩm bàn giao ở chuẩn kỹ thuật cao nhất.

Ngay sau đó tin tuyển dụng viết hai câu ngắn: cần chiều sâu kỹ thuật, và kỳ vọng phán đoán kiến trúc. Đọc cùng yêu cầu chịu trách nhiệm cả với code do AI sinh, hai câu này gợi ý rằng chiều sâu kỹ thuật giờ cần cho việc thẩm định code của người khác hay của máy, chứ không chỉ cho việc tự viết.

10Clouds tách FDE khỏi kỹ sư nền tảng bằng chính tiêu chí này. FDE viết code trên hệ thống của khách, thường làm ngay tại chỗ, và là người chịu trách nhiệm kết quả triển khai. AI không làm phần trách nhiệm đó mờ đi. Thậm chí, khi AI sinh code nhanh hơn con người kịp đọc, phần trách nhiệm ấy còn nặng hơn.

Thử hình dung một tình huống. Công cụ AI viết xong connector từ agent sang hệ thống CRM của khách trong 20 phút, test đều qua.

Nhưng connector kéo toàn bộ trường dữ liệu vào context của agent, trong đó có cả số điện thoại và ghi chú cá nhân của khách hàng cuối. Mô hình sẽ không tự phát hiện lỗi này.

Người phát hiện phải là FDE đang ngồi trong phòng.

**Điểm mấu chốt:** Code có thể do máy viết, nhưng người chịu trách nhiệm vẫn phải là kỹ sư.

## Mô hình chỉ chiếm phần nhỏ của bài toán

Colin Jarvis, trưởng bộ phận forward deployed engineering của OpenAI, ước tính năng lực mô hình chỉ chiếm "khoảng 20% hoặc ít hơn" trong khoảng cách giữa demo và một hệ thống chạy thật. Theo ông, phần còn lại là chuyện tổ chức, dữ liệu, quyền truy cập và đánh giá. Đây là nhận định từ người điều hành đội FDE của chính một phòng lab làm mô hình.

Hãy thử áp con số này vào một dự án giả định bị tắc 10 tuần. Đây chỉ là cách minh họa thô: Jarvis nói về tỷ trọng của khoảng cách triển khai, không đưa ra cách chia thời gian nào.

Nếu quy đại khái sang thời gian, phần thuộc về mô hình chiếm nhiều nhất khoảng 2 tuần, còn 8 tuần kia dành cho xin quyền truy cập dữ liệu, chờ phòng bảo mật duyệt, dọn bảng dữ liệu bẩn và xây bộ eval mà khách tin được.

Công cụ AI viết code giúp rút ngắn khâu viết code, còn phần lớn thời gian thì nằm ở 8 tuần kia.

Tin tuyển FDE Applied AI của Anthropic cho thấy rõ điều đó. FDE làm việc bên trong hệ thống của khách để đưa ứng dụng lên production trên Claude. Thứ họ bàn giao là MCP server, sub-agent và agent skill.

Mỗi thứ đó đều chứa sẵn các quyết định về tổ chức và quyền hạn. Một MCP server quyết định agent được phép chạm vào công cụ và dữ liệu nào. Vì vậy, chuyện quyền truy cập mà Jarvis nhắc tới không dừng ở biên bản họp: nó thành những dòng cấu hình cụ thể trong server bạn bàn giao.

Bạn có thể nhờ AI viết phần thân của MCP server. Còn việc quyết định server mở những gì, đóng những gì, và lấy gì để chứng minh agent làm đúng thì AI không làm thay được. Đó là việc bạn phải tự bảo vệ trước khách hàng.

## FDE có phải chỉ là miếng vá tạm thời?

Phản biện đáng nghe nhất đến từ Larry Dignan của Constellation Research: FDE có mặt vì các sản phẩm còn non. Lập luận này có lý. Nếu nền tảng tự lo được dữ liệu, phân quyền và eval thì người đứng giữa sẽ bớt cần thiết.

Chính OpenAI cũng không muốn FDE trở thành chỗ dựa lâu dài. Jarvis nói rõ: "Chúng tôi không muốn tạo ra sự phụ thuộc vào FDE." Anthropic nhấn vào một vế khác: FDE phải mang những gì học được ở hiện trường về cho đội Product và Engineering, để kinh nghiệm từ từng khách hàng quay lại làm sản phẩm tốt hơn.

Vì thế lời phê bình của Dignan có lẽ chỉ đúng với một kiểu FDE: người có giá vì khách không thể thiếu họ. Kiểu FDE đó sẽ mất chỗ khi sản phẩm hoàn thiện. Kiểu còn lại để lại năng lực cho khách, và mỗi lần triển khai lại giúp sản phẩm tốt hơn.

Kiểu này vẫn có việc ở khách hàng tiếp theo, với bài toán khó hơn. Gergely Orosz của The Pragmatic Engineer ghi nhận nhu cầu cho vai trò này đang rất lớn ở Google, OpenAI và Anthropic.

## Developer Việt Nam cần chứng minh điều gì

Bước đầu tiên là sửa CV. Một dòng như "phát triển 15 API" giờ ít có sức nặng, vì AI cũng làm được. Hãy viết theo hướng trách nhiệm: bạn chịu trách nhiệm triển khai cái gì lên production, bạn chặn được rủi ro gì trong code do AI sinh, và sau khi bạn rời đi, khách tự vận hành được gì.

Khi đọc JD, hãy để ý các cụm từ như "owns the outcome", "architectural judgment", "customer systems", "MCP servers". Chúng cho biết công ty đang tuyển người chịu trách nhiệm hay chỉ cần thêm người viết code.

Trước buổi phỏng vấn, hãy chuẩn bị sẵn một câu chuyện có thật về lần bạn từ chối code do AI viết: code đó sai ở đâu, bạn phát hiện bằng cách nào, và nếu cho qua thì hậu quả sẽ là gì.

Về luyện tập, một dự án cá nhân đáng làm là dựng MCP server cho một hệ thống nội bộ lộn xộn. Kèm theo đó là một trang ghi rõ phạm vi truy cập, một bộ eval nhỏ, và một runbook đủ để đồng nghiệp chạy lại mà không cần bạn. Dự án này luyện được đủ ba điều Jarvis nhắc tới: dữ liệu, quyền truy cập và đánh giá.

Cuối cùng là phần phi kỹ thuật mà 10Clouds đặt ra: trực giác sản phẩm và sự điềm tĩnh trước khách hàng. Nếu bạn làm outsource và hay họp với khách nước ngoài, bạn đang có sẵn chỗ để rèn hai kỹ năng này. Hãy tập nói "không" với một yêu cầu, kèm lý do kỹ thuật, theo cách khách vẫn tin bạn.

Khi riêng một công ty đã cho máy viết hơn 28 triệu dòng code, nhà tuyển dụng sẽ ít hỏi bạn viết được gì. Họ muốn biết bạn dám chịu trách nhiệm cho phần code nào.

**Thử ngay tuần này:**

- Chọn một đoạn code AI vừa sinh cho bạn trong tuần này, viết ra ba điểm bạn sẽ không chấp nhận nếu đem lên production, và giải thích lý do của từng điểm.
- Dựng một MCP server nhỏ nối với một hệ thống nội bộ lộn xộn. Kèm theo một trang ghi rõ agent được và không được đọc dữ liệu gì, cùng 10 ca test để đánh giá.
- Sửa một dòng trong CV từ 'đã phát triển tính năng X' thành 'chịu trách nhiệm triển khai X đến production', rồi bổ sung bạn đã chặn rủi ro gì.

## Nguồn

- [Forward Deployed Engineer (Agentforce & Data cloud) – Salesforce](https://jobs.omegavp.com/companies/salesforce-2/jobs/83134716-forward-deployed-engineer-agentforce-data-cloud)

- [Forward Deployed Engineer, Applied AI (Anthropic, General Catalyst job board)](https://jobs.generalcatalyst.com/companies/anthropic/jobs/70192292-forward-deployed-engineer-applied-ai)

- [OpenAI's enterprise AI problem: The hard part starts after the model](https://www.groundlevel-ai.com/p/openais-enterprise-ai-problem-the)

- [Forward deployed engineers: The promise, peril in AI deployments](https://www.constellationr.com/insights/news/forward-deployed-engineers-promise-peril-ai-deployments)

- [Forward Deployed Engineer: What FDEs Do and When to Hire One](https://www.10clouds.com/blog/a-i/what-is-a-forward-deployed-engineer/)

- [The Pulse: Forward deployed engineering heats up again](https://newsletter.pragmaticengineer.com/p/the-pulse-forward-deployed-engineering)