Định hình lại SDLC & Kinh tế học Agent
Tái cấu trúc 5 pha SDLC khi có AI hỗ trợ, ma trận chấm điểm cơ hội sản phẩm, bài toán kinh tế học Capex vs Opex và chiến lược định tuyến Model.
Định hình lại điểm nghẽn trong quy trình phát triển
AI rút ngắn phần triển khai nhiều hơn là phần đánh giá sản phẩm. Yêu cầu, kiến trúc, ưu tiên và xác minh vẫn bị giới hạn bởi quyết định của con người, dù code có thể được tạo ra rất nhanh.
SDLC Truyền thống và SDLC AI-driven
Vẫn 6 giai đoạn quen thuộc, nhưng điểm nghẽn và tỷ trọng thời gian đã đổi.
Implementation
Giai đoạn dài nhất; code viết tay.
Rút ngắn còn vài phút–vài giờ; agent tự sửa lỗi ngay giữa vòng lặp.
SDLC truyền thống đi qua các phase riêng là yêu cầu, thiết kế, triển khai, kiểm thử, review, triển khai và bảo trì. Trong phiên bản dùng AI, phần triển khai và phản hồi có thể diễn ra liên tục. Một đặc tả có thể tạo prototype trong vài phút, test có thể chạy sau mỗi hành động của agent, còn lỗi có thể quay thẳng vào một lượt triển khai khác.
Hàm ý với PM không chỉ là timeline ngắn hơn mà là cách phân bổ công sức khác đi:
- Yêu cầu phải nêu kết quả, ranh giới và edge case đủ chính xác để agent hành động.
- Kiến trúc vẫn là trade-off của con người vì bao gồm các ràng buộc kinh doanh và hậu quả dài hạn.
- Kiểm thử mở rộng sang đánh giá cả đầu ra cuối cùng lẫn trajectory đã dùng.
- Review chuyển trọng tâm sang giả định, bằng chứng, failure mode và khả năng bảo trì.
- Phản hồi từ production phải cải thiện đặc tả, bối cảnh, tool và trường hợp eval.
Khi phần triển khai rẻ hơn, mục đích thiếu rõ ràng trở nên đắt hơn. Đội ngũ có thể tạo ra sai thứ cần làm nhanh hơn rất nhiều.
Đặc tả từng phase của SDLC có AI hỗ trợ
Các phase không biến mất; loại công việc và bằng chứng của chúng đã thay đổi. Technical PM nên duy trì một contract phát hành đi cùng tính năng từ mục đích tới production.
Hãy theo agent phản hồi qua từng phase. Requirements định nghĩa “chủ đề có liên kết bằng chứng” và cách tính độ bao phủ. Kiến trúc quyết định việc truy xuất có giữ read-only hay không và phân quyền nguồn được enforce ở đâu. Phần triển khai dựng một workflow hằng tuần có giới hạn. Kiểm thử so sánh chủ đề với tập đã gắn nhãn và kiểm tra trajectory bị cấm. Review kiểm tra giả định cùng thay đổi về quyền truy cập; triển khai bắt đầu với một nhóm sản phẩm và công tắc vô hiệu hóa. Bảo trì đưa từ vựng và lỗi mới quan sát được vào taxonomy cùng bộ eval. Bảng dưới đây chỉ tóm tắt vòng đời đó, không phải sáu checklist tách rời.
| Phase | AI thay đổi điều gì | Quyết định và artifact của PM | Bằng chứng lỗi và metric |
|---|---|---|---|
| Requirements và lập kế hoạch | Brief có thể thành user story, edge case, schema và prototype tương tác trong vài phút | Duyệt đặc tả mục đích gồm kết quả cho người dùng, ràng buộc, giả định, non-goal, ví dụ, tiêu chí chấp nhận và câu hỏi còn mở | Prototype trông hữu ích nhưng mã hóa giả định chưa được duyệt; đo độ bao phủ làm rõ và lỗi yêu cầu phát hiện sau triển khai |
| Thiết kế và kiến trúc | Agent có thể scaffold nhất quán theo pattern đã chọn nhưng không thể sở hữu trade-off kinh doanh | Ghi quyết định kiến trúc cho build vs. buy, tính nhất quán vs. tính sẵn sàng, khả năng đảo ngược, ranh giới dữ liệu và owner dài hạn | Module được tạo đúng ở cục bộ nhưng tạo coupling hoặc lock-in; đo ngoại lệ kiến trúc và rework do thiếu quyết định |
| Triển khai | Thay đổi nhiều file và thuật toán thông thường xuất hiện nhanh; công việc của con người chuyển sang định hướng và xác minh | Phân rã thành tác vụ có giới hạn, ghi vùng ảnh hưởng, tool được phép, bất biến và bằng chứng hoàn thành | Diff lớn che dependency bị hallucinate hoặc scope creep; đo tỷ lệ chấp nhận ở lượt đầu, tỷ lệ lỗi thay đổi và thời gian review thay vì số dòng được tạo |
| Kiểm thử và QA | Agent có thể tạo ví dụ, edge case, property-based test và chạy vòng lặp sửa lỗi | Duy trì kế hoạch test và eval bao phủ đầu ra deterministic, chất lượng non-deterministic, trajectory, ca đối kháng và cổng regression | Đầu ra cuối cùng pass dù agent bỏ qua kiểm tra bắt buộc hoặc dùng path bị cấm; đo riêng tỷ lệ tác vụ thành công và mức tuân thủ trajectory |
| Code review và triển khai | AI có thể review lượt đầu, tóm tắt thay đổi, theo dõi sức khỏe và kích hoạt rollback có giới hạn | Định nghĩa gói bằng chứng phát hành gồm tóm tắt thay đổi, giả định, kết quả test/eval, phát hiện bảo mật, tiêu chí rollout/rollback và người phê duyệt | Khối lượng review tăng nhanh hơn năng lực reviewer hoặc tín hiệu sức khỏe sai khiến bản phát hành lỗi tiếp tục; đo lỗi lọt ra ngoài, tải reviewer, độ chính xác rollback và thời gian phát hiện |
| Bảo trì và phát triển | Agent có thể đọc code cũ, migrate framework, cập nhật API deprecated và hiện đại hóa test | Giữ brief bảo trì gồm bất biến, lát cắt migration, cửa sổ tương thích, kế hoạch deprecation và owner dịch vụ chịu trách nhiệm | Hiện đại hóa quá rộng âm thầm đổi hành vi hoặc tăng technical debt; đo tỷ lệ regression, số dependency không còn hỗ trợ, thời gian khôi phục và chi phí bảo trì trên mỗi bản phát hành |
Requirements nên tiếp tục là cuộc đối thoại tạo ra cả đặc tả lẫn bằng chứng nhanh, không phải document hand-off một chiều. Kiến trúc vẫn do con người sở hữu vì trade-off phụ thuộc ràng buộc tổ chức và chiến lược tương lai. Tốc độ triển khai chỉ hữu ích khi năng lực review và xác minh tăng tương ứng.
Kiểm thử phải đánh giá cả đầu ra lẫn trajectory. Eval đầu ra hỏi artifact cuối cùng có hoạt động không. Eval trajectory hỏi agent có chọn tool phù hợp, tuân thủ kiểm tra bắt buộc và đi theo path được phép hay không. Một lượt chạy trôi chảy nhưng bỏ qua bảo mật hoặc xác minh không phải là lượt chạy thành công.
Hãy vận hành chất lượng như một flywheel:
- Đánh giá các tác vụ đại diện theo rubric rõ ràng.
- Nhóm lỗi theo nguyên nhân gốc thay vì vá từng ví dụ.
- Sửa đúng đặc tả, bối cảnh, tool, guardrail hoặc tuyến model chịu trách nhiệm.
- Chạy lại bộ regression rồi so sánh cả chất lượng lẫn chi phí.
- Lấy mẫu traffic production để tìm ca mới và đưa chúng vào bộ eval.
Artifact phát hành là một gói bằng chứng, không chỉ là phần triển khai được tạo ra.