AutonomyAI Moves Product Questions Into Pull Requests

The mistake is to treat AutonomyAI’s new feature as a faster way to write tickets. That framing keeps the old workflow intact: a PM turns a question into a specification, engineering turns the specification into code, and the PM returns later to review what happened. On September 24, AutonomyAI released Discover Mode, which it says takes a PM from an initial product question to a review-ready pull request without a manual handoff. The important change is not that one more system can produce code. It is that the specification step no longer has to be the boundary between product and engineering.

That puts a different question in front of product teams: what does a PM oversee when the path from discovery to build is a single autonomous pipeline? The answer cannot be a better template for handing work over. It has to be a working model for deciding which questions the pipeline may pursue, what evidence should count, and where a human review still changes the outcome. The announcement from AutonomyAI makes a specific promise about the workflow, from product question to review-ready pull request. It does not, by itself, tell us how teams should judge the quality of the discovery or implementation. That gap is where the PM job moves.

The handoff disappears

Think about a familiar Monday request: “Why are new users abandoning onboarding?” In a conventional team, that question might become a discovery brief, then a set of engineering-ready requirements, then a pull request for someone else to inspect. Discover Mode is designed to carry the question through that chain without the manual transfer. The useful mental shift is to stop seeing the output as a ticket that happens to be detailed. The output is a proposed change that has already crossed into implementation, ready for review.

That changes the unit of PM work. You are no longer only specifying what another team should build. You are setting the conditions under which an autonomous system can investigate and build on your behalf. A good question now needs a clear product boundary. “Improve onboarding” is broad enough to invite an unhelpful search. “Find a change that addresses the largest identifiable drop in onboarding” gives the system a direction, while still leaving the final judgment with the team. The distinction matters because a review-ready pull request can be easy to inspect and still be aimed at the wrong problem.

The PM workflow shifts from handing off specifications to supervising decisions that arrive already attached to code.

The pull request becomes the visible end of a much longer product action. That means review should not begin and end with “does this implementation look right?” It should also ask whether the original question was interpreted correctly, whether the chosen change answers it, and whether the proposed scope is appropriate. AutonomyAI’s announcement supports the first part of this shift, the end-to-end movement from question to pull request. The second part, how a team evaluates the reasoning inside that movement, remains a practice teams will need to establish for themselves.

Make oversight operational

The practical response is not to write larger prompts and hope for better work. Start with a small, repeatable review routine. For each Discover Mode run, record the product question, the decision the team expected to make, and the pull request produced. At review time, compare those three things in order. Did the implementation address the question, or merely produce plausible work? Did the scope stay inside the decision the team was trying to make? What would you reject even if the code were clean? This turns oversight into a product activity rather than a vague feeling that someone should keep an eye on the system.

You should also decide which questions are suitable for autonomous discovery-to-build work before putting the feature into a regular team rhythm. A question with a clear product boundary and an inspectable proposed change is easier to supervise than one that quietly contains a strategy decision. The distinction is not about whether the system can produce a pull request. It is about whether the team can review the path from the question to that pull request without reconstructing the entire investigation afterward. Nobody outside AutonomyAI’s announcement knows yet how broadly Discover Mode will perform in day-to-day product work, so the sensible first move is a contained trial with explicit review criteria.

The routine I’d start Monday is simple: choose one narrowly framed product question, ask Discover Mode to carry it through to a review-ready pull request, and hold the review around the question before the code. Keep the pull request if it answers the decision you needed to make. Send it back if it only looks finished. The new PM skill is not writing less. It is knowing what must remain yours when the handoff disappears.