I've been using AI coding tools seriously for about eighteen months now. Claude Code, Cursor, Copilot — the full stack. And somewhere along the way, I noticed my job had quietly changed.

I wasn't writing less code. I was making more decisions.

Not decisions about implementation — the AI handles most of that. Decisions about what should exist. What's worth building. What "good enough" looks like. When to stop iterating.

The same shift is happening everywhere I look. Engineers, founders, ops people, domain experts — they're all doing work that used to belong to a specific job title.

AI hasn't turned everyone into a software engineer.

It's turned everyone into a product manager.

The bottleneck moved

Most commentary about AI coding focuses on speed and cost. Code gets written faster. Prototypes appear in hours. Small teams build what once required departments.

All true — but it misses the more important point.

Execution is no longer the scarce resource. Direction is.

When tools can scaffold, refactor, test, and document software almost instantly, the limiting factor isn't implementation. It's intent.

What are we actually trying to build? Who is it for? What does "good" look like? What trade-offs are acceptable?

Those questions used to belong to a specific role. They no longer do.

What senior engineers actually do now

I was talking to a friend recently — fifteen years in backend engineering, now leading a small team. He described his typical day: maybe 20% of it involves writing code directly. The rest?

  • Holding a product vision in his head
  • Breaking that vision into agent-sized tasks
  • Deciding architectural constraints before prompting
  • Reviewing AI-generated output critically
  • Rejecting, refining, iterating
  • Deciding when something is "good enough"

The value he provides isn't keystrokes. It's judgement.

AI hasn't replaced engineering skill — it's exposed what the real skill always was: taste, system-level thinking, and an instinct for trade-offs.

In practice, he's doing two jobs at once: engineer and product manager. He just doesn't fill in a Jira ticket to do it.

The non-technical builders crossed the same line

The more interesting shift is happening outside engineering.

I've watched several non-technical founders build real software over the past year using AI tools. They call it "vibe coding" or "no-code" — but what's actually happening is more subtle.

The moment a non-technical user:

  • Describes a user problem
  • Chooses which features matter
  • Decides what can wait
  • Reviews AI output and says "yes" or "no"
  • Iterates based on results

…they're no longer "using a tool".

They're owning a product.

They may never write a line of code, but they're doing the same cognitive work that product managers have always done. AI has simply removed the final barrier to execution.

Why vibe coding still requires product thinking

There's a tendency to dismiss this as unserious — typing vague prompts and hoping something useful appears.

That works, briefly, under very specific conditions: small scope, low failure cost, single user, no long-term maintenance.

The moment you want reliability, users, integrations, or change over time, the same old questions reappear:

  • What is the minimum viable version?
  • What happens if this breaks?
  • What do we not support?
  • How will this evolve?

AI doesn't eliminate product thinking. It forces it earlier.

The difference is that instead of those decisions being spread across documents, meetings, and roles, they now live inside a single person's head — the person driving the agent.

From writing code to managing capability

One way to understand the shift: look at the workflow.

The old model:

Idea ? Spec ? Code ? Product

The new model:

Intent ? Constraints ? Agent ? Review ? Iterate ? Product

The critical role isn't the agent. It's the human setting intent, defining constraints, and judging output.

That role is — by definition — product management.

Bad management gets amplified too

Here's the part that doesn't get talked about enough.

As execution becomes cheap, the quality of decisions becomes visible. AI doesn't just amplify good management. It amplifies bad management too.

Poorly framed problems get solved faster — badly. Unclear goals produce more output, not better outcomes. Indecision creates infinite iteration.

I've seen this firsthand. A project that should have taken a week stretched to three because nobody had decided what "done" meant. The AI kept building. The humans kept changing direction. More code, less progress.

We're about to see more software built than ever before — and more unusable software than ever before. The gap between "it works" and "it matters" is widening.

The winners won't be the people who know the tools best. They'll be the people who know what to build, why to build it, and when to stop.

Product management escaped its job description

For decades, product management was a function you hired for.

In an AI-first world, it's becoming a baseline skill — like writing or spreadsheet literacy once were.

You don't need to call yourself a product manager. You don't need a roadmap template or a backlog tool. But you do need:

  • Clear thinking
  • Problem framing
  • Trade-off awareness
  • The ability to say "this is good enough"

AI has democratised execution. It has not democratised judgement.

The takeaway

If you're building anything with AI tools — whether you're an engineer, a founder, or someone who's never written code — you're already doing product management. You just might not have named it yet.

The skill worth developing isn't prompt engineering. It's learning to hold a clear picture of what you're trying to build, why it matters, and what trade-offs you're willing to accept.

Direction is the new bottleneck. The people who learn to provide it — clearly, consistently, decisively — will build things that matter.

Everyone else will just build more.