Trong phần lớn dự án phần mềm hiện nay, đặc tả yêu cầu, thiết kế kỹ thuật, design memo, user story không còn được đọc đầu tiên bởi con người. Chúng được đọc đầu tiên bởi agent, AI coding assistant lấy đó làm căn cứ để sinh code, sinh test, sinh task breakdown. Con người chuyển xuống vai trò thứ hai, review kết quả sau khi agent đã thực thi, thay vì đọc tài liệu để tự mình hiểu vấn đề trước khi làm.
Đây là một thay đổi cấu trúc, không phải thay đổi bề mặt. Tài liệu truyền thống luôn giả định độc giả là con người, có khả năng suy luận, tự lấp khoảng trống bằng kinh nghiệm khi tài liệu thiếu hoặc mơ hồ. Khi độc giả đầu tiên là một mô hình ngôn ngữ, giả định đó không còn đúng. Đây là lý do SpecOps cần tồn tại như một kỷ luật vận hành, không chỉ là một cách viết spec tốt hơn.
Vấn đề của tài liệu truyền thống
Ba vấn đề lặp lại ở hầu hết tổ chức, không phụ thuộc ngành hay quy mô.
- Checklist tuân thủ thường được ký xác nhận nhưng không được đọc hết. Đây là vấn đề về thực thi, không phải về nội dung checklist.
- Convention document được viết một lần, sau đó không cập nhật. Theo khảo sát ngành, khoảng sáu mươi phần trăm tài liệu kỹ thuật trở nên lỗi thời trong vòng sáu tháng, vì tài liệu và code sống trong hai hệ thống tách biệt, không có cơ chế nào tự động đồng bộ hai bên.
- Code và tài liệu trôi khỏi nhau một cách âm thầm. Một API đổi tên field, một luồng xử lý thêm điều kiện mới, tài liệu vẫn mô tả hành vi cũ. Không có lỗi biên dịch, không có test fail. Hiện tượng này gọi là documentation drift, sự sai lệch chỉ bị phát hiện khi ai đó làm theo tài liệu và nhận kết quả không khớp.
Con người xử lý sự trôi lệch này bằng phán đoán ngầm, không ghi lại ở đâu. Một kỹ sư có kinh nghiệm đọc spec cũ, thấy chỗ không khớp thực tế, sẽ tự điều chỉnh, hỏi lại đồng nghiệp, hoặc tin vào code hơn tài liệu. Cơ chế này không tồn tại khi người đọc đầu tiên là agent.
AI thực thi đúng những gì được viết, không lấp khoảng trống
Agent không có phán đoán ngầm để tự điều chỉnh khi spec sai hoặc thiếu. Nó đọc đúng những gì được viết ra và thực thi ngay, ở tốc độ cao, không nghi ngờ. Một khoảng trống mà con người từng âm thầm vá bằng kinh nghiệm, bây giờ trở thành hành vi sai được sinh ra ngay lập tức, ở quy mô lớn hơn.
Khảo sát của JetBrains đầu năm 2026, thực hiện trên hơn mười một ngàn kỹ sư, cho thấy khoảng chín mươi phần trăm đã dùng AI trong công việc hàng ngày, nhưng chỉ khoảng mười ba phần trăm dùng AI xuyên suốt toàn bộ vòng đời phần mềm. Khoảng cách giữa hai con số này là khoảng trống SpecOps cần lấp vào, từ dùng AI để gõ code nhanh hơn, sang dùng AI như một phần được kiểm soát của cả quy trình.
Ví dụ minh hoạ, một đặc tả viết theo văn xuôi truyền thống.
“The system must handle appointment scheduling in a way that works well with the doctor’s calendar.”
Câu này con người đọc vẫn hiểu được, dựa vào ngữ cảnh nghiệp vụ có sẵn trong đầu. Agent đọc câu này sẽ phải đoán, thế nào là hợp lý, xử lý thế nào khi trùng lịch, phản hồi gì khi bác sĩ không còn slot trống. Viết lại theo dạng có thể kiểm chứng.
SPEC-ID: SCHED-014GIVEN a patient selects an appointment slotWHEN that slot conflicts with the doctor's existing scheduleTHEN the system must reject the booking and return the nearest available slotsAND no other patient's appointment may be automatically rescheduled
Dạng thứ hai không còn chỗ cho suy luận. Agent đọc một điều kiện, sinh một đoạn code, viết một test kiểm chứng đúng điều kiện đó.
SpecOps, ba lớp vận hành
SpecOps gồm ba phần, mỗi phần giải quyết một lỗ hổng cụ thể của mô hình cũ.
- Spec first. Không có task nào được bắt đầu nếu chưa có spec được duyệt. Đây là luật vào cổng, áp dụng cho cả người và agent.
- Spec anchored. Mọi artifact sinh ra, code, test, tài liệu, phải mang một trace ID trỏ ngược về đúng điều khoản trong spec đã sinh ra nó. Đây là cơ chế chạy liên tục, không phải bước làm một lần.
- Spec as source. Spec giữ vị trí duy nhất có thẩm quyền, không artifact hạ nguồn nào được phép qua mặt nó. Phần lớn tài liệu ngành hiện khuyến nghị các đội nhắm tới spec anchored làm mục tiêu vận hành thực tế, và chỉ coi spec as source là tầng cao hơn, áp dụng cho phạm vi hẹp, được kiểm soát chặt, vì nó đòi hỏi kỷ luật regenerate nghiêm ngặt. Chỉ một lần sửa tay downstream không phản ánh ngược lại spec là invariant vỡ ngay.
Ngoài vai trò governance, SpecOps còn phục vụ trực tiếp hai năng lực khác đang định hình cách agent vận hành trong tổ chức. Context engineering là việc chọn lọc và cấu trúc đúng lượng thông tin đưa vào ngữ cảnh của agent để nó ra quyết định chính xác, và input tốt nhất cho việc đó chính là spec đã được viết rõ ràng, không mơ hồ, đúng dạng mà spec anchored và BDD tạo ra. Harness engineering là việc xây dựng khung vận hành xung quanh agent, file constitution, cơ chế trace, cổng kiểm tra, cũng chính là những gì SpecOps vận hành hàng ngày. SpecOps vì vậy không chỉ là kỷ luật viết tài liệu, nó là phần hạ tầng làm nền cho cả context engineering lẫn harness engineering hoạt động đáng tin cậy.
Sơ đồ vận hành.
[ Approved spec ] | v spec-first: blocks any work from starting without a spec[ Story / Task with SPEC-ID ] | v spec-anchored: every artifact carries a trace ID[ Code ] --- [ Test ] --- [ Docs ] | v gate: PR blocked if trace ID is missing or AC is not met[ Merge ] | v spec-as-source: continuous drift check[ Drift Monitor ] --> auto-fix low risk drift, escalate high risk drift to a human
Ví dụ triển khai
Năm thành phần cụ thể để vận hành SpecOps trong một dự án.
1. Constitution file
Đặt ở gốc repo, tương tự AGENTS.md hoặc CLAUDE.md, định nghĩa nguyên tắc bắt buộc cho agent.
markdown
CONSTITUTION.md Mandatory rules Do not modify code without a valid SPEC-ID assigned to the task. Every public function must have a corresponding test, traced to the correct AC in the spec. Do not change the database schema unless the spec explicitly states it. Before reporting completion, the agent must re-run every AC in the spec and report pass or fail for each one.
2. Viết user story theo BDD, kỷ luật của người viết, không phải công cụ
Áp dụng BDD ở đây là một discipline khi viết user story, không phải một artifact hay công cụ riêng. Không tạo file .feature, không cần framework như Cucumber. Cùng một tài liệu user story, phần Acceptance Criteria được viết theo cấu trúc Given, When, Then thay vì văn xuôi tự do, ngay trong chính tài liệu đó.
Kỷ luật nằm ở người viết, thường là BA hoặc PO, không nằm ở định dạng. Ba yêu cầu cụ thể. Trạng thái bắt đầu phải là một màn hình hoặc trạng thái cụ thể, không viết chung chung. Hành động phải là một thao tác quan sát được, không phải một ý định. Kết quả phải là một trạng thái kiểm chứng được, thông báo hiển thị, màn hình điều hướng tới, bản ghi được tạo, không viết mục tiêu trừu tượng. Nếu người viết không giữ kỷ luật này, BDD chỉ còn là định dạng, không mang lại giá trị gì hơn văn xuôi.
Ví dụ, cùng một user story, viết theo flow.
User Story: Book an appointment with a doctor
As a patient, I want to book an appointment with a doctor so that I can be seen at a convenient time.
Acceptance Criteria:
Scenario, successful booking. Given the patient is on Dr. Nguyen Van A’s Available Slots screen, when the patient selects the 9:00 AM slot on 20 Aug 2026 and taps Confirm Booking, then the system shows a “Booking confirmed” message, navigates to the Appointment Detail screen, and the new appointment appears in the patient’s My Appointments list.
Scenario, slot already taken. Given the 9:00 AM slot on 20 Aug 2026 has already been booked by another patient, when the patient selects that same slot and taps Confirm Booking, then the system shows a “Slot already booked” error and displays the doctor’s nearest available slots, and no appointment is created.
Viết đến mức chi tiết này, đặc tả phục vụ được cả hai hướng làm test case. QA có thể chuyển trực tiếp thành các bước test case thủ công, mở màn hình khung giờ của bác sĩ, chọn khung giờ, nhấn xác nhận, kiểm tra thông báo và điều hướng. Hoặc có thể đưa cùng đặc tả đó cho AI để phác thảo một automated test script, theo đúng luồng và đúng kết quả kiểm chứng đã mô tả. Cả hai hướng đều đọc từ cùng một đặc tả, không hướng nào cần diễn giải lại ý định ban đầu, và không hướng nào bắt buộc hơn hướng còn lại.
3. Template spec dạng kiểm chứng được
spec_id: SCHED-014title: Reject double booked appointment slotacceptance_criteria: - id: AC-1 given: patient selects an appointment slot when: slot conflicts with the doctor's existing schedule then: system rejects the booking and returns the nearest available slots - id: AC-2 given: system rejects the booking when: suggesting an alternative slot then: must not automatically reschedule another patient's appointmentowner: BAstatus: approved
Registry này được trích trực tiếp từ acceptance criteria đã viết theo BDD trong user story ở mục trên, mỗi Scenario trở thành một acceptance criterion, giữ nguyên SPEC-ID để cả ba, story, spec registry, test case, cùng trỏ về một điểm.
4. Gate kiểm tra trace ID trước khi merge
Trước khi một PR được phép merge, hệ thống CI đọc commit message hoặc PR description để tìm một SPEC-ID hợp lệ. Nếu không tìm thấy SPEC-ID nào, PR bị từ chối ngay, kèm lý do cụ thể. Nếu có SPEC-ID, hệ thống đối chiếu tiếp với spec registry, nếu ID đó không tồn tại trong registry, PR cũng bị từ chối. Chỉ khi SPEC-ID vừa có mặt vừa hợp lệ trong registry, PR mới đủ điều kiện merge. Toàn bộ bước kiểm tra này chạy tự động ở tầng pipeline, không phụ thuộc vào việc reviewer có nhớ kiểm tra thủ công hay không, đây là chỗ governance thực sự nằm ở một điều kiện chặn cứng, không phải ở một quy trình mô tả trên giấy.
5. Job phát hiện trôi lệch định kỳ
Một job chạy theo lịch, ví dụ mỗi đêm hoặc mỗi khi có merge mới, đọc toàn bộ spec registry và đối chiếu với các annotation trace hiện có trong code. Với mỗi spec, job kiểm tra xem có đoạn code nào trỏ về đúng SPEC-ID đó không, nếu không có, đây là dấu hiệu rủi ro cao, một spec đã được duyệt nhưng chưa có gì hiện thực hoá. Với mỗi acceptance criterion trong spec, job kiểm tra xem đã có test tương ứng chưa, nếu thiếu, đây là dấu hiệu rủi ro trung bình. Kết quả được phân loại theo mức rủi ro, những lệch nhỏ ở mức rủi ro thấp được tự động mở một PR sửa annotation thiếu, còn những lệch ở mức rủi ro trung bình và cao được gắn nhãn và đẩy lên cho người quyết định, hệ thống không tự ý sửa.
Kết quả vận hành
Khi năm thành phần trên chạy đồng bộ, vai trò con người dịch chuyển rõ ràng, từ đọc toàn bộ tài liệu để tìm lỗi, sang chỉ can thiệp vào đúng điểm hệ thống đánh dấu là cần phán đoán của người. Đây cũng là điều kiện để các con số tiết kiệm từ AI trong toàn vòng đời phát triển trở nên đáng tin, không chỉ dừng ở tốc độ gõ code.
Lưu ý triển khai, không phải task nào cũng cần đi qua toàn bộ chuỗi constitution, template, trace ID, gate. Với thay đổi nhỏ, chi phí tuân thủ đầy đủ nghi thức có thể lớn hơn giá trị nhận được. Ngưỡng áp dụng SpecOps đầy đủ nên gắn với mức rủi ro của thay đổi, không áp dụng đồng loạt cho mọi task.
Transforming Leadership 