Trong một dự án offshore, đối với IT Communicator, có những công việc không hề khó, chỉ là đòi hỏi nhiều thời gian để hoàn thành. Chẳng hạn như việc dịch lại tài liệu thiết kế vừa được cập nhật. Hoặc là tạo một file testcase cho một màn hình mới. Hay là việc chuẩn bị data trước khi bắt đầu test. Trong bối cảnh AI không ngừng mở rộng sang nhiều lĩnh vực, chúng tôi cũng đã thử giao bớt những phần công việc mang tính lặp lại như vậy cho AI, và ghi lại một cách chân thật kết quả đã đạt được. Trong đó có cả chỗ hiệu quả thấy rõ, lẫn chỗ mà hiện tại để con người làm vẫn hợp lý hơn.

Công việc của IT Communicator: nhiều hơn hai chữ "phiên dịch"

Nhiều người hình dung IT Communicator (COM) đơn giản chỉ là người phiên dịch trong dự án. Thực tế thì phạm vi rộng hơn thế khá nhiều. COM là điểm nối giữa lập trình viên, quản lý dự án phía Việt Nam với kỹ sư và khách hàng phía Nhật Bản. Trách nhiệm đi kèm với vị trí đó cũng trải dài suốt vòng đời của một dự án.

Hình 1. IT Communicator là điểm nối giữa hai đầu cầu của dự án.

Một COM không chỉ đơn thuần là người dịch các tài liệu thiết kế sang tiếng Việt, mà còn là người đọc thiết kế để nắm logic nghiệp vụ, phát hiện chỗ mô tả chưa rõ và đặt câu hỏi (QA) gửi lại phía Nhật Bản. Tùy độ phức tạp của tài liệu thiết kế, COM sẽ phải tổ chức buổi giải thích thiết kế cho đội ngũ phát triển. Ngoài ra, COM có thể sẽ phụ trách cả việc viết testcase UT (unit test — kiểm thử đơn vị) và IT (integration test — kiểm thử kết hợp), chuẩn bị data, tự tay test rồi test lại sau khi bug được sửa. COM cũng là người sẽ phải phụ trách việc thông dịch và báo cáo tiến độ trong các cuộc họp với bên Nhật Bản.

Đặt các công việc ấy cạnh nhau, chúng ta sẽ thấy hai nhóm khác hẳn nhau. Một nhóm là phần giao tiếp và phán đoán, vốn gắn chặt với con người và rất khó thay thế. Nhóm còn lại là phần xử lý tài liệu, xử lý dữ liệu, phần lớn lặp lại theo một khuôn mẫu quen thuộc. Chính phần khuôn mẫu ấy là nơi chúng tôi thử đặt AI vào trước tiên, cụ thể ở bốn công việc dưới đây.

Trước khi nói đến hiệu quả, hãy nói về công cụ và ranh giới dữ liệu

Về công cụ, phần lớn những việc dưới đây được làm ngay trong VS Code với GitHub Copilot và Claude Code, kèm theo các bộ hướng dẫn (instruction, skill,...) do chính đội dự án viết và tinh chỉnh dần qua từng lần dùng. Ở giai đoạn được nói tới trong bài, model chúng tôi dùng là Claude Sonnet 4.5; hiện tại đội đã chuyển sang Claude Opus 5.

Tài liệu thiết kế trong một dự án offshore là tài sản của khách hàng, nên trước khi đưa bất cứ nội dung nào vào AI, chúng tôi xác định trước mấy nguyên tắc. Chỉ sử dụng các dịch vụ ở mức doanh nghiệp có cam kết không dùng dữ liệu đầu vào để huấn luyện model. Chỉ đưa vào AI đúng phần nội dung mà công việc đang cần, thay vì upload trọn bộ tài liệu khi không cần thiết, và lược bỏ hoặc thay thế những thông tin nhạy cảm như dữ liệu thật của người dùng hay thông tin kết nối hệ thống. Và quan trọng nhất, phạm vi sử dụng AI phải nằm trong khuôn khổ đã thống nhất với khách hàng, chứ không phải là quyết định riêng của đội phát triển.

Bốn việc chúng tôi đã giao cho AI

