# You Can't Prompt the Room: The Last Skill AI Won't Replace

Balázs Horváth · VisualLabs · AI Engineer World's Fair 2026: Online Track

> Khi build đã rẻ, phần đắt là quyết định build gì: story mapping, user story, bốn câu hỏi về value và lối tư duy VAD trước khi giao việc cho agent.

Topics: Workflow, Agents, Careers

Canonical: https://homus.dev/talks/you-cant-prompt-the-room-the-last-skill-ai-wont-replace

## 1. Thứ cuối cùng AI sẽ không lấy đi của người làm phần mềm

Balázs Horváth mở đầu bằng câu hỏi của cả talk: trong nghề phần mềm, đâu là thứ cuối cùng AI sẽ lấy đi khỏi con người? Câu trả lời của anh xuất phát từ một quan sát đơn giản. Khi viết code không còn là bottleneck nữa, việc thật sự quan trọng là tìm ra mình nên build cái gì. Và chuyện đó rốt cuộc quy về kỹ năng làm việc với con người, khả năng "work the room": ngồi cùng những người trong phòng họp, hiểu họ, dẫn dắt cuộc thảo luận để rút ra điều họ thật sự cần.

Tên talk chính là cách anh nói gọn ý này: bạn prompt được AI của mình, nhưng bạn không prompt được cả một căn phòng đầy người ("you can't prompt a room").

