Artifacts trong Antigravity: kiểm chứng agent không cần đọc code

TL;DR: Artifacts trong Antigravity là các sản phẩm hữu hình agent tạo ra trong lúc làm việc — Task List, Implementation Plan, Walkthrough, code diff, screenshot, browser recording. Thay vì đọc từng dòng code agent viết, bạn nhìn artifacts để kiểm chứng logic trong vài giây: kế hoạch có đúng hướng không, tiến độ tới đâu, kết quả có bằng chứng gì. Bài 5 của series hướng dẫn cách đọc từng loại artifact, comment để agent tự điều chỉnh, và quy trình review ba bước để không bị "agent làm bừa".

Hồi mới dùng thử các công cụ AI viết code, mình có một nỗi sợ rất cụ thể: agent chạy một mạch 10 phút, sửa 15 file, rồi báo "xong rồi nhé" — và mình chẳng biết bắt đầu kiểm tra từ đâu. Đọc hết diff thì mất cả buổi, mà không đọc thì chẳng khác gì ký giấy khống. Artifacts trong Antigravity sinh ra để giải đúng bài toán đó: agent phải nộp "bằng chứng công việc" ở mỗi giai đoạn, còn bạn kiểm chứng ở tầng logic thay vì tầng từng-dòng-code.

Nếu bạn chưa cài Antigravity hoặc chưa chạy task đầu tiên, nên đọc trước bài 4 về cách tạo task đầu tiên với agent — bài này tiếp nối trực tiếp từ đó.

Artifacts trong Antigravity là gì?

Theo tài liệu công bố trên trang chủ Antigravity, artifacts là "tangible deliverables" — sản phẩm hữu hình mà agent sinh ra song song với việc viết code. Chúng gồm mấy loại chính:

Artifact	Xuất hiện khi nào	Trả lời câu hỏi gì
Implementation Plan	Trước khi agent chạy	Agent định làm gì, theo hướng nào?
Task List	Trong lúc chạy	Đang ở bước mấy, còn bao nhiêu việc?
Code diff	Trong và sau khi chạy	Cụ thể file nào đổi, đổi ra sao?
Screenshot	Khi agent test giao diện	Kết quả nhìn thấy được như thế nào?
Browser recording	Khi agent tự test trên Chrome	Luồng thao tác end-to-end có chạy không?
Walkthrough	Sau khi hoàn thành	Đã thay đổi gì, kiểm thử ra sao?

Điểm mấu chốt: artifacts không phải log kỹ thuật khô khan. Chúng được viết cho con người đọc, ở độ cao vừa đủ để bạn nắm ý đồ của agent mà không phải lặn xuống từng dòng code.

Vì sao artifacts là khác biệt lớn so với chat AI thường?

Với chatbot viết code kiểu cũ, mọi thứ trộn lẫn trong một luồng chat dài: giải thích, code, xin lỗi, code sửa lại. Muốn biết "rốt cuộc nó đã làm gì", bạn phải cuộn ngược cả trăm tin nhắn.

Antigravity tách bạch hẳn: hội thoại là nơi trao đổi, còn artifacts là hồ sơ công việc. Cách tổ chức này thay đổi trải nghiệm review theo ba hướng:

• Kiểm chứng logic trong nháy mắt. Nhìn Implementation Plan 30 giây là biết agent hiểu đúng hay sai yêu cầu — trước khi nó viết bất kỳ dòng code nào.
• Bằng chứng thay vì lời hứa. Screenshot và browser recording cho thấy tính năng chạy thật, không phải agent "tự nhận" là chạy.
• Truy vết được. Mỗi task để lại chuỗi artifacts theo thứ tự thời gian. Một tuần sau quay lại vẫn dựng lại được chuyện gì đã xảy ra.

Mình để ý điều này giống hệt cách một dev senior giao việc cho junior: không soi từng dòng code ngay, mà hỏi "kế hoạch của em là gì?" trước, rồi mới xem kết quả kèm bằng chứng test. Antigravity ép agent làm việc theo đúng nề nếp đó. Đây cũng là triết lý agent-first mà mình đã giới thiệu trong bài mở đầu về Google Antigravity.

Đọc từng loại artifact như thế nào cho nhanh

Implementation Plan — chặn sai lầm từ gốc

Đây là artifact quan trọng nhất, vì nó xuất hiện trước khi code bị đụng tới. Khi đọc plan, mình tập trung ba câu hỏi:

1. Agent có hiểu đúng yêu cầu không, hay đang giải một bài khác?
2. Phạm vi có hợp lý không — nó định sửa 3 file hay 30 file?
3. Có bước nào nguy hiểm không (xoá dữ liệu, đổi schema, chạm file config)?

Sai ở tầng kế hoạch thì sửa rẻ. Sai phát hiện sau khi code xong thì đắt gấp nhiều lần.

Task List — theo dõi tiến độ không cần nhìn màn hình

Task List là checklist từng bước, tự tích dần khi agent làm xong mỗi mục. Với task dài, mình để agent chạy nền rồi thỉnh thoảng liếc Task List — giống xem thanh tiến độ, nhưng mỗi dòng là một việc có nghĩa chứ không phải phần trăm vô hồn.