Hình 2. Phân vai giữa AI và COM ở bốn công việc.

Dịch thuật tài liệu

Đây là nơi AI được đưa vào sớm nhất, và cũng là nơi cho kết quả rõ ràng nhất.

Với tài liệu dù ở dạng Markdown, Word, PowerPoint hay PDF, AI đều có thể dịch được. Việc còn lại của COM là đọc lại và chỉnh những chỗ chưa ổn.

Riêng trường hợp không phải tài liệu mới hoàn toàn mà là tài liệu đã dịch được cập nhật thêm, chúng tôi đã đóng gói các công đoạn lặp lại thành một skill riêng. Chuyện chỉ dịch phần thay đổi thì COM vốn vẫn làm; cái khác nằm ở chỗ từ bước dò commit, khoanh vùng phần thay đổi, cho tới tìm đúng vị trí trong bản dịch cũ rồi ráp nội dung mới vào sao cho khớp văn phong — những bước tốn công và dễ sót ấy giờ đã chạy tự động.

Hình 3. Quy trình cập nhật bản dịch theo commit, trước và sau khi đóng gói thành skill.

Ở giai đoạn đầu, khi COM chưa ứng dụng AI một cách nhuần nhuyễn, đội ngũ phát triển đã dựng riêng cho COM một trang web dịch thuật. Thao tác khá đơn giản: chỉ cần upload tài liệu Markdown cần dịch, chờ một lát, rồi nhận link tải bản đã dịch về. Về sau, khi mọi người đã sử dụng quen GitHub Copilot và Claude Code trong VS Code, thì trang web đó dần không còn được dùng nữa.

Đọc hiểu logic tài liệu

Trước đây khi tài liệu thiết kế khó hiểu, COM phải đọc đi đọc lại nhiều lần, nếu vẫn thấy khó hiểu thì sẽ đặt QA hỏi bên Nhật Bản. Giờ đây khi gặp tài liệu khó hiểu, COM đã có thể nhờ AI giải thích và đưa ra gợi ý, từ đó phát hiện thêm những chỗ khác cần hỏi phía Nhật Bản. Ngoài ra, AI còn có thể tóm tắt luồng nghiệp vụ trước, giúp cho buổi họp giải thích nghiệp vụ diễn ra suôn sẻ hơn.

Dù vậy, AI ở đây không ra quyết định thay COM. AI đóng vai trò một người đọc thứ hai, một trợ lý có thể đọc nhanh, đọc lại bao nhiêu lần cũng được, và gợi ý ra chỗ đang xảy ra mâu thuẫn. Việc kiểm chứng và chốt lại thì vẫn thuộc về COM. Khác với phần dịch thuật và phần viết testcase, công việc này không cần đóng gói thành bộ hướng dẫn riêng, mà chỉ là trao đổi trực tiếp với AI ngay trên tài liệu đang đọc.

Viết testcase UT và IT

Chúng tôi đã đóng gói yêu cầu viết testcase thành một bộ hướng dẫn riêng và giao vai trò người viết cho AI. Dựa theo đó, AI sinh ra bảng testcase bám sát tài liệu thiết kế. Còn COM thì lùi về vai trò người review: bổ sung case còn thiếu, loại bỏ case sai, đối chiếu lại một lượt với thiết kế trước khi đưa vào sử dụng.

Testcase UT và IT được tách thành hai bộ hướng dẫn riêng, bởi hai loại này cho ra format khác hẳn nhau. UT thì đi theo từng màn hình hoặc từng API riêng lẻ, còn IT là kịch bản nghiệp vụ chạy xuyên nhiều màn hình và được viết theo góc nhìn của từng role.

Chuẩn bị data test

Với những màn hình có dữ liệu ràng buộc qua nhiều bảng, việc dựng data test bằng tay rất tốn thời gian. Chỉ cần thiếu một bản ghi ở bảng cha thì cả bộ data phía dưới cũng trở nên vô nghĩa. Giờ đây phần viết SQL đã có AI đảm nhiệm: COM mô tả bộ data mà testcase cần rồi để AI sinh ra câu lệnh dựa trên thiết kế DB, sau đó chỉ việc import và bắt đầu test từng testcase một.

