Tasks as Code: Đưa công việc vào chính kho mã nguồn

Các tác nhân lập trình AI (AI coding agent) làm việc dựa trên kho mã nguồn, vậy tại sao vẫn giữ task trong Jira? Phương pháp Tasks as Code lưu công việc dưới dạng tệp Markdown trong Git, nằm cạnh mã nguồn và tài liệu.

Bài viết gợi ý một cách tiếp cận đơn giản nhưng hiệu quả: thay vì để yêu cầu công việc nằm rải rác trong các công cụ bên ngoài, hãy đưa chúng vào chính kho mã nguồn. Khi đó, tác nhân AI có thể đọc yêu cầu và mã nguồn ở cùng một nơi, còn con người thì theo dõi lịch sử thay đổi qua Git như mọi commit khác.

Từ "Docs as Code" đến "Tasks as Code"

Tài liệu đã đi trước một bước trong quá trình chuyển dịch này. Từ chỗ nằm trong phần mềm riêng biệt, tài liệu nay thường được viết bằng Markdown và đặt trong thư mục /docs của kho mã nguồn — cách làm quen thuộc với tên gọi Docs as Code (hay Docs Like Code).

Minh họa cách tiếp cận Docs as Code

Khi có tác nhân AI, cách làm này càng trở nên hữu ích. Tác nhân có thể đọc tài liệu để hiểu hệ thống, sửa mã nguồn, rồi cập nhật tài liệu liên quan trong cùng một quy trình. Tài liệu trở thành một phần không thể tách rời của quá trình phát triển phần mềm, thay vì một việc phải làm sau cùng.

Tasks as Code áp dụng nguyên lý tương tự cho các task phát triển. Khi task được lưu dưới dạng tệp Markdown, tác nhân có thể đọc trực tiếp, dùng chúng để lập kế hoạch và ghi lại kết quả vào chính tệp đó. Git giữ lịch sử task song hành với lịch sử phần mềm và tài liệu.

Ý tưởng này đã phần nào xuất hiện trong Spec-Driven Development (SDD) — phương pháp dùng đặc tả Markdown để định nghĩa hành vi mong muốn trước khi AI triển khai. Tệp task có thể phục vụ mục đích tương tự, mức độ chi tiết tùy vào quy mô công việc: một task bảo trì nhỏ chỉ cần mô tả ngắn, trong khi một tính năng phức tạp có thể cần tiêu chí nghiệm thu, quyết định kỹ thuật, phụ thuộc và yêu cầu kiểm thử.

Quy trình năm bước

Không cần công cụ chuyên dụng để bắt đầu — chỉ cần Git và một tác nhân AI là đủ. Dưới đây là quy trình đơn giản gồm năm bước:

• Mô tả task: viết mô tả ngắn về thay đổi hoặc tính năng cần triển khai.
• Phân tích yêu cầu: tác nhân đọc task, xem xét mã nguồn và tài liệu liên quan.
• Lập kế hoạch triển khai: tác nhân đề xuất giải pháp và xác định những thay đổi dự kiến.
• Xem xét và phê duyệt: lập trình viên đánh giá kế hoạch và cho phép triển khai.
• Triển khai và báo cáo: tác nhân sửa mã nguồn, cập nhật tài liệu khi cần và ghi thêm báo cáo triển khai vào tệp task.

Điểm mấu chốt là mô tả task, kế hoạch triển khai và báo cáo cùng nằm trong một tệp. Nhờ vậy, người review dễ dàng đối chiếu yêu cầu ban đầu, hiểu hướng tiếp cận dự kiến và xem tác nhân thực sự đã thay đổi những gì.

Bước phê duyệt giúp con người giữ quyền kiểm soát. Tác nhân không đi thẳng từ mô tả task sang triển khai, mà kế hoạch có thể được xem xét và chỉnh sửa trước.

Một cách thiết lập thực tế

Trong thiết lập của tác giả, ba kho Git riêng biệt được sử dụng: mã nguồn, tài liệu và task. Lý do khá thực tế — tài liệu thường công khai, còn task có thể chứa thông tin nhạy cảm như bản vá bảo mật chưa hoàn thiện, kế hoạch nội bộ hay tính năng chưa công bố. Tách kho giúp cấu hình quyền truy cập độc lập và giữ task riêng tư.

Về mặt cục bộ, lập trình viên clone kho tài liệu và kho task vào các thư mục con bên trong kho mã nguồn. Cả hai thư mục được liệt kê trong .gitignore của kho cha, và mỗi kho clone vẫn giữ lịch sử Git riêng, có thể commit, push và đồng bộ độc lập.

/code-repo
/src
/tests
/docs                 # Kho tài liệu riêng
/user-guides
/admin-manuals
/developer-docs
/tasks                # Kho task riêng tư
/release-123
task-551-something-descriptive.md
task-552-something-descriptive.md
.gitignore            # Loại trừ docs và tasks

