FDE hay Solutions Architect: ai được commit vào production mới là ranh giới

Thử hình dung buổi kickoff đầu tiên của bạn tại một khách hàng lớn. Trên bàn là bản thiết kế kiến trúc dày cộp, sơ đồ đẹp, mũi tên đi đúng chiều. Câu hỏi làm cả phòng im lặng không phải “thiết kế này đúng chưa”, mà là “ai sẽ mở pull request đầu tiên vào repo của khách”.

Câu hỏi đó chính là đường phân chia giữa Forward Deployed Engineer và Solutions Architect. Netguru gói nó trong một câu: FDE sở hữu code chạy production, còn Solutions Architect tạo ra các sản phẩm kiến trúc. Và để không ai hiểu nhầm, họ nói thẳng rằng SA tạo ra artifact chứ không tạo ra commit.

Với một developer đang tính chuyển sang FDE, đây là điều cần nắm trước mọi thứ khác. Vì rất nhiều tin tuyển dụng dùng từ “solutions”, “architecture”, “customer-facing” lẫn lộn, bạn có thể nhận một việc vẽ sơ đồ trong khi tưởng mình sẽ đi ship code. Hoặc ngược lại.

Bản thiết kế không chạy, commit mới chạy

Hãy nhìn vào cái được bàn giao. Bảng so sánh của Aced đặt hai thứ cạnh nhau: FDE giao một hệ thống production đang hoạt động cho một khách hàng cụ thể, còn SA giao kế hoạch triển khai. Về code, FDE liên tục ship và duy trì; SA, theo cùng bảng đó, thường chỉ dừng ở proof-of-concept.

Thời điểm cũng khác: Aced đặt FDE ở giai đoạn sau khi bán, sâu trong rollout và vận hành. Ngược lại, Anthropic gọi vị trí Solutions Architect của mình là vai trò pre-sales, một cố vấn kỹ thuật cho khách doanh nghiệp, người định hướng lựa chọn kiến trúc và hỗ trợ khách tích hợp Claude chứ không nắm code production của khách.

Hai mô tả này không mâu thuẫn, chúng bổ sung nhau. SA đứng trước hợp đồng, trả lời câu hỏi “có nên làm và làm như thế nào”. FDE đứng sau hợp đồng, trả lời câu hỏi “nó đã chạy chưa và vì sao nó vừa chết”.

Các công ty viết ranh giới này bằng động từ

Nếu bạn còn nghi ngờ, đọc chính tin tuyển dụng của các công ty đang tuyển vai trò này. OpenAI, trong tin FDE tại San Francisco, yêu cầu ứng viên chịu trách nhiệm triển khai kỹ thuật qua nhiều deployment, từ prototype đầu tiên đến production ổn định. Cùng tin đó liệt kê việc viết và review code production cả frontend lẫn backend bằng Python, JavaScript hoặc stack tương đương.

Tin tuyển FDSE của Palantir mô tả kỹ sư được nhúng trực tiếp tại khách hàng để dựng ứng dụng, LLM workflow và giải pháp production được thiết kế cho thực tế của từng khách. Họ cũng nói rõ cái giá: dự kiến đi lại 25–50% tùy team và địa điểm.

Capicua gọi tên trách nhiệm đó gọn hơn: viết code production trực tiếp trên hạ tầng và dữ liệu của khách.

Để ý các động từ: own, write, review, build, ship. Những dòng mô tả FDE này nghiêng hẳn về hành động trên code, khác với động từ “guide” trong tin SA của Anthropic. Đó là cách phân biệt nhanh nhất khi bạn lướt một JD trên điện thoại.

Cùng một bài toán, hai cách ra tay

Thử lấy một tình huống giả định để thấy sự khác biệt trong hành động. Một công ty bảo hiểm muốn dùng LLM phân loại và định tuyến yêu cầu bồi thường. Cả SA và FDE đều được gọi vào.

SA sẽ ngồi với CTO của khách, hỏi về khối lượng, về SLA, về nơi dữ liệu được phép đi. Sản phẩm của họ là một tài liệu: luồng ingest, bước phân loại, bước định tuyến, lựa chọn model, phương án fallback. Có thể kèm một notebook proof-of-concept chạy trên vài trăm mẫu để chứng minh ý tưởng khả thi.