Dù vậy, AI cũng chỉ đảm nhiệm được phần ràng buộc mang tính kỹ thuật. Câu SQL mà AI viết ra thoả đúng các khóa ngoại giữa những bảng liên quan, nhưng bộ data thì còn phải thỏa cả điều kiện nghiệp vụ mà từng testcase cần đến. Phần đó COM vẫn phải tự đọc thiết kế rồi chỉ định trước cho AI.

Tiết kiệm được bao nhiêu thời gian

Hình 4. Mức thời gian tiết kiệm được (ước lượng) ở ba công việc.

Cần nói ngay rằng đây là những con số ước lượng mang tính chủ quan, dựa trên cảm nhận và ghi nhận không chính thức của các COM trong đội khi so sánh cùng một loại công việc trước và sau khi có AI. Đây không phải là kết quả của một phép đo có kiểm soát, nên có thể xem chúng như một dấu hiệu về độ lớn của thay đổi, hơn là một con số chính xác.

Con số 50–80% ở phần dịch thuật cần nói thêm một chút, bởi nó không đạt được ngay từ những ngày đầu. Ở giai đoạn mới áp dụng AI, COM vẫn phải mất thời gian để chỉnh sửa lại format của bản dịch và thống nhất từ vựng, tiết kiệm được thời gian ở khâu này thì lại mất thêm thời gian ở khâu kia. Tốc độ chỉ thực sự tăng lên khi bộ hướng dẫn (instruction, skill,...) đã được viết một cách đầy đủ.

Con số khoảng 50% ở phần chuẩn bị data test đến từ việc bỏ được công đoạn dò quan hệ giữa các bảng rồi viết SQL bằng tay. Phần thời gian còn lại vẫn phải bỏ ra: import, chạy thử và xác nhận rằng bộ data dựng lên đúng là bộ data mà testcase cần.

Riêng con số khoảng 50% ở phần viết testcase thì chỉ đúng với một loại màn hình nhất định, và đó cũng là chỗ chúng tôi gặp giới hạn rõ nhất. Phần dưới nói rõ hơn chuyện này.

Ngoài ba con số trên, ở phần đọc hiểu logic còn có một kết quả không đo được bằng thời gian, và cũng nằm ngoài dự tính. AI không dừng lại ở việc chỉ ra lỗ hổng logic, mà còn đề xuất cả hướng sửa. Những đề xuất đó tất nhiên không thể dùng trực tiếp mà không có sự kiểm chứng lại. Tuy chỉ được xem như một nguồn tham khảo, nhưng chúng cũng giúp ích nhiều khi COM chuẩn bị nội dung QA: sau khi kiểm chứng được đề xuất của AI, COM thay vì chỉ hỏi "chỗ này chưa rõ", câu hỏi gửi đi có thể có thêm một phương án cụ thể để phía Nhật Bản cân nhắc.

Chỗ chúng tôi phải viết tay lại từ đầu

Không phải nội dung công việc nào cũng cho kết quả như nhau. Với phần dịch thuật, việc áp dụng AI cho ra kết quả khá lạc quan. Với phần viết testcase thì lại phụ thuộc vào loại màn hình. Ở những màn hình chỉ có một tầng phân quyền, AI sinh ra testcase phần lớn dùng được ngay, từ đó tiết kiệm được khoảng một nửa thời gian. Ngược lại, ở những màn hình có nhiều tầng phân quyền lồng nhau, AI vẫn sinh ra đủ số lượng case nhưng gán sai quyền hạn ở gần như toàn bộ, số case phải sửa quá nhiều, khiến việc sửa lại từng case còn tốn thời gian hơn so với viết mới. Cuối cùng chúng tôi đã bỏ hẳn kết quả đó và ngồi viết tay lại từ đầu.

Dù vậy, chúng tôi không vội kết luận rằng AI không làm được việc này. Nhìn lại thì AI không làm sai so với prompt, prompt chỉ đơn giản là không yêu cầu điều đó. Vấn đề nằm ở hai chỗ, và cả hai đều thuộc về phía chúng tôi. Thứ nhất, prompt khi đó chưa mô tả chi tiết và đầy đủ các trường hợp ràng buộc giữa các tầng quyền hạn. Thứ hai, cách chúng tôi dùng model khi đó cũng chưa khai thác được khả năng suy luận qua nhiều lớp điều kiện chồng lên nhau. Cả hai đều là những thứ hoàn toàn có thể cải thiện, và đó cũng là hướng chúng tôi đang đi.

