Cách nâng cao năng lực lập trình bằng AI

• Muốn dùng công cụ viết mã bằng AI để rút ngắn các công việc chuyển đổi vốn mất 1–2 giờ của con người xuống còn mức chỉ cần 15–20 phút để rà soát
• Tuy nhiên, hiện tại chất lượng mã do AI tạo ra còn chưa đạt tới 90% so với mã tự viết, nên có vẻ chưa thực sự hữu ích
• Vì vậy, muốn biết cách sử dụng AI thế nào để đồng thời nâng cao năng suất và chất lượng mã

Tổng hợp các mẹo thực chiến để nâng cao hiệu quả và chất lượng lập trình bằng AI

1. Chỉ tập trung dùng AI cho các tác vụ có thể lặp lại

• AI phát huy hiệu quả lớn nhất khi thực hiện nhiều lần các công việc có dạng tương tự nhau
• Một lần đầu hãy để con người tự triển khai với chất lượng tốt nhất, rồi dùng nó làm ví dụ chuẩn
• Sau đó giao cho AI xử lý hàng loạt các công việc cùng mẫu
• Với những công việc cần suy nghĩ và phán đoán, hiệu quả kỳ vọng sẽ giảm rất nhanh

2. Nhất định phải lập kế hoạch trước khi viết mã

• Đừng tạo mã ngay, hãy viết kế hoạch giải quyết trước
• Ở giai đoạn lập kế hoạch, hãy làm lộ rõ mọi điểm mơ hồ và mọi câu hỏi
• Nếu kế hoạch chưa đủ thỏa đáng thì không chuyển sang giai đoạn thực thi
• Chất lượng kết quả phụ thuộc vào độ rõ ràng của tài liệu kế hoạch hơn là prompt

3. Chia nhỏ đơn vị công việc đến mức tối đa

• Hãy yêu cầu theo đơn vị một file, một component, vài hàm
• Những yêu cầu như “refactor toàn bộ”, “cải thiện cho idiomatic hơn” có xác suất thất bại cao
• Con người làm phần thiết kế cấu trúc, còn AI chỉ đảm nhiệm phần triển khai lặp lại

4. Đừng tích lũy context, hãy khởi tạo lại thường xuyên

• Càng hội thoại dài, khả năng tuân thủ quy tắc và chất lượng càng giảm mạnh
• Mỗi session chỉ xử lý một công việc
• Nếu đổi hướng, hãy bắt đầu lại trong một session mới
• Với công việc dài hạn, hãy lưu trạng thái bằng tài liệu (plan.md chẳng hạn) rồi nạp lại

5. Tài liệu quy tắc nên ngắn và có tính máy móc

• Giữ CLAUDE.md / AGENTS.md trong khoảng 500~1000 token
• Thay vì chỉ dẫn mang tính tuyên ngôn, hãy viết các quy tắc cụ thể và có thể kiểm chứng
• Chỉ ghi lại tối thiểu những lỗi thường sai
• Phần còn lại hãy dùng mã và kiểm tra tự động để ép tuân thủ

6. Dùng test, linter và build như một vòng lặp phản hồi

• Thay vì nói “hãy làm cho tốt”, hãy đưa ra rõ ràng các điều kiện cần vượt qua
• Đặt mục tiêu là test pass, build thành công và linter có 0 lỗi
• Phải có vòng lặp phản hồi thì AI mới tự hội tụ được
• Những bài test xác minh hành vi hiện có sẽ giảm mạnh độ khó của việc refactor

7. Đừng sửa giữa chừng khi đang thực thi, hãy sửa kế hoạch rồi chạy lại

• Nếu không hài lòng với kết quả, đừng lặp lại việc yêu cầu sửa mã
• Hãy sửa tài liệu kế hoạch rồi chạy lại trong một session mới
• Nếu đổi hướng ngay trong giai đoạn thực thi, chất lượng sẽ nhanh chóng sụp đổ

8. Dạy phong cách bằng ví dụ

• Những chỉ dẫn trừu tượng kiểu “mã tốt” hầu như không có tác dụng
• Hãy cung cấp kèm ví dụ Before / After
• Trình bày rõ ràng ví dụ tốt và ví dụ xấu
• Mở rộng quy tắc xoay quanh các ví dụ

9. Đừng từ bỏ việc hiểu mã, hãy làm rõ ranh giới trách nhiệm

• Mã do AI tạo ra nhất định phải được con người hiểu và rà soát
• Ngoài prototype và mã rủi ro thấp, không được dùng mà không kiểm tra
• Với mã liên quan đến bảo mật, vận hành hoặc bảo trì dài hạn, sự thấu hiểu là tiền đề của chất lượng

10. Trước hết hãy kiểm tra xem công việc này có phù hợp với AI hay không

• Những công việc không có đáp án đúng duy nhất, đòi hỏi nhiều đánh giá về thẩm mỹ hoặc cấu trúc, sẽ bất lợi cho AI
• Refactor UI, nơi khó tự động kiểm chứng kết quả trực quan, đặc biệt khó xử lý
• Khi cần, có thể làm như sau:
  • Giai đoạn 1: chuyển đổi mang tính cơ học để giữ nguyên hành vi
  • Giai đoạn 2: con người thực hiện refactor chất lượng

