| author | Alan Dipert
<alan@tailrecursion.com> 2025-12-28 02:39:48 UTC |
| committer | Alan Dipert
<alan@tailrecursion.com> 2025-12-28 02:39:48 UTC |
| parent | 33f0c82f214f1e8294c6a7240101135eb087c3fe |
| md/Coherence.md | +1 | -1 |
diff --git a/md/Coherence.md b/md/Coherence.md index abd2e12..887f14b 100644 --- a/md/Coherence.md +++ b/md/Coherence.md @@ -22,7 +22,7 @@ The biggest gains come from **non-code artifacts** that lock intent in place bef Codex needs the same feedback loop I have. If I’m building a site, it should see the browser. If I’m building a CLI, it should run in a close match of the target environment. If I’m stuck manually validating everything, I’ve kept myself in the loop and throttled iteration. -I also send Codex through the site as a new reader to collect rough edges and TODOs—confusing flows, broken links, odd formatting—before touching content. That keeps its work queue self-filling instead of relying on my memory. +Let Codex exercise the work and fill its own backlog: browse the site like a new reader, run the CLI in a staged environment, and capture TODOs for confusing flows or visual glitches without waiting on me to spot them. Commits record outcomes, not dead ends. I start and end work by logging an issue in `git-bug` (or similar) so failed approaches and constraints live beside the code. Without that memory, Codex will “fix” problems by creating new ones forever.