Live data from Hacker News

Launch HN: Nia (YC S25) – Give better context to coding agents

trynia.ai

11–20 of 92 posts

Re: Launch HN: Nia (YC S25) – Give better context to coding agents

#11
post #8

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?

hey! knowledge graphs are also used at runtime but paired with other techniques, since graphs are only useful for relationship queries.

Re: Launch HN: Nia (YC S25) – Give better context to coding agents

#12
post #10

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 team…

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.

Re: Launch HN: Nia (YC S25) – Give better context to coding agents

#15
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

Re: Launch HN: Nia (YC S25) – Give better context to coding agents

#16

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

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

Re: Launch HN: Nia (YC S25) – Give better context to coding agents

#20
post #4

Absolutely insane that we celebrated coding agents getting rid of RAG, only with the next innovation being RAG

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".
Post reply on HN