Hầu hết các cuộc thảo luận về phát triển phần mềm tự động đều bắt đầu với việc các agent viết code. Một agent nhận một issue, triển khai một tính năng, mở một pull request. Bản demo hoạt động. Mọi người trở nên phấn khích.
Trước khi bất kỳ quy trình phân phối tự động nào có thể hoạt động đáng tin cậy, ai đó phải thiết kế hệ thống kỹ thuật mà quy trình tự động đó sẽ vận hành bên trong. Cấu trúc repository, lựa chọn công nghệ, ranh giới kiến trúc, định hướng thiết kế, quy ước kỹ thuật, cơ chế xác thực, vai trò chuyên môn, ranh giới phê duyệt. Không có điều nào trong số đó nên phát sinh từ một tập hợp các agent độc lập phỏng đoán song song với nhau.
Cách tiếp cận của tôi bắt đầu với một sự phân chia trách nhiệm khác. Con người thiết kế hệ thống kỹ thuật. Các agent chuyên biệt thực hiện công việc. Các vòng lặp bất đồng bộ điều phối khi nào công việc đó diễn ra và bước tiếp theo là gì.
Mục tiêu không phải là loại bỏ con người khỏi quá trình phát triển phần mềm. Mục tiêu là tập trung sự tham gia của con người vào các quyết định đòi hỏi phán đoán, bối cảnh và hiểu biết về sản phẩm, đồng thời xây dựng một môi trường nơi phần lớn quá trình thực thi có thể tự động tiếp diễn.
Đây là sáu bước tôi luôn thực hiện mỗi khi bắt đầu một dự án được thiết kế để cuối cùng có thể vận hành mà không cần tôi theo dõi.
Bước 1: con người thiết kế hệ thống kỹ thuật
Khi tôi bắt đầu một dự án, tôi không yêu cầu một agent tự động phát minh ra nền tảng của nó.
Tôi quyết định những phần quan trọng trước: cách tổ chức repository, sử dụng công nghệ nào, ranh giới kiến trúc chính hoạt động ra sao, định hướng thiết kế là gì, những quy ước kỹ thuật nào phải được tuân theo, và quyền tự động nên dừng lại ở đâu. Những quyết định này trở thành nền tảng cho mọi thứ sau đó.
Sau đó, tôi sử dụng opencode-onboard để mã hóa chúng vào repository.
/make-engineer tạo ra các kỹ sư AI chuyên biệt mà dự án cần. Frontend, backend, infrastructure, testing, security, data, mobile, bất kỳ sản phẩm nào yêu cầu. Đây không phải là các agent chung chung với các nhãn khác nhau. Mỗi agent có một chuyên môn xác định, một bộ kỹ năng và một vị trí rõ ràng trong quy trình kỹ thuật.
/make-architecture ghi lại cấu trúc và ranh giới kỹ thuật trong ARCHITECTURE.md. /make-design ghi lại ngôn ngữ hình ảnh, design tokens và các mẫu component trong DESIGN.md. /make-guardrails chuyển đổi tất cả các quyết định đó thành các quy tắc cụ thể mà mọi agent phải tuân theo. Ranh giới kiến trúc, quy ước đặt tên, kỳ vọng kiểm thử, phong cách code, ràng buộc bảo mật, thực hành Git. Chúng không còn là kiến thức chỉ riêng nhà phát triển ban đầu nắm giữ, mà trở thành một phần của môi trường vận hành.
Repository cuối cùng không chỉ chứa tài liệu. Nó chứa một tổ chức kỹ thuật đã được mã hóa và một nguồn sự thật chung cho mọi agent sẽ làm việc bên trong nó.
Con người xác định hệ thống trước. Chỉ sau đó, việc thực thi tự động mới trở nên hữu ích.
Bước 2: nền tảng tương tác có trước quyền tự động
Khi hệ thống kỹ thuật đã được xác định, tôi xây dựng nền tảng ban đầu của dự án một cách tương tác.
Ở giai đoạn này, tôi thường sử dụng /plan-quick và /plan-apply. /plan-quick phân tích một mục tiêu cụ thể và biến nó thành một chuỗi nhiệm vụ cụ thể, có thứ tự. Nó cố tình nhẹ nhàng hơn một quy trình đặc tả hoàn chỉnh. Tôi sử dụng nó khi công việc đã rõ ràng và tôi muốn tiến nhanh mà không mất đi khả năng quan sát hoặc kiểm soát. /plan-apply thực hiện các nhiệm vụ đó và xác minh kết quả.
Đây là cách tôi thiết lập cơ sở hạ tầng cơ bản của dự án. Cấu trúc repository, khung ứng dụng, thiết lập cơ sở dữ liệu, nền tảng xác thực, hệ thống thiết kế, cơ sở hạ tầng kiểm thử, cấu hình CI/CD, nền tảng triển khai.
Các giai đoạn đầu của dự án chứa đựng những quyết định ảnh hưởng đến mọi thứ được xây dựng sau đó. Một abstraction yếu kém, một cấu trúc thư mục không nhất quán, một chiến lược kiểm thử không rõ ràng. Bất kỳ điều nào trong số đó cũng có thể bị tái tạo hàng trăm lần một khi các agent tự động bắt đầu làm việc. Tôi đã thấy điều đó xảy ra. Nó không đẹp mắt chút nào.
Vì lý do đó, giai đoạn này vẫn diễn ra nhanh chóng và có sự hỗ trợ của AI, nhưng được giám sát.
Mục đích không phải là tối đa hóa quyền tự động càng sớm càng tốt. Mục đích là làm cho dự án trở nên ổn định, dễ hiểu và dễ dự đoán đủ để quyền tự động sau này có thể vận hành an toàn bên trong nó.
Bước 3: sự tham gia của con người trở thành một chính sách của dự án
Sau khi nền tảng đã sẵn sàng, tôi quyết định mức độ tự động mà hệ thống phân phối nên có.
Đây không phải là một lựa chọn nhị phân giữa phát triển thủ công và tự động hóa hoàn toàn. Sự tham gia của con người có thể tồn tại ở các điểm khác nhau trong vòng đời, và cấu hình phù hợp phụ thuộc vào dự án.
Một dự án được giám sát hoàn toàn có thể yêu cầu con người tinh chỉnh issue, phê duyệt kế hoạch triển khai, xem xét pull request, phê duyệt merge và ủy quyền triển khai.
Một dự án bán tự động có thể để AI tinh chỉnh và triển khai, trong khi con người trả lời các câu hỏi chưa được giải đáp, xem xét các pull request quan trọng hoặc giữ quyền kiểm soát merge cuối cùng.
Một dự án có tính tự động cao có thể để hệ thống tự động tinh chỉnh, triển khai, xem xét và merge các thay đổi khi các guardrails, kiểm thử và kiểm tra chất lượng cần thiết đều được thông qua.
Một sản phẩm mới với các yêu cầu không ổn định cần sự tham gia của con người nhiều hơn một công cụ nội bộ đã trưởng thành. Một hệ thống được quản lý yêu cầu các cổng phê duyệt rõ ràng mà một thử nghiệm nhỏ sẽ không cần. Và cùng một dự án có thể trở nên tự động hơn theo thời gian khi kiến trúc, kiểm thử và cơ chế phân phối của nó trưởng thành.
Điểm quan trọng là quyền tự động được xác định một cách có chủ ý. Tinh chỉnh issue, giải quyết câu hỏi, phê duyệt kế hoạch, xem xét pull request, phê duyệt merge, phê duyệt triển khai. Đây không phải là những gián đoạn ngẫu nhiên. Chúng là các cổng có thể cấu hình trong hệ thống kỹ thuật.
Mỗi dự án chọn một mức độ tự động khác nhau, và các ranh giới đó phát triển cùng với dự án.
Bước 4: ý tưởng trở thành các mục backlog bền vững
Bảng điều khiển tương tác vẫn là nơi tôi nghiên cứu các ý tưởng.
Khi một ý tưởng chưa hoàn chỉnh, tôi sử dụng /plan-explore. Đây không phải là một lệnh triển khai. Đó là một quy trình khám phá hợp tác. Agent kiểm tra repository, ánh xạ các component liên quan, xác định các mẫu hiện có, thách thức các giả định, truy vết các phụ thuộc, xem xét rủi ro và giúp xác định những gì thực sự nên được xây dựng.
Nhiều vấn đề phát triển ban đầu trông giống như các nhiệm vụ code nhưng thực chất là vấn đề về hiểu biết. Gửi một ý tưởng không rõ ràng trực tiếp vào quy trình triển khai tự động thường tạo ra một kết quả triển khai không rõ ràng. Khám phá giúp ý tưởng có đủ cấu trúc để trở nên khả thi mà không cam kết sớm với một giải pháp.
Khi hướng đi đã rõ ràng, tôi sử dụng /ops-backlog để tạo một mục công việc có cấu trúc trong GitHub, Azure DevOps hoặc Jira. Mục công việc trở thành cầu nối bền vững giữa tư duy tương tác và thực thi bất đồng bộ. Nó có thể chứa bối cảnh, phạm vi, tiêu chí chấp nhận, rủi ro, câu hỏi chưa được giải đáp và các phụ thuộc cần thiết cho các giai đoạn tiếp theo của quy trình.
Lúc này, backlog không còn chỉ là nơi lưu trữ các nhiệm vụ. Nó trở thành lớp phối hợp chung giữa con người, agent và các vòng lặp.
Con người tạo ra ý tưởng, trả lời câu hỏi và đưa ra quyết định. Các vòng lặp quan sát trạng thái issue và chọn công việc đủ điều kiện. Các agent nhận các nhiệm vụ tập trung với bối cảnh cần thiết để thực hiện chúng.
Backlog biến một cuộc trò chuyện tương tác thành công việc bền vững tiếp tục sau khi cuộc trò chuyện đó kết thúc.
Bước 5: loop-task điều phối công việc bất đồng bộ
Khi dự án, kỹ sư, guardrails, backlog và chính sách phê duyệt đã sẵn sàng, tôi cấu hình loop-task trên một máy local hoặc VM.
loop-task chạy các vòng lặp điều phối bên ngoài. Các vòng lặp này liên tục kiểm tra backlog, xác định công việc đủ điều kiện, gọi quy trình kỹ thuật thích hợp và cập nhật trạng thái của từng issue.
Một vòng lặp tinh chỉnh có thể chọn một issue mới, nghiên cứu nó, cải thiện đặc tả của nó và thêm các câu hỏi khi thiếu thông tin. Khi cần một quyết định của con người, issue chuyển sang trạng thái chờ. Một người sẽ trả lời khi có thể, và vòng lặp tiếp tục khi thông tin xuất hiện.
Khi issue đã đủ rõ ràng, nó chuyển sang trạng thái sẵn sàng để triển khai. Vòng lặp triển khai nhận nó và gọi quy trình kỹ thuật tự động.
Một vòng lặp xem xét có thể kiểm tra phản hồi pull request, điều phối các chỉnh sửa, chạy lại quy trình cần thiết và đưa thay đổi trở lại trạng thái chấp nhận. Một vòng lặp hoàn thành có thể merge công việc đã được chấp nhận, đóng issue liên quan và cho phép mục đủ điều kiện tiếp theo vào hệ thống.
Các vòng lặp không cần giao tiếp trực tiếp với nhau. Chúng phối hợp thông qua các trạng thái backlog bền vững. Một issue điển hình di chuyển qua một vòng đời như sau:
Mới, Đang tinh chỉnh, Chờ câu trả lời, Sẵn sàng triển khai, Đang triển khai, Pull request, Đang xem xét, Hoàn thành.
Con người có thể tham gia vào quy trình bất cứ khi nào chính sách dự án yêu cầu, nhưng hệ thống không phụ thuộc vào việc ai đó liên tục theo dõi một terminal. Ngay cả khi nhà phát triển ngoại tuyến, VM vẫn tiếp tục kiểm tra backlog và chuyển công việc đủ điều kiện về phía trước.
Đây là sự khác biệt trọng tâm của loop engineering:
Các agent thực hiện công việc. Các vòng lặp quyết định khi nào công việc tồn tại, khi nào nó nên bắt đầu, quy trình nào nên thực thi nó và điều gì xảy ra tiếp theo.
Bước 6: /plan-goal thực thi một issue từ đầu đến cuối
Khi vòng lặp triển khai tìm thấy một issue đã sẵn sàng, nó gọi /plan-goal.
Lệnh này không chịu trách nhiệm quyết định hướng đi của sản phẩm hay phát minh ra kiến trúc dự án. Những quyết định đó đã được thực hiện và mã hóa vào repository. Trách nhiệm của nó là thực thi một mục công việc đã được tinh chỉnh đầy đủ trong hệ thống kỹ thuật hiện có.
/plan-goal đọc issue, khám phá các phần liên quan của codebase, tạo một đề xuất OpenSpec, tạo ra các nhiệm vụ có cấu trúc, xác định các khoảng trống về đặc tả hoặc kiểm thử, chọn các kỹ sư chuyên biệt phù hợp, gán các model tier, tính toán các phụ thuộc và tổ chức công việc triển khai thành các đợt thực thi song song.
Các nhiệm vụ độc lập và sửa đổi các khu vực riêng biệt của repository có thể được gán cho các kỹ sư khác nhau đồng thời. Các nhiệm vụ phụ thuộc vào công việc trước đó hoặc chạm vào cùng các tệp được thực thi theo thứ tự yêu cầu.
Agent chính điều phối công việc, thu thập từng kết quả, tạo các commit tập trung, chạy kiểm thử, linting, kiểm tra kiểu và build. Nó dừng lại thay vì gửi thay đổi khi việc xác minh không thể hoàn tất thành công.
Khi quá trình triển khai hợp lệ, nhánh được push và một pull request được tạo với bối cảnh và bằng chứng cần thiết.
Chính sách dự án đã cấu hình sau đó sẽ quyết định điều gì xảy ra tiếp theo. Một người có thể xem xét pull request. Một hệ thống AI khác có thể thực hiện việc xem xét. Một dự án có tính tự động cao có thể tự động merge khi mọi kiểm tra cần thiết đều được thông qua. Trong các dự án khác, quyết định cuối cùng vẫn thuộc về con người một cách rõ ràng.
Điều này cho thấy hai lớp điều phối trong hệ thống. loop-task là lớp điều phối bên ngoài. Nó quản lý vòng đời backlog và quyết định khi nào việc tinh chỉnh, triển khai, xem xét hoặc hoàn thành nên diễn ra. /plan-goal và các lệnh opencode-onboard khác tạo thành quy trình kỹ thuật bên trong. Chúng hiểu cách khám phá, lập kế hoạch, gán nhiệm vụ, triển khai, xác minh và giao hàng một thay đổi cụ thể.
Một hệ thống tồn tại sau cuộc trò chuyện
Một trong những hạn chế của phát triển dựa trên prompt là quá nhiều trạng thái tồn tại bên trong một cuộc trò chuyện tạm thời.
Kiến trúc phải được giải thích lại. Các quyết định trước đó bị lãng quên. Một quá trình triển khai bị gián đoạn rất khó để tiếp tục. Một nhà phát triển phải có mặt để quyết định agent nên làm gì sau mỗi bước.
Quy trình này chuyển trạng thái đó vào các hệ thống bền vững. Repository chứa kiến trúc, quy tắc thiết kế, kỹ sư và guardrails. OpenSpec chứa thay đổi đã được lập kế hoạch và các nhiệm vụ của nó. Git chứa lịch sử triển khai và các điểm khôi phục. Backlog chứa trạng thái phân phối và các quyết định của con người. Máy local hoặc VM cung cấp môi trường liên tục nơi các vòng lặp tiếp tục chạy.
Kết quả không phải là một agent tự động duy nhất cố gắng hoạt động như một tổ chức phần mềm hoàn chỉnh. Đó là một hệ thống phối hợp trong đó các component khác nhau có các trách nhiệm khác nhau.
Con người xác định hướng đi, ràng buộc và ranh giới trách nhiệm. Các agent chuyên biệt thực hiện công việc kỹ thuật tập trung. Các vòng lặp điều phối vòng đời một cách bất đồng bộ. Backlog kết nối chúng.
Thay đổi quan trọng nhất không phải là các agent có thể tạo ra nhiều code hơn. Sự chuyển dịch lớn hơn là từ các tương tác AI riêng lẻ sang các hệ thống kỹ thuật bền vững.
Thay vì giải thích repository trước mỗi nhiệm vụ, dự án tự mang theo kiến trúc và guardrails của nó. Thay vì yêu cầu một agent chung chung triển khai mọi thứ, công việc được gán cho các chuyên gia. Thay vì tự quyết định thủ công điều nên xảy ra sau mỗi bước, các vòng lặp phản ứng với các trạng thái quy trình bền vững. Thay vì giữ toàn bộ quy trình bên trong một cuộc trò chuyện, tiến độ tồn tại trong các issue, đặc tả, commit, pull request và trạng thái cục bộ.
Vai trò của con người không biến mất. Nó chuyển sang thiết kế môi trường nơi quyền thực thi tự động được phép hoạt động.
Đó là mô hình tôi hiện đang xây dựng: một vòng đời phát triển phần mềm AI do con người thiết kế, nơi nhà phát triển thiết lập môi trường kỹ thuật và ranh giới tự động trước, sau đó các vòng lặp bất đồng bộ điều phối các agent chuyên biệt thông qua một vòng đời phân phối dựa trên backlog.
Từ con số không đến khi các vòng lặp tự chạy. Sáu bước, mỗi bước xây dựng trên bước trước đó, mỗi bước chuyển một chút trạng thái ra khỏi cuộc trò chuyện và vào các hệ thống không quên.
PS: Bạn có thể tìm thấy loop-task, opencode-onboard và các công cụ khác tại ckgrafico.com
