AI-native development9 phút đọc · 28 thg 5, 2026

AI workflow lập trình: một ngày code với AI trông thế nào

✦ Tóm tắt bởi AI

Bài viết hướng dẫn quy trình lập trình với AI thực tế: thay vì chỉ dùng autocomplete, bạn nên mô tả rõ yêu cầu, review diff cẩn thận, và biết chia việc nào cho AI (boilerplate, test, refactor) và việc nào tự làm (logic phức tạp, quyết định kiến trúc). Chìa khóa là quản lý ngữ cảnh tốt, lập kế hoạch cho task lớn, và luôn kiểm soát được code bạn merge.

HOLETEX · POST
AI WORKFLOW
hằng ngày

Nhiều người cài Cursor hoặc Claude Code xong vẫn dùng nó như một cái autocomplete đắt tiền: gõ vài dòng, nhấn Tab, thỉnh thoảng hỏi chat. Khoảng cách giữa "có công cụ" và "code nhanh hơn thật" nằm ở quy trình, không phải ở việc bạn dùng model nào.

Bài này không giới thiệu công cụ (nếu bạn cần bức tranh tổng thể, đọc Lập trình với AI 2026 trước). Ở đây mình mô tả một ai workflow lập trình thực tế: một ngày code với AI diễn ra ra sao, chia việc thế nào, và những thói quen giữ cho code không trôi khỏi tầm kiểm soát.

Một ngày code với AI trông thế nào

Hình dung một buổi làm việc bình thường. Bạn nhận một task: thêm tính năng đăng nhập bằng Google.

Thay vì mở file và tự gõ, bạn mở agent, mô tả việc cần làm và yêu cầu nó đọc codebase, lập kế hoạch trước. Bạn đọc kế hoạch, sửa vài chỗ nó hiểu sai, rồi cho chạy. Agent sửa năm bảy file, chạy test, báo kết quả. Bạn đọc diff, thấy một chỗ xử lý lỗi chưa đúng, gõ một câu yêu cầu sửa. Xong phần này, bạn clear ngữ cảnh và chuyển sang task tiếp theo.

Xen giữa đó vẫn là những lúc bạn tự code tay: một đoạn logic nghiệp vụ tinh tế, một quyết định kiến trúc, một bug mà bạn muốn tự lội vào để hiểu. AI không thay thế những lúc này, nó dọn đường để bạn có thời gian cho chúng.

Điểm khác biệt so với cách cũ: bạn dành nhiều thời gian mô tả và review hơn là . Tài liệu của Anthropic mô tả đúng sự dịch chuyển này: "thay vì tự viết code rồi nhờ Claude review, bạn mô tả thứ mình muốn và Claude tìm cách dựng nó". Vai trò của bạn nghiêng về người ra đề và người duyệt bài.

Chia việc nào cho AI, việc nào tự làm

Đây là quyết định quan trọng nhất mỗi ngày, và nó không cố định. Một cách phân loại đơn giản:

Giao cho AI những việc rõ ràng, lặp lại, hoặc tốn công gõ:

  • Viết test cho một hàm theo các case bạn liệt kê.
  • Boilerplate: CRUD endpoint, form, component theo pattern có sẵn.
  • Refactor cơ học: đổi tên, tách hàm, chuyển một pattern sang pattern khác trên nhiều file.
  • Tra cứu trong codebase: "logging hoạt động thế nào", "tạo API endpoint mới ở đâu".
  • Dịch lỗi khó hiểu thành lời giải thích.

Tự làm (hoặc giữ quyền quyết định) ở những việc cần phán đoán:

  • Quyết định kiến trúc: tách module thế nào, dữ liệu chảy ra sao.
  • Logic nghiệp vụ phức tạp mà chỉ bạn hiểu ngữ cảnh thật.
  • Những đoạn nhạy cảm: xử lý tiền, phân quyền, bảo mật.
  • Đánh giá cuối cùng: code này có đáng merge không.

