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

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 source...