Crash course prompting cho người mới dùng coding agent

1. Prompt là nền móng của mọi thứ phía sau

Philipp Lackner mở đầu bằng một lời hứa (video đăng ngày 01/11/2026): xem xong video này, bạn sẽ không còn phải lo về prompt của mình nữa, vì anh nói sẽ thật sự đi qua mọi thứ cần biết. Anh nhấn mạnh điều đó rất quan trọng, ít nhất là với một software developer dùng prompt để điều khiển coding agent: để sinh code, để đưa chỉ dẫn cho AI làm một việc gì đó, để viết code.

Theo Philipp (video đăng ngày 01/11/2026), prompting chắc chắn không phải khoa học tên lửa (no rocket science). Anh nói sẽ giữ phần hướng dẫn này khá ngắn, tập trung vào những gì thực sự quan trọng và bỏ qua phần còn lại. Nhưng làm đúng các nền tảng này một lần là rất, rất quan trọng, bởi vì xét cho cùng, prompt là nền móng tuyệt đối (the absolute foundation) của mọi thứ bạn làm.

Anh giải thích (video đăng ngày 01/11/2026): prompt khởi động một kiểu dây chuyền (cascade), kích hoạt các hành động phía sau, việc sinh code, hay việc coding agent lập ra một plan. Và nếu prompt của bạn không chính xác, không tốt, thì mọi thứ đi sau nó cũng sẽ không tốt.

2. Prompt vẫn quan trọng, nhưng với frontier model thì khác

Philipp nhắc tới chuyện có thể bạn đã nghe các "AI guru" trên mạng, hay những người làm video về prompt engineering, nói rằng một thứ khác đã thay thế nó. Với anh (video đăng ngày 01/11/2026), điều đó "thật sự là BS". Xét cho cùng, chúng ta vẫn đang prompt một LLM, và prompt đó vẫn quan trọng.

Ở một mức độ nào đó, anh hiểu ý những người này. Nếu gọi đúng tên là prompt engineering, và biến việc viết một prompt tốt thành một nghề thủ công thật sự, thì theo anh (video đăng ngày 01/11/2026) nó vẫn có chỗ đứng trong một số ngách nhất định, nơi bạn thật sự phải "engineer" prompt và bỏ rất nhiều chất xám để làm ra một prompt tốt.

Nhưng với công việc liên quan tới code thông thường, khi bạn làm việc trong Claude Code hay một công cụ tương tự, Philipp nói (video đăng ngày 01/11/2026) bạn thường muốn bám vào các frontier model. Và khi bạn dùng một frontier model như model Opus mới nhất tại thời điểm video đăng ngày 01/11/2026, thì thường bạn không phải bỏ nhiều chất xám để đưa prompt vào một cấu trúc thật đẹp: có các dấu phân tách (divider) đàng hoàng, chỉ ra chính xác thứ tự các bước model phải làm. Theo anh, những thứ đó rất quan trọng với các model yếu hơn.

Anh lấy ví dụ (video đăng ngày 01/11/2026): trong business automation, khi bạn tự động hoá một số quy trình trong công ty và có một bước ở giữa do LLM làm. Bước đó dựa vào một model yếu hơn vì nó rẻ hơn, do phải chạy rất thường xuyên, có thể là GPT mini hay một model tương tự. Theo anh, đó là những môi trường mà prompt engineering thực thụ vẫn rất quan trọng, vì các model yếu hơn hiển nhiên cũng yếu hơn ở khả năng hiểu bạn thật sự muốn gì.

Tuy vậy, Philipp nói (video đăng ngày 01/11/2026), ngay cả khi dùng frontier model cho công việc liên quan tới code, vẫn có vài nguyên tắc rất nền tảng mà bạn đơn giản là phải hiểu.

3. Nguyên tắc đầu: thật cụ thể, và một prompt tệ trông ra sao

