The AI-Native Engineering Doctrine covers what this discipline is and why it works. This playbook covers how.
Six operational systems make the doctrine real. Each one is simple on its own. Together they compound into a development methodology that lets one person operate like an engineering team.
Story points measure complexity, not time. They provide a consistent unit that translates between AI-native development speed and traditional stakeholder expectations.
Story points represent solved complexity, not hours worked.
| SP | Category | Scope | Example |
|---|---|---|---|
| 1 | Trivial | 1 file, <50 LOC | Fix typo, update constant |
| 2 | Small | 1-2 files, <150 LOC | Add form field, simple bug fix |
| 3 | Medium | 2-4 files, <300 LOC | New UI component, API endpoint |
| 5 | Large | 4-8 files, <600 LOC | New page, auth system, migration |
| 8 | Very Large | 8-15 files, <1200 LOC | Major feature, architectural refactor |
| 13 | Epic | 15+ files, >1200 LOC | Must split into smaller tasks |
How technically difficult is the problem? How many systems does it touch?
How many files, components, and integration points are affected?
How well understood is the requirement? Are there unknowns?
What is the likelihood of rework? Could it break existing functionality?
Story points do not measure hours, business value, or developer skill.
Clients buy value delivered, not time. Efficiency gains accrue to the builder as margin.
| Project Size | Rate per SP | Example (8 SP feature) |
|---|---|---|
| 1-50 SP | $150 | $1,200 |
| 51-200 SP | $125 | $1,000 |
| 200+ SP | $100 | $800 |
Traditional consulting assumes human effort maps linearly to time maps linearly to output. AI-native development collapses this relationship. Two hours of architecture work can replace two weeks of traditional engineering effort.
When the relationship between time and output breaks, hourly billing punishes the builder for being efficient. Story points align incentives: the client pays for solved complexity, and speed accrues to the builder as margin.
Structured 30-minute discovery that converts ideas to scoped plans.
Phase 0 is always the smallest proof of value. Build the thing that proves the system works, then expand.
A session is a 2-4 hour focused work block with clear objectives, tracked outcomes, and documented decisions. Sessions are the atomic unit of AI-native development.
Every AI session starts cold. Documentation is the persistence layer.
What we set out to do. Acceptance criteria defined before work starts.
What actually happened. Divergences from plan are documented, not hidden.
Mini-ADRs captured inline. Why we chose X over Y. These feed future sessions.
Files modified, SP delivered, commits created, pages deployed.
What stopped us, what to do next. Feeds directly into the next session's objectives.
Three files maintain continuity across sessions. Without them, AI is stateless and every session starts from scratch.
Automated system runs at 6 AM. Aggregates calendars, emails, project states, and uncommitted changes across all repos. Purpose: system awareness + entropy detection. Catch drift before it becomes debt.
Architecture Decision Records preserve the why behind technical choices. In AI-native development, they serve double duty: they're documentation for humans and constraints for AI.
Architecture is the prompt.
AI performs best when operating inside clearly defined constraints. ADRs define those constraints. Without them, every session re-discovers decisions that were already made, debates recur, and compliance gaps surface late.
ADRs solve this by making decisions permanent and machine-readable. The AI reads the ADR before proposing changes, new sessions start with full context, and there is an audit trail from day one.
Key rules: ADRs are permanent. Supersede, don't delete. A superseded ADR is still valuable because it records what changed and why.
Case study: Recovery Ecosystem (Orbiit) produced 42 ADRs across 174 documented sessions. These ADRs enabled a 12x productivity multiplier because every AI session operated inside well-defined architectural constraints instead of re-discovering decisions.
AI handles execution. Humans handle judgment. The line between them is the quality gate. Cross it in the wrong direction and you get vibe coding. Respect it and you get velocity with integrity.
AI writes the code. Humans own the consequences.
| Checkpoint | When | What Happens |
|---|---|---|
| Pre-PR Grill | Before any pull request | "Grill me on these changes. Don't PR until I pass." |
| Post-Correction | After any mistake | Update CLAUDE.md so the same mistake never repeats. |
| High-Stakes Review | Architecture, security, data | Second AI instance reviews as a staff engineer. |
| Session End | Before closing a session | Update STATE.md with decisions, blockers, outcomes. |
| Mediocre Ship | After shipping a compromise | "Knowing everything now, scrap and implement the elegant solution." |
The goal is not zero mistakes. It is zero repeated mistakes. Every correction gets encoded into the system so it cannot happen again.
The engineering knowledge lives in the repo. ADRs, session docs, patterns, commit history. But the people who need to understand what you built don't read repos.
Documentation that nobody reads is documentation that doesn't exist.
Shareable pages bridge the gap. Single-URL, self-contained HTML pages that open instantly on any device, render cleanly on mobile, and print to PDF. Hash-based URLs serve as lightweight access control.
| Trigger | Example |
|---|---|
| Stakeholder needs to understand a feature | Feature brief for investor or partner |
| Partner onboarding | Platform capabilities overview |
| Release communication | What shipped, what changed, what's next |
| Decision affects non-engineers | ADR summary for business stakeholders |
| Sales material | One-pager, proposal, demo walkthrough |
| Post-incident | Simplified RCA for affected parties |
| Thought leadership | Article or whitepaper for distribution |
Rule of thumb: If the audience is an AI agent or engineer on your team, it stays in the repo (ADR, runbook, session doc). If the audience is anyone else, consider a shareable page.
| Repo Artifact | Becomes |
|---|---|
| ADR | Decision summary for stakeholders |
| Session docs | Sprint/release summary for leadership |
| RCA | Incident summary for affected parties |
| ROADMAP.md | Feature brief for partners/investors |
| Patterns | Best practices article for community |
The multiplier: A partner reads a capabilities page before a call. They ask informed questions. The meeting is productive instead of introductory. 30 minutes creating a page saves hours of meetings, emails, and misunderstandings.
The methodology above works for one project. Scaling to 5-7 concurrent projects requires consistent tooling and automated awareness.
Same methodology. Different repos. Consistent tooling.
Every new project starts from the AI Development Starter Kit, which provides standardized scaffolding.
Project context, stack, conventions, key paths, guardrails. AI reads this at session start.
9 starter decisions covering auth, database, hosting, CI/CD, testing, and more.
Template with objectives, outcomes, decisions, artifacts. Consistent format across all projects.
Living document: current sprint, recent decisions, blockers, and context that AI needs.
One person, multiple companies, same methodology. Each project gets its own repo with the full starter kit. The portfolio layer (command center, daily notes, briefings) sits across all of them in a central notes repo.
The methodology is replicable. The IP is in the system, not in any individual's head. New projects inherit the full discipline from day one through the starter kit.
Proven results: Recovery Ecosystem achieved 160,000+ lines of code, 1,315+ commits, 174 documented sessions, 42 ADRs, and a 12x productivity multiplier vs. traditional development. All from one architect and AI execution.
Six systems. Each one simple. Together they compound into a methodology that lets one person with AI operate like an engineering team.
The Doctrine explains the thesis. This playbook explains the mechanics. Neither is complete without the other.
Build the system. Then let the system build.