Một mẹo thực tế từ docs Claude Code: nếu bạn có thể mô tả thay đổi trong một câu thì cứ bảo AI làm thẳng, khỏi cần kế hoạch. Còn khi bạn không chắc cách tiếp cận, hoặc thay đổi đụng nhiều file, hoặc bạn chưa quen vùng code đó, hãy lập kế hoạch trước. Ranh giới nằm ở độ chắc chắn của chính bạn.

Vòng lặp cốt lõi: prompt → review diff → sửa

Đây là trái tim của một quy trình code với ai lành mạnh. Nó lặp lại hàng chục lần mỗi ngày.

Prompt cụ thể

Chất lượng output tỉ lệ thuận với độ rõ của yêu cầu. So sánh hai cách:

  • Mơ hồ: "viết test cho auth.ts".
  • Cụ thể: "viết test cho auth.ts, phủ case người dùng đăng xuất giữa chừng, theo pattern trong thư mục __tests__/, không dùng mock".

Cursor nói thẳng trong tài liệu của họ: "tỉ lệ thành công của agent cải thiện đáng kể khi hướng dẫn cụ thể". Chỉ rõ file liên quan, ràng buộc, và ví dụ pattern bạn muốn theo. Phần này là một kỹ năng riêng, mình viết kỹ hơn trong Prompt cho lập trình.

Review diff

Bước không bao giờ được bỏ. Đọc từng dòng AI sinh ra, hiểu nó làm gì. Cursor cảnh báo đúng chỗ đau: "code do AI sinh ra có thể trông đúng mà sai một cách tinh vi", và "agent càng làm nhanh, quy trình review của bạn càng quan trọng".

Khi agent đang chạy, bạn có thể nhìn diff hiện ra theo thời gian thực và bấm Stop ngay nếu thấy nó đi sai hướng. Đừng đợi nó làm xong cả mớ rồi mới sửa.

Sửa, hoặc làm lại

Nếu kết quả lệch nhẹ, gõ một câu chỉnh hướng. Nhưng nếu nó lệch nhiều, đừng cố vá. Cả Cursor lẫn Anthropic đều khuyên cùng một điều: quay lại, revert thay đổi, viết lại yêu cầu cho rõ hơn và chạy lại. Cursor mô tả cách này "thường nhanh hơn là sửa một agent đang làm dở, và cho kết quả sạch hơn".

Docs Claude Code có một quy tắc dễ nhớ: nếu bạn đã sửa cùng một lỗi hơn hai lần trong một phiên, ngữ cảnh đã bị nhiễu bởi các hướng sai. clear và bắt đầu lại với một prompt tốt hơn gần như luôn thắng một phiên dài đầy các lần sửa chồng lên nhau.

Dùng Plan mode cho task lớn

Với task chạm nhiều file hoặc có nhiều cách làm, đừng để AI nhảy thẳng vào code. Cả hai công cụ đều có chế độ lập kế hoạch trước (Cursor là Plan Mode, nhấn Shift+Tab; Claude Code là plan mode).

Quy trình Anthropic đề xuất gồm bốn pha: explore → plan → implement → commit. Đầu tiên để AI đọc file và hiểu vùng code mà chưa sửa gì. Sau đó yêu cầu nó tạo kế hoạch chi tiết: cần đổi những file nào, luồng ra sao. Bạn đọc và sửa kế hoạch (cả hai công cụ cho mở plan dưới dạng file Markdown để edit trực tiếp). Duyệt xong mới cho thực thi, rồi commit.

Lý do nó hiệu quả: sửa một kế hoạch sai rẻ hơn nhiều so với sửa hàng trăm dòng code sai. Cursor khuyên dùng Plan Mode cho "tính năng phức tạp có nhiều cách làm hợp lệ" và "task chạm nhiều file hoặc nhiều hệ thống"; còn việc đơn giản thì "vào thẳng Agent mode là ổn". Đừng lập kế hoạch cho mọi thứ, nó cũng tốn thời gian.

Quản ngữ cảnh (context)

Đây là phần dev mới thường bỏ qua, nhưng nó quyết định chất lượng output về cuối ngày. Hầu hết best practice của Claude Code đều xoay quanh một ràng buộc: "context window đầy nhanh, và hiệu năng giảm khi nó đầy". Khi ngữ cảnh chật, model bắt đầu "quên" hướng dẫn trước đó và mắc lỗi nhiều hơn.

