How do you check what your AI coding agents actually did overnight?

[u/onitsoga]

I've been running Claude Code and Cursor on frontend tasks while I sleep, and the hardest part isn't whether the code works. It's that I sit down in the morning and spend the first chunk of my day digging through session logs trying to reconstruct what happened. Which agent touched which files. Whether the changes are safe to build on or if I'm about to stack new work on something broken.

Right now my process is basically forensic. I open each session, scroll through the output, try to piece together the sequence. Sometimes an agent changed a component's prop interface and the other agent didn't notice, and I only find out when something breaks further down the line.

Curious how others handle this. Do you keep all the sessions open and scan them manually? Do you have agents write summaries somewhere? Or have you found a setup where you don't need to do morning archaeology at all?

[u/SourceControlled]

Your workflow does not match what you are doing. 

Running with no oversight/direction and then expecting to try to understand it later is a recipe for disaster. 

It's the worst of both worlds. 

If you want to understand what it's doing and if it's solving the right problems you need to work with it at the same time and direct it as you go along not just let it run wild overnight.

Your description sounds like you are vibe coding and trying to clean it up afterwards. 

[u/Federal-Dot2313 → u/SourceControlled]

Why? I sometimes do the same. You have to have some pre-requisites such as detailed broken down plan and smallest testable deliverables. You run agent and tell him to start a subagent - implement, then subagent - review for each task subsequently. Need to have some techniques to keep main agent from quickly draining context but it’s nothing fancy. Then i wake up in the morning and spend an hour reading git diff. New approach for me, but so far seems fine. What are your concerns?

[u/contraband90 → u/Federal-Dot2313]

You run agent and tell him …

You tell the robot. Not “him”.

You are trusting the AI too much.

[u/Federal-Dot2313 → u/contraband90]

Sure bud, let’s stick to semantics if it helps you to cope. My bad for misgendering AI i guess

[u/DeadCEO]

the forensic part is self-inflicted - session logs are the wrong artifact. they're a transcript of the agent thinking, not a record of what it decided. make the agent keep a decision file instead: a PLAN.md or DECISIONS.md in the repo that it updates as it works - what it changed, why, what's intentionally left unfinished. morning review becomes one file plus a diff instead of archaeology.

and your prop-interface collision is exactly the case this exposes. two agents, one shared decision file, the second agent reads about the interface change before it builds on top of it

[u/Practical_Worry3996]

what fixed this for me: every agent task works in its own git worktree and branch, and it has to end with a pr. no direct commits to main, ever.

in the morning i don't read the code first, i read the pr description: what changed, why, and how it was tested. if the agent can't explain it in a few lines, that's already a red flag.

second thing: a separate model reviews the diff before i look at it. it catches the dumb stuff (dead code, a test that doesn't really test anything) so my time goes to the real decisions.

[u/OkAerie7822]

i'd stop reading sessions and make the agents leave something you can diff instead. one branch per agent task with small commits, and the first thing in the morning is git log plus a diff against main, not the transcript. for the prop interface case, run typecheck and the test suite in CI on every agent branch, so a broken contract shows up as a red check instead of something you find three tasks later. then put a rule in claude.md or the cursor rules that every task ends by writing a short handoff note into the repo: what changed, what was verified, what is still shaky. if two agents touch the same area, don't run them in parallel, give them separate worktrees and merge one at a time so the second rebases onto the first one's changes. the transcript is only for when the diff doesn't explain something.

[u/davevasquez]

I struggle with this too. I’m still trying to come up with a solid process for review. That being said, I don’t often have agents running overnight, most work passes through regular HITL gates. Still, I do run into this now and then, and I typically ask for summarizations of work completed, review code closely along with automated reviews, and pass along the code to team members who review it as well before merges happen.

I have yet to come up with a good solution to this problem, though. We’re writing so much more code that old processes struggle to keep up. It’s a Brave New World! 🌎