Tài liệu được duyệt, hợp đồng được ký, SA chuyển sang khách tiếp theo.

FDE nhận tài liệu đó và clone repo của khách. Họ phát hiện bảng claims thật có một cột trạng thái không ai ghi trong tài liệu, hệ thống auth nội bộ chặn service account mới, và pipeline đêm chạy trước giờ dữ liệu được đồng bộ. Không có mục nào trong bản thiết kế nói về ba việc này.

FDE sửa migration, viết adapter cho auth, đổi lịch chạy, mở pull request, chờ team platform của khách review, rồi theo dõi dashboard tuần đầu sau go-live.

Hãy nghe hai câu trả lời cho cùng một tin nhắn từ khách vào chiều thứ Sáu: “Schema vừa đổi, thứ Hai phải chạy.” SA, đúng vai trò, sẽ trả lời rằng cần cập nhật tài liệu và ước lượng lại. FDE sẽ trả lời bằng một link pull request. Cả hai đều làm đúng việc của mình. Chỉ là hai việc khác nhau.

Tự kiểm tra bạn đang được tuyển vào phía nào

Bước một, đọc JD và tách động từ. Nếu phần lớn là guide, advise, design, recommend, đó là SA dù chức danh có chữ “engineer”. Nếu là own, write, ship, maintain, debug, đó là FDE dù chức danh có chữ “solutions”.

Bước hai, trong phỏng vấn hỏi một câu cụ thể: “Sau go-live, nếu code tôi viết gây lỗi, ai là người sửa?” Nếu câu trả lời là “team của khách” hoặc “team product”, bạn đang nói chuyện về vai trò artifact. Nếu là “bạn”, đó là vai trò commit.

Bước ba, hỏi về thời điểm và địa điểm. Bạn vào trước hay sau khi hợp đồng ký? Code chạy trong hạ tầng của khách hay trong sandbox demo của công ty? Có bao nhiêu phần trăm thời gian ở tại chỗ khách? Palantir trả lời câu cuối ngay trong JD; những nơi mập mờ thì bạn phải tự hỏi.

Bước bốn, viết CV theo cùng logic. Dòng “thiết kế kiến trúc cho hệ thống X” nói với hiring manager FDE rằng bạn tạo artifact. Dòng “ship hệ thống X vào production tại khách hàng Y, duy trì nó qua ba đợt release” nói rằng bạn tạo commit và chịu trách nhiệm về nó. Dòng thứ hai mới là thứ họ tìm.

Những sai lầm thường gặp

Sai lầm lớn nhất là nghĩ FDE chỉ là “SA biết code”. Không phải. Nhiều SA code rất giỏi. Khác biệt không nằm ở kỹ năng mà ở chỗ ai đứng tên trên commit chạy thật và ai phải trả lời khi nó hỏng. Một proof-of-concept chạy trên laptop, dù hay đến đâu, vẫn là artifact.

Sai lầm thứ hai là coi demo pre-sales như deployment. Demo tồn tại để chứng minh khả năng và chốt hợp đồng. Deployment tồn tại để sống sót trong dữ liệu bẩn, auth lạ và lịch batch của khách. Nếu toàn bộ kinh nghiệm “customer-facing” của bạn là demo, bạn chưa có bằng chứng cho vai trò FDE.

Sai lầm thứ ba là né trách nhiệm vận hành khi đã làm FDE. Aced đặt FDE “sâu trong rollout và vận hành” không phải để cho vui. Nếu bạn ship xong rồi biến mất, bạn đang làm việc của SA với mức rủi ro của FDE.

Bài tập cho tuần này

Mở CV của bạn và đánh dấu từng dòng kinh nghiệm: dòng nào mô tả artifact, dòng nào mô tả commit đã chạy thật. Chọn một dòng artifact và viết lại nó thành thứ bạn đã ship và duy trì, hoặc thừa nhận rằng bạn chưa có bằng chứng đó.

Bản thiết kế cho biết hệ thống nên chạy thế nào. FDE là người chịu trách nhiệm để nó chạy thật.