SDLC AI-Native Bắt Đầu Từ Hạ Tầng Của Bạn

Anthropic vừa công bố một playbook chi tiết về cách tái cấu trúc vòng đời phát triển phần mềm (SDLC) xoay quanh các tác nhân viết mã (coding agents). Luận điểm chính là SDLC truyền thống được thiết kế khi việc viết mã còn chậm, nhưng giờ đây agent đã khiến bước này trở nên nhanh chóng, và điểm nghẽn đã chuyển sang các giai đoạn xung quanh nó.

Playbook đề xuất sáu giai đoạn, mỗi giai đoạn tạo ra một artifact (sản phẩm đầu ra) cho giai đoạn kế tiếp đọc: Planning tạo intent.md, Design chuyển thành spec.md, Build tạo plan.md trước khi sửa code, và Deploy đặt chính sách review trong REVIEW.md. Càng cụ thể bao nhiêu, playbook càng bỏ qua một chi tiết quan trọng: mã của agent sẽ chạy dựa trên cái gì khi nó tự kiểm tra?

Giai đoạn 4: Nơi agent tự kiểm tra công việc của mình

Giai đoạn 4 là vòng phản hồi, nơi agent kiểm tra công việc của chính nó trước khi kỹ sư nhìn thấy. Playbook yêu cầu bạn cung cấp thứ gì đó để agent đối chiếu: test, bản build, hoặc screenshot diff. Nó cũng khuyên chặn agent sửa file test khi đang sửa lỗi, và tích hợp công cụ browser hoặc screenshot qua MCP cho phần UI.

Đi xa hơn hầu hết tổ chức, Anthropic còn đề nghị coi cấu hình của agent như phần mềm: chạy evals trong CI để kiểm tra lại CLAUDE.md, skills, và hooks mỗi khi chúng thay đổi, biến mọi sự cố production thành một eval vĩnh viễn.

Điều kiện tiên quyết để giai đoạn 4 hoạt động là bạn phải có một bộ test và một bản build chạy được bằng một lệnh duy nhất trên máy local.

Điểm dừng của playbook chính là điểm bắt đầu của hạ tầng của bạn. Nó nói agent cần test để chạy, nhưng không nói test đó chạy dựa trên cái gì. Với một dịch vụ giao tiếp với hàng chục dịch vụ khác (database, queue, third-party API...), đó là phần lớn câu hỏi.

Vì sao xác minh là phần khó nhất

Nếu test chạy dựa trên các bản fake của các dịch vụ đó trên máy của agent, thì test pass chỉ chứng tỏ mã hoạt động với bản fake — không đảm bảo nó hoạt động với hệ thống thật trong cluster.

• Developer khi chạy cùng bộ test đó biết được mức độ tin cậy: họ biết fake billing service đã cũ từ năm ngoái, còn thật thì đổi auth header hai tháng trước.
• Họ biết fake search endpoint luôn trả về ba kết quả giống nhau, còn thật thì phân trang.
• Họ biết không có gì trong bộ fake từng giới hạn tốc độ hay timeout.

Agent không biết bất kỳ điều gì trong số đó. Nó thấy test pass và báo cáo hoàn thành. Đây không phải lỗi của playbook, mà là giới hạn của nó: mọi giai đoạn khác đều thao tác trên file trong repository, và Anthropic có thể cụ thể vì Claude Code là của họ. Các dịch vụ, database, queue, message broker của bạn — không ai có thể mô tả chúng thay bạn, nên playbook dừng lại ở việc yêu cầu có một cơ chế kiểm tra.

Agent không bao giờ thấy hệ thống đang chạy

Nhìn vào chuỗi artifact: intent.md, spec.md, plan.md, CLAUDE.md, skills, REVIEW.md — mỗi cái ghi lại điều mà con người quyết định và viết ra. Không cái nào cho phép agent nhìn vào hệ thống đang chạy thực tế trong production hoặc staging: không biết upstream service trả về gì, không biết queue đang chứa gì, không biết schema staging database hiện tại ra sao — thứ có thể đang lệch vài migration so với branch agent đang làm. CLAUDE.md nói cho agent biết tổ chức đã quyết định gì, không phải cái gì đang thực sự chạy.

mirrord làm được gì

mirrord cho phép mã của agent chạy dựa trên các dịch vụ thật trong staging cluster thay vì bản fake trên máy. Mã vẫn chạy local, hoặc trên CI runner hay sandbox, nhưng mọi thứ xung quanh thay đổi: process đọc cùng biến môi trường và secrets với service mà nó đứng chân trong cluster, các cuộc gọi đi ra qua mạng của cluster, và traffic trong cluster có thể được route tới nó.

Công cụ này vốn được xây cho developer, chủ yếu rút ngắn feedback loop bằng cách bỏ chu kỳ deploy-rồi-chờ. Agent hưởng lợi nhiều hơn, vì developer có thể đánh giá độ "cũ" của bộ fake, còn agent thì không. Chạy kiểm tra dựa trên dịch vụ trong cluster nghĩa là không ai phải phán đoán.

Nó cũng hỗ trợ trước bước kiểm tra: cùng kết nối đó cho phép agent thấy API thực sự trả về gì, message trên queue chứa gì, thay vì làm việc từ tài liệu.

Nhiều agent chạy song song trên một cluster

Playbook gợi ý chạy nhiều Claude Code session cùng lúc, mỗi session trong một git worktree riêng, với subagents bên trong. Worktree giữ mã tách biệt, nhưng không cô lập cluster mà các session kiểm tra. Năm agent nhắm vào cùng một staging service sẽ can thiệp lẫn nhau và với kỹ sư đang dùng nó — đó là lúc tổ chức quyết định "agent không hợp staging" và quay lại cấp cho mỗi agent một bản copy riêng (chậm, đắt, nông).

Sơ đồ các giai đoạn SDLC AI-native của Anthropic

mirrord operator giải quyết vấn đề này:

• Traffic được lọc theo header, mỗi session agent chỉ nhận request của riêng mình.
• Queue được chia nhỏ, mỗi session có một phần riêng của topic dùng chung.
• Database được branch để session ghi không làm phiền người khác.

Một staging cluster phục vụ bao nhiêu agent session cũng được.

Bắt đầu từ đâu

Nếu áp dụng playbook, câu hỏi đầu tiên đáng trả lời nhất là câu mà nó không hỏi: mã của agent sẽ chạy dựa trên cái gì khi nó tự kiểm tra?

Với doanh nghiệp Việt Nam đang chuyển sang phát triển có hỗ trợ AI, bài học quan trọng là đừng vội tin vào kết quả test của agent khi test đó chạy trên môi trường giả lập. Đầu tư vào hạ tầng xác minh thực tế — dù dùng mirrord hay giải pháp tương tự — chính là nền móng để SDLC AI-native thực sự mang lại hiệu quả, thay vì chỉ tạo ra thêm một lớp tự động hóa thiếu đáng tin cậy.

mirrord là mã nguồn mở. Operator — thứ xử lý các session đồng thời — nằm trong sản phẩm thương mại. Các đội ngũ tại monday.com, National Australia Bank, và SurveyMonkey dùng mirrord để lặp và phát hành nhanh hơn, tiết kiệm chi phí hạ tầng môi trường dev đáng kể.