Story points are useless when building is the easy part

I’ve seen an agent build an entire product end to end, every feature one-shotted, in under five hours.

Meanwhile, somewhere, six people are debating whether a ticket is a three or a five.

For work like this, story points are useless. The estimate needs to justify its cost. “We always do it” is a fairly expensive answer.

The interesting question is what happens to software development when building stops being the hard part.

Where did the complexity go

Upstream, for a start.

Who actually has this problem? What have we misunderstood? What should the product do? What should it absolutely not do?

An agent can implement a bad requirement very efficiently. Now you get to be wrong faster, with a functioning interface.

Then downstream. Distribution. Marketing. Getting someone to try the thing. Giving them a reason to come back.

A product nobody knows about or uses is useless. Shipping it in five hours doesn’t change that.

That build also doesn’t establish security, reliability or demand. Engineering constraints still matter. A database migration and a disposable experiment deserve different scrutiny. Cheap construction isn’t permission to ignore consequences.

But don’t preserve the entire old process because some work still needs it.

What are we planning now

I’d start with the bet rather than the ticket.

We think this person has this problem. We think this product will change this behavior. Here’s how we’ll reach them and find out.

The working loop becomes:

Research → hypothesis → build → distribute → observe usage → decide.

Sometimes the right experiment is a landing page. Sometimes it’s a feature. Sometimes it’s the whole product. If building the whole thing is cheap enough, forcing it through twenty estimated stories can cost more than it saves.

Before building, write down enough to make the bet testable:

• Who has the problem, and what behavior would show you’ve helped?
• How will those people encounter the product?
• What are the spending and risk boundaries?
• What evidence would make you continue, change direction or stop?

A few lines may be enough. Please don’t turn this into a certification.

Should the agent estimate instead

Maybe. If the answer changes a decision.

Let it inspect the repository, surface dependencies, propose a plan and flag unknowns. That’s useful when you’re deciding whether a migration is safe, which approach to take or whether a commitment is realistic.

But having AI assign points to every plan can recreate the same ceremony at machine speed.

Compare forecasts with completed work and actual outcomes. Ranking one imaginary plan against another doesn’t magically produce calibration.

Keep complexity and risk separate from elapsed time and product value. A difficult implementation can still be worthless. An easy one can matter enormously.

If a bounded build gives you the answer more cheaply than an estimate, build it.

What happens to sprints and WIP

A sprint can still be a useful alignment rhythm. It shouldn’t become a waiting room for work that’s ready to ship. Scrum doesn’t require story points or waiting for the Sprint Review to release value.

And fifty agents don’t mean you should run fifty product bets.

Limit work in progress around the constraint you actually observe. Maybe it’s engineering. Maybe it’s access to customers, distribution capacity or the time needed to see whether anyone comes back.

DORA’s WIP guidance explicitly warns against looking at only one part of the journey from idea to customer.

Count the live bets waiting for evidence, not just the tickets waiting for code review. More output can mean a bigger pile of unanswered questions.

Do we need a new SDLC

Maybe. “Agentic Agile” and “AI-DLC” already exist as labels.

The useful question is what we’d change underneath them.

I’d want the lifecycle to tell me which uncertainty we removed, what reached people, what they did and what we should try next.

Keep the controls that protect people and systems. Keep the planning that improves decisions. Drop the rituals whose cost exceeds their usefulness.

If the AI factory makes building abundant, managing coding capacity can’t remain the whole job.

A product nobody uses is just a very efficiently completed backlog.