Een van de interessantste workflowpatronen die ik met Codex Plus heb opgemerkt, heeft minder te maken met hoe ik prompts formuleer en meer met wanneer ik ze inzet.
Als ik nog maar de laatste 3–5% van mijn 5-uurs- of wekelijkse limiet over heb, besteed ik dat restant niet meer aan kleine verzoeken. Ik doe juist het tegenovergestelde. Ik gebruik die laatste capaciteit om de grootste engineeringtaken te starten die ik over meerdere vooraf voorbereide projecten kan uitrollen.
Dat betekent meestal werk zoals volledige TypeScript-migraties, repositorybrede ESLint-opruiming, diepe bugreviews over complete codebases of grote refactors die normaal te duur voelen om zomaar aan te slingeren.
Wat mijn workflow veranderde
De reden is simpel: meer dan eens heb ik gezien dat Codex bleef doorwerken terwijl de zichtbare limiet al opgebruikt leek. Van buitenaf lijkt de sessie dan voorbij, maar de taak gaat door en wordt soms zelfs helemaal afgerond.
Ik presenteer dat niet als een gegarandeerde productregel. Ik beschrijf alleen een terugkerende ervaring die genoeg indruk maakte om mijn gedrag te veranderen. Sinds ik dat patroon zag, voelt die laatste paar procent niet meer als iets wat ik voorzichtig moet bewaren. Het voelt juist als het beste moment om het duurste en meest impactvolle werk te starten.
Hoe ik die laatste procenten nu gebruik
In plaats van de laatste ruimte te besteden aan veilige, goedkope prompts, behandel ik die nu als een lanceermoment voor zwaar engineeringwerk, zoals:
- volledige TypeScript-migraties
- repositorybrede ESLint-opruiming
- diepe bugreviews in grote codebases
- grootschalige structurele refactors
De sleutel is voorbereiding. Deze aanpak is vooral nuttig als het project al klaarstaat voor uitvoering en de taak helder is afgebakend. Op dat moment voelt het vaak als verspilling om de resterende ruimte aan iets kleins uit te geven.
Waarom dit belangrijk voelt
Tools zoals Codex Plus draaien niet alleen om ruwe capaciteit. Het gaat er ook om hoe je inspanning in de tijd plant. Een kleine verschuiving in timing kan de praktische waarde die je uit dezelfde limiet haalt flink veranderen.
Voor mij heeft dat zelfs de psychologie van het product veranderd. Die laatste paar procent voelen niet meer als het einde van een sessie. Ze voelen als het moment waarop ik moet stoppen met twijfelen en het zwaarste werk moet overdragen dat nog logisch is om te starten.
Soms voelt het eerlijk gezegd alsof Codex zelfs blijft doorwerken nadat de zichtbare limiet al verdwenen is. Of dat een bewust randgeval is of gewoon de manier waarop sommige taken in de praktijk afronden, weet ik niet. Maar het was nuttig genoeg om mijn workflow er inmiddels op in te richten.
Een praktische les voor ontwikkelaars
Als je Codex Plus gebruikt voor softwareontwikkeling, kan het de moeite waard zijn om je eigen end-of-limit-workflow te testen in plaats van automatisch aan te nemen dat die laatste paar procent zo voorzichtig mogelijk moeten worden gebruikt. In mijn geval werkte de omgekeerde aanpak beter.
Ik ben erg benieuwd of andere ontwikkelaars hetzelfde patroon hebben gezien, vooral bij migraties, lint-opruiming, grote reviews of brede refactors over meerdere repositories.