← Building

From Vibe Coder to AI Product Builder

A thought from building with Cursor and studying other harnesses: when AI implements, the scarce job is product judgment—kept alive through tight loops.

Capability, AI & the Future of Work

Published Jul 15, 2026 1 min read

The Default

Becoming a better coder—or a better prompter—is how you win as AI writes more software.

A Different Perspective

Becoming the person who owns the customer problem, product taste, and loop design is how you win while AI implements.

Why It Matters

Without that shift, vibe coding ships volume without ownership; with it, harnesses like Cursor accelerate learning instead of replacing it.

In this essay

Today I realized something strange.

AI writes almost all my code now.

So what exactly is my job?


The confusion

Am I still a product manager?

A designer?

A founder?

Have I become a developer?

A tech architect?

Or just someone prompting AI?

The labels stopped fitting cleanly.

And for a while that felt like a problem.

Diagram · The label fog

PM Designer Founder Developer Architect Prompt engineer Product judgment In the loop

The job titles blur. The work that stays scarce is clearer.


The realization

Then I looked at where the hours actually go.

Not at which title I could claim.

What I spend my time doing:

AI handles much of the implementation.

I stay in the loop for everything that decides whether the product is worth shipping.

Diagram · Two ways to ship with AI

Vibe coding

Prompt → hope → paste → next feature. Speed without ownership. Code appears; product taste often doesn't.

AI product building

Customer → intent → generate → review → correct → ship. AI writes modules. You still own the product.

Same tools. Different posture. The second one compounds judgment.


Questions that changed my thinking

I'm not an AI researcher.

I'm learning by building—mostly in Cursor, keeping myself in the loop, while looking at other harnesses (Devin-style agents, newer ones I'm only considering).

A few questions pulled me out of the title fog.

Why do we need multiple AI agents?

Because one brain doing everything is a myth—even when the brain is artificial.

One agent can write a module.

Another can review.

Another can explore a risky refactor while you protect the product spine.

Specialization reduces chaos.

But more agents without clearer ownership just multiplies noise.

The scarce skill isn't "run more agents."

It's knowing when parallel help helps—and who (you) still owns the outcome.

What's loop engineering?

It's the craft of designing your feedback cycle with AI.

Not: dump a giant prompt and disappear.

Yes: intention → generate → review → correct → ship—tight enough that taste stays in the room.

Loop engineering is how you keep learning while the model writes code.

If the loop is loose, you become a spectator of your own product.

If the loop is tight, AI accelerates you without replacing your judgment.

Interactive · How close do you stay?

Spectator mode

One big ask. Hope the output is done. Fast to start. Slow to trust. Easy to ship something you don't understand.

"Did this actually solve the customer problem?"

Builder in the loop

Short cycles. You steer. Cursor-style harnesses shine here—code stays visible; corrections compound into taste.

"What should we try next, given what we just learned?"

Longer autonomous runs

Devin-style agents can take bigger chunks. Useful when the task is scoped and reviewable. Dangerous when judgment should have stayed human.

"Did I define the outcome clearly enough to trust a long run?"

Harnesses change how long you can leave the loop. They don't remove the need for one.

What's the difference between Cursor and Devin?

In simple language:

Cursor is a collaborative workbench. You stay close to the files. You talk, edit, reject, redirect. The default loop is short.

Devin-style agents aim for longer autonomous runs—more "go do this chunk" and come back for review.

Neither is "the future" alone.

They're different distances from the steering wheel.

I build day-to-day in Cursor because I want to upgrade my knowledge while shipping—not outsource learning.

I'm watching longer-agent tools (and newer names people are experimenting with) to learn when delegation helps without hollowing out judgment.

If AI writes the modules, what does an architect do?

When modules get cheap, architecture gets expensive in a new way.

Not "draw boxes because the title says architect."

Decide boundaries.

Name what must stay simple.

Catch the wrong abstraction before ten agents amplify it.

Choose which trade-offs the product can live with.

An architect in this era is less a gatekeeper of code and more a guardian of coherence.

When anyone can generate a module, the scarce skill is knowing which modules should exist—and how they should talk to each other.

Where I am today

I'm not an AI expert.

I'm learning in public.

I'm somewhere between a founder, a product thinker, and an AI-assisted builder.

I ship by prompting—on purpose.

I stay in the loop—on purpose.

I treat new harnesses as experiments in method, not as identity upgrades.

The portfolio side of my work is where proof lives: journey, craft, case studies.

This essay is the reflection layer—what's changing in how I build.


Closing thought

Maybe the future isn't about becoming the best coder.

Maybe it's about becoming the person who can translate customer problems into products—while AI handles more and more of the implementation.

That doesn't make coding irrelevant.

It makes judgment, taste, and loop design the compounding skills.

I'll leave you with the question I'm sitting with:

What part of software development do you think humans will own five years from now?

TL;DR

AI wrote the code. I still own the product.

Titles blur when models implement. The hours don't.

Customer. Flows. Scope. Trade-offs. Taste.

Loop engineering > prompt dumps.

Cursor keeps you close; longer agents need clearer ownership.

When modules are cheap, coherence is the job.

Humans keep the customer problem—for as long as that stays hard.

Continue Reading

Related essays