(no title)
generallyjosh | 1 day ago
These things are built for pattern matching, and if you keep their context focused on one pattern, they'll perform much better
You want to avoid dumping in a bunch of data (like a year's worth of git logs) and telling it to sort out what's relevant itself
Better to have pre-processing steps, that find (and maybe summarize) what's relevant, then only bring that into context
You can do that by running your git history through a cheap model, and asking it to extract the relevant bits for the current change. But, that can be overkill and error prone, compared to just maintaining markdown files as you make changes
just6979|15 hours ago
So instead you give it a years worth of changelog.md?
"Better to have pre-processing steps, that find (and maybe summarize) what's relevant, then only bring that into context"
So, not a list of commits that touched the relevant files or are associated with relevant issues? That kind of "preprocessing" doesn't count?
"You can do that by running your git history through a cheap model, and asking it to extract the relevant bits for the current change. But, that can be overkill and error prone, compared to just maintaining markdown files as you make changes"
And somehow extracting the same data out of a [relatively] unstructured and context-free (the changelog only has dates and description, that will need to be correlated to actual changes with git anyway...) markdown file is magically less error-prone?
generallyjosh|6 hours ago
And no, I wouldn't ever give it a year of changelog.md. I give it a short description of the current functionality, and a well-trimmed list of 'lessons-learned' (specific pitfalls/traps from previous work, so the AI doesn't have to repeat them)
If you think git logs are a good way to give context, try it and and see how it works! My instinct's that it won't work as well as a short readme, but I could be wrong. It's so easy to prototype these days, no reason to not give it a shot