Uno dei pattern di utilizzo più interessanti che ho notato con Codex Plus non riguarda tanto il modo in cui scrivo i prompt, quanto il momento in cui li uso.
Quando arrivo all’ultimo 3–5% del mio limite di 5 ore o del limite settimanale, non spendo più quella parte residua in richieste piccole. Faccio l’esatto contrario. Uso ciò che resta per avviare i compiti di ingegneria più grandi che riesco a lanciare su più progetti già preparati.
Di solito parliamo di attività come migrazioni complete a TypeScript, pulizia di ESLint su tutto il repository, revisioni profonde dei bug su intere codebase oppure grandi refactoring che, in condizioni normali, sembrerebbero troppo costosi da far partire con leggerezza.
Cosa ha cambiato il mio workflow
Il motivo è semplice: più di una volta ho visto Codex continuare a lavorare anche quando il limite visibile sembrava già esaurito. Dall’esterno la sessione sembra finita, ma il task continua ad avanzare e a volte arriva davvero fino in fondo.
Non sto presentando questa cosa come una regola garantita del prodotto. Sto solo descrivendo un’esperienza ripetuta che mi ha colpito abbastanza da cambiare il mio comportamento. Da quando ho notato questo pattern, gli ultimi punti percentuali non mi sembrano più qualcosa da proteggere. Mi sembrano invece il momento migliore per attivare il lavoro più costoso e più utile.
Come uso ora quella parte finale
Invece di usare il limite residuo per prompt prudenti e poco costosi, ora lo tratto come una finestra di lancio per operazioni di ingegneria pesanti, come per esempio:
- migrazioni complete a TypeScript
- pulizia di ESLint su tutto il repository
- revisioni profonde dei bug su codebase grandi
- refactoring strutturali su larga scala
La chiave è la preparazione. Questo approccio funziona al meglio quando il progetto è già pronto per essere eseguito e il task è definito con chiarezza. A quel punto, usare il budget residuo per qualcosa di piccolo spesso sembra uno spreco del momento di massima leva.
Perché questo mi sembra importante
Strumenti come Codex Plus non riguardano solo la potenza pura. Conta anche il modo in cui distribuisci lo sforzo nel tempo. Un piccolo cambiamento nel timing può cambiare in modo concreto il valore pratico che ottieni dallo stesso limite.
Per me questo ha cambiato anche la psicologia del prodotto. Gli ultimi punti percentuali non sembrano più la fine di una sessione. Sembrano il momento in cui smettere di esitare e affidare allo strumento il lavoro più pesante che abbia senso delegare.
A volte, sinceramente, sembra proprio che Codex continui a lavorare per me anche dopo che il limite visibile è sparito. Non so se sia un caso particolare voluto o semplicemente il modo in cui certi task si completano nella pratica, ma è stato abbastanza utile da spingermi a organizzare il mio workflow intorno a questa osservazione.
Uno spunto pratico per altri sviluppatori
Se usi Codex Plus per il software engineering, potrebbe valere la pena testare il tuo workflow di fine limite invece di dare per scontato che gli ultimi punti percentuali vadano usati con estrema prudenza. Nel mio caso, l’approccio opposto si è rivelato più efficace.
Sarei molto curioso di sapere se altri sviluppatori hanno notato lo stesso pattern, soprattutto quando usano Codex per migrazioni, pulizia del lint, revisioni ampie o refactoring su più repository.