Protect your LLM's context window by using documents

Continuing on with my recent ramblings on protecting your context window: Imagine you had to create a client to access an API where the only documentation is the code. One way you could try and do this is just to tell your coding agent where the API repository is, and then just ask it to create a client. However, this might cause your context window to fill up:

1. First it needs to investigate the API repository to get the API shape and work out what it does.
2. Then it needs to investigate the client repository in order to work out where to put it and what idioms and patterns it should adopt.
3. Then it needs to implement it.

What I have previously done in this situation is to do it in stages:

1. First I ask my coding agent to comprehensively document an API and put its findings in a markdown document.
2. Then in a fresh context window I will ask the coding agent to use the markdown document to create an API client.

You can use the pattern in lots of different ways. The key thing is to break down a task into stages where each stage starts with a fresh context window, and eventually outputs its contribution into a document. This approach plays really well with version control: Each stage can have its own commit - allowing you to easily rewind when things go wrong, and you can use branches to experiment with different solutions.