AI is no longer the bottleneck. Context is.
A few years ago, the biggest challenge was getting AI to generate decent code.
Today?
GPT-5, Claude, Gemini, Codex, and other models can all produce surprisingly good code.
Yet many teams are still struggling to build production software with AI.
Why?
Because every AI session starts with an empty understanding of your engineering organization.
It doesn't know:
- Why your architecture is designed that way.
- Which patterns your team has already agreed on.
- What security policies must never be violated.
- How services relate to one another.
- What trade-offs have already been made.
- Which decisions are still open for discussion.
We keep solving this with longer prompts.
Or by copying documentation into chat.
Or by hoping the AI "remembers."
None of these approaches scale.
I think the missing layer isn't a more powerful language model.
It's a structured engineering context that every AI agent can understand and reuse.
That's one of the core ideas behind the project I'm building, NAEOS.
Instead of treating prompts as the source of truth, I'm exploring the idea that architecture, policies, documentation, knowledge, and engineering decisions should become first-class assets that AI can consume consistently.
Maybe the future of AI software engineering isn't about better prompts.
Maybe it's about better systems.
I'm curious how other founders and engineers are approaching this.
How does your team preserve engineering context when working with AI?
This hits the nail on the head.
We’ve definitely reached the point where raw model capability outpaces organizational context. Prompt engineering is just a temporary patch for what is fundamentally a systemic information architecture problem.
A few ways teams are trying to tackle this right now:
Repository-as-Context (RAG/Indexing): Using local vector indices to auto-fetch related architecture docs and code conventions before sending context to the LLM.
System Prompts & Repo Configs: Hardcoding strict .cursorrules or system prompt files directly into repositories so the AI adopts team-specific constraints by default.
Architectural Decision Records (ADRs): Keeping lightweight, version-controlled markdown files in the codebase that explain the why behind design choices, giving the AI immediate access to historical trade-offs.
Treating architectural intent and organizational knowledge as first-class, machine-readable assets (like NAEOS is aiming to do) feels like the logical next step.
I think the interesting distinction is that most of these approaches improve context retrieval, while the harder problem is context interpretation.
RAG, repository rules, and ADRs help the model access relevant information, but they still leave the model to infer which constraints matter most, how different decisions relate to each other, and when a historical decision should or shouldn't apply.
That's why representing organizational reasoning as structured knowledge is compelling. It's less about giving the AI more context, and more about giving it context with explicit relationships, priorities, and rationale instead of expecting those to emerge from scattered documents alone.
Thanks, I completely agree.
The approaches you mentioned are all valuable, but to me they're still optimizing context retrieval, not context structure.
RAG, repository rules, and ADRs help AI find and consume information more effectively, but they still assume the underlying organizational knowledge is already coherent and machine-readable. In reality, most engineering knowledge remains fragmented across code, docs, tickets, chats, and people's heads.
What we're exploring with NAEOS is a layer that makes architectural intent, organizational constraints, and decision logic explicit from the start—not just retrievable after the fact. The goal isn't to give the model more context, but to give it structured context that stays consistent as teams and systems evolve.
I think that's the shift we'll eventually see: moving from "AI that searches our knowledge" to "AI that operates on a living organizational model."
The shift from retrieval to structured context makes sense. It's the difference between giving AI a filing cabinet versus giving it a mental model of how the organization thinks.
Exactly. That's a great way to frame it.
I'd even take it one step further: a mental model shouldn't just describe how the organization thinks, but also preserve why it thinks that way.
Architecture is ultimately a history of decisions, constraints, trade-offs, and accumulated knowledge. If AI only retrieves documents, it can reference past decisions without understanding the reasoning behind them. But if that reasoning is represented as a structured, evolving knowledge model, the AI can reason consistently with the organization's architectural intent instead of treating every request as an isolated prompt.
That's the direction we're pursuing with NAEOS—turning organizational intelligence into a living, machine-understandable system rather than a collection of documents for retrieval.
The 'why' behind decisions is exactly what gets lost. Documents capture what was decided, not why. That gap is where AI gets confused and humans get frustrated.
I think that's the fundamental problem.
The "why" isn't just documentation—it's the organization's reasoning process. Once that reasoning is lost, every new engineer, and every AI system, has to reconstruct it from artifacts that were never designed to preserve intent.
That's why I see this as more than a documentation problem. It's a knowledge representation problem.
If architectural intent, constraints, assumptions, and trade-offs are represented as first-class, machine-readable entities with explicit relationships, AI no longer has to infer organizational reasoning from scattered documents. It can navigate the same decision model that humans use.
In that sense, NAEOS isn't trying to build a better documentation system or a better RAG layer. It's aiming to provide the cognitive architecture that sits beneath both—where the organization's reasoning becomes persistent, queryable, and continuously evolves alongside the software itself.
Knowledge representation problem — that's the right framing. Documentation captures output, not reasoning. And you can't reconstruct reasoning from output alone.
Exactly. In information theory terms, the reasoning process contains information that is discarded once only the final decision is recorded. The output is a compressed artifact of a much richer decision space, so trying to reconstruct the original reasoning from that artifact is fundamentally underdetermined.
That's why I think we need to stop treating reasoning as something that happens before documentation. It should become part of the architecture itself.
For me, that's the core hypothesis behind NAEOS: architectural reasoning should be captured as a persistent knowledge graph of decisions, assumptions, constraints, alternatives, evidence, and their relationships. Documentation then becomes just one possible view of that underlying model, rather than the model itself.
If that model exists, AI doesn't have to reverse-engineer intent from documents—it can reason directly over the same knowledge structure that produced those documents in the first place.
Interesting thread. One thing I'm curious about with the living-model approach: who actually keeps it current? Is the plan for engineers to be responsible for updating the model when a decision changes, or is the idea that the AI itself detects drift and updates it? If it's the latter, how would that tie into the actual PDLC — does it run as part of code review, at merge time, or as some separate background process? That distinction feels important, because a context layer that requires manual upkeep tends to decay the same way documentation does, but a self-updating one raises its own trust questions.
I think that's the key implementation question. A knowledge model that's entirely manual will likely suffer the same entropy as documentation, while a fully autonomous one introduces governance and trust challenges.
The approach that seems most practical is treating updates as evidence-driven rather than AI-driven. Code changes, ADRs, design discussions, and reviews become signals that propose changes to the organizational model, while humans approve or reject those proposals when they affect architectural intent.
That also fits naturally into the PDLC. Instead of a separate documentation task, the knowledge model evolves alongside the development workflow, with AI acting as an observer and synthesizer rather than the final authority. The goal isn't for AI to own organizational knowledge, but to keep it synchronized with how the organization actually evolves.