naeos

Most teams start projects the same way: a spec document that slowly drifts out of sync with the code. NAEOS inverts this. You describe your system once in a YAML/JSON specification, and NAEOS builds an internal engineering model (NEIR), validates it, schedules a DAG of tasks, and generates production-quality code across Go, TypeScript, Python, Java, and Rust — with full traceability from intent to implementation.

And the spec stays the source of truth for the entire lifecycle. Watch mode re-runs the pipeline on every change, the diff engine shows what drifted, the migration engine evolves schemas across versions, and the artifact store keeps every generated output auditable.

NAEOS is built for the AI era. Its compiler transforms the engineering model into instruction sets for GitHub Copilot, Claude Code, Cursor, Gemini CLI, Codex, and OpenCode — so any AI assistant works from an accurate model of your system, not a guess. A built-in MCP server exposes the model to AI agents, and context bundles give LLMs the project summary they need in a single file.

Features

• Spec Language v2 — variable interpolation (${var}), environment resolution ($env{VAR}), cross-references ($ref{path}), multi-file composition ($include{file}), custom functions ($fn{name(args)}), and conditional sections ($if / $endif)

• Multi-language generation — Go, TypeScript, Python, Java, Rust from one specification

• AI compiler — instruction sets for 6 AI tools (Copilot, Claude Code, Cursor, Gemini CLI, Codex, OpenCode), MCP server, LLM-optimized context bundles

• 67 CLI commands — run, validate, compile, context, test, docgen, mcp, marketplace, diff, watch, migrate, and more

• NEIR-aware LSP server — autocomplete, real-time diagnostics, hover docs, and go-to-definition for .naeos.yaml files

• Profile & plugin marketplaces — 5 built-in industry profiles (SaaS, AI Agent, FinTech, Healthcare, Government), WASM plugin SDK with official example plugins

• Governance built-in — policy evaluator, artifact review, and full audit trail

• Enterprise plumbing — PostgreSQL/MySQL/SQLite, WebSocket, event sourcing, distributed task execution, stage caching, pipeline profiling

• Open source — Apache 2.0, Go, single static binary, Docker-ready

Getting started

curl -fsSL https://naeos.dev/install.sh | sh naeos create # interactive wizard — enter your project name cd my-app naeos run --input-file spec.yaml

Docs: https://docs.naeos.dev — GitHub: https://github.com/NAEOS-foundation/naeos Whitepaper: https://naeos.dev/whitepaper

3. Gallery Images

