how do you tell the agent what changed since the last session?
by•
someone on my last thread pointed out the project file says what the project is, but not what changed since yesterday. i don’t have a good answer for that yet.
what do you do, just let it read the git log?
30 views
Replies
Best
Newest entry on top. My LLMPvP roadmap runs in reverse order, so the first thing the agent reads is the last decision made. In a competition repo, the context file gets its own commits and the message is the current state, like "training paused for the reboot". So git log on that one file reads like a changelog.
Report
@wwenioaguiar newest on top, huh. never thought of that, but yeah the agent reads the last decision first and the rest barely matters. does the file get long after a few months or do you trim it?
Report
@kumarr_rittik It gets long. My LLMPvP roadmap is at 170 KB and I never trim it. Old decisions get marked as superseded instead of deleted, so the reasoning behind dropped ideas stays. What keeps it usable is structure: fixed sections like "explicitly deferred", and a tag for "decided but not coded yet". Agents grep for those instead of reading the whole file.
Report
Mostly the git log, and it works because of how the commits are written. Every message says what changed and why in plain words, like "createFunnelCheckout kept warm: a cold session took 7 to 11 s". So the last twenty commits at the start of a session read like a diary of yesterday. Anything that isn't obvious from the message goes into the topic note the moment it's learned, so the agent reads the log for what happened and the notes for why. The project file itself only changes when a rule changes.
Report
@gbasovv ok this is the bit i was missing. i only thought about reading the log, never about how the commits get written. the 7 to 11 s example makes it obvious, the message tells the whole story before you open the diff. gonna steal that style.
Report
@kumarr_rittik glad it helped. One thing that keeps the style consistent: the agent writes the commits itself, and the rule for how a message should read sits in the project file, so every session follows it without me checking. And put the number in the message whenever there is one, like that 7 to 11 s. A month later it's the only thing that tells you whether the fix actually worked.
Replies
Newest entry on top. My LLMPvP roadmap runs in reverse order, so the first thing the agent reads is the last decision made. In a competition repo, the context file gets its own commits and the message is the current state, like "training paused for the reboot". So git log on that one file reads like a changelog.
@wwenioaguiar newest on top, huh. never thought of that, but yeah the agent reads the last decision first and the rest barely matters. does the file get long after a few months or do you trim it?
@kumarr_rittik It gets long. My LLMPvP roadmap is at 170 KB and I never trim it. Old decisions get marked as superseded instead of deleted, so the reasoning behind dropped ideas stays. What keeps it usable is structure: fixed sections like "explicitly deferred", and a tag for "decided but not coded yet". Agents grep for those instead of reading the whole file.
Mostly the git log, and it works because of how the commits are written. Every message says what changed and why in plain words, like "createFunnelCheckout kept warm: a cold session took 7 to 11 s". So the last twenty commits at the start of a session read like a diary of yesterday. Anything that isn't obvious from the message goes into the topic note the moment it's learned, so the agent reads the log for what happened and the notes for why. The project file itself only changes when a rule changes.
@gbasovv ok this is the bit i was missing. i only thought about reading the log, never about how the commits get written. the 7 to 11 s example makes it obvious, the message tells the whole story before you open the diff. gonna steal that style.
@kumarr_rittik glad it helped. One thing that keeps the style consistent: the agent writes the commits itself, and the rule for how a message should read sits in the project file, so every session follows it without me checking. And put the number in the message whenever there is one, like that 7 to 11 s. A month later it's the only thing that tells you whether the fix actually worked.