11. Hãy bắt đầu kỳ vọng từ “cải thiện 10%”

• Đừng kỳ vọng 10x ngay từ đầu
• Chiến lược tích lũy các cải thiện nhỏ sẽ hiệu quả hơn về lâu dài
• Điều cốt lõi là không từ bỏ tiêu chuẩn về thiết kế và chất lượng

[GN⁺]

Ý kiến trên Hacker News

• Tôi là Boris từ đội Claude Code. Xin chia sẻ vài mẹo

  1. Những chỗ Claude thường sai hoặc không hiểu thì nên ghi vào CLAUDE.md. Claude sẽ tự động đọc file này
  2. Hãy tích cực dùng chế độ Plan (Shift+Tab hai lần), lập kế hoạch trước rồi mới cho chạy, với các tác vụ khó có thể cho kết quả tốt hơn 2~3 lần
  3. Nên cung cấp cách kiểm chứng công việc. Ví dụ trong Svelte có thể dùng máy chủ Puppeteer MCP để cho nó kiểm tra kết quả trong trình duyệt
  4. Tôi khuyên dùng Opus 4.5. Nó thật sự cho cảm giác nâng cấp hẳn một bậc so với Sonnet 4.5
     Mong là có ích
  • Tôi cũng đã trải nghiệm mức tăng năng suất lớn nhờ chế độ Plan. Nhưng ở bản gần đây có một lỗi là Plan mode cứ tiếp tục tham chiếu kế hoạch đầu tiên của phiên, làm hỏng workflow của tôi. Không biết có phải do tôi dùng theo cách bất thường không
  • Sau khi chỉnh lại Claude trong lúc làm việc, nên chạy prompt tự phản tư (self-reflection). Quá trình này sẽ tự động đưa những gì bạn đã sắp xếp thủ công vào CLAUDE.md
  • Tôi đồng ý với các lời khuyên trên. Đặc biệt vòng lặp phản hồi ở mục (3) là cốt lõi. Phải để mô hình tự sửa rồi tự kiểm tra kết quả. Cho nó để lại log file hoặc lập kế hoạch pseudocode thì ngay cả bài toán phức tạp cũng được giải quyết nhanh
  • Opus 4.5 thật sự là game changer. Nó giúp tôi rất nhiều khi refactor một dự án React cũ. Nếu viết prompt thật kỹ và thiết lập CLAUDE.md tốt thì hiệu quả rất lớn
  • CLAUDE.md chỉ hoạt động tốt khoảng 4~5 lần, sau đó nó quên chỉ thị. Ví dụ bảo nó gọi tôi là “Mr. bcherny” thì nó cũng nhanh chóng quên mất
  • So với Google Jules, Claude Code cho cảm giác giống một lập trình viên chuyên nghiệp hơn nhiều. Tuy nhiên Claude Code Web không có tính năng project, tôi được trả lời là hãy dùng file .clinerules, nhưng tôi muốn biết khác gì với CLAUDE.md
  • Một tính năng hữu ích trong CLAUDE.md là @import. Nếu thêm @ trước tên file thì có thể ép đưa nó vào context. Nhưng dùng quá nhiều thì sẽ kém hiệu quả

• Khi dùng nhập liệu bằng giọng nói, mô hình sẽ hiểu ý định chính xác hơn. Tôi nói ra các prompt cỡ 500 từ. Khi nói thì dòng suy nghĩ tự nhiên hơn so với gõ
  Nếu nói “hãy lập kế hoạch và hỏi nếu có thắc mắc”, Claude thật sự sẽ đặt câu hỏi. Bảo nó bắt chước phong cách code trước đó cũng rất hiệu quả

  • Tôi cũng đã làm gần như toàn bộ laboratory.love bằng giọng nói. Tôi thường dùng phím tắt cho câu “hãy phân tích vấn đề và yêu cầu trước khi viết code, và hỏi những điểm còn mơ hồ”
  • Nói nhanh không có nghĩa là nói không suy nghĩ. Thậm chí vấn đề có thể là nói ra mà suy nghĩ quá ít
  • Nói chuyện với AI khi có người khác đang nghe thì hơi ngượng, nhưng những câu dài thì tôi cũng nhập bằng giọng nói
  • Tôi tò mò không biết bạn dùng dịch vụ nhận dạng giọng nói nào

• Cần đưa điều kiện lặp (loop condition) vào prompt. Ví dụ: “lặp lại cho đến khi yarn test pass”.
  Xét cho cùng LLM là một agent lặp đi lặp lại việc chạy công cụ, nên phải đối xử với nó theo cách đó
  Tham khảo: Prompting the Agent Loop

• Tôi muốn giới thiệu cấu hình nori-profiles mà tôi đã làm.
  Sau 4 tháng thử nghiệm, hiệu năng của Claude Code được cải thiện rõ rệt.
  Bài liên quan: Averaging 10 PRs a Day with Claude

  • Tôi tò mò nó khác gì so với skills của Claude Code