PH requires at least 3 gallery images; minimum size 750×750px, recommended 1600×900px (16:9) or square. Dark backgrounds match the brand (#05050a).

All five gallery images + the logo are already generated in assets/ (PNG, 1600×900, brand-accurate). Regenerate anytime with node launch/producthunt/assets/generate.js (requires sharp: npm i sharp).

#ImageFile1Hero cover — logo, tagline, real naeos run output in a terminal cardassets/01-hero-cover.png2Pipeline diagram — Input → Core Layer → Generation → Output with traceability barassets/02-pipeline-diagram.png3CLI screenshot — real naeos run pipeline output on a dark terminalassets/03-cli-pipeline.png4AI compiler output — naeos context bundle + 6 compiled AI instruction setsassets/04-ai-compiler.png5LSP / VS Code — .naeos.yaml with hover tooltip, diagnostics, and status barassets/05-lsp-editor.png—Logo (upload in the logo field, 240×240px)assets/logo-240.png

Do not put links in gallery images — PH strips them and it looks unprofessional.

4. Links

• Website: https://naeos.dev

• GitHub: https://github.com/NAEOS-foundation/naeos

• Documentation: https://docs.naeos.dev

• Whitepaper (EN): https://naeos.dev/whitepaper

• Release notes (v3.1.0): https://github.com/NAEOS-foundation/naeos/releases

• Community (Discord): https://discord.gg/WnUWmm7XMv

AI Can Generate Code Faster Than We Can Verify Its Knowledge.

One thing has become increasingly clear to me while building NAEOS:

The problem isn't only giving AI more context.

We also need to know whether that context is trustworthy.

Imagine an AI coding agent retrieves five pieces of engineering knowledge.

One is outdated.

One contradicts another.

One references an API that no longer exists.

One was never approved.

And one is correct.

The AI doesn't necessarily know which one is authoritative.

More context doesn't automatically mean better decisions.

Sometimes it just means more opportunities for confusion.

That's why I've started thinking about knowledge validation as a first-class part of AI engineering.

Before knowledge becomes available to an AI agent, we should be able to validate things like:

• Is the schema valid?

• Is the owner defined?

• Is the reference still valid?

• Does it contradict another approved rule?

• Are its dependencies available?

• Is the version current?

• Has it passed the required review?

• Is it allowed by organizational policy?

• Is it duplicated somewhere else?

And validation shouldn't necessarily happen only once.

Knowledge changes.

Systems change.

Dependencies change.

Policies change.

So knowledge may need continuous validation throughout its lifecycle.

I'm beginning to think about this similarly to how we treat source code.

We don't blindly deploy every line of code.

We run tests.

We perform static analysis.

We enforce policies.

We review changes.

We validate dependencies.

Why should the knowledge that guides AI engineering be treated differently?

If an AI agent is going to use engineering knowledge to make decisions, that knowledge itself needs quality gates.

This is becoming one of the core ideas behind NAEOS:

Don't just retrieve knowledge. Verify it.

Because an AI with less knowledge but high-quality context may be more useful than an AI with unlimited access to unreliable information.

I'm curious:

What should happen when two pieces of engineering knowledge contradict each other?

Should the AI choose the newest one?

The most recently approved one?

The one with the highest authority?

Or should it stop and ask a human?

I've been thinking about a problem that becomes obvious once a project gets large enough.

The problem isn't always finding information.

Sometimes the information is already there.

The problem is understanding how everything is connected.

Imagine an AI coding agent working on an authentication service.

It finds the authentication documentation.

But does it know that:

• The service depends on a specific API contract?

• That API is consumed by three other services?

• A security policy requires MFA?

• An architecture decision prohibits a particular dependency?

• A database schema is shared with another domain?

• A deployment workflow requires additional validation?

• A previous incident changed the recommended implementation?

All of those pieces may exist in different documents.

A human engineer can connect the dots.

An AI agent needs those relationships to be explicit.

That's why I've started thinking about knowledge as a graph, not just a collection of documents.

For example:

Architecture | +---- defines ----> Service | +---- exposes ----> API | +---- depends ----> Database | +---- governed by -> Security Policy | +---- tested by ---> Test Suite | +---- deployed by -> Workflow

Now the AI isn't just searching for "authentication."

It can traverse the engineering knowledge connected to authentication.

Architecture.

Dependencies.

Policies.

APIs.

Tests.

Incidents.

Deployments.

Decisions.

This changes the retrieval problem.

Instead of asking:

"Which document is relevant?"

We can start asking:

"Which knowledge and relationships are relevant to this engineering decision?"

That's a much more interesting problem.

And I think it becomes increasingly important as AI agents move from generating individual functions to modifying entire systems.

This is another area I'm exploring while building NAEOS.

The goal isn't to build a smarter search engine.

It's to create an engineering knowledge layer where relationships are first-class.

Because good engineering decisions rarely depend on one piece of information.

They depend on how many pieces of information fit together.

Do you think AI coding agents need a knowledge graph to work effectively on large software systems?

AI Doesn't Just Need Knowledge. It Needs Rules.

The more I build with AI coding agents, the more I think about something we rarely talk about:

What should the AI be allowed to do?

Giving an AI access to your architecture and documentation is useful.

Giving it project memory is useful.

But knowledge alone doesn't guarantee good engineering decisions.

Imagine giving a new engineer access to your entire company's documentation without telling them:

• Which principles are mandatory.

• Which security practices are non-negotiable.

• Which architectural patterns are approved.

• Which dependencies are prohibited.

• When they need human approval.

• What quality gates must pass before deployment.

They might have all the information.

But they still don't have the rules.

I think AI agents face the same problem.

Today, we often put these rules inside prompts:

"Always write tests."

"Don't expose secrets."

"Follow our architecture."

"Use this coding style."

"Ask before making destructive changes."

But these instructions are usually scattered across prompts, README files, configuration files, and tribal knowledge.

That's fragile.

If AI is becoming part of the engineering team, I think engineering principles should become explicit, versioned, and enforceable.

Something closer to an Engineering Constitution.

A set of principles that defines how software should be designed, implemented, tested, secured, documented, and deployed.

And importantly, it shouldn't belong to one AI tool.

It should be independent of the model or coding agent being used.

That's one of the ideas I'm exploring with NAEOS.

The AI agent can change.

The model can change.

The IDE can change.

But the engineering principles shouldn't disappear with them.

Maybe the future isn't:

"Give AI a better prompt."

Maybe it's:

"Give AI a better engineering system."

I'm curious:

What is one engineering rule you would never allow an AI coding agent to violate?

Documentation Is No Longer Written Just for Humans

For years, we treated documentation as something we wrote for other developers.

API docs.

Architecture diagrams.

Decision records.

Runbooks.

Coding standards.

The audience was always human.

But AI has changed something fundamental.

Today, one of the most frequent readers of our documentation isn't another engineer.

It's an AI coding agent.

That made me rethink what good documentation actually means.

Traditional documentation is optimized for humans.

It's okay if information is spread across multiple pages.

It's okay if some context only exists in someone's head.

It's okay if decisions are implied instead of explicitly recorded.

Humans are remarkably good at filling in the gaps.

AI isn't.

An AI agent doesn't naturally understand that an ADR explains why an architecture exists, or that a runbook captures operational constraints, or that a coding standard overrides an older README.

It only sees disconnected pieces of information unless we give them structure.

So I think we're entering a new era.

Documentation still needs to be human-readable.

But it also needs to become machine-readable.

Not just in format.

In meaning.

Relationships.

Dependencies.

Ownership.

Version history.

Decision rationale.

The goal isn't to replace documentation with AI.

It's to make documentation a reliable source of engineering knowledge for both humans and machines.

This idea has become one of the design principles behind NAEOS.

Not "documentation first."

But knowledge first.

Because documentation is valuable only when knowledge can be discovered, trusted, and reused.

I'd love to hear how other teams are thinking about this.

If AI is becoming one of the primary consumers of documentation, should we change how we write it?

I Don't Think AI Has a Memory Problem.

I Think Software Engineering Does.

When people talk about "AI memory," they usually mean giving an AI model the ability to remember previous conversations.

That's useful.

But after building with AI every day, I don't think that's the real problem.

Imagine a new engineer joining your team.

You wouldn't expect them to become productive just because they could read your last Slack conversation.

You'd give them access to:

• The system architecture.

• Technical documentation.

• Coding standards.

• Decision records.

• API contracts.

• Security policies.

• Team workflows.

• Project history.

That's what allows them to make good engineering decisions.

Now compare that to how we usually work with AI.

Every new session starts with a blank slate.

We paste context.

Upload documents.

Explain the architecture again.

Repeat the same engineering rules.

We're treating memory as conversation history.

But engineering memory is much bigger than that.

It's the accumulated knowledge of a project.

Not just what was said.

But why things were built the way they were.

The more I work on NAEOS, the more I believe AI doesn't just need memory.

It needs access to an engineering knowledge system.

A place where architecture, documentation, standards, decisions, and relationships evolve together—and where every AI agent can understand the same source of truth.

That's a very different problem from remembering yesterday's chat.

I'm curious how others think about this.

If you could give your AI coding assistant one permanent memory, what would it be?

The more I used AI coding tools, the more I realized the real problem wasn't the AI.

First of all, thank you to everyone who commented on my previous post. Reading different perspectives from founders and engineers has been incredibly valuable.

One comment kept coming back in different forms:

"AI is great until it loses context."

That resonated with me because I've experienced the same thing.

When I start a new chat with an AI coding assistant, it doesn't know anything about my project.

It doesn't know:

• Why I chose a microservices architecture instead of a modular monolith.

• Which security principles are non-negotiable.

• Why certain technical decisions were made six months ago.

• Which conventions my team has already agreed on.

• How different services and domains relate to each other.

So what do we do?

We write longer prompts.

We paste documentation into the conversation.

We upload architecture diagrams.

We remind the AI of the same rules over and over again.

Eventually, the conversation becomes less about solving problems and more about rebuilding context.

That doesn't feel like the future of software engineering.

It feels like a workaround.

This is one of the core assumptions behind NAEOS.

Instead of treating engineering knowledge as something humans read and AI occasionally references, what if we treated it as a structured system that AI could understand from the beginning?

Imagine every AI agent joining a project with access to:

• The architecture.

• The engineering standards.

• The decision history.

• The documentation.

• The security policies.

• The team's workflows.

Not as scattered documents.

But as a shared engineering foundation.

I'm still exploring whether this idea can work at scale, but the more I build, the more convinced I become that context—not code generation—is the next big challenge in AI-assisted software development.

I'd love to hear how others are solving this today.

How do you keep AI aligned with your project's engineering decisions over weeks or months of development?

Why I Don't Think Prompt Engineering Is the Future

A year ago, I believed the answer to better AI-generated code was writing better prompts.

So I did what many developers did.

I created prompt templates.

Saved reusable instructions.

Built long system prompts.

Refined them over and over.

They definitely helped.

But after working on multiple projects, I noticed something.

Every prompt eventually became outdated.

The architecture changed.

The coding standards evolved.

New services were added.

Security requirements became stricter.

The prompt that worked perfectly last month slowly drifted away from reality.

So I found myself constantly editing prompts instead of improving the software.

That's when I started asking a different question.

Maybe prompts aren't supposed to be the source of truth.

Maybe they're just an interface.

The real source of truth should live somewhere else.

Architecture.

Engineering standards.

Documentation.

Decision records.

Policies.

Domain knowledge.

Those things change over time, and they deserve versioning, reviews, approvals, and traceability—just like source code.

If AI is going to become a real engineering teammate, it shouldn't rely on a giant prompt that someone manually updates every week.

It should be able to consume structured engineering knowledge directly.

That's one of the ideas driving the design of NAEOS.

Not replacing prompts.

Reducing how much we depend on them.

I'm curious how other builders think about this.

Do you still see prompt engineering as a long-term solution, or just a bridge until better engineering systems emerge?

Hi everyone 👋

I'm an indie builder from Indonesia, and over the last few months I've been working on a project called NAEOS (Nusantara AI Engineering Operating System).

After experimenting with tools like Cursor, Claude Code, GitHub Copilot, Gemini CLI, and Codex, I noticed the same pattern:

AI can generate code incredibly fast.

But every new project still requires rebuilding the engineering foundation:

• Project structure

• Architecture decisions

• Coding standards

• Documentation

• Security rules

• Testing strategy

• AI prompts

• Team conventions

The AI is powerful.

The engineering context is often missing.

So instead of building another AI coding assistant, I'm trying to build something different:

An open AI Engineering Operating System that provides the standards, workflows, governance, and knowledge layer for AI coding agents.

The long-term vision is to make AI agents work more like experienced software engineers rather than autocomplete tools.

I'm building everything in public:

• Documentation first

• Open architecture

• Modular design

• AI-native workflows

• Vendor-neutral approach

This is still an early-stage project, and I'm looking for honest feedback.

Some questions I'd love to hear your thoughts on:

• Do you think AI development needs an "operating system" layer?

• What's the biggest engineering problem you've faced while using AI coding tools?

• Would an open standard for AI software engineering be valuable?

I'd really appreciate your feedback, criticism, or ideas.

Thanks for reading!