You Can't Prompt the Room: The Last Skill AI Won't Replace - Balázs Horváth, VisualLabs

At-a-Glance

• Verdict: Watch fully
• Core thesis: As AI commoditizes code-writing, the bottleneck shifts to requirements elicitation and stakeholder communication—'you can't prompt the room'—making analyst/product skills (story mapping, value architecture design) the last irreplaceable human capability.
• Why it matters: Ken's agent systems and AI ops teams risk building the wrong thing fast unless they master upstream problem definition, user story discipline, and customer-facing requirements work before prompting AI to generate code.
• Best use: Use as a playbook for reorienting Ken's smartest engineers upstream into requirements/product roles and adopting story mapping + VAD frameworks to ensure AI builds the right thing, not just the next thing.

Executive Summary

Balázs Horváth, founder of VisualLabs and a 13-year veteran of bridging business and IT, argues that AI has eliminated code-writing as the bottleneck in software development. The new constraint is figuring out what to build—a human skill rooted in stakeholder communication, requirements elicitation, and product sense. He frames this as 'you can't prompt the room': AI can generate code from prompts, but it cannot replace face-to-face discovery sessions, negotiation with decision-makers, or reading the room to uncover latent needs. Horváth's internal hackathon at VisualLabs produced 21 agent ideas; 17 were abandoned because they lacked business value or data access—only 4 had real impact. This ratio underscores that access to AI tooling does not guarantee valuable output; the filter is rigorous requirements work.

Horváth champions classic analyst techniques—user story mapping, business model canvas, value canvas—as the new core skill set. He walks through story mapping for a support system (contact → triage → resolve → close) and shows how capturing user stories ('As a support lead, I need cases triaged by urgency so that no escalations slip') gives AI the structured input it was trained on, yielding better code. He emphasizes the persona-need-why triad and acceptance criteria, and advocates daisy-chaining user stories into a coherent spec before prompting AI. His 'VAD' framework (Value → Architecture → Design) ensures teams start from business value, map the process, understand underlying systems, and only then design—avoiding the trap of building 'faster horses' when the market needs a car.

Horváth identifies anti-patterns: high feature velocity but low adoption, one-time usage without repeat engagement, 'demo is the deliverable' syndrome, and PRs that skip real user testing. He urges leaders to audit KPIs (stop counting features shipped; count features used more than twice), move subject-matter experts upstream to customer-facing roles, and run mapping sessions before every build. He frames this as 'old skill, new economics': product management and business analysis are not new, but AI's commoditization of coding has made them the decisive competitive advantage. The talk closes with a challenge to compare AI output with and without rigorous user story input, a test Horváth claims was his own 'holy cow' moment that cemented story-driven development in his practice.

Key Takeaways

