A product manager describes what a customer needs and why. The description needs enough detail for the team to judge whether the resulting software does the job. Traditionally, that description becomes a specification or user story in a backlog. In a highly effective agentic development setup, an agent could take that specification, implement the change and open a pull request for review.
The ambition is to make that path reliable enough that a clear product specification routinely leads to software fit for production. That is an aspirational end-state. Each team has to establish which kinds of work its system can handle and where people still need to intervene.
Engineering's responsibility is to build and improve the system that makes this possible. Product management has work to do on both sides. The customer product needs discovery and commercial judgment; the development system needs someone to understand its users, decide which capabilities to invest in and assess whether those investments help.
In agentic engineering, software agents investigate tasks, change code and use tools to check their work. The application they build might contain no AI at all. The question for a software company is how to turn those capabilities into dependable delivery of improvements customers need.
From customer need to a usable specification
Suppose an accounting team spends too long matching incoming payments to invoices. This is a hypothetical example. The team asks for a better matching screen, but a conversation about difficult payments reveals that many arrive without the references needed to identify the invoices. The useful change might be to collect those references earlier in the process.
PM needs to investigate the work with users, designers and engineers before specifying a response. It also needs to establish whether enough customers have this problem to justify the investment. A perfectly implemented request can still leave the original problem unresolved.
A useful specification would explain the intended behavior and how the team will judge it. For this example, it would describe how a reference is collected and retained, what happens when it is missing and which existing payment behavior must remain intact. Examples would make ambiguous cases explicit. The customer objective might be less time investigating unmatched payments while preserving accounting accuracy.
The agent would need access to that specification alongside current product context and technical constraints. An unresolved question about payment allocation should cause it to ask for a decision. It should have enough context to recognize the gap before it implements an invented rule.
PM stays involved as the work develops. A prototype or an implementation attempt may reveal something the team misunderstood. The specification and affected acceptance criteria need to change with that understanding. A clear starting point makes the work possible; feedback keeps it directed at the actual need.
Engineering the path to production
Given a usable specification, a development agent could inspect the application, propose an implementation and produce a pull request (PR). The PR contains a proposed code change. It still needs to meet the product requirements and the engineering standards for release, and a merge alone does not establish successful operation in production.
Engineering builds the system that makes those proposed changes increasingly dependable. Agents need access to the relevant code and product context, an environment in which to run the application, and checks that reveal whether their changes work. They need useful feedback when they fail so they can investigate and correct the problem.
That system should also be able to improve the software as it works. When a performance check identifies a slow query, it could trigger an agent to propose a revision and compare its behavior and execution time with the original. The system could identify duplicated logic, propose a simplification and verify that the required behavior survives. A defect discovered after release could trigger the creation of a regression test for later changes.
Engineers design and extend those capabilities. They determine which changes the system can accept on its own, which require human review and what evidence is required in either case. If an agent can weaken the checks that judge its implementation, a passing result proves little. Acceptance checks and changes to them need independent control.
When a PR requires correction, the team should investigate why. The specification may have omitted a requirement, or the agent may have misunderstood a shared function. It may also have lacked a way to reproduce the problem and verify its change. That diagnosis can guide an improvement that helps subsequent changes reach production with less intervention.
OpenAI's account of an internal agentic development experiment describes engineers giving agents access to application behavior and enforcing architectural constraints through automated checks. Recurring agent tasks also identify inconsistencies and propose repairs. The account illustrates work on the development system itself. Its results depend on that team's environment and investment; they do not establish that another application is ready for the same autonomy.
The development system needs product management
The development system has users and problems worth investigating. Engineers may spend too much time correcting generated changes. Product managers may find that specifications repeatedly stall on questions the system should be able to resolve. Reviewers may lack the evidence needed to decide whether a PR is ready.
Product discovery should establish where this work breaks down and which improvement would be useful across enough future changes to justify its cost. DORA's platform engineering guidance recommends treating internal platforms as products and starting with developer needs. The same reasoning applies to a system used to develop software with agents.
Suppose every payment-related change requires an engineer to assemble test data manually. A system that can prepare and validate representative data could remove that recurring intervention. But the team needs to understand which scenarios it must support, how often they recur and whether the resulting tests help reviewers trust the proposed change.
The capability needs its own intended outcome and acceptance criteria. After it is introduced, the team should assess whether people use it, where they still have to intervene and how much effort it saves after operating and maintenance costs. An impressive demonstration is a poor basis for committing future delivery to it.
Product management helps determine what this internal product should become. Engineering contributes the technical judgment needed to build it. Those responsibilities can be shared within the team; they do not require a separate PM title. The team should name someone to lead discovery with the system's users and maintain its priorities. Product and engineering leadership need to agree who can resolve conflicts between that work and customer commitments.
Evidence for both products
For the customer product, assess whether the change improved the work. In the payment example, that includes time spent investigating unmatched payments and errors that require correction. Talk to users about cases that remain difficult. Product data will miss work outside the application and the needs of people who avoid using it.
For the development system, examine whether it can turn an appropriate specification into a reliable production change. Track where people intervene, how much rework is required and the cost of running and reviewing the work. Include defects discovered after release and the effort needed to recover from them.
A higher merge rate could reflect better implementations or weaker review. The team needs evidence that changes meet the requirements and remain dependable after release. DORA's continuous-delivery guidance connects effective testing and fast feedback with less rework. Those practices give the team and its agents information they can use to improve delivery.
Customer evidence can expose a mistaken product decision even when the software works as specified. Delivery evidence can expose a weakness in the development system even when the customer need is well understood. PM and engineering need both to decide what to change next.
Investment in future delivery
The development system belongs in product planning because its capabilities affect what the business can deliver. PM needs to account for customer commitments and expected future demand. Engineering needs to explain what an improvement would enable and what it would cost to build and operate.
If the roadmap contains several payment-related changes, automated preparation of test data may reduce repeated work across them. For a single isolated change, the cost of building and maintaining that capability may be harder to justify. The team can make an initial decision from those expectations and revisit it after seeing the system in use.
Required verification remains part of the delivery commitment. Investment in greater autonomy needs its own justification. The team should choose a class of work it understands, establish the conditions for acceptance and expand the system's authority as evidence supports it.
As that capability improves, PM should revisit assumptions about what is affordable. A release previously limited to straightforward payment cases might be able to address more of the customer's problem. The value could come from a more complete result or an earlier release. Customer needs and commercial priorities should guide that choice.
Applying this to a customer engagement
Forward deployed engineering gives engineers direct access to the customer's work. They can use what they observe to improve a specification and test whether a proposed change addresses the problem. PM helps determine how that need relates to the wider product and business. Agentic engineering concerns how development is performed; the two approaches can be used together or independently.
Take a customer improvement already under consideration and describe the intended result with product, design and engineering. Follow that specification through implementation and release. Record where people have to intervene and why. After release, review the customer result and the delivery difficulties together, then choose what to improve in the customer product and the system that develops it.
Product discovery in FDE · Forward deployed engineering projects