CLI agent: chọn bài tập nhỏ trước đã

CLI agent: chọn bài tập nhỏ trước đã

Một playbook giúp team builder quyết định khi nào dùng Copilot CLI, khi nào làm HTML tool một file, và khi nào nên né agent cho khỏe.

Có một kiểu demo rất dễ làm tech lead mềm lòng: mở terminal, gõ một câu, agent chạy lệnh, sửa file, app hiện lên. Trông như sinh viên làm bài tập nhóm mà tự biết chia việc, tự nộp bài, tự sửa lỗi chính tả. Rồi sáng thứ Hai, team đem về áp vào repo thật và phát hiện: “Ủa sao nó sửa luôn file config production?”

Mình không chê CLI coding agent. Ngược lại, những thứ như GitHub Copilot CLI đang mở ra một workflow khá đáng tiền: mô tả việc cần làm ngay trong terminal, để AI đề xuất lệnh, chỉnh code, chạy thử, rồi lặp lại. Nhưng luận điểm của bài này hơi ngược gió một chút: đừng bắt đầu bằng dự án lớn. Hãy bắt đầu bằng một bài tập nhỏ có rubric chấm điểm rõ ràng.

Nếu bạn đang xây hệ thống AI cho team, câu hỏi không phải là “tool nào mới nhất?”. Câu hỏi nên là: việc nào đủ nhỏ để agent làm tốt, đủ thật để team học được, và đủ an toàn để sai không cháy nhà?

Mục tiêu: biến CLI agent thành trợ lý triển khai, không phải người lái chính

Trong bài GitHub kể chuyện build một roguelike procedurally generated bằng Copilot CLI, phần đáng chú ý với mình không phải là game. Game chỉ là sân chơi. Điểm đáng học là cách dùng CLI agent để đi qua vòng lặp: tạo cấu trúc, viết code, chạy thử, sửa lỗi, thêm tính năng.

Ở phía khác, Simon Willison có một hướng rất thực dụng: build HTML tools — các công cụ nhỏ gói trong một file HTML, gồm HTML, CSS, JavaScript, đôi khi load dependency từ CDN. Không cần React, không build step, copy ra là chạy. Với LLM, kiểu bài này hợp vì phạm vi nhỏ, feedback nhanh, ít tầng hạ tầng.

Hai nguồn cảm hứng này gặp nhau ở một playbook khá gọn:

Dùng CLI agent cho vòng lặp triển khai; dùng bài toán nhỏ, dễ chạy, dễ kiểm tra để huấn luyện workflow của team.

Dịch sang chuyện lớp học: đừng giao luận văn ngay buổi đầu. Hãy giao bài tập về nhà có đáp án kiểm tra được.

Checklist trước khi bật agent trong repo thật

Trước khi cho agent đụng vào codebase, mình sẽ kiểm tra 6 thứ này. Không phải để làm màu quy trình, mà để giảm kiểu tai nạn “agent rất chăm nhưng chăm sai”.

1. Phạm vi có đóng khung không?
Việc tốt cho CLI agent thường có ranh giới rõ: tạo một tool nội bộ, viết script migration nháp, thêm command vào CLI, sinh test case, refactor một module nhỏ. Việc xấu là “tối ưu toàn bộ backend” hoặc “làm lại auth”.

2. Có cách chạy và kiểm tra nhanh không?
Nếu mỗi lần validate phải deploy staging, chờ QA, hỏi product, agent sẽ bị mù. Lý tưởng là có lệnh như:

npm test
npm run lint
python -m pytest

3. Có dữ liệu giả thay vì dữ liệu thật không?
Đừng để agent học thói quen chạm vào secret, customer data, hoặc production credentials. Nếu cần state phía client, với HTML tool nhỏ có thể dùng localStorage — nơi trình duyệt lưu dữ liệu cục bộ — nhưng nhớ chỉ dùng cho dữ liệu không nhạy cảm hoặc môi trường cá nhân.

4. Có commit nhỏ để rollback không?
Agent sinh code nhanh, nhưng diff cũng phình nhanh. Commit nhỏ giống bảng điểm từng câu, sai câu nào sửa câu đó.

5. Có policy dependency không?
Nếu tool một file HTML load thư viện từ CDN, hãy ghi rõ thư viện nào được phép. Nếu repo production cấm CDN, đừng để agent tự kéo về cho tiện.

6. Có người chịu trách nhiệm review không?
AI có thể viết code, nhưng ownership vẫn là của team. Code do agent sinh ra mà không ai hiểu thì chẳng khác gì bài làm chép mạng: nhìn sạch, hỏi sâu là lúng túng.

Ba đường triển khai: chọn theo độ rủi ro

Không phải mọi việc đều cần cùng một cấp công cụ. Đây là khung mình hay dùng khi phải quyết định trong team builder.

| Lựa chọn | Hợp với việc gì | Điểm mạnh | Rủi ro |
|---|---|---|---|
| HTML tool một file | Tool nội bộ nhỏ, converter, viewer, form tính toán | Không build step, dễ share, feedback nhanh | Dễ thành “file thần kỳ” khó maintain nếu phình |
| CLI agent như Copilot CLI | Viết script, chỉnh repo, chạy test, lặp lỗi | Gắn thẳng vào workflow terminal | Có thể sửa quá tay nếu prompt mơ hồ |
| Open-source coding agent | Team muốn tự host, kiểm soát luồng, thử nghiệm sâu | Linh hoạt, có thể audit hoặc tùy biến | Tốn công vận hành và guardrail |