• Claim: AI commoditizes code-writing, so the real bottleneck is now 'getting people into the room' and eliciting requirements—'you can't prompt the room.' | Evidence: Horváth's hackathon: 21 agent ideas, 17 abandoned for lack of business value or data access, only 4 had impact. He states 'getting access to code is no longer the bottleneck… the real bottleneck is getting your stakeholders into the room and being able to elicit the requirement.' | Caveat: Assumes sufficient AI maturity and tooling access; in orgs without advanced AI infra, code-writing may still bottleneck. Also assumes stakeholders are available and willing to engage, which is not always true. | Implication: Ken's teams should invest in hiring/training product analysts and requirements specialists, not just more engineers. Sprint planning should allocate explicit time for stakeholder interviews and requirements sessions before AI generates any code. | Timestamp: timestamp unavailable
• Claim: User story structure (persona, need, why) + acceptance criteria is the optimal input format for AI code generation because AI was trained on these well-known patterns. | Evidence: Horváth: 'AI is really good at pattern recognition and it was actually trained on the user story structure because it's a very well known and well used setup. So if you go back to something familiar to AI, it will get you better results.' Example: 'As a support lead, I need to open cases right by urgency so that none of the escalations slip.' | Caveat: No quantitative comparison provided (e.g., code quality, test pass rate, or iteration count with vs. without user stories). Speaker relies on anecdotal experience and does not specify which AI models or prompt frameworks were tested. | Implication: Ken should standardize user story templates across agent/AI projects and require acceptance criteria in markdown files tracked in repos. Run a controlled test: build one feature with full user stories, one without, and measure code correctness, edge-case coverage, and iteration cycles. | Timestamp: timestamp unavailable
• Claim: Story mapping (backbone steps + user stories beneath) and the VAD framework (Value → Architecture → Design) prevent 'faster horses' syndrome and ensure AI builds transformative solutions, not just incremental improvements. | Evidence: Horváth references Henry Ford: 'If he'd asked customers what they needed, they would have said more horses. But in reality, you build a car.' He shows a story map for support (contact → triage → resolve → close) with MVP stories (capture intent, classify urgency, draft answer, log to system) and backlog stories (read sentiment, suggest next action, check satisfaction). | Caveat: Story mapping is time-intensive and requires skilled facilitators; Horváth does not address how to scale this across multiple teams or rapid-iteration contexts. VAD is conceptually sound but lacks a detailed implementation guide or failure modes. | Implication: Ken should pilot story mapping workshops for high-stakes agent projects and train product leads in facilitation. Embed VAD checkpoints in sprint 0 and gate AI build kickoff on completed value/architecture analysis to avoid building the wrong thing fast. | Timestamp: timestamp unavailable
• Claim: Anti-pattern metrics to eliminate: feature velocity, time-on-site. Replace with 'features used more than twice' and frequency of repeat activity. | Evidence: Horváth: 'If you've got velocity of shipping new features crazy, but the adoption is not good… that's a very poor pattern. Don't look at time of usage. Much rather look at the frequency of a certain activity. If the demo is the deliverable… a demo system is not a live system.' | Caveat: Frequency of use can be gamed (e.g., automated pings) and may not capture deep value for infrequent but critical tasks (e.g., annual compliance workflows). No threshold given for 'more than twice' or time window. | Implication: Ken's product analytics should instrument repeat-usage cohorts (7-day, 30-day) and flag features below a threshold for sunsetting or redesign. Shift eng team OKRs from story points shipped to 'features achieving >10% monthly active usage within 60 days of launch.' | Timestamp: timestamp unavailable
• Claim: Move your smartest people upstream to customer-facing roles and involve them in 'what to build' decisions, not just 'how to build.' | Evidence: Horváth: 'Before the AI boom, we had our smartest people writing our code, but now we need to be shifting our smartest people towards our customers, towards the business problems… deciding what to build is the expensive part. Building it has become very cheap.' | Caveat: Senior engineers may resist product/analyst roles due to career identity or comp structures that reward technical IC work. Horváth does not address transition plans, training, or how to retain deep technical expertise if top talent shifts entirely upstream. | Implication: Ken should create hybrid 'technical product lead' roles with eng+product responsibilities and pair senior engineers with customers for quarterly discovery sprints. Comp bands and promotion criteria must reward requirements quality and customer impact, not just code contributions. | Timestamp: timestamp unavailable

Detailed Brief

The Bottleneck Has Shifted: From Code to Requirements

• Claims: AI has commoditized code-writing; the new constraint is stakeholder access and requirements elicitation.; Internal VisualLabs hackathon: 21 agent ideas, 17 abandoned due to lack of business value or data access, 4 had real impact.; Horváth's 13-year career as a bridge between business and IT (functional designs, ERP/CRM consulting, founding VisualLabs) informs his view that customer interaction has not changed, but how we build has.
• Evidence: Horváth: 'Getting access to code and being able to build is no longer the bottleneck… the real bottleneck is getting your people, your stakeholders, your decision makers into the room.'; Henry Ford analogy: customers would ask for 'more horses,' not a car—AI by default gives 'the most common answers,' replicating existing solutions unless guided by deep requirements work.
• Caveats: No data on how many orgs have reached the same maturity level where code is not a bottleneck.; Assumes stakeholders are available and willing to engage, which is not always the case in large or distributed orgs.
• Implications: Ken's hiring should pivot toward business analysts, product managers, and requirements specialists with domain expertise.; Sprint 0 should be mandatory for all AI/agent projects, with explicit time allocated for stakeholder interviews and room-reading sessions.

