The Experiment That Reveals Who Will Survive the AI Era

We ran an experiment. A domain expert and a senior developer, both using Claude Code, both building the same app: a simple Apple Watch application to display train schedules.

Same tools. Same goal. Very different results.

The Senior Developer’s Approach

The developer did what senior developers do. He architected the solution properly:

Domain-Driven Design
Hexagonal architecture
Clean separation of concerns
Proper abstractions

The code was beautiful. The structure was textbook-perfect.

But the data displayed was wrong. The UX made no sense. The app showed information that no commuter would ever need, and buried the information they actually wanted.

He built a technically excellent app that solved the wrong problem.

The Domain Expert’s Approach

The domain expert knew exactly what commuters need. She takes that train every day. She knows:

Which information matters at a glance
What decisions riders make in the moment
Which edge cases actually happen vs. theoretical ones

Her problem? She didn’t know how to build it. She’s not a developer.

But she had Claude Code.

The Twist

Here’s what happened:

The senior developer, even with AI assistance, couldn’t finish. He kept refining the architecture, adding layers of abstraction, making the code “better”—while the actual product drifted further from useful.

The domain expert, with a few tips on app architecture, shipped a working app. It wasn’t architecturally elegant. But it showed the right data, in the right way, at the right time.

One app sits in a repo, technically impressive and completely useless.

The other app is on her wrist, used every morning.

What This Means

This experiment crystallized something I’ve been observing for years:

Technical excellence without domain knowledge builds the wrong thing perfectly.

Domain knowledge without technical skills builds the right thing imperfectly.

In the pre-AI era, “imperfect” was often a dealbreaker. You needed the developer.

In the AI era, the gap is closing fast. Claude Code didn’t turn the domain expert into a senior developer—but it gave her enough technical capability to ship something useful.

The developer’s deep knowledge of DDD and hexagonal architecture? Claude already knows that. It’s commoditized.

The domain expert’s intuition about what commuters actually need? That’s not in any training data.

The Product Engineer Question

This brings us to the central question: Who has a better path to becoming a Product Engineer?

A Product Engineer combines technical skills with deep customer understanding and business acumen. They don’t just build—they decide what to build and why.

Our experiment suggests the answer:

The domain expert learning technical concepts has a clearer path than the developer learning domain expertise.

Why? Because:

AI is democratizing technical skills faster than domain knowledge. You can prompt your way to decent architecture. You can’t prompt your way to understanding why a commuter glances at their watch differently at 7:45am vs 8:15am.
Domain knowledge compounds. Every day the expert takes that train, she learns something new about the problem space. The developer, no matter how skilled, is starting from zero.
The hard part is knowing what to build. “How” is becoming easier every month. “What” and “why” remain stubbornly human.

The Uncomfortable Implication

If you’re a developer who has spent years perfecting your craft—learning design patterns, mastering frameworks, architecting elegant systems—this might feel threatening.

It should.

Not because your skills are worthless. But because they’re no longer sufficient.

The developers who thrive in the AI era won’t be the ones who write the cleanest code. They’ll be the ones who deeply understand the problems they’re solving.

That means:

Talking to customers (not just reading tickets)
Understanding business models (not just APIs)
Caring about outcomes (not just outputs)

The senior developer in our experiment could have built a great app. But he would have needed to ride that train for a month first. To watch people use the existing schedule apps. To feel the frustration of missing a connection because the display prioritized the wrong information.

He didn’t. He went straight to the code.

The Moraleja

If you’re a developer: Learn the domain. Not casually. Deeply. Your architectural skills are becoming table stakes. Your understanding of customer problems is becoming your edge.

If you’re a domain expert: The barriers to building are falling. You don’t need to become a developer. But you might be able to become a Product Engineer faster than you think.

And if you’re building a team: Hire for curiosity about problems, not just skill with solutions. The AI can help with solutions. The curiosity is irreplaceable.

This experiment reflects a core thesis of “The Broken Telephone”—that the future belongs to people who combine technical capability with deep customer understanding. The traditional separation between “business” and “tech” is collapsing.