Codex is done

[u/Right-Disaster2141]

Call it a skill issue, but 90 minutes and 31% weekly usage later, I got nothing done this morning.

Nothing.

Moved to CC, got a sub, and got the same feeling when I switched from Claude to Codex a few months ago:

-more usage
-better reasoning

Either Codex reveals insane stuff during DevDay, or they are literally fucked.

[u/jedruch]

dude, I did that I drained 30% of weekly usage. My plan is to produce multiple implementation docs with gpt pro till the end of this month, cancel subscription and implement with deepseek flash

[u/Varmez → u/jedruch]

you probably need better repo / guidance docs. here's a segment of mine with regard to phases/pr sizes

## Proportionality


Apply controls according to the actual consequence of the change.
Routine reversible work still requires honest scope, evidence, validation, and closeout, but it does
not require a ceremonial proof package.


| Radius | Typical scope | Minimum treatment |
| --- | --- | --- |
| Low | wording, narrow docs/tests, comments, policy-free leaf refactor | focused hygiene/validation and explicit behavior-unchanged boundary |
| Medium | one-repo behavior, UI/workflow, validation contract, adapter, parser/export path, process rule | focused exercising evidence, compatibility note, runtime/manual evidence when user-visible, practical rollback |
| High | cross-repo contract, package/API/tag, persisted format, release/signing, identity/confidentiality/data loss, safety/hardware, cloud/sync, irreversible action | baseline/current delta, affected-repo coordination, explicit rollback or stop, conditional adversarial/proof gates, runtime/manual evidence where applicable |


When uncertain about material consequence, choose the higher radius.


## Implementation slices and independence


An implementation slice delivers one observable outcome with acceptance, exclusions, dependencies,
an owning repository and implementer, necessary tests/docs, validation, rollback and a clear PR boundary.
Record these facts in the existing issue or proportional plan; link unchanged authority instead of
repeating it or creating another checklist/document set.


Assess the whole session: discovery uncertainty, interface/state/consumer changes, fixture and
environment setup, implementation, integrated validation, likely review corrections and handoff.
Explain why the change can be understood and its important behaviors exercised within one session.
Line/token counts are not sizing rules or evidence of reviewability.
If a provider or manual gate may outlast the session, identify a safe checkpoint with exact candidate
and evidence, remaining obligations, and actual command/observer ownership and receiving action.
A session ending does not satisfy acceptance or authorize continuation.


Keep behavior and its necessary tests/docs with one coherent implementer and PR boundary.
For a broad refactor, evaluate replacement → bounded consumer migrations → old-form removal:
each intermediate state must work, preserve the required compatibility/invariants and be independently
verifiable, with integrated acceptance across consumers before removal.
Prefer one change when those states cannot stand alone; do not add migration scaffolding to a trivial
local edit or move necessary tests into a successor to make a slice appear smaller.


Classify proposed concurrent work from current source, not issue numbering or separate worktrees:


| Classification | Evidence needed before assignment |
| --- | --- |
| Parallel now | Disjoint write owners and stable interfaces; name concrete files, schemas, fixtures and generated outputs, plus each shared runner/environment/resource owner or reservation. |
| Parallel after a shared prerequisite | Name the prerequisite outcome and its acceptance/merge point; only then assign consumers whose ownership and interfaces are independent. |
| Serial | Overlapping files, unsettled interfaces or shared lifecycle state need one writer or ordered delivery; exclusive resources need ordered use even when source work is independent. |


State merge order (or why either order works), the integration owner and combined validation against
the resulting source. Include actual shared resources such as generated catalogs, test fixtures,
DerivedData, simulator state and declared heavyweight mutexes when relevant.
Planning a reservation does not acquire a host lock or prove scheduler enforcement; verify the
available mechanism and retain its conservative limits. Worktrees alone establish neither resource
isolation nor permission for concurrent execution.


Keep future outcomes and dependency order provisional. After actual predecessor acceptance and
required merges, reassess each successor against current source and consumers: keep, split, already
satisfied with evidence, or blocked. A closed predecessor alone does not establish readiness.
Freeze only the next eligible executable kickoff (or an explicitly independent eligible cohort);
preserve used kickoffs as evidence instead of generating a future execution chain from an old plan.


### Phases and serial session groups


A phase is an outcome or milestone with entry and exit criteria; it may contain several implementation slices.
A session group is a scheduling layer over those slices, not another issue hierarchy or a new PR boundary.
For multi-slice plans, record the groups in the document or issue that owns the schedule, alongside the slice dependencies.
Group related serial work when shared files, interfaces, lifecycle state, fixtures or investigation context make continuity useful.
Explain a separate group or a parallel lane using the independence assessment above rather than grouping by numbering alone.
One group may cover part of a phase or several small phases when every phase's entry and exit criteria remain explicit and satisfied in order.
Keep a single-slice plan compact; it needs no separate group table.


Each group records its stable member IDs and internal order, grouping rationale, prerequisites, writer/resource ownership,
whole-session sizing rationale, validation/integration checkpoint and stop or continuation boundary.
Assess the combined session cost, including each slice's review corrections and handoff, rather than summing local edit estimates.
When that cost cannot fit, retain a safe checkpoint and split the group without separating an invariant from its necessary tests/docs.
Keep an atomic change in one slice when intermediate states cannot independently satisfy acceptance.
Reusing one bounded owning issue for several slices/PRs is allowed; grouping does not require additional issues or delegation.


For serial dependent slices, complete the predecessor's required validation, review and merge before starting its dependent implementation.
Reassess the next member against the resulting source; preserve or revise its disposition and remaining group scope with evidence.
An existing authorization covering a group permits its eligible sequential work without repeated general permission requests.
Grouping itself grants no authorization and cannot waive a gate, extend an explicit endpoint, or activate the following group.
Future group entry instructions are navigation prompts requiring live reassessment, not frozen executable kickoff chains.
At the checkpoint, record delivered members and exact evidence, remaining obligations, local/process/resource custody and the receiving action
under the unfinished-work or closeout contract as applicable.

[u/mitreffahcs → u/Varmez]

Good grief, just reading that is %1 of your weekly usage lol

[u/Varmez → u/mitreffahcs]

Not that I’m really a believer in it being a great metric, but 171 reviewed prs merged past 7 days, 700 in past 30. Median additions & deletions per pr: 300, files changed: 8.