Story Mapping and User Story Discipline as AI Input

• Claims: Story mapping (backbone + user stories beneath) provides high-level process view and prioritization (MVP vs. backlog).; User stories should follow persona-need-why structure + acceptance criteria because AI is trained on these patterns and will generate better code.; Daisy-chaining user stories creates a coherent system spec that AI can translate into production code.
• Evidence: Support system story map: contact → triage → resolve → close. MVP: capture intent, classify urgency, draft grounded answer, log to system. Backlog: read sentiment, write to team, suggest next action, check satisfaction.; Example user story: 'As a support lead, I need to open cases right by urgency so that none of the escalations slip.'; Horváth: 'AI is really good at pattern recognition… if you go back to something familiar to AI, it will get you better results.'
• Caveats: No side-by-side comparison of code quality with vs. without user stories provided.; Story mapping requires skilled facilitators and can be time-consuming; scalability across multiple teams not addressed.
• Implications: Ken should standardize user story templates in markdown and store them in repos for AI context.; Pilot story mapping workshops for 2-3 high-stakes agent projects and measure iteration cycles, bug counts, and user adoption vs. a control group without story mapping.; Train product leads and senior engineers in story mapping facilitation techniques.

VAD Framework: Value → Architecture → Design

• Claims: Always start from value: whose problem, what does winning look like, what would make them refuse to use it, would it change a decision.; Map the underlying process and architecture that supports that process before designing the system.; This prevents building 'faster horses' (incremental improvements) and enables 'car' (magnitude-shift innovations).
• Evidence: Horváth's four questions: Whose problem? What does winning look like? What would make them refuse? Would it change a decision?; Track all answers in markdown in the repo so AI can access context.; VAD sequence: understand value → map process → understand architecture → design system.
• Caveats: VAD is conceptually sound but lacks a step-by-step implementation guide or case studies showing failure modes.; No guidance on how to handle conflicts between value, architecture constraints, and design trade-offs.
• Implications: Ken should embed VAD checkpoints in sprint 0 and gate AI build kickoff on completed value/architecture analysis.; Create a VAD template doc with the four questions and process/architecture mapping sections, and make it mandatory for all agent projects.; Consider hiring or upskilling a 'value architect' role responsible for leading VAD sessions across teams.

Anti-Patterns and Metrics to Abandon

• Claims: Building the wrong thing looks like: high feature velocity but low adoption, one-time usage without repeat engagement, demo as deliverable, PRs without real user testing.; Metrics to eliminate: number of features shipped, time-on-site, velocity of new features.; Metrics to adopt: features used more than twice, frequency of repeat activity, real user feedback loops.
• Evidence: Horváth: 'If you've got velocity of shipping new features crazy, but the adoption is not good… that's a very poor pattern.'; Horváth: 'A demo system is not a live system. If a PR is not real user tested, then chances are it will not make it into a live environment.'
• Caveats: Frequency of use can be gamed or may not capture infrequent but critical workflows.; No specific threshold for 'more than twice' or time window for measurement.; Real user testing may be expensive or slow in some contexts.
• Implications: Ken's product analytics should instrument repeat-usage cohorts (7-day, 30-day) and flag features below a threshold for sunsetting.; Shift eng OKRs from story points shipped to 'features achieving >10% monthly active usage within 60 days of launch.'; Require real user testing (not just internal QA) before merging PRs for user-facing features.

Organizational Shift: Move Smart People Upstream

• Claims: Pre-AI boom: smartest people wrote code. Post-AI: smartest people should face customers and define problems.; Deciding what to build is now the expensive part; building it is cheap.; Involve subject-matter experts in decision-making about what gets built, not just how.
• Evidence: Horváth: 'We had our smartest people writing our code, but now we need to be shifting our smartest people towards our customers, towards the business problems.'; Horváth: 'I'm not suggesting everybody should become a functional consultant or product manager… just involve them in the decision-making.'
• Caveats: Senior engineers may resist product/analyst roles due to career identity or compensation structures.; No guidance on how to retain deep technical expertise if top talent shifts entirely upstream.; Transition plans and training requirements not addressed.
• Implications: Ken should create hybrid 'technical product lead' roles with eng+product responsibilities and attractive comp.; Pair senior engineers with customers for quarterly discovery sprints and retrospectives on 'what we should have built.'; Comp bands and promotion criteria must reward requirements quality and customer impact, not just code contributions.