Ba điều rút ra sau một thời gian áp dụng:

1. Chất lượng đầu ra phụ thuộc vào chất lượng bộ hướng dẫn (instruction, skill,...). Lần chạy đầu tiên hiếm khi cho ra kết quả dùng được ngay, hiệu quả thật sự chỉ đến sau vài vòng tinh chỉnh.
2. Phải đo theo nội dung từng công việc, không thể đo chung với nhau. Cùng một công cụ, cùng một dự án, nhưng nếu hai loại màn hình khác nhau thì kết quả cho ra cũng khác hẳn nhau.
3. Vai trò của COM chỉ dịch chuyển chứ không mất đi. Trọng tâm rời khỏi việc tự tay làm ra sản phẩm, để dồn công sức về phần review và chịu trách nhiệm cho những gì được bàn giao.

Cảm nhận sau một thời gian dùng

Thành thật mà nói, lúc mới bắt đầu chúng tôi cũng chỉ mang tâm lý thử nghiệm. Nỗi lo lớn nhất là liệu có thực sự tiết kiệm được thời gian hay không: bản dịch AI trả về vẫn phải đọc lại từng dòng, thuật ngữ chuyên ngành dịch sai, format thì vỡ — sửa hết chừng đó có khi còn lâu hơn tự dịch từ đầu. Song song với đó là một quan ngại khác: tài liệu thiết kế này là của khách hàng, đưa vào AI thì có được phép không, và đưa tới đâu thì phải dừng.

Chúng tôi bắt đầu mong đợi nhiều hơn ở AI khi dần khai thác được nó vào từng công việc cụ thể. Chẳng hạn như việc cập nhật bản dịch theo commit: dò commit, khoanh vùng phần vừa thay đổi, tìm đúng vị trí trong bản dịch cũ rồi ráp nội dung mới vào. Nhờ có AI mà công đoạn vốn phải ngồi cả buổi này giờ chỉ còn mất vài phút. Ngoài ra, AI cũng đã chỉ ra được những chỗ mâu thuẫn trong tài liệu thiết kế mà COM đọc đi đọc lại vẫn không nhận ra.

Bên cạnh đó, AI còn mang lại cho chúng tôi vài điều bất ngờ. Như đã nói ở phần trên, AI không dừng lại ở việc chỉ ra lỗ hổng mà còn đề xuất luôn hướng sửa. Hơn nữa, viết prompt hoá ra là một kỹ năng cần phải học: nếu chỉ đơn giản đưa ra một câu lệnh thì kết quả rất có khả năng sẽ không như mong đợi. Càng cải thiện kỹ năng viết prompt, chúng tôi càng nhận được kết quả tốt hơn.

Cuối cùng, có một điều chúng tôi muốn nói rõ, bởi nó dễ bị hiểu nhầm khi nhìn vào những con số phía trên. Phần tiết kiệm được chủ yếu là thời gian tạo ra sản phẩm, còn thời gian đọc lại thì gần như không đổi. Đến thời điểm này, AI đã trở thành một phần trong nhịp làm việc hằng ngày của COM chứ không còn là thứ mang ra dùng thử, nhưng nó vẫn ở vị trí một công cụ hỗ trợ, chưa thay được người đưa ra quyết định.

Kết luận

Nhìn lại cả quá trình, ở những công việc có khuôn mẫu rõ ràng thì mức tiết kiệm là đáng kể, đủ để thay đổi cách một COM sắp xếp thời gian của mình. Tuy nhiên, con số cũng chỉ mới là một nửa câu chuyện.

Nửa còn lại nằm ở quan điểm làm việc của mỗi người. COM bớt được thời gian gõ lại những thứ vốn đã có sẵn ở đâu đó, và dành được nhiều hơn cho phần mà không công cụ nào làm thay được: hiểu đúng nghiệp vụ, đặt câu hỏi vào đúng chỗ, và giữ chất lượng cho những gì mình sẽ bàn giao.