DEV Community: Vladimir Panov

AI-Native Software Delivery: Two Loops, One Product

Vladimir Panov — Sun, 06 Sep 2026 04:58:35 +0000

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.

Notes: Memory, Context, and Large Language Models (LLMs)

Vladimir Panov — Wed, 01 Jul 2026 05:24:54 +0000

Notes following a discussion on how memory works in language models - and how it could be improved: ranging from the common issue of "context window" exhaustion to node architecture and entity linking.

1. The illusion of an infinity chat.

No model possesses a truly infinite context; the window size is always finite. The illusion of a continuous dialogue is maintained through information compression and selection mechanisms. Specific approaches include: Infini-attention (from Google) - a compressed long-term memory mechanism built on top of standard attention; it reportedly maintains performance quality even when exceeding the million-token threshold. StreamingLLM - utilizing several "anchor" tokens at the start of the sequence combined with a sliding window for recent tokens. MemGPT/Letta - a system resembling OS virtual memory that incorporates three tiers: core memory (always within the context window), archival memory (in vector storage), and recall memory (the full history in a database). Mem0 - instead of summarizing everything indiscriminately, it selectively stores only significant facts, reducing token volume by 80–90%. Also worth mentioning is EM-LLM: this model segments history not mechanically, but based on a "surprise" metric - an approach that appears to mirror the workings of human memory.

2. Human memory as a working model of limitation.

Human working memory holds only a small number of items at once (the classic figure being Miller’s “magic number” of 7±2, which Cowan later revised to approximately 4). Yet, it is precisely this limitation that compels the brain to constantly compress information: what is stored in memory is not a recording, but a reconstruction. As early as the 1930s, Bartlett demonstrated that remembering is the recreation of an image based on cognitive schemas rather than the playback of a tape recording; this is why memory is prone to distortion, yet it is also what allows it to serve as a tool for thinking rather than merely an archive. Forgetting is not a data "leak" but an active process: during sleep, the hippocampus "replays" events and gradually transfers them to the neocortex in a generalized form (consolidation). This limitation is not a glitch but a factor that forces the system to generalize information rather than simply copying it.

3. Language, encoding, and the "cost" of memorization.

The brain doesn't store every word form individually. Instead, it performs morphological analysis (isolating the root and the rule), ensuring that a complex morphological system doesn't create "search noise" at the semantic level. However, this poses a problem for the tokenizers used in LLMs: for instance, the o200k_base tokenizer yields an average of 1.96 tokens per word for Russian, compared to 1.16 for English. Consequently, processing the same amount of information in Russian is approximately 70% more expensive, as the rich inflectional system causes BPE token frequencies to be "diluted" across dozens of forms of the same word. Notably, a comparative study of languages (Coupé et al., 2019) demonstrated that the rate of spoken information transmission tends toward a universal value - approximately 39 bits per second. Languages with high syllabic information density require a slower speaking pace; thus, there is no "free lunch" in this regard.

4. Thought and language are separate systems.

Using fMRI, Evelina Fedorenko (MIT) demonstrates that the brain's language network remains virtually inactive during the performance of mathematical and logical tasks, musical activities, or contemplation of others' intentions. Patients with severe global aphasia lose their language abilities yet retain the capacity to perform arithmetic, play chess, and reason about the world around them. A word is not a vessel for a thought but rather a label "attached" to it only after the thought has been formed. In bilinguals, this is corroborated by the Revised Hierarchical Model (Kroll and Stewart): there is a single conceptual node linked to distinct lexical units for each language. This explains the example involving the words "girl" and "девочка" (Russian for 'girl'): it is an image that surfaces in memory, not the word itself; the word is selected only subsequently.

5. A New "Language" of Memory: Writing and Reading Around the Text.

Two approaches directly address the question of exactly how writing to and reading from memory occurs - distinct from the prompting process itself.

The continuous approach: "gist tokens" (Mu et al., 2023) - the model is trained to compress the prompt into a set of vectors. This is not human-readable text but data read directly by the model (achieving compression ratios of up to 26x). Similar methods are employed by AutoCompressors and ICAE, utilizing summary vectors or memory slots. The Titans model (Google, January 2025) takes this further: long-term memory is implemented as a separate neural module (an MLP) that continues learning during inference, with "memorization" decisions based on a gradient-based "surprise signal" - a mechanism virtually identical to human memory consolidation.

