NAEOS: Building an Open-Source Engineering System for the AI-Native Era
Software development is changing.
AI coding agents can now read repositories, implement features, write tests, refactor code, investigate bugs, and perform increasingly complex engineering tasks.
Tools such as Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, and other AI agents are becoming part of the everyday development workflow.
But there is a problem that becomes more obvious as these agents become more capable:
How do we make AI agents follow the engineering system of a project instead of simply generating code?
This is the problem I am exploring with NAEOS — Nusantara AI Engineering Operating System.
What is NAEOS?
NAEOS is an open-source engineering framework for building production-ready software with AI coding agents.
The goal is not to create another AI coding assistant.
Instead, NAEOS provides an engineering layer around AI agents:
┌──────────────────────────────────────┐
│ NAEOS │
│ │
│ Governance │
│ Engineering Constitution │
│ Architecture Standards │
│ Security Policies │
│ Testing Standards │
│ Documentation Standards │
│ AI Instructions │
│ Playbooks │
│ Knowledge │
│ Quality Gates │
└──────────────────┬───────────────────┘
│
┌──────────┼──────────┐
↓ ↓ ↓
Codex Claude Code Cursor
↓ ↓ ↓
└──────────┼──────────┘
↓
Repository
The idea is simple:
Different agents, one engineering system.
Why does this matter?
AI coding agents are becoming increasingly autonomous.
A traditional development workflow might look like:
Developer
↓
Design
↓
Implementation
↓
Testing
↓
Review
↓
Deployment
An AI-native workflow can look more like:
Human
↓
Intent
↓
AI Agent
↓
Implementation
↓
Testing
↓
Validation
↓
Review
↓
Deployment
The bottleneck therefore changes.
Previously, we were primarily concerned about:
Can developers write enough code?
Now we increasingly need to ask:
Can AI agents consistently operate within our engineering constraints?
An agent can produce code that compiles and passes basic tests while still violating:
- architecture decisions
- security policies
- domain boundaries
- coding standards
- testing requirements
- documentation requirements
- organizational conventions
This is where an engineering layer becomes interesting.
From prompts to engineering systems
Today, many teams manage AI context using files such as:
AGENTS.md
CLAUDE.md
.cursor/rules
.github/copilot-instructions.md
README.md
docs/
These are useful.
But as projects become more complex, engineering knowledge becomes distributed across many locations.
The problem isn't simply having instructions.
The problem is governance and consistency.
NAEOS explores whether these concepts can be formalized into a reusable engineering framework.
Instead of treating AI instructions as isolated prompts, we can treat them as part of a larger system:
Principles
↓
Constitution
↓
Policies
↓
Architecture
↓
Workflows
↓
AI Instructions
↓
Implementation
↓
Quality Gates
NAEOS Reference Architecture
One of the core ideas in NAEOS is the NAEOS Reference Architecture (NRA).
The architecture defines a layered model for the system:
Governance Layer
↓
Constitution Layer
↓
Profiles / Policies
↓
Kernel
↓
Runtime
↓
Compiler
↓
AI Layer
↓
Extensions
Each layer has a different responsibility.
Governance
Defines the strategic direction of the engineering system.
Constitution
Defines fundamental engineering principles.
Examples include:
- architecture
- security
- testing
- documentation
- AI usage
Policies
Translate principles into enforceable rules.
Kernel
Provides the core concepts and mechanisms of the framework.
Runtime
Defines how workflows and engineering processes are executed.
Compiler
Transforms engineering definitions and specifications into usable artifacts.
AI Layer
Connects engineering knowledge and constraints with AI agents.
Extensions
Allow the ecosystem to expand without modifying the core.
The architecture is intentionally modular and vendor-neutral.
Engineering Constitution
One of the concepts I consider most important is the Engineering Constitution.
Most software projects have architectural decisions and coding standards.
But they are often scattered across:
- documentation
- pull requests
- tribal knowledge
- code reviews
- Slack messages
- issue discussions
Over time, new developers have to reconstruct the reasoning behind those decisions.
AI agents have the same problem.
A constitution provides a formal place for fundamental engineering principles.
For example:
Architecture Principle
Systems MUST maintain clear separation
between domain, application, infrastructure,
and interface concerns.
Or:
Testing Principle
Production behavior MUST be covered by
appropriate automated tests before merge.
The exact rules will differ between projects.
The important idea is that engineering decisions become explicit machine-readable context.
AI agents become participants in the engineering system
This leads to a different mental model.
Instead of:
Human → AI → Code
we can think about:
Engineering System
│
┌─────────────┼─────────────┐
↓ ↓ ↓
Policies Architecture Knowledge
│ │ │
└─────────────┼─────────────┘
↓
AI Agent
↓
Code
↓
Quality Gates
The AI agent is no longer operating in isolation.
It becomes one participant inside a defined engineering process.
Quality Gates
Another important part of NAEOS is verification.
AI-generated code should not automatically be considered production-ready.
A potential workflow is:
Requirement
↓
Planning
↓
AI Implementation
↓
Unit Tests
↓
Integration Tests
↓
Security Validation
↓
Architecture Validation
↓
Documentation
↓
Quality Gate
↓
Merge
The goal is not to eliminate human review.
The goal is to make AI-assisted development more deterministic and auditable.
Vendor neutrality
NAEOS is intentionally not tied to a single AI provider.
The ecosystem is evolving too quickly to assume that one agent will dominate forever.
A project might use:
Claude Code
Codex
Cursor
GitHub Copilot
Gemini CLI
Cline
Roo Code
Windsurf
The engineering standards should ideally remain independent of that choice.
This is one of the fundamental design principles of NAEOS:
The engineering system should belong to the project, not to the AI vendor.
Open source by design
NAEOS is being developed as an open-source project because I believe the engineering standards for AI-native development should not belong exclusively to a single company or AI provider.
There are many unresolved questions:
- What should an AI engineering constitution contain?
- Which policies should be machine-readable?
- How should agents consume architecture constraints?
- How should AI-generated decisions be recorded?
- How should organizational knowledge be preserved?
- How should quality gates evaluate AI-generated changes?
- How should multiple agents collaborate?
- What should remain under human control?
- Which parts should be standardized across organizations?
I don't think these questions have definitive answers yet.
That's exactly why I want to explore them in the open.
The bigger idea
NAEOS is based on a simple hypothesis:
AI coding agents will eventually become powerful enough that the limiting factor will not be code generation, but engineering governance.
If that happens, the next generation of developer infrastructure may need to focus less on:
“How do we generate more code?”
and more on:
“How do we build reliable systems around agents that generate code?”
That means engineering systems may increasingly need:
- explicit policies
- machine-readable standards
- architecture constraints
- reusable workflows
- organizational knowledge
- agent instructions
- verification
- observability
- governance
This is the direction I want to explore with NAEOS.
Contributing
NAEOS is still evolving.
I'm particularly interested in contributions and discussions around:
- AI-native software architecture
- engineering governance
- agent workflows
- developer tooling
- quality gates
- knowledge management
- multi-agent systems
- AI coding standards
- production AI engineering
You don't need to agree with the architecture.
In fact, disagreement is useful.
If you think this abstraction is unnecessary, I'd like to know why.
If you have experienced the problems described above, I'd like to hear how you solved them.
If you're building something similar, I'd also be interested in comparing approaches.
The goal is not simply to build another tool.
The goal is to explore what software engineering itself looks like when AI agents become first-class participants in the development process.
NAEOS
Nusantara AI Engineering Operating System
An open-source engineering framework for building production-ready software with AI coding agents.
GitHub: NAEOS Foundation
Website: naeos.dev
Built in Indonesia. Designed for a global AI-native engineering community.
You invited disagreement, so: the problem is real, but this is a lot of architecture (governance, constitution, kernel, compiler, runtime) for what most teams solve today with a good CLAUDE.md and a CI check. The risk isn't the abstraction being wrong, it's being heavier than the pain it treats. Heavy frameworks die on adoption cost, not correctness.
Nobody adopts a nine-layer system to fix "the agent ignored our test convention." They adopt the smallest thing that stops the bleeding. The wedge isn't the full NRA, it's the layer that hurts most today, likely quality gates that block a merge when an agent breaks a rule. Ship that alone, get teams hooked, then earn the rest.
Which single layer would a team adopt this week without the whole framework?
I think that's a fair challenge, and honestly, adoption cost is one of the risks I worry about most.
If I had to pick a single layer for a team to adopt this week, it would be Quality Gates.
Not the full NRA. Not the Constitution. Not the Kernel.
A lightweight quality-gate layer that sits between an AI agent and the merge:
Agent change → policy checks → tests/security/docs checks → pass or block → merge
The important part is that the gates should be machine-enforceable and agent-aware, while remaining compatible with the tools a team already uses.
The broader architecture exists because I don't think quality gates will remain isolated forever. Once teams start asking why did this gate fail?, which engineering rule does it enforce?, who decided that rule?, and how should the agent fix it?, you naturally start needing standards, policies, and engineering memory around the gates.
But I agree with your underlying point: the architecture should be earned through adoption, not imposed upfront.
So if NAEOS can't deliver immediate value through one small, independently useful layer, the nine-layer architecture is just an interesting diagram.
That's probably a useful constraint for how I should approach the next phase.
Right wedge, and your "why did this gate fail / who decided that rule" progression is the key insight: the architecture gets pulled, not imposed. Each layer earns its place only when a team hits the wall it solves, gate fails → "which rule?" pulls in policies → "who decided?" pulls in the constitution. The layers aren't a framework you sell, they're a path teams walk as they outgrow the previous one.
How to sequence: build the gate, let users' questions decide which layer comes next. If nobody asks "who decided this rule," that layer doesn't exist yet. Your roadmap is downstream of which walls people hit.
So the gate is also your research instrument. What do you expect teams to ask first once it's blocking merges?
I think the first questions will be surprisingly practical:
1. "Why did this fail?"
The agent needs a clear explanation, not just a red CI check.
2. "Which rule caused it?"
Once teams see repeated failures, they'll want the violation mapped to an explicit engineering rule rather than buried in tooling.
3. "How should the agent fix it?"
This is where the gate starts becoming more than a validator—it becomes an executable engineering contract for the agent.
4. "Can we change this rule for our project?"
That introduces project-specific policy and precedence.
5. "Who decided this rule, and why?"
That's probably the point where engineering memory and constitutional governance become necessary.
So my hypothesis is that the first layer people pull toward isn't actually "policy"—it's explainability.
The gate blocks the merge, but the explanation creates the demand for everything above it.
And I really like your framing that the gate becomes a research instrument. Rather than designing all nine layers in advance, we can observe the questions generated by real failures and let those questions reveal the next missing abstraction.
That gives NAEOS a much more empirical roadmap.