[HN Gopher] Launch HN: Nia (YC S25) - Give better context to cod...
___________________________________________________________________
Launch HN: Nia (YC S25) - Give better context to coding agents
Hi HN, I am Arlan and I am building Nia (https://trynia.ai), a
context layer for AI coding agents. Nia lets tools like Cursor,
Claude Code, and other MCP clients index and query real codebases
and documentation so they stop hallucinating against outdated or
wrong sources, with applications beyond coding agents to any AI
system that requires grounded context across domains. Coding
agents are only as good as the context you give them. General
models are trained on public code and documentation that is often
old, and they usually have no idea what is inside your actual repo,
internal wiki, or the exact version of a third party SDK you use.
The result is very familiar: you paste URLs and code snippets into
the prompt, the agent confidently uses an outdated API or the wrong
framework version, and you spend more time verifying and correcting
it than if you had written the code yourself. Once models are good
enough at generating code, feeding them precise, up-to-date context
becomes the bottleneck. I ran into this pattern first on my own
projects when (a few months ago) I was still in high school in
Kazakhstan, obsessed with codegen tools and trying every coding
agent I could find. I saw it again when I got into YC and talked to
other teams who were also trying to use agents on real work. The
first version of Nia was basically "my personal MCP server that
knows my repos and favorite doc sites so I do not have to paste
URLs into Cursor anymore." Once I saw how much smoother my own
workflow became, it felt obvious that this should be a product
other people could use too. Under the hood, Nia is an indexing and
retrieval service with an MCP interface and an API. You point it at
sources like GitHub repositories, framework or provider docs, SDK
pages, PDF manuals, etc. We fetch and parse those with some simple
heuristics for code structures, headings, and tables, then
normalize them into chunks and build several indexes: a semantic
index with embeddings for natural language queries; a symbol and
usage index for functions, classes, types, and endpoints; a basic
reference graph between files, symbols, and external docs; regex
and file tree search for cases where you want deterministic matches
over raw text. When an agent calls Nia, it sends a natural
language query plus optional hints like the current file path,
stack trace, or repository. Nia runs a mix of BM25 style search,
embedding similarity, and graph walks to rank relevant snippets,
and can also return precise locations like "this function
definition in this file and the three places it is used" instead of
just a fuzzy paragraph. The calling agent then decides how to use
those snippets in its own prompt. One Nia deployment can serve
multiple agents and multiple projects at once. For example, you can
have Cursor, Claude Code, and a browser based agent all pointed at
the same Nia instance that knows about your monorepo, your internal
wiki, and the provider docs you care about. We keep an agent
agnostic session record that tracks which sources were used and
which snippets the user accepted. Any MCP client can attach to that
session id, fetch the current context, and extend it, so switching
tools does not mean losing what has already been discovered. A lot
of work goes into keeping indexes fresh without reprocessing
everything. Background workers periodically refetch configured
sources, detect which files or pages changed, and reindex those
incrementally. This matters because many of the worst
"hallucinations" I have seen are actually the model quoting valid
documentation for the wrong version. Fixing that is more about
version and change tracking than about model quality. We ship Nia
with a growing set of pre-indexed public sources. Today this
includes around 6k packages from common frameworks and provider
docs, plus package search over thousands of libraries from
ecosystems like PyPI, npm, and RubyGems, as well as pre indexed
/explore page where everyone can contribute their sources! The idea
is that a new user can install Nia, connect nothing, and still get
useful answers for common libraries. Then, as soon as you add your
own repos and internal docs, those private sources are merged into
the same index. Some examples of how people use Nia so far: -
migrating from one payments provider or API version to another by
indexing the provider docs plus example repos and letting the agent
propose and iterate on patches; - answering "how do I do X in this
framework" by indexing the framework source directly instead of
relying only on official docs that might be stale; - turning an
unfamiliar public codebase into a temporary wiki to self onboard,
where you can ask structural questions and jump to specific files,
functions, or commits; - building a browser agent that answers
questions using up to date code and docs even when the public
documentation lags behind. Nia is a paid product
(https://www.trynia.ai/) but we have a free tier that should be
enough for individuals to try it on real projects. Above that there
is a self-serve paid plan for heavier individual use, and
organization plans with higher limits, SOC 2, seat based billing,
and options for teams that want to keep indexing inside their own
environment. For private GitHub repos we can clone and index
locally so code does not leave your infrastructure. We store
account details and basic telemetry like query counts and errors to
operate the service, and we store processed representations of
content you explicitly connect (chunks, metadata, embeddings, and
small graphs) so we can answer queries. We do not train foundation
models on customer content and we do not sell user data. Moreover,
I can see Nia play out in the larger context of the agents space
due to the global problem of providing reliable context to those
systems. Early signals show that people are already using Nia for
healthcare data, cloning Paul Graham by indexing all of his essays
and turning him into an AI agent, using Naval's archive to build a
personalized agent, and more. I would love to get Nia into the
hands of more engineers who are already pushing coding agents hard
and see where it breaks. I am especially interested in hearing
about failure modes, annoying onboarding steps, places where the
retrieval logic is obviously wrong or incomplete, or any security
concerns I should address. I will be in the thread to answer
questions, share more technical details, and collect any brutal
feedback you are willing to give!
Author : jellyotsiro
Score : 74 points
Date : 2025-12-08 17:10 UTC (5 hours ago)
(HTM) web link (www.trynia.ai)
(TXT) w3m dump (www.trynia.ai)
| RomanPushkin wrote:
| Having this RAG layer was always another thing to try for me. I
| haven't coded it myself, and super interested if this gives a
| real boost while working with Claude. Curious from anyone who
| have already tried the service, what's your feedback? Did you
| feel you're getting real improvements?
| jellyotsiro wrote:
| Wouldn't call it just RAG though. Agentic discovery and
| semantic search are the way to go right now, so Nia combines
| both approaches. For example, you can dynamically search
| through a documentation tree or grep for specific things.
| zwaps wrote:
| We call it agentic RAG. The retriever is an agent. It's still
| RAG
| jellyotsiro wrote:
| Which would be much better than the techniques used in
| 2023. As context windows increase, combining them becomes
| even easier.
|
| There are a lot of ways of how you can interpret agentic
| rag, pure rag, etc
| zwaps wrote:
| Absolutely insane that we celebrated coding agents getting rid of
| RAG, only with the next innovation being RAG
| choilive wrote:
| The pendulum swings back.
| jellyotsiro wrote:
| Not exactly just RAG. The shift is agentic discovery paired
| with semantic search.
|
| Also, most of the coding agents still combine RAG and agentic
| search. See cursor blog about how semantic search helps them
| understand and navigate massive codebases:
| https://cursor.com/blog/semsearch
| ModernMech wrote:
| This is happening over and over and over. The example of prompt
| engineering is just a form of protocol. Context engineering is
| just about cache management. People think LLMs will replace
| programming languages and runtimes entirely, but so far it
| seems they have been used mostly to write programs in
| programming languages, and I've found they're very bad
| interpreters and compilers. So far, I can't really pick out
| what exactly LLMs are replacing except the need to press the
| individual keys on the keyboard, so I still struggle to see
| them as more than super fancy autocomplete. When the hype is
| peeled away, we're still left with all the same engineering
| problems but now we have added "Sometimes the tool hallucinates
| and gaslights you".
| dang wrote:
| " _Please don 't post shallow dismissals, especially of other
| people's work. A good critical comment teaches us something._"
|
| " _Don 't be snarky._"
|
| https://news.ycombinator.com/newsguidelines.html
| govping wrote:
| The context problem with coding agents is real. We've been
| coordinating multiple agents on builds - they often re-scan the
| same files or miss cross-file dependencies. Interested in how Nia
| handles this - knowledge graph or smarter caching?
| jellyotsiro wrote:
| hey! knowledge graphs are also used at runtime but paired with
| other techniques, since graphs are only useful for relationship
| queries.
| 6thbit wrote:
| This looks neat, we certainly need more ideas and solutions on
| this space, I work with large codebases daily and the limits on
| agentic contexts are constantly evident. I've some questions
| related to how I would consume a tool like this one:
|
| How does this fare with codebases that change very frequently? I
| presume background agents re-indexing changes must become a
| bottleneck at some point for large or very active teams.
|
| If I'm working on a large set of changes modifying lots of files,
| moving definitions around, etc., meaning I've deviated locally
| quite a bit from the most up to date index, will Nia be able to
| reconcile what I'm trying to do locally vs the index, despite my
| local changes looking quite different from the upstream?
| jellyotsiro wrote:
| great question!
|
| For large and active codebases, we avoid full reindexing. Nia
| tracks diffs and file level changes, so background workers only
| reindex what actually changed. We are also building "inline
| agents" that watch pull requests or recent commits and
| proactively update the index ahead of your agent queries.
|
| Local vs upstream divergence is a real scenario. Today Nia
| prioritizes providing external context to your coding agents:
| packages, provider docs, SDK versions, internal wikis, etc. We
| can still reconcile with your local code if you point the agent
| at your local workspace (cursor and claude code already provide
| that path). We look at file paths, symbol names and usage
| references to map local edits to known context. In cases where
| the delta is large, we surface both the local version and the
| latest indexed version so the agent understands what changed.
| mritchie712 wrote:
| Cursor promises to do this[0] in the product, so, especially on
| HN, it'd be best to start with "why this is better than Cursor".
|
| > favorite doc sites so I do not have to paste URLs into Cursor
|
| This is especially confusing, because cursor has a feature for
| docs you want to scrape regularly.
|
| 0 - https://cursor.com/docs/context/codebase-indexing
| jellyotsiro wrote:
| The goal here is not to replace Cursor's own local codebase
| indexing. Cursor already does that part well. What Nia focuses
| on is external context. It lets agents pull in accurate
| information from remote sources like docs, packages, APIs, and
| broader knowledge bases
| jondwillis wrote:
| That's what GP is saying. This is the Docs feature of Cursor.
| It covers external docs/arbitrary web content.
|
| `@Docs` -- will show a bunch of pre-indexed Docs, and you can
| add whatever you want and it'll show up in the list. You can
| see the state of Docs indexing in Cursor Settings.
|
| The UX leaves a bit to be desired, but that's a problem
| Cursor seems to have in general.
| jellyotsiro wrote:
| yeah ux is pretty bad and overall functionality. it still
| relies on a static retrieval layer and limited index scope.
|
| + as I mentioned above there are many more use cases than
| just coding.Think docs, APIs, research, knowledge bases,
| even personal or enterprise data sources the agent needs to
| explore and validate dynamically.
| nrhrjrjrjtntbt wrote:
| As an AI user (claude code, rovo, github copilot) I have
| come across this. In code it didnt build something right
| where it needed to use up to date docs. Luckily those
| people have now made an MCP but I had to wait. For a
| different project I may be SOL. Suprised this isnt
| solved, well done for taking it on.
|
| From a business point of view I am not sure how you get
| traction without being 10x better than what Cursor can
| produce _tomorrow_. If you are successful the coding
| agents will copy your idea and then people being lazy and
| using what works have no inventive to switch.
|
| I am not trying to discourage. More like encourage you to
| figure out how you get that elusive moat that all
| startups seek.
|
| As a user I am excited to try it soon. Got something in
| mind that this should make easier.
| jellyotsiro wrote:
| thanks! will be waiting for ur feedback
| bn-l wrote:
| This is different because of the background refresh, the
| identifier extraction and the graph. I know because I use
| cursor and am building the exact same thing oddly enough.
| orliesaurus wrote:
| Benchmarks?
| dang wrote:
| Arlan had this in his text but I cut it for brevity - sorry
| about that! Here's the bit:
|
| _In our internal benchmark on bleeding edge SDK and library
| features, Nia produced the lowest hallucination rate among the
| context providers and search tools we tested (context7, exa
| code, etc), and I wrote up the setup and results in a separate
| blog post:https://www.nozomio.com/blog/nia-oracle-benchmark_
| jellyotsiro wrote:
| https://www.nozomio.com/blog/nia-oracle-benchmark
| marwamc wrote:
| I've no idea what their architecture/implementation looks like,
| but I've built a similar tool for my own use and the improvements
| are dramatic to say the least.
|
| Mine's a simple BM25 index for code keyword search (I use it
| alongside serena-mcp) and for some use cases the speeds and token
| efficiency are insane.
|
| https://gitlab.com/rhobimd-oss/shebe#comparison-shebe-vs-alt...
| jellyotsiro wrote:
| looks cool, what's the largest codebase you have tested it on?
| marwamc wrote:
| OpenEmr and Istio. https://gitlab.com/rhobimd-
| oss/shebe/-/blob/main/docs/Perfor...
| dang wrote:
| (I detached this subthread from
| https://news.ycombinator.com/item?id=46195560 because your
| comment is fine and I don't want it to be penalized.)
| marwamc wrote:
| Thanks @dang
| ModernMech wrote:
| It's amazing that you can do this on your own but the company
| in question cannot although they have raised $6M. If your
| README were their entire pitch and website and, it would be
| 100000x more convincing.
| bluerooibos wrote:
| YC these days is just a fast track for rich kids to raise
| millions with nothing but a landing page.
|
| Vaporware.
| dang wrote:
| [under-the-rug stub]
|
| [see https://news.ycombinator.com/item?id=45988611 for
| explanation]
| himike wrote:
| I love Nia, keep it up Arlan
| jellyotsiro wrote:
| thank you haha!
| johnsillings wrote:
| super smart. congrats on the launch!
| ramzirafih wrote:
| Love it.
| phegler wrote:
| Amazing product. As an individual heavy user I must say it does
| what it is supposed to do and it does it well.
| jellyotsiro wrote:
| glad to hear that!
| rushingcreek wrote:
| Congrats on the launch! Definitely a problem I've run into
| myself.
| ayushrodrigues wrote:
| congrats on the launch Arlan! Nia is a lifesaver when we're
| coding :)
| agentastic wrote:
| Congrats on the launch, Nia looks great.
| canopi wrote:
| Congrats on the launch. The problem is definitely there. I wonder
| how are you planning to differentiate yourself from Cursor and
| the like. You mention you are complementary, but Cursor provide
| similar features to add external doc context for instance to a
| prompt. I understand you do better in your benchmark, but with
| the amount of funding they may be able to replicate and improve
| over it (unless you have a secret thing).
| jellyotsiro wrote:
| as I mentioned above there are many more use cases than just
| coding (APIs, research, knowledge bases, even personal or
| enterprise data sources the agent needs to explore and validate
| dynamically)
|
| I started out with coding agents specifically because it came
| from personal pain of how horrible they are with providing up
| to date context.
| bn-l wrote:
| Is the RAG database on your servers or is it local? If not local
| is there a local option?
| jellyotsiro wrote:
| hey! i use multiple DBs but the primary ones are turbopuffer
| and chroma for package search. they are really great
|
| re local, I do local for certain companies!
| kenforthewin wrote:
| Congrats. From my experience, Augment (https://augmentcode.com)
| is best in class for AI code context. How does this compare?
| jellyotsiro wrote:
| augment is a coding agent. nia is an external context engine
| for coding agents that improves their code output quality
| kenforthewin wrote:
| Sure, but Augment's main value add is their context engine,
| and imo they do it really well. If all they had to do was
| launch an MCP for their context engine product to compete, I
| think the comparison is still worth exploring.
| emmabotbot wrote:
| https://x.com/igoro/status/1995960021331706319
| jellyotsiro wrote:
| yeah, their mcp is to provide better context of your own
| codebase. not external information.
| chrisweekly wrote:
| This looks interesting and worthwhile. I did a double-take when I
| read _" when (a few months ago) I was still in high school in
| Kazakhstan"_
| mike1505 wrote:
| How does it compare to Serena MCP? :)
|
| https://github.com/oraios/serena
| jellyotsiro wrote:
| Serena is great for semantic code editing and symbol-level
| retrieval on your own codebase. It gives the agent IDE-like
| capabilities inside the repo. Nia focuses on a different layer.
| We target external context: remote code, docs, packages, APIs,
| research, enterprise knowledge, etc
|
| w nia the agent can dynamically search, traverse, and validate
| information outside the local project so it never hallucinates
| against out-of-date or incomplete sources.
| jacobgorm wrote:
| SOTA on internal benchmark?
| jellyotsiro wrote:
| going to open source it soon :)
| alex-ross wrote:
| This resonates. I'm building a React Native app and the biggest
| friction with AI coding tools is re-explaining context every
| time.
|
| How does Nia handle project-specific patterns? Like if I always
| use a certain folder structure or naming convention, does it
| learn that?
| jellyotsiro wrote:
| Nia is focused on external context rather than learning the
| patterns inside your own codebase. Cursor and IDE-native tools
| are better for local project structure today. Where Nia helps
| is when the agent needs ground truth from outside your repo.
| For example, you can index React Native docs, libraries you
| depend on, API references or Stack for your backend and let the
| agent search and validate against those sources directly
| instead of losing context between prompts.
___________________________________________________________________
(page generated 2025-12-08 23:00 UTC)