FDE của KPMG: nút thắt giờ là context, không còn là viết code

Khi Justin Johnsen vào KPMG làm software engineer, mọi dòng code đều được viết tay. Giờ anh là forward deployed engineer kiêm lead technical architect của hãng, và theo anh, phần khó nhất của công việc đã không còn nằm ở bàn phím.

Trong bài chia sẻ trên Business Insider, Johnsen nói nút thắt từng là viết code. Bây giờ, nó là việc thu thập context và làm rõ ý định trước khi bắt đầu phát triển. Ấn bản tiếng Nhật của Business Insider, dựa trên cuộc phỏng vấn với anh, cũng ghi lại đúng nhận định này.

Nếu bạn đang làm FDE hoặc nhắm tới vai trò này, nhận định ấy thay đổi cách bạn được đánh giá. Ở chỗ khách hàng, giá trị của bạn dịch dần từ tốc độ viết code sang khả năng hiểu vấn đề đủ sâu, để bản mô tả giao cho AI không còn chỗ mơ hồ buộc nó phải đoán.

AI chỉ giỏi đến mức context bạn đưa cho nó

Johnsen cho rằng AI có năng lực rất lớn nhưng chỉ tốt đến mức context nó nhận được. Nghe thì hiển nhiên, nhưng hệ quả với FDE thì không. Khi model viết xong một module trong vài phút, một chỗ hiểu sai yêu cầu cũng thành code sai nhanh như vậy.

Thử hình dung khách hàng nhờ bạn “tự động hoá việc đối soát hoá đơn”. Đưa nguyên câu đó cho một coding agent, bạn sẽ nhận về code chạy được nhưng có thể giải sai bài toán: mức chênh lệch nào được chấp nhận, hoá đơn ngoại tệ xử lý thế nào, ai duyệt các trường hợp ngoại lệ.

Câu trả lời nằm trong đầu đội kế toán của khách, không nằm trong repo.

Vì thế, khi định nghĩa FDE, Johnsen nhấn vào chữ “ở lại”: người FDE làm việc trực tiếp với khách hàng và bám theo vấn đề. Business Insider Nhật Bản mô tả cụ thể hơn: hành trình ấy đi từ lúc hiểu nhu cầu kinh doanh đến khi giao được giải pháp thực sự chạy.

Nhưng đừng hiểu thành “bớt phần kỹ thuật”

Cách hiểu sai dễ mắc nhất là coi FDE thời AI như một chân tư vấn có mang theo laptop. Tin tuyển dụng vị trí Technical Lead, Forward Deployed Engineering của KPMG US nói điều ngược lại: ứng viên cần tối thiểu bảy năm kinh nghiệm gần đây trong việc ship các hệ thống phần mềm production end-to-end.

Theo mô tả trong tin, người được tuyển sẽ build và deploy nhanh các hệ thống AI end-to-end, cùng một pod gồm các full-stack engineer “AI-native”. Pod làm việc theo chu kỳ hai đến sáu tuần, nhận phản hồi trực tiếp từ người dùng và stakeholder. Chu kỳ ngắn như vậy chỉ khả thi khi người viết spec cũng hiểu hệ thống sẽ hỏng ở đâu.

Thu thập context không thay thế kỹ năng engineering mà được xây trên nền kỹ năng ấy. Bạn chỉ biết hỏi đúng về hoá đơn ngoại tệ nếu đã hiểu một pipeline đối soát có thể hỏng vì nó như thế nào.

Một bản mô tả ý định trông ra sao?

Quay lại ca đối soát hoá đơn giả định. Thay vì một câu, bản mô tả bạn giao cho agent có thể mở bằng mục tiêu nghiệp vụ: giảm số hoá đơn đội kế toán phải khớp tay, chứ không phải “khớp được mọi hoá đơn”.

Phần ràng buộc ghi rõ những gì phải hỏi khách trước: ngưỡng chênh lệch được tự khớp do ai chốt, hoá đơn ngoại tệ quy đổi theo tỷ giá ngày nào. Phần edge case liệt kê hoá đơn thanh toán nhiều lần và hoá đơn đã huỷ, kèm quy định chúng phải chuyển sang hàng chờ cho người duyệt.

Cuối cùng là tiêu chí nghiệm thu: chạy lại trên một tháng dữ liệu cũ và so với kết quả kế toán đã làm tay. Mỗi dòng trong bản đó là một câu hỏi bạn phải đặt cho khách, và đó chính là phần việc Johnsen gọi là nút thắt.

Đây cũng là thứ đáng mang vào phỏng vấn FDE. Kể lại một bản mô tả như vậy, chỉ ra câu hỏi nào đã cứu dự án khỏi việc build sai, thường thuyết phục hơn một danh sách framework.

Johnsen bắt đầu sự nghiệp bằng việc tự tay viết từng dòng code. Ngưỡng bảy năm ship hệ thống production trong tin tuyển dụng của KPMG cho thấy kinh nghiệm ấy vẫn là vé vào cửa; điều thay đổi là nó giờ được dùng để đặt đúng câu hỏi trước khi dòng code đầu tiên được viết.