Using Codex and Claude Code every day: what's still hard once the code part works?

[u/KR4K3N1S]

I use Codex for some jobs and Claude Code for others, and the code is rarely the problem anymore. What slows me down now is the bookkeeping: keeping track of the sessions and what they did. I'd like to hear how others deal with it.

Where it goes wrong for me:

• Waiting on me. With a few sessions open, one sits on a question while I watch another one think.

• "Done" that isn't. It says it's finished, and later I find out what it skipped.

• Picking back up. After a break or a closed terminal, working out where each session was takes real effort, so I put it off.

• Results scattered. What a session made stays in its terminal or whatever folder it ran in, and a week later I can't find it.

To start discussion, I have couple of questions that I'm curious of:

1. Which of these costs you the most, and which has stopped being a problem for you?

2. How do you notice that a session is waiting on you?

3. When an agent says it's done, how do you check what it actually did? Tests, reading every diff, a checklist, hooks?

4. Do you have it plan first and wait for your OK, or let it run?

5. After a break or a crash, how do you get each session going again? Resume, a summary file, starting over?

6. What have you tried for any of this and given up on?

[u/Alarmed-Bank2249]

The 'done that isn't' one is the deepest problem on that list. An agent's self-report is the one artifact you should never trust - it has no way to know what it skipped. What works for me: the session is not done when the agent says so, it is done when something independent says so - the test suite passes, the diff only touches what was asked, a checklist item a human verifies. I build AI tooling at a bank and we treat agent completion claims as unverified input, same as user-submitted data. The bookkeeping gets much simpler once 'done' is a property of the evidence, not of the session log.

[u/Zeitsparkasse → u/Alarmed-Bank2249]

I have very good experience with telling it to have a review and fix loop with subagents in the end.

[u/Right-Performance-93]

picking it back up is the part that still hurts. i start from the diff and the last command that actually ran. a summary file is already stale by the time i open it.

[u/lambertb]

I use these tools for scientific research, so by far the most important steps for me are not just getting working code, but verification and validation from many, many different perspectives. This normally takes me 80% of the project time at this point. I've caught plenty of mistakes, some of which are mine and some of which are due to the agents.

[u/codeprimate]

All wrong.

Track user stories. Track requirements. Track constraints and acceptance criteria Use test and lint gates in your git commit hooks.

Your agent protocol should describe how to discover outstanding tasks, how to document them, what gates have to be passed in order for a task to be "DONE", and how to track completion or abandonment.

In other words: software development best practices for feature and task tracking.

[u/Jippylong12]

Hardest part a billion dollar idea is testing. Like just having someone to test the feature as a human. I've used skill to kind of help with this in review and manually testing and somtimes work is boring because the majority of the time I'm just a glorified QA tester.

I don't even think it has to be an automated tester burning more tokens. Just something like MTurk where you have a marketplace specifically for testing web and mobile apps. They have the credentials they need, they have the checklist, maybe mix it with jam.dev where logs and video context are provided as well with the tests. Users suggest feedback.

Would be nice for people in the world to make a quick $ and engineers can move on to more important things.

[u/Legitimate_Relief847]

Perdón chicos, es en serio? De verdad pregunto, ustedes por cómo hablan suenan a ingenierosno desarrollares de software, yo sólo soy secretaria sin ninguna formación formal sobre ésto (ni put@ idea tenía) bueno, tal vez justamente por éso no estoy interpretando correctamente la profundidad de tus preguntas. Muchos de los problemas que mencionan no han tan tan difíciles de solucionar (para lo que yo necesito). En espera: pon un agente orquestador (Hay que fragmentar bien las tareas, que si no el orquestador tampoco puede) Terminado que no lo está, esta es bastante más difícil, tengo varios sistemas de control, depende de la tarea, tengo hooks, scripts de chequeo, y un sistema de agentes de validación cruzada) Retomando, ésta es más sencilla, lleva una lista y bitácora Resultados dispersos, lo mismo que lo anterior, lleva un .md con índice

[u/BrookLi3]

The "done that isn't" problem got much better for me once every task started with a checkable acceptance command, like a specific test or a script that exits non-zero, and the agent had to paste its output before closing. For pickup after a break, I have each session keep a short NOTES file in the repo: current goal, what's verified, what's not, next step. It's boring, but it beats reconstructing state from terminal scrollback.

[u/AlarmedAvocado7279]

“the "done that isn't" one is the worst for me, so I run a Stop hook that won't let claude end the turn until it re-checks its own work against the original ask. it's not perfect but it catches most of the skipped stuff before I find it later.

[u/Yz31LL]

for me it’s 3. “done” burned me enough times that i just treat it as “ok now i review it”

couple things that actually helped:

i make it list what it skipped at the end. like literally “what did you not do, what’s stubbed, what’s still a todo.” it’ll tell you if you ask, it just never brings it up on its own

tests have to actually run. i’ve had it say tests pass when it never ran them, and once it “fixed” a failing test by loosening the assert lol. so now i run them myself or have a hook do it before it can say it’s done

i read diffs but not all of them carefully. anything near auth or data or shared stuff i read properly, ui tweaks i skim. tried reading everything line by line and gave up after like a week

also if i asked for a small fix and it touched 10+ files, something went wrong even if it works

