The last skill AI will never replace in software development isn't writing clever algorithms or architecting elegant systems — it's walking into a room full of stakeholders and figuring out what should actually be built. You can prompt your AI. You can prompt your code. You can even prompt your entire specification. But you cannot prompt the room. That's the core insight from Balázs Horváth, founder of Visual Labs, who has spent 13 years bridging business and technology as a functional consultant, and who now trains teams to elicit requirements in the age of AI.

What Skills Will AI Never Replace in Software Development?

For most of the last two decades, the biggest bottleneck in software development was access to code. Hiring good developers was expensive and slow. But that bottleneck is gone. Today, with the latest AI models, getting working code is cheap, fast, and increasingly commoditized. The new bottleneck is something far older and far harder to automate: understanding what needs to be built in the first place.

This shift has a profound implication. Because everyone now has access to the same AI tools and the same models, competitive advantage will no longer come from who can build fastest. It will come from who understands the business problem most clearly. That requires human skills — empathy, facilitation, active listening, stakeholder management, and the ability to read a room. These are the skills that belong to business analysts, functional consultants, and product managers. And they are exactly the skills that AI, by design, cannot replicate.

AI is trained to give the most statistically common answer. That means if you ask it to solve a problem without first deeply understanding what the problem really is, it will give you a faster horse, not a car. Henry Ford famously noted that if he'd asked customers what they needed, they'd have said more horses. The real breakthrough came from understanding the underlying need — faster, more reliable transportation — not from optimizing the existing solution. The same logic applies to software today.

Why Do Most Software Teams Build the Wrong Thing?

At the start of one year, Horváth's team ran an internal hackathon with 21 AI agent ideas. Seventeen of those were abandoned. Not because they were technically difficult — because they created no business value. Either the data wasn't accessible, or the problem they solved wasn't real. Only four ideas survived, and those four have meaningfully changed how the team works today.

\p>That 80% failure rate isn't unusual. It reflects a systemic problem: teams are optimizing for shipping speed rather than shipping the right things. There are three classic anti-patterns to watch for:

  • High velocity, low adoption. Features ship constantly, but nobody uses them. If users aren't coming back more than once or twice, you're measuring the wrong things.
  • The demo is the deliverable. It's fast and easy to build something that looks great in a demo. But a demo system is not a live system. If your team celebrates demos instead of production usage, you have a problem.
  • No real user testing in the PRD. If your product requirements document is built without feedback from actual users, the chances of it making it into a live, used environment are very low.

The fix isn't a new tool or a new AI model. It's a deliberate shift in where your smartest people spend their time — moving them upstream, closer to the customer, before a single line of code is written.

What Is User Story Mapping and Why Does It Matter?

User story mapping is one of the most powerful tools in the analyst toolkit, and it becomes even more powerful in the age of AI. The technique involves laying out the full journey a user takes through a process — the backbone — and then capturing the specific actions and needs beneath each step.

Take a support system as an example. The backbone might look like: Contact → Triage → Resolve → Close. Beneath each of those stages, you identify what users and agents need to do. At the MVP level, that might include capturing intent, classifying urgency, drafting a grounded answer, and logging the resolution to a system of record. Everything else — reading sentiment, suggesting next actions, checking satisfaction — goes into the backlog for later releases.

What story mapping gives you is a big-picture view before you commit to building anything. It forces conversations with stakeholders about what actually matters and in what order. It makes trade-offs visible. And crucially, it gives you a structured foundation that AI can work with extremely well.

How Do You Write User Stories That Work With AI?

AI models are exceptionally good at pattern recognition, and they were trained on enormous amounts of software development content — including user stories. That means if you package your requirements in the well-established user story format, you get dramatically better outputs from your AI tools.

The structure is simple and deliberate:

  • Persona: Who is this for? (e.g., a support lead)
  • What: What do they need to do? (e.g., open cases ranked by urgency)
  • Why: What outcome does this enable? (e.g., so no escalation slips through)

A complete user story in practice: "As a support lead, I need to open cases ranked by urgency, so that no escalations slip through unnoticed."

Add acceptance criteria to each story, and you can derive test cases directly from them. Chain these stories together in sequence, and you have a coherent specification. That specification becomes the context your AI model needs to generate high-quality, relevant code — rather than generic solutions that solve the average problem, not your actual one.

The key insight is that the software development lifecycle itself hasn't changed. What's changed is the toolkit we use at each stage, and how dramatically better the output becomes when we feed AI well-structured, context-rich input rather than vague prompts.

What Is the VAD Framework and How Does It Work?

Before jumping into design or development, Horváth's team always works through what they call the VAD framework: Value, Architecture, Design.

  • Value: What is the value being created? What does the customer actually need? How does value flow through the current process?
  • Architecture: What is the underlying system or data structure that supports that process? What constraints exist?
  • Design: Only after understanding value and architecture do you begin designing the solution — including what process changes are needed.

This sequence matters because skipping to design — which is what most teams do when they're excited about a new AI capability — means you're designing a solution before you've understood the problem. The VAD framework enforces discipline. It also pairs naturally with four diagnostic questions Horváth uses on every project:

  • Whose problem is this, specifically?
  • What does winning look like for that person?
  • What would make them refuse to use this solution?
  • Does this change a decision they make — and which decision?

Store the answers to these questions in a markdown file in your repository. AI models that have access to this context will produce significantly better, more relevant outputs than models working from a blank slate.

How Do You Know If Your Software Features Are Being Used?

Most teams track the wrong metrics. They count features shipped per quarter, time spent on site, or number of logins. These numbers feel like progress. They're not.

The metric that actually matters is frequency of repeated use. Not whether someone tried a feature once. Not whether they logged in. Whether they came back and used it again — and again. A feature used once is not a successful feature. A feature used regularly is evidence of real value creation.

The KPI shift Horváth recommends is simple: stop tracking "number of features shipped last quarter" and start tracking "number of features shipped that were used more than twice." That single change in measurement reorients the entire team toward outcomes instead of outputs.

How Do You Shift Your Team Toward Real Business Value?

The practical shift starts Monday morning. Here's where to begin:

  • Audit what you're currently measuring. Identify the metrics that reward shipping over adoption and eliminate them.
  • Move your subject matter experts closer to customers. The people with the deepest product knowledge shouldn't be isolated in engineering. Their experience of what worked and what didn't is invaluable input for deciding what to build next.
  • Run a mapping session before you build anything. Whether it's a user story map, a business model canvas, or any other format — do it before you write a prompt or a line of code. Understand where the value lives first.
  • Compare results with and without user stories. If you have a use case you want to build with AI, try it both ways. The difference in output quality will be immediately obvious.

This isn't a new discipline. Product management, business analysis, and design thinking have existed for decades. What's new is the economics. Building software has become so cheap and fast that the decision of what to build is now the most expensive part of the process. The teams that win in the AI era won't be the ones with the best models. They'll be the ones who best understand what their customers actually need — and who have the human skills to go find out.