# You Can't Prompt the Room: The Last Skill AI Won't Replace Balázs Horváth, VisualLabs | AI Engineer World's Fair 2026 | 15:45 Source: https://www.youtube.com/watch?v=6bmM45jkMDY Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/you-cant-prompt-the-room-the-last-skill-ai-wont-replace Published: 2026-06-29 Tags: agents, product-strategy ## TL;DR - The bottleneck in software development has moved from writing code to deciding what is worth building. - Story maps and well-formed user stories give stakeholders and AI enough context to define useful software. - Teams should measure features reused more than twice instead of counting features shipped. ## Summary Balázs Horváth argues that AI has made implementation cheap while making discovery and decision-making more valuable. VisualLabs generated 21 agent ideas in an internal hackathon, but 17 were abandoned because they lacked data access, a business owner, or measurable value. The four that survived had a reason to exist and are now in production. Horváth recommends returning to analysis practices such as story mapping, business model canvases, and value canvases. A story map lays out the process backbone, then places user stories beneath each stage at a useful level of detail. He also uses four questions to define value: whose problem is being solved, what success looks like, what would make the user refuse the solution, and which decision it changes. His VAD path, Value to Architecture to Design, keeps teams focused on the process and outcome before they design an agent. He measures delivery by reuse rather than feature count. ## Key ideas ### The expensive part of software has moved upstream [00:01](https://www.youtube.com/watch?v=6bmM45jkMDY&t=1s) Horváth says access to code and the ability to build are no longer the bottleneck in the software development life cycle. The harder work is getting stakeholders and decision-makers into the room, spending time with them, and eliciting the requirement behind a request. VisualLabs saw this during an internal hackathon: the team produced about 21 agent ideas, but abandoned 17 because there was no business value, no data access, or no sensible reason to build them. The four surviving ideas had a clear impact and are now running in production. His experience bridging business and IT leads him to put more effort into deciding what to build before asking AI to implement it. ### AI tends to reproduce the common answer [00:02](https://www.youtube.com/watch?v=6bmM45jkMDY&t=2s) Horváth uses the familiar Henry Ford and horse analogy to explain the risk of prompting without analysis. If a team asks AI to improve an existing process, the model is likely to produce a more typical version of what already exists because it is designed to give common answers. The human task is to move from that average answer to something materially better for the business. He describes this as moving from a faster horse to a car. AI can generate code, specifications, and tests, but it cannot decide what a room of stakeholders actually needs or discover an opportunity that nobody has stated precisely. ### Story mapping gives AI and stakeholders a shared structure [04:43](https://www.youtube.com/watch?v=6bmM45jkMDY&t=283s) Horváth presents story mapping as the analysis technique he has found most useful. A support-system map can follow a case through contacting, triaging, resolving, and closing. User stories sit beneath those process stages, while the map stays high enough level to preserve the whole picture. An initial release might include capturing intent, classifying urgency, drafting a grounded answer, and logging the result to a system of record. Other work, such as reading sentiment or suggesting the next action, can remain in the backlog. The map gives stakeholders something concrete to discuss before the team commits to a design or implementation. ### User stories improve both discussion and generated software [06:22](https://www.youtube.com/watch?v=6bmM45jkMDY&t=382s) Horváth recommends writing each story around a persona, a need, and a reason. His example is, "As a support lead, I need to open cases ranked by urgency so that none of the escalations should slip." Acceptance criteria can then provide the basis for test cases. He says AI recognises this familiar pattern, so giving the model structured stories produces better results than a generic instruction. Connecting the stories into a coherent flow supports the later specification and code. The software development life cycle remains broadly similar, but the tools used to describe and prepare the work change because AI can consume this structured context. ### Four questions expose whether an idea has value [07:53](https://www.youtube.com/watch?v=6bmM45jkMDY&t=473s) Horváth asks four questions before building an agent. Whose problem is being solved, and can the team name a direct persona? What does winning look like for that person, including the outcome they need to reach? What would make them refuse the solution, such as an unavailable platform, cumbersome use, or a data-security concern? Would the system change a decision, and which decision would it change? He recommends recording the answers in a Markdown file in the repository so AI can access the context. A request such as "build us an agent that handles support" is too generic to guide a useful result. ### VAD keeps design connected to value and process [09:31](https://www.youtube.com/watch?v=6bmM45jkMDY&t=571s) Horváth describes a thinking path called VAD: Value, Architecture, Design. The team first works out how value is created, what value the customer wants, and how the current process supports it. It then examines the underlying architecture before designing a system around the value and process. This order can also reveal which process changes are needed. Horváth accepts that this resembles established product management and business analysis. He calls it an old skill with new economics: teams have access to similar AI models, so their difference comes from how well they understand the business need and prepare the work. ### Production use matters more than feature velocity [11:01](https://www.youtube.com/watch?v=6bmM45jkMDY&t=661s) Horváth describes shipping features quickly while adoption stays low as a poor pattern. A feature may attract initial trials, logins, or time spent in a system without being used again. He recommends tracking how often an activity is repeated instead of relying on time on site. A demo is also not a live system. If the demo is the deliverable, the team has shown something that looks good without proving that people use it in production. A product requirements document without feedback from real users has the same weakness, because the team has not tested whether the proposed system fits actual work. ### Subject-matter experts should move closer to the customer [12:42](https://www.youtube.com/watch?v=6bmM45jkMDY&t=762s) Horváth says teams should move their most experienced people upstream, toward customers, business problems, and decisions about what to build. He is not asking every specialist to become a functional consultant or product manager. He wants subject-matter experts involved in decisions because they know what worked and failed in the past. He recommends auditing current measurements and replacing the number of features shipped with the number of shipped features used more than twice. Before building, teams should run a mapping session, using a story map, business model canvas, or another method that shows where value lives. ## Notable quotes - "You can prompt your AI. You can't prompt the room." (00:28) - "Now the real bottleneck is getting your people, your stakeholders, your decision-makers into the room." (02:36) - "It's old skill, but new economics." (10:40) - "The demo system is not a live system." (11:48) - "We can build the right thing and not just the next thing." (15:31) ## Tools & references mentioned - VisualLabs - Henry Ford - Microsoft Partner - story mapping - business model canvas - value canvas - VAD - Markdown ## Who should watch - You are building AI agents quickly but cannot explain who owns the problem or how success will be measured. - Your team has a backlog of attractive demos and needs a way to test whether users will return to them. - You work in product, business analysis, consulting, or engineering and want to give AI better requirements before it writes the implementation.