Code diff, screenshot và browser recording — lớp bằng chứng

Code diff cho biết chính xác thay đổi ở đâu. Screenshot chứng minh giao diện render đúng. Browser recording — thứ mình thấy "đã" nhất — quay lại toàn bộ thao tác agent tự thực hiện trên Chrome khi test tính năng, chi tiết hơn ở bài 6 về browser control.

Walkthrough — bản báo cáo nghiệm thu

Kết thúc task, agent nộp Walkthrough: đã đổi gì, vì sao, test bằng cách nào. Mình coi đây là "biên bản bàn giao" — đọc xong là quyết định được chấp nhận, yêu cầu sửa, hay bỏ.

Auxiliary Pane: trung tâm điều khiển artifacts

Mọi artifact tập trung ở Auxiliary Pane, bật/tắt ở góc trên bên phải cửa sổ hội thoại. Pane này hiển thị ba nhóm nội dung: artifacts của task hiện tại, file nguồn liên quan, và chi tiết triển khai.

Thao tác mình dùng nhiều nhất ở đây là comment trực tiếp lên artifact. Quy trình rất tự nhiên:

1. Mở Implementation Plan trong Auxiliary Pane.
2. Thấy bước nào chưa ổn, comment thẳng vào đó — ví dụ "đừng đụng vào bảng users, chỉ thêm bảng mới".
3. Agent đọc comment, sửa lại plan, nộp bản mới.
4. Ưng rồi mới bấm Proceed cho chạy.

Cảm giác giống review pull request của đồng nghiệp hơn là "chat với bot". Và vì phản hồi gắn vào đúng vị trí trong artifact, agent hiểu ngữ cảnh chính xác hơn hẳn so với việc mô tả lại bằng lời trong khung chat.

Quy trình review ba bước để không bị agent làm bừa

Sau một thời gian dùng, mình chốt được quy trình ba chặng, bám đúng vòng đời artifact:

Chặng 1 — duyệt kế hoạch (trước khi chạy). Không bao giờ bấm Proceed mà chưa đọc Implementation Plan. Đây là chốt chặn rẻ nhất. Task càng mơ hồ, plan càng phải đọc kỹ.

Chặng 2 — liếc tiến độ (trong khi chạy). Theo dõi Task List. Nếu thấy agent lan man sang việc ngoài phạm vi — dừng lại và điều chỉnh ngay, đừng đợi nó "sáng tác" xong.

Chặng 3 — nghiệm thu bằng chứng (sau khi chạy). Đọc Walkthrough trước, xem screenshot/recording để xác nhận tính năng chạy, cuối cùng mới mở code diff ở những chỗ nhạy cảm.

Vài mẹo nhỏ kèm theo:

• Task nhỏ thì artifact ít, review nhanh — thêm một lý do để chia nhỏ yêu cầu thay vì giao một cục to.
• Với thay đổi liên quan auth, thanh toán, migration dữ liệu: luôn đọc diff bằng mắt, artifacts chỉ là lớp lọc đầu.
• Kết hợp với Git: mỗi task một branch, artifacts giúp bạn viết mô tả commit/PR cực nhanh vì Walkthrough đã tóm sẵn. Bạn nào chưa vững Git có thể xem lại bài Git cơ bản cho người mới.

Artifacts trong bức tranh lớn của Antigravity

Artifacts không đứng một mình. Chúng là chất keo nối hai surface chính — Editor và Agent Manager — mà mình đã mô tả trong bài 3 về giao diện Antigravity. Khi bạn chạy nhiều agent song song trong Agent Manager, artifacts chính là thứ giúp bạn "quản lý đội" mà không cần ngồi kèm từng con: mỗi agent tự nộp plan, tiến độ và bằng chứng, bạn chỉ đảo qua duyệt.

So với các công cụ cùng thời — mình từng viết về OpenCode, cách viết code AI miễn phí trên GitHub — thì artifacts là lý do chính khiến Antigravity tạo cảm giác "làm việc với đồng nghiệp" thay vì "xài máy sinh code". Bạn có thể xem thêm các chuỗi bài khác của blog ở trang tổng hợp series hoặc dạo chuyên mục Công nghệ.

Kết: kiểm chứng bằng artifacts, không kiểm chứng bằng niềm tin

Điều mình muốn bạn mang về từ bài này: sức mạnh của agent chỉ hữu ích khi bạn kiểm soát được nó, và artifacts trong Antigravity là cơ chế kiểm soát được thiết kế sẵn — kế hoạch trước, tiến độ giữa, bằng chứng sau. Đọc plan trước khi Proceed, liếc Task List khi chạy, nghiệm thu bằng Walkthrough và recording. Ba thói quen đó biến agent từ "hộp đen đáng ngờ" thành cộng sự có báo cáo rõ ràng.

Bước tiếp theo, hãy xem lớp bằng chứng ấn tượng nhất hoạt động ra sao: agent tự mở Chrome, tự click, tự điền form để test tính năng nó vừa viết — tất cả trong bài 6: Browser control trong Antigravity.