Founder Journey: Why I’m Looking for Builders
Building NAEOS started with a technical question:
What should software engineering look like when AI becomes part of the engineering team?
The more I explored that question, the bigger the problem became.
AI can already write code.
It can understand repositories.
It can generate tests.
It can refactor systems.
It can interact with tools.
It can even execute increasingly complex engineering workflows.
But there is still something missing.
The engineering system around the AI.
AI Is Getting Better. Engineering Context Is Not.
An AI agent can be extremely capable and still make the wrong decision.
Not necessarily because the model is weak.
Sometimes it simply doesn't have the right context.
It may not know:
- why an architecture was chosen
- which engineering standards matter
- what policies must be followed
- which components are critical
- what should never be changed
- how the organization defines quality
- what decisions were made months ago
This led me to a core idea behind NAEOS:
AI agents need an engineering operating environment, not just better prompts.
That environment needs architecture, specifications, policies, knowledge, validation, and governance.
This Changed the Direction of NAEOS
NAEOS is evolving around a specification-driven approach.
The idea is to make engineering intent structured and machine-readable.
Instead of allowing every tool and every AI agent to interpret a project independently, NAEOS creates a common engineering model.
The project uses NEIR — NAEOS Engineering Intermediate Representation — as a central representation connecting different parts of the engineering lifecycle.
From that foundation, NAEOS can connect specifications with validation, governance, AI context, compilation, testing, documentation, and other engineering workflows.
The goal is not to replace AI coding tools.
It is to give them a shared engineering context.
The Technology Is Only One Part of the Journey
This is where the founder journey becomes more interesting.
I can continue building the architecture.
I can continue writing code.
I can continue adding features.
But eventually I have to recognize something:
NAEOS is becoming bigger than what one person should build alone.
The next challenge isn't simply technical.
It is about:
Product.
Community.
Adoption.
Enterprise validation.
Open-source strategy.
Partnerships.
Business model.
Ecosystem.
And that changes the kind of people I am looking for.
I'm Looking for a Co-Founder
I'm not looking for someone to simply "join NAEOS."
I'm looking for someone who wants to build NAEOS with me.
Someone who can look at the current state of software engineering and see the same fundamental shift:
AI is becoming a participant in engineering.
And if that is true, then engineering organizations need a new layer of infrastructure.
A potential co-founder could be deeply technical.
They could be a product thinker.
They could understand enterprise technology.
They could be strong in developer ecosystems.
What matters most is the ability to think beyond the next feature.
I want someone who can help answer:
What should AI-native software engineering actually become?
I'm Also Looking for Strategic Partners
Not everyone needs to become a co-founder.
Some organizations may be better positioned as partners.
I'm interested in conversations with people and organizations working around:
- AI agents
- developer infrastructure
- cloud platforms
- enterprise software
- developer tools
- cybersecurity
- software architecture
- universities and research
- open source
- AI governance
The partnership could take many forms.
Integration.
Research.
Enterprise pilots.
Community.
Open-source collaboration.
Technology partnerships.
The important part is creating something larger than NAEOS alone.
Building in Public
One reason I started documenting this journey is simple:
I don't want to build in isolation.
The repository is open.
The ideas are open to criticism.
The architecture can evolve.
And the vision should be challenged.
I believe the best way to build something foundational is to let more people see it, question it, use it, break it, and improve it.
NAEOS is still a journey.
There are many things I don't know yet.
But I know the problem is worth exploring.
The Question I'm Taking Into the Next Chapter
The first chapter was about:
Can this idea be built?
The next chapter is different:
Can this become something people actually build on?
That requires more than code.
It requires people.
Builders.
Researchers.
Product thinkers.
Enterprise engineers.
Open-source contributors.
Partners.
And eventually, a team capable of turning the foundation into an ecosystem.
If You See the Same Future
If the idea of an AI Engineering Operating System resonates with you, I would love to hear your perspective.
You don't have to agree with the current architecture.
You don't have to believe every assumption is correct.
In fact, challenging those assumptions may be exactly what NAEOS needs.
What matters is that you believe there is a deeper problem worth solving.
How do we build software when AI is no longer just a tool, but an engineering participant?
That's the journey I'm documenting.
And that's the journey I'm looking for people to join.
NAEOS GitHub:
https://github.com/NAEOS-foundation/naeos
Build with us. Challenge us. Help shape what comes next.
— Bayu
Founder, NAEOS
Specify Once. Build Anywhere.
Honest feedback aimed at your actual goal, which is recruiting, not marketing: this post gives a potential co-founder nothing to grab, because everything is pitched at maximum abstraction. "AI Engineering Operating System," "engineering intermediate representation," "shared engineering context" — nobody can tell what NAEOS actually does in thirty seconds, and that's not just a landing-page problem, it's a co-founder problem.
Here's why it matters specifically for finding a co-founder. Abstract vision attracts enthusiasts who like big ideas; concrete pain attracts builders who've felt it. The right co-founder isn't someone who agrees "AI is becoming an engineering participant" in principle — that's everyone. It's someone who has personally watched an AI agent make a specific wrong call and thought "there has to be a system for this." You reach that person with the specific call, not the philosophy.
You have the raw material and you abstracted it away. Your list — "what should never be changed," "why an architecture was chosen" — is a list of abstractions where there should be one war story. "An agent refactored a component nobody told it was load-bearing and took down prod, because the constraint lived in someone's head, not in a spec the agent could read" — that sentence recruits better than your entire vision section, because a builder reads it and thinks "yes, that exact thing, I've been burned by it." The philosophy makes people nod. The scar makes the right person reply.
So before the next builders post: what's the single most concrete moment where missing engineering context made an AI agent do real damage? Lead with that, and the co-founder you want will recognize themselves in it. Do you have that story, or is NAEOS still living at the layer of abstraction where every builder agrees and none of them acts?
This is fair feedback, and I think you’re right about the distinction between explaining the vision and recruiting the person who actually needs to build it.
NAEOS started from a lot of recurring failure modes I was seeing around AI coding agents, and I probably abstracted those experiences too early.
One of the clearest examples is this:
An agent can receive a task, create a valid plan, get approval under the current policy, and start executing. Then an important constraint changes while the task is still in flight — for example, a dependency that was allowed when the plan was created is no longer permitted.
A conventional CI pipeline may eventually catch the resulting code. But the more fundamental problem happened earlier: the agent was still operating under an authorization that was valid when the plan was created, but no longer valid when the next action was about to execute.
That led me toward the idea that AI engineering needs a control layer that can reason about:
intent → policy → authorization → execution → verification → audit
and re-evaluate the authorization at the actual action boundary.
The other failure mode we've been discussing is multi-agent verification: one agent makes a change, another reviews it, but the second agent can inherit too much context or trust the first agent's reasoning. That's why I'm increasingly treating independent verification and fresh-context validation as first-class primitives rather than just another CI check.
So I agree with your broader point: the abstractions are useful for defining the architecture, but they aren't enough to recruit the right builders.
The next NAEOS material should probably start with the scars:
“Here is the failure. Here is why existing tooling didn't prevent it. Here is the smallest mechanism that would have prevented it.”
Then the larger architecture becomes the answer to a concrete engineering problem rather than the starting point.
And honestly, that's probably a better test for NAEOS itself: if I can't explain the first painful failure in a way that an experienced engineer immediately recognizes, the abstraction is probably still too high.