![Slide tiêu đề You can't prompt the room](https://homus.dev/photos/6bmM45jkMDY-0024.jpg)

Slide mở đầu "You can't prompt the room." với dòng phụ "Cheap to build. Expensive to decide.": build giờ đã rẻ, còn quyết định build gì mới là phần đắt. Balázs trình bày từ xa, hình anh ở bên phải slide.

## 2. Hackathon nội bộ: 21 ý tưởng agent, 17 bị bỏ

Ví dụ đầu tiên đến từ chính công ty anh. Đầu năm nay, VisualLabs tổ chức một hackathon nội bộ. Cả đội đưa ra khoảng 21 ý tưởng agent, và 17 trong số đó bị bỏ giữa chừng. Lý do theo lời anh kể: chúng thật ra không tạo ra business value nào. Có cái thì đội không có quyền truy cập dữ liệu cần thiết, có cái thì đơn giản là build ra cũng chẳng có ý nghĩa gì.

Bốn ý tưởng còn lại mới là những cái tạo ra tác động rất lớn lên cách VisualLabs làm việc ngày nay. Với Balázs, đây là một ví dụ rất rõ cho việc phải chắc chắn mình đang build đúng thứ đáng build, chứ không phải build tất cả những gì build được.

![Slide 17 of 21 agents abandoned](https://homus.dev/photos/6bmM45jkMDY-0056.jpg)

Slide "Where this starts": một lưới 21 ô, 17 ô gạch chéo và 4 ô sáng màu, cạnh con số 17 lớn "of 21 agents abandoned". Dòng chú thích trên slide ghi "On data access. None of them reached the model.", tức theo slide thì các ý tưởng này dừng lại ở khâu truy cập dữ liệu và không cái nào đi tới được bước đưa vào model. Phần mô tả talk trên YouTube còn nói thêm rằng 4 agent sống sót hiện đang chạy production.

## 3. Mười ba năm làm cầu nối giữa business và developer

Balázs kể lại con đường của mình. Suốt mười ba năm sự nghiệp, anh luôn là người đứng giữa, làm cầu nối giữa business, bộ phận IT và developer. Anh bắt đầu bằng việc test các functional design và specification, rồi chuyển sang tự viết chúng. Sau đó, trong vai trò functional consultant, anh làm việc với các chương trình ERP và CRM lớn ở Mỹ và Anh, trước khi thành lập VisualLabs.

Ở VisualLabs, việc anh làm về cơ bản là đào tạo đội của mình cách khai thác yêu cầu (elicit requirements) sao cho biến được chúng thành specification tốt: cho developer để build, cho consultant để cấu hình hệ thống, và gần đây nhất là cho AI để build.

Điều anh thấy gần như không thay đổi qua bao nhiêu năm là cách mình tương tác với khách hàng. Cách mình tương tác với hệ thống, với AI thì đang thay đổi rất nhiều, và đó là câu chuyện lớn lúc này. Nhưng nếu bạn đọc được không khí trong phòng (read the room) và khai thác được đúng requirement, bạn sẽ build ra phần mềm có giá trị hơn.

![Slide The bridge: I've always prompted the developers](https://homus.dev/photos/6bmM45jkMDY-0144.jpg)

Slide "The bridge": "I've always prompted the developers. The room was always the hard part." Ba nhãn bên dưới tóm lý lịch của anh: 13 năm với ERP và CRM; Mỹ, Anh và Hungary; VisualLabs, một Microsoft partner. Ý của tiêu đề: từ trước khi có AI, anh đã luôn "prompt" developer bằng specification, còn phần khó nhất vẫn luôn là căn phòng.

## 4. Bottleneck đã dời chỗ: từ viết code sang quyết định build gì

Theo Balázs, chuyển dịch lớn của hai, ba năm qua là: có được code và có khả năng build không còn là bottleneck của software development lifecycle nữa. Bottleneck thật bây giờ là đưa được đúng người vào phòng: các stakeholder, những người ra quyết định. Là có được quyền tiếp cận họ, có thời gian ngồi với họ, và khai thác được requirement từ họ.

Nói cách khác, việc khó nhất bây giờ là tìm ra cái gì nên được build. Anh nhắc lại câu chủ đề: bạn prompt được code của mình, prompt được AI, thậm chí prompt được cả bản specification, nhưng bạn không prompt được căn phòng của mình.

![Slide The bottleneck moved](https://homus.dev/photos/6bmM45jkMDY-0240.jpg)

Slide "The shift: The bottleneck moved." Trước đây bottleneck là "getting the code built" (làm sao cho code được viết xong), mũi tên chỉ sang bây giờ: "deciding what to build" (quyết định build cái gì).

## 5. Hỏi model nên build gì, bạn nhận về một con ngựa nhanh hơn

Để giải thích vì sao model không tự làm được phần việc này, Balázs mượn câu chuyện quen thuộc gắn với Henry Ford. Nếu Ford hỏi khách hàng của mình họ cần gì, họ sẽ nói họ cần những con ngựa nhanh hơn. Nhưng thực tế ông build ra chiếc ô tô, và thành công rực rỡ với nó.

Những gì một model làm được, theo anh, rất giống câu trả lời "ngựa nhanh hơn" kia. Nếu bạn chỉ dùng AI để làm cho mọi thứ tốt hơn một chút, khả năng cao là bạn đang tái tạo lại những gì đã tồn tại, vì AI về bản chất được xây dựng để đưa ra câu trả lời phổ biến nhất. Việc của chúng ta là kéo AI ra khỏi mức trung bình đó, hướng về thứ thật sự tốt hơn cho mình, để không dừng ở một con ngựa nhanh hơn mà làm ra được chiếc ô tô, một bước nhảy lớn hơn hẳn so với những gì đang có.

![Slide Ask it what to build. You get a faster horse.](https://homus.dev/photos/6bmM45jkMDY-0336.jpg)

Slide "Why a model can't do it: Ask it what to build. You get a faster horse." Chuỗi ba bước trên slide: "what already exists" (những gì đã có) dẫn tới "the average" (mức trung bình) rồi tới "a faster horse". Góc slide ghi "after Henry Ford".

Một ghi chú nhỏ: câu "faster horses" thường được gán cho Henry Ford, nhưng các nhà nghiên cứu trích dẫn chưa tìm được bằng chứng ông thật sự nói câu này (xem [Quote Investigator](https://quoteinvestigator.com/2011/07/28/ford-faster-horse/)). Dù vậy nó vẫn là cách nói phổ biến cho ý: khách hàng mô tả giải pháp theo những gì họ đã biết.

## 6. Bộ đồ nghề của analyst giờ là việc của người senior

Balázs gọi đây là một thế giới thú vị: viết code tốt không còn là kỹ năng quan trọng nhất. Kỹ năng thật bây giờ là trở thành analyst, dùng được bộ đồ nghề của analyst (analyst toolkit). Đó là những thứ như story mapping, [business model canvas](https://www.strategyzer.com/library/the-business-model-canvas), value canvas ([value proposition canvas](https://www.strategyzer.com/library/the-value-proposition-canvas)), những công cụ "cũ mà tốt" mà các functional consultant, business analyst, hay người làm design thinking đã quá quen tay.

Trong số đó, anh chọn đi sâu vào story mapping, vì đây là bộ kỹ năng anh thấy có giá trị nhất.

![Slide The analyst's toolkit is senior work now](https://homus.dev/photos/6bmM45jkMDY-0424.jpg)

Slide "The craft comes back: The analyst's toolkit is senior work now." Dòng phụ: "Story mapping is one example among several frameworks", story mapping chỉ là một ví dụ trong nhiều framework.

## 7. Story map cho một hệ thống support: backbone, release 1 và backlog

Một story map bắt đầu bằng backbone: chuỗi các bước lớn trong quy trình. Khi đã có backbone và hiểu ở mỗi bước khách hàng, người dùng của bạn đang làm gì, bạn sẽ thấy cái gì giúp họ tiến lên được trong quy trình của mình.

Ví dụ của anh là story map cho một hệ thống support, với backbone gồm bốn bước: tiếp nhận liên hệ (contact), phân loại (triage), giải quyết hoặc chuyển tiếp (resolve or route), và đóng case (close). Story map giúp bạn hiểu từng giai đoạn của quy trình, rồi ghi các user story nằm bên dưới mỗi giai đoạn. Nó được cố ý giữ ở mức khá cao để bạn thấy bức tranh tổng thể.

![Story map hệ thống support với bốn cột Contact, Triage, Resolve or route, Close](https://homus.dev/photos/6bmM45jkMDY-0544.jpg)

"The story map": bốn ô backbone Contact, Triage, Resolve or route, Close. Hàng "Release 1" bên dưới là Capture intent, Classify urgency, Draft a grounded answer, Log to system of record. Hàng "Later" là Read sentiment, Route to a team, Suggest next action, Check satisfaction.

Từ bức tranh đó, bạn quyết định release 1 sẽ build gì. Ở đây là bốn việc: nắm được ý định của người liên hệ (capture intent), phân loại mức độ khẩn (classify urgency), soạn một câu trả lời có căn cứ (draft a grounded answer), và ghi lại vào system of record. Về cơ bản đó là MVP của bạn: những thứ đầu tiên muốn build, và cũng là bốn user story đầu tiên.

Bên dưới là lớp user story thứ hai: đọc sentiment, route tới đúng team, gợi ý bước tiếp theo (suggest next action), chat, kiểm tra mức hài lòng (check satisfaction), và cứ thế tiếp. Những cái này nằm trong backlog.

## 8. Một user story: persona, nhu cầu, lý do, và vì sao AI hiểu dạng này

Theo Balázs, cách để có kết quả agentic thật tốt là tập trung vào chính các user story này, và dùng chúng làm phương tiện để mở ra thảo luận với stakeholder, với phía business, rồi cùng nhau làm rõ mỗi user story thật ra nói về điều gì.

Anh lấy user story thứ hai làm ví dụ: "As a support lead, I need open cases ranked by urgency so that none of the escalations slip." Tức là: với vai trò trưởng nhóm support, tôi cần các case đang mở được xếp theo mức độ khẩn, để không một escalation nào bị lọt.

![Slide One story: As a support lead, I need open cases ranked by urgency so that none of the escalations slip](https://homus.dev/photos/6bmM45jkMDY-0704.jpg)

Slide "One story" tô màu ba phần của user story: "As a support lead" là persona (vấn đề của ai), "I need open cases ranked by urgency" là what (nhu cầu), "so that none of the escalations slip" là why (giá trị).

Anh khuyên viết mọi user story theo đúng khuôn này, vì AI rất giỏi nhận dạng pattern, và nó thật sự đã được huấn luyện trên cấu trúc user story, một khuôn mẫu rất nổi tiếng và được dùng rộng rãi. Quay về thứ AI đã quen thì bạn sẽ có kết quả tốt hơn.

Mỗi user story gồm những phần quen thuộc: persona, cái gì (nhu cầu thật), và tại sao. Đóng gói các phần này lại và đưa cho AI, tất nhiên kèm acceptance criteria để từ đó suy ra test case, bạn sẽ có một thiết lập tốt và kết quả rất tốt.

```
As a
, I need  so that .

As a support lead, I need open cases ranked by urgency so that none of the escalations slip.
```

Rồi nếu bạn nối các user story với nhau thành chuỗi ("daisy chain"), bạn có được một hệ thống mạch lạc, từ đó viết ra specification và cuối cùng là code. Vì vậy, theo anh, software development lifecycle không thay đổi nhiều vì AI. Thứ thay đổi là bộ công cụ mình dùng.

Nối các user story thành chuỗi để có một hệ thống mạch lạc, rồi viết specification và code từ đó. Mỗi story mang persona, nhu cầu, lý do, cùng acceptance criteria để suy ra test case.

## 9. Bốn câu hỏi trước khi agent bắt đầu

Khi làm việc với hệ thống và nghĩ xem mình muốn build gì, Balázs luôn đặt ra bốn câu hỏi.

![Slide Before the agents start với bốn câu hỏi](https://homus.dev/photos/6bmM45jkMDY-0832.jpg)

Slide "Before the agents start": 1. Whose problem is this? 2. What does winning look like for them? 3. What would make them refuse to use it? 4. What decision does it change?

**Một: đây là vấn đề của ai?** Mình đang thật sự giải quyết vấn đề cho ai? Để có thể gọi tên một người cụ thể, một persona cụ thể, và định lượng rõ ràng.

**Hai: thắng với họ trông như thế nào?** Khi nào họ thật sự thành công? Họ có đạt được đúng kết quả không? Mình có giúp họ đạt kết quả đó một cách nhanh, trơn tru hay an toàn không?

**Ba: điều gì khiến họ từ chối dùng nó?** Có thể là nó không có trên platform họ đang dùng. Có thể nó cồng kềnh, khó dùng. Có thể vướng chuyện bảo mật dữ liệu, nên họ sẽ không dùng.

**Bốn: nó có thay đổi một quyết định không?** Lý tưởng nhất, mình muốn tác động lên cách một người ra quyết định, và nghiêng họ về phía những quyết định tốt hơn. Vậy nó có thay đổi một quyết định không, và đó là quyết định nào?

Khi trả lời được bốn câu này, bạn sẽ nhận được phản hồi tốt hơn từ AI. Anh khuyên ghi tất cả lại trong một file Markdown "cũ mà tốt" ngay trong repository để AI truy cập được; nó sẽ lấy được nhiều context hơn hẳn từ đó.

```
1. Whose problem is this?
2. What does winning look like for them?
3. What would make them refuse to use it?
4. What decision does it change?
```

## 10. VAD: Value, Architecture, Design

Nếu bạn chỉ đưa ra một yêu cầu chung chung kiểu "build us an agent that handles support" (build cho chúng tôi một agent xử lý support), bạn sẽ không nhận được câu trả lời mình muốn.

Cách đội của Balázs luôn làm là đi từ value. Hiểu value được tạo ra thế nào, cái gì cấu thành value, quy trình hiện đang chạy ra sao, kiến trúc nào nằm bên dưới để đỡ quy trình đó, rồi mới bắt đầu phần design thật sự. Họ gọi lối tư duy này là VAD: Value → Architecture → Design, và đây là con đường họ luôn muốn đi qua.

Nghĩa là luôn giữ value trong đầu. Mình tạo ra value thế nào? Value mình đang tạo ra là gì? Khách hàng đang tìm kiếm value gì? Quy trình nào bên dưới đỡ cho nó, và mình có thể design một hệ thống xung quanh ra sao để hỗ trợ tốt nhất cho cả value lẫn quy trình, cùng những thay đổi quy trình cần làm trên đường đi.

![Slide Build us an agent that handles support, Value Process Stories, VAD](https://homus.dev/photos/6bmM45jkMDY-0952.jpg)

Slide "One problem, all the way through" lấy đúng yêu cầu chung chung "Build us an agent that handles support." làm điểm xuất phát. Trên slide ghi ba bước Value ("frame the real need", đóng khung nhu cầu thật), Process ("how the work actually flows", công việc thật sự chạy thế nào) và Stories ("precise, sequenced, shared", chính xác, có thứ tự, được chia sẻ), cùng dòng "We call the shape VAD - Value » Architecture » Design".

## 11. "Đây chẳng phải là product management sao?"

Balázs đoán trước câu hỏi của khán giả: "Đây chẳng phải là product management cũ thôi sao?" Ở một mức độ nào đó, đúng vậy. Đây là một kỹ năng cũ, một cái nghề cũ, nhưng rất đáng để học lại. Lý do: nó đang trở thành moat (lợi thế phòng thủ), nếu có thể gọi như vậy, quyết định ai khai thác được đúng requirement và ai build được phần mềm tốt hơn.

Tất cả chúng ta đều có trong tay cùng một bộ công cụ, nên khác biệt sẽ nằm ở chỗ ai hiểu nhu cầu của business tốt hơn. Phần viết code thì ai cũng có thể giao cho model mới nhất, mạnh nhất. Vậy là kỹ năng cũ, nhưng kinh tế học mới ("old skill, new economics"), và là một chuyển dịch thật sự về phía bộ đồ nghề của analyst.

![Slide Isn't this just product management? Old skill. New economics.](https://homus.dev/photos/6bmM45jkMDY-1040.jpg)

Slide "The question you're already asking": "Isn't this just product management?" và câu trả lời ngắn "Old skill. New economics."

## 12. Build sai thứ một cách thật nhanh trông ra sao

Tiếp theo, Balázs mô tả build sai thứ trông như thế nào, qua một loạt anti-pattern.

![Slide Building the wrong thing fast với bốn anti-pattern](https://homus.dev/photos/6bmM45jkMDY-1136.jpg)

Slide "Building the wrong thing fast" với bốn ô gạch đỏ: "Velocity up, adoption flat" (tốc độ tăng, mức sử dụng đứng yên), "Never used a second time" (không ai dùng lần hai), "The demo is the deliverable" (demo là sản phẩm bàn giao), "A PRD no real user tested" (một PRD chưa người dùng thật nào thử).

**Velocity tăng, adoption không tăng.** Bạn ship tính năng mới liên tục như điên, nhưng adoption kém, người ta hầu như không dùng. Đó là một pattern rất tệ, và là thứ bạn cần xử lý.

**Không ai dùng lần thứ hai.** Người ta thử tính năng mới, đăng nhập vào hệ thống mới, chỗ mình vừa vibe code ra thứ mới nhất, điên rồ nhất, nhưng họ không quay lại dùng nữa. Vì vậy đừng nhìn vào thời gian sử dụng hay thời gian ở lại trên trang. Hãy nhìn vào tần suất của một hoạt động cụ thể.

**Demo là sản phẩm bàn giao.** Đây là một anti-pattern khác. Mình muốn chắc chắn người ta đưa được thứ đó vào production. Làm demo thì rất nhanh và trông rất đẹp, nhưng người ta không thật sự dùng. Một hệ thống demo không phải là một hệ thống live.

**PRD chưa được người dùng thật thử.** Nếu một PRD (product requirements document) chưa được test với người dùng thật, nếu bạn không thu được feedback đúng nghĩa từ một người dùng thật, khả năng cao nó sẽ không đi tới được môi trường live, và người ta sẽ không dùng nó.

## 13. Đưa người giỏi nhất lên thượng nguồn

Điều lớn nhất ở đây, theo Balázs, là mọi thứ cần dời lên thượng nguồn (upstream). Trước cơn bùng nổ AI, chúng ta để những người giỏi nhất của mình viết code. Bây giờ cần chuyển những người giỏi nhất đó về phía khách hàng, về phía các vấn đề của business, và dành nhiều thời gian hơn để quyết định build cái gì. Vì đó mới là phần đắt. Còn build thì thật ra đã trở nên rất rẻ.

![Slide Point your best judgement upstream](https://homus.dev/photos/6bmM45jkMDY-1232.jpg)

Slide "So what: Point your best judgement upstream." Hai hàng: "Deciding what to build", ghi "expensive now" (giờ là phần đắt), và "Building it", ghi "cheap now" (giờ là phần rẻ).

## 14. Làm gì từ sáng thứ Hai

Balázs đưa ra vài việc bạn có thể bắt đầu ngay từ sáng thứ Hai, hoặc ngay ngày mai.

![Slide Monday morning với ba việc](https://homus.dev/photos/6bmM45jkMDY-1352.jpg)

Slide "Monday morning" với ba việc: "Audit the wrong-thing rate" (features shipped last quarter, used more than twice), "Move one senior person upstream" (from build supervision into discovery), "Run one mapping session" (before the next build starts).

**Audit tỷ lệ build sai.** Bắt đầu tìm xem mình đang đo sai những thứ gì, rồi chỉnh lại cách đo, cách dùng thời gian, và thứ mình đang tìm kiếm. Con số "bao nhiêu tính năng đã ship trong quý trước" nên bị loại bỏ. Thay vào đó, hãy nhìn vào số tính năng mình ship mà thật sự được dùng nhiều hơn hai lần. Đó sẽ là một chuyển dịch tốt trong KPI, trong các metric của bạn.

**Đưa một người senior lên thượng nguồn.** Chuyển những subject matter expert thật sự sang vai trò gần khách hàng hơn, nơi họ có tác động thật lên việc cái gì được build. Trên slide, ý này được ghi là chuyển từ giám sát việc build sang discovery. Anh nói rõ, anh không bảo ai cũng phải trở thành functional consultant, product manager hay product owner. Ý anh là hãy kéo họ vào việc ra quyết định, vì họ là những người có nhiều kinh nghiệm nhất về cái gì đã chạy được trong quá khứ và cái gì không. Đảm bảo kinh nghiệm đó được đưa vào quyết định build cái gì là một khía cạnh cực kỳ quan trọng.

**Chạy một buổi mapping trước khi build.** Đây là việc anh vẫn làm, và khuyên mọi người bắt đầu làm. Hãy tạo một user story map, một business model canvas, hay bất kỳ kiểu mapping nào làm nổi bật value nằm ở đâu, để chắc chắn bạn hiểu mình tạo ra value như thế nào.

## 15. Build the right thing, not the next thing

Balázs khép lại: những gì anh trình bày phần lớn là nhiều thứ cũ được khâu lại với nhau, nhưng chúng thật sự tạo ra khác biệt. Lời mời của anh rất cụ thể: nếu bạn có một use case tốt muốn vibe code, hãy thử build nó một lần có user story và một lần không có user story, rồi so sánh khác biệt trong kết quả.

Khi anh tự làm thử điều này, đó là một chuyển biến lớn với chính anh, kiểu "Holy cow, mình vẫn cần đưa user story vào quá trình phát triển của mình." Theo cách đó, chúng ta build được thứ đúng, chứ không chỉ thứ tiếp theo.

Thí nghiệm Balázs mời mọi người làm: cùng một use case, vibe code một lần có user story và một lần không, rồi đặt hai kết quả cạnh nhau.

Slide cuối nhắc lại thông điệp "Build the right thing. Not the next thing.", kèm mã QR để kết nối với anh trên LinkedIn. Anh rất sẵn lòng trò chuyện thêm, và cảm ơn mọi người đã theo dõi.

## Nguồn và link

- [Trang talk chính thức trên ai.engineer](https://ai.engineer/talks/6bmM45jkMDY) · [Video gốc](https://www.youtube.com/watch?v=6bmM45jkMDY)

- VisualLabs, Microsoft Solutions Partner do Balázs thành lập: [visuallabs.com](https://www.visuallabs.com/)

- Balázs Horváth trên LinkedIn: linkedin.com/in/balazshorvathd365

- User story mapping, kỹ thuật do Jeff Patton phổ biến: [jpattonassociates.com](https://jpattonassociates.com/user-story-mapping-presentation/)

- Business Model Canvas: [strategyzer.com](https://www.strategyzer.com/library/the-business-model-canvas) · Value Proposition Canvas: [strategyzer.com](https://www.strategyzer.com/library/the-value-proposition-canvas)

- Nguồn gốc câu "faster horses" gán cho Henry Ford: [quoteinvestigator.com](https://quoteinvestigator.com/2011/07/28/ford-faster-horse/)