A talk by Balázs Horváth (VisualLabs) arguing that as AI handles code generation, the bottleneck in software delivery has shifted upstream to requirements work: getting stakeholders together, eliciting real needs, and deciding what is worth building. Drawing on a VisualLabs internal hackathon (21 agent ideas generated, 17 abandoned for lack of data access, business ownership, or measurable value, 4 now in production), it presents three practical tools: story mapping, a 4-question value framework (whose problem, what winning looks like, what would cause refusal, what decision it changes), and the VAD thinking path (Value to Architecture to Design) for separating production agents from demo agents. # Video Identity Observation Document ## Video Overview **Title:** *You Can't Prompt the Room: The Last Skill AI Won't Replace - Balázs Horváth, VisualLabs* ## Creator Identity & Explicit Self-Description - The speaker identifies himself as **Balázs Horváth**: *"Hi everyone. I am Balázs Horváth"* - He claims to be the **founder of Visual Labs**: *"And then I founded Visual Labs."* - He describes a **13-year career trajectory**: *"throughout my career in the past 13 years, I've always been the bridge between business and IT and the developers,"* progressing from writing functional designs and specifications to functional consulting on *"large ERP and CRM programs in the US and the UK."* - He claims a **leadership/training role** at his company: *"I trained my team on how to elicit those requirements."* ## Claimed Scope & Positioning - The presentation frames the channel's subject matter as the **intersection of AI and software business practices**, with a specific thesis: *"what is the last thing that AI will take away from us as people in the software business."* - Core claim: **requirements elicitation and stakeholder skills** are now the bottleneck — *"you can prompt your code, you can prompt your AI... but you can't prompt your room."* - He proposes a branded methodology: *"we like to call this thinking process VAD, value architecture design."* - Positioning statement: *"it's an old skill, but new economics"* — traditional analyst tools (story mapping, business model canvas) matter more in the AI era. ## Intended Audience (Observable Evidence) The address targets a **professional software/business audience**, demonstrated by: - Direct workplace advice framing: *"couple of things that you can start doing from Monday morning."* - Assumed familiarity with SDLC concepts: PRDs, KPIs, MVPs, backlog, acceptance criteria, user stories. - References to decision-making roles: *"stakeholders, your decision-makers,"* "product owner," "functional consultant." - Audience-consistent exhortations: *"I recommend it to everyone to actually start doing a mapping session before you build."* ## Demonstrated Presentation Patterns - **Personal case study as evidence:** an internal hackathon with 21 agent ideas, 17 abandoned — *"those four were the ones that actually had a very big impact on how we work today."* - **Structured teaching format:** walks through a support-systems user story map (contacting, triaging, resolving, closing a case), the four-question framework ("Whose problem is this?", "What does winning look like?"), and anti-patterns ("the demo is the deliverable"). - **Practical, tool-agnostic guidance:** e.g., *"track all of these in a good old markdown file in your repository so that AI can access it."* - **Audience engagement / networking CTA:** *"You can scan a QR code to connect with me on LinkedIn. I would be happy to chat further."* — indicating professional networking intent. ## Separation of Claims vs. Demonstration - **Creator claims:** 13 years of experience, Visual Labs founding, training his team, the VAD methodology's effectiveness. - **Demonstrated:** command of business-analysis frameworks, opinionated methodology around AI-assisted development, and a coaching/consulting presentation style — consistent with the self-described business-IT bridge role, though this is observable style, not verified biography. # Delivery Observation Report ## Speaker **Balázs Horváth, VisualLabs** — self-introduced at the open: *"Hi everyone. I am Balázs Horváth and today I will talk to you about what is the last thing that AI will take away from us as people in the software business."* --- ## Tone & Register - **Conversational, colloquial**: frequent "you know," "so," "uh," "um," and idioms like *"holy cow, I still need to incorporate user stories in my development."* - ** plainspoken analogies**: references Henry Ford's "faster horse" story — *"if he'd asked them what it is that they needed, they would have said they needed more horses."* - **Direct audience address** throughout: *"you can prompt your code, you can prompt your AI, you can prompt your whole specification, but you can't prompt your room."* ## Signature Phrases (Recurring) - **Title concept, repeated as a refrain**: - *"you can't prompt the room"* - *"you can prompt your AI... but you can't prompt your room"* - **"The right thing" vs "the next thing"** framing appears at open and close: *"making sure that we are building what is worth building"* → *"we can build the right thing and not just the next thing."* - Repeated use of **"bottleneck"** for contrast: *"writing code is no longer the bottleneck"* / *"the real bottleneck is getting your people, your stakeholders, your decision-makers into the room."* ## Teaching Habits - **Claim → concrete example structure**: - Hackathon anecdote: *"about 21 agents... 17 of those were abandoned because they actually created no um business value."* - Support-systems story map walkthrough: *"contacting, triaging, resolving, and then essentially closing a case."* - **Numbered/enumerated question sets**: *"I always like to ask these four questions: whose problem is this?... What does winning look like for them?... what would make them refuse to use it?... would it change a decision?"* - **Named frameworks/labels**: coins **"VAD, value architecture design"** and lists tools: *"story mapping, business model canvas, value canvas."* - **Template examples**: models the user-story format — *"as a support lead, I need to open cases ranked by urgency so that none of the escalations should slip."* - **Actionable takeaways**: explicit "from Monday morning" list — *"audit the wrong thing... start looking at the number of features that we shipped that is actually used more than twice."* - **Anti-pattern teaching**: names failure modes — *"if the demo is the deliverable,"* *"velocity of shipping new features like crazy, but the adoption is not good."* ## Communication Patterns - **Contrastive framing** is his dominant rhetorical device: old vs new, cheap vs expensive, code vs people — *"Building it has actually become very cheap"* vs *"deciding what to build... that's the expensive part."* - **Self-positioning via credentials**: *"throughout my career in the past 13 years, I've always been the bridge between business and IT and the developers."* - **Anticipates objections**: *"So, you might ask, isn't this just good old product management? And to certain extent, yes."* - **Closing call to action with experiment**: *"Try building it with user stories first or without user stories and just compare the difference in the results,"* plus a LinkedIn QR-code invitation. ## Delivery Features & Uncertainty - **Disfluency and word repetition** are frequent in the transcript ("uh um," "that's that's that's," "and then and then"), suggesting spontaneous, unscripted or lightly-scripted delivery. - Transcription quirks (e.g., *"Google it out"* at [690], *"wipe code"* at [909]) make some phrasing uncertain — these may be transcription errors rather than spoken words. - Repetition of the core refrain is well-attested; the "four questions" and "VAD" frameworks each appear once, so their status as recurring teaching tools beyond this talk is **unverifiable from this single sample**. # Position Record: "You Can't Prompt the Room: The Last Skill AI Won't Replace" **Speaker:** Balázs Horváth, VisualLabs ## Core Thesis - **Writing code is no longer the bottleneck** of the software development lifecycle; the real bottleneck is **figuring out what to build** — getting stakeholders and decision-makers into the room and eliciting requirements. - Central slogan: *"You can prompt your code, you can prompt your AI, you can prompt your whole specification, but you can't prompt your room."* - The last irreplaceable skill is therefore **people skills / requirements elicitation**, i.e., the "analyst toolkit." ## Supporting Evidence Claimed - Internal hackathon at the start of the year: **21 agent ideas, 17 abandoned** because they created no business value (no data access, or building it didn't make sense); the remaining **4 had a big impact** on how they work today. - Speaker's background: 13 years as a bridge between business and IT, functional consultant on large ERP/CRM programs in the US and UK, founder of VisualLabs. ## Reasoning Pattern: Why AI Alone Produces Mediocrity - Invokes the **Henry Ford analogy**: if asked, customers would have said "more horses," but Ford built a car. (Speaker attributes this analogy to Ford.) - Claim: **AI by definition gives the most common answers**, so using it merely to "build things better" risks **replicating what already exists**. The real job is moving AI "away from that average" — not a faster horse, but a magnitude-shift better car. ## Prescribed Method: The Analyst Toolkit - Skills emphasized: **story mapping, business model canvas, value canvas**, design thinking — "old skills, but new economics." - **User story mapping** highlighted as most valuable: - Example support-systems map: contacting → triaging → resolving → closing a case; capture user stories beneath backbone steps; first slice = MVP (capture intent, classify urgency, draft grounded answer, log to system of record); second layer = backlog. - Use stories as **a means to elicit discussion** with stakeholders. - Write stories in classic **persona / what / why** structure (e.g., "As a support lead, I need to open cases ranked by urgency so that no escalations slip") — argued to work better because **AI was trained on this well-known structure** and is good at pattern recognition; add acceptance criteria to derive test cases. - "Daisy chain" stories into a coherent system → specification → code. Claim: **the SDLC doesn't change much; the toolkit changes**. - **Four framing questions**: Whose problem is this (named persona, quantified)? What does winning look like? What would make them refuse to use it (platform, cumbersome, data security)? Would it change a decision? - Track answers in a **markdown file in the repository** so AI gets more context; generic prompts ("build us an agent that handles support") won't yield the desired answer. - **VAD framework** (Value → Architecture → Design): start from how value is created, map the current process, understand the underlying architecture, then design. ## Acknowledged Counterpoint - Speaker asks: *"Isn't this just good old product management?"* Answer: **"to a certain extent, yes"** — an old trade worth learning, newly decisive because everyone has the same tools; the differentiator is who understands the business need better. ## Anti-Patterns of Building the Wrong Thing - High feature velocity with poor adoption. - Users trying features once but **not reusing them** — measure **frequency of activity**, not time-on-site. - **"The demo is the deliverable"** — demo systems aren't live systems. - PRDs without real user testers. ## Recommended Actions - **Audit what you're tracking wrong**: replace "features shipped last quarter" with "features shipped that are used more than twice." - Move **subject-matter experts into customer-facing, decision-influencing roles** — with the qualification: *"I'm not suggesting that everybody should become a functional consultant or product manager"* — involve them in decisions on what gets built. - Run a **mapping session (story map / business model canvas) before building**. - Experiment suggestion: build a use case with and without user stories and compare results; speaker reports his own shift: "I still need to incorporate user stories in my development." ## Overarching Claim - **Shift smartest people upstream**: previously they wrote code; now they should face customers and business problems, since "building it has actually become very cheap" while deciding what to build is the expensive part. Goal: "build the right thing and not just the next thing." # Video Attribution Record ## Video - **ID:** `01a15ca8-d973-7441-8e10-3eb556c06e82` - **Title:** *You Can't Prompt the Room: The Last Skill AI Won't Replace - Balázs Horváth, VisualLabs* ## Speakers & Roles - **Balázs Horváth** — sole speaker; **creator / presenter**, self-identified as founder of **Visual Labs** and a functional consultant with 13 years bridging business and IT. - No guests, narrators, or other identified speakers appear in the transcript. ## Referenced Sources & Third-Party Claims - **Henry Ford anecdote:** speaker attributes to Henry Ford the analogy that customers asked what they needed would have said "more horses" while Ford built a car. Presented as the speaker's paraphrase ("what he said"); not independently sourced in the transcript. - **Internal hackathon (own organization):** ~21 agent ideas, 17 abandoned, 4 with impact — first-party claim by the speaker's company. - **Methodologies named** (referenced as concepts, not cited sources): story mapping, business model canvas, value canvas, design thinking, user stories, "VAD" (value architecture design — the speaker's own coined term). ## Promotional Segments - **Closing call-to-action:** speaker invites viewers to **scan a QR code to connect on LinkedIn** — flagged as promotional/self-promotion segment. ## Availability & Provenance Limits - **Comments:** no comment availability information present in source material. - **Curated metadata:** none supplied beyond title and transcript; timestamps, citations, and external links unavailable. - All career and outcome claims (ERP/CRM programs in US/UK, hackathon results, personal experience) are **unverified first-party statements** from the speaker. Hi everyone. I am Balázs Horváth and today I will talk to you about what is the last thing that AI will take away from us as people in the software business. So, at a point where writing code is no longer the bottleneck, the real thing is to figure is figuring out what it is that you should be building. Um and that comes down to to people skills and being able to work the room because you can't prompt the room. You can prompt your AI. So, at the beginning of the year, we held an internal hackathon uh where we had about 21 agents uh agent ideas and 17 of those were abandoned because they actually created no um business value. They uh um we either didn't have uh data access or or it just didn't make sense uh to build it. And those four were the ones that actually had a very big impact on how we work today. And it's it's a very good example of of just making sure that we are building what is worth building. And throughout my career in the past 13 years, I've always been uh the bridge between business and IT and the developers. Um I started writing, well, initially testings uh uh functional designs, specifications, and then uh and then I wrote them. And as uh as a functional consultant, I worked with large ERP and CRM programs in the US and the UK. And then I founded Visual Labs. And essentially, I trained my my team on how to elicit those requirements in a way uh that we can turn them into good uh specifications for developers to build, for consultants to configure, and most recently now for AI to build. And what's not really changed over the years is how we interact with our customers, how we interact with systems, how we interact with AI is very much changing. Um and that's that's uh that's the big thing now. Uh but if you can read the room, if you can elicit the right requirements, uh then you will be able to build more valuable software. And that essentially the big shift over the past 2 3 years was that getting access to code and being able to build is no longer the bottleneck to the software development life cycle. Now the real bottleneck is getting your people, your stakeholders, your decision-makers into the room and being able to access them and elicit the requirement and being able to spend the time with them. So that's the right That's the real bottleneck, figuring out what it is that should be built. Cuz you can prompt your code, you can prompt your AI, you can prompt your whole specification, but you can't prompt your room. And what a model can't do is very similar to how Henry Ford's analogy of what he said about asking his users or his customers, if he'd asked them what it is that they needed, they would have said they needed more horses. But in reality, he built a car and he made a perfect success of them. So if you're just using AI um to to make things, you know, build things better, um the chances are that you are replicating what already exists because AI by definition is coded to give you the most common answers. So for So for us, the real job is to make sure that AI moves away from that average into what is better for us. So, we can just got to not a faster horse, but actually produce a car that's a magnitude shift better than what we had. So, it's really an interesting word world where being able to write good code is no longer the most important skill to have. Actually, the real skill now is becoming the analysis analysis toolkit, which is things like story mapping, business model canvas, value canvas, and those those good old things that we are so used to using as functional consultants, business analysts, or or uh in in the world of design thinking. So, I'd like to zoom in on story mapping because that's the the skill set that I found as the most valuable. So, once you have the story map with the backbones and understand at each step what your customers, your users are doing, that would give them the ability to to move forward in their in their processes. So, here's a support systems user story map contacting, triaging, resolving, and then essentially closing a case. With this, you can understand different stages of the process, and then capture the user stories beneath them. It is intended to stay at a fairly high level so you can get a a big picture, and then in you can decide what it is that you want to build and release one like capturing intent, classifying urgency, drafting a grounded answer, and then logging logging it to a system of record. That's essentially your MVP. Those are the first things that you'd want to build, and those are your first four user stories. And beneath those, you've got the the second set of user stories, like reading a sentiment, writing to a team, suggesting next action, chatting checking satisfactions, so on and so forth. Those will be part of your backlog. So, what it would allow you to to get really good results is by honing in on these user stories and making sure that you use these user stories as a means to elicit discussions with your stakeholders, with your business, and then work out what that user story should really be about. So, the first user story second user story would be as a support lead, I need to open cases ranked by urgency so that none of the escalations should slip. So, just make sure that every user story covers these is ideally written in this setup because 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 that's familiar to AI, it will get get you better better results. And every user story is actually made up with of these, you know, well-known structures, the persona, the what, the actual need, and the why. So, by packaging these up and giving it to AI, obviously with the acceptance criteria based on which you can derive the test cases, you will be able to create very good setup and very good very good results. And then if you just connect these user stories, daisy chain them up, then that will allow you to create a coherent system based on which you can create your specification and then essentially your code. So, the software development life cycle doesn't change as much as a result of AI. It's actually the toolkit that we are we are using is changing. Right. So, when we uh work with systems and when we think about what we want to build, I always like to ask these four questions as whose problem is this? Whose problem are we actually solving? So, we can we can name it to a direct person, direct persona, uh and it's very much quantified. What does winning look like for them? So, when are they actually successful? Are they achieving the right outcome? Uh can we help them achieve that right outcome uh in a quick way or a smooth way or a safe way? And what would that make make them refuse to use it? It's not available on their platform, it's cumbersome to use, it's uh the data security aspect applies, so they would wouldn't actually use it. And would it change a decision? Ideally, we want to be impacting how a person makes a decision and we'd want to, you know, tilt them to making better decisions. So, does it change a decision and and what is the decision that it changes? So, once you can answer these four questions, then you'll be able to elicit better responses from your AI and just make sure that you track all of these in a good old markdown file in your repository so that AI can access it. It will just get way more context out of it. And you know, if you just did something as generic as build us an agent that handles support, uh you will not get the answer you want. So, what we always do is go from value, so understand how value is created, what constitutes value, how the process currently flows, what is the underlying architecture beneath it that supports that process, and then you can and then you can start the actual design where you can start designing. So, we like to call this uh thinking process VAD, value architecture design, and this is what we want to always go through. So, always have, you know, value in mind, how we're creating value, what is the value we are creating, what is the value that your customer is looking for, what is the underlying process that supports this, and how you can design a system around it so it best supports the value and the process, and what process changes are needed along the way. So, you might ask, isn't this just good old product management? And to certain extent, yes, it is an old skill, it is an old trade that is worth picking up and learning, because this is now becoming uh the mode, if you will, of how you can elicit the right requirements, how you can build better software, because we all have access to the same tools, so the difference will be who can understand the business need better, uh because then we can all just uh have the latest and greatest model write the code for us. So, it's old skill, but new economics, and it's a real shift towards analyst toolkit. So, what building the wrong thing looks like, if you've got velocity of your shifting shipping new features like crazy, uh but the adoption is not good. If people are barely using it, that's actually a very very poor pattern, that's what you want to address. Um if people are trying out new features, they're logging into the new system, we just wiped Google it out, craziest newest thing, but they are not actually reusing it. So, don't look at time of usage and time spent on site. Much rather you got look at the frequency of a certain activity. Um, if another uh miss pattern and anti-pattern is if the demo is the deliverable. We want to make sure that people can can put things into production. It's really fast to do a demo and it will look nice, but people aren't actually using it. So, the demo system is not a live system. And if your PRD has no real user testers, so if you if you don't gather proper feedback uh from a real user, then it's chances are it will not make it into into a live environment and people will not use it. So, uh the big thing here is is actually putting your you know your everything is needs to be moving upstream here. Uh so, uh earlier on before the AI boom, uh we had our smartest people writing our code, but what now we need to be shifting our smartest people towards our customers, towards the business problems, and we need to be spending more time on deciding what to build because that's the expensive part. Building it has actually become very cheap. So, couple of things that you can start doing from Monday morning or from the next day is audit the wrong thing, right? Just start figuring out what are the wrong things that you're currently tracking. And and just make sure that you are realigning your measurements, your time, what what it is that you're looking for. So, uh the number of features shipped last quarter, that should be should be eliminated and you should just start looking at the number of features that we shipped that is actually used more than twice. So, that would be a good a good shift in your KPIs and your metrics. And just make sure that you're moving those real subject matter experts to a more customer-facing, client-facing role or position where they have an actual impact on what gets built. And I'm not suggesting that everybody should become a functional consultant or a product manager, product owner. I'm just saying involve them in the decision-making because they have the most experience of what worked in the past and what didn't. And just making sure that gets included in the decision-making of what should be built is a super important aspect. And I still do this I recommend it to everyone to actually start doing a mapping session before you build. Just make sure that you either create a user story map or business model canvas or any old mapping that highlights where the value lives and just make sure that you understand how you create value. So, um I hope you found this valuable. It's a lots of lots of old things stitched together that will really make a difference. Just give it a shot if you have a good use case that you want to wipe code. Try building it with user stories first or without user stories and just compare the difference in the results. When I did this for myself, that was the big big shift that I started doing is holy cow, I still need to incorporate user stories in my development. So this way we can build the right thing and not just the next thing. Um You can scan a QR code to connect with me on LinkedIn. I would be happy to chat further. Thank you so much.