Notable Concepts & Terms

• You can't prompt the room: Central metaphor: AI can generate code from prompts, but cannot replace face-to-face stakeholder negotiation, room-reading, or latent needs discovery. The irreplaceable human skill.
• Story mapping: User story mapping technique: backbone (high-level process steps: contact → triage → resolve → close) with user stories beneath, allowing prioritization into MVP vs. backlog. Horváth's core tool for requirements.
• VAD (Value → Architecture → Design): Horváth's framework for upstream thinking: start from business value, map underlying process and architecture, then design the system. Prevents 'faster horses' syndrome.
• Faster horses syndrome: Henry Ford analogy: asking customers what they want yields incremental requests (more horses) instead of transformative solutions (a car). AI defaults to 'most common answers,' so rigorous requirements are needed to escape this trap.
• Analyst toolkit: Horváth's term for the classic product/BA skill set now becoming decisive: story mapping, business model canvas, value canvas, design thinking. 'Old skill, new economics.'
• Anti-pattern: demo is the deliverable: Building impressive demos that are never deployed or user-tested, a common failure mode when AI makes prototyping too easy.
• Features used more than twice: Horváth's proposed replacement metric for feature velocity: count only features that achieve repeat usage, not one-time curiosity clicks.

Operator Notes / Why Ken Should Care

• For Ken's AI ops teams: This talk is a direct warning that the current bottleneck in agent/AI projects is not code generation but requirements elicitation and stakeholder alignment. Ken should audit whether his teams are running rigorous requirements sessions before prompting AI, or simply building whatever seems cool. The hackathon ratio (17/21 abandoned) is a sobering benchmark.
• For product/GTM: Horváth's VAD framework and four-question checklist (whose problem, what's winning, what's the refusal point, does it change a decision) are immediately actionable. Ken should embed these in sprint 0 templates and gate AI build kickoff on completed value analysis. This prevents the 'demo is the deliverable' trap.
• For hiring/org design: The recommendation to move senior engineers upstream to customer-facing roles is radical but logical. Ken should experiment with hybrid 'technical product lead' roles and ensure comp structures reward requirements quality, not just code output. Career tracks must reflect this shift or top talent will leave.
• For metrics/KPIs: The call to replace feature velocity with 'features used more than twice' and frequency of repeat activity is a hard pivot. Ken should instrument these in product analytics and flag features below threshold for sunsetting. This requires retraining PMs and eng leads to think in adoption cohorts, not story points.
• For workflow/tooling: Horváth emphasizes storing user stories and acceptance criteria in markdown files in the repo so AI can access them as context. Ken should standardize this practice and evaluate whether current LLM prompts are ingesting these artifacts. If not, the team is leaving quality on the table.
• For competitive strategy: 'Everyone has access to the same tools. The difference will be who can understand the business need better.' This is a zero-sum insight: if Ken's competitors adopt story mapping and VAD faster, they will build better products with the same AI. Ken should treat analyst skill-building as a competitive moat and not just a process improvement.

Watch Map

• timestamp unavailable: Transcript does not include chapter markers or timestamps. Speaker covers: intro/thesis (you can't prompt the room), hackathon example (21 ideas, 17 abandoned), career background, story mapping walkthrough, VAD framework, anti-patterns, metrics to abandon, organizational shifts, closing challenge to test user stories vs. no user stories.

Source/Metadata

• Title: You Can't Prompt the Room: The Last Skill AI Won't Replace - Balázs Horváth, VisualLabs
• Transcript words: 2259
• Duration seconds: 945
• Timestamp note: Timestamps/chapters were unavailable in the provided transcript.