Attribution
AI: ChatGPT; Claude; Gemini
NI: Alex Chompff ; MVAI
TLDR
Problem: “An AI agent fixes a bug at 10 a.m. At 10:01, it has forgotten why the bug existed.”
That is not a minor inconvenience. It changes how software teams must work. If AI agents do more of the coding, the team’s memory cannot live mainly in context windows, people or conversations. It must live in durable, searchable systems (i.e., memory surface).
The original AI-Native SDLC essay explains this model. The companion essays show how it behaves under real operational pressure. The public AI-Native SDLC Kit v2.0 repo turns the ideas into a practical starter kit.
The central v2.0 lesson: running more AI agents is not enough. Teams must manage agentic context, coordination, and verification.
Context
The starting point for AI-native software development is simple: AI workers are generally stateless.
An agent can read a codebase, make a change, run tests and report its result. Then the session ends. The next agent may or may not be equally capable, but it does not automatically inherit the earlier worker’s discoveries, decisions or failed attempts.
That changes the meaning of computational and institutional memory.
In a conventional engineering team, some context lives in people. They remember why a decision was made, which workaround failed, where a feature is fragile and what a customer meant months earlier. An AI-heavy operation cannot rely on that continuity. Its memory needs to live in a durable, searchable system outside the worker (i.e., real memory surface not merely “context”).
The original essay calls that system a repository-based memory surface. It includes source code, issues, labels, pull requests, comments, commit messages, tests, documentation and operating instructions. The model is not that humans disappear. It is that natural intelligence (NI) orchestrators direct, prioritize and judge, while AI workers produce work inside a written operating system. Read the original essay.
The essay organizes the approach around five themes:
Memory outside the worker.
Structural coordination among workers.
Quality evidence that does not depend on a worker’s self-report.
Rituals that replace informal culture.
Vocabulary that changes how workers interpret the system.
That fifth theme is especially important. In an AI-native environment, words are not cosmetic. They shape the next worker’s behavior.
Calling an issue tracker a “to-do list” suggests a short-lived task queue. Calling it a “memory surface” encourages workers to search it before re-solving a problem. The language becomes part of the operating instruction carried into every new session.
The companion collection expands the argument. It is explicitly presented as seven essays about managing memory, compute and coordination across an AI-native workforce. It includes concrete operational lessons: when a failure occurs, the goal is not only to fix it in the moment. The failure should leave behind a durable teaching — an issue, a test, a recovery path, an explicit rule or a better route for future workers to find the lesson. Read the companion essays.
That is the context for version 2.0 of the AI-Native SDLC Kit.
Body
Imagine a familiar sequence.
An agent finds a defect, identifies the cause, makes a clean fix and runs the relevant tests. The work looks complete. Then the session ends. The next agent arrives with no lived knowledge of the defect, the decision or the edge case that made the fix necessary.
If the lesson existed only in the conversation, it is gone.
The AI-Native SDLC model begins there. It treats the repository not simply as a place where code lives, but as a shared memory system for a workforce whose members do not reliably persist across sessions.
That memory system includes code, issues, labels, pull requests, comments, commit messages, tests, documentation and clear project instructions. Each item can carry part of the context that a future worker needs to avoid repeating work, breaking a prior decision or declaring success too early.
The original essay argues that this is a shift in operating model, not merely a productivity technique. Humans still matter. Their role moves upward: they set direction, make judgment calls, establish priorities and decide what good work looks like. AI workers produce, verify and record work inside the system the humans create. Read the original essay.
Its practical lesson is simple: a failure should leave more behind than a patch.
It should create a durable teaching. That may mean an issue that names the failure mode, a test that catches the next instance, a recovery path, a clarified rule or a better route for future workers to discover the lesson. If the system does not preserve that learning, the next stateless worker may pay for it again.
That is the foundation for the AI-Native SDLC Kit v2.0.
The kit is not presented as a plug-and-play framework. It provides a starter instructions file, six operating rituals, an installer and practical guides. Teams are expected to trim and adapt the materials for their own repository, tools and risk profile. See the README.
That is an important design choice. The kit deliberately does not export source-project tools that depend on internal file names, thresholds or a specific structural map of one repository. Instead, it provides the method and the contracts an adopting team can build locally. See the v2.0 changelog.
Version 2.0 focuses on the problem that emerges after a team moves beyond one agent: fleet operations.
First
Its first major addition is a three-tier model.
The strongest model belongs in the human-facing seat, where a poor judgment can waste human attention or damage trust. A strong mid-tier coordinator, or “quarterback,” plans work, assigns lanes and verifies results. Lower-cost lanes handle bounded work such as reading, searching, editing and running tests.
The key question is not, “How much work does this seat perform?” It is, “What does a wrong decision in this seat cost?”
That is a more useful way to allocate AI capability. A cheap lane can re-run a search. A human-facing thread that makes a bad recommendation may cost far more than the tokens saved.
Second
The second major v2.0 addition is context economics.
The fleet guide reports a comparison in which a read-only session on a top model cost the same as a session coordinating six parallel lanes. The project attributes the cost difference primarily to repeated rereading of resident context across turns, rather than the length of the output produced. Read “Running a Fleet.”
The operational response is clear: wait inside one command instead of repeatedly polling; report once; batch independent calls; read only the necessary slices of a file or record; and use the least expensive model that can reliably do the job.
Third
The third major v2.0 addition is the orientation kernel.
A standing project brief helps every worker understand shared rules. But every worker may load that brief repeatedly, making it an ongoing cost rather than a one-time onboarding expense. The kernel approach creates audience-specific, generated projections from one canonical brief.
The goal is to reduce repeated context without creating competing versions of the rules. The kernel guide emphasizes that a smaller brief is not automatically better if it drops a load-bearing rule. It calls for drift checks, explicit “cannot measure” states and a canary before any fleet-wide rollout. Read “The Orientation Kernel.”
Kit
The kit is not a software framework that a team installs and forgets. It provides a starter instructions file, six operational rituals, an installer and practical guides. Its documentation is explicit that teams must adapt the templates to their own repository, workflow and tools. See the v2.0 README.
That restraint matters. The kit does not ship tools that are too closely tied to the source project’s internal file inventory, module names or thresholds. Instead, it describes the contracts that an adopting team should build locally. References to repository-chart tools use placeholders rather than pretending that one project’s internal tooling is universally applicable. See the changelog.
Sequence
The sequence is clear.
The original essay provides the theory: stateless workers need durable memory and independent evidence.
The companion essays add operational texture, including how failures become reusable lessons.
Version 2.0 packages the resulting practices into a portable kit while preserving an important distinction between evidence and aspiration.
The kit reports findings about context cost and coordination. It does not claim that its tiered model has already proven lower defect rates. Its fleet guide states that question remains unmeasured.
That is a sound discipline for AI-native engineering: record what happened, distinguish evidence from inference and make it easier for the next worker to begin with the lessons already paid for.
Stats
The original essay states that its source repository had roughly 87,000 lines of Python, 38 scheduled workflows and about 1,871 commits at publication.—Source.
The companion collection is described as seven essays about memory, compute and coordination across 12 roles.—Source.
v2.0 adds a fleet-operations guide, an orientation-kernel guide and a sixth ritual for a sub-quarterback.—Source.
The kernel guide reports a reduction of roughly four-fifths in fixed boot payload, but less than one-fifth when task-specific context is included—Source.
Summary
AI-native SDLC is not an argument that AI removes the need for engineering discipline. It is an argument that discipline must become more explicit when workers forget.
The original essay supplies the operating theory.
The companion essays add real-world failure and recovery patterns.
The v2.0 kit supplies a reusable starting point, particularly for teams running multiple agents at once.
Its practical message is straightforward: put memory in the repository, make coordination structural, verify work outside the producing session, preserve lessons from failure and treat context as a real operating cost.
Links
AI-Native SDLC via GitHub
AI-Native SDLC via Google Drive
Monday
If you lead a team using AI for recurring work, perhaps do not begin by launching a fleet on “Monday” based on this information.
Start smaller:
Create a concise project brief with the few rules every worker must know.
Treat issues, pull requests and commit messages as searchable memory, not administrative overhead.
Write down the recovery path when a failure costs real time.
Define what evidence is required before work is called shipped or done.
Add parallel lanes only when the work can be cleanly divided and independently verified.
The technology matters. The operating system around the technology matters more.
Notes
This work is educational only, please fact check and verify all details. The information above are source-project-reported measurements and have not been independently audited. The v2.0 fleet guide also says its tiered approach has not yet established an independently measured defect-rate improvement.