Quy trình phát triển sản phẩm đang được viết lại hoàn toàn

Các tác nhân lập trình AI đang tiến bộ với tốc độ theo cấp số nhân, và điều này đang phá vỡ hoàn toàn cách chúng ta xây dựng phần mềm. Câu hỏi không còn là "AI có thể viết code hay không" mà là "khi việc tạo mã trở nên rẻ và nhanh, điều gì thực sự quan trọng trong quy trình phát triển sản phẩm?"

Quy trình phát triển sản phẩm truyền thống

Quy trình tuần tự cũ đang lỗi thời

Trong nhiều thập kỷ, phát triển phần mềm tuân theo một chuỗi tuyến tính: Ý tưởng → Sản phẩm → Thiết kế → Kỹ thuật → QA → Vận hành. Với mô hình này, phần lớn thời gian và chi phí tập trung vào giai đoạn triển khai (implementation). Các khâu ở hai đầu (Ý tưởng và QA) chỉ chiếm một phần rất nhỏ so với toàn bộ quy trình.

Chính vì giai đoạn viết code chiếm chi phí lớn nhất, toàn bộ quy trình đã được thiết kế để xoay quanh nó. Nhưng giờ đây, khi các mô hình ngôn ngữ lớn đã đạt đến điểm bùng phát về chi phí/hiệu suất, việc giao các tác vụ kéo dài và không đồng bộ cho các tác nhân đám mây (cloud agents) trở nên khả thi trong môi trường sản xuất thực tế.

Sự hợp nhất của Product, Design và Engineering

Khi việc tạo code trở nên dễ dàng, nhu cầu hiểu câu chuyện đằng sau mã nguồn — thay đổi thực sự đang diễn ra trong codebase — trở nên cấp thiết hơn bao giờ hết. Kho mã nguồn (repository) không còn đủ để kể toàn bộ câu chuyện về giá trị mà nó mang lại.

Một hệ quả thú vị là sự hội tụ mạnh mẽ của các vai trò khác nhau, đặc biệt là Thiết kế (Design), Kỹ thuật (Engineering) và Sản phẩm (Product). Nhiều công ty đã chứng kiến ba bộ phận này nhập làm một, với công việc hàng ngày gần như giống nhau, dù mỗi người có chuyên môn riêng.

Vòng lặp phát triển sản phẩm mới

Vòng lặp mới: Ý định → Triển khai → Kết quả quan sát được

Thay cho quy trình tuần tự cũ, nhiều đội ngũ đang chuyển sang một đơn vị công việc mới, có thể mô tả như một "thay đổi hành vi sản phẩm đã được xác minh", với vòng lặp:

• Ý định (Intent): Mục tiêu kinh doanh và sản phẩm rõ ràng
• Triển khai (Implementation): Các tác nhân AI thực hiện thay đổi code
• Kết quả quan sát được (Observed Result): Bằng chứng runtime, thay đổi luồng sản phẩm, và hiệu ứng trên hành trình người dùng

Kết quả quan sát được mang tính thực nghiệm cao — nó dựa trên những gì thực sự xảy ra trong môi trường chạy thực, không chỉ là những gì nằm trong file code.

Codebase không còn là trung tâm

Trong vòng lặp mới, thứ quan trọng nhất cần lưu giữ không phải là code, mà là tín hiệu runtime — cách phần mềm chạy trên thiết bị, giao diện hiển thị ra sao, hiệu suất của luồng thanh toán với những thay đổi mới, và kiến trúc dịch vụ phân tán phía backend hoạt động thế nào.

Codebase vẫn quan trọng, nhưng nó không còn ghi lại đầy đủ câu chuyện và giá trị của code. Ví dụ: nếu một agent thay đổi luồng thanh toán (checkout), repository có thể cho biết file nào đã thay đổi, nhưng không thể cho biết:

• Bàn phím có che mất nút thanh toán hay không
• Người dùng quay lại có bị dẫn vào đường sai hay không
• Độ trễ có tăng lên không
• Trải nghiệm cuối cùng có còn đúng với ý định ban đầu không

Dữ liệu runtime và hành vi sản phẩm

Tương lai: Bằng chứng hành vi trong mọi thay đổi

Việc lưu trữ và tổng hợp tất cả dữ liệu này trên một nền tảng xuyên suốt tất cả công việc, tạo nên dữ liệu lịch sử, mang lại giá trị to lớn vượt xa mã nguồn. Trong năm tới, nhiều tiêu chuẩn mới sẽ được áp dụng trong phát triển phần mềm:

• Pull requests kèm bằng chứng hành vi như một tiêu chuẩn bắt buộc
• Tín hiệu runtime trở thành ngữ cảnh phát triển hạng nhất (first-class development context)
• Product, Design, Engineering hội tụ ngày càng sâu hơn quanh mục tiêu phát triển hướng kết quả

Sản phẩm phát triển chưa hề "chết" — nó sống động hơn bao giờ hết, chỉ là đang được viết lại từ nền móng. Với người làm công nghệ tại Việt Nam, đây chính là lúc thích nghi với cách làm việc mới, nơi sự kết hợp giữa tư duy sản phẩm, hiểu biết thiết kế và kỹ năng thực chiến với AI sẽ tạo ra lợi thế cạnh tranh lớn nhất.