How AI Made Me a Faster Builder (And a Worse Product Thinker)

A few weeks before The Problem-First Method launched, two teammates at Ambiki sat me down for what was, in every practical sense, an intervention.

Not a sprint retro. Not a product review. An actual “we need to talk” conversation.

Which, as a founder, is rarely a great start to a morning.

The dopamine of instant momentum

I remember opening the call already halfway distracted, because I’d been in the middle of building something. Or maybe three somethings. That was part of the problem.

AI had quietly changed the shape of my work over the previous few months.

What used to take days now took hours. What used to require careful scoping could suddenly be prototyped before lunch. I could go from idea → PR → working implementation with almost frightening speed.

And honestly? It felt incredible.

There is a particular dopamine hit that comes from watching an idea materialize instantly. You type a prompt. The scaffolding appears. You refine it. The code compiles. The feature works. Another checkbox disappears from the backlog.

For someone who has spent most of his career constrained by time, energy, and engineering bandwidth, it felt like suddenly discovering gravity had been turned down.

I was shipping constantly.

Too constantly.

“You’ve stopped starting with the problem”

One of my teammates finally said it plainly:

You’ve stopped starting with the problem.

That sentence landed harder than I expected.

Because they were right.

I had started building the way casinos are designed.

No clocks. No windows. Continuous stimulation.

The feedback loop had become so fast that I stopped pausing long enough to ask the uncomfortable question:

Should this exist at all?

The irony, of course, was brutal.

I was literally weeks away from launching a book called The Problem-First Method.

A book whose entire thesis is that skipping the problem is the most expensive shortcut in product development.

And there I was, doing exactly that.

Not maliciously. Not recklessly. Just… incrementally.

That’s the dangerous part.

Most bad product decisions do not arrive with dramatic music.

They arrive disguised as productivity.

When friction protected us

A decade ago, building software created natural friction.

You had to think before you built because building itself was expensive.

Engineering time was scarce. Prototypes took real effort. Entire ideas died naturally because implementing them sounded exhausting.

Those constraints were frustrating.

But they also protected us.

AI has removed an enormous amount of that friction.

And that is both wonderful and dangerous.

Because the cost of creating has collapsed.

But the cost of building the wrong thing has not moved an inch.

You still pay for it.

You pay in customer confusion.

You pay in onboarding complexity.

You pay in support tickets.

You pay in edge cases.

You pay in the quiet accumulation of “temporary” decisions that never quite leave the product afterward.

Every unnecessary feature becomes another block in the Jenga tower.

And unlike demos, products do not get simpler over time by accident.

Activity is not clarity

One of the easiest traps in the AI era is confusing momentum with progress.

You feel productive because output is happening continuously.

PRs are flying.

The roadmap looks alive.

Slack notifications never stop.

But activity is not the same thing as clarity.

In some ways, AI makes problem-first thinking more important than it was before.

When building was expensive, bad ideas naturally died young.

Now they survive long enough to become architecture.

That changes the responsibility of product leadership entirely.

The bottleneck is no longer implementation.

The bottleneck is judgment.

Which problems deserve to exist in the finite space of your product?

Which customer pain is actually painful?

Which request is merely loud?

Which friction is useful?

Which workflows are solving root causes versus generating feature-parity theater?

Those questions matter more now, not less.

Because if AI allows every company to build almost anything, then the strategic advantage shifts to the teams that know what not to build.

Velocity without orientation

After that conversation, I started noticing how subtle the drift had been.

I wasn’t skipping discovery meetings intentionally.

I wasn’t abandoning customer empathy.

I simply started compressing the “problem” phase because the “solution” phase had become intoxicatingly fast.

A dangerous little voice appears:

We can always adjust later.

Sometimes that’s true.

But software has memory.

Every rushed abstraction leaves residue.

Every speculative feature teaches customers something about your product.

Every implementation creates future maintenance obligations.

And every hour spent building the wrong thing is still an hour not spent solving the right one.

AI didn’t create this problem.

It amplified a very human one.

Builders like building.

We always have.

AI just removed enough friction that many of us can now outrun our own reflection.

A compass matters more when your vehicle gets faster.

That was the real lesson of the intervention.

My teammates were not warning me about AI.

They were warning me about velocity without orientation.

Speed does not absolve you of direction.

It just gets you lost faster.

Restraint is a competitive advantage

When I first started writing The Problem-First Method, I thought the book was primarily about avoiding wasted engineering effort.

Now I think it’s about something deeper.

Restraint.

The discipline to pause before building.

The humility to admit a customer request might not represent the actual customer problem.

The willingness to sit inside ambiguity long enough to understand what truly deserves to exist.

That work feels slower.

It feels less glamorous.

Sometimes it even feels unproductive.

But increasingly, I think it may become the highest leverage skill in modern product development.

Not building faster.

Deciding better.

The intervention worked, by the way.

At least temporarily.

I still catch myself drifting toward solution-first thinking. Probably more often than I’d like to admit.

But now I recognize the feeling sooner.

Usually it sounds like this:

This would be easy to build.

Which is almost never the right first question.

The better question is still the old one:

What problem are we actually solving?

Turns out I didn’t just write this book for founders or PMs or product teams.

I wrote it for myself too.