• Ở công ty tôi làm việc với một codebase Golang quy mô lớn. Tôi đã thử nhiều công cụ như Cursor, Claude Code, Gemini CLI, nhưng đa số đều bị khối lượng code áp đảo.
  Tuy nhiên aider dễ kiểm soát hơn nhiều và có độ chính xác cao. Việc thêm file thì phải làm thủ công, nhưng gần như chính xác 100%.
  Dùng với Claude Sonnet mới nhất hoặc Gemini 2.5 Pro thì cho độ chính xác tốt nhất

  • Điểm mạnh của aider là không phải agent hoàn toàn tự trị. Bạn tự quản lý context bằng tay nên không có chuyện sửa nhầm file. Nó cũng có lợi về tiết kiệm token và tốc độ

• Khi làm việc với Cursor, trước tiên tôi cho nó refactor một route để tạo file rule. Sau đó với các route khác chỉ cần nói “refactor” là được

  • Đừng sợ prompt dài. Đó chính là context engineering. Chính lịch sử hội thoại sẽ làm context phong phú hơn.
    Nên luôn ý thức về dung lượng context còn lại, và khi cần thì xóa context sớm

• Góc nhìn đối xử với agent như đồng đội là rất quan trọng. Phải quan sát điểm mạnh và điểm yếu của nhau rồi điều chỉnh cách cộng tác.
  Tôi tập trung sức mạnh của agent vào những bài toán có thể kiểm chứng hoặc code thử nghiệm.
  Tôi không rành Svelte, nhưng có lẽ nên dẫn dắt việc rewrite bằng các bài test disposable theo kiểu TDD.
  Đôi khi cách tốt nhất là bỏ bối cảnh sai trước đó và bắt đầu lại trong một workspace mới

  • Sẽ rất hay nếu bạn chia sẻ bản tóm tắt đoạn nói về “phong cách nhận thức và làm việc nhóm” đó

• Tôi xem LLM là một cỗ máy tìm kiếm (searcher). Nếu câu hỏi nhỏ và cụ thể thì việc tìm kiếm dễ hơn, còn càng xa dữ liệu huấn luyện thì xác suất lỗi càng cao.

  1. Mở project trong Zed
  2. Kết nối một trong Gemini CLI, Qwen code, hoặc Claude
  3. Yêu cầu sửa file rồi chạy test
  4. Nếu không được thì thử với Grok hoặc Gemini 3 Chat
  5. Vẫn không xong thì tự xử lý thủ công
     Với project mới, chỉ cần prompt one-shot cũng thường là đủ
  • Nhưng prompt quá ngắn lại gây ra vấn đề thiếu đặc tả (underspecification). Nó chỉ giảm chi phí tính toán chứ bất lợi về mặt chất lượng

• Bộ công cụ Claude Code tôi hay dùng là superpowers

  1. Trước tiên mô tả tính năng trong một buổi brainstorm
  2. Claude viết tài liệu thiết kế và kế hoạch triển khai rồi lưu xuống đĩa
  3. Trong cửa sổ Claude mới, dùng lệnh Execute Plan để thực hiện từng bước và commit
  4. Cứ mỗi ba bước lại cho nó tự review để nâng chất lượng code
     Tôi dùng được 2 tuần rồi và gần như chưa từng thất bại

• Nguyên tắc lập trình với AI của tôi rất đơn giản

  1. Hoàn thành trong một lần (one-shot) là thất bại
  2. Chia công việc thành các đơn vị có thể kiểm chứng
  3. Ghi toàn bộ kế hoạch vào một file Markdown
  4. Ở mỗi bước, chạy trong một phiên mới, review rồi commit
     Cốt lõi là “Less is more”. Cửa sổ context càng mới càng tốt, và khoảng 500~750 từ là lý tưởng. Mọi bước đều phải kiểm chứng được

• Với các tác vụ liên quan đến Java, Claude liên tục đổi hướng hoặc đưa ra đề xuất mâu thuẫn. Tôi thấy ChatGPT tốt hơn nhiều

  • Nếu đưa chỉ thị cụ thể hơn trong prompt thì có thể sẽ khá hơn
  • Không biết bạn đã thử phiên bản Claude Code chưa

• Nếu muốn có idiomatic code, trước tiên bạn phải định nghĩa thật chi tiết phong cách mà mình nghĩ tới. Chia nhỏ ví dụ tốt/xấu, đưa chúng vào Plan mode của Opus 4.5 để lập kế hoạch rồi thực thi. Nếu chưa hoàn hảo trong một lần, hãy sửa tài liệu kế hoạch rồi thử lại. Nếu cố chỉ dẫn quá li ti như với lập trình viên junior thì ngược lại còn kém hiệu quả

  • Một người khác chia sẻ kinh nghiệm rằng “các model dạo này không nhất thiết phải mở phiên mới”, và refactor inline cũng đã đủ ổn định rồi