{`Two-hour AI-native training sessions where we barely mention Claude Code — and run roleplay instead`}

Software Got Easy. Empathy Didn't.

Lukas

Lukas

Jun 29th 26

4 min Read

I've been running two-hour sessions to train our team into AI-native builders. Here's the part that surprised me: we barely talk about Claude Code, Codex, or loop engineering. The tools come up almost never. What we actually do, over and over, is roleplay.

I expected the opposite. If the goal is an AI-native team, surely the point is to drill the latest tools until they're muscle memory? But session after session, it became clear the real bottleneck lives somewhere else entirely.

The mission: a 60-year-old salon owner in New York

The exercise I give the team goes like this. I play the client — call him Lukas.

"Hi, I'm a woman in my sixties running a hair salon in New York. Customers come two ways — walk-ins and phone bookings. I work with five partner stylists, and each offers a different set of services. They're at different seniority levels, and pricing changes by level. My commission also varies by stylist, anywhere from 30% to 50%. I need an app. I don't really understand the technical stuff, so just figure it out and make running the salon easy for me."

I deliberately hand over zero technical spec. "Just figure it out and make it easy" — the exact thing real clients actually say.

90% of people freeze right here

Give someone this mission and roughly 90% freeze. What's striking is that it isn't tied to any one role or country. Domestic or overseas, backend or frontend, designer or PM — most people find it genuinely hard to imagine how another person (the customer) will use the thing, and what they'll feel in that moment.

It isn't a coding-ability gap. The questions that stop people cold are these: What does this owner dread most on a packed Saturday afternoon? When she's juggling a phone booking and running out of hands, what does she want to see on the screen? The block isn't the answer — it's the empathy itself. So that's what we train, on repeat.

The follow-up questions that keep digging into one product

So I keep firing questions at the same scenario. The goal isn't to land the "right" answer — it's to build the muscle of stepping inside the user's head.

  • The waiting-customer scenario — "A walk-in named Mike comes in asking for Stylist A. But A is in demand and the wait is three hours. Mike says he'll wait. What does the software need to consider to handle this?"
  • The commission-change scenario — "Starting in July, I want to raise Stylist B's commission from 30% to 35%. What does the system need to account for?"
  • The first-screen scenario — "This app targets salon-goers living in New York. When a user lands on the home screen, what should they see first? (1) the stylist list, (2) the service list, or (3) the calendar?"

Every one of these leads with who is standing in front of this screen, and in what state of mind — before it ever gets to how do we build it. Mike's impatience as he waits, Stylist B's stake in a commission hike, the intent of a New Yorker opening the app for the first time. Start anywhere else and no feature can be the right answer.

Software got easy. The thing to train now is empathy.

After running these sessions back to back, the conclusion is clear. Software has become almost trivially easy to make. AI has knocked down nearly the entire wall of implementation. So the area genuinely worth training is no longer the hands that wield the tools — it's the ability to fully empathize with the user.

When implementation was scarce, knowing how to build was the edge. Now that the scarcity is gone, the remaining edge is the ability to draw who you're building for, what, and why straight out of that person's emotions. That's exactly why we keep summoning a hair-salon owner in New York into the room.

Lukas

Lukas

Founder

Dad of 2 Kids

Follow me:

  • facebook
  • linkedIn
  • instagram
See more blogs