Nguyên tắc rất quan trọng đầu tiên để viết một prompt tốt, theo Philipp (video đăng ngày 01/11/2026), là phải thật cụ thể (be very specific). Anh nói đây thật sự là chuyện của luyện tập: ai cũng thấy hiển nhiên là phải cụ thể trong prompt, nhưng không nhiều người thật sự nghĩ xem điều đó nghĩa là gì.

Ví dụ tệ của anh là câu "Add a search feature to my app". Theo anh (video đăng ngày 01/11/2026), câu đó để lại rất nhiều chỗ cho việc diễn giải. AI không biết tính năng search phải hoạt động thế nào. Anh liệt kê một loạt câu hỏi còn bỏ ngỏ:

• Đó chỉ là một phép search SQL đơn giản? Hay bạn muốn dùng full text search? (ví dụ câu hỏi Philipp nêu trong video đăng ngày 01/11/2026)
• Bạn chỉ search trong database local, hay gửi một request search lên API? (cũng trong video đăng ngày 01/11/2026)
• Văn bản phải được so khớp chính xác thế nào? (cũng trong video đăng ngày 01/11/2026)
• Có template nào bạn muốn áp vào việc search không, kiểu như Google hỗ trợ chẳng hạn? (cũng trong video đăng ngày 01/11/2026)

Và nhất là khi làm software development, theo Philipp (video đăng ngày 01/11/2026), tất nhiên bạn muốn thật cụ thể về đặc tả chính xác (specification) của một tính năng như vậy khi lên kế hoạch cho nó cùng AI.

4. Bản prompt cụ thể hơn cho tính năng search

Philipp đưa ra một bản gắn nhãn GOOD, nhưng anh nói rõ (video đăng ngày 01/11/2026) rằng bản này cũng vẫn còn quá thiếu chính xác, chỉ để bạn hình dung nó đi theo hướng nào. Câu trên slide ghi:

"Add a search bar to the board screen that filters cards by title and description as the user types. Match case-insensitively, debounce the input by 300ms and show an empty state when nothing matches."

Anh đi qua từng phần (video đăng ngày 01/11/2026): bạn muốn chính xác hơn nhiều về cách lọc thực sự hoạt động, lọc theo những trường nào, việc lọc diễn ra khi người dùng gõ là một yêu cầu quan trọng ở đây, so khớp không phân biệt hoa thường, debounce input, hiện một empty state khi không có gì khớp, và cứ thế tiếp tục. Tất nhiên, với một tính năng search hoàn chỉnh, anh nói bạn sẽ tiếp tục viết thêm theo kiểu prompt này.

5. Brain dump vào Claude Code, rồi bảo model phản biện mình

Philipp kể cách anh thường làm khi brainstorm một tính năng như vậy và soạn đặc tả cho nó (video đăng ngày 01/11/2026): anh "xả não" trọn vẹn (complete brain dump) vào cửa sổ Claude Code, gồm mọi thứ, mọi góc nhỏ trong đầu anh về chủ đề đó, những gì anh đang nghĩ.

Đây là điểm anh nói tới lúc trước: theo Philipp (video đăng ngày 01/11/2026), giờ làm vậy hoàn toàn ổn. Bạn cứ có một bản brain dump trọn vẹn, không cần có cấu trúc. Theo anh, các model hiện đại, các frontier model, rất, rất giỏi trong việc thật sự hiểu ý bạn. Bạn không phải sắp xếp nó trước. Bạn không phải chia suy nghĩ thành các phần riêng biệt trong prompt. Với các frontier model, anh nói điều này không còn quan trọng nữa.

Nhưng điều thật sự quan trọng, theo Philipp (video đăng ngày 01/11/2026), là đưa vào mọi thứ bạn nghĩ ra được cho task cụ thể đó, rồi vẫn kết thúc bằng một câu như câu trên slide, để model thật sự phản biện bạn về những quyết định bạn đã đưa ra và có thể nghĩ ra những thứ bạn chưa nghĩ tới. Lý do anh đưa ra: hầu như lúc nào cũng có những thứ bạn đã bỏ sót, một vài edge case chẳng hạn, và bạn cần prompt model về điều đó một cách tường minh.