Lúc này, mọi thông tin đều sẵn có cho trợ lý lập trình cục bộ như Claude Code hay OpenCode. Khi triển khai một task, tác nhân đọc task, phân tích mã nguồn, thực hiện thay đổi và cập nhật tài liệu liên quan. Báo cáo triển khai ở lại cùng task, còn thay đổi mã nguồn thực tế được ghi vào kho mã nguồn. Việc tham chiếu tên tệp task trong commit Git giúp gắn kết phần triển khai với yêu cầu ban đầu.

Khi task được tổ chức theo thư mục phiên bản phát hành, tác nhân có thể dựa vào các task đã hoàn thành và lịch sử Git để soạn changelog và release notes, đồng thời xác định những tài liệu cần cập nhật.

Tasks as Code kết hợp với giao diện Typemill

Thêm giao diện, nhưng không thay thế Git

Git và một tác nhân AI là đủ để vận hành quy trình này. Tuy nhiên, một giao diện trên trình duyệt sẽ bổ sung cách duyệt, chỉnh sửa và tổ chức tệp mà không thay thế Git ở vai trò hệ thống quản lý phiên bản gốc.

Typemill có thể đồng bộ nội dung với kho Git. Nhờ hỗ trợ nhiều kho, bạn có thể cấu hình một dự án riêng cho task nội bộ song song với dự án tài liệu — quản lý cả hai qua cùng một giao diện dù nội dung nằm ở các kho khác nhau.

Giao diện quản lý tài liệu của Typemill

Như vậy, cùng một bộ tệp có thể truy cập qua ba giao diện, mỗi giao diện phục vụ một mục đích riêng:

• Trong IDE: lập trình viên và tác nhân AI làm việc trực tiếp với các kho cục bộ.
• Trên GitHub: cộng tác viên có thể review thay đổi và chỉnh sửa tệp qua giao diện kho.
• Trên trình duyệt: Typemill cung cấp giao diện đọc và quản lý task, tài liệu cho cả người không chuyên kỹ thuật như chủ sản phẩm hay biên tập viên kỹ thuật.

Git vẫn chịu trách nhiệm về lịch sử phiên bản và đồng bộ. Đây là một điểm phân biệt quan trọng: giao diện không nhất thiết phải sở hữu dữ liệu. Nó chỉ cung cấp cách làm việc tiện lợi với những tệp vẫn có thể mang đi và truy cập bằng công cụ khác.

Cục bộ, riêng tư và dựa trên tệp

Typemill cùng một CMS dạng flat-file chỉ là một lựa chọn nhanh để thử nghiệm quy trình. Bất kỳ thiết lập nào giữ tệp Markdown trong Git và cho tác nhân truy cập đều hoạt động — bạn có thể bắt đầu chỉ với một thư mục chứa các tệp task.

Câu hỏi thú vị hơn là điều gì sẽ diễn ra tiếp theo. Một khi task theo chân tài liệu vào kho mã nguồn, nhiều phần mềm và giao diện mới được thiết kế cho mô hình này sẽ xuất hiện. Lập trình viên, chủ sản phẩm và biên tập viên kỹ thuật sẽ cần một nơi làm việc chung, và tác nhân AI sẽ là một phần của quy trình đó. Cũng còn bỏ ngỏ câu hỏi những tính năng nào của hệ thống ticket hiện nay vẫn thực sự cần thiết: phân công, bình luận, bảng kanban, sprint? Có lẽ không phải tất cả, nếu phần lớn công việc do tác nhân AI đảm nhận.

Dựa trên thiết lập trên, đây là những đặc tính đáng hướng tới:

• Gốc Git (Git-native): task và đặc tả là các tệp có thể đọc được, quản lý qua Git và gắn với mã nguồn lẫn tài liệu.
• Tài liệu và task song hành: một giao diện cung cấp quyền truy cập cả tài liệu lẫn quản lý task.
• Dựa trên tệp: Markdown vẫn dễ đọc, dễ mang đi và không phụ thuộc nền tảng cụ thể.
• Tự lưu trữ (self-hosted): đội ngũ giữ quyền kiểm soát dữ liệu, quyền riêng tư và hạ tầng.
• Mở với dịch vụ AI: lập trình viên tự chọn nhà cung cấp AI ưa thích, giao diện nên có tích hợp chung thay vì khóa người dùng vào một dịch vụ duy nhất.

Với các đội ngũ phát triển tại Việt Nam đang bắt đầu đưa AI vào quy trình làm việc, mô hình Tasks as Code là một cách nhẹ nhàng để thử nghiệm: chi phí thấp, không cần thay đổi công cụ quản lý hiện tại ngay lập tức, nhưng mở đường cho việc cộng tác giữa người và tác nhân AI trên cùng một nền tảng dữ liệu minh bạch.