For the last phase of building NAEOS, I have been asking myself a simple question:
What happens when software engineering becomes specification-driven, AI-assisted, and increasingly autonomous?
I don't think the answer is another AI coding assistant.
I think we need an engineering system.
That is what I am building with NAEOS.
What NAEOS Actually Is
NAEOS stands for Nusantara Engineering & Architecture Operating System.
The core idea is:
Specify Once. Build Anywhere.
Instead of starting with code, NAEOS starts with a structured specification.
That specification becomes the source of truth for the engineering system.
From there, NAEOS can parse, normalize, resolve, validate, model, schedule, compile, generate, test, document, and manage engineering artifacts.
The project already has a working foundation for this approach.
The repository currently includes the NAEOS specification pipeline, NEIR engineering model, AI compiler, MCP integration, governance, marketplace, plugin infrastructure, testing, documentation generation, security, knowledge components, database integrations, event sourcing, distributed execution, pipeline caching, and more.
This is no longer just a concept.
The foundation exists.
Now the question becomes:
Who should build the next layer with me?
The Problem
Software engineering has become increasingly fragmented.
A modern project can involve:
- multiple programming languages
- multiple frameworks
- multiple infrastructure providers
- multiple deployment environments
- multiple engineering standards
- multiple AI coding agents
- multiple documentation systems
- multiple security requirements
And now we are adding another layer:
AI agents.
GitHub Copilot, Claude Code, Cursor, Gemini CLI, Codex, OpenCode and other systems can increasingly participate in software development.
But each tool has its own context format, instructions, capabilities, and workflow.
The engineering organization still has to provide:
Architecture
Standards
Policies
Context
Knowledge
Validation
Governance
Traceability
NAEOS is designed to become that layer.
The Core Thesis
NAEOS is built around a simple thesis:
Software should be derived from a structured engineering specification rather than assembled independently across disconnected tools.
The specification becomes the source of truth.
NAEOS transforms that specification into an internal engineering model called NEIR — NAEOS Engineering Intermediate Representation.
NEIR represents the system across architecture, domains, modules, services, APIs, storage, infrastructure, security, AI, documentation, deployment, testing, and metadata.
Conceptually:
Engineering Specification
│
▼
┌───────────────────┐
│ NAEOS Parser │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ Normalizer / │
│ Resolver │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ NEIR │
│ Engineering Model │
└─────────┬─────────┘
│
┌────────────────┼────────────────┐
▼ ▼ ▼
Validation Governance AI Compiler
│ │ │
└────────────────┼────────────────┘
▼
Engineering Artifacts
│
┌───────────────┬───┴────┬──────────────┐
▼ ▼ ▼ ▼
Code Docs Tests AI Context
This architecture is what makes NAEOS fundamentally different from a conventional project generator.
The AI Layer
One of the most important parts of NAEOS is the relationship between the engineering model and AI agents.
NAEOS can compile engineering context into instructions for multiple AI development environments.
The current repository documents adapters for:
- GitHub Copilot
- Claude Code
- Cursor
- Gemini CLI
- Codex
- OpenCode
It also includes MCP integration and LLM-optimized context bundles.
The goal is not to replace these tools.
It is to make them operate from the same engineering source of truth.
That distinction matters.
NAEOS is not trying to win the AI coding assistant war.
It is trying to build the layer above the assistants.
From Coding Assistant to Engineering Runtime
This is where I believe the bigger opportunity exists.
Today:
Developer
│
▼
AI Coding Agent
│
▼
Code
The future could look more like:
Engineering Specification
│
▼
NAEOS Engineering
Runtime
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
Governance Knowledge Policy
│ │ │
└──────────────────┼──────────────────┘
▼
AI Agent Layer
│
▼
Engineering
Actions
│
▼
Validated Artifacts
The AI agent becomes a participant inside the engineering system.
Not the system itself.
What Has Already Been Built
This is an important distinction for anyone considering joining NAEOS.
This is not a pitch deck looking for someone to build the first prototype.
The repository already contains a substantial engineering foundation.
Among the implemented areas are:
Specification Engine
NAEOS Specification Language v2 supports variables, environment resolution, references, includes, functions, conditionals, and schema versioning.
NEIR
A central engineering representation connecting architecture, implementation, infrastructure, AI, security, testing, documentation, and deployment.
Compiler
A compiler that transforms the engineering model into AI-specific instruction sets.
Governance
Policy evaluation, artifact review, and audit traceability are part of the platform.
Marketplace
NAEOS includes profile and plugin marketplace capabilities, with built-in profiles for areas such as SaaS, AI Agent, FinTech, Healthcare, and Government.
Developer Platform
The CLI already exposes a broad engineering surface including validation, compilation, context generation, testing, documentation, MCP, marketplace, profiles, artifacts, migrations, auditing, plugins, templates, workspace management, rollback, repair, and more.
Extensibility
The repository contains a plugin SDK with a WASM runtime, making extensibility a first-class architectural concern.
Infrastructure
The codebase also includes database integrations, event sourcing, distributed execution, pipeline caching, WebSocket infrastructure, security rules, observability-related components, and AI integration.
In other words:
The hard part has started.
But Building the Technology Is Not Enough
This is where I need help.
NAEOS now needs to evolve from:
a technically ambitious open-source project
into:
an ecosystem, platform, and organization.
That requires capabilities beyond writing code.
It requires product thinking.
It requires developer adoption.
It requires enterprise validation.
It requires partnerships.
It requires community.
It requires business development.
And eventually, it requires a team.
I Am Looking for a Co-Founder
I'm looking for someone who doesn't simply want to join a startup.
I'm looking for someone who wants to help define a new engineering category.
A potential co-founder could come from several backgrounds.
Technical Co-Founder
Someone with deep experience in:
- AI systems
- compiler architecture
- developer platforms
- distributed systems
- cloud infrastructure
- developer tooling
- software architecture
- agent systems
The ideal person is comfortable going deep into architecture while still thinking about product.
Product / Platform Co-Founder
Someone who can answer:
Who needs NAEOS first?
What is the smallest product that creates enormous value?
How do we turn a complex engineering platform into an understandable developer experience?
This person would help turn the existing architecture into an adoption engine.
Business / GTM Co-Founder
Someone capable of building relationships with:
- enterprises
- technology companies
- cloud providers
- AI companies
- universities
- developer communities
- strategic partners
- investors
The technical foundation already exists.
The next challenge is distribution.
Strategic Partners
Co-founder is only one path.
I'm also interested in strategic partnerships with organizations working in:
AI
AI model providers, agent platforms, AI infrastructure companies, and AI research organizations.
Developer Infrastructure
Cloud providers, DevOps platforms, CI/CD providers, observability companies, and developer tooling companies.
Enterprise
Organizations willing to experiment with specification-driven and AI-native engineering.
Education
Universities, bootcamps, engineering communities, and research institutions.
Open Source
Projects that share the same belief in open, interoperable engineering infrastructure.
What I Want to Build With Partners
Not just integrations.
I want NAEOS to become an ecosystem.
Imagine a future where an organization can install:
NAEOS
│
├── Industry Profile
│
├── Architecture Blueprint
│
├── Engineering Policies
│
├── Security Policies
│
├── AI Agents
│
├── Plugins
│
├── Templates
│
├── Knowledge
│
└── Compliance Controls
Then describe the system once.
And let the engineering platform coordinate the rest.
That is the long-term direction.
Why I'm Opening This Conversation Now
NAEOS has reached a point where building more features alone is not necessarily the highest-leverage activity.
The next phase is about answering harder questions:
Who is the first ideal customer?
Which engineering problems should NAEOS own?
Which parts should remain open source?
What becomes the commercial layer?
How should the ecosystem evolve?
Which standards should NAEOS help define?
How do we make specification-driven engineering a real industry practice?
These are not questions that should be answered by one person.
They should be answered by a team.
The Opportunity
I believe the next generation of software engineering will not be defined simply by better AI models.
It will be defined by the systems that organize those models.
The winners may not only be the companies building the smartest agents.
They may also be the companies building the engineering infrastructure that makes agents useful, controllable, interoperable, and trustworthy at scale.
That is the opportunity I see for NAEOS.
I Don't Know Exactly What NAEOS Will Become
And I think that is important to say openly.
The architecture is becoming clearer.
The problem is becoming clearer.
The technology is becoming more mature.
But the final product, business model, and ecosystem will be shaped by the people who build the next stage.
That is why I'm looking for collaborators rather than simply employees.
If You Think This Problem Matters
If you are working on:
AI agents
Developer infrastructure
Compilers
Enterprise architecture
Cloud infrastructure
Developer tools
AI governance
Software engineering
Open source
Enterprise transformation
or simply believe that software engineering needs a better foundation for the AI era—
I'd like to hear from you.
You don't need to have the same vision.
You don't need to agree with every architectural decision.
But you should be interested in the question:
What should software engineering look like when AI becomes a first-class engineering participant?
That is the question behind NAEOS.
And I believe it is worth building.
Build With Us
NAEOS is open source and available on GitHub.
Repository:
https://github.com/NAEOS-foundation/naeos
The project is currently under active development, with the latest repository state documented around the v3.1.0 line.
If you want to explore the architecture, read the specifications, run the CLI, inspect the compiler, examine the NEIR model, or simply challenge the thesis:
Start with the repository.
Then let's talk.
One Last Thought
I've spent a lot of time thinking about what NAEOS should become.
But perhaps the better question is:
Who should build it?
I don't want NAEOS to become another project built around one founder.
I want it to become a foundation that many engineers can build upon.
A platform.
An ecosystem.
A standard.
And eventually, perhaps, a new layer of the software engineering stack.
The foundation is being built.
Now I'm looking for the people who want to build the future on top of it.
— Bayu
Founder, NAEOS
Specify Once. Build Anywhere.
Architecture Drives Engineering.
Top comments (0)