Câu kết trên slide:

"Challenge me about any decisions and think of what I didn't think of."

6. Bắt model phỏng vấn mình về từng quyết định

Philipp nói thêm (video đăng ngày 01/11/2026): kể cả khi bạn không prompt điều đó mà chỉ đang ở plan mode, model cũng sẽ phỏng vấn bạn một chút. Nhưng anh thấy rằng nếu bạn thật sự đưa yêu cầu này vào prompt, kiểu như nói rằng bạn thật sự muốn nó phỏng vấn bạn một cách kỹ lưỡng (rigorously) về từng chi tiết trong các quyết định bạn đã đưa ra và đề xuất một phương án thay thế thực tế, thì cuối cùng bạn sẽ có một bản đặc tả tính năng kỹ lưỡng hơn nhiều.

Theo lời anh, câu anh nói với model có nội dung như sau (video đăng ngày 01/11/2026):

I really want you to rigorously interview me about every single detail in the decision I've made and propose a realistic alternative

Lý do, theo Philipp (video đăng ngày 01/11/2026): nếu không làm vậy, anh thấy các model thường chỉ tập trung vào những điều quan trọng nhất cần làm rõ, và bỏ qua những thứ đáng ra nên bàn, những thứ mà khi được hỏi, anh sẽ nói: "Ồ, đó thật ra là một ý hay. Sao mình không dùng luôn cách đó?"

7. Ngôn ngữ của con người vốn mơ hồ

Ý tiếp theo rất gần với chuyện phải thật cụ thể, nhưng Philipp nói (video đăng ngày 01/11/2026) nó thật ra không phải một nguyên tắc, mà là một điều bạn phải suy nghĩ: ngôn ngữ của con người rất mơ hồ (ambiguous). Khi chúng ta nói một điều gì đó, thường có rất nhiều cách để người khác hiểu nó. Theo anh, đó là thứ chúng ta không thật sự gặp khi chỉ viết code thô (raw code).

Anh nói (video đăng ngày 01/11/2026) đây cũng là điều người ta hay chỉ trích ở AI: ngôn ngữ của con người mơ hồ và có thể mang nhiều nghĩa. Còn nếu chúng ta có một thuật toán, chúng ta có một đặc tả deterministic hoàn hảo về cách thuật toán đó phải chạy. Nhưng nếu chúng ta mô tả thuật toán đó bằng lời, thì thường vẫn có những phần nhỏ mà chúng ta không thể diễn đạt hoàn toàn deterministic.

Ví dụ của anh (video đăng ngày 01/11/2026): nếu bạn đưa cùng một prompt y hệt mô tả một thuật toán vào ba, bốn, năm session khác nhau, mỗi lần bạn sẽ nhận được một thuật toán khác. Phần ngôn ngữ vẫn giữ nguyên, nhưng output thì khác.

Theo Philipp (video đăng ngày 01/11/2026), chúng ta không thể làm cho ngôn ngữ của con người bớt mơ hồ, nhưng có thể tập trung làm cho prompt của mình ít mơ hồ nhất có thể.

8. "Do not leave anything untested" nghĩa là gì?

Ví dụ tiếp theo của Philipp là câu "Do not leave anything untested". Anh hỏi (video đăng ngày 01/11/2026): câu đó nghĩa là gì? Với bạn, có thể nó rõ ràng trong đầu. Nhưng khi nghĩ kỹ, bạn cũng sẽ đi tới kết luận: ừ, thật ra nó nghĩa là gì nhỉ? Phải test những gì?

Anh giải thích (video đăng ngày 01/11/2026): không để sót thứ gì chưa test, vậy thì chúng ta có thể test code tới tận góc cuối cùng, có thể test cả UI preview chẳng hạn, vì nếu không test chúng thì vẫn còn một thứ chưa được test, và prompt này sẽ không được đáp ứng. Kết quả, theo anh, là bạn có thể nhận về rất, rất nhiều test case không cần thiết, chỉ vì AI muốn đáp ứng prompt của bạn.

9. Nói cho model biết phải làm gì, đừng để model tự đặt tiêu chí

Philipp thừa nhận (video đăng ngày 01/11/2026) các frontier model có lẽ sẽ hiểu điều này, sẽ phản biện nó một chút, hoặc sẽ chuyển nó thành những tiêu chí (criteria) đàng hoàng. Nhưng theo anh, tiêu chí mà một frontier model tự chuyển câu đó thành sẽ luôn là tiêu chí kém hơn so với khi chính bạn đặt ra tiêu chí.

Thay vào đó, anh đưa ra một câu cụ thể hơn. Câu trên slide ghi (slide trong video đăng ngày 01/11/2026):

"Reach 100% line coverage for business logic and security and 70% test coverage for the UI, excluding previews, then run mutation tests to fix tests that make the wrong assertions"

Theo Philipp (video đăng ngày 01/11/2026), như vậy là bạn thật sự nói cho model biết nó nên làm gì, thay vì nói nó không nên làm gì.

10. Cẩn thận với câu "do not", trừ những câu kiểu có/không

Vì vậy, nói chung, Philipp khuyên (video đăng ngày 01/11/2026) hãy rất, rất cẩn thận với những câu "do not", dù chúng nằm ở đâu, trong system prompt hay trong prompt của bạn: đừng nói cho AI biết những gì không được làm.

Theo anh (video đăng ngày 01/11/2026), có vài ngoại lệ, khi nghĩa của câu thật sự rõ ràng, khi không có cách nào khác để hiểu nó. Đó là những câu kiểu Boolean điển hình. Nếu bạn nói kiểu như "do not touch this file", câu hỏi đó thật sự trả lời được bằng có hoặc không: nó có đụng vào file hay không? Câu đó không mơ hồ, vì bạn có thể trả lời rõ ràng là chuyện đó có xảy ra hay không.

Còn với câu "không để sót thứ gì chưa test", Philipp nói (video đăng ngày 01/11/2026) bạn không thể trả lời rõ ràng là có thứ gì bị bỏ sót chưa test hay không, vì lúc nào cũng sẽ còn một thứ gì đó bạn có thể test thêm. Bạn còn chưa nói rõ là loại test nào. Theo anh, những câu "do not" này có thể thật sự gây hại cho prompt của bạn, cho chất lượng output bạn nhận được.

Một ví dụ khác của anh (video đăng ngày 01/11/2026): nếu bạn nói kiểu "do not consume a lot of tokens", điều này có thể rất có hại, vì nó chủ động ngăn chính model khỏi khả năng đưa ra output chất lượng. Nhưng nếu bạn nói chính xác hơn về việc model nên dùng token, hay thời gian suy nghĩ (thinking time), chủ yếu cho việc gì, thì theo anh đó là điều model biết cách làm. Không có hướng hiểu nào khác mà nó có thể rút ra từ prompt đó.

11. Đưa ví dụ thật, nhưng đừng lặp cùng một loại ví dụ

Tiếp theo, theo Philipp (video đăng ngày 01/11/2026), một cách lúc nào cũng hiệu quả nếu bạn muốn model hiểu nó nên làm một việc như thế nào là đưa sẵn một ví dụ minh hoạ điều đó. Ví dụ bạn có một coding pattern, một coding convention, hay một package structure cụ thể cho kiến trúc của mình, thì hãy đưa cho nó một ví dụ thật để nó hiểu, vì theo anh các model rất giỏi trong việc chuyển từ ví dụ của bạn sang những trường hợp tương tự khác.

Điều quan trọng khi làm vậy, theo anh (video đăng ngày 01/11/2026), là đừng "spam" AI bằng rất nhiều ví dụ cùng một loại. Ví dụ với prompt "Write commit messages like these:", nhiều ví dụ cùng loại sẽ là hai hay nhiều ví dụ khác nhau nhưng không thêm được gì, vì tất cả chỉ mô tả commit message nên trông thế nào cho một loại thay đổi, ví dụ code của một feature mà logic đã thay đổi.

