I love this idea. In the past I stored our coding style guidelines and philosophy in our wiki. Putting it into git brings it closer to where it is used. Also, it makes it more easily accessible to AI tools, which is an added bonus.

AFAIK that kind of separation is a longstanding criticism of git by fossil devs.

Interesting idea. I have been using a SPECIFICATION.md and TODO.md to keep my models on track. What kind of stuff do you put in LESSONS.md that can't just live in the system prompting?

Nothing, that's roughly the same idea I think. it's just when I'm using Aider I don't really have a good way to feed a system prompt in, so I just put REPOPROMPT.md in the root folder.

TODO.md and FEATURE_TODO.md are also very valuable for keeping on track.

> with approximate knowledge of every API and style on the internet

Like economists, who have predicted 7 of the last 3 recessions, AI knows 17 out of 11 API calls!

In my experience, if I'm looking how to do something pretty standard with an API I'm unfamiliar with, it's usually correct and faster than trying to trawl through bad, build-generated documentation that would rather explain every possible argument than show a basic example.

And in the case it's wrong, I will know pretty quickly and can fall back to the old methods.

A tool that gives me 17 out of 11 API calls from a vague textual description of my intent would be incredibly useful.

> Like economists, who have predicted 7 of the last 3 recessions, AI knows 17 out of 11 API calls!

It's definitely been said before, but the fact that they're calling out these non-existent functions in the first place can tell library devs a lot about what new features could be there to take up the namespace.

But also willing to make up nonexistent features or uses of said APIs.