Trong hai năm qua, gần như mọi trợ lý lập trình bằng AI đều giới thiệu một tính năng quen thuộc: Plan Mode. Người dùng mô tả yêu cầu, AI phân tích mã nguồn, tạo kế hoạch triển khai, chờ con người phê duyệt rồi mới bắt đầu chỉnh sửa code.
Cách tiếp cận này từng được xem là tiêu chuẩn an toàn khi làm việc với AI coding agent. Nó tạo ra một “điểm kiểm soát” giữa suy nghĩ và hành động, giúp lập trình viên hiểu AI dự định làm gì trước khi hàng loạt tệp tin bị thay đổi.
Tuy nhiên, một bài viết có tiêu đề “Plan mode is dead” của Ayman Nadeem đã đặt lại toàn bộ giả định đó. Điểm đáng chú ý là tác giả không chỉ quan sát Plan Mode từ bên ngoài. Cô từng xây dựng và ra mắt Nuanced, một ứng dụng lập trình trên máy tính với tính năng lập kế hoạch làm trung tâm.
Sau khi chứng kiến sản phẩm không đạt được kỳ vọng, Nadeem đã viết một bản phân tích thẳng thắn về lý do mô hình “lập kế hoạch trước, thực thi sau” không còn phù hợp với cách các AI coding agent hiện đại hoạt động.
Bài học lớn không phải là con người không cần lập kế hoạch. Ngược lại, việc hiểu vấn đề và đưa ra quyết định vẫn quan trọng hơn bao giờ hết. Điều đang thay đổi là hình thức của kế hoạch, cũng như vị trí của nó trong quy trình phát triển phần mềm.
Mục lục
Plan Mode từng giải quyết hai vấn đề khác nhau
Theo phân tích của Nadeem, Plan Mode thực chất được dùng để xử lý hai nhu cầu riêng biệt nhưng thường bị gộp làm một.
1. Hướng dẫn AI đủ chi tiết để tạo ra code đúng
Trong giai đoạn đầu của các công cụ lập trình bằng AI, mô hình thường cần rất nhiều chỉ dẫn cụ thể. Người dùng phải nói rõ:
- Kiến trúc cần sử dụng.
- Tệp tin nào cần chỉnh sửa.
- Luồng dữ liệu sẽ đi qua đâu.
- Các trường hợp ngoại lệ cần xử lý.
- Cách kiểm thử kết quả.
Nếu thiếu thông tin, mô hình dễ tự đưa ra giả định. Những giả định đó sau đó được chuyển thành code, tạo ra lỗi kiến trúc hoặc khiến việc sửa chữa trở nên tốn kém.
Trong bối cảnh đó, một bản kế hoạch chi tiết đóng vai trò như hợp đồng giữa người dùng và AI. Nó biến yêu cầu mơ hồ thành một chuỗi chỉ dẫn có cấu trúc, giúp mô hình giảm số lượng quyết định phải tự phỏng đoán.
2. Giúp con người hiểu rõ mình sắp xây dựng gì
Lập kế hoạch không chỉ phục vụ AI. Nó còn buộc lập trình viên phải dừng lại và suy nghĩ trước khi triển khai.
Khi đọc lại kế hoạch, con người có thể phát hiện:
- Yêu cầu chưa rõ ràng.
- Giả định sai về hệ thống hiện tại.
- Rủi ro bảo mật hoặc hiệu năng.
- Phạm vi công việc quá lớn.
- Sự mâu thuẫn giữa các yêu cầu kinh doanh.
Nói cách khác, Plan Mode vừa là công cụ hướng dẫn AI, vừa là công cụ giúp con người hình thành mô hình tư duy về sản phẩm và hệ thống.
Vấn đề là hai chức năng này không còn có cùng mức độ cần thiết. Khi các mô hình ngôn ngữ ngày càng giỏi đọc repository, truy tìm quan hệ giữa các module và tự kiểm tra kết quả, nhu cầu viết ra một bản chỉ dẫn chi tiết cho từng bước đang giảm xuống.
Trong khi đó, nhu cầu giúp con người hiểu AI đang làm gì vẫn tồn tại, thậm chí còn trở nên cấp thiết hơn.
Vì sao quy trình lập kế hoạch trước có thể thất bại?
Thất bại của một sản phẩm tập trung vào việc lập kế hoạch cho thấy nhiều vấn đề có tính hệ thống. Những vấn đề này không chỉ liên quan đến một ứng dụng cụ thể mà còn phản ánh sự thay đổi nhanh chóng của AI coding agent.
Đánh đồng quá trình suy nghĩ với tài liệu kế hoạch
Đây có lẽ là sai lầm quan trọng nhất: cho rằng giá trị của việc suy nghĩ nằm trong bản kế hoạch được tạo ra sau đó.
Trên thực tế, phần hữu ích nhất có thể là quá trình trao đổi, đặt câu hỏi, loại bỏ giả định sai và thu hẹp phạm vi vấn đề. Một tài liệu dài chỉ là kết quả phụ của quá trình đó.
Nhiều người dùng muốn AI giúp họ suy nghĩ, nhưng không nhất thiết muốn đọc một tài liệu hàng nghìn từ mô tả mọi chi tiết kỹ thuật. Họ cần biết:
- Vấn đề cốt lõi là gì?
- AI đang đưa ra giả định nào?
- Quyết định nào có rủi ro cao?
- Điều gì cần con người xác nhận?
- Kết quả có thể được kiểm chứng bằng cách nào?
Điều này khác hoàn toàn với việc phải đọc một bản đặc tả dài trước khi bắt đầu viết code.
Một kế hoạch có thể rất chính xác nhưng vẫn không hữu ích nếu người dùng không muốn đọc nó. Sản phẩm tốt không nhất thiết phải tạo ra tài liệu lớn nhất; sản phẩm tốt phải làm cho quyết định quan trọng trở nên dễ nhìn thấy nhất.
Khả năng của mô hình đã thay đổi nhanh chóng
Trong giai đoạn trước, một công cụ lập kế hoạch có thể tạo lợi thế đáng kể vì mô hình còn hạn chế trong việc hiểu toàn bộ codebase. Người dùng phải cung cấp cấu trúc, bối cảnh và các mối liên hệ quan trọng.
Hiện nay, nhiều AI coding agent có thể:
- Đọc hàng loạt tệp tin trong repository.
- Tìm kiếm định nghĩa và nơi sử dụng của một hàm.
- Phân tích quan hệ giữa các module.
- Kiểm tra cấu hình build và dependency.
- Chạy test hoặc linter.
- Phát hiện lỗi sau khi triển khai thay đổi.
- Tự điều chỉnh cách tiếp cận dựa trên kết quả thực tế.
Khả năng này làm thay đổi giá trị của một giao diện lập kế hoạch riêng biệt. Nếu AI có thể tự khám phá hệ thống và đưa ra kế hoạch phù hợp ngay trong lúc làm việc, việc bắt người dùng tạo một tài liệu kế hoạch hoàn chỉnh trước đó có thể tạo thêm ma sát thay vì nâng cao chất lượng.
Đây là một dạng cạnh tranh đặc biệt: năng lực của mô hình có thể làm giảm giá trị của lớp giao diện được xây dựng bên trên nó.
Tài liệu do AI tạo ra thường dài nhưng khó đọc
AI rất giỏi tạo ra văn bản có cấu trúc. Nó có thể viết mục tiêu, phạm vi, các bước thực hiện, rủi ro, giả định và kế hoạch kiểm thử chỉ trong vài giây.
Tuy nhiên, “đầy đủ” không đồng nghĩa với “dễ hiểu”. Tài liệu do AI tạo ra thường có những đặc điểm sau:
- Lặp lại cùng một ý bằng nhiều cách.
- Chia nhỏ quá mức thành nhiều mục.
- Giải thích mọi khả năng dù không phải khả năng nào cũng quan trọng.
- Thiếu thứ tự ưu tiên giữa các quyết định.
- Dùng ngôn ngữ chính xác nhưng thiếu trọng tâm.
- Khiến người đọc khó nhận ra rủi ro thực sự.
Điều này tạo ra một nghịch lý. Để giúp tài liệu dễ đọc hơn, sản phẩm phải bổ sung bản tóm tắt, chế độ trình bày từng phần hoặc tính năng hướng dẫn người dùng đi qua các điểm quan trọng. Nhưng nếu người dùng chỉ cần bản tóm tắt, giá trị của tài liệu chi tiết ban đầu là gì?
Vấn đề không nằm ở việc AI không thể viết kế hoạch. Vấn đề nằm ở chỗ con người không muốn tiêu thụ quá nhiều nội dung AI nếu phần lớn nội dung đó không dẫn đến một quyết định cụ thể.
Quy trình waterfall không phù hợp với công việc khám phá
Quy trình Plan Mode truyền thống thường có dạng:
- Trao đổi với AI.
- Làm rõ yêu cầu.
- Tạo bản kế hoạch.
- Đọc và phê duyệt kế hoạch.
- Cho phép AI triển khai.
- Đọc code và đánh giá kết quả.
Quy trình này có vẻ an toàn, nhưng nó giả định rằng con người có thể hiểu đầy đủ vấn đề trước khi bắt đầu xây dựng.
Trong thực tế, phần lớn công việc phát triển phần mềm có tính khám phá. Chúng ta thường chỉ phát hiện vấn đề sau khi:
- Chạy thử một phần chức năng.
- Đọc dữ liệu thực tế.
- Kiểm tra hành vi của hệ thống cũ.
- Đối chiếu với phản hồi từ người dùng.
- Thấy một test thất bại.
- Nhận ra một giả định ban đầu là sai.
Vì vậy, quá trình thực tế thường giống một vòng lặp hơn là một đường thẳng:
Hiểu vấn đề
↓
Thực hiện một phần nhỏ
↓
Kiểm tra kết quả
↓
Phát hiện thông tin mới
↓
Điều chỉnh quyết định
↓
Tiếp tục triển khaiNếu hệ thống buộc người dùng phải hoàn tất toàn bộ suy nghĩ trước khi bắt đầu code, nó có thể biến những giả định chưa được kiểm chứng thành một kế hoạch “chính thức”. Khi đó, việc thay đổi hướng đi sau này dễ bị xem là quay lại hoặc thất bại, dù trên thực tế đó là một phần bình thường của quá trình kỹ thuật.
Plan Mode không hẳn vô dụng, nhưng không nên là cánh cổng bắt buộc
Kết luận “Plan Mode đã chết” cần được hiểu chính xác hơn. Điều đang lỗi thời có thể không phải là hoạt động lập kế hoạch, mà là mô hình xem kế hoạch như một cánh cổng bắt buộc trước mọi hành động.
Không phải tác vụ nào cũng cần cùng một mức độ kiểm soát. Một thay đổi nhỏ như đổi tên biến hoặc sửa lỗi hiển thị không nên trải qua quy trình phê duyệt phức tạp giống như một cuộc di chuyển cơ sở dữ liệu.
Một hệ thống linh hoạt nên cho phép AI tự chọn mức độ lập kế hoạch dựa trên:
- Phạm vi thay đổi.
- Mức độ rủi ro.
- Khả năng kiểm thử.
- Số lượng tệp tin bị ảnh hưởng.
- Độ nhạy cảm của dữ liệu.
- Khả năng hoàn tác thay đổi.
- Mức độ chắc chắn của yêu cầu.
Thay vì một công tắc “Plan Mode bật hoặc tắt”, công cụ có thể tự động tăng mức độ giải thích khi phát hiện tác vụ phức tạp hoặc nguy hiểm.
Quy trình mới: hiểu, hành động, kiểm tra và điều chỉnh
Một quy trình phù hợp hơn với AI coding agent hiện đại có thể bao gồm năm bước chính.
1. Hiểu bối cảnh
AI cần đọc yêu cầu, khảo sát repository và xác định các thành phần liên quan. Ở giai đoạn này, điều quan trọng không phải là viết một kế hoạch dài mà là tạo ra nhận định ban đầu có thể kiểm chứng.
Ví dụ, AI có thể trả lời ngắn gọn:
Tôi tìm thấy luồng xác thực người dùng trong:
- src/auth/session.ts
- src/middleware/auth.ts
- src/api/login.ts
Thay đổi này có thể ảnh hưởng đến:
- API đăng nhập
- Middleware bảo vệ route
- Test tích hợp
Tôi sẽ bắt đầu bằng việc bổ sung test cho trường hợp hết hạn session.Cách trình bày này giúp người dùng hiểu hướng đi mà không cần đọc một đặc tả dài.
2. Thực hiện một phần nhỏ
Thay vì yêu cầu AI lập kế hoạch cho toàn bộ tính năng, hãy để nó triển khai một lát cắt có thể kiểm tra được.
Ví dụ, trong một tính năng thanh toán, AI có thể bắt đầu bằng việc:
- Thêm mô hình dữ liệu.
- Viết test cho một trạng thái đơn giản.
- Triển khai một endpoint nội bộ.
- Mô phỏng phản hồi từ cổng thanh toán.
Cách tiếp cận này giúp phát hiện sai lầm sớm, trước khi chúng lan rộng sang nhiều lớp của hệ thống.
3. Kiểm tra kết quả
AI agent cần được phép chạy các công cụ xác minh như test tự động, linter, type checker hoặc build pipeline.
Ví dụ:
npm test
npm run lint
npm run typecheck
npm run buildĐiểm quan trọng là việc kiểm tra không nên chỉ diễn ra sau khi toàn bộ kế hoạch hoàn tất. Nó cần được thực hiện ngay sau từng thay đổi có ý nghĩa.
4. Chỉ hỏi con người khi xuất hiện quyết định thực sự
AI không cần hỏi người dùng về mọi dòng code. Nó nên tự xử lý các quyết định có thể suy ra từ repository và chỉ yêu cầu con người can thiệp khi có sự mơ hồ hoặc rủi ro đáng kể.
Ví dụ, AI có thể hỏi:
- Nên giữ dữ liệu cũ hay xóa trong quá trình migration?
- Khi thanh toán thất bại, hệ thống có nên tự động thử lại không?
- Thay đổi này có được phép phá vỡ API hiện tại không?
- Thông tin cá nhân nào cần được ẩn trong log?
Đây là những câu hỏi liên quan đến sản phẩm, chính sách hoặc rủi ro. Chúng không thể được giải quyết chỉ bằng cách đọc code.
5. Điều chỉnh và tiếp tục hành động
Sau mỗi vòng kiểm tra, AI và con người có thể cập nhật hướng đi. Một quyết định mới không nên bị xem là phá vỡ kế hoạch cũ; nó là kết quả của thông tin mới được phát hiện trong quá trình triển khai.
Đây là sự khác biệt giữa quy trình tuyến tính và quy trình thích ứng.
Vấn đề lớn hơn: con người sẽ theo dõi AI bằng cách nào?
Nếu kế hoạch dài không còn là công cụ trung tâm, một câu hỏi khó hơn xuất hiện: làm thế nào để con người vẫn giữ được hiểu biết về hệ thống?
Đây là vấn đề đặc biệt nghiêm trọng khi một lập trình viên sử dụng nhiều AI agent song song. Với một agent, người dùng có thể đọc toàn bộ cuộc hội thoại và kiểm tra diff. Nhưng khi có năm, mười hoặc hàng trăm agent hoạt động cùng lúc, cách làm này không còn khả thi.
Khối lượng thay đổi không chỉ tăng theo số lượng agent. Nó còn tăng theo số lượng quyết định, giả định và mối liên hệ giữa các thay đổi.
Trong bối cảnh đó, nhiệm vụ chính của công cụ phát triển không còn là hiển thị tất cả mọi thứ. Nó phải giúp phân bổ sự chú ý của con người vào đúng nơi.
Hệ thống hỗ trợ lập trình viên cần trả lời các câu hỏi nào?
- Thay đổi nào có rủi ro cao nhất?
- Agent nào đang làm việc dựa trên giả định chưa được xác nhận?
- Diff nào ảnh hưởng đến dữ liệu hoặc bảo mật?
- Thay đổi nào không có test đủ mạnh?
- Agent nào đang đi lệch khỏi mục tiêu ban đầu?
- Những quyết định nào cần con người phê duyệt ngay?
- Có xung đột nào giữa các agent hoặc các nhánh code không?
Đây là bước chuyển từ “đọc toàn bộ kế hoạch” sang “hiểu các điểm cần chú ý”. Công cụ tương lai có thể không cần tạo ra một tài liệu dài, nhưng phải cung cấp đủ ngữ cảnh để con người đưa ra quyết định đúng.
Code review trong thời đại AI không còn chỉ là đọc diff
Trước đây, code review thường được hiểu là đọc thay đổi, kiểm tra logic và đánh giá chất lượng triển khai. Với AI agent, vai trò của review đang mở rộng.
Người reviewer cần quan tâm đến cả:
- AI đã hiểu yêu cầu ban đầu như thế nào.
- Những giả định nào đã được sử dụng.
- Những phần nào chưa được kiểm thử.
- Vì sao agent chọn cách triển khai này.
- Thay đổi nào là cần thiết và thay đổi nào chỉ là phụ.
- Kết quả hiện tại có phù hợp với kiến trúc dài hạn không.
Một diff 400 dòng do một agent tạo ra có thể vẫn còn trong khả năng kiểm soát. Nhưng nếu sáu agent cùng tạo ra sáu diff riêng biệt, thách thức không còn là đọc từng dòng code. Thách thức là quyết định diff nào đáng được xem xét trước.
Do đó, công cụ AI coding trong tương lai cần phát triển khả năng:
- Tóm tắt tác động của thay đổi.
- Chỉ ra vùng mã nguồn có rủi ro.
- Liên kết thay đổi với yêu cầu ban đầu.
- Đánh dấu các giả định chưa được kiểm chứng.
- So sánh kết quả với kiến trúc hiện có.
- Đề xuất thứ tự review dựa trên mức độ ảnh hưởng.
Khi nào vẫn nên viết một kế hoạch rõ ràng?
Việc giảm phụ thuộc vào Plan Mode không có nghĩa là mọi kế hoạch đều thừa. Có nhiều trường hợp một tài liệu bền vững vẫn mang lại giá trị cao.
Thay đổi có phạm vi ảnh hưởng lớn
Những thay đổi liên quan đến cơ sở dữ liệu, quyền truy cập, hệ thống thanh toán hoặc dữ liệu cá nhân cần được lên kế hoạch cẩn thận.
Ví dụ, migration cơ sở dữ liệu có thể cần ghi rõ:
- Cấu trúc hiện tại và cấu trúc mới.
- Chiến lược tương thích ngược.
- Quy trình rollback.
- Ảnh hưởng đến dữ liệu đang tồn tại.
- Thời gian khóa bảng hoặc gián đoạn dịch vụ.
- Kế hoạch giám sát sau triển khai.
Kết quả khó hoặc không thể tự động kiểm chứng
Nếu AI không thể chạy test đáng tin cậy và con người cũng khó đánh giá kết quả bằng quan sát trực tiếp, bước phê duyệt trước khi thực thi vẫn rất cần thiết.
Ví dụ có thể bao gồm:
- Thay đổi chính sách bảo mật.
- Điều chỉnh thuật toán tài chính.
- Thiết kế lại quy trình vận hành.
- Thay đổi hành vi pháp lý hoặc tuân thủ.
- Các tính năng ảnh hưởng đến trải nghiệm người dùng nhưng khó đo lường ngay.
Yêu cầu có nhiều bên liên quan
Khi sản phẩm, kỹ thuật, pháp chế, vận hành và khách hàng có những ưu tiên khác nhau, tài liệu là nơi ghi lại các quyết định chung.
Trong trường hợp này, kế hoạch không chỉ dành cho AI. Nó giúp con người thống nhất về:
- Phạm vi công việc.
- Tiêu chí thành công.
- Trách nhiệm của từng bên.
- Rủi ro được chấp nhận.
- Những điều không nằm trong phạm vi triển khai.
Công việc kéo dài nhiều ngày hoặc nhiều tuần
Cuộc trò chuyện với AI thường có tính tạm thời. Khi công việc kéo dài qua nhiều phiên, nhóm cần một nguồn thông tin bền vững để ghi lại quyết định, trạng thái và các vấn đề còn tồn đọng.
Trong trường hợp này, tài liệu không nhất thiết phải là một bản kế hoạch khổng lồ. Nó có thể là một bản ghi ngắn bao gồm:
# Trạng thái triển khai
## Đã hoàn thành
- Tạo bảng orders
- Thêm API tạo đơn hàng
- Viết test cho trạng thái pending
## Đang thực hiện
- Xử lý webhook từ cổng thanh toán
## Quyết định cần xác nhận
- Có tự động hoàn tiền khi webhook thất bại hay không?
## Rủi ro
- API cũ chưa hỗ trợ idempotencyĐây là dạng tài liệu thực tế hơn nhiều so với việc tạo một đặc tả hoàn chỉnh ngay từ đầu.
Cách sử dụng AI coding agent hiệu quả hơn mà không phụ thuộc vào Plan Mode
Chia nhiệm vụ thành các lát cắt có thể kiểm tra
Thay vì giao một yêu cầu quá lớn, hãy chia nó thành các phần có đầu ra rõ ràng. Mỗi phần nên có cách kiểm tra độc lập.
Ví dụ, thay vì yêu cầu:
Xây dựng toàn bộ hệ thống đăng ký và thanh toán cho ứng dụng.Có thể chia thành:
- Phân tích cấu trúc người dùng hiện tại.
- Thêm trạng thái subscription vào cơ sở dữ liệu.
- Viết test cho việc thay đổi trạng thái.
- Tạo endpoint đăng ký gói dịch vụ.
- Tích hợp webhook thử nghiệm.
- Bổ sung xử lý idempotency.
- Kiểm tra các trường hợp thanh toán thất bại.
Yêu cầu AI nêu giả định thay vì viết tài liệu dài
Một danh sách giả định ngắn thường có giá trị hơn một bản kế hoạch hàng nghìn từ.
Trước khi triển khai, tôi đang giả định:
1. API hiện tại dùng PostgreSQL.
2. User ID được lưu dưới dạng UUID.
3. Route /account chỉ dành cho người dùng đã đăng nhập.
4. Có thể thêm migration mới nhưng không được thay đổi migration cũ.
Nếu một giả định không đúng, hãy cho tôi biết trước khi tiếp tục.Yêu cầu AI kiểm tra sau mỗi thay đổi quan trọng
Đừng chờ đến cuối quy trình mới chạy test. Hãy yêu cầu agent kiểm tra từng bước:
Sau khi hoàn thành thay đổi:
- Chạy các test liên quan.
- Chạy typecheck.
- Kiểm tra diff.
- Báo cáo các tệp đã thay đổi.
- Nêu rõ phần nào chưa được kiểm chứng.Đặt giới hạn quyền hành động
AI agent nên được trao quyền phù hợp với mức độ rủi ro của công việc. Với các tác vụ nhạy cảm, có thể giới hạn quyền:
- Không tự động chạy migration production.
- Không xóa dữ liệu nếu chưa được xác nhận.
- Không sửa file cấu hình triển khai nếu chưa phê duyệt.
- Không commit hoặc push thay đổi quan trọng nếu chưa review.
- Không truy cập secret không cần thiết.
Đây là nguyên tắc quan trọng trong việc xây dựng quy trình phát triển phần mềm có AI tham gia: tự động hóa nhiều hơn không đồng nghĩa với trao quyền vô hạn.
Những nguồn tham khảo đáng chú ý
Cuộc tranh luận về Plan Mode nằm trong bối cảnh rộng hơn của AI-assisted software engineering, human-in-the-loop và agentic coding. Một số nguồn có thể tham khảo gồm:
- Bài phân tích “Plan mode is dead” của Ayman Nadeem.
- Thảo luận trên Hacker News về bài viết Plan Mode.
- Tài liệu chính thức của Anthropic về Claude Code.
- Tài liệu của OpenAI về Agents.
- Các phân tích của Martin Fowler về việc ứng dụng Generative AI trong phát triển phần mềm.
- DORA State of DevOps Report, cung cấp các nghiên cứu về hiệu suất phát triển, độ tin cậy và tác động của công cụ trong quy trình kỹ thuật.
Các nguồn trên không chứng minh rằng một mô hình quy trình duy nhất phù hợp với mọi đội ngũ. Chúng cho thấy điều quan trọng là phải đánh giá AI coding agent dựa trên chất lượng đầu ra, khả năng kiểm chứng, mức độ kiểm soát rủi ro và hiệu quả hợp tác giữa con người với máy móc.
Kết luận: Kế hoạch không biến mất, nó đang thay đổi vai trò
Plan Mode từng là giải pháp hợp lý cho một vấn đề thực tế: AI chưa đủ khả năng tự hiểu codebase và cần con người mô tả hướng đi thật chi tiết. Khi mô hình ngày càng mạnh hơn, phần giá trị đó đang dần bị thu hẹp.
Điều không biến mất là nhu cầu hiểu vấn đề, phát hiện giả định sai và đưa ra các quyết định quan trọng. Thứ đang thay đổi là cách những hoạt động đó được tích hợp vào quy trình.
Thay vì tách biệt hoàn toàn giữa lập kế hoạch và triển khai, các AI coding agent hiện đại nên hỗ trợ một vòng lặp liên tục:
- Khảo sát hệ thống.
- Nêu các giả định quan trọng.
- Thực hiện một thay đổi nhỏ.
- Chạy kiểm tra.
- Hiển thị rủi ro và tác động.
- Hỏi con người khi có quyết định thực sự cần xác nhận.
- Điều chỉnh và tiếp tục.
Trong mô hình này, một tài liệu kế hoạch dài không còn là trung tâm. Nó chỉ xuất hiện khi quy mô, rủi ro hoặc yêu cầu phối hợp khiến tài liệu đó thực sự cần thiết.
Thách thức lớn nhất của phát triển phần mềm với AI không còn là làm thế nào để AI viết code nhanh hơn. Đó là làm thế nào để con người duy trì được một mô hình tinh thần chính xác về hệ thống trong khi máy móc liên tục thay đổi nó.
Công cụ giải quyết được bài toán phân bổ sự chú ý, làm rõ giả định và hiển thị quyết định có rủi ro sẽ có giá trị lớn hơn một giao diện Plan Mode truyền thống. Tương lai của lập trình với AI có thể không thuộc về những bản kế hoạch hoàn hảo, mà thuộc về các quy trình giúp con người hiểu đúng, hành động nhanh và điều chỉnh kịp thời.
