The Owner shapes the desired product. The squad takes selected changes to production. AI performs a substantial share of the work in both loops. Imagine AI taking on a substantial share of the technical work: helping design solutions, writing code and tests, analyzing failures, and preparing changes for release. How should we organize software delivery around that? We could keep the existing workflow and simply speed up individual activities. But I am more interested in a different question: what would the process look like if we designed it around AI’s capabilities from the start, rather than adding AI to an existing pipeline of assignments? I propose organizing the work around two continuous loops. The first develops an approved vision of what the product should be. The second turns selected parts of that vision into working, verified, and delivered behavior. One loop develops intent. The other makes it real. Two States of One Product Let us call these states Product and Delivery. Product describes approved, desired behavior: what users should be able to do, which rules apply, which constraints must hold, and what outcomes the system must provide. Delivery describes behavior that has already been implemented, verified, and shipped. This description is tied to the version of the product actually released, not merely to the latest merged code change. Both models use the same language of requirements. What differs is not how they describe the product, but which state they represent. For example, Product may already specify that users can invite colleagues into their workspace. Delivery may not include that capability yet. That is normal: the desired product is ahead of the delivered one. The gap between Product and Delivery is not a documentation error. It is an explicit representation of work that remains to be done. Product is not a warehouse for every wish anyone has ever expressed. It describes current, approved intent. Ideas under discussion do not automatically become requirements; decisions that have been reversed must not remain active rules. In practice, these states can be maintained in two branches - product and delivery - with changes to each made through merge requests, or MRs. But two branches alone do not constitute a methodology. What matters is the meaning of the changes and the accountability of the people and agents working with them. The Product Loop: From Idea to Approved Intent The Owner is accountable for Product. Their work does not have to begin with a fully formed requirement. It may start with a problem, an observation, a hypothesis, or a vague sense that the product should work differently. A space such as ideas is enough for this stage. Here, the Owner works with AI to explore options, discuss consequences, examine assumptions, and abandon unpromising directions. Not every thought needs to become an immediate promise to the user. Once the intent is sufficiently clear, the Owner uses AI to prepare a change to the product model and open an MR. AI helps find related requirements, identify contradictions, articulate expected behavior, and surface unanswered questions. The change goes through discussion and the necessary review. Once approved and merged, it becomes part of Product. In Ideas, we explore what we might want. In Product, we record what we have decided we want. Then the next iteration begins. The Owner can refine existing capabilities, add new ones, and revisit priorities without waiting for every implementation to finish. This does not mean product work is isolated from technical reality. An architect or another specialist can help assess constraints and consequences. AI can examine the existing system and show that a seemingly small requirement would require substantial rework. But technical complexity becomes an input to the product decision, not an automatic veto. Accountability for the approved intent stays with the Owner. The product loop produces requirements, not executable checks. The Owner defines what must happen and what must not happen. For example: "Completing a task does not delete it; the task can be reopened." That is a product rule. How to verify that the rule holds is a delivery concern. The product loop must define intent clearly enough to implement and evaluate it. But it does not have to perform that evaluation work in advance. The Delivery Loop: Accountability for End-to-End Delivery The Implementer is accountable for turning Product into reality. Let us call the delivery unit that takes on a particular change a squad. A squad is not necessarily a group of people. It can be one engineer working with AI, several specialists working with agents, or - with sufficient autonomy - a team of agents operating within defined authority boundaries. Its composition is secondary. What matters is the commitment the squad makes: Turn a selected, coherent change in product intent into accepted behavior running in production. The squad’s work does not end when it hands code to the next participant in the process. It must understand the requirements, ask questions, organize implementation, verify the result, obtain the Owner’s acceptance, and take the change to production. It does not have to perform every step itself. But it is accountable for seeing the entire journey through. Choosing What to Take On Next When a squad has available capacity, AI helps compare Product and Delivery. Which approved changes have not been delivered? Which depend on one another? What is already in progress? Which next slice aligns with product priorities and can be delivered as a complete outcome? The result is a proposed delivery slice - a coherent, deliverable change in behavior - and an MR for delivering it. The selected requirements are brought over from Product into this MR; implementation and checks are added as the work progresses. A slice does not have to match a single product MR. A large product decision may require several deliveries. Conversely, several smaller, related decisions may sensibly be delivered together. The boundary is determined by behavior and dependencies, not by file counts or the convenience of distributing technical subtasks. AI helps propose that boundary, but it cannot derive business priorities simply by comparing requirements. The Owner sets priorities; the squad takes ownership of the slice and its implementation. The slice is pinned to a specific revision of the requirements. As Product continues to evolve, the squad works toward a clear target rather than a constantly shifting set of expectations. How the Work Proceeds Within delivery, AI helps develop the technical solution, build a verification matrix, write tests and implementation, investigate failures, and prepare the release. The matrix connects requirements to checks and makes remaining gaps visible: unverified behavior must not automatically count as complete. The technical specification answers the question, "How will we implement the selected intent?" It must not silently become a new version of what the product is supposed to do. Implementation and verification can proceed in parallel and iteratively. The methodology does not require finishing all tests first, writing all the code second, and only then discovering unanswered questions. For acceptance, the squad presents more than an MR with "CI is green." It shows which behavior has changed, which requirements the result satisfies, how that has been verified, and what limitations remain. After the Owner accepts the result, the change is released, and the squad confirms that the expected behavior is actually available in the target environment. Code is part of delivery. Verification is part of delivery. Acceptance is part of delivery. None of them alone substitutes for a complete outcome. One Example, Two Parallel Loops Consider a small task-list application. For now, users can create tasks and see them in a list. Product and Delivery are aligned. The Owner Approves the First Change The Owner discusses task completion with AI. The discussion produces a product MR: Users can mark a task as completed and reopen it. Completing a task does not delete it. Its state persists after the application is reopened. The MR is merged into Product. This is now desired behavior, but it does not yet exist in the released application. Approving the intent did not require waiting for implementation or writing tests. A Squad Takes Ownership of Delivery An available squad uses AI to analyze the gap between the two states and selects task completion and reopening as one coherent slice. It prepares a delivery MR, pins the requirements, and starts work. AI helps design the technical solution, implement it, and prepare checks for state transitions, persistence, and ensuring that the task is not lost. This is not an assignment to "add a button." Even if the button accounts for most of the visible change, the squad’s commitment covers the entire approved behavior. Product Keeps Moving While the squad is working, the Owner decides that completed tasks should not get in the way of seeing the remaining work. The next product MR introduces a rule: Users can switch the list between all tasks and only incomplete tasks. Filtering does not delete or modify tasks. This MR is approved and merged too. Product now describes both state changes and filtering. Meanwhile, the squad continues delivering the first slice. The Owner does not wait for implementation to finish, and the squad does not have to automatically absorb every new decision into its current work. The First Slice Reaches Production The implementation passes verification and is accepted by the Owner. The squad then releases the change and confirms that it works. Delivery now includes task completion and reopening. Filtering remains part of the intent that has not yet been delivered. The delivery results flow back into Product’s shared context, but this synchronization neither erases newer requirements nor declares them implemented. Synchronizing results does not mean forcing the two states to become identical immediately. The squad can take on filtering as its next slice, provided it remains a priority. Point in time Product: approved intent Delivery: shipped behavior Starting point Task creation Task creation First product MR merged Creation, completion, and reopening Task creation Second product MR merged All of the above, plus filtering Task creation First slice shipped All of the above, plus filtering Creation, completion, and reopening Second slice shipped All of the above, plus filtering The same behavior There is no mandatory sequence in which every new product idea must wait for the previous delivery to finish. There are two loops, each moving at its own pace, grounded in a shared understanding of the product. Feedback Must Not Silently Rewrite Requirements Suppose that while preparing filtering, the squad discovers an unanswered question: should the selected filter persist between visits to the application? AI can propose options. The Implementer can estimate the cost of each. A quality specialist can explain how the checks would differ. But the product decision remains with the Owner. The question returns to the product loop. The Owner makes a decision, the clarification goes through a product MR, and the squad explicitly updates the target of the current delivery if the change affects it. The loops operate at independent cadences, but they are not isolated from one another. Feedback may reveal ambiguity, a technical constraint, or a flaw in the intent itself. The Owner can revise that intent. What matters is that the revision is an explicit decision, not an accidental consequence of whatever code happened to get produced. The same applies to discrepancies found during verification. A check must not be weakened simply because the current implementation fails it. First, determine what is wrong: the code, the check, or the requirement itself. After release, there are also two fundamentally different kinds of feedback. The product may violate an approved rule, requiring a corrective delivery. Or it may follow a rule exactly, yet prove unhelpful to the user, requiring a new product decision. Delivering new capabilities is therefore not the delivery loop’s only job. Restoring already-promised behavior is also its responsibility, even when there is no new change in Product. Two Responsibilities, Not a Mandatory Org Chart The minimal model requires only an Owner and an Implementer. One person can fulfill both roles, distinguishing when they are making a product decision from when they are responsible for realizing it. As complexity grows, cross-cutting specialist roles can be introduced. The Architect helps preserve system coherence, assess the implications of requirements, and address decisions that extend beyond a single slice. They can participate in both loops within their area of expertise. The Quality Gate Specialist, or QGS, helps determine whether verification is sufficient, develops shared quality gates, and works with squads in delivery. A quality gate here is a condition whose fulfillment must be verified before a delivery can be accepted. The QGS does not become a mandatory approver of product requirements. They can discover questions and return them to the Owner, but their primary work is verifying that implementation fulfills the approved intent. These roles can support multiple squads or participate in particular complex changes. Their presence must not turn end-to-end delivery back into a chain of responsibility handoffs. Not having a dedicated QGS does not eliminate the need to verify quality. Having one does not relieve the squad of accountability for the outcome. Likewise, the absence of a dedicated architect does not mean there are no architectural decisions to make. Specialization is introduced where complexity calls for it, not as a mandatory entry requirement for the methodology. Why This Is AI-Native Two loops by themselves do not require AI. What distinguishes this approach is the role AI plays within them. AI does not merely write code from a ready-made ticket. It helps explore intent, maintain consistency across requirements, select the next delivery slice, develop a technical solution, implement it, and verify the result. For this to work, requirements must remain a coherent model, with clear rules, dependencies, and a history of approvals. Each AI operation needs defined inputs, authority boundaries, and a verifiable result. Such repeatable operations can be packaged as skills without tying the methodology to a particular tool. The Owner does not have to manually translate all of Product into a separate, detailed backlog of technical assignments. AI and the squad help derive actionable work from approved intent and the current state of implementation. Tickets and plans may exist, but they remain derived from the selected slice rather than becoming an independent version of product intent. The Implementer, in turn, does not have to personally write every line of code and every test. Their responsibility is to organize the journey from requirements to production, using AI and bringing in the necessary expertise. As autonomy increases, agents can perform more of the work. But authority to implement a solution independently does not imply authority to change the expected behavior, accept any risk, or release a change without the required acceptance. AI-generated checks are not trustworthy merely because they exist. They must be assessed against the requirements: what do they actually verify, what do they leave unchecked, and do they reproduce the same mistake as the implementation? The work is automated. Accountability remains. Delivering Behavior, Not Code Changes For me, the outcome that matters in this methodology is not a closed ticket, a technical specification, or a merged MR. It is a coherent change in behavior that fulfills approved intent, has been verified and accepted by the Owner, and has reached production. The Owner first approves the intent, then evaluates the resulting behavior against that intent. The squad is accountable for the journey between the two and for completing the delivery. AI helps perform the work throughout that journey. The gap between Product and Delivery does not have to shrink continuously: the Owner may approve new changes or abandon old ones. The goal is not to implement everything ever written down at any cost. It is to consistently deliver the most important coherent changes in current intent while maintaining an honest view of what has not yet been realized. This model does not promise error-free or fully autonomous development. It establishes boundaries within which autonomy can grow without losing product intent or accountability for outcomes. The Owner develops what the product should be. The squad is accountable for making a selected part of that intent real. AI powers the entire journey - not just faster coding.