7-Layer Architecture for AI-Native SDLC: How Anthropic, OpenAI, GitHub & Kiro Map to the Stack
This article presents a 7-layer reference architecture for AI-native software development platforms, mapping capabilities from Anthropic, OpenAI, GitHub, and AWS Kiro across infrastructure, specifications, context engineering, agent orchestration, evaluation, production feedback, and governance layers, with a practical migration path from traditional DevOps.
The article opens with a core distinction: using an AI coding tool like Cursor solves a single-point problem, while building an AI-native R&D platform means designing a system that solves end-to-end process problems. The author researched four major vendors — Anthropic, OpenAI, GitHub, and AWS Kiro — and found they each tackle different layers of the same large problem: Anthropic restructures the entire R&D flow, OpenAI builds the agent runtime environment, GitHub embeds agents into the engineering control plane, and Kiro focuses on requirements-to-code transformation.
7-Layer Architecture: A Unified Map
The author abstracts a 7-layer reference architecture (not an official model from any vendor) to place these disparate approaches on one map. The layers form a bidirectional loop: L6 production data feeds back to L2 to trigger new development cycles, and L7 cuts across all layers for governance.
L1 – Engineering Infrastructure (Where): Git, repos, CI/CD, cloud — now must be directly accessible by agents. OpenAI's Harness experiments show the real limiter is not model capability but whether the environment gives agents enough tools, context, and feedback. Teams don't rebuild L1; they expose existing infra via standardized tool interfaces, sandboxes, and permissions.
L2 – Specifications & R&D Assets (What): The biggest difference from traditional R&D. Requirements are scattered across Jira, PRDs, wikis, meetings, and PMs' heads. Agents need structured, machine-readable, version-controlled artifacts. Anthropic's artifact chain: intent.md (why), requirements.md (what), spec.md (done criteria), design.md (technical design), plan.md (implementation steps), task (subtask assignment), evidence (traceable proof). Each artifact gates the next — an event-driven SDLC where downstream phases auto-trigger on upstream approval. Kiro follows the same spec-driven philosophy.
L3 – Context Engineering (Know): Called the highest technical barrier. Simple RAG (semantic search) returns code fragments but misses call graphs, impact analysis, recent changes, test coverage, and architectural constraints. Example task: "Modify login logic to add failure-count limiting." RAG returns login.ts, auth.ts, user.ts snippets. A Code Graph answers: AuthService called by LoginController, depends on TokenService + UserRepository, used by /api/login, /api/refresh, /api/oauth/callback, tests in auth.test.ts, login.e2e.ts, recent commit abc123 fixed token expiry. OpenAI calls this "Repository as System of Record"; ByteDance's TRAE positions as "Context Engineer." L3 also includes steering rules, skills, and repository context.
L4 – Agent Runtime & Orchestration (How): One agent is rarely enough. Real tasks need planner, coder, tester, reviewer, security, deploy agents. OpenAI's Harness provides a controlled execution environment with five subsystems: Agent Runtime (model + context + tools + memory + state), Orchestrator (task decomposition → planner → subagents → dependency management), Tool System (Git, GitHub, FS, terminal, browser, DB, MCP), Workspace (git worktree, sandbox containers, isolation), Recovery (failure diagnosis → retry → rollback → human escalation). Codex in Harness can edit code, run tests, start apps, drive browsers, view screenshots, query logs, create PRs, handle reviews, fix CI, and merge.
L5 – Quality Verification & Delivery (Prove): Traditional: code → unit → e2e → code review → CI → release. AI-native adds: agent self-test → agent review → Eval → security scan → CI → human gate → release. Traditional tests ask "did code fail at runtime?" Eval asks "did the agent complete the correct engineering task?" An agent may pass all tests but change the wrong files or miss required changes. Anthropic's Continuous Evals act as AI-native stage-gate QA; real tasks become eval cases, production incidents feed back into the eval suite. L5 outputs Evidence — a structured, traceable proof bundle. An AI-native PR includes: Spec, Plan, Diff, Unit Tests, E2E, Agent Eval, Security Scan, Review, Evidence — aggregating scattered info for efficient human gating.
L6 – Production Feedback (Observe): Traditional: alert → SRE dashboard → analyze → fix → ticket → dev. AI-native: production control-band breach → agent auto-diagnoses → writes new intent.md → re-enters R&D loop. True closed loop: production issues automatically trigger development tasks. Trend: Code Graph and Observability Graph merge so SRE agents know
A → B → Database → Latency↑ → ErrorRate↑ → Deployment#123 → Commit abc123.
L7 – Organizational Governance (Govern): As agents grow stronger, governance questions become unavoidable: which code can agents read/write? who authorizes production deploys? audit trails? accountability? Core: extend permission systems from humans to agents. Traditional: Developer → Git Permission → push to main. AI-native: Planner Agent → read-only repo + spec, no code write; Coder Agent → read repo + write worktree + run tests; Reviewer Agent → read diff + test results, no code write;
Deploy Agent → read CI results + deploy to staging, prod needs human approval. GitHub Agentic Workflows already enforce default read-only, declarative safe-outputs for writes, sandboxes, network isolation, tool allow-lists, human approvals. L7 also covers audit logs, risk classification, cost control, compliance checks.
Vendor Strengths by Layer
L1 Infra: GitHub leads (GitHub); Anthropic (Git / CI / Runtime), OpenAI (Repo / CI / DevTools), AWS Kiro (AWS / Git).
L2 Spec: Anthropic leads (intent/spec/plan); AWS Kiro leads (Requirements/Design/Tasks); OpenAI (Intent / Exec Plans), GitHub (Issue / PR).
L3 Context: OpenAI leads (Repo as System of Record); Anthropic (CLAUDE.md / Skills), GitHub (Repo Context), AWS Kiro (Steering).
L4 Agent: OpenAI leads (Codex / Harness); Anthropic (Claude Code / Subagents), GitHub (Coding Agent), AWS Kiro (Kiro Agent).
L5 Verify: Anthropic leads (Continuous Evals); OpenAI (Feedback Loop), GitHub (Actions / Checks), AWS Kiro (Tests / Validation).
L6 Prod: Anthropic leads (Closing Loop); OpenAI (Observability), GitHub (Actions / Events), AWS Kiro (AWS Operations).
L7 Gov: GitHub leads (Permissions / Safe Outputs); Anthropic (Hooks / Human Gates), OpenAI (Harness Policy), AWS Kiro (Steering / Controls).
Summary: Anthropic leads L2+L5+L6 (spec system + eval + production loop); OpenAI leads L3+L4 (context engineering + agent harness); GitHub leads L1+L5+L7 (engineering control plane + CI + governance); Kiro leads L2 (spec-driven engineering). They are complementary. A full platform can combine: R&D process design ← Anthropic, Agent Runtime ← OpenAI Harness, Engineering control plane ← GitHub, Spec methodology ← Kiro, Context infra ← Code Graph.
What's New vs. Existing
AI-native SDLC does not replace DevOps; it adds layers on top. L1, L5 (CI/test), L6 (monitoring), L7 (permissions) already exist. Truly new: L2 (spec system), L3 (context engineering), L4 (agent runtime), and L5's new Eval + Evidence components. Migration is incremental layering, not rip-and-replace.
Maturity Assessment & Migration Path
If your flow is Jira → Developer → Cursor/Claude → Code → Jenkins, you're at L1 + partial L4 = AI-assisted, not AI-native. True AI-native:
Intent → Spec → Context → Agent → Eval → Evidence → Gate → Deploy → Production → Feedback → Intent, each phase auto-triggered by prior artifact.
Recommended stepwise path:
Build L2 first: structure requirements, shift from Jira tickets to intent.md + spec.md.
Then L3: provide Code Graph and repository context to agents.
Then L4: introduce coding agents that complete full engineering tasks.
Then L5: establish eval system so agent output is verifiable.
Finally L6+L7: close production feedback loop, implement governance.
Each step delivers value independently.
Key Takeaways
AI-native R&D platform is a 7-layer system, not a single tool.
Mnemonic: Where · What · Know · How · Prove · Observe · Govern.
Anthropic, OpenAI, GitHub, Kiro each dominate different layers — complementary, not competitive.
AI-native extends DevOps by adding L2 (spec), L3 (context), L4 (agent), and L5's eval/evidence.
Adopt incrementally: L2 → L3 → L4 → L5 → L6/L7.
Next article will dive into L2 — the artifact chain from intent.md to evidence, schemas, trigger mechanics, and making the chain run end-to-end.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Qborfy AI
A knowledge base that logs daily experiences and learning journeys, sharing them with you to grow together.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
