{
  "video": {
    "id": "6bmM45jkMDY",
    "title": "You Can't Prompt the Room: The Last Skill AI Won't Replace - Balázs Horváth, VisualLabs",
    "duration": 945,
    "upload_date": null,
    "channel": "AI Engineer",
    "source": "AI Engineer",
    "event_format": "Online"
  },
  "analysis": {
    "video_id": "6bmM45jkMDY",
    "title": "You Can't Prompt the Room: The Last Skill AI Won't Replace - Balázs Horváth, VisualLabs",
    "one_liner": "Now that writing code is cheap, the remaining bottleneck is getting stakeholders in a room and eliciting the right requirements — so the durable skill is the old business-analyst toolkit (story mapping, user stories, value canvases), not prompting.",
    "summary": "Balázs Horváth of VisualLabs argues that AI has removed code as the bottleneck in the software lifecycle, leaving 'figuring out what should be built' as the expensive part — and that is a people skill you can't prompt. He walks through the analyst toolkit he now treats as the core competency: user story mapping to find the MVP slice, the persona/what/why user story structure plus acceptance criteria as the format AI was trained on, four qualifying questions kept in a markdown file in the repo for AI context, and a 'VAD' (value, architecture, design) thinking order. He names the anti-patterns of building the wrong thing — high shipping velocity with no adoption, the demo as deliverable, a PRD with no real user testers — and prescribes moving the smartest people upstream toward customers.",
    "key_points": [
      "At an internal VisualLabs hackathon at the start of the year, 21 agent ideas were generated and 17 were abandoned for creating no business value (no data access, or it just didn't make sense to build); the surviving 4 had a big impact on how the company works today.",
      "The bottleneck has moved: access to code and ability to build is no longer the constraint — getting stakeholders and decision-makers into the room, accessing them and spending time eliciting requirements is.",
      "Because AI is 'by definition coded to give you the most common answers', prompting it for improvement replicates what already exists; the Henry Ford framing is that customers ask for faster horses, and the job is to pull AI off the average toward the car.",
      "The valuable skill set is the analysis toolkit — story mapping, business model canvas, value canvas, design thinking — not writing good code.",
      "Worked story map example for a support system with a backbone of contacting → triaging → resolving → closing a case: the MVP is the first four user stories (capturing intent, classifying urgency, drafting a grounded answer, logging to a system of record); the second row (reading sentiment, routing to a team, suggesting next action, checking satisfaction) is backlog.",
      "Write user stories in the classic persona / need / why structure ('As a support lead, I need to open cases ranked by urgency so that none of the escalations should slip') with acceptance criteria to derive test cases — AI is good at pattern recognition and was trained on that well-known structure, so a familiar format returns better results; daisy-chaining the stories yields a coherent spec and then the code.",
      "Four qualifying questions before building: whose problem is this (named persona, quantified)? what does winning look like for them? what would make them refuse to use it (not on their platform, cumbersome, data security)? would it change a decision, and which one?",
      "Anti-patterns of building the wrong thing: shipping features fast with poor adoption; users trying a feature but not returning; the demo being the deliverable ('the demo system is not a live system'); a PRD with no real user testers.",
      "The SDLC itself doesn't change much because of AI — the toolkit used within it does; it's an 'old skill, new economics' shift, since everyone has access to the same models and the differentiator is who understands the business need better."
    ],
    "takeaways": [
      "Run a mapping session before you build — a user story map, business model canvas or any mapping that highlights where the value lives — and only then start designing.",
      "Track the four questions (whose problem, what winning looks like, what would make them refuse, what decision it changes) in a plain markdown file in your repository so the AI can read it and get far more context than a generic prompt like 'build us an agent that handles support'.",
      "Change the KPI: drop 'number of features shipped last quarter' and count features that are actually used more than twice; measure frequency of an activity rather than time of usage or time spent on site.",
      "Move subject matter experts into customer- and client-facing positions — not necessarily to become product owners, but so their experience of what worked and what didn't is in the decision about what gets built.",
      "Run the comparison yourself on a real use case: build it with user stories first versus without, and compare the results."
    ],
    "topics": [
      "requirements elicitation",
      "story mapping",
      "user stories",
      "product management",
      "agents",
      "product metrics",
      "business analysis",
      "ai-assisted development"
    ],
    "tools": [
      "VisualLabs",
      "Ford (Henry Ford 'faster horse' analogy)",
      "LinkedIn",
      "Markdown files in the repo as AI context"
    ],
    "quotes": [
      {
        "text": "You can prompt your code, you can prompt your AI, you can prompt your whole specification, but you can't prompt your room.",
        "at": "02:59",
        "url": "https://www.youtube.com/watch?v=6bmM45jkMDY&t=179s"
      },
      {
        "text": "The chances are that you are replicating what already exists because AI by definition is coded to give you the most common answers.",
        "at": "03:37",
        "url": "https://www.youtube.com/watch?v=6bmM45jkMDY&t=217s"
      },
      {
        "text": "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.",
        "at": "12:46",
        "url": "https://www.youtube.com/watch?v=6bmM45jkMDY&t=766s"
      },
      {
        "text": "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.",
        "at": "12:57",
        "url": "https://www.youtube.com/watch?v=6bmM45jkMDY&t=777s"
      }
    ],
    "words": 2731
  },
  "summary_url": "/#6bmM45jkMDY",
  "transcript": {
    "html": "/transcripts/6bmM45jkMDY.html",
    "txt": "/transcripts/6bmM45jkMDY.txt",
    "vtt": "/transcripts/6bmM45jkMDY.vtt"
  }
}