AI Engineer World's Fair 2026
You Can't Prompt the Room: The Last Skill AI Won't Replace
Read the talk
You Can't Prompt the Room: Choosing What AI Should Build
As implementation gets cheaper, requirements discovery becomes more consequential: map the workflow, define the decision, and test whether people return to what you ship.
From a talk by Balázs Horváth
Choosing what deserves to be built
At an internal hackathon, Balázs Horváth’s team started with about 21 agent ideas and abandoned 17. Some lacked access to the necessary data; others did not make enough business sense to build. He reports that the four remaining ideas substantially changed how the team worked. The useful distinction was not which agent could be implemented, but which deserved to be implemented.
That distinction draws on what Horváth describes as thirteen years bridging business and IT. He began by testing functional designs and specifications, then writing them, worked on large ERP and CRM programs in the US and UK, and founded VisualLabs. His team learned to elicit requirements that could become specifications for developers, configuration work for consultants, and now instructions for AI. The implementation tools have changed much faster than the work of understanding customers. Reading the room is part of building valuable software.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Stakeholder access becomes the bottleneck
When access to code stops being the main constraint, another constraint becomes visible: getting stakeholders and decision makers into a room, securing enough of their time, and discovering what they actually need. A prompt can produce code or an entire specification. It cannot supply the missing conversation that determines whether that specification describes worthwhile work.
Horváth uses the familiar horse-to-car analogy: asking customers what they want may produce a request for more or faster horses, while understanding their underlying need may suggest a car. The saying is commonly attributed to Henry Ford, although The Henry Ford museum has not satisfactorily traced it to him. Here its purpose is to distinguish improving a familiar solution from discovering a different one. Horváth characterizes AI as tending toward common answers; that is his explanation for why human discovery must guide generation beyond reproducing existing approaches, rather than a technical definition of how every model behaves.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Map the workflow and slice the first release
This shifts attention toward the analyst’s toolkit: story mapping, the Business Model Canvas, value canvases, and design thinking. Story mapping is the technique Horváth singles out. Start with a backbone of user activities, then place the stories that support each activity beneath it. The backbone preserves the overall process while the details explain what users need at each step.
For a support system, the process runs from contacting support through triaging and resolving or routing, then closing the case. A first release can cover that entire journey with a small set of capabilities:
| Workflow stage | Release 1 capability |
|---|---|
| Contact | Capture intent |
| Triage | Classify urgency |
| Resolve or route | Draft a grounded answer |
| Close | Log to a system of record |
These are the first four stories of the MVP. Sentiment reading, team routing, next-action suggestions, chatting, and satisfaction checks can sit in the later backlog. Keeping the map at this level makes it possible to choose a release without losing sight of the complete support workflow.
The map does not finish requirements discovery. Each story becomes a starting point for discussion with stakeholders: what should this capability actually do, and what would make it useful in their process? That conversation turns a short label such as “classify urgency” into a requirement an agent can act on.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Turn stories into specifications and tests
Consider the urgency story: a support lead needs open cases ranked by urgency so that escalations do not slip. Its structure carries three distinct pieces of context:
- Persona: the support lead who needs the capability.
- Need: a ranking of open cases by urgency.
- Purpose: preventing missed escalations.
The purpose matters because it gives the requested behavior a reason. Horváth argues that this familiar user-story structure also helps AI interpret requirements through pattern recognition; he presents that as practical guidance, without a measured model comparison.
Add acceptance criteria to make the story testable, then derive test cases from those criteria. For the support-lead story, the stakeholder conversation still has to establish what urgency means and what would count as a missed escalation; the sentence alone does not settle those rules. Once the stories are connected, they can describe a coherent system from which to create the specification and code. The development lifecycle remains recognizable: requirements, acceptance conditions, tests, and implementation still need to agree, even when AI changes the tools used to produce them.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Four questions that make requirements concrete
Before deciding what to build, work through four discovery questions:
- Whose problem is this? Name a specific person or persona and make the problem concrete enough to quantify.
- What does winning look like for them? Identify the successful outcome, including whether reaching it faster, more smoothly, or more safely matters.
- What would make them refuse to use it? Look for an unsupported platform, cumbersome interaction, or data-security concerns that would block adoption.
- Would it change a decision? Name the decision and explain how the system would help the person make it better.
The final question connects the proposed capability to an action in the user’s work, rather than treating the existence of a new feature as success.
Keep the answers in a Markdown file in the repository so AI has access to the same context. For the support-lead example, a working requirements.md can retain the established story and make the remaining discovery questions explicit:
markdown
# Rank open support cases
## User story
As a support lead, I need open cases ranked by urgency
so that no escalations slip.
## Discovery questions to resolve
- Whose problem: Which support lead owns this workflow,
and how often are escalations currently missed?
- Winning: What observable outcome means escalations no longer slip?
- Refusal: Which platform, usability, or data-security constraints
would prevent use?
- Decision: Which case-handling decision should the ranking change?
## Acceptance criteria to agree
- Define urgency with the support lead.
- Establish examples of the expected ordering of open cases.
- Derive test cases from the agreed examples.
The unanswered items remain questions, not silently invented business rules. This gives the next discussion a concrete starting point and is more useful context than a generic instruction to build an agent that handles support.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Value → Architecture → Design
Requirements discovery also needs an order of operations. First establish what constitutes value and how the current process creates it. Then understand the architecture that supports that process. Only then begin designing the system. Horváth calls this VisualLabs’ VAD: Value → Architecture → Design:
- Value: determine what the customer is trying to gain and how that value is created.
- Architecture: understand the process flow and the systems supporting it.
- Design: shape the system around the desired value and process, including any process changes needed along the way.
Starting with value prevents a convenient implementation from becoming the goal before the team understands the work it is supposed to improve.
Much of this is familiar product management. Its significance changes when teams can reach for the same implementation tools and coding models. Under those conditions, the differentiator is how well a team understands the business need before asking a model to build. The old skill becomes more consequential as the economics of implementation change.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
When shipping speed hides a product problem
High development velocity can coexist with weak adoption. A team may ship features rapidly while few people use them. Even an initial login or trial of a new feature does not establish that it has lasting value. Horváth recommends looking at the frequency of a relevant activity, rather than relying on time spent on the site: do people come back to perform the work the system is intended to support?
Two further warning signs concern delivery itself. A polished demo is easy to mistake for a finished product, but a demo is not a live system that people actually use. Likewise, a product requirements document, or PRD, that has never been tested with real users lacks the feedback needed to establish whether the proposed product belongs in their work. Production use and real-user feedback are part of the path to delivery, not consequences to assume from a convincing presentation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Move expertise upstream and measure repeat use
If implementation becomes cheaper, choosing the work deserves more attention from experienced people. Horváth’s organizational proposal is to move expertise upstream: closer to customers, business problems, and the decisions about what gets built. Begin by auditing which measurements and time allocations currently reward building the wrong thing.
Horváth proposes replacing the count of features shipped last quarter with the count of shipped features actually used more than twice. This is a practical suggestion for shifting attention toward repeat use, not a validated universal threshold; he does not specify a user denominator or observation window. Its purpose is to change what the team pays attention to after shipping.
The corresponding staffing change is to give subject-matter experts more influence over customer-facing decisions. That does not require every engineer or expert to become a functional consultant, product manager, or product owner. It requires including their knowledge of what has worked and failed before while the team is still deciding what to build.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Run a mapping session before building
Before the next implementation, run a mapping session. Use a user story map, a Business Model Canvas, or another map that makes value creation visible. The artifact matters less than whether the team can explain where the value lives and how the proposed system contributes to it.
Then try the same AI-assisted use case with and without user stories and compare the results. Horváth reports that doing this himself persuaded him to keep user stories in his development process; he offers a personal observation, not a quantified controlled evaluation. The next useful experiment is available before any elaborate process change: take the thing you already want to build, articulate the users’ needs and purposes, and see how that changes the result.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
A compact guide to arranging user activities, adding story details and slicing releases around user outcomes.
Strategyzer's printable template for mapping customers, value propositions, operations and business economics.
Further reading
Alex Osterwalder explains how to map customer jobs, pains and gains against a proposed offering.
Horváth's webinar and transcript explain VisualLabs' Value → Architecture → Design method and enterprise AI readiness.
Read the complete timestamped transcript
- 0:01
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.
- 0:13
So at a point where writing code is no longer the bottleneck, the real thing is to figure out-- is figuring out what it is that you should be building.
- 0:25
Um, and that comes down to, to people skills and being able to work the room 'cause you can't prompt a room, you can prompt your AI. So at the beginning of the year, we held an internal hackathon, uh, where we had about twenty-one agents, uh, agent ideas, and seventeen of those were abandoned because they actually created no,
- 0:48
uh, business value. They, uh, uh, we either didn't have, uh, data access or w- 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.
- 1:05
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 thirteen years, I've always been, uh, the bridge between business and IT and the developers.
- 1:26
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 VisualLabs.
- 1:44
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, uh, for AI to build.
- 2:03
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.
- 2:17
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.
- 2:27
And that essentially the big shift over the past two, three years was that getting access to code and being able to build is no longer the bottleneck to the software development lifecycle.
- 2:40
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.
- 2:53
So that's the right-- that's the real bottleneck, figuring out what it is that should be built. 'Cause you can prompt your code, you can prompt your AI, you can prompt your whole specification, but you can't prompt your room.
- 3:06
And what a model can do is very similar to how Henry Ford's analogy of, uh, what he said about asking his users or his customers, if he'd asked them what it is that they needed, they would've said they needed more horses.
- 3:23
But in reality, he built a car, and he made a very big success on them. So if you're just using AI, uh, 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.
- 3:45
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 get to, uh, not a faster horse, but actually produce a car that's a magnitude shift better than what we had.
- 4:04
So it's really an interesting wor- world where, uh, being able to write good code is no longer, uh, the, the most important skill to have. Uh, actually, the real skill now is becoming the analyst, analyst toolkit, uh, which is, you know, things like story mapping, business model canvas, uh, value canvas, and those, those good old things that
- 4:29
we are so used to using as functional consultants, business analysts, um, 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.
- 4:47
So, uh, 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, uh, to move forward, uh, in their, in their processes.
- 5:04
So, uh, here is a, uh, support systems user story map, contacting, triaging, resolving, and then essentially closing a case. Uh, with this, uh, you can understand different stages of the process, uh, and then capture the user stories beneath them.
- 5:23
It is intended to stay at a fairly high level, so you can get a, uh, a big picture, and then in-- you can decide, uh, what it is that you want to build in release one, like capturing intent, classifying urgency, drafting a grounded answer, and then logging, logging it to a system of record.
- 5:41
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, uh, uh, the second set of user stories, like reading a sentiment, routing to a team, suggesting next action, chatting, checking satisfaction, so on and so forth.
- 6:01
Uh, those will be part of your backlog. So what it would allow you to Um, to get really good, uh, agentic results is by honing in on these user stories and making sure that you use these user stories as a means, uh, to elicit discussions with your stakeholders, with your business, and then work out what that
- 6:26
user story should really be about. So the first user story, uh, second user story would be as a support lead, I need to open cases ranked by urgency so that none of the escalations sh-- slip.
- 6:40
So just make sure that every user story covers these is ideally, uh, 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, uh, setup.
- 6:58
So if you go back to something that's familiar to AI, it will get, get you better, better results. And every user story, uh, is actually made up with, uh, of these, you know, well-known structures, the persona, the what, the actual need, and the why.
- 7:16
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, um, very good results.
- 7:31
And then if you just connect these user stories, daisy chain them up, then that will allow you to, uh, to create a coherent system based on which you can create your specification and then essentially your code.
- 7:45
So the software development lifecycle doesn't change as much as a result of AI. It's actually the toolkit that we are, uh, we are using is changing.
- 7:56
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 is, whose problem is this?
- 8:11
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?
- 8:23
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?
- 8:36
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 applied, so they would-- wouldn't actually use it.
- 8:49
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.
- 9:01
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.
- 9:21
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.
- 9:35
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 c-- and then you can start the actual design where you can start designing.
- 9:59
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.
- 10:10
How are we 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.
- 10:29
So you might ask, "Isn't this just good old product management?" And to a 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
- 10:51
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.
- 11:05
So it's old skill, but new ec-economics, and it's a real shift towards analyst toolkit. So what building the wrong thing looks like if you've got velocity up, you're shifting, shipping new features like crazy, uh, but the adoption is not good if people are barely using it.
- 11:25
That's actually a very, very poor pattern. That's what you want to address. Um, if people are trying out new features, they are logging into the new system, we just vibe coded our craziest, newest thing, but they are not actually reusing it.
- 11:40
So don't look at time of usage and time spent on site. Much rather you ca- look at the frequency of a certain activity. Um, if another, uh, miss pattern, uh, anti-pattern is if the demo is the deliverable.
- 12:00
We want to make sure that people can, uh, can put things into production. It's really fast to do a demo, and it, it will look nice, but people aren't actually using it.
- 12:11
So a demo system is not a live system. And
- 12:16
If a PRD is no real user tested, so if you, if you don't gather proper feedback, uh, from a real user, then chances are it will not make it into, into a live environment and people will not use it.
- 12:31
So, uh, the big thing here is, is actually putting your, you know, your-- everything is needs to be moving upstream here. Uh, so,
- 12:42
uh, earlier on, before the AI boom, uh, we had our smartest people writing our code, but wh- 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.
- 13:03
Building it has actually become very cheap. So a couple of things that you can start doing from Monday morning or from the next day is audit the wrong thing, right?
- 13:16
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.
- 13:28
So, uh, the number of features shipped last quarter, um, that should be, um, should be eliminated and sh- just start looking at the number of features that we shift, uh, that is actually used more than twice.
- 13:46
So that would be a good, uh, a good shift in your KPIs, in your metrics. And just make sure that you're moving those real subject matter experts to a more customer-facing, client-facing, uh, role or position where they have an actual impact on what gets built.
- 14:07
And I'm not suggesting that everybody should become a, uh, functional consultant or a product manager or 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, uh, is a
- 14:30
super important aspect. And I still do this, uh, or recommend it to everyone to actually start doing a mapping session before you build. Uh, 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, uh, how you
- 14:52
create value. So, um, I hope you found this valuable. It's lots of, lots of, uh, old things stitched together, uh, that will really make a difference. Just, uh, give it a shot if you have a, a, a good use case that you want to vibe code, try building it with user stories first or without user stories and
- 15:14
just compare, uh, the difference in the results. Uh, when I did this for myself, that was the big sh- big shift that I started doing is, "Holy cow, I still need to incorporate user stories, uh, in my development."
- 15:29
So this way we can build the right thing and not just the next thing. Um, you can, uh, scan a QR code, uh, to connect with me on LinkedIn.
- 15:40
Uh, would be happy to chat further. Thank you so much.