|
|
|
|
|
|
by linsys
79 days ago
|
|
|
This is what we do for our own internal apps, what we do is actually much more complex we ingest all the docs from Github and Confluence AND we generate code-maps into a RAG then we expose it with an MCP, integrate that MCP into claude code so claude can ask for both our coding standards, IaC standards, testing standards, etc.. but also has the full context about the applications it needs to consume from or deliver to. |
|
|
If we want AI assistants to contribute to a codebase like a productive member of the team, they need the same kind of context you’d give a new hire. Coding standards, infra conventions, testing patterns, and the shape of the system all matter.
We’re focused on a narrower version of that same problem.
First, we want to make it simple for any team to adopt a new library or SDK without reading a pile of docs or spending hours writing and debugging integration code. The goal is to make it easy for an agentic coding workflow to absorb a new API library quickly and use it correctly.
Second, a lot of teams are already maintaining their own AI context across AGENTS.md files, skills, and MCP servers. That means API providers, and really maintainers of any library at this point, need to provide a context layer that fits into what teams have already built. Adding a new dependency shouldn’t force every team to create and maintain a separate context layer just to consume that API well.
That’s the part we care about a lot: SDK context should be generated and maintained automatically, stay in sync with the SDK and docs, and avoid becoming extra work for either the API provider or the API consumer.