1. Giới thiệu
AI đang thay đổi cách phát triển phần mềm. Các AI coding agent có thể hỗ trợ viết code, sửa lỗi, review pull request và thực hiện nhiều công việc vốn cần sự tham gia trực tiếp của lập trình viên. Nhờ đó, tốc độ phát triển phần mềm tăng lên đáng kể.
Tuy nhiên, tốc độ viết code tăng nhanh cũng tạo ra một thách thức mới: hệ thống kiểm thử và CI/CD có thể không theo kịp tốc độ phát triển của phần mềm.
Trong bài viết “Agentic coding is straining CI. Here’s how we scaled test impact analysis at Anthropic”, Sachin Malhotra chia sẻ cách Anthropic cải tiến hệ thống Test Impact Analysis (TIA) để xử lý khối lượng công việc ngày càng lớn. Thay vì tiếp tục bổ sung các giải pháp tạm thời, nhóm đã thay đổi kiến trúc hệ thống nhằm cải thiện khả năng mở rộng và duy trì độ ổn định.
+1
Bài viết này sẽ phân tích những vấn đề Anthropic gặp phải, cơ chế kỹ thuật được sử dụng và những bài học có thể áp dụng vào công việc kiểm thử phần mềm hằng ngày.
2. Vì sao AI coding agent tạo áp lực lên CI?
Trong quy trình phát triển phần mềm truyền thống, lập trình viên viết code, tạo pull request (PR), sau đó chờ hệ thống CI chạy kiểm thử trước khi hợp nhất thay đổi.
Khi AI coding agent tham gia vào quá trình này, code có thể được tạo ra nhanh hơn, PR được tạo thường xuyên hơn và số lượng test cũng tăng lên. Điều đó khiến hệ thống kiểm thử phải xử lý nhiều công việc hơn trong cùng một khoảng thời gian.
Theo bài viết của Anthropic:
- Lượng code mà các kỹ sư bàn giao mỗi quý tăng khoảng 8 lần so với giai đoạn 2021–2025.
- Claude tạo ra khoảng 80% lượng code được đề cập trong bài viết.
- Số lượng test trong codebase tăng 10 lần.
- Khối lượng CI job tăng 25 lần chỉ trong 6 tháng, trong khi số lượng kỹ sư chỉ tăng ở mức khiêm tốn.
Những con số này cho thấy một vấn đề quan trọng: tăng tốc độ phát triển không đồng nghĩa với tăng tốc độ bàn giao nếu quá trình kiểm thử trở thành nút thắt.
Nếu chạy toàn bộ test suite sau mỗi thay đổi, thời gian chờ có thể kéo dài, chi phí hạ tầng tăng và kết quả CI trở nên khó quản lý hơn. Ngược lại, nếu cắt giảm test không hợp lý, các lỗi hồi quy có thể bị bỏ sót.
Vì vậy, bài toán đặt ra là làm thế nào để chọn đúng test cần chạy cho từng thay đổi, đồng thời đảm bảo việc lựa chọn dựa trên dữ liệu kiểm thử chính xác và được cập nhật kịp thời.
3. Test Impact Analysis là gì?
Test Impact Analysis là phương pháp xác định những test case có khả năng bị ảnh hưởng bởi một thay đổi trong code, từ đó ưu tiên chạy các test phù hợp thay vì luôn chạy toàn bộ test suite.
Anthropic xây dựng một dịch vụ lựa chọn test dựa trên hai yếu tố chính:
- Lịch sử kết quả kiểm thử: những test đã chạy và kết quả tương ứng.
- Mức độ liên quan của package: mối liên hệ giữa thay đổi trong code và các phần của hệ thKiến trúc ban đầu có hai thành phần chính: Listener và Selector
Cơ chế này giúp giảm lượng test chạy không cần thiết và rút ngắn thời gian phản hồi. Tuy nhiên, hiệu quả phụ thuộc vào việc Listener có ghi nhận kết quả đầy đủ và kịp thời hay không.
4. Vấn đề lớn nhất: Listener không xử lý kịp kết quả CI
Khi số lượng CI job tăng nhanh, Listener bắt đầu xử lý kết quả chậm hơn tốc độ dữ liệu được tạo ra.
Theo bài viết, chỉ cần Listener chậm khoảng 20 phút cũng có thể khiến hàng chục nghìn cập nhật kết quả test chưa được phản ánh vào dữ liệu mà Selector sử dụng.
Điều này dẫn đến ba rủi ro chính.
Thứ nhất, dữ liệu lựa chọn test bị lỗi thời. Một thay đổi mới hoặc một test vừa được sửa có thể chưa được phản ánh vào lịch sử mà Selector sử dụng.
Thứ hai, test không ổn định tiếp tục gây cản trở. Nếu một dependency hoặc test thường xuyên bị lỗi không nhất quán, hệ thống có thể tiếp tục lựa chọn các test đó và gây ra những lần chặn PR không cần thiết.
Thứ ba, nhóm phát triển mất thêm thời gian điều tra. Khi dữ liệu cũ không phản ánh đúng trạng thái kiểm thử, kỹ sư có thể phải kiểm tra lại những lỗi đã biết hoặc tìm nguyên nhân cho các kết quả không còn phù hợp.
Cần lưu ý rằng vấn đề này không có nghĩa là CI ngừng chạy test hoặc code chưa được kiểm thử vẫn tự động được đưa lên production. Vấn đề nằm ở việc một số kết quả chưa được Listener ghi nhận kịp thời, khiến Selector có thể đưa ra quyết định dựa trên dữ liệu cũ.
Đây là một bài học quan trọng: một hệ thống kiểm thử không chỉ cần chạy test đúng mà còn phải xử lý và cập nhật kết quả đáng tin cậy.
5. Ba giải pháp ban đầu và lý do chưa hiệu quả lâu dài
Trước khi thiết kế lại hệ thống, Anthropic đã thử ba biện pháp khắc phục. Mỗi biện pháp đều giúp giảm áp lực trong một khoảng thời gian nhưng không giải quyết triệt để vấn đề kiến trúc.
Claude by Anthropic
| Giải pháp | Kết quả |
|---|---|
| Tăng tài nguyên máy chủ | Tăng gấp đôi số CPU core, giúp hệ thống hoạt động tốt hơn trong khoảng 70 ngày |
| Chia tải theo package (sharding) | Phân chia trạng thái của từng package cho worker riêng, nhưng chỉ duy trì hiệu quả khoảng 29 ngày |
| Khởi động lại hằng ngày | Giảm áp lực bộ nhớ tạm thời nhưng hiệu quả chưa đến một ngày |
Các giải pháp này không sai. Tăng tài nguyên, xử lý song song và khởi động lại dịch vụ đều có thể hữu ích trong những trường hợp phù hợp.
Tuy nhiên, khi khối lượng công việc tiếp tục tăng, những cách làm trên chỉ giúp trì hoãn vấn đề. Đặc biệt, việc khởi động lại thường xuyên còn khiến hệ thống tích lũy độ trễ xử lý và làm tăng nguy cơ dữ liệu lịch sử chưa được cập nhật.
Anthropic nhận ra rằng cần thay đổi cách hệ thống vận hành, thay vì tiếp tục bổ sung các bản vá riêng lẻ.
6. Giải pháp cuối cùng: thiết kế lại kiến trúc theo hướng phân tán và stateless
Thay đổi quan trọng nhất là đưa phần lưu trữ và xử lý lịch sử ra khỏi một tiến trình duy nhất.
Anthropic sử dụng một kho dữ liệu trong bộ nhớ (in-memory data store) cùng một nhật ký sự kiện (event journal) để tách việc tiếp nhận kết quả khỏi việc tổng hợp lịch sử test.
Quy trình mới gồm các bước:
- Listener worker tiếp nhận kết quả. Bất kỳ worker phù hợp nào cũng có thể xử lý một kết quả kiểm thử đến từ CI.
- Ghi sự kiện vào journal. Worker ghi kết quả vào kho dữ liệu dùng chung rồi tiếp tục công việc khác, thay vì phải giữ toàn bộ lịch sử trong bộ nhớ của chính nó.
- Consumer tổng hợp lịch sử. Một tiến trình riêng đọc các sự kiện và cập nhật lịch sử theo từng test sau mỗi vài giây.
- Selector truy vấn dữ liệu mới. Khi cần chọn test cho PR mới, Selector có thể truy xuất lịch sử tương ứng nhanh hơn.
- Mở rộng bằng cách tăng số worker. Khi khối lượng CI tăng, hệ thống có thể bổ sung worker để xử lý nhiều kết quả hơn.
Vì sao kiến trúc này tốt hơn?
Điểm quan trọng là Listener không còn phải vừa tiếp nhận kết quả vừa thực hiện toàn bộ việc cập nhật lịch sử trong cùng một tiến trình.
Các worker theo hướng stateless không cần giữ toàn bộ trạng thái lịch sử trong bộ nhớ riêng. Việc tổng hợp dữ liệu được chuyển sang một thành phần độc lập, nhờ đó hệ thống dễ phân phối tải và mở rộng theo chiều ngang hơn.
Theo tác giả, kiến trúc mới tốn chi phí vận hành cao hơn, nhưng dễ mở rộng và theo dõi bộ nhớ hơn so với thiết kế cũ. Dự án thiết kế lại mất khoảng ba tuần cho một kỹ sư; sau khi triển khai và tinh chỉnh, lượng sự kiện kết quả đang chờ xử lý đã ổn định thay vì tiếp tục tăng dần.
7. Những bài học kỹ thuật rút ra từ Anthropic
7.1. Lập kế hoạch cho sự tăng trưởng
Không nên chỉ thiết kế hệ thống dựa trên khối lượng công việc hiện tại. Khi AI agent có thể tạo code và PR nhanh hơn, tải CI có thể tăng mạnh trong thời gian ngắn.
7.2. Theo dõi toàn bộ quy trình xử lý
Tác giả đề xuất các nhóm cân nhắc khả năng hệ thống phải chịu tải gấp 25 lần trong vòng hai quý. Đây là khuyến nghị lập kế hoạch từ kinh nghiệm của Anthropic, không phải dự báo áp dụng cho mọi dự án
Chỉ biết dịch vụ đang hoạt động là chưa đủ. Cần theo dõi số job đầu vào, số kết quả đã xử lý, độ dài hàng đợi, thời gian chờ, mức sử dụng bộ nhớ và tỷ lệ lỗi.
Một chỉ số đặc biệt hữu ích là so sánh số sự kiện được tạo ra với số sự kiện được xử lý. Nếu số lượng đầu vào liên tục lớn hơn đầu ra, hàng đợi sẽ tăng và hệ thống có nguy cơ chậm dần.
7.3. Hạn chế giữ trạng thái trong từng tiến trình
Việc giữ quá nhiều trạng thái trong một tiến trình có thể khiến hệ thống khó mở rộng. Tách lưu trữ và xử lý giúp phân phối tải dễ hơn, đồng thời thuận tiện hơn khi điều tra các vấn đề về bộ nhớ.
7.4. AI hỗ trợ kỹ thuật nhưng không thay thế tư duy kiến trúc
Trong quá trình cải tiến, Claude hỗ trợ tạo code, chia tải và tinh chỉnh hệ thống. Tuy nhiên, kết quả bền vững đến từ việc thay đổi kiến trúc, chứ không chỉ từ việc dùng AI để tạo thêm các bản vá.
8. Bài học cá nhân của tôi với vai trò Software Tester
Sau khi tìm hiểu trường hợp của Anthropic, tôi nhận ra rằng công việc kiểm thử không chỉ dừng lại ở việc viết test case, thực thi test và báo cáo bug. Khi quy mô dự án tăng lên, cách tổ chức và vận hành quy trình kiểm thử cũng cần được cải tiến.
Tôi rút ra ba bài học chính.
Thứ nhất, cần chọn test phù hợp thay vì chỉ tăng số lượng test.
Một bộ regression test lớn không nhất thiết hiệu quả nếu mọi thay đổi đều phải chạy tất cả test trong thời gian dài. Tôi cần hiểu mối quan hệ giữa module, chức năng và các luồng nghiệp vụ để ưu tiên những test có khả năng phát hiện lỗi cao nhất.
Thứ hai, lịch sử test và bug là nguồn dữ liệu có giá trị.
Các lỗi đã từng xảy ra có thể giúp tôi nhận diện khu vực rủi ro, xây dựng regression test tốt hơn và tránh bỏ sót những trường hợp đã gây lỗi trong quá khứ.
Thứ ba, cần nhìn vào hiệu quả của toàn bộ quy trình.
Nếu test chạy lâu, CI trả kết quả chậm hoặc các test không ổn định liên tục cản trở việc xác nhận thay đổi, tôi cần tìm nguyên nhân thực tế thay vì chỉ yêu cầu chạy lại test hoặc tăng tài nguyên.
Những bài học này có thể áp dụng ngay cả khi dự án chưa sử dụng AI coding agent. Bộ test lớn dần, số lượng thay đổi tăng lên và nhu cầu phát hành thường xuyên đều có thể tạo ra những vấn đề tương tự.
9. Tôi có thể áp dụng vào dự án hiện tại như thế nào?
Với công việc Software Tester, tôi sẽ bắt đầu từ những việc thực tế, không cần triển khai ngay một hệ thống phức tạp như Anthropic.
9.1. Cải thiện việc lựa chọn regression test
Tôi có thể phân loại test case theo module, chức năng, mức độ rủi ro và sự phụ thuộc giữa các chức năng.
Ví dụ, nếu module tính giá báo giá (quotation calculation) có thay đổi, tôi sẽ ưu tiên kiểm tra:
- Công thức tính giá và quy tắc làm tròn.
- Kiểm tra dữ liệu đầu vào và trường bắt buộc.
- Luồng tạo đơn hàng có sử dụng dữ liệu báo giá.
- Các module liên quan nhận dữ liệu từ báo giá.
- Những trường hợp đã từng phát sinh bug.
Tôi sẽ chạy các test liên quan trước để có phản hồi sớm, sau đó thực hiện regression test rộng hơn theo mức độ rủi ro và quy định release.
Điều này không có nghĩa là bỏ toàn bộ regression test. Mục tiêu là giảm công việc không cần thiết nhưng vẫn duy trì độ bao phủ kiểm thử phù hợp.
9.2. Sử dụng lịch sử bug để ưu tiên kiểm thử
Tôi có thể duy trì bảng theo dõi bug với các thông tin như module, loại lỗi, mức độ nghiêm trọng, nguyên nhân gốc, test case liên quan và tần suất lỗi lặp lại.
Khi có thay đổi mới, tôi sẽ xem xét lịch sử này để ưu tiên kiểm tra những khu vực từng có vấn đề.
Ví dụ, nếu trước đây hệ thống gặp lỗi Invalid column name DELIVERY_PERIOD, khi có thay đổi liên quan đến dữ liệu giao hàng, tôi sẽ kiểm tra kỹ mapping giữa ứng dụng và database, việc truy vấn dữ liệu, cũng như các luồng nghiệp vụ liên quan.
Đây là cách vận dụng nguyên tắc sử dụng dữ liệu lịch sử để đưa ra quyết định kiểm thử tốt hơn, chứ không phải triển khai nguyên xi thuật toán TIA của Anthropic.
9.3. Theo dõi hiệu quả kiểm thử bằng dashboard
Nếu dự án có CI và automated test, tôi sẽ theo dõi các chỉ số cơ bản sau:
| Chỉ số | Mục đích |
|---|---|
| Tổng số CI job | Theo dõi mức tăng của khối lượng kiểm thử |
| Thời gian chạy test trung bình | Phát hiện test chậm |
| Thời gian chờ trong hàng đợi | Xác định tắc nghẽn khi thực thi |
| Tỷ lệ test thất bại | Nhận diện các vấn đề chất lượng |
| Tỷ lệ flaky test | Phát hiện test không ổn định |
| Độ trễ cập nhật kết quả | Kiểm tra kết quả có được ghi nhận kịp thời hay không |
Tôi có thể bắt đầu bằng báo cáo đơn giản từ CI hoặc Google Sheets, sau đó mới cân nhắc tự động hóa khi có đủ dữ liệu.
9.4. Sử dụng AI hỗ trợ phân tích test
AI có thể hỗ trợ đọc báo cáo kiểm thử, nhóm các lỗi có biểu hiện tương tự, tóm tắt regression test result và đề xuất những test case cần xem xét khi code thay đổi.
Ví dụ, tôi có thể cung cấp mô tả thay đổi, danh sách module bị ảnh hưởng và các test case hiện có, sau đó yêu cầu AI đề xuất những regression test tiềm năng kèm lý do.
Tuy nhiên, tôi vẫn cần đối chiếu với requirement, dependency và mức độ rủi ro. Không nên để AI tự động loại bỏ test khỏi regression suite nếu chưa có cơ chế xác nhận độ bao phủ và độ an toàn.
Cũng cần phân biệt rõ: bài viết của Anthropic mô tả một dịch vụ lựa chọn test dựa trên lịch sử kết quả và mức độ liên quan của package; tác giả không mô tả việc thay thế toàn bộ dịch vụ này bằng một mô hình AI tự do.
10. Kế hoạch triển khai thực tế cho Tester
Tôi sẽ triển khai theo từng giai đoạn để có thể đánh giá hiệu quả trước khi mở rộng.
Giai đoạn 1 — Chuẩn hóa dữ liệu test
Phân loại test case theo module, chức năng, rủi ro và dependency. Ghi nhận thời gian chạy cùng lịch sử lỗi nếu có.
Giai đoạn 2 — Xác định quy tắc lựa chọn test
Liên kết các loại thay đổi với nhóm test cần ưu tiên. Trao đổi với developer khi chưa rõ phạm vi ảnh hưởng.
Giai đoạn 3 — Đo lường kết quả
So sánh thời gian chạy test trước và sau khi áp dụng lựa chọn có mục tiêu. Kiểm tra xem có bỏ sót lỗi hoặc giảm độ bao phủ hay không.
Giai đoạn 4 — Xác nhận độ an toàn
Duy trì full regression tại các mốc phù hợp, đánh giá những trường hợp bỏ sót và chỉ mở rộng khi kết quả chứng minh phương pháp an toàn, hiệu quả.
Đây là kế hoạch đề xuất của tôi dựa trên các nguyên tắc rút ra từ bài viết, không phải quy trình được Anthropic yêu cầu tất cả tester phải áp dụng.
11. Kết luận
Trường hợp của Anthropic cho thấy khi AI tăng tốc độ phát triển phần mềm, hệ thống CI cũng cần thay đổi để theo kịp. Việc tăng CPU, chia tải theo package và khởi động lại dịch vụ chỉ mang lại hiệu quả tạm thời. Giải pháp bền vững hơn là thiết kế lại kiến trúc theo hướng phân tán, giảm trạng thái trong từng tiến trình và tách việc tiếp nhận kết quả khỏi việc tổng hợp lịch sử test.
Đối với tôi, bài học quan trọng nhất là chiến lược kiểm thử tốt phải cân bằng giữa tốc độ, độ bao phủ, độ tin cậy của dữ liệu và khả năng mở rộng.
Trong công việc hằng ngày, tôi có thể bắt đầu từ việc lựa chọn regression test phù hợp, khai thác lịch sử bug và theo dõi hiệu quả kiểm thử. Đây là những bước thực tế để tiết kiệm thời gian mà không đánh đổi chất lượng phần mềm.
Khi AI coding và automation ngày càng phổ biến, vai trò của tester cũng cần mở rộng: không chỉ xác nhận từng chức năng hoạt động đúng mà còn góp phần xây dựng một quy trình kiểm thử hiệu quả, đáng tin cậy và có khả năng phát triển cùng quy mô dự án.
Tài liệu tham khảo
Sachin Malhotra, Agentic coding is straining CI. Here’s how we scaled test impact analysis at Anthropic, Anthropic, ngày 14/09/2026.