The conceptual approach: Meta’s Large Concept Models (December 2024) - the model operates not on tokens but on "concepts": embeddings of entire sentences within the SONAR space, which is independent of both language and modality. A sentence in Russian, French, or Hindi yields a virtually identical representation; reasoning occurs at the concept level and is rendered into a specific language only at the output stage.

The symbolic approach: graph-based memory (Zep/Graphiti, Mem0’s graph mode) - during writing, the LLM autonomously extracts entities and relationships, while reading involves graph traversal rather than vector search. Although less efficient in terms of data compression, this method allows humans to read and edit the memory content.

The trade-off for using approaches based on continuous representations lies in their interpretability: they cannot simply be "opened and read". Individual facts within them cannot be corrected in isolation, and, as a rule, they are tightly coupled to a specific model.

6. The uniqueness of interior spaces and the problem of coordination.

If two models form their internal representations independently, there is no guarantee that these representations will align - a phenomenon that has already been studied empirically. In the game Hanabi, agents that play brilliantly alongside the partner with whom they trained perform extremely poorly when paired with an independently trained agent. During joint training, they develop arbitrary conventions - or "handshakes" - unlinked to the objective values of the cards; this phenomenon is known as the zero-shot coordination problem. The "other-play" method enables agents to avoid such idiosyncratic traits to ensure compatibility, though this comes at the cost of reduced flexibility and uniqueness.

There is also an opposing view: the Platonic Representation Hypothesis (Huh, Isola et al., ICML 2024) posits that as models scale up and the tasks they perform become more diverse, their internal representations don't diverge; instead, they converge toward a unified statistical model of reality - since they are all modeling the same world. Furthermore, a technique utilizing relative representations (Moschella et al., 2023) demonstrates that even formally incompatible latent spaces can be aligned without retraining. This is achieved by comparing the degree of similarity to a fixed set of reference points (anchors) rather than comparing absolute coordinates. In other words - the task becomes one of recognizing different orientations of the same underlying geometric structure, rather than performing a word-for-word translation.

7. Subjective, objective, and the nature of "glitches".

A category such as "cat" is not an objective entity but a culturally shaped interpretation. Eleanor Rosch’s prototype theory demonstrates that concepts are organized around a "fuzzy" prototype rather than having rigid boundaries. Individual deviations (such as a fear of cats) are not "bugs" but the result of the system tuning itself based on personal experience.

The way we explain someone else's deviation (e.g., "a cat must have scared him in childhood") reflects the work of what Gazzaniga called the "left-brain interpreter" - a specialized brain module that constantly generates plausible explanations for behavior, even without access to the true cause (recall the classic split-brain experiment involving images of a chicken claw and a snowy landscape). This is a normal mode of brain function, not a malfunction.

An analogy can be drawn to Large Language Models (LLMs) based on the OpenAI paper "Why Language Models Hallucinate" (Kalai, Nachum, Vempala, Zhang; September 2025). The paper formally proves that any model capable of generalizing beyond its training data will inevitably either hallucinate or "collapse" by refusing to provide diverse answers - there is no other way. The situation is exacerbated by the fact that training and evaluation processes reward confident guesses rather than an honest "I don't know." An important caveat: this strips the term "glitch" of its moral baggage but don't erase the distinction between subjective categories (where there are no wrong answers) and facts (where reality is singular, and confidence calibration matters regardless of the mechanism).

8. How this actually gets built: RAG today.

The standard pipeline as of 2025-2026 looks like this: data chunks (typically 512-1024 tokens) are fed into a vector store that supports similarity search (using HNSW indices). Since pure vector search is unreliable when dealing with specific facts and names, a hybrid approach has become the standard: combining embeddings with the BM25 algorithm and merging results via Reciprocal Rank Fusion (RRF). Next, a cross-encoder (a re-ranking model) steps in to select the most relevant candidates from a pool of fifty (boosting accuracy by approximately 17%). The major trend of the past year has been "agentic RAG": instead of the system pre-determining what information to retrieve, the LLM itself formulates the query, evaluates whether the retrieved data is sufficient, and repeats the search if necessary.

Anthropic has already implemented this solution in a real-world setting - it is not merely a concept: Claude.ai summarizes chat history daily, extracting key facts that are carried over into new conversations (with each project maintaining its own isolated memory). At the API level, a memory management tool is available: the model autonomously creates, reads, and updates files in persistent storage that survives across sessions, loading only the necessary data as needed without overloading the context window.

