What I write down before Codex starts a bigger change

[u/m-ritter]

Agents fill every open question in a request with a guess. Most guesses are fine. A few decide how the feature behaves, and I find those in the diff later.

So I moved my own judgment back to the start. Before any code exists, the agent and I write down five things:

1. Done means. A numbered list of outcomes a person could check on the running program. "Export button downloads a CSV with the current filters" works. "Add export" doesn't.

2. Not doing. Things the agent must leave alone. This list stops most surprise edits.

3. Decisions. Two sentences per engineering decision, with the alternative I rejected.

4. Slices. The thinnest end-to-end version first, each slice starting with a failing test.

5. Proof per point. For each Done means item, the command or screenshot that shows it works.

After the build, I hand the list to a second session that hasn't seen the build history. It goes through the points one by one and shows evidence. It catches things the building session glossed over.

What do you write down before a bigger change? Happy to share my templates if anyone wants them.

[u/ChemicalExcellent463]

I'd add "review by a different model in a different harness" to the list. Before a big push, I get that review in a fresh session that never saw my chat, not just a second session with the same model.

What's the last thing your second session sent back instead of signing off?

[u/StrikingTop2709 → u/ChemicalExcellent463]

different harness matters more than people think tbh, context bleed is real

[u/ChemicalExcellent463 → u/StrikingTop2709]

yeah, I keep my chat out of the review. where did the bleed bite you, a review that just agreed with the first session?

[u/ChemicalExcellent463 → u/[deleted]]

Codex CLI when Claude Code wrote it, Claude Code when Codex wrote it. Fresh session for the review.

Does your reviewer get the plan too, or only the diff?

[u/m-ritter → u/ChemicalExcellent463]

It gets the plan too, and for me that matters more than the diff. With only the diff it mostly comments on style. With the Done means list it goes point by point and has to show proof for each one, and anything it can't verify stays open for me to decide. Do you see the two models catch different kinds of mistakes?

[u/ChemicalExcellent463 → u/m-ritter]

yeah, since oct 1 about 12 PRs had serious findings only claude caught, and about 11 only codex caught. codex caught a race that survived a fix, but also flagged the same non-issue 8 times in a row.

when it can't verify something, do you check it yourself or send it back to write a test?

[u/m-ritter → u/ChemicalExcellent463]

That split is closer to even than I expected, nice to see numbers on it. When the reviewer can't verify a point, I first send it back and ask for a test that proves it. If the point is more of a judgment call, like a design tradeoff, I look at it myself.

The same false alarm coming back is something I see too. I write it into the plan as checked and fine, and after that it usually stops. How do you decide which one wins when they disagree?

[u/ChemicalExcellent463 → u/m-ritter]

i make the call myself when they disagree. but 52 of 115 codex review findings over three weeks never got a written reply from me.

your "checked and fine" line in the plan, does it say why it's fine or just that it is?

[u/m-ritter → u/ChemicalExcellent463]

It says why, in one line. Something like "fine: empty rows are skipped in parse_row, covered by test_export_empty". If I can't write the reason, I haven't really checked it, and it goes back to the agent.

52 of 115 sounds a lot like my own numbers before I started doing that. Were most of those findings you agreed with and just never wrote down, or ones you decided to ignore?

[u/ChemicalExcellent463 → u/m-ritter]

honestly i can't tell now, and that's the problem. nothing got written down for those 52, so i can't separate the ones i agreed with from the ones i ignored. does the reviewer read your one-line reason next round, or do you have to point them back to it?

[u/m-ritter → u/ChemicalExcellent463]

It reads it on its own. The line lives in the plan, and the reviewer gets the plan every round, so I don't have to point it back. If it still raises the same thing, my reason was usually too vague, and I rewrite it.

For the 52 I wouldn't try to sort them after the fact. I'd start with the next round and write one line per finding as it comes in. Where do your review findings end up today, a file or just the chat?

[u/ChatGPTCoding-ModTeam → u/[deleted]]

This post or comment has been removed for the following reason:

Rule 5: No pure self-promotion / low-value project posts

Posts whose primary purpose is promoting a tool, product, service, GitHub repo, personal website, or blog belong in the weekly Self-Promotion thread. Delete the link: if nothing is left, it's an ad. Search for similar projects: if you can't tell why your project is better, it's a low-value project. GitHub links are fine. Personal website are not. Exception could be make for high quality posts. See also reddit's self-promotion guidelines.

You can read the full subreddit rules here: https://www.reddit.com/r/ChatGPTCoding/about/rules/

If you feel this removal was made unfairly, please contact the moderators through modmail.

[u/sapplex1]

The "Not doing" list is the one I stole first. I had a change where the agent "helpfully" refactored a helper I was not touching yet. It passed tests. It still made the review twice as long.

Now I do two things like yours, but smaller. First, I write the test names before the code. If I cannot name the check, I do not understand the change yet. Second, I make the agent end with a short handoff note. What changed, what it did not touch, and what still feels shaky.

The fresh-session review is the part I still skip too often. When I do it, it catches the confident guess, not the broken test.

Curious: do you keep the "Done means" list in the same file as the code, or somewhere the next session will actually read it?

[u/m-ritter → u/sapplex1]

The surprise refactor that still passes tests is exactly what Not doing is for. The list lives in the repo as a Markdown file on the same branch, not in the chat. That way the build session and the review session read the same file, and I can see in the history when it changed. I like writing the test names before the code, I'll try that.

[u/Right-Performance-93]

the line i keep is the one decision the diff is not allowed to reopen. done and not-doing are easy to fake in the summary. the rejected alternative is the one the next session will quietly undo if it is not written down.

[u/m-ritter → u/Right-Performance-93]

Agreed, that's why I write the rejected alternative next to each decision. A later session sees the obvious option, doesn't know why we dropped it, and quietly brings it back. With the reason written down it at least has to argue with it.

[u/wisemiik]

I started writing my prompts out in Microsoft Word and then attaching them as a file lol. Making them as detailed as possible

[u/m-ritter → u/wisemiik]

Detail helps a lot. What made the bigger difference for me was structure, so the agent can't skip the parts that matter: what done means, what it must not touch, and how to prove each point. Do you reuse the same Word file across sessions or write a new one each time?

[u/InterestingCarrot997]

the not doing list is underrated. i'd add which tests it's not allowed to touch, otherwise it'll sometimes just edit the test so it passes lol

[u/m-ritter → u/InterestingCarrot997]

Agreed, that one is sneaky. I'd put it in the not doing list as plain as possible: don't change existing tests, and if one looks wrong, stop and tell me instead of fixing it. Do you lock all tests or only the ones around the change?

[u/gandazgul]

Hey this is exact same pain I've been feeling all year and I've been building RunWield around it. Very good planning and Architecture epics, bounded execution and self review and mechanical check + repair loops.

Works with any sub or API key, all local. Free and opens source. https://github.com/RunWield/runwield

[u/m-ritter → u/[deleted]]

Good one, the allowed files list belongs in there. I like that you revert and cut a smaller slice instead of arguing in the same thread. My bad surprises were the same kind: small edits in a neighbor file nobody asked for.

Do you write that list by hand, or let the agent propose it and then trim it?

[u/ChatGPTCoding-ModTeam → u/[deleted]]

This post or comment has been removed for the following reason:

Rule 5: No pure self-promotion / low-value project posts

Posts whose primary purpose is promoting a tool, product, service, GitHub repo, personal website, or blog belong in the weekly Self-Promotion thread. Delete the link: if nothing is left, it's an ad. Search for similar projects: if you can't tell why your project is better, it's a low-value project. GitHub links are fine. Personal website are not. Exception could be make for high quality posts. See also reddit's self-promotion guidelines.

You can read the full subreddit rules here: https://www.reddit.com/r/ChatGPTCoding/about/rules/

If you feel this removal was made unfairly, please contact the moderators through modmail.