Open-source alternatives ở đây có thể là các coding agent hoặc framework điều phối như Aider, Continue, OpenHands, AutoGen, CrewAI. Mình không nói bạn nên nhảy ngay vào một framework. Với nhiều team Việt Nam, quyết định khôn hơn là: bắt đầu bằng HTML tool hoặc CLI agent có sandbox, rồi mới tính tự host khi workflow đã chứng minh giá trị.

Ví dụ cụ thể: team data của một công ty thương mại điện tử cần tool so sánh hai file CSV campaign. Đừng mở dự án React mới, dựng CI/CD, tạo design system. Một file HTML kéo thả CSV, parse bằng JavaScript, highlight dòng khác nhau là đủ cho vòng đầu. Sau đó nếu tool sống lâu, lúc ấy mới nâng cấp.

Ví dụ khác: team backend muốn thêm command validate-config cho service nội bộ. Đây là bài hợp với CLI agent: yêu cầu đọc schema, sinh command, viết test, chạy pytest, sửa lỗi. Nhưng đừng giao luôn “chuẩn hóa toàn bộ config platform”. Bài đó quá rộng, agent sẽ tự làm giáo án cho chính nó, và thường là giáo án lạc đề.

Thực hành trong một buổi chiều

Bạn có thể thử playbook này mà không cần xin ngân sách hay mở dự án mới.

Bước 1: Chọn một việc nhỏ nhưng thật
Chọn việc mà team đang làm thủ công ít nhất vài lần mỗi tuần. Ví dụ:

Bước 2: Viết prompt như đề bài kiểm tra
Đừng viết “làm tool giúp tôi”. Hãy viết:

Tạo một file index.html duy nhất.
Không dùng React, không cần build step.
Cho phép paste JSON vào textarea.
Hiển thị bảng gồm path, old value, new value.
Có nút copy kết quả dạng Markdown.
Không gửi dữ liệu ra server.

Ở đây, “không dùng React” không phải ghét React. Nó chỉ giúp scope nhỏ lại. Với tool cần copy-paste nhanh, build step là ma sát không cần thiết.

Bước 3: Cho agent chạy trong thư mục riêng

mkdir ai-lab-json-diff
cd ai-lab-json-diff
git init

Nếu dùng CLI agent, yêu cầu nó tạo file, rồi tự mở bằng browser hoặc local server đơn giản. Nếu không dùng Copilot CLI, bạn vẫn có thể dùng LLM web để sinh file HTML, sau đó tự chạy.

Bước 4: Tự viết rubric chấm điểm
Rubric nên ngắn, cụ thể:

Bước 5: Commit theo từng vòng

git add index.html README.md
git commit -m "prototype json diff html tool"

Sau đó mới yêu cầu agent cải thiện UI, thêm sample, hoặc tách hàm. Mỗi vòng một mục tiêu. Nói thẳng ra thì: agent càng ít phải đoán, bạn càng ít phải dọn.

Những cái bẫy khiến team tưởng mình đang nhanh

Bẫy đầu tiên là để agent chọn kiến trúc quá sớm. Một tool xem log nội bộ mà agent dựng Vite, React, state management, test framework, deploy config thì giống bài kiểm tra 15 phút nộp kèm luận cương thạc sĩ. Không sai về mặt kỹ thuật, nhưng lệch mục tiêu.

Bẫy thứ hai là tin vào demo chạy được một lần. Chạy được chưa có nghĩa là dùng được. Với builder, cần hỏi thêm: lỗi input thì sao, dependency có ổn không, ai review, data có rời máy không, có rollback không?

Bẫy thứ ba là đưa secret vào prompt hoặc local state bừa bãi. localStorage tiện, nhưng không phải két sắt. Nếu tool cần token, hãy ưu tiên nhập tạm trong session, không lưu lâu; hoặc dùng backend proxy có kiểm soát nếu đã lên production.

Bẫy cuối cùng hơi buồn cười: agent viết code tốt hơn viết README. Mình từng thấy một prototype chạy ổn, nhưng không ai trong team biết mở thế nào vì README chỉ ghi “run the app”. Với tool nội bộ, README là tờ hướng dẫn làm bài. Thiếu nó, người sau sẽ hỏi lại từ đầu.

Next action: chọn một quyết định, không chọn một món đồ chơi

Nếu là mình, mình sẽ không bắt đầu bằng câu “team nên dùng Copilot CLI hay open-source agent nào?”. Mình sẽ bắt đầu bằng quyết định nhỏ hơn:

Takeaway của mình: đừng đo AI coding bằng độ hoành tráng của demo; hãy đo bằng số việc nhỏ team dám giao, dám kiểm, và dám maintain. Agent giỏi nhất vẫn cần đề bài tử tế — chấm điểm mơ hồ thì đừng trách học trò làm văn lạc đề.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo