Managing Ambiguity
The real skill in the age of AI isn’t writing better prompt, it’s discovering your unknowns before they turn into expensive rework
Có một giai đoạn mình nghĩ rằng làm việc tốt với AI chỉ đơn giản là viết prompt rõ hơn. Nếu kết quả chưa đúng, có lẽ là do mình mô tả chưa đủ chi tiết, chưa đưa đủ context, hoặc chưa nói rõ format đầu ra. Cách nghĩ đó không sai, nhưng càng làm việc nhiều với các AI coding agent, mình càng nhận ra nó chỉ đúng ở tầng rất nông.
Vấn đề lớn hơn không nằm ở chỗ mình có viết prompt dài hay không, mà nằm ở chỗ mình có thật sự hiểu điều mình đang yêu cầu AI làm hay không.
Nói cách khác, giới hạn của AI trong nhiều trường hợp không còn nằm ở năng lực của model, mà nằm ở khả năng của mình trong việc nhận diện những điều chưa rõ.
Mình đọc một bài viết của Thariq về cách làm việc với Claude Fable, trong đó có một ý làm mình khá thích: “the map is not the territory”. Hiểu một cách đại lý là bản đồ không phải là vùng đất thật. Prompt, tài liệu, spec, context, hình ảnh, user story hay design mà mình đưa cho AI chỉ là bản đồ. Còn vùng đất thật tức là nơi AI thực sự làm việc là codebase, business logic, edge case, constraint kỹ thuật, expectation của user, deadline của sprint, và cả những quyết định sản phẩm chưa được nói thành lời.
Khoảng cách giữa bản đồ và vùng đất đó chính là nơi các “unknowns” xuất hiện.
Và khi AI phải đi vào territory, nó sẽ gặp những điều mà map không mô tả đầy đủ. Lúc đó, nếu mình không làm rõ từ trước, AI buộc phải tự đoán, AI sẽ tự đưa ra các assume chưa có căn cứ. Có lúc nó đoán đúng, có lúc nó đoán theo best practice, có lúc nó chọn một hướng nghe rất hợp lý về mặt kỹ thuật nhưng lại sai với ngữ cảnh sản phẩm.
Đó là lý do tôi nghĩ kỹ năng làm việc với AI trong giai đoạn này không còn chỉ là “prompt engineering” nữa. Nó giống hơn với một kỹ năng rất quen thuộc của PM, BA, Product hay Engineering Lead: managing ambiguity trước khi nó trở thành cost of rework.
1. The Unknowns We Bring to Every Project
Khi bắt đầu một task, thông thường chúng ta sẽ có một phần thông tin khá rõ. Ví dụ, chúng ta biết mình muốn xây một tính năng bulk assign client trong CRM. Mình biết user cần chọn nhiều client cùng lúc, assign cho một team hoặc một agent, và hệ thống cần giúp thao tác nhanh hơn thay vì xử lý từng dòng.
Đó là phần “known knowns”, tức là những điều mình biết và có thể nói ra cho AI hiểu được.
Nhưng ngay sau đó sẽ xuất hiện nhóm thứ hai: những điều mình biết là mình chưa rõ. Ai có quyền assign? Team Lead có được assign trực tiếp cho agent không? Shift Lead có được override owner cũ không? Nếu client đang được chăm sóc bởi sales khác thì xử lý thế nào? Có cần audit log không? Có cần rollback không?
Đó là “known unknowns”, những câu hỏi mình biết là cần clarify.
Hai nhóm này tương đối dễ xử lý, vì ít nhất chúng ta còn nhìn thấy chúng, biết rõ cần phải làm gì để xử lý. Tuy nhiên, vấn đề khó hơn nằm ở hai nhóm còn lại.
Có những thứ mình thật ra biết, nhưng không viết ra vì nghĩ nó hiển nhiên. Ví dụ, khi nhìn vào một màn hình, mình có thể nói ngay layout này chưa ổn, flow này hơi rối, hay trạng thái lỗi này nên hiển thị gần input hơn thay vì đặt ở một banner chung. Nhưng nếu được yêu cầu mô tả từ đầu bằng chữ, chưa chắc mình đã nói được rõ ràng.
Đó là “unknown knowns”, đó là những điều mình biết ngầm, nhưng chỉ nhận ra khi nhìn thấy một prototype, một UI, một flow hoặc một implementation cụ thể.
Và cuối cùng là phần nguy hiểm nhất: “unknown unknowns”, những điều mình chưa từng nghĩ tới. Đây thường là những case chỉ lộ ra khi dev bắt tay vào làm, khi QA test, hoặc tệ hơn, khi user thật bắt đầu sử dụng sản phẩm.
Trong product work, unknown unknowns có thể là một rule permission bị thiếu, một case duplicate client giữa hai brand, một dependency với module khác, một API cũ có behavior không giống tài liệu, hoặc một interaction nhỏ khiến toàn bộ UX trở nên khó dùng.
Trong coding với AI, những unknown unknowns này còn nguy hiểm hơn, vì AI không dừng lại để hỏi nếu mình không yêu cầu nó hỏi. Nó sẽ tiếp tục đi, chọn một hướng hợp lý theo xác suất, rồi hoàn thành task với sự tự tin rất cao.
Kết quả là mình có một output nhìn khá hoàn chỉnh, nhưng bên trong chứa rất nhiều giả định chưa từng được review.
2. AI as a Thought Partner
Điểm mình thích nhất trong bài viết không phải là các prompt cụ thể, mà là mindset phía sau: hãy dùng AI như một thought partner để tìm unknowns, thay vì chỉ xem nó như một người nhận task.
Trước đây, khi giao việc cho AI, mình thường có xu hướng đi thẳng vào yêu cầu: “Viết user story này”, “Tạo implementation plan”, “Generate test cases”, “Refactor đoạn code này”, “Viết lại bài này thành essay”. Cách đó vẫn hiệu quả với những việc đơn giản, nhưng với những task dài, nhiều tầng logic hoặc nhiều rủi ro sản phẩm, đi thẳng vào execution thường khiến mình bỏ qua giai đoạn quan trọng nhất: làm rõ vấn đề.
Một cách hay hơn là bắt đầu bằng việc yêu cầu AI tìm điểm mù.
Ví dụ, thay vì nói:
“Hãy viết user story cho bulk assign clients.”
Mình có thể bắt đầu bằng:
“Tôi đang define tính năng bulk assign clients cho CRM. Hãy làm một blind spot pass và chỉ ra những unknown unknowns có thể ảnh hưởng tới permission, ownership, duplicate clients, audit log, rollback, UX flow và data model. Đừng viết solution ngay, hãy giúp tôi hiểu những điểm cần clarify trước.”
Giải thích một tí cho các bạn về blind spot pass, đó là bước yêu cầu AI tạm thời chưa làm solution ngay, mà trước tiên giúp mình rà soát những điểm mù của vấn đề. Nói đơn giản, đó là lúc mình hỏi AI: “Có điều gì tôi chưa biết là mình chưa biết không?” Với những task phức tạp như viết requirement, thiết kế flow hay implement một phần mới trong codebase, blind spot pass giúp phát hiện sớm các rủi ro, edge case, assumption ẩn, dependency hoặc câu hỏi cần clarify trước khi bắt tay vào làm. Đây là cách dùng AI như một thought partner để giảm ambiguity và tránh rework sau này.
Quay lại phần US trên, cách hỏi này thay đổi vai trò của AI. Nó không còn là người viết theo yêu cầu, mà trở thành một người reviewer đầu tiên, giúp mình nhìn thấy những câu hỏi đáng lẽ phải xuất hiện trước khi task được đưa vào sprint.
Với công việc PM/BA, đây là điểm rất đáng áp dụng. Nhiều khi vấn đề không phải là team thiếu effort, mà là requirement đi vào development khi vẫn còn quá nhiều giả định. Đến lúc implement mới phát hiện thiếu flow, thiếu state, thiếu rule, thiếu permission, thiếu error message, thì chi phí sửa luôn cao hơn rất nhiều so với việc hỏi đúng câu hỏi từ đầu.
Mình cũng đã sử dụng cách tìm blind spot pass trong cách làm việc của mình khá nhiều trong 2-3 tháng trở lại đây, và thực sự phải woa khi các model Fable, Opus hay Codex có thể giúp mình tìm ra những điểm mù trong quá trình phân tích yêu cầu.
3. Making the Invisible Visible
Có một dạng unknown rất khó xử lý bằng chữ: những điều mình chỉ biết khi nhìn thấy.
Trong UI/UX, điều này xảy ra liên tục. Mình có thể nói “màn hình này cần clean hơn”, “flow này nên đơn giản hơn”, “dashboard này cần professional hơn”, nhưng những câu đó không đủ để AI hoặc designer hiểu chính xác mình muốn gì. Ngay cả bản thân mình đôi khi cũng chưa chắc mình muốn gì, cho đến khi nhìn thấy vài phương án khác nhau.
Đó là lúc brainstorm và prototype trở nên hữu ích.
Thay vì yêu cầu AI làm ngay một version hoàn chỉnh, mình có thể yêu cầu nó tạo ra vài hướng khác nhau để mình phản ứng. Không cần backend, không cần data thật, không cần wire up logic phức tạp. Chỉ cần một mockup đủ rõ để mình nhìn vào và nói: hướng này đúng, hướng kia sai, phần này nên giữ, phần kia nên bỏ.
Điểm quan trọng ở đây là prototype không chỉ giúp AI hiểu mình hơn. Nó còn giúp chính mình hiểu mình hơn.
Nhiều quyết định sản phẩm không xuất hiện trong đầu khi mình ngồi viết spec, nhưng lại xuất hiện rất nhanh khi mình nhìn thấy một flow cụ thể. Ví dụ, khi nhìn vào màn hình bulk action, mình mới nhận ra cần có preview trước khi apply. Khi nhìn vào assignment modal, mình mới thấy cần phân biệt assign cho team và assign cho từng agent. Khi nhìn vào error state, mình mới thấy nếu một vài client assign thất bại thì không nên fail toàn bộ batch, mà nên có partial success report.
Những điều đó thường không đến từ việc suy nghĩ trừu tượng. Chúng đến từ phản ứng với một artifact cụ thể.
Và AI rất mạnh ở điểm này: nó có thể tạo ra artifact ít tốn token, nhanh, nhiều biến thể, đủ để mình khám phá suy nghĩ của chính mình trước khi commitment vào một implementation tốn kém hơn.
Và có một điều mình chú ý là gần đây khi dùng Fable, Opus hay thậm chí Sonnet, nếu các bạn tích hợp sẵn MCP Playwright, thì chính các model này có thể sử dụng MCP này để control mở browser và tự compare với những gì mà nó đề xuất, và tự correct lại nếu output tạo ra không đúng spec ban đầu, một highly recommend nên kết hợp với MCP Playwright khi muốn tạo nhanh các prototype và đối chiếu nhé.
4. Planning for Change, Not Certainty
À đoạn này thì viết dành cho các bạn build product hay developer nhé, còn nếu BA/ PM mình nghĩ dừng lại ở phần trên là được rồi, vì mục tiêu của chúng ta là hoàn thiện spec đúng requirement của khách đưa ra và giải quyết các vấn đề mơ hồ. Tuy nhiên, nếu bạn là một TPM, bạn có thể lên plan này để hỗ trợ cho team cũng được, vì với mindset của bạn, kết hợp AI sẽ giúp cho việc triển khai của team hiệu quả hơn.
Sau khi đã brainstorm, clarify và chọn hướng đi, bước tiếp theo không nên là “code luôn”. Với những task phức tạp, mình nghĩ nên yêu cầu AI tạo một implementation plan trước.
Nhưng implementation plan tốt không phải là một checklist dài, liệt kê càng nhiều bước càng tốt. Một plan tốt nên làm nổi bật những quyết định có khả năng thay đổi cao nhất.
Ví dụ, nếu task có thể ảnh hưởng tới data model, type interface, permission, UX flow hoặc user-facing behavior, những phần đó nên được đưa lên đầu để review. Còn những việc cơ học như đổi tên file, thêm helper, update import, refactor nhỏ thì có thể để phía sau, vì đó là phần mình có thể tin AI hoặc dev xử lý sau.
Điều này rất giống cách mình review requirement với team. Mình không cần kiểm soát từng dòng code, nhưng cần nắm những quyết định có thể làm lệch sản phẩm. Nếu data model sai, flow sai, permission sai, hoặc expectation của user sai, thì dù implementation có sạch đến đâu cũng vẫn là sai.
Với AI agent, implementation plan còn có một vai trò khác: nó tạo ra một điểm dừng để con người review trước khi AI đi quá xa. Vì khi AI đã bắt đầu sửa nhiều file, tạo nhiều logic, refactor nhiều chỗ, việc quay lại sẽ khó hơn. Một plan rõ ràng giúp mình bắt lỗi khi chi phí sửa còn thấp.
5. Capture the Decisions That Matter
Đây là kinh nghiệm khi mình build một số product và feature, dù chuẩn bị kỹ đến đâu, implementation thật luôn có bất ngờ. Codebase có thể có pattern cũ, API có thể trả data khác với kỳ vọng, một component có thể đang được reuse ở nhiều nơi, hoặc một edge case có thể khiến plan ban đầu không còn phù hợp.
Vấn đề không phải là AI có gặp edge case hay không. Chắc chắn nó sẽ gặp. Vấn đề là khi gặp, nó có ghi lại cho mình biết hay âm thầm tự chọn một hướng rồi đi tiếp.
Đây là một điểm tôi thấy rất thực tế trong bài viết: hãy yêu cầu AI giữ một file implementation notes tạm thời, trong đó ghi lại các quyết định, edge case, deviation so với plan, và lý do chọn hướng xử lý.
Cách làm này cũng khá đơn giản, sau khi bạn đã có implementation plan rồi, bạn hãy thiết lập một rule vào file CLAUDE.md với yêu cầu như trên, điều này sẽ giúp mỗi session khi AI thực hiện, nó luôn biết để tuân thủ theo rule, highly recommend các bạn sử dụng repo này của Andrej Karpathy để tích hợp vào trong quá trình implement: https://github.com/multica-ai/andrej-karpathy-skills/tree/main
Điều này đặc biệt hữu ích khi review một thay đổi lớn. Nếu chỉ đọc diff, mình thấy code thay đổi, nhưng không phải lúc nào cũng hiểu vì sao nó thay đổi như vậy. Implementation notes giúp mình nhìn thấy đường đi của AI: nó đã gặp gì, đã giả định gì, đã chọn gì, và có chỗ nào cần con người review lại không.
Trong workflow thực tế, đây cũng là một cách giảm rủi ro khi dùng AI coding agent. Mình không chỉ nhận output cuối cùng, mà còn nhận lại cách agent suy nghĩ và xử lý ở mức có thể kiểm tra được. Không cần AI trình bày chain-of-thought chi tiết, nhưng cần nó ghi lại decision log đủ rõ để reviewer hiểu các lựa chọn quan trọng.
6. Understanding Before Approving
Một điểm nữa mình rất đồng ý: sau khi AI implement xong, đọc diff là chưa đủ.
Diff cho mình biết file nào thay đổi, function nào được thêm, logic nào được sửa. Nhưng diff không luôn cho mình biết behavior thực tế của sản phẩm đã thay đổi như thế nào. Đặc biệt trong những hệ thống có nhiều code path cũ, nhiều permission, nhiều role, nhiều trạng thái dữ liệu, một thay đổi nhỏ trong code có thể tạo ra tác động khá rộng.
Vì vậy, sau implementation, mình thích yêu cầu AI tạo một explainer: thay đổi này giải quyết vấn đề gì, user sẽ thấy gì khác, flow hoạt động như thế nào, edge case nào đã được xử lý, decision nào cần reviewer chú ý, và còn rủi ro nào chưa chắc chắn.
Nếu cần thuyết phục stakeholder, explainer đó có thể trở thành một pitch. Nếu cần review với dev, nó có thể trở thành technical note. Nếu cần bàn với QA, nó có thể trở thành testing guide. Nếu cần tự kiểm tra lại hiểu biết của mình, có thể yêu cầu AI tạo quiz.
Nghe quiz có vẻ hơi lạ, nhưng mình thấy ý này rất hay. Sau một session dài với AI, đôi khi AI làm được nhiều hơn mình nghĩ. Nếu mình không thật sự hiểu thay đổi, việc merge hoặc approve chỉ dựa trên niềm tin là khá nguy hiểm. Một bài quiz nhỏ buộc mình kiểm tra lại: mình có hiểu flow không, có hiểu edge case không, có hiểu trade-off không, có biết phần nào chưa chắc chắn không.
Bạn có thể tham khảo cách làm này của Suzanne trong team Anthropic, cách cô ấy dùng nó để explain lại tất cả những thay đổi do AI tạo ra, cá nhân mình rất thích cách approach này, mình còn tự build nó lại thành 1 skill để dành sau khi mình implement một task dài, và sử dụng nó để giúp mình hiểu rõ hơn những gì bên trong feature được tạo ra.
Ở góc độ PM, điều này cũng tương tự việc không chỉ hỏi “dev xong chưa”, mà phải hỏi “behavior cuối cùng là gì, user sẽ trải nghiệm như thế nào, còn case nào chưa cover, QA cần test gì”. AI có thể giúp mình tạo ra lớp giải thích đó rất nhanh, nhưng mình vẫn phải là người chịu trách nhiệm hiểu nó.
7. Managing Ambiguity Is the New Skill
Điểm thú vị là khi AI còn yếu, chúng ta thường tập trung vào giới hạn của AI. Nó viết code sai, hiểu sai prompt, không theo instruction, hoặc không đủ context. Nhưng khi model ngày càng mạnh, một phần giới hạn bắt đầu chuyển ngược về phía con người.
Nếu mình không biết mình muốn gì, AI sẽ đoán.
Nếu mình không biết điều gì chưa rõ, AI sẽ lấp khoảng trống bằng giả định.
Nếu mình không biết thế nào là tốt, AI có thể tạo ra một thứ trông ổn nhưng không thật sự đúng.
Điều này không làm AI kém hữu ích hơn. Ngược lại, nó khiến vai trò của con người trở nên quan trọng hơn, nhưng theo một cách khác. Thay vì chỉ trực tiếp làm mọi thứ, chúng ta cần biết cách đặt giới hạn, tìm điểm mù, phản ứng với prototype, review decision, và kiểm tra kết quả.
Mình nghĩ đây là một kỹ năng rất gần với product thinking. Một PM giỏi không chỉ viết ticket, mà phải phát hiện những câu hỏi chưa được hỏi. Một BA giỏi không chỉ ghi requirement, mà phải làm rõ business rule ẩn phía sau requirement. Một engineer giỏi không chỉ code theo spec, mà phải biết spec nào đang thiếu giả định quan trọng.
Làm việc với AI agent cũng vậy. Prompt tốt không phải là một đoạn lệnh thật dài. Prompt tốt là một quá trình giúp cả người và AI cùng thu hẹp khoảng cách giữa bản đồ và vùng đất thật.
8. Changing How I Work With AI
Nếu rút bài viết này thành một thay đổi nhỏ trong workflow của mình, mình nghĩ đó là: trước khi yêu cầu AI làm một task lớn, mình sẽ không bắt đầu bằng câu “hãy làm giúp tôi”. Thay vào đó sẽ bắt đầu bằng câu “hãy giúp tôi tìm những điều tôi chưa biết”.
Với một user story, mình sẽ yêu cầu AI tìm ambiguity trước khi viết AC.
Với một feature phức tạp, mình sẽ yêu cầu AI làm blind spot pass trước khi đề xuất solution.
Với một UI chưa rõ, mình sẽ yêu cầu vài prototype để phản ứng trước khi chốt flow.
Với một implementation dài, mình sẽ yêu cầu plan trước, notes trong lúc làm, và explainer sau khi làm.
Với một thay đổi quan trọng, mình sẽ không chỉ hỏi “code đúng chưa”, mà sẽ hỏi “hãy kiểm tra xem tôi có thật sự hiểu thay đổi này không”.
Tất cả những việc đó nghe có vẻ làm chậm quá trình, nhưng thật ra lại là cách đi nhanh hơn. Vì trong software, thứ làm chậm team nhiều nhất thường không phải là việc gõ code, mà là sửa lại những thứ được build trên một giả định sai.
AI giúp chúng ta làm nhanh hơn, nhưng nếu dùng không cẩn thận, nó cũng giúp chúng ta đi sai nhanh hơn. Vì vậy, kỹ năng quan trọng không chỉ là biết cách tăng tốc, mà là biết khi nào cần dừng lại để làm rõ.
9. From Better Prompts to Better Thinking
Mình thích bài viết này vì nó không thần thánh hóa AI, cũng không hạ thấp vai trò của con người. Nó mô tả một cách làm việc thực tế hơn: AI rất mạnh, nhưng để dùng được sức mạnh đó, mình phải học cách quản trị unknowns.
Trong một thế giới mà AI có thể viết code, tạo prototype, đọc codebase, brainstorm solution và giải thích hệ thống rất nhanh, giá trị của con người sẽ nằm nhiều hơn ở khả năng định hướng: biết vấn đề thật là gì, biết chỗ nào chưa rõ, biết điều gì cần review, biết khi nào nên để AI tiếp tục và khi nào nên yêu cầu nó dừng lại để hỏi thêm.
Có lẽ làm việc tốt với AI không phải là cố viết một prompt hoàn hảo ngay từ đầu. Nó là một cuộc đối thoại liên tục giữa map và territory, giữa điều mình nghĩ mình biết và điều thực tế buộc mình phải học thêm.
Và nếu phải chọn một câu để bắt đầu project tiếp theo với AI, mình nghĩ câu đó sẽ là:
“Trước khi làm, hãy giúp tôi tìm những unknowns của task này.”