> Maintain an LLM-friendly list of errors that LLMs commonly make when using your thing. For example, in Next.js the `headers` function, as of recently, returns a Promise (it used to return headers directly), and therefore you now have to `await` it, and it's extremely common for LLMs to not include an `await`, which prevents your app from working, and you have to waste time fixing this. It would be really good if Next.js provided an LLM-friendly list of common errors like this one, and there are many others.
My team is actually working on a total revamp of our errors for AI driven debugging. Will write a blog post when its landed more thoroughly, but the current thing we're working on is:
1. Replace our error codes on individual routes with a global list of errors, so every error on every route maps to a global id of this-route-this-error. When you receive one you get not only the id but a link to (2)
2. Generate docs pages for every single one of these errors that note where they come from, metadata, over time we also want to add notes to all these pages about what these errors are, how people have triggered them in the past and how people have solved them.
3. Create what we are currently calling a "DevOps MCP" for our cloud. This MCP is not like a full control MCP, its almost completely read only, and its for pulling logs and seeing whats going on. The usecase is primarily — AI knows API request failed, AI looks at recent API requests, finds the failed one, can then pull the error code, then pull the docs to solve it, then solve it.
We're not sure exactly how this system will/should look and atm we're working on #1 of these 3.
I'm bearing on the concept of an llm-errors-full.txt for these, as I worry it would create the same effect as a `cat-facts.txt` in practice — by being hyper aware of all the errors it would fixate on them and write code in ways to solve errors it never had. I think it would work much better as an MCP, or a list of codes that it debugs when they come up.
> I think this is definitely relevant at early stages, and for as long as LLMs don't have your APIs in their own knowledge (you can look for "knowledge cut-off" date in model descriptions). I would go as far as saying that this is very important because if you don't have this, and LLMs don't have your APIs in their own knowledge, it will be a pain to use your library/SDK/whatever when coding with LLMs.
I've been thinking a lot about the future of SDKs recently and I'm not sure where they go now. Notably, if AI thrives in consistency, then a lot of object models that my favorite SDKs do don't make sense anymore. Rather a more standardized interface for everything makes more sense because the AI could understand it better.
As noted in the post, I've tried (and failed) repeatedly to generate good SDK docs, and I'm not clear what the right solution for the future of SDKs is. I believe it needs more code generation, as my dream SDK docs for AI would include flattened type definitions for all the inputs with every single method, and I'm not sure exactly how to achieve that today.
Thoughts?
> 1. Replace our error codes on individual routes with a global list of errors, so every error on every route maps to a global id of this-route-this-error. When you receive one you get not only the id but a link to (2)
> 2. Generate docs pages for every single one of these errors that note where they come from, metadata, over time we also want to add notes to all these pages about what these errors are, how people have triggered them in the past and how people have solved them.
I don't like having LLMs follow links because that adds costs and latency. Imagine your conversation is already a few hundred thousand tokens, and, let's say, some error occurred, so you enter the error with an ID and a link to the generated docs into the chat. Now, something that needs to be noted is that the LLM may decide to not even open the link, it may decide to try and fix the error on its own, so it may need to be encouraged to open your links. Let's say the LLM did decide to open the link and made a corresponding tool call. At that point, you already spent a few hundred thousand tokens and a few seconds, just for the LLM to make the decision to read the docs. I think this can be optimized by inlining the docs into the response (use XML).
> 3. Create what we are currently calling a "DevOps MCP" for our cloud. This MCP is not like a full control MCP, its almost completely read only, and its for pulling logs and seeing whats going on. The usecase is primarily — AI knows API request failed, AI looks at recent API requests, finds the failed one, can then pull the error code, then pull the docs to solve it, then solve it.
I love this idea. Any time something goes wrong, the user, without the need to look through logs, can just ask the LLM to use the dev MCP server to find the error. I imagine this would greatly reduce the mental burden when encountering errors. But once again, I think there should be as much inlining as possible because indirections are expensive.
> As noted in the post, I've tried (and failed) repeatedly to generate good SDK docs, and I'm not clear what the right solution for the future of SDKs is. I believe it needs more code generation, as my dream SDK docs for AI would include flattened type definitions for all the inputs with every single method, and I'm not sure exactly how to achieve that today.
I ran into the same problem, and yeah, I haven't seen anyone make documentation generators for LLMs yet, so one way to achieve this is to write one yourself, and perhaps open source it. I would look for an existing parser implementation, e.g. if your language has a formatter, I would try and steal from there. If it's TypeScript, I would use swc's crates. Once you have that, collect API function signatures, type definitions, etc, and format as LLM-friendly markdown files.