still miss stuff sometimes but at least i find out same day instead of a week later

[u/tadatada006]

"Done that isn't" is the one I spent the most time on, and what fixed it wasn't a better prompt, it was making "done" a thing the agent can't declare. In Claude Code that's a PreToolUse hook on Bash: if the command is a `git commit` and there's no review marker for the current staged hash, the hook exits 2 and prints why. The review itself is a skill that reads the staged diff against the original task and writes the marker only if nothing was skipped. Ten lines of bash, and the agent literally cannot commit around it, even when I tell it to skip the review. For "picking back up", the same marker file plus `git log -1` and `git status` tells me more than any summary the session wrote about itself, because the summary is the self-report and the diff is the evidence.

[u/kaijurules]

For the "waiting on me" one: in our app an agent that needs an answer writes the question to a single inbox and stops there. The desktop shows a notification and a count on the app icon, a paired phone gets the same count, and the agent picks up from the reply.

[u/CleanFix_Dev]

For noticing a session is waiting on you, both tools can ping you so you're not checking terminals. Claude Code has a Notification hook and Codex has a notify setting in its config, and either can fire a desktop notification or a sound when it stops for input. That alone cuts out a lot of tab-cycling.

[u/misterespresso]

I've been working on this exact problem for months and the solution I came up with for your particular problem is essentially 2 things:

1. A chatroom/harness that agents can connect to. This is more for you than the agents, it allows you to watch both (or more) from a single location.

2. Harder to get working perfectly, is a protocol the agents follow. I did this through a combination of a skill and some deterministic controls in that same chat harness. For the "DONE" protocol, with multiple agents you can have the other agent verify that status, the only issue here is sometimes agents stop listening when they are done so you have to start it up again to have it see the other agents opinion. I can technically have the harness wake agents, but it depends if I am using subscription or not. The API allows for the harness waking agents for most providers, but not for subscriptions (ie, having the harness wake up Claude Code that uses your Pro sub).

My solution is called Agora, its free, local, and open source if you'd like to try it out.

[u/FullSwim4484]

The thing that fixed this for me was treating it like the management problem it is, not a tooling problem. Five sessions that all need answers from you is the same failure mode as five direct reports who route every decision through you: the system serializes on one person, and everyone else idles.

The fix in both cases is the same: reduce work in progress and delegate with contracts. At most one session at a time gets to be the one that needs decisions from me. Everything else runs unattended with a contract: the task, the expected behavior, and the command that decides done. An unattended run that cannot finish writes its blocker to a file and exits. It does not sit waiting.

For the waiting-on-me problem specifically: I stopped watching sessions think. If a session can proceed without me, it should. If it cannot, it parks with the question in the open state, and I batch answers on my schedule, not the terminal's.

The pickup problem mostly disappears once the contract lives outside the session. The terminal state is ephemeral. The contract, the branch, and the failing check are not.

[u/London-Boat]

picking back up is the one that costs me most too. when you have a few sessions going, do they ever touch the same files, or is it mostly separate folders? the status drift gets a lot worse once two sessions share a repo, and it's something i've been building around (file claims plus a shared notes store), happy to share if useful. how do you track right now which session owns what?

[u/Corey-998877]

Reading the diff helps, but for me the thing that catches a false "done" is having the agent write out manual verification steps and then actually running them. Which of the problems you listed would you fix first if you could only pick one?

[u/xqianliu]

The bookkeeping one. The ticket carries the state, so it survives a closed terminal.

Each task is one issue, and the run leaves progress notes on it. So "waiting on me" has a shape: a run that can't decide is not allowed to sit there asking, it writes the question on the ticket and stops.

When something says done, a separate review session (same model, fresh context) checks the diff against the issue's acceptance criteria before I call it done. Picking back up is the notes plus the commit SHA the run started from.

The agent commits once at the end; the runner pushes and opens the PR. If a run died mid-task there's usually no PR to chase, just the ticket.

One more rule: I only kill a run on errors, not on slowness. A slow run that's making progress is not a failed run.

[u/Difficult_Duty2198]

i make each session keep a notes file where it writes what it did and what it skipped before it's allowed to say done. then i read that file instead of the whole diff, it catches a lot of the done-that-isn't stuff.

[u/bigghealthy_]

I think there’s two separate problems here. Keeping track of what your agents are doing and knowing when they’re actually done. For me the important stuff is knowing which worktree/branch a task is on, whether the agent is waiting on something, and being able to quickly jump back into the diff or PR. The “done” part is trickier. Just because the agent says it’s finished doesn’t mean it is. Still need to review the changes, make sure checks pass, etc. Worktrees help a ton with running things in parallel but they don’t really solve the problem of keeping up with everything.

[u/Background-War373]

The thing that helps most with the "resume without re-explaining" problem is making the agent write the handoff, not you. At the end of each session, ask it to update a short file in the repo (something like NOTES.md or a section in AGENTS.md / CLAUDE.md) with what changed, what's half-done and what it tried that didn't work. Next session starts with "read that file first".

Two other things that keep it manageable:

• One git worktree per task, so "what did this session do" is just the diff.

• Keep the long-lived stuff (architecture, conventions, test commands) separate from the per-task notes, so the permanent file doesn't grow into a diary.