Shape Up in the Era of AI-Driven Engineering

October 26, 2026

strategy development ai

I was a technical PM at a developer tools company when Claude Code went mainstream. Somewhere around Opus 4.7 it got obvious, fast. Great engineers were suddenly superheroes. Productivity felt like it went up 10x.

Now I'm in a new role, trying to help a different company work this way. And the question I keep landing on is: how do you actually run projects when building is the cheap part?

My answer starts with an old favorite.

Why Shape Up

Years ago I was stuck in enterprise agile. I'd already read Shape Up and run a couple projects with it, and I missed it constantly. It was kind of the chill version of Lean Startup. Shape the work before anyone touches it, bet on it, give it a fixed amount of time, and let scope flex to fit.

At the new company we need something. We don't know exactly what yet. But we love those core ideas. Teams shouldn't start on something until it's been shaped, pitched, and bet on. Projects should have fixed timeboxes. "Done" should mean clear acceptance criteria were met.

What doesn't make sense anymore is the calendar. Six-week cycles and two-week cooldowns were sized for humans writing all the code. That's not the world now.

Fixed time, unlimited team

Here's what I'd argue over a beer:

So the question for every project becomes: what can we get done in a month that achieves the outcome we want?

Shape Up was built around one scarce resource, engineering hours. Everything in it (fixed time, variable scope, the circuit breaker) existed to protect builder time. That's not the bottleneck now. What's scarce is knowing what the problem actually is, human review and judgment, production risk, and the cost of owning whatever ships for the rest of its life.

Shape Up allocated builders. Now it needs to allocate attention.

Building the wrong thing is cheap now

I've built the wrong version of things many times. That used to hurt. Now it's the cheap part. Throw it away and laravel new it, as they say.

I recently built a data integration codebase to kickstart a project team. I told them to throw it away if it wasn't going to work. It's not precious. It's a way to learn what the real problem is before anyone commits to a solution.

That's how I think about shaping now. Shape with code. Spike the risky parts, learn, throw the prototype away. The pitch cites what you learned, not the prototype.

But cheap building cuts the other way too. Agents accept your premise and aim to please. They'll build the wrong thing really well. The moment where an engineer or designer pushes back with "that's not actually the problem" used to happen for free, because humans were slow and had time to think about it. Now it has to happen on purpose.

So I'd add one step Shape Up didn't need: a written Challenge between shaping and betting. Someone other than the shaper writes 3–5 real objections to the problem, the no-gos, and the acceptance criteria, plus how the pitch answers each one. An agent can take an adversarial first pass, as long as a human reads it. It's a doc, not a meeting. No Challenge, no bet.

Saying no when everything is easy

When you can build anything quickly, saying no matters more, not less. "It was easy to add" is how you end up owning a pile of stuff nobody loves.

I really like how the Amp team handles this: "If we don't use and love a feature, we kill it." They're more known lately for removing features than adding them.

That's the bar I want for scope. Not "can we build it" (yes, obviously) but "do we want to own this forever?"

It's also why no-gos are the most important part of a pitch now. Agents build whatever you describe. Boundaries are the only thing that stops them. A pitch with empty or generic no-gos doesn't get bet on.

Appetite is attention

Appetite used to mean "how much time is this worth?" Now I think it's "how much attention and risk is this worth?"

That means review bandwidth, decisions someone has to make, blast radius, and the long tail of owning it. Work touching correctness, auth, billing, or data migrations needs way more review than its line count suggests, so it should count as bigger than it looks.

And just because agents can run five projects at once doesn't mean one person can own five. Every bet gets one named owner who can explain every meaningful decision from memory. If they can't, the bet is too big. That's the size limit, not story points or line counts.

Why a month

A month because the expensive parts of real projects (integration across systems, rolling out data changes, proving it works) don't compress into a week, even when the code does.

Inside that month the owner does a quick weekly gut check, just for themselves. At the end of the month the bet gets a real decision: continue, reshape it as a new bet, or stop. No automatic extensions. "Finish what you start" still holds, but it applies to the problem, not the first solution.

Two more things I'd keep tight:

Where this goes wrong

The failure modes I'm watching for:

We're still figuring out which version of this sticks. The working draft is below if you want to steal any of it.

Appendix: the working draft

Challenge template

# Challenge: [pitch]
Shaper / Challenger / Date / Adversarial agent run (link)

## Objections (3–5)
- Objection → how the pitch answers it → residual risk

## No-gos check
- Specific and non-empty? What did the challenger try to add that was rejected, and why?

## Acceptance criteria attack
- Which criteria are ambiguous or gameable? What evidence would falsify "done"?

## Decision
- Ready for table: yes / no. If no, what must change.
- Residual risks named here become either kill criteria or explicit ownership costs in the bet.

What goes in a pitch

Problem, appetite, boundaries, no-gos, affected systems and repos, acceptance criteria, evidence expectations, kill criteria. Name the rabbit holes, which these days are usually product ambiguity, data correctness, cross-system integration, and rollout rather than technical unknowns.

Appetite tiers

High-risk surfaces (correctness, auth, billing, public-facing numbers, data migrations) count one tier up for review capacity. If the owner can't explain the pitch, no-gos, and acceptance criteria without reading them, the bet counts one tier up for concurrency too.

Weekly owner checkpoint (15 minutes, not reported)

  1. Remaining unknowns: uphill or downhill? Name them.
  2. Which acceptance criteria got evidence this week? What's missing?
  3. Scope growth: explicit decision or drift?
  4. Can I explain the current system and the end state from memory?
  5. Is the thin slice livable? What did using it change?
  6. (Optional) Did any risk from the Challenge just become real?

Monthly checkpoint: continue, reshape, or stop

  1. Were the original unknowns resolved with evidence, or are there new ones that change the appetite?
  2. Are acceptance criteria met with the agreed evidence?
  3. Has scope gone past the original no-gos? Document the decision or kill the growth.
  4. Can the owner explain every meaningful decision and the system as it exists now?
  5. Did we hit a kill criterion?
  6. What are we now committed to maintaining that we weren't before? Still OK with that?

Stopping is low ceremony: write the decision record, carve anything salvageable into a smaller re-shaped bet (or drop it), archive the pitch with the reason.

Decision record

## Decision — [date]
- Outcome: continue / reshape / stop
- What we learned that changed the picture
- What we chose and what we rejected, with why
- Scope changes and no-gos revisited
- Challenge residuals resolved or carried forward
- New ownership commitments
- Next bet (if reshape) or archive reason (if stop)

Principles

Show Comments