Disclaimer: Nội dung dịch lại từ post của thím Burke Holland, bổ sung các quan điểm cá nhân, vài nhận xét và một số cải tiến, có thể bỏ qua đọc trực tiếp tiếng Anh.

Mới đọc nhanh bài này trên X của GitHub, thấy có nhiều điểm đồng ý (có vài điểm không đồng ý) và vì cũng đang follow theo workflow dạng này, thấy khá hiệu quả, nên tóm tắt nhanh lại cho các fen.

Bài này, mention nhiều về GitHub Copilot, tuy nhiên có thể bỏ qua tất cả các keyword về Copilot, chỉ giữ lấy ý tưởng, và dùng ý tưởng đó apply cho bất kỳ công cụ nào tương tự.

FOMO và ngập trong tin tức AI

Đầu tiên, tui có cùng cảm giác với vấn đề tác giả đặt ra: luôn cảm thấy bị ngập, hoặc thấy mình bị chậm cập nhật trong kỷ nguyên AI, tâm lý FOMO khi theo dõi các tin tức về AI. Mỗi ngày có cả đống tin tức về AI như tool mới được sinh ra, MCP mới, model mới được giới thiệu. Lâu lâu lại có khứa show một skill, workflow, feature về AI mới, cảm giác bị FOMO vl.

Ví dụ như gần đây là Kimi 3, Opus 5, Claude Cowork, Sicene, rồi security workflow … trên FB thì các content tiếng Việt, hội nhóm tiếng Việt đa phần FOMO, share câu chuyện, nhưng ẩn đi ngữ cảnh.

Bởi tâm lý FOMO đó, dẫn tới hôm nay dùng tool này, ngày mai lại FOMO tool khác. Dùng workflow này, mai lại workflow khác, thấy người khác shill skill này tốt, là copy nguyên folder skill về nhét vào agent. Càng ngày tooling càng bloat, chất lượng output kém đi, một mớ slop code được gen ra.

Từ tâm lý đó, dẫn tới việc xác định cho mình một cách làm việc hiệu quả rất quan trọng, giúp bản thân tránh bị tâm lý, chạy đua công cụ.

Agent = Model + Harness

Model thì trả tiền để dùng, giàu sang phú quý thì Mẽo model (Anthropic, OpenAI), nghèo thì Tung Của model, nhìn chung các frontier model hiện tại đều làm tốt các tác vụ, công việc thông thường của software engineering, nên chọn cái nào cũng được.

Harness là mớ tool, flow, skills, template, sanbox, permission, policy, guardian …

Workflow cụ thể

Chọn coding agent

Coding agent gì cũng được, ban đầu chọn đại, không cần nghĩ nhiều mệt: Claude Code, Codex, Pi, OpenCode, Copilot… whatever. Nguyên tắc ở đây là dùng quen, hãy tìm hiểu về internal của coding agent đó, hiểu cách hoạt động, hiểu cách customize, sẽ có ích sau này.

YOLO mode

Tác giả khuyên xài YOLO mode. Lý do cũng khá hợp lý, agent có càng nhiều context, thì output càng chất lượng, mà context tốt nhất để feed vào agent là ở YOLO mode. Nhưng ở khía cạnh security, nên cẩn trọng. Cá nhân tui không hoàn toàn đồng ý với tác giả ở điểm này. Ae nào mạnh thì YOLO, nhưng cẩn thận mấy cái sensitive trong máy. Kể cả các khái niệm như sandbox bằng container hoặc VM cũng không thực sự giúp bảo vệ các sensitive data khỏi agent.

Bắt đầu với prototype

Đại ý là có một cái gì đó sơ sơ, một bản prototype ý tưởng, mong muốn của mình, chứ đừng bảo agent one-shot từ A-Z. Tác giả khuyến nghị ở bước này xài medium-sized model, cỡ như Sonnet thôi là được rồi.

Nếu thím nào đọc bài prompt caching của thím Mario (tác giả của Pi) thì sẽ thấy một ý được nhắc tới, đó là stick với model và reasoning level mà bạn đã chọn, đừng switch giữa chừng, vì prompt caching sẽ giúp tiết kiệm mớ token/usage, bài của Mario deep dive về KV Cache.

Plan trước, implement sau

Nhiều người cũng đang apply plan/implement flow hoặc spec flow. Đại ý là đừng code vội (Software engineering flow truyền thống), mà hãy viết plan/spec trước, xong dựa trên cái đó, yêu cầu AI implement. Flow này hiện tại được build-in trong các coding agent như ClaudeCode, OpenCode, Codex hay Antigravity, chỉ cần switch mode là dùng được, nhưng cũng có thể tự custom như tui đang dùng spec-workflow.

