Quy trình phát triển phần mềm truyền thống không biến mất — nó bị nén lại, và điều đó đòi hỏi bạn phải học lại vai trò của chính mình trong đó.
Vòng Lặp Truyền Thống Không Biến Mất — Nó Bị Nén Lại
Vòng lặp phát triển phần mềm kinh điển — hiểu yêu cầu, thiết kế giải pháp, viết code, viết test, review, sửa theo feedback, merge — vẫn tồn tại nguyên vẹn về mặt logic khi làm việc với agentic workflow. Điều thay đổi là thời gian giữa các bước bị nén lại gần như bằng không, và nhiều bước trước đây tốn hàng giờ (viết toàn bộ implementation, viết test bao phủ, chạy và debug) giờ có thể diễn ra trong một vòng lặp agent kéo dài vài phút.
Điều nguy hiểm ở đây là: vì các bước diễn ra nhanh và "có vẻ" tự động hoàn chỉnh, nhiều kỹ sư có xu hướng bỏ qua các bước đó về mặt tư duy — tưởng rằng agent đã "làm hộ" luôn cả phần thiết kế và tư duy kiến trúc, trong khi thực ra agent chỉ đang thực thi rất nhanh một kế hoạch mà không ai thực sự nghĩ kỹ từ trước. Kết quả là code chạy được, test pass, nhưng kiến trúc lộn xộn, không nhất quán với phần còn lại của hệ thống — vì không có bước "thiết kế" nào thực sự diễn ra một cách có chủ đích.
Việc nén thời gian không có nghĩa là nén tầm quan trọng. Ngược lại, vì tốc độ thực thi tăng vọt, chất lượng của các bước đầu vào (yêu cầu, đặc tả, ràng buộc kiến trúc) trở nên quan trọng hơn bao giờ hết — sai sót ở đầu vào giờ được nhân bản với tốc độ nhanh hơn nhiều so với khi con người tự tay gõ từng dòng.
Một cách hình dung hữu ích: nếu trước đây quy trình giống một dây chuyền sản xuất với các trạm chậm rãi, thì giờ nó giống một dây chuyền chạy ở tốc độ cao — bất kỳ lỗi thiết kế nào ở đầu vào cũng sẽ tạo ra phế phẩm nhanh hơn nhiều, và bạn cần trạm kiểm soát chất lượng (QA/review) mạnh hơn tương ứng để bắt kịp tốc độ đó.
Mẹo: Mỗi khi thấy mình sắp gõ prompt "hãy implement tính năng X" mà chưa tự trả lời được câu hỏi "thiết kế của X trông như thế nào, nó chạm vào những phần nào của hệ thống" — hãy dừng lại và tự thiết kế trước, dù chỉ 2-3 câu, trước khi giao cho agent.
"Vibe Coding" và Agentic Workflow Có Cấu Trúc
"Vibe coding" là thuật ngữ mô tả cách làm việc mà nhiều người mới tiếp cận agentic tool rơi vào: gõ một prompt mơ hồ, để agent tự làm hết, xem kết quả "có vẻ đúng" (chạy được, giao diện đẹp), rồi chấp nhận mà không thực sự hiểu hay kiểm tra kỹ những gì agent đã thay đổi bên dưới. Đây là cách làm rất hấp dẫn vì tốc độ cảm nhận được cực nhanh — nhưng nó đặt cược hoàn toàn vào việc agent hiểu đúng ý định của bạn ở mọi chi tiết, điều gần như không bao giờ đúng 100% với yêu cầu có độ phức tạp vừa trở lên.
Agentic workflow có cấu trúc (structured agentic workflow) là cách tiếp cận đối lập: bạn vẫn tận dụng tốc độ của agent, nhưng đưa vào các "điểm neo" (checkpoint) có chủ đích:
- Đặc tả trước khi thực thi — mô tả rõ ràng input/output mong đợi, ràng buộc, edge case cần xử lý, trước khi để agent viết code (đây là chủ đề trọng tâm của Module 3 — Spec-Driven Development).
- Review kế hoạch trước khi review code — với task phức tạp, yêu cầu agent trình bày plan trước khi thực thi, để bạn có cơ hội sửa hướng đi sớm, thay vì sửa sau khi đã có hàng trăm dòng diff.
- Review diff có chủ đích, không chỉ nhìn "chạy được" — kiểm tra logic, không chỉ kiểm tra kết quả render hay test pass, vì test cũng có thể được agent viết theo hướng hiểu sai giống hệt code.
- Xác nhận rõ ràng ở các điểm rủi ro cao — migration, thay đổi API public, xóa dữ liệu — luôn có một bước dừng lại chờ con người duyệt.
Sự khác biệt không nằm ở việc "có dùng agent hay không" — cả hai cách làm đều dùng agent. Khác biệt nằm ở việc bạn có chủ động thiết kế các điểm dừng và kiểm soát trong quy trình hay để mọi thứ trôi theo quán tính "trông ổn là được".
Ví dụ đối lập cụ thể — cùng một yêu cầu, hai cách tiếp cận:
Vibe coding:
Làm cho tôi trang checkout có thanh toán qua Stripe.
Structured agentic workflow:
Tôi cần thêm luồng thanh toán Stripe cho trang checkout. Trước khi
code, hãy trình bày kế hoạch gồm: (1) các file/module sẽ bị ảnh
hưởng, (2) cách xử lý lỗi thanh toán thất bại và timeout, (3) cách
đảm bảo không tính tiền hai lần nếu user bấm nút nhiều lần, (4) test
case cần có. Chờ tôi duyệt kế hoạch trước khi bắt đầu implement.
Cả hai prompt đều "dùng AI để code Stripe", nhưng kết quả về chất lượng và khả năng bảo trì sẽ khác nhau rất xa.
Mẹo: Một dấu hiệu nhận biết bạn đang vibe coding: bạn không thể tự giải thích cho đồng nghiệp vì sao đoạn code agent vừa viết lại được cấu trúc theo cách đó. Nếu không giải thích được, đừng merge.
Nơi Con Người Vẫn Phải Là Người Quyết Định
Dù agent giỏi đến đâu, có những loại quyết định mà việc giao hoàn toàn cho agent là sai lầm về nguyên tắc, không chỉ vì công nghệ hiện tại chưa đủ tốt:
- Đánh đổi kiến trúc (architectural trade-off). Chọn giữa consistency và availability, chọn monolith hay microservices, chọn đồng bộ hay bất đồng bộ — đây là quyết định phụ thuộc vào ngữ cảnh kinh doanh, đội ngũ, và tương lai sản phẩm mà agent không có đủ thông tin (và không nên có đủ thẩm quyền) để tự quyết.
- Đánh giá rủi ro kinh doanh. Một agent có thể đề xuất giải pháp kỹ thuật "tối ưu" nhưng không biết rằng feature đó sắp bị loại bỏ theo roadmap quý sau, hay rằng khách hàng lớn nhất của công ty cực kỳ nhạy cảm với một loại lỗi cụ thể.
- Trách nhiệm giải trình (accountability). Khi có sự cố production, người chịu trách nhiệm giải thích và sửa chữa là con người trong tổ chức — không phải agent. Điều này có nghĩa con người phải thực sự hiểu code đã được viết ra, không chỉ "đã duyệt PR".
- Đạo đức và tuân thủ (compliance). Xử lý dữ liệu cá nhân, tuân thủ quy định ngành (tài chính, y tế), các quyết định có tác động đến quyền riêng tư người dùng — cần con người có thẩm quyền và hiểu biết pháp lý xác nhận, agent chỉ hỗ trợ thực thi.
- Đánh giá "đủ tốt chưa" trong bối cảnh sản phẩm thực tế. Agent có thể xác nhận test pass, nhưng chỉ con người mới biết liệu trải nghiệm đó có thực sự phù hợp với người dùng thật, văn hóa công ty, hay tiêu chuẩn thương hiệu.
Ranh giới này không cố định mãi mãi — nó sẽ dịch chuyển khi công nghệ agentic trưởng thành hơn. Nhưng tại thời điểm hiện tại, cách an toàn và hiệu quả nhất là xác định rõ ràng những điểm quyết định nào thuộc về con người trước khi bắt đầu một agentic workflow, chứ không phải phát hiện ra ranh giới đó sau khi mọi thứ đã sai.
Mẹo: Viết ra một danh sách ngắn "những việc tôi sẽ luôn tự quyết định, không giao cho agent" và dán nó vào CLAUDE.md hoặc tài liệu quy trình của team — biến ranh giới ngầm định thành quy tắc tường minh giúp cả team nhất quán.
Từ Người Viết (Author) Đến Người Chỉ Đạo (Director): Chuyển Đổi Mô Hình Tư Duy
Sự thay đổi lớn nhất mà agentic engineering đòi hỏi không phải là học một công cụ mới — mà là chuyển đổi mô hình tư duy về vai trò của chính bạn trong quy trình phát triển phần mềm.
Trong mô hình cũ, bạn là Author (người viết/tác giả): bạn tự tay gõ phần lớn code, tự tay debug từng dòng, và giá trị của bạn được đo phần lớn qua tốc độ và chất lượng gõ code trực tiếp.
Trong mô hình agentic, vai trò chuyển thành Director (người chỉ đạo/đạo diễn): giống một đạo diễn phim không tự cầm máy quay mọi cảnh, nhưng hiểu rõ mình muốn kể câu chuyện gì, chọn đúng người (hoặc agent) cho đúng cảnh quay, và có con mắt tinh tường để nhận ra khi một cảnh quay "không ổn" dù nhìn thoáng qua có vẻ ổn.
Cụ thể, sự chuyển đổi này thể hiện qua:
- Từ "viết đúng" sang "đặc tả đúng". Kỹ năng quan trọng nhất không còn là gõ code không lỗi, mà là mô tả rõ ràng bạn muốn gì, ràng buộc gì, và làm sao biết khi nào nó đúng.
- Từ "debug từng dòng" sang "review có hệ thống". Bạn cần khả năng đọc một diff lớn nhanh và chính xác, nhận ra pattern sai, thay vì chỉ giỏi truy vết một lỗi cụ thể bằng debugger.
- Từ "biết cách làm" sang "biết khi nào nên tin, khi nào nên nghi ngờ". Đạo diễn giỏi biết diễn viên nào đáng tin ở cảnh nào; kỹ sư giỏi trong thời đại agentic biết loại task nào agent thường làm tốt, loại nào cần giám sát chặt.
- Từ cá nhân gõ code sang điều phối hệ thống (bao gồm cả con người và agent). Bạn có thể đang quản lý song song: một agent đang refactor module A, một agent khác đang viết test cho module B, trong khi bạn tự tay xử lý một quyết định kiến trúc phức tạp cho module C.
Điều quan trọng: chuyển sang vai trò Director không có nghĩa là bạn ngừng hiểu code. Ngược lại, để chỉ đạo tốt, bạn cần hiểu code ở mức sâu hơn theo một cách khác — hiểu đủ để nhận ra sai lầm tinh vi trong logic agent viết ra, dù bạn không tự gõ từng dòng đó.
Mẹo: Tự đánh giá bản thân mỗi tuần bằng câu hỏi: "Tuần này tôi dành bao nhiêu % thời gian ở vai trò Author so với Director?" — không có tỷ lệ đúng tuyệt đối, nhưng xu hướng nên nghiêng dần về Director khi bạn thành thạo hơn với agentic workflow.
Thực Hành: Tái Cấu Trúc Một Quy Trình Implement Tính Năng
Bài tập này yêu cầu bạn chọn một tính năng thực tế (đã làm trước đây theo cách truyền thống, hoặc sắp làm) và thiết kế lại toàn bộ quy trình theo hướng structured agentic workflow.
Bước 1 — Chọn một tính năng vừa đủ phức tạp. Không quá đơn giản (sửa một dòng CSS) cũng không quá lớn (một module hoàn toàn mới) — lý tưởng là một tính năng từng mất bạn nửa ngày đến một ngày làm theo cách cũ.
Bước 2 — Viết đặc tả trước khi mở agent. Trước khi gõ bất kỳ prompt nào, viết ra (trên giấy hoặc file riêng): mục tiêu, input/output, edge case, ràng buộc hiệu năng/bảo mật nếu có. Đây chính là bước "thiết kế" bạn không được bỏ qua dù agent chạy nhanh đến đâu.
Bước 3 — Yêu cầu agent trình bày kế hoạch trước. Ví dụ:
Đây là đặc tả tính năng [dán đặc tả từ bước 2]. Trước khi viết bất
kỳ code nào, hãy trình bày: các file sẽ tạo/sửa, các quyết định thiết
kế cần đưa ra (và đề xuất của bạn cho mỗi quyết định), và danh sách
test case dự kiến. Không code cho đến khi tôi xác nhận.
Bước 4 — Review kế hoạch, không phải review code trước. Đọc kỹ plan, sửa hướng đi nếu cần, rồi mới cho phép agent thực thi.
Bước 5 — Review diff có chủ đích. Sau khi agent hoàn thành, tự hỏi: mình có thể giải thích từng phần thay đổi cho đồng nghiệp không? Test có thực sự kiểm tra đúng ý định ban đầu, hay chỉ kiểm tra rằng code chạy không lỗi?
Bước 6 — So sánh với cách làm cũ. Ghi lại: tổng thời gian bỏ ra (bao gồm cả thời gian viết đặc tả), chất lượng kết quả so với làm truyền thống, và điều gì khiến bạn tự tin (hoặc không tự tin) để merge.
Mẹo: Lưu lại đặc tả và kế hoạch từ bài tập này — đây chính là "mẫu" (template) bạn sẽ tinh chỉnh dần và tái sử dụng cho các tính năng tương tự sau này, một kỹ năng sẽ được hệ thống hóa sâu hơn ở Module 3.
Những điểm chính
- Agentic workflow không loại bỏ vòng lặp phát triển phần mềm truyền thống — nó nén thời gian thực thi lại gần bằng không, khiến chất lượng đầu vào (đặc tả, thiết kế) trở nên quan trọng hơn bao giờ hết.
- "Vibe coding" (giao việc mơ hồ, chấp nhận kết quả vì "trông ổn") và structured agentic workflow (đặc tả trước, review kế hoạch, review diff có chủ đích, xác nhận ở điểm rủi ro cao) đều dùng agent — khác biệt nằm ở việc có chủ động thiết kế điểm kiểm soát hay không.
- Một số quyết định — trade-off kiến trúc, rủi ro kinh doanh, trách nhiệm giải trình, tuân thủ pháp lý, đánh giá "đủ tốt" trong bối cảnh thực — luôn cần con người quyết định, không giao hoàn toàn cho agent.
- Vai trò kỹ sư dịch chuyển từ Author (người viết) sang Director (người chỉ đạo): giá trị nằm ở khả năng đặc tả rõ ràng, review có hệ thống, và biết khi nào nên tin/nghi ngờ kết quả của agent — không phải ở tốc độ gõ code thủ công.