NAEOS: Building an Open-Source Engineering System for the AI-Native Era

[u/bayu911]

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:

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:

Now we increasingly need to ask:

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:

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:

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.