Eines der interessantesten Codex-Plus-Muster, die ich beobachtet habe, hat weniger mit Prompting zu tun als mit Timing.
Wenn ich bei den letzten 3–5 % meines 5-Stunden- oder Wochenlimits angekommen bin, nutze ich diesen Rest nicht mehr für kleine Anfragen. Ich mache genau das Gegenteil. Ich verwende die verbleibende Kapazität, um die größten Engineering-Aufgaben zu starten, die ich über bereits vorbereitete Projekte hinweg auslösen kann.
Dazu gehören bei mir typischerweise vollständige TypeScript-Migrationen, repository-weite ESLint-Bereinigungen, tiefe Bug-Reviews über ganze Codebasen oder große Refactorings, die man normalerweise nicht leichtfertig anstößt.
Was meinen Workflow verändert hat
Der Grund ist simpel: Mehr als einmal habe ich erlebt, dass Codex weiterarbeitet, obwohl das sichtbare Limit bereits erschöpft zu sein scheint. Von außen wirkt es so, als müsste die Sitzung vorbei sein, aber die Aufgabe läuft weiter und wird manchmal sogar komplett abgeschlossen.
Ich stelle das nicht als garantierte Produkteigenschaft dar. Ich beschreibe eine wiederkehrende Erfahrung, die stark genug war, um mein Verhalten zu ändern. Seit ich dieses Muster bemerkt habe, fühlt sich der letzte Rest des Limits nicht mehr wie etwas an, das ich schützen muss. Er fühlt sich wie der beste Zeitpunkt an, um die teuerste und wirkungsvollste Arbeit anzustoßen.
So nutze ich die letzten Prozent heute
Statt die letzten Reserven für sichere, kleine Prompts zu verwenden, behandle ich sie heute als Startfenster für aufwendige technische Arbeit. Dazu zählen zum Beispiel:
- vollständige TypeScript-Migrationen
- repository-weite ESLint-Bereinigung
- tiefe Bug-Reviews über große Codebasen
- umfangreiche strukturelle Refactorings
Entscheidend ist die Vorbereitung. Dieser Workflow ist vor allem dann nützlich, wenn das Projekt bereits startklar ist und die Aufgabe sauber definiert wurde. Dann fühlt es sich oft wie Verschwendung an, die letzten Ressourcen für etwas Kleines zu verbrauchen.
Warum ich das für wichtig halte
Tools wie Codex Plus drehen sich nicht nur um reine Leistungsfähigkeit. Entscheidend ist auch, wie man Aufwand zeitlich einsetzt. Eine kleine Veränderung im Timing kann den praktischen Wert desselben Limits deutlich verändern.
Für mich hat das die Wahrnehmung des Produkts verschoben. Die letzten Prozent fühlen sich nicht mehr wie das Ende einer Session an. Sie sind der Moment, in dem ich aufhöre zu zögern und dem Tool die schwerste Aufgabe übergebe, die ich sinnvoll rechtfertigen kann.
Manchmal fühlt es sich ehrlich gesagt so an, als würde Codex sogar dann noch für mich weiterarbeiten, wenn das sichtbare Limit bereits weg ist. Ob das ein beabsichtigter Grenzfall ist oder einfach daran liegt, wie bestimmte Aufgaben praktisch zu Ende laufen, weiß ich nicht. Nützlich genug war es jedenfalls, dass ich meinen Workflow inzwischen darauf ausrichte.
Eine praktische Beobachtung für Entwickler
Wer Codex Plus für Software Engineering nutzt, sollte vielleicht den eigenen End-of-Limit-Workflow testen, statt automatisch anzunehmen, dass die letzten Prozent besonders vorsichtig eingesetzt werden müssen. In meinem Fall war der gegenteilige Ansatz effektiver.
Mich würde sehr interessieren, ob andere Entwickler dasselbe Muster beobachtet haben, vor allem bei Migrationen, Lint-Cleanup, großen Reviews oder breiten Refactorings über mehrere Repositories hinweg.