Anti-corruption layer và strangler fig: cách gắn AI vào hệ thống cũ của khách hàng mà không làm hỏng nó
Hệ thống cũ của khách không cần được viết lại từ đầu. Lớp AI mới cũng không nên học theo những quy ước lộn xộn của nó.
09/10/2026
Tờ báo của nghề Forward Deployed Engineer
Giải thích từng khái niệm của nghề FDE: ngắn, có hình, có việc nên làm ngay.
Hệ thống cũ của khách không cần được viết lại từ đầu. Lớp AI mới cũng không nên học theo những quy ước lộn xộn của nó.
09/10/2026
Khách sẽ không bao giờ gửi dữ liệu theo tốc độ bạn muốn, nên hệ thống của bạn phải tự quyết định nó nhận nhanh đến đâu.
Lúc dịch vụ của bạn phải chạy sau load balancer của khách, ba lỗi thường cùng lộ ra: mất IP thật của người dùng, session nhảy lung tung và health check báo sai. Cả ba đều sửa được nếu bạn biết mỗi lớp mạng nhìn thấy gì.
Mỗi gigabyte đi qua server ứng dụng tốn compute, bộ nhớ và băng thông mà bạn phải trả tiền, trong khi một chìa khóa tạm thời có thể làm thay việc đó.
Một câu JOIN chạy đúng trên laptop vẫn có thể trả về con số sai ở hệ thống của khách nếu bạn chưa biết họ chia dữ liệu ra sao.
Khi API của khách trả lời chậm mà bạn không được sửa nó, chọn đúng chiến lược cache quyết định người dùng nhận dữ liệu nhanh hay nhận dữ liệu sai.
Khi đội hạ tầng của khách hỏi "p99 bao nhiêu, mỗi giây chịu được bao nhiêu request", câu "chạy khá nhanh" sẽ làm bạn mất sự tin cậy của họ ngay trong buổi họp đầu.
Khi trợ lý AI trả lời bằng dữ liệu cũ hơn hệ thống của khách, lỗi thường không nằm ở model mà ở mức nhất quán chưa ai chọn một cách có chủ đích.
Con số 99,9% nghe như một lời hứa dễ dàng, cho đến khi bạn nhân nó với database, API bên thứ ba và hai phút chờ failover.
Latency trung bình trông rất ổn vẫn có thể che đi những request chậm mà người dùng của khách sẽ gặp đúng ngày ra mắt.
Khách chỉ cần đổi tên một field là code tích hợp của bạn có thể hỏng mà không báo một lỗi nào, trừ khi có một bài test được viết riêng để bắt đúng khoảnh khắc đó.
Ngày đầu ở khách hiếm khi có một REST API gọn gàng: thường là một service XML từ thời trước, một file .proto hoặc một endpoint GraphQL duy nhất. Muốn gọi được, hãy xin đúng bản hợp đồng thay vì đọc hết tài liệu.
Model chạy tốt trên notebook là chuyện dễ. Khách sẽ hỏi bạn những câu khó hơn: có mất message không, có chấm trùng không, model chậm thì pipeline sẽ ra sao.
Model chấm điểm tín dụng chạy rất tốt cho tới khi có người hỏi “vì sao hồ sơ này bị loại”, và câu trả lời phải đúng với chính hồ sơ ấy.
Databricks ra đề viết một hàm xử lý dictionary trong notebook, OpenAI giao một bài implementation chia nhiều phần, còn Palantir dành 60 phút decomposition cho một đề cố ý thiếu thông tin và không quan tâm bạn có thuộc Dijkstra hay không.
Hội đồng AI của khách không chấm độ chính xác của model; họ muốn biết sau mọi biện pháp, phần rủi ro còn lại là gì và ai đã ký chấp nhận nó.
Hệ thống vừa chậm vừa đắt thì phản xạ đầu tiên thường là đổi sang model rẻ hơn, trong khi đòn bẩy này nên để muộn, chỉ dùng khi đã có eval.
Câu hỏi về đánh đổi kiểm tra xem bạn có thấy mình đã bỏ lại thứ gì, vì sao bỏ, và đã giải thích chuyện đó với khách hàng ra sao.
Ngay sau buổi demo, khách có thể hỏi "tháng sau chạy được chưa". Mười giây trả lời của bạn sẽ quyết định không khí của mấy tháng làm việc sau đó.
Trước khi được chạm vào CRM thật của khách hàng, bạn có thể dựng một bản giả lập trong một buổi chiều và dùng nó để chốt cách thiết kế tool cho agent.
Lần đầu khách gọi báo model dự báo sai, bạn cần trả lời được ngay ba câu: model nào đang chạy, sai từ bao giờ và lỗi nằm ở dữ liệu hay ở model.
Agent càng được tự chạy lệnh ở máy khách hàng thì càng cần một hàng rào mà nó không thể thuyết phục để được cho qua.
Agent báo khách "đã hoàn tiền" chưa đủ để tin. Muốn biết nó có hoàn thật hay không, bạn phải xem database và chạy lại bài test nhiều lần.
Kẻ tấn công thật chẳng cần toán cao cấp, chỉ cần một email viết khéo, và FDE nên là người gửi email đó đầu tiên.
Khách vừa gửi một URL MCP và bạn chỉ có một buổi chiều để gọi được tool đầu tiên. Phần khó thường nằm ở vài header bị bỏ sót chứ không nằm ở JSON-RPC.
Bị cắt khỏi tài liệu gốc, một đoạn văn có thể mất cả tên công ty lẫn mốc thời gian. Chỉ cần gắn lại vài chục token ngữ cảnh, số lần truy xuất thất bại đã giảm 49%, và giảm 67% nếu thêm reranking.
Có công ty cho FDE làm cả presales, có công ty thì không. Nhưng sau khi ký, FDE nào không rõ mình giữ phần nào thì rất dễ bàn giao một hệ thống không ai dùng.
Khi khách hỏi "cần mấy node", bạn chỉ cần một ngày dữ liệu thật và vài lệnh đo là biết họ cần compaction, cần cluster hay một máy là đủ.
Màn hình chạy được trên localhost mới là nửa đường; nửa còn lại là kiểm kiểu, build sạch và không để lộ một chiếc API key nào trong bundle.
Hai tuần đầu thường dành cho việc nội bộ, nên FDE mới phải chọn đúng một việc nhỏ nhưng có tác động lớn, rồi chốt nó cùng khách trước bức tường của tuần năm hoặc tuần sáu.
Bộ lọc PII viết vội vẫn có thể để lọt dữ liệu cá nhân, còn bảng ánh xạ giữ lại cho tiện có thể khiến cả hệ thống khó được coi là đã khử nhận dạng.
Demo RAG chạy mượt trên file mẫu sẽ vỡ ngay khi gặp ổ đĩa của khách, và chỗ vỡ thường không nằm ở model mà ở bước đọc tài liệu.
Agent của bạn gọi lại một API bị treo, và hệ thống khách hàng hoàn tiền hai lần; khoảng 80 dòng TypeScript là đủ để chuyện đó không xảy ra.
Một request phân tích tài liệu kéo dài vài phút không được giữ kết nối HTTP của khách hàng, và cũng không được biến mất khi worker sập giữa chừng.
Phần lớn tính năng chat với LLM chỉ cần server đẩy token xuống trình duyệt. Chọn WebSocket theo thói quen có thể khiến bạn phải gánh thêm những đánh đổi hạ tầng mà khách hàng không cần.
Lỗ hổng đứng đầu danh sách OWASP có thể bị khai thác chỉ bằng cách đổi ID trong request, và bạn hoàn toàn có thể tự kiểm tra điều đó trước khi đội bảo mật của khách làm.
Một job đồng bộ chạy vô tư có thể khiến khách khóa API key của bạn ngay tuần đầu. Ngược lại, nếu API của bạn không có giới hạn thì chỉ một client lỗi cũng đủ làm nó sập; cả hai chiều đều xử lý được bằng vài chục dòng code.
Chatbot nội bộ lộ dữ liệu thường không phải vì model nói bậy, mà vì bước retrieval chưa biết người đang hỏi là ai.
Lỗi 401 đầu tiên ở site khách chưa phải điều đáng sợ nhất. Đáng sợ hơn là integration vẫn chạy trong khi bạn hiểu sai cách hệ thống xác thực.
Vòng lặp đọc dữ liệu chỉ có vài dòng code, nhưng nếu chọn sai cách phân trang, script sẽ chạy cả đêm hoặc trả về dữ liệu trùng mà bạn không hề hay biết.
Nếu API chỉ trả về một mã 500 kèm câu "Something went wrong", sự cố nào bên khách cũng sẽ thành ticket gửi về bạn. Vài trường JSON đặt đúng chỗ có thể thay đổi điều đó.
Cùng một đoạn code, nhưng mạng của ngân hàng hay nhà máy có thể trả về 407, 504 hoặc một dòng CORS đỏ trong console, và FDE nào biết lỗi nằm ở tầng nào thì sửa xong trước.
Model chạy mượt trên cloud vẫn có thể thất bại ngay cạnh băng chuyền, nơi đường truyền yếu, nên FDE phải tính đến thiết bị, nguồn điện và kế hoạch rollout trước khi nghĩ tới model.
Khách gửi ảnh chụp một con số sai. Lần đường từ con số đó về đúng job và đúng lần chạy đã sinh ra nó giúp FDE tìm nguyên nhân gốc có định hướng, thay vì đoán mò ở model.
Model vẫn trả HTTP 200 chỉ sau vài mili giây, kể cả khi dữ liệu khách hàng đã khác hẳn dữ liệu nó từng học. Hướng dẫn này giúp bạn dựng một hệ thống nhận ra chuyện đó trước khi khách hàng phát hiện.
Model đạt độ chính xác cao trên laptop vẫn có thể không load nổi trên server của khách hàng; bài thực hành này đi qua từng bước để tránh đúng tình huống đó.
Khi khách hỏi "model tháng trước học trên dữ liệu nào?", FDE cần trả lời bằng một commit hash, không phải bằng trí nhớ.
Một file workflow và ba script Python là đủ để reviewer biết thay đổi của bạn làm model tốt lên hay tệ đi, trước khi bấm merge.
Với bảng mười nghìn dòng, mô hình cây vẫn khó bị đánh bại. Với ảnh và văn bản thì ngược lại, và người FDE giỏi phải nói được vì sao ngay trong buổi họp đầu tiên.
Trong ví dụ về tín dụng của scikit-learn, giữ nguyên model và chỉ dời ngưỡng quyết định đã giúp lợi ích kinh doanh tốt lên gần gấp đôi.
Hệ số "4,54 lần" lan truyền trên mạng có thể làm bản báo giá đội lên gấp ba. Cách chữa rất đơn giản: lấy dữ liệu thật của khách và đếm.
Cắt bớt lịch sử là cách dễ nhất để agent không bị tràn context, nhưng cắt sai chỗ thì lượt gọi model kế tiếp có thể lỗi, nên bạn cần một vòng nén làm có chủ đích và đo được kết quả.
Hệ RAG cơ bản tìm một lần rồi trả lời bằng bất cứ thứ gì nó tìm được. Bài này dựng thêm một vòng lặp nhỏ để agent tự kiểm tra bằng chứng, và nếu chưa đủ thì tự sửa câu hỏi rồi tìm lại.
Dashboard hạ tầng xanh hết mà khách hàng vẫn phàn nàn agent làm hỏng việc, vì bạn đang đo máy chạy chứ chưa đo việc có xong hay không.
Một agent cứ làm xong một bước lại phải hỏi model lớn bước tiếp theo sẽ chậm và khó kiểm soát; tách việc lập kế hoạch, thứ tự chạy và khâu phản biện ra riêng sẽ cho bạn một hệ thống đo được, sửa được và giải thích được với khách hàng.
Câu SQL chạy không lỗi nhưng trả về một con số mà phòng tài chính không công nhận. Đó là kiểu lỗi bạn sẽ gặp nhiều nhất, và bài hướng dẫn này chỉ cách bắt nó trước khi khách bắt được.
Sáu bước để mọi lệnh hoàn tiền hay email của agent đều qua tay người duyệt mà khách không phải chờ vô thời hạn: trả lời cú bấm trong 3 giây, chờ quyết định bao lâu cũng được, và tự từ chối khi không ai bấm.
Bản demo agent tìm kiếm web có thể xong trong một buổi chiều. Phần khó đến vào tuần sau, khi trang web trả về 403, đường link được trích dẫn không nói đúng điều agent khẳng định, và bộ phận pháp lý muốn biết ai đã cho phép crawl.
Một agent không có điều kiện dừng có thể chạy vô hạn và đốt chi phí mà không ném ra lỗi nào, và người phải giải thích với khách hàng là FDE.
Model không đọc code hay Swagger của khách. Mọi thứ nó biết về API chỉ gói trong vài dòng mô tả bạn viết, nên tool gọi sai thường bắt đầu từ chính mấy dòng đó.
Judge đạt 90% đồng thuận vẫn có thể bỏ sót mọi câu trả lời sai. Muốn khách tin con số eval, bạn phải đo judge với người hiểu nghiệp vụ nhất bên họ.
Xoá cột giới tính khỏi dữ liệu chưa chắc làm mô hình công bằng hơn. Muốn biết trợ lý có thiên lệch hay không, bạn phải đo nó, và việc đo cần một quy trình rõ ràng.
PhoWhisper lo phần chép lời tiếng Việt, WhisperX lo phần ai nói câu nào, còn những lỗi làm hỏng bản tóm tắt thường nằm ở khâu nối hai bên với nhau.
Model card của Llama 3.1 có tiếng Thái nhưng không có tiếng Việt, và đó là loại chi tiết bạn phải nắm trước khi đưa một mô hình mở vào hệ thống của khách hàng.
Ảnh chụp nghiêng, chữ viết tay có dấu và clip quay rung từ điện thoại mới là dữ liệu thật ở công trường, và pipeline của bạn chỉ dùng được khi xử lý được chúng.
Bài thực hành đi từ ticket đã gắn nhãn đến một adapter nhỏ gọn chạy trên model gốc, kèm cách giữ tập test để con số đánh giá cuối cùng còn đáng tin.
Trước khi giao mọi thứ cho framework, bạn nên tự đi hết một vòng request, streaming và tool call với Claude và OpenAI, rồi biết Gemini khác ở đâu. Đó là những thứ bạn sẽ phải gỡ lỗi khi ngồi ở văn phòng khách hàng.
Prompt injection gần như chưa có cách chặn triệt để, nên FDE phải xếp nhiều lớp phòng thủ chồng lên nhau, sao cho một lớp thủng thì hậu quả vẫn nhỏ.
Model đời mới không làm prompt engineering lỗi thời. Chúng chỉ khiến thói quen bắt đầu bằng kỹ thuật nặng nhất trở nên tốn kém.
Chỉ cần một câu hỏi về lương là biết pipeline truy xuất của bạn hở ở đâu.
Embedding hiểu nghĩa câu hỏi rất tốt, nhưng lại dễ nhầm giữa HD-2024-0153 và HD-2024-0135. Bài hướng dẫn này đi qua sáu bước, từ bộ đo, tokenizer đến rerank, để sửa lỗi đó và đo được kết quả sau khi sửa.
Model được fine-tune cho luật tiếng Việt tự báo Accuracy@1 tăng từ 0.5682 lên 0.7274. Nhưng con số đó chưa nói được gì về kho tài liệu bảo hiểm của khách hàng mà bạn đang phụ trách.
Khi agent trả lời sai ở site khách hàng, lỗi thường không nằm ở câu prompt mà ở những gì bạn đã đưa vào context window, hoặc đã quên đưa vào.
Bản demo từng làm khách hàng gật gù sẽ hỏng ngay ở file CSV lỗi đầu tiên, và ở vai trò FDE, người phải sửa nó là bạn.
Model của bạn đã đủ tốt. Thứ còn thiếu là phần việc sau khi model chạy xong: API, auth, monitoring, và một khách hàng đang đợi kết quả.
Ở site khách hàng, lỗi thiết kế bắt được trên một trang Google Doc rẻ hơn rất nhiều so với lỗi lộ ra khi code đã chạy, và đây là bảy bước để viết trang đó rồi đưa nó qua vòng duyệt.
Nhiều dự án trễ không phải vì code mà vì một quyết định còn treo. Bản báo cáo gửi khách mỗi tuần là nơi bạn đưa quyết định đó ra.
Một pilot chạy tốt về kỹ thuật vẫn có thể chết trong cuộc họp ngân sách, nếu FDE không trả lời được khách kiếm tiền ở đâu, tiền dự án lấy từ quỹ nào và ai là người ký.
Quy trình trong tài liệu và quy trình nhân viên đang thật sự làm hiếm khi trùng nhau, và agent bạn xây sẽ hỏng đúng ở những chỗ hai bản đó lệch nhau.
Ở site khách, máy chủ đang lỗi thường không có dashboard và không cho cài thêm công cụ. Thứ bạn chắc chắn có chỉ là một bastion, một shell và vài phút trước khi có người hỏi bạn đã tìm ra nguyên nhân chưa.
Ngày đầu ở site khách, lỗi Git đáng sợ nhất thường không phải conflict mà là một commit mang sai email bị đẩy lên sai server.
docker save, docker load, một registry nội bộ và một người ký duyệt là bốn thứ đưa bản build của bạn vào mạng cách ly của khách.
Prototype chạy ổn bằng API key cá nhân của bạn vẫn chưa đủ: việc thật bắt đầu khi phải đưa nó vào tài khoản, vùng và hệ thống phân quyền của khách.
Ứng dụng nào cũng trả lời được câu hỏi trong buổi demo. Khi đưa lên production, bạn còn phải chỉ ra được nó đã trả lời thế nào và mỗi câu trả lời tốn bao nhiêu token.
Chỉ cần một task bị retry lúc 2 giờ sáng là dữ liệu nạp đêm qua có thể bị nhân đôi. Nếu bạn là FDE, sáng hôm sau người phải giải thích chuyện đó với khách hàng có thể chính là bạn.
Trước khi gõ truy vấn đầu tiên ở khách hàng, hãy tìm một bản sao để đọc; nếu buộc phải dùng primary, hãy khoá phiên ở chế độ chỉ đọc và đặt thời hạn cho mọi câu lệnh.
Trước buổi review tích hợp, bạn chưa cần học thêm ngôn ngữ mới. Bạn cần biết mở ba file nào trước, rồi lần theo một request cho tới tận database.
Đội tích hợp của khách hàng sẽ dùng endpoint của bạn lâu hơn rất nhiều so với thời gian bạn ở lại dự án, nên mỗi tên trường bạn đặt hôm nay là một lời hứa phải giữ.
Chỉ cần một dòng chữ giấu trong ticket là agent có thể đọc nó như một mệnh lệnh. Vì vậy, thứ phải thiết kế cẩn thận là giới hạn những gì agent được phép làm sau khi đọc.
Chạy được model chỉ là phần dễ. Phần khó là dựng nó trong mạng của khách sao cho đội bảo mật chịu ký duyệt và hệ thống không nghẽn khi tải tăng.
Sửa vội một câu prompt có thể làm hỏng thứ đang chạy đúng, và một golden dataset gắn vào pull request sẽ bắt được lỗi đó trước khi khách hàng phát hiện.
Khi agent quên sạch hội thoại sau một lần deploy, hay nhớ mãi điều người dùng đã bảo bỏ, đừng vội đổ lỗi cho model mà hãy tự hỏi: bạn đã quyết định lưu gì, lưu ở đâu và bao giờ xoá chưa?
Khi agent của khách hàng chạy sai lúc 2 giờ sáng, người tự viết vòng lặp sẽ biết ngay cần mở dòng code nào. Người chỉ biết gọi framework thì không.
Tài liệu quy trình của khách đã là một nửa prompt. Nửa còn lại là bộ ca kiểm thử để prompt không âm thầm hỏng khi model đổi phiên bản.
Khi trợ lý AI của khách hàng tự bịa ra một điều khoản không có thật, phải hiểu bốn khái niệm này thì bạn mới tìm được lỗi nằm ở đâu, thay vì chỉ biết sửa prompt rồi cầu may.
Hai con số, một bộ câu hỏi chuẩn và vài chục dòng Python đủ để bạn biết hệ thống tìm sai ở đâu, trước khi phải đọc câu trả lời sai của LLM.
Hai thứ quyết định agent được khách tin dùng hay bị khoá mãi ở chế độ duyệt tay: một bảng phân quyền kiểu đèn giao thông, và một bản bàn giao vẫn chạy được khi bạn đã rời dự án.
Lối tắt nhanh nhất vào một hệ thống cũ thường là lối gỡ ra đắt nhất, vì vậy cần chọn cửa vào trước khi bắt đầu viết code.
Một yêu cầu "tự động hoá review PR" có thể hoá ra là chuyện hai người duyệt code đang ngập việc, và bạn hoàn toàn học được cách phát hiện điều đó trước khi mất ba tuần build sai hướng.
Bản demo có thể chạy hoàn hảo, nhưng nếu bạn không trả lời được câu "nhân viên nghỉ việc thì bao lâu sau mất quyền truy cập?", đội bảo mật của khách sẽ không cho bạn lên production.
Khách thường xin một agent, nhưng câu hỏi bạn cần mang vào buổi họp lại khác: bạn có liệt kê trước được các bước hệ thống phải đi hay không.
Khi bạn là người duy nhất nhìn thấy hệ thống đang chạy, kỹ năng quý nhất là biến những gì mình thấy thành một bản tái hiện mà người ở xa chạy được ngay.
Năm mươi câu hỏi lấy từ lỗi thật, chấm đúng/sai bằng pytest và một LLM judge đã đối chiếu với nhãn chấm tay: đủ để biến cảm giác "có vẻ ổn hơn" thành một con số cả đội cùng tin.
Đoạn code bạn viết vội ở chỗ khách có thể chết cùng dự án đó, hoặc thành tính năng cho hàng trăm khách khác. Kết cục nào xảy ra phụ thuộc vào cách bạn ghi lại và chuyển nó về cho đội product.
Ở site khách hàng, FDE phải thuyết phục một đội kỹ sư không thuộc quyền mình đổi hệ thống của chính họ, và chức danh không giúp được gì trong việc đó.
Khi hệ thống bạn deploy hỏng ngay trên hạ tầng của khách hàng, 60 phút đầu cần một người điều phối hơn là thêm một người đọc log.
Lỗi đắt nhất của một tích hợp doanh nghiệp thường không làm sập hệ thống: nó lặng lẽ trừ tiền khách hai lần, hoặc bỏ sót một sự kiện mà không ai hay.
Ngày đầu ở site khách hàng, câu SQL đầu tiên bạn viết có thể chạy đúng cú pháp mà vẫn trả về con số sai, và người phát hiện ra đầu tiên lại là khách hàng.
CTO, kế toán trưởng, CFO và nhân viên ngồi trước màn hình cùng nhìn một hệ thống nhưng mỗi người hỏi một câu khác nhau. FDE nào chỉ trả lời được một câu thì deployment sẽ dừng ở bản demo.
Hệ thống bạn dựng có sống được sau khi bạn rời dự án hay không thường phụ thuộc vào vài trang giấy bạn viết vội trong tuần cuối.
Phần lớn công sức của một dự án AI nằm ở những việc diễn ra sau khi khách hàng vỗ tay ở buổi demo, và FDE thường là người phải gánh phần ấy.
Khi CFO của khách hàng hỏi dự án có đáng tiền không, câu "người dùng thấy nhanh hơn" sẽ không thuyết phục được ai.
Gật đầu với mọi yêu cầu thì dự án mất biên lợi nhuận, từ chối mọi yêu cầu thì mất luôn lý do khách chọn bạn, nên kỹ năng thật nằm ở chỗ biết yêu cầu nào thuộc loại nào.
Khi khách hỏi “chạy được trong VPC của chúng tôi không?”, họ cần biết control plane, compute và dữ liệu sẽ nằm ở đâu, nên một chữ “có” là chưa đủ.
Ngày đầu trên site khách hàng, ai cũng muốn agent làm được thật nhiều việc. Kỹ năng đáng tiền nằm ở chỗ khác: biết cắt quyền nào để một ticket chứa chỉ thị độc không biến thành sự cố rò rỉ dữ liệu.
Khách hỏi vì sao hóa đơn tuần này tăng vọt. Bạn chỉ trả lời được nếu mỗi lần gọi model đều để lại một span ghi token, tên tính năng và tên khách hàng.
Khi agent “tự hoàn tiền” trong buổi demo, thứ thực sự cầm tiền của khách hàng là đoạn vòng lặp vài chục dòng do FDE viết, chứ không phải mô hình.
Khi khách hàng gửi một thư mục PDF và đòi một chatbot, việc đầu tiên nên làm là đếm token, chưa phải chọn vector database.
Bộ test xanh trước ngày ra mắt chỉ cho biết agent làm đúng những gì bạn đoán người dùng sẽ hỏi. Còn những gì người dùng thật sự hỏi thì nằm trong trace.
Ở vòng quyết định, người phỏng vấn không đưa đề có input và output rõ ràng. Họ đưa một mục tiêu kinh doanh mơ hồ, rồi ngồi nghe bạn suy nghĩ thành tiếng.
Mô hình tốt đến đâu cũng đứng im nếu mã thiết bị ở hai hệ thống không khớp nhau, và người gỡ nút thắt đó thường là FDE.
Code là điều kiện bắt buộc để làm FDE, nhưng khi ứng viên đã qua ngưỡng đó, khả năng giao tiếp và thuyết phục khách hàng mới là thứ phân định ai được chọn.
Khách hàng không bao giờ đưa bạn một metric, họ chỉ đưa một lời phàn nàn, và việc của FDE là biến lời phàn nàn đó thành phép đo cả hai bên cùng ký vào.
Databricks neo mỗi FDE engagement vào OKR chung với khách trước khi bắt tay xây, và một tấm brief một trang chia ba tầng giúp bạn khoá phần "what" theo cách tương tự.
FDE giỏi triage những gì khách gửi từ tối hôm trước rồi mới bước vào standup của khách, để cuộc họp đó chốt được việc đáng làm nhất trong ngày.
Kevin B., FDE tại Rippling, gọi lời phàn nàn của khách là triệu chứng; việc của bạn là tìm ra căn bệnh trước khi viết dòng code đầu tiên.
Khi không có ai giữ vai Echo cho bạn, kỹ năng thật nằm ở chỗ biết lúc nào mình đang lắng nghe, lúc nào đang xây, và viết ra bản brief nối hai việc đó.
Khi code của bạn ship cho một khách hàng thay vì cho mọi người, cách bạn định nghĩa "xong", chọn giải pháp và nói chuyện mỗi ngày đều phải đổi.
Hai vai trò có thể vẽ cùng một sơ đồ, nhưng chỉ một người phải mở pull request vào repo của khách và đưa nó tới production ổn định.
Trong 300 dự án AI doanh nghiệp mà MIT NANDA khảo sát, 95% không tạo ra lợi nhuận đo được, và OpenAI lẫn Anthropic đang trả lời bằng cách gửi kỹ sư thẳng tới văn phòng khách hàng.
Với cùng một cặp kỹ thuật, một nghiên cứu cộng dồn được lợi ích còn một nghiên cứu khác ghi nhận mô hình kém đi. Với FDE, điều đó có nghĩa là phải phân loại lỗi và đo baseline trước khi chọn bất cứ thứ gì.
Khi prompt được version như code, chuyển label là deploy, eval chặn merge là test, còn kế hoạch rollback phải được viết trước khi sự cố xảy ra.
Câu "dữ liệu có hết trong warehouse rồi" thường chỉ đúng một nửa. FDE nào tin trọn câu đó có thể mất vài tuần mới phát hiện model của mình đang học từ một bảng dashboard.