Với cá nhân tui, plan/impl/spec là chưa đủ, issue lớn nhất là dù đã dành thời gian ĐỌC lại spec/impl, vẫn có nhiều ý chưa hiểu, chưa tường minh. Nên trong workflow từ spec -> implement, tui luôn nhét /grill-me của thím Matt Pocock vào trong đó và khá hài lòng với skill này. Đây là một critical step với tui. Mục tiêu là human (mình) và agent shared understanding. Nó giúp mình củng cố kiến thức, agent hiểu chính xác cái mình đang mong muốn (ở plan mode) -> Điều này đem lại kết quả siêu tốt ở bước implement.

Implement với autopilot

Tác giả implement bằng cách dùng autopilot trong Copilot, tựa /goal trong Claude Code vậy, loop tới khi nào xong thì thôi. Với input là implement markdown từ bước trên, chạy tới khi nào đạt được goal. Ở bước này, tùy mỗi cá nhân có thể lựa chọn việc muốn áp dụng cho phù hợp, có thể dùng auto hoặc ra lệnh agent implement từng bước. Bước này không quan trọng lắm, linh động theo nhu cầu.

Human review và lặp lại

Đây là bước human (thằng người là mình) tham gia vào review lại kết quả, đây cũng là bước quan trọng, vì nó giúp con người có giá trị trong flow của AI. Và vì tất nhiên không phải lúc nào AI implement xong, output cũng chính xác với cái mình muốn (chuyện đó hết cmn sức bình thường), nên buộc con người phải tồn tại trong vòng lặp này.

Flow của bước này là review, feedback, update spec/plan, grill nếu cần và lặp lại tới khi nào đạt được kết quả mình mong muốn.

Tác giả có nói: đừng chấp nhận kết quả ở mức “tạm được”. Hãy yêu cầu khắt khe về chất lượng sản phẩm, bởi cuối cùng, đó là trách nhiệm của lập trình viên. Khả năng phân biệt được đâu là sản phẩm chất lượng, đâu là một thứ xoàng xoàng nhưng vẫn work mới chính là giá trị mà con người mang lại. AI không thể thay thế được dấu ấn cá nhân của con người trong sản phẩm. Đây cũng là một điểm cực kỳ quan trọng giúp sản phẩm tạo ra không phải AI slop.

Nếu ai từng đọc qua My LLM coding workflow going into 2026 của Addy Osmani, sẽ thấy một ý tương đồng và CỰC KỲ QUAN TRỌNG. Mục Keep a human in the loop - verify, test, and review everything, bước này đặt con người vào flow làm việc, coi con người vẫn là trung tâm, là architect, là người điều khiển AI thay vì là nô lệ của AI =))). Lúc này, vai trò của AI sẽ rõ ràng hơn, trở thành “trợ thủ cực kỳ hiệu quả”, giúp lập trình viên làm việc tốt hơn, nhanh hơn, hiểu quả hơn.

Final review

Request review từ một model khác họ, đây cũng là một flow khá phổ biến trong giới lập trình (và cả testing, security phase). Trước đây khi chưa có AI, code sau khi được implement, owner tạo PR và nhờ người review code (Senior hoặc teammate) trước khi code được merge. Mục tiêu là đánh giá giải pháp, bắt các bug mà người lập trình có thể bỏ sót.

Với AI, code đã được gen bởi AI, nếu dùng chính model code để review lại code, sẽ có bias, nên người ta nghĩ ra một cách đó là dùng model khác họ để review lại code thay vì dùng sức người. Ví dụ dùng GPT implement thì request Sonnet review, hoặc ngược lại (ClaudeCode còn có trò spawn nhiều agent, dùng Haiku để chain review, output của agent này sẽ là input của agent kia). Model khác họ train bởi dataset khác, sẽ giúp tránh bias.

Cá nhân tui, có thể nâng cấp bằng cách apply bước review (hay xài một prompt gọi là audit-me) để review ngay ở bước gen spec/implement markdown (tùy độ lớn của task/feature). Mục tiêu là đạt được spec/implement markdown chất lượng trước khi gen code. Tất nhiên vẫn review code ở bước cuối cùng trước khi merge PR.

Lời kết quan trọng

But keep in mind that nobody really knows what they are doing right now. We’re all figuring this out as we go. A lot of what is today’s magical incantation for AI will be tomorrow’s anti-pattern.

Just focus on getting a repeatable, high-quality result in the simplest way that you can. Learn the harness and you’ll be just fine.

Quan điểm cá nhân

  • Dùng một coding agent quen rồi, nên thử một coding agent khác. Sau đó nâng cấp bằng cách custom sơ sơ agent (prompt, skill, extension) cho phù hợp với cách mình làm việc, sẽ thấy nhiều cải tiến.
  • Hãy dùng thử các open source coding agent, như OpenCode hay Pi, vì ClaudeCode khá bloat do được gắn sẵn nhiều tools.
  • Nếu có điều kiện, hãy dùng các model mới nhất.
  • Hãy cẩn thẩn với sub-agent, nó đốt token nhiều hơn rất nhiều.