Most product teams run on five tools that don’t talk to each other, and a person carrying context between them. We built Autonomous Product Delivery so the whole loop runs as one system, led by product teams.
So we asked Tammuz Dubnov, our co-founder and CTO, about it. What it actually is. What one turn of the loop looks like. Why enabling PMs with a tool wasn’t enough. Where the line sits between the work a product team signs off and the work an engineer should. The one number he tracks. What surprised him using it himself. And whether you could just build this. One line from him on each, and what it means.
1. What is Autonomous Product Delivery
The Autonomous Product Delivery loop starts with the system noticing something in your analytics, building the answer, and asking you to look. Tammuz’s version: “What if the system looked at the analytics, figured out the next thing to do, did it, pinged you: hey, take a look, what do you think?” You sign off, it goes to a pull request, your engineers merge it. Nobody filed a ticket.
2. One turn, start to finish
Signals in, a brief with the evidence, before-and-after pictures you can judge at a glance, then one click to send it to dev. What lands in your engineers’ queue is, in his words, “code that is production grade, on top of your codebase, with your engineers’ coding practices already built in.” And the turn ends where the next one starts: “all of that goes back to a learning mechanism, so that the next cycle is even smarter.” Because it’s one system on one codebase, the learning stays.
3. Why we built it
A tool that helps one person is still that person doing the work. The jump was to a system that takes the work: “agents take work end to end and truly offload it from you, so you can work on the important, complicated core IP while agents take care of everything else.” That’s his definition of an autonomous company, and the reason enabling PMs with a tool was never going to be enough.
4. Where the line is
This is the answer to “does it replace engineers.” The system draws the line at what you can personally validate and sign off: “the agent’s going to stop you at the work that is user-facing, that you can personally validate, that you have the authority to sign off on.” Past that line it leaves work for an engineer on purpose, “because that’s the side where you want that developer’s judgment call.” And the engineers approve every merge either way.
5. The metric that counts
“The golden metric is one-shot PR merged. Meaning no comments, no issues detected, solid code quality that an engineer will see, approve, and merge.” The metric is set by the people who guard the codebase, so it can’t be gamed from the product side. Every review comment is a lesson the system takes into the next turn, and the target is a PR that needs none.
6. It goes deeper than you’d expect
The CTO who built it gives it less instruction over time: “I’ve lately started giving it shorter and shorter prompts, just to say: hey, this is the direction, you fill in the rest. Because I found it does a better job than if I try to fill in the details.” One request about output artifacts came back as a brief built from the analytics, usage data, an old ticket, and a dig through Slack. That’s what a system that knows your product looks like from the inside.
7. Can you just build this?
You can stitch five tools together and run the loop yourself. Tammuz’s answer: “You can do anything if you’re determined enough. But you’re in the loop.” Insight from one tool, fed to the next, cross-referenced with the code, prototyped, aligned, signed off, end to end, by you. “Boy, that’s a lot of labor.” Every handoff runs through a person, which is the problem the loop was built to remove.
Seven moments, one thread: the loop only works as one system. Five tools in a trenchcoat is still five tools, and you’re the one in the coat.
Want the whole loop end to end, on a real codebase? Here’s the full demo.
See what it looks like on your own codebase. Book 20 minutes.
Discover what the future of product teams looks like!