Vài thói quen giữ ngữ cảnh sạch:

  • Reset giữa các task không liên quan. clear (Claude Code) hoặc mở chat mới (Cursor) khi chuyển sang việc khác. Một phiên ôm nhiều task khiến ngữ cảnh đầy thông tin thừa.
  • Đừng tag thủ công mọi file. Agent có search tool đủ mạnh để tự tìm file liên quan qua grep và semantic search. Tag tay nhiều khi chỉ làm nhiễu.
  • Tạo file quy tắc cho dự án. CLAUDE.md (Claude Code) hoặc rules trong .cursor/rules/ (Cursor) cho AI ngữ cảnh bền vững: lệnh build, code style, quy ước. Nguyên tắc chung của cả hai: chỉ thêm rule khi agent lặp lại cùng một lỗi, và giữ file ngắn. Anthropic nói thẳng file quá dài khiến Claude "bỏ qua nửa số rule vì cái quan trọng lạc trong đống chữ".

Khi nào KHÔNG nên dùng AI

AI là đòn bẩy, không phải lúc nào cũng là lựa chọn đúng. Vài tình huống nên cân nhắc tự làm:

  • Khi bạn không đủ sức review output. Nếu code AI sinh ra vượt khả năng đọc hiểu của bạn, bạn đang merge thứ mình không kiểm soát. Anthropic gọi đây là "trust-then-verify gap": kết quả trông hợp lý nhưng không xử lý hết edge case. Quy tắc gọn: thứ gì bạn không verify được thì đừng ship.
  • Đoạn code nhỏ mà rõ. Sửa một biến, thêm một dòng log: tự gõ còn nhanh hơn mô tả.
  • Khi bạn đang học. Nếu mục tiêu là hiểu một khái niệm hay một framework, để AI làm hộ sẽ lấy mất chính phần luyện tập bạn cần. Dùng nó để giải thích, đừng dùng nó để né việc hiểu.
  • Quyết định kiến trúc lớn. AI gợi ý được, nhưng người chịu trách nhiệm cho hệ thống vẫn là bạn.

Thói quen giữ chất lượng

Tốc độ chỉ có giá trị nếu code vẫn đứng vững. Vài thói quen nên đóng đinh:

  • Cho AI một cách tự kiểm chứng. Đây là mẹo lớn nhất từ docs Claude Code: đưa cho agent một thứ trả về pass/fail (test suite, lệnh build, linter, hoặc screenshot để so) thì vòng lặp tự đóng. AI làm, chạy check, đọc kết quả, tự sửa tới khi qua. Không có check, "trông như xong" là tín hiệu duy nhất, và bạn thành người dò lỗi thủ công.
  • Đọc diff như review code đồng nghiệp. Code AI viết mà bạn merge thì đó là code của bạn. Trách nhiệm không chuyển sang AI.
  • Hiểu code trước khi merge. Nếu không giải thích được một đoạn làm gì, đừng cho nó vào nhánh chính. Đây là lằn ranh giữa dùng AI và vibe coding mù quáng.
  • Một check độc lập cho task lớn. Sau khi xong, mở một phiên mới (hoặc subagent) review lại diff với ngữ cảnh sạch. Model mới không thiên vị code nó vừa viết nên bắt lỗi tốt hơn.

Để ý kỹ sẽ thấy: mọi thói quen trên đều dựa vào nền tảng của chính bạn. Bạn phải đọc code giỏi, hiểu hệ thống, biết test thế nào là đủ thì mới điều khiển được AI thay vì bị nó dắt. AI khuếch đại người có nền, và phơi bày người không có.

Nếu bạn muốn xây cái nền đó cho frontend, khóa React PRO của HoleTex dạy bạn làm chủ React tới mức đọc và đánh giá được mọi đoạn code AI sinh ra, để AI là đòn bẩy chứ không phải cái bẫy.

Bài liên quan

Nguồn tham khảo: Best practices for Claude Code (code.claude.com), Best practices for coding with agents (cursor.com), Plan Mode (cursor.com). Cập nhật 2026-06-07.

Thấy hay? Chia sẻ