Theo Philipp (video đăng ngày 01/11/2026), hợp lý hơn hiển nhiên là có những ví dụ khác biệt, mỗi cái bao một phần khác nhau. Và trong trường hợp này, cứ đi qua mỗi loại một lần. Anh nói anh nghĩ điểm này đã rõ.

12. Giải thích lý do: ví dụ cơ chế auth

Một điều Philipp nói anh rất thích làm (video đăng ngày 01/11/2026) là giải thích vì sao anh muốn có một thứ, hoặc vì sao anh không muốn có nó. Theo anh, giải thích "vì sao" cho AI thật sự giúp ích rất nhiều.

Anh kể một tác dụng phụ nho nhỏ dễ chịu (video đăng ngày 01/11/2026): bạn cũng tự nghĩ kỹ hơn một chút về lập luận của mình và tự hiểu các khái niệm liên quan tốt hơn một chút. Nhưng lý do chính anh làm vậy là mặc định AI tất nhiên không hiểu mục đích đằng sau của chúng ta. Theo anh, nếu chúng ta đưa mục đích đó cho nó, nó bỗng có thể hiểu tốt hơn những đánh đổi (tradeoff) có thể có, vì mục đích đằng sau việc chúng ta thật sự muốn làm, và lý do chúng ta muốn làm nó, quyết định hoàn toàn cách việc đó nên được làm.

Ví dụ của anh (video đăng ngày 01/11/2026): nếu anh chỉ nói "do not implement a complex auth mechanism" hay "do not implement a secure auth mechanism", thì chính câu đó có thể là điều AI sẽ phản đối. Theo anh, AI sẽ nói kiểu: "Không, authentication dựa trên bảo mật. Chúng ta muốn dữ liệu người dùng được an toàn. Nên tôi không khuyến nghị làm như vậy." Anh nói đó có lẽ là thứ AI sẽ trả lời ở đây.

Nhưng nếu đưa kèm lý do, rằng anh đang làm project này chỉ như một demo project cho YouTube, thì theo Philipp (video đăng ngày 01/11/2026) mọi thứ bỗng trở nên hợp lý. Theo lời anh, phần lý do thêm vào là:

because I'm building this project solely as a demo project for YouTube

13. Cùng một quyết định, project này đúng, project kia sai

Theo Philipp (video đăng ngày 01/11/2026), tất cả hoàn toàn phụ thuộc vào việc bạn đang làm gì, vì sao bạn đưa ra những quyết định nhất định. Cùng một quyết định tất nhiên có thể đúng, hay là một quyết định tốt, cho project A, nhưng lại là quyết định tệ cho project B.

Anh giải thích (video đăng ngày 01/11/2026): mặc định, nếu bạn không đưa cho AI lý do nào, nó sẽ trả lời theo những gì nó đã thấy nhiều nhất ngoài kia, theo các thực hành chuẩn (proper practices). Nhưng rất thường xuyên bạn có lý do rất chính đáng để không theo những thứ tiêu chuẩn. Và nếu bạn đưa những lý do đó, theo anh, bạn cũng mở ra chỗ cho AI thật sự phản biện bạn về lý do đó, đồng thời mở ra chỗ để AI đề xuất thêm những thứ hợp lý với lý do và mục đích đó.

Theo Philipp (video đăng ngày 01/11/2026), nếu bạn làm theo những nguyên tắc anh đã đi qua, bạn thật sự có mọi thứ cần thiết về mặt prompting, ít nhất là để áp dụng khi sinh code với coding agent. Tất nhiên, anh nói, vẫn còn một con đường dài phía trước để thật sự áp dụng tất cả những điều đó trong một môi trường chuyên nghiệp. Với anh, prompting chỉ là tầng thấp nhất của chuyện đó: nó cực kỳ quan trọng, nhưng tất nhiên còn rất nhiều thứ khác cũng quan trọng.

Anh mong video này có ích, chúc mọi người phần còn lại của tuần thật tuyệt, rồi chào tạm biệt.