9. An entity graph built on the fly.

The Zep/Graphiti architecture embodies a working prototype of the model where "a node is created upon the first interaction, while edges accumulate through repeated interactions". It comprises three levels: episodes (raw observations), entities (extracted entities, deduplicated across sessions), and communities (clusters of related entities). Upon receiving new data, the LLM determines whether the information refers to an existing node (an update or expansion) or a new one (creation) - a decision made not based on a rigid distance threshold, but through contextual assessment. Each edge is annotated with bitemporal metadata - information indicating when the fact was true and when the agent acquired the data. Without this, the node would eventually accumulate contradictory edges and become useless.

The linking problem itself represents the classic stability-plasticity dilemma - a challenge around which Carpenter and Grossberg built an entire architecture in the 1980s: Adaptive Resonance Theory. This theory employs a vigilance parameter (ρ) that dictates how closely a new stimulus must match an existing node to trigger an update rather than the creation of a new node. A setting that is too loose leads to the merging of distinct entities and node distortion, while one that is too strict causes a single entity to spawn fragmented duplicates. There is no universally correct threshold.

A biological parallel to this three-stage model is the Complementary Learning Systems theory (McClelland, McNaughton, & O'Reilly, 1995): the hippocampus rapidly encodes each episode individually (employing pattern separation to preserve detail), whereas the neocortex slowly integrates these episodes into a generalized semantic node through repeated replay during sleep.

10. A node as a response, not an image.

A key shift lies in the fact that a node is defined not by the stimulus itself, but by the convergent pattern of response to it; this approach is characteristic of functionalism in the philosophy of mind and is supported by direct empirical evidence. Examples include "concept cells" - such as the so-called "Jennifer Aniston neuron" (Quiroga et al., Nature, 2005) -neurons in the human medial temporal lobe that activate upon perceiving a specific individual, regardless of the information channel: whether through various photographs, a written name, or even a name spoken by a computer-generated voice. A similar phenomenon was artificially replicated in the CLIP model (Goh et al., OpenAI, 2021), where a "Spider-Man neuron" responds to a photograph of a spider, the word "spider," or an image of the Spider-Man costume; the authors explicitly state that they were inspired by Quiroga’s discovery.

The "signal flow → weighted network → node key" mechanism closely resembles the VQ-VAE architecture (Van den Oord et al., 2017): an encoder transforms a signal into a vector, which is matched to the nearest element in a learnable discrete codebook, yielding a discrete index as output, while the codebook itself continues to learn during operation. A historical precedent for the concept of "space reorganization during sleep" is the wake-sleep algorithm (Hinton, Dayan, Frey, Neal, 1995), which incorporates a distinct "sleep" phase: the network generates its own data (in a top-down direction) to adjust weights offline.

Individual elements of this picture already exist and have been validated. The open engineering question lies not in any single one of them, but in how to combine them into a unified, continuously functioning structure, rather than a system fixed at the pre-training stage.

Key sources

AI-Native Software Delivery

Vladimir Panov — Sun, 10 May 2026 04:43:15 +0000

A process for shipping software when AI generates most of the implementation and humans own intent, validation, and behavioral guarantees.

This is a rewrite of an earlier article that introduced the idea. The thinking has matured into a working, clone-and-go process toolkit:

github.com/DominicTylor/ai-software-process

What follows is the methodology in its current shape — what changed since the first article, why those changes mattered, and what the resulting process looks like in practice.

The problem this process exists to solve

AI now generates a meaningful share of production code, and that share keeps growing. Engineers spend less time writing code and more time reviewing what was generated, often less deeply than we like to admit. The question stops being "is this code well-written?" and becomes "does this code do what we said it should do?" — and the systems most engineering teams use today were designed for a world where humans wrote everything by hand.

A few pains, all interlocking:

Story trackers describe intent in plain English in one place; the code that implements it lives somewhere else; the tests that verify it live somewhere else again. Each drifts at its own rate. A Jira ticket that was current six months ago describes behavior that the code no longer has — and nobody knows when it stopped being accurate.

BDD frameworks tried to bridge this. They duplicated scenarios in Gherkin (.feature files) alongside the executable code. Two artifacts that say the same thing must be kept in sync, and they never are. The feature file becomes documentation; the code becomes the truth; the gap between them is where bugs live.

Decision history fragments across chat threads, old tickets, deleted documents, and the heads of senior engineers. When a new contributor asks "why did we drop password authentication?", the answer is gone. The current code shows what we do; nothing shows why.

Tests check internal state — Redis keys, database rows, in-memory variables — instead of customer-observable behavior. They pass while the user-visible flow is broken, because they were written to be easy rather than honest.

And underneath all of this: when AI generates the implementation, none of the safeguards a team built around human authorship apply the same way. Code review catches less because reviewers skim more. Linters and type checks don't catch semantic drift from the spec. The acceptance criteria — if they exist — are in a ticket nobody reads.

The standard practices were designed for a different world. The reshape is not a productivity tweak; it is a structural change in where trust lives.

What changes

Implementation-centric engineering optimized for the people writing code. Result-centric engineering optimizes for the property the product must hold. The shift is concrete:

Humans increasingly own intent, validation, and behavioral guarantees. AI increasingly generates the code that satisfies them. The center of human attention moves from "did I write this well?" to "have I described what must hold, and is it verified?"

This is not a productivity argument. The argument is that as AI-generated code becomes the default, the only durable form of trust is executable behavioral validation: a machine-checkable through-line from customer intent to verified behavior. Everything in the process below serves that through-line.

Stories are folders, not tickets

The unit of work is not a row in a tracker. It is a folder in git.

stories/auth/user-signup/
  user-spec.md           ← what the user wants, who they are, what must hold
  e2e/
    signup-via-github.spec.ts
    signup-via-magic-link.spec.ts
  perf/                  (optional)
  security/              (optional)
  a11y/                  (optional)

The user-spec describes intent, personas, high-level user goals, functional constraints, architect tech notes, quality-gate notes, scenario references, and which platform invariants the Story is subject to. What it deliberately does not contain: step-by-step scenarios in prose (those are in the commented tests), changelogs (in git), resolved-question annotations (in git), future-state plans (elsewhere), implementation choices (in tech specs in code repos).

A Story always describes current behavior — not history, not roadmap, not the journey of how it got here. If the system behaves this way right now, it goes in the spec. Otherwise, it goes elsewhere. That single rule eliminates a class of drift that older spec formats accept by default.

A scenario, concretely

Acceptance criteria live as commented executable tests:

test('User signs up via GitHub for the first time', async ({ user }) => {
  // # User opens the signup page
  await user.opensSignupPage();

  // # User sees three auth options with GitHub marked as recommended
  await user.seesAuthOptions({ recommended: 'github' });

  // # User clicks "Continue with GitHub"
  await user.clicksContinueWithGitHub();

  // # System completes OAuth and lands the user on an empty workspace dashboard
  await user.expectsDashboardWithEmptyWorkspace();
});

The Owner writes the comments first. An AI helper, or the Implementer, fills in executable code under each comment without removing it. The comment stays as documentation; the code stays as verification; they live in the same file for the life of the test.

Three properties fall out of this shape with no extra effort:

The Owner reads only the comments to verify acceptance criteria. The Quality Gate Specialist reads comments and code together to verify they agree. Drift between described behavior and verified behavior is physically impossible — they share a file and appear in the same diff. There is no second artifact to keep synchronized.

A scenario that has only comments and no code under them is wrapped in test.todo(). It appears in the test runner as TODO. The Story's observable state — what's drafted, what's verified, what's still pending — is whatever the test runner reports. Not a status field; the report.

Frameworks as bilateral contracts

Notice the test above. No selectors. No data-testid strings. No sleeps. No mocks. The verbs — user.opensSignupPage(), user.clicksContinueWithGitHub() — come from a framework owned by the Quality Gate Specialist.

The framework's PageObjects hold one end of a bilateral contract:

// frameworks/e2e/page-objects/login-page.ts
class LoginPage {
  async entersEmail(email: string) {
    await this.page.fill('[data-testid="login-email"]', email);
  }
}

The test-id "login-email" lives in this file, in plain code. Code-perimeter implementation reads this file to know what the UI must expose. There is no separate test-id registry; the framework's PageObjects are the registry.

When the Story uses user.entersLoginEmail(...), the framework declares that the UI must render data-testid="login-email" on the login form's email input. The code-perimeter team reads the framework to know what to build. The team building the test reads the framework to know what verbs are available.

Same pattern for other frameworks. A probe.scanTable('account', { where: 'password IS NOT NULL' }) call in the security framework rests on a database probe helper that names the table and column explicitly; code that creates the schema reads that helper to know what names are expected.

This is the through-line from intent to verified code: scenarios consume framework verbs, framework PageObjects declare identifiers, code-perimeter implementation honors those identifiers. The contract is not implicit. It is readable code on both sides.

Constitution: platform-wide invariants

Stories describe features. Some rules apply across all features — they are invariants of the platform, not properties of any one Story. Those live in a separate constitution.md document at the repository root.

A constitution is short, prose, self-contained:

No user password is ever stored, transmitted, or accepted by any code path.

The SMTP capture service never originates outgoing connections on ports 25, 465, or 587.

No request authenticated by tenant A can read or modify data belonging to tenant B. Cross-tenant access attempts return 404 or 403, never 500 and never partial data.

All persistent data is encrypted at rest under platform-managed keys.

The constitution declares; it does not enumerate enforcement. Each rule has an owning Story under stories/ — same shape as any other Story, but with an attacker or system-probe persona, scenarios that attempt to violate the rule, and assertions that the violation is refused.

A Story may reference a constitution rule it depends on (enforces: no-passwords in frontmatter) for traceability. The constitution itself does not reference back. It does not need to know how each rule is verified or by which Story.

The Architect holds final word over constitution.md. When a Story's design would conflict with a rule, the Architect-review skill blocks the PR. If the team genuinely wants to change the rule, that goes through a separate constitution PR — explicit, reviewed, recorded.

Decision history in commit messages

Every behavioral change in the system is captured in a structured git commit message:

behavior: drop password auth from auth flow

Why: minimize attack surface; password storage adds risk for a developer-tool
audience that is comfortable with OAuth and magic links.
Considered: keep with bcrypt, move to passkeys only, drop entirely.
Chose: drop entirely; OAuth + magic link cover all signup and login paths.
Affects: stories/auth/user-signup/, constitution.md §3.2.

A commit-msg git hook enforces the Why / Considered / Chose / Affects shape on every commit whose subject starts with behavior:. Non-behavioral commits (chore, fix, docs) are not gated. The hook is local; a matching CI check protects main against commits that bypassed the hook.

Significant decisions are tagged for direct addressability:

git tag decision/no-password-auth <sha>
git tag -l "decision/*"

To answer "why did we decide X?", the workflow is git log --grep="X", follow tags, read the structured sections of the relevant commit. There is a /decision-search skill that makes this queryable in natural language, but the storage layer is just git.

This rule has one specific consequence: no artifact in the repository contains a changelog. No "Resolved on 2026-05-11" annotations inside specs. No version-history blocks. Specs describe current behavior. The history of why behavior is current lives in commit messages, addressable through tags.

State is observed, not declared

A Story is not a thing that has a status: "approved" field. The tracked unit is a change vector — a (branch, PR) pair against the master repository — and its state is whatever git and the forge say it is.

Branch	PR	Vector state
Doesn't exist (or merged into main)	—	Doesn't exist, or is live
Exists, no PR	—	Private work in progress
Exists, PR open (any state)	Draft / Open	In review or iteration
Exists, PR open, all approvals + CI green	Open	Ready to merge
Merged	Merged	Live

There is no status field anywhere. No external state store. git branch -a plus the forge's PR list answers "who's working on what, what's in review, what's blocked, what just shipped" — without a separate tool.

Parallel work follows from this naturally. Multiple branches mean multiple vectors in flight. Two vectors touching the same area are a coordination signal — usually a sign that two people are attempting the same change without realizing it. Tooling on top of the process (a dashboard, a query) can surface this; the process itself does not block it.

Master and code perimeters: asymmetric awareness

A non-trivial project usually has two physical territories: the master repository where Stories, frameworks, and constitution live; and one or more code repositories where implementation, tech specs, and code review live. In small projects these can coexist in one physical repo; the boundary remains conceptual.

Awareness flows in one direction only.

The master perimeter never queries, inspects, or coordinates with code repositories. Its references to them are descriptive ("this Story affects services A and B"), not operational. A skill running in the master perimeter never opens a code repository's pull request list, never reads code-side tech specs to decide what to do, never coordinates code-side merges.

The code perimeter, in contrast, reads the master perimeter as its source of truth. To produce a tech spec or implementation, an engineering agent in a code repository reads the corresponding Story's user-spec, the architect tech notes inside it, the quality gates, the constitution rules it must respect, and the framework's PageObjects to know what identifiers to expose.

This asymmetry keeps responsibilities clean. The master perimeter never has to know about deployment topology, CI runners, or how many code repositories the company has. The code perimeter never has to argue with product about what a feature should do.

Roles as areas of final word

The process names six roles: Owner, Architect, Quality Gate Specialist, Implementer, Code Owner, UI/UX Specialist. These are responsibilities, not positions. In a one-person project, one human holds all six and switches modes consciously. In a fifteen-person team, they tend toward distinct people. The role structure stays the same regardless of headcount.

Stories are written collaboratively. Anyone with something to contribute writes into the Story — Owner sets intent, Architect adds tech notes, Quality Gate Specialist refines scenarios, UI/UX Specialist adds accessibility constraints. A Story does not "belong" to a role.

What roles hold is areas of final word — domains where, when a decision is contested, that role's approval is required to ship. These are enforced through CODEOWNERS rules on path patterns, not through social convention. Owner over stories/**/user-spec.md, Architect over constitution.md, Quality Gate Specialist over frameworks/** and scenario folders, and so on.

A second pattern governs how non-final-word roles still carry real weight: mandatory review with required engagement. Horizontal roles — Architect, Quality Gate Specialist, UI/UX Specialist — review every relevant Story automatically. Their comments are blocking. The Owner is free to overrule their advice in the Owner's own product domain, but only by explicit acknowledgment — a written statement that the risk is read, accepted, and carried. Silent dismissal is not allowed.

When a horizontal role believes an Owner's acknowledgment underestimates a systemic risk, the open path is to escalate by opening a constitution PR. The discussion moves from Story scope (Owner's call) to platform scope (Architect's call). The right argument resolves at the right altitude.

Skills and sub-agents

Skills are AI-assisted helpers — focused operations a contributor invokes like commands: /spec-brainstorm, /architect-review, /scenario-implement, /decision-search. Sub-agents are role-specialists with deeper expertise in a single domain (spec-spec for product consistency, architect-spec for constitution and system invariants, quality-spec for frameworks and coverage, ui-ux-spec for visible-state completeness, decision-historian for git history). Skills invoke sub-agents when judgment in a domain is required.

The operational principle is: skills are soft assistance inside a branch, hard gates on the pull request. While work is private, every skill is invokable and ignorable. An author can use them or not. Once a PR is opened, the horizontal-role review skills run automatically and their comments are blocking. Resolution takes one of two forms — fix the concern, or write an explicit acknowledgment of the risk. There is no third option.

This separation matters. A contributor who prefers to write everything by hand is not punished. A contributor who relies heavily on AI is not given a shortcut around the gates. The path is different; the destination is the same.

What this process is not

To prevent drift toward familiar models:

Not Jira-as-spec. A Story is not a ticket. Stories live in git and always describe current behavior. There is no parallel ticket queue describing the same work.

Not BDD with Gherkin. Scenarios are first-class TypeScript inside test files, not a parallel .feature layer that has to be kept in sync. One source of truth.

Not test-after. Acceptance criteria are written before or alongside implementation, as commented executable tests. Code is generated to satisfy them, not the other way around.

Not waterfall, despite the milestone names. Stages cycle. Implementation can expose gaps in scenarios; review can redirect back to spec. The process recognizes legitimate return points instead of pretending the flow is linear.

Not vendor-locked. The methodology shape is independent of any specific AI tool. The current incarnation uses Claude Code; the same shape works with any AI environment given equivalent primitives.

Not headcount-prescriptive. Roles are responsibilities. One person can hold all six. A team of fifteen can split them across people. The process does not require any specific organizational chart.

Where to start

The process lives at github.com/DominicTylor/ai-software-process.

The repository is a clone-and-go Claude Code toolkit. process.md is the full canon. constitution.md is a working template adopters rewrite in place. templates/story/ holds the per-Story scaffolds skills consume when creating new artifacts. .claude/skills/ and .claude/agents/ ship a complete master-perimeter toolkit (twelve skills, five sub-agents) plus a code-perimeter starter pack drawn from a real TypeScript/Node monorepo. .githooks/commit-msg enforces the structured commit format locally; .github/workflows/ enforces it (and spec validation, and ai-review) on the PR.

Adopt by forking, rewriting the constitution and high-level project description in place, and piloting a Story end-to-end. MIT No Attribution license — no permission, no obligation to credit, no friction. Attribution back is appreciated but never required.

If anything here resonated, that's where it goes from idea to applied.