Tháng 3/2026, Anthropic ra mắt Claude Certified Architect — Foundations (CCA-F), chứng chỉ kỹ thuật chính thức đầu tiên dành cho những người trực tiếp xây dựng hệ thống với Claude, thay vì chỉ sử dụng AI để hỏi đáp.
Điều khiến chúng tôi quan tâm không phải là tấm chứng chỉ, mà là cách bài thi được thiết kế. Thay vì kiểm tra khả năng ghi nhớ tài liệu hay cú pháp API, bài thi đặt người làm AI vào những tình huống thực tế: khi nào nên chia một tác vụ cho nhiều agent, khi nào cần con người can thiệp, làm thế nào để đánh giá một hệ thống AI có đủ đáng tin cậy để đưa vào vận hành. Đó cũng chính là những câu hỏi mà đội ngũ kỹ sư của ZTO phải đối mặt mỗi ngày.
Các kỹ sư của chúng tôi có cơ hội tham gia kỳ thi sau khi ZTO trở thành thành viên của Claude Partner Network. Với chúng tôi, đây không phải là dịp để sưu tầm thêm một chứng chỉ, mà là cơ hội để kiểm chứng chính cách mình đang làm việc với AI.
Vì sao ZTO chọn Claude Certified Architect?
Chúng tôi muốn trả lời hai câu hỏi.
Thứ nhất, đội ngũ của mình có thực sự hiểu mình đang xây dựng điều gì với AI, hay chỉ là những người sử dụng AI rất nhiều nhưng chưa chắc đã sử dụng đúng? Claude là công cụ chúng tôi làm việc cùng mỗi ngày, nên một bài thi do chính Anthropic xây dựng là cách trực diện nhất để biết mình đang đứng ở đâu.
Thứ hai, triết lý đào tạo mà ZTO theo đuổi có thực sự đúng? Chúng tôi luôn tin rằng làm việc hiệu quả với AI không đơn giản là viết prompt hay hơn hay điều khiển công cụ thành thạo hơn. Điều quan trọng hơn là biết cách thiết kế cả một hệ thống xung quanh AI: tổ chức agent, quản lý context, thiết kế tool, xác định khi nào con người cần tham gia và khi nào hệ thống có thể tự vận hành. Nói cách khác, chúng tôi muốn giúp cá nhân và doanh nghiệp làm chủ AI, thay vì chỉ trở thành người vận hành công cụ.
Claude Certified Architect là một trong số ít bài thi độc lập kiểm tra đúng tầng tư duy đó. Bài thi kéo dài 120 phút với 60 câu hỏi, yêu cầu người tham gia đạt tối thiểu 720/1000 điểm. Nội dung trải rộng trên năm lĩnh vực: kiến trúc agent, Claude Code, thiết kế tool và MCP, prompt engineering, quản lý context và độ tin cậy của hệ thống. Không có câu hỏi nào yêu cầu học thuộc lòng tài liệu. Hầu hết đều là các tình huống buộc người làm AI phải cân nhắc giữa nhiều lựa chọn thiết kế khác nhau và đưa ra quyết định phù hợp với từng bối cảnh.
Bài viết này không tập trung vào kỳ thi hay cách ôn luyện. Thay vào đó, chúng tôi muốn chia sẻ điều mà bốn kỹ sư trong đội ngũ rút ra sau hành trình học và vượt qua Claude Certified Architect. Họ bước vào kỳ thi với những điểm xuất phát rất khác nhau và cũng thay đổi theo những cách rất khác nhau. Nhưng tất cả đều dẫn đến cùng một kết luận: điều tạo nên sự khác biệt khi làm việc với AI không nằm ở việc viết một prompt tốt hơn, mà ở cách bạn thiết kế cả hệ thống phía sau nó.
Bốn kỹ sư, bốn xuất phát điểm khác hẳn nhau
Bốn kỹ sư tham gia kỳ thi từ những xuất phát điểm rất khác nhau, từ người mới chỉ xem AI như một công cụ tìm kiếm thuận tiện hơn, đến người đã dựng hệ thống multi-agent nhiều năm. Khoảng cách này quyết định mỗi người rút ra điều gì sau hành trình với Claude Certified Architect.
Lộc, một frontend engineer, chủ yếu dùng AI như một công cụ tìm kiếm thông minh hơn và để hỗ trợ viết tiếp code. “Cách dùng của tôi còn khá rời rạc: hỏi một câu, nhận một câu trả lời, dùng được phần nào thì lấy phần đó, rồi tiếp tục tự làm phần còn lại.”
Happy, cũng là frontend engineer, sử dụng AI ở gần như toàn bộ quy trình làm việc, nhưng mỗi lần chỉ xem đó là một tác vụ riêng lẻ, chưa có một cách tiếp cận xuyên suốt.
Hiếu, một backend engineer, đã có kinh nghiệm xây dựng các hệ thống AI trong thực tế. Tuy nhiên, phần lớn quyết định vẫn dựa vào kinh nghiệm và cảm tính: prompt được chỉnh sửa cho đến khi thấy ổn, ngưỡng confidence được đặt theo cảm tính, còn một agent duy nhất được giao xử lý gần như toàn bộ công việc thay vì chia nhỏ thành nhiều tác vụ.
Trái ngược với Lộc, Kyle, một frontend engineer khác, đã có nhiều năm xây dựng các hệ thống agentic. Anh phát triển kiến trúc multi-agent, xây custom slash command, tích hợp CI/CD và làm việc với AI từ 8 đến 16 tiếng mỗi ngày trên nhiều dự án song song. Bước vào kỳ thi, Kyle không tìm kiếm một kỹ thuật prompting tốt hơn. Điều anh muốn là kiểm chứng và mài giũa cách mình đang thiết kế hệ thống AI.
Hành trình với Claude Certified Architect
Quan niệm sai lầm ban đầu về chứng chỉ
Có một điểm gần như ai cũng bất ngờ lúc mới tham gia kỳ thi: bài thi không kiểm tra kiến thức học thuộc mà kiểm tra năng lực phán đoán của người vận hành hệ thống. Hiếu là người bất ngờ nhất về nội dung bài thi:
“Tôi nghĩ nội dung sẽ là câu hỏi kiến thức: tham số API, cú pháp, ‘flag nào làm gì.’ Thực ra bài thi kiểm tra khả năng phán đoán: trong tình huống này, con người cần can thiệp ở đâu, khi nào nên chia việc cho nhiều agent phối hợp, khi nào chỉ cần một cách giải đơn giản, làm sao biết hệ thống có đáng tin không.”
— Hiếu
Kyle, dù đã xây hệ thống agentic nhiều năm, cũng cùng chung bất ngờ với Hiếu, khi thấy bài thi kiểm tra khả năng phán đoán chứ không xem ai có trí nhớ tốt hơn.
Không phải ai cũng vượt qua quá trình chuẩn bị một cách suôn sẻ. Happy từng không đạt ở lần mock test đầu tiên. Điều khiến anh bất ngờ không phải là thiếu kiến thức, mà là việc mình vẫn tiếp cận AI như một chuỗi tác vụ rời rạc. Chính lần thất bại đó khiến anh thay đổi cách học và cũng là tiền đề cho góc nhìn mới về system design sau kỳ thi.
Bài học rút ra được sau kỳ thi
Nhưng đó cũng là điểm chung duy nhất. Cả bốn đều bước vào kỳ thi với cùng một hiểu lầm về việc xây dựng hệ thống AI. Sau kỳ thi, mỗi người lại nhìn ra một bài học hoàn toàn khác nhau.
LỘC VÀ HAPPY: TỪ RA LỆNH ĐẾN THIẾT KẾ HỆ THỐNG
Với Lộc và Happy, thay đổi nằm ở chính thứ ai cũng tưởng là quan trọng nhất: câu lệnh. Lộc từng coi AI chỉ như một công cụ tìm kiếm xịn hơn. Happy thì gói gọn sự chuyển dịch trong một câu:
“Trước đây tôi nghĩ làm việc với AI chủ yếu là prompting, hướng dẫn đúng rồi để nó tự xử lý. Giờ tôi nghĩ kỹ năng thật là system design: cách cấu trúc context, quản lý quyền truy cập tool, điều phối nhiều agent phối hợp với nhau. Prompt chỉ là bước cuối.”
— Happy
HIẾU: ĐÒN BẨY NẰM Ở THIẾT KẾ TOOL
Với Hiếu, sự thay đổi nằm ở cách thiết kế công cụ. “Trước kia, bản năng của tôi là xây agent tốt hơn bằng cách nhồi thêm tool hoặc điều chỉnh prompt. Qua kỳ thi, tôi nhận thấy đòn bẩy thật sự nằm ở giao diện công cụ: ranh giới rõ ràng, phạm vi được định nghĩa tốt, tên gọi chính xác, quyết định tool đó được phép làm gì và từ chối làm gì. Một ranh giới công cụ được thiết kế tốt làm được nhiều hơn bất kỳ câu lệnh khéo léo nào.”
Một thay đổi khác đến từ cách Hiếu nhìn nhận confidence score của mô hình. Trước đó, anh từng xây dựng một chatbot hỗ trợ khách hàng, nơi AI sẽ tự trả lời hoặc chuyển sang nhân viên dựa trên confidence score. Khi ấy, Hiếu luôn nghĩ rằng nếu AI báo confidence 0.90 thì có nghĩa là nó sẽ đúng trong khoảng 90% trường hợp.
Sau kỳ thi, anh nhận ra điều đó không hoàn toàn đúng.
“Khi AI nói nó ‘chắc chắn 90%’, điều đó không có nghĩa là nó sẽ đúng 9 trên 10 lần. Confidence score chỉ thực sự có ý nghĩa khi được kiểm chứng trên dữ liệu đã biết đáp án. Thậm chí, một hệ thống đạt độ chính xác 97% trên toàn bộ tập dữ liệu vẫn có thể chỉ đạt 40% ở chính những trường hợp hiếm nhưng quan trọng nhất.”
— Hiếu
KYLE: VẤN ĐỀ KHÔNG NẰM Ở MODEL
Với Kyle, người đã quen với tư duy hệ thống, kỳ thi không làm anh thay đổi cách nhìn về prompting. Điều thay đổi lớn nhất là cách anh đánh giá vai trò của model trong một hệ thống AI.
“Trước đây, tôi dành rất nhiều sự tập trung cho năng lực của model. Nhưng càng làm, tôi càng nhận ra agent, skill, tool, cách quản lý context hay thiết kế quy trình làm việc mới là những yếu tố quyết định chất lượng của cả hệ thống, hơn là bản thân model. Một hệ thống gồm nhiều agent chuyên biệt thường hiệu quả hơn một agent duy nhất cố gắng làm tất cả.”
Nhận thức đó cũng khiến Kyle thay đổi cách tối ưu hệ thống. Thay vì tập trung cải thiện từng agent riêng lẻ, anh bắt đầu nhìn toàn bộ workflow như một thể thống nhất, nơi giá trị nằm ở cách các thành phần phối hợp với nhau.
“Tôi từng tối ưu từng agent riêng lẻ. Giờ tôi tối ưu cả hệ thống.”
— Kyle
Sự thay đổi trong cách làm việc với AI
Kỳ thi không chỉ thay đổi cách họ nhìn về AI, mà còn thay đổi cách họ làm việc với AI mỗi ngày.
| Kỹ sư | Trước kỳ thi | Sau kỳ thi |
|---|---|---|
| Hiếu | Tin vào điểm tự tin của AI để cho chạy tự động | Kiểm chứng điểm tự tin bằng dữ liệu thật trước khi để AI tự quyết |
| Kyle | Dựa vào prompt trong một, hai phiên làm việc | Lên kế hoạch và định ra tiêu chí đánh giá từ đầu; đối xử agent như một bộ phận phần mềm, chạy thử từng phần nhỏ trước khi giao việc thật |
| Lộc | Dùng AI rời rạc, viết tay phần lớn | Dùng AI trong hơn 90% công việc, tập trung thời gian vào việc đưa context cho AI và kiểm tra đầu ra |
| Happy | Dồn mọi việc cho một agent | Chia nhỏ cho nhiều agent con phối hợp |
Từ việc thi chứng chỉ đến suy ngẫm về hướng đi của nghề
Bốn kỹ sư bước vào Claude Certified Architect với những xuất phát điểm khác nhau và cũng rút ra những bài học rất khác nhau. Nhưng nhìn rộng hơn, tất cả đều dẫn đến một suy nghĩ chung: điều tạo nên giá trị của một kỹ sư AI không còn chỉ nằm ở việc chọn model mạnh hơn hay viết prompt tốt hơn, mà ở khả năng thiết kế, kiểm chứng và vận hành cả một hệ thống AI.
Hiếu đặc biệt nhấn mạnh vai trò của việc đánh giá đầu ra:
“Nếu bạn không có một bộ dữ liệu để kiểm chứng AI đúng hay sai, bạn không có một sản phẩm AI. Bạn chỉ có một bản demo.”
— Hiếu
Happy thì cho rằng việc để agent vận hành hoàn toàn tự động vẫn còn quá rủi ro, ít nhất ở thời điểm hiện tại. Theo anh, giá trị thật nằm ở việc xác định đúng những điểm mà con người cần tham gia trong quy trình, thay vì cố gắng loại bỏ con người khỏi hệ thống.
Lộc lại quay về một điều tưởng chừng đã cũ: nền tảng kỹ thuật vẫn là yếu tố quan trọng nhất. AI có thể viết code, nhưng con người vẫn phải chịu trách nhiệm đánh giá đoạn code đó có đúng, có an toàn và có dễ bảo trì hay không. Trong thời đại AI, năng lực cốt lõi không chỉ là biết sử dụng AI, mà còn là có đủ nền tảng để đặt đúng bài toán và cung cấp đúng ngữ cảnh cho AI.
Trong khi nhiều cuộc thảo luận về AI vẫn tập trung vào việc chọn model mạnh hơn, viết prompt tốt hơn hay đẩy agent tự động hóa xa hơn, bốn kỹ sư của ZTO lại cùng rút ra một kết luận khác. Điều tạo nên khác biệt không còn nằm ở từng thành phần riêng lẻ, mà ở cách cả hệ thống được thiết kế và vận hành.
Như Kyle chia sẻ về tương lai của nghề:
“Lập trình viên sẽ dành ít thời gian hơn để tạo ra sản phẩm, và nhiều thời gian hơn để thiết kế cách những sản phẩm đó được tạo ra.”
— Kyle
Lời kết
Bốn kỹ sư của chúng tôi bước vào kỳ thi từ bốn xuất phát điểm khác nhau, và kết thúc với bốn bài học khác nhau. Nhưng tất cả đều chạm vào cùng một điều ZTO tin từ đầu: thứ tạo ra khác biệt khi làm việc với AI không đơn giản là biết cách viết một câu prompt tốt hơn mà là khả năng thiết kế hệ thống quanh nó. Khi nào nên chia việc cho nhiều agent và chia như thế nào? Khi nào cần có sự kiểm soát của con người? Khi nào biết hệ thống của mình có thật sự đáng tin? Đó là khoảng cách giữa người vận hành công cụ và người làm chủ.
Chứng chỉ là một cách để kiểm chứng khoảng cách đó. Nhưng nó không phải con đường duy nhất. Các chương trình đào tạo của ZTO, từ AI Practitioner cho người không chuyên đến AI Engineer cho lập trình viên, đều được thiết kế quanh đúng một câu hỏi: làm sao để bạn chuyển mình từ bước vận hành công cụ sang bắt đầu làm chủ cả hệ thống?
Chúng tôi không dạy AI từ sách vở, mà từ chính những gì đội ngũ của mình đã trực tiếp xây, thử, sai và sửa mỗi ngày. Bốn kỹ sư trên là một ví dụ: kinh nghiệm họ mang vào lớp học là kinh nghiệm thực chiến, không phải lý thuyết suông. Trong các bài viết tới, chúng tôi sẽ tiếp tục chia sẻ chi tiết hành trình ôn luyện và những mẹo làm bài thi hiệu quả.
Ngoài ra, xem các chương trình đào tạo của ZTO tại: ztolabs.com/programs.html
Bài viết của đội ngũ ZTO Labs, chuyên đào tạo và nghiên cứu AI tại Việt Nam.
