Có một tình huống ngày càng quen thuộc với các đội dev dùng AI agent: bạn giao một tính năng, agent viết code, chạy test, thấy lỗi, tự sửa test cho đến khi mọi thứ chuyển xanh. Nhìn vào dashboard, mọi thứ đều ổn — build pass, pipeline xanh, test confirm hệ thống chạy đúng.
Nhưng đúng theo cái gì?
Đó chính là câu hỏi khó chịu đang nổi lên trong thời đại "agentic coding". Khi cùng một quy trình vừa tạo ra code, vừa tạo ra bằng chứng rằng code đó đúng, thì ai là người kiểm chứng độc lập?
Test tự sinh: tiện, nhưng có thể chỉ là cái bóng của code
Về mặt truyền thống, automated test được kỳ vọng đóng vai trò như một "trọng tài" độc lập — mô tả hành vi nên xảy ra, và báo động khi code làm sai điều đó.
Vấn đề là khi một AI agent vừa code vừa tự viết/sửa test, ranh giới độc lập đó rất dễ biến mất. Agent viết feature, chạy test, thấy fail, rồi chỉnh lại test cho tới khi pass — nghe rất hợp lý, nhưng kết quả cuối cùng có thể chỉ là bộ test mô tả lại những gì implementation hiện tại đang làm, chứ không còn xác minh điều nó nên làm.
Rủi ro này càng rõ khi agent suy luận hành vi mong muốn ngay từ chính source code. Nếu code có một chỗ hiểu sai yêu cầu, test sinh ra từ đó sẽ hồn nhiên "đóng dấu đúng" cho chính cái sai đó. Lúc này, test suite không còn là công cụ kiểm chứng — nó chỉ còn là tấm gương phản chiếu code.
Một dấu hiệu rất thực tế để nhận ra vấn đề này: đội ngũ bắt đầu thấy agent tốn cả chục phút mỗi phiên làm việc chỉ để "vá" lại test end-to-end — sửa assertion, đổi selector, tạo lại snapshot. Công cụ self-healing giúp được phần kỹ thuật (test không bị vỡ vì UI đổi vặt), nhưng không giúp được phần quan trọng hơn: liệu kỳ vọng hành vi đằng sau test đó có còn đúng hay không. Việc vá test triền miên thường là dấu hiệu cho thấy team chưa có một định nghĩa hành vi rõ ràng, độc lập với code — và agent thì không thể tự phân biệt đâu là thay đổi sản phẩm có chủ đích, đâu là hồi quy thật sự.
Một vài đội ngũ khác trong ngành cũng quan sát thấy hiện tượng tương tự từ góc nhìn riêng của họ: khi cùng một agent vừa viết code vừa viết test cho chính code đó, cả hai output chia sẻ chung một điểm mù — nếu agent hiểu sai yêu cầu ngay từ đầu, test sinh ra sau đó chỉ xác nhận lại cái hiểu sai ấy, chứ không phát hiện ra nó. Đây cũng là lý do một số nhóm chọn dùng một agent kiểm chứng hoàn toàn tách biệt — với ngữ cảnh, prompt và mục tiêu khác với agent viết code — thay vì để agent "tự chấm bài" cho chính mình.
Vậy giải pháp là quay lại viết test case thủ công?
Không hẳn theo nghĩa "con người ngồi click tay từng bước mỗi lần release" — đó là hiểu lầm phổ biến. Cái đang được nói tới là test case được diễn đạt tách rời khỏi code automation: viết bằng ngôn ngữ tự nhiên, Markdown, Gherkin, hay bất kỳ định dạng nào mà người làm product, engineer, và QA đều đọc và duyệt được — mà AI agent cũng đọc được.
Một test case "thủ công" tốt thường trả lời rõ: tình huống nghiệp vụ là gì, điều kiện đầu vào ra sao, người dùng làm gì, kết quả mong đợi là gì, các trường hợp biên/tiêu cực nào cần lưu ý, và nó đang xác minh cho yêu cầu/tiêu chí nghiệm thu nào.
Vì viết ở dạng dễ đọc, nó trở thành một thứ giống "hợp đồng chung" giữa mọi bên liên quan — kể cả AI. Nó có thể được rà soát trước khi code được viết, được chốt cùng stakeholder, được lưu version như bất kỳ tài liệu bàn giao nào khác. Và quan trọng hơn: sửa một đoạn Markdown mô tả hành vi rẻ hơn rất nhiều so với việc ngồi debug một test E2E phức tạp mỗi lần có thay đổi.
Một cách chia vai hợp lý hơn cho quy trình có AI agent
Cách làm đáng cân nhắc là tách rõ ba việc: ai định nghĩa hành vi mong muốn, ai hiện thực hoá nó, và ai kiểm chứng nó — thay vì để một agent làm cả ba trong cùng một vòng lặp kín.
Trong mô hình này, requirement/tiêu chí nghiệm thu trả lời câu hỏi "vì sao tính năng này cần tồn tại". Test case thủ công — do QA hoặc một agent chuyên trách soạn — biến yêu cầu đó thành kịch bản cụ thể, có thể rà soát được. Agent phát triển thì hiện thực hoá hành vi, và có thể đề xuất chỉnh sửa test case nếu phát hiện điều gì đó chưa rõ ràng — nhưng không được tự ý định nghĩa lại kỳ vọng. Một agent automation riêng biệt sẽ sinh test E2E từ test case đã được duyệt, chứ không phải từ giao diện hay code hiện tại. Và nếu có ai đó (kể cả agent) muốn sửa test case, một lớp rà soát riêng sẽ kiểm tra: thay đổi này có được một yêu cầu đã duyệt cho phép không, hay đây thực chất là một cách "lách" để hợp thức hoá một lỗi hồi quy.
Nghe có vẻ rườm rà, nhưng mục tiêu chỉ đơn giản là: không để một agent vừa viết sai, vừa tự sửa bài kiểm tra cho đúng với cái sai đó, rồi tự cho mình điểm 10.
Vì sao chuyện này quan trọng hơn bạn nghĩ
Tốc độ sinh code của AI agent là có thật và rất hấp dẫn. Nhưng tốc độ không đồng nghĩa với việc hành vi hệ thống đã được xác minh đúng. Nếu không có một lớp mô tả hành vi độc lập với code, các đội ngũ rất dễ rơi vào vòng lặp "implement – fail – fix – hồi quy" — nơi càng dùng AI nhiều, thời gian lại càng đổ vào việc chỉnh test cho khớp code, thay vì bảo vệ đúng những gì sản phẩm cần giữ vững.
Ngược lại, một tập test case thủ công được quản lý tốt — có duyệt, có version, gắn với requirement rõ ràng — giúp giảm hẳn công sức vá E2E lặp đi lặp lại, giảm rủi ro âm thầm chấp nhận hồi quy, và giảm tình trạng nhiều agent tạo ra các test trùng lặp, chồng chéo. Nó cũng là thứ giúp một CTO nhìn ra ngay yêu cầu nào đang thực sự được bảo vệ, và một QA engineer nhìn ra ngay chỗ nào đang thiếu coverage cho trường hợp biên.
Nói cách khác: trong thời đại agentic, test case thủ công không phải bước lùi so với automation. Nó là bản hợp đồng giữ cho automation không "tự diễn giải lại luật chơi" theo ý mình.
Nguồn tham khảo:
- Manual Test Cases in the Agentic Era: The Baseline AI Agents Need — testomat.io, Michael Bodnarchuk.
- Why AI Coding Agents Need a Dedicated AI Testing Agent — Autonoma.
- How I Validate Quality When AI Agents Write My Code — DEV Community.
- Why Coding Agents Need Independent Quality Gates to Work at Scale — Codacy.