DEV Community

Abby Lehr
Abby Lehr

Posted on

No questions before the first demo: how agents made us move our product engineering handoff

#ai #github #agents #software

I'm Abby, a growth engineer at a small startup. This year, the way work reaches me changed completely. This post covers what broke, what we changed, and the one rule that made it work.

What broke

For years our team ran on a familiar ratio: roughly one or two people in product to five engineers.

Product took an idea, researched it and shaped it in detail. Then they handed it over, and engineers finished the planning, built it and shipped it.

In February two things happened at once. Our CEO and head of product moved from London to the US, eight hours away from the engineers. And agents got good enough that product people could write real code.

That broke the ratio. By the time product had taken a customer problem, researched the options and decided on the shape of a solution, they knew enough to hand it straight to an agent and get a good result in a couple of hours. That was faster than handing it to an engineer, and they could do it at any hour, which mattered with eight time zones in the way.

Rebalance the team, or rebalance the handoff?

We had two options. We could cut engineers, or we could move the handoff.

We moved the handoff, and it was the right call.

Product now hands over an idea, not a spec. Engineers do the research, shaping and planning, then hand the build to an agent. My job changed from:

  • detailed specification → high-quality code

to:

  • ambiguous problem → high-quality code

Engineers now make many of the smaller product decisions that used to be settled long before the work reached us. Two things made that possible.

Rule: no questions before the first demo

When an engineer picks up a piece of work, they can't ask anyone anything until they've produced a demo. After that, they can talk to whoever they like, however they like.

It sounds harsh, but it does two useful things:

  1. It forces product to put what really matters into the handover. The engineer can't come back and ask, so the important context has to be written down up front.
  2. It forces the engineer to own the tradeoffs. The many small "how" decisions stop going back to product and get made by the person closest to the code.

The engineer drives instead of the product manager, and that made the whole transition much easier.

do…while vs. until

The second thing was a principle. We care a lot that engineers still do engineering. That means understanding the system we're building, and making the important tradeoffs we'll have to support later, rather than leaving them to the AI. Whether we write, or even read, every line of code matters much less.

Most AI coding tools we tried work like a do…while loop:

do {
  agent.decide();
  agent.write();
} while (!looksDone());
// ...and now you reverse-engineer its decisions from the diff
Enter fullscreen mode Exit fullscreen mode

The agent makes all the decisions, and you're left trying to understand them afterwards.

We wanted an until loop instead:

const decisions = humans.decide();   // the interesting part
until (code.matches(decisions)) {
  agent.build();
}
Enter fullscreen mode Exit fullscreen mode

Humans make the interesting decisions, and the agent loops until the code matches them.

Until

That loop became the product we're building, called Until. It's a Git-backed, plan-driven workflow for you and your coding agents:

  1. Plan: you and your agent draft the outcome, the approach, and what's out of scope.
  2. Review: a teammate approves the plan or sends it back with comments. This is where your attention goes, because it's where the decisions are.
  3. Build: approval releases the plan as jobs. Agents claim them, leave handoff notes as they go, and ask you when a decision is yours to make.
  4. Check: an agent review compares the code with the approved plan and lists every place they differ.

It runs locally in your own Git repo, with no server, no account and no telemetry. It works with Claude Code, Cursor, Codex, Amp, OpenCode, or any agent that can run a command.

We're not public yet, but you can join the waitlist, or apply for early access if you want to try it on a real project.

The long version

Dylan, our CEO, went through all of this in his DevOpsDays talk, Pull requests are dead, long live peer review:

How has your team's handoff between product and engineering changed since agents got good? And has anyone else tried a "no questions before the demo" rule? I'd love to hear how it went.

Top comments (0)