Collaborer avec Codex sur des tâches de longue haleine

Codex peut travailler sur de longues périodes, surtout lorsqu'un /goal lui donne un objectif persistant. Le plus difficile est de rester orienté pendant qu'il travaille pendant des heures ou des jours, découvre de nouveaux détails d'implémentation et passe par plusieurs types de vérification.

Les hypothèses initiales changent souvent une fois l'implémentation commencée. Le modèle de collaboration doit préserver l'objectif tout en vous donnant, à vous et à Codex, la possibilité de réviser le plan à mesure que de nouvelles preuves apparaissent.

Au cours des dernières semaines, j'ai utilisé cinq pratiques :

1. Laisser Codex planifier le travail et maintenir la feuille de route.
2. Garder le fil principal concentré sur la coordination.
3. Auditer la feuille de route et réviser le code après chaque étape.
4. Utiliser des threads locaux pour les tests Computer Use.
5. Rapporter l'avancement via des mises à jour concises et des tableaux de bord.

Généré avec GPT Image 2 dans Codex

1. Laisser Codex planifier le travail et maintenir la feuille de route

Je commence généralement par une conversation plutôt que par le mode /plan. Je décris ce que j'essaie de construire, j'exprime des idées approximatives, je partage des contraintes, et je laisse Codex poser des questions jusqu'à ce qu'il ait suffisamment de contexte pour proposer un plan initial.

Cela maintient la discussion préliminaire flexible. Je n'ai pas besoin de transformer des idées à moitié formées en un cahier des charges formel avant que Codex ne puisse commencer à m'aider. Il peut m'interviewer, reformuler ce qu'il a compris, identifier les lacunes et transformer progressivement la conversation en un plan réalisable.

Au fur et à mesure que le projet prend forme, je demande à Codex de définir l'Objectif actuel. Le mode Objectif donne à Codex un objectif persistant, lui permettant de continuer à travailler vers le même résultat à travers plusieurs tours jusqu'à ce que l'objectif soit atteint, bloqué ou remplacé.

Je peux définir l'objectif moi-même avec /goal, mais je demande généralement à Codex de le faire. Le mode Objectif est exposé via le harnais, donc Codex peut synthétiser notre conversation, le contexte du projet et tout ce qu'il a appris jusqu'à présent en un objectif clair. Il peut également définir les preuves requises avant de considérer cet objectif comme atteint.

Pour les projets plus importants, je demande à Codex d'écrire la feuille de route globale dans GOALS.md. C'est une convention de projet plutôt qu'une fonctionnalité intégrée de Codex, et le fichier peut être nommé comme vous le souhaitez.

J'organise généralement GOALS.md autour d'étapes plutôt que d'une simple liste de tâches. Chaque étape enregistre :

• le résultat attendu
• le travail actuellement dans le périmètre
• les décisions importantes
• les blocages connus
• les preuves requises avant de passer à la suite

Codex maintient le fichier au fur et à mesure que le projet se développe. De nouvelles découvertes peuvent modifier le périmètre d'une étape, en introduire une autre, ou changer les preuves requises pour son achèvement.

Un seul objectif en mode Objectif est actif à la fois. Au fur et à mesure que les étapes sont terminées, Codex met à jour GOALS.md, active l'objectif suivant et continue à travailler pour l'atteindre.

2. Garder le fil principal concentré sur la coordination

Une fois la feuille de route établie, je garde le fil principal concentré sur l'objectif, les contraintes, les décisions et l'état actuel du projet.

Il décide de ce qui doit se passer ensuite, délègue des tâches limitées et évalue les résultats. Il n'a pas besoin de porter chaque détail d'implémentation.

Un travailleur peut passer une heure à lire du code inconnu, essayer plusieurs approches ou tracer un test qui échoue. Le coordinateur n'a besoin que des informations qui affectent le projet dans son ensemble :

• ce que le travailleur a appris
• ce qui a changé
• les preuves à l'appui
• ce qui devrait se passer ensuite

Codex peut déléguer ce travail à un sous-agent ou créer un thread séparé. Fonctionnellement, ils peuvent effectuer la même tâche. J'utilise un thread séparé lorsque je prévois de revenir sur le travail plus tard, car il reste visible dans l'application Codex et conserve son propre historique.

Cela devient particulièrement utile une fois que plusieurs tâches sont exécutées en parallèle. Le fil principal peut continuer à coordonner le projet pendant que chaque investigation, implémentation ou révision reste facile à inspecter.

3. Auditer la feuille de route et réviser le code après chaque étape

GOALS.md reflète ce qui était connu au moment de la dernière mise à jour par Codex. À la fin d'une étape, le projet a généralement découvert quelque chose de nouveau.

Avant de passer à la suite, je demande à un autre thread de comparer la feuille de route avec l'état actuel :

• L'étape est-elle réellement terminée ?
• L'objectif suivant est-il toujours le bon ?
• Des étapes manquent-elles ?
• De nouvelles preuves ont-elles changé l'ordre du travail ?
• La définition de « terminé » tient-elle toujours ?

J'effectue cet audit à la fin de chaque étape, ainsi qu'à chaque fois que de nouvelles preuves modifient matériellement la direction du projet.

J'exécute également /review sur l'implémentation.

Supposons que l'implémentation et les tests à distance pour un flux de connexion soient terminés. L'audit de la feuille de route peut remarquer que personne n'a testé le flux dans un vrai navigateur connecté. En même temps, /review peut constater que le nouveau chemin stocke un jeton de manière incorrecte, même si les tests à distance réussissent.

Le coordinateur met à jour GOALS.md, délègue la correction du jeton, ajoute la vérification manquante du navigateur, et seulement ensuite active l'étape suivante.

Je conserve généralement les audits et les révisions dans des threads séparés. Un sous-agent pourrait effectuer le même travail, mais un thread séparé laisse une trace visible à laquelle je peux revenir plus tard.

4. Utiliser des threads locaux pour les tests Computer Use

La plupart de mes sessions Codex s'exécutent sur une instance distante, afin que le travail puisse continuer pendant que mon ordinateur portable est fermé. Certaines vérifications dépendent toujours de ma machine locale :

• un navigateur connecté
• des identifiants locaux
• Xcode
• les permissions macOS
• le simulateur iOS

Le coordinateur distant peut créer un thread local pour l'une de ces vérifications. J'applique le diff distant ou je bascule sur la branche ou le commit approprié afin que le thread local teste le bon code.

Le thread local utilise le navigateur ou l'application et renvoie des captures d'écran, des journaux et des résultats. Lorsqu'une vérification échoue, un travailleur distant corrige le problème et le thread local teste à nouveau.

Une boucle typique ressemble à ceci :

1. Un travailleur distant implémente le flux de connexion.
2. Les tests distants réussissent.
3. Un thread local utilise l'extension Chrome Codex.
4. Le test du navigateur révèle un bug de redirection.
5. Un travailleur distant le corrige.
6. Le thread local répète la vérification.

Le projet reste distant par défaut. Mon ordinateur ne se joint que pour les vérifications qui le nécessitent. Le thread distant peut également continuer à vérifier si le thread local redevient disponible lorsque je rouvre mon ordinateur portable.

5. Rapporter l'avancement via des mises à jour concises et des tableaux de bord

Les threads de travailleurs rapportent généralement sur une seule tâche. Lorsque je reviens au projet, j'ai besoin d'une vue d'ensemble de l'état :

• ce qui est terminé
• ce qui a changé
• ce qui reste
• ce qui nécessite une décision

Je demande à Codex de faire un rapport à chaque fois que l'état du projet change, en utilisant trois courtes sections :

**Ce qui est fait

Ce qui vient ensuite

Tout blocage**

C'est presque comme avoir un daily standup avec Codex, mais toutes les heures.

Codex peut envoyer la même mise à jour via Slack, soit en message direct, soit dans un canal dédié au projet.

Pendant que je suis dans l'application Codex, j'utilise également /side pour faire le point sans interrompre le fil principal. Depuis le thread latéral, je peux demander un résumé de ce qui a été accompli, de ce qui reste et si quelque chose nécessite mon aide — par exemple, un clic manuel, une approbation ou une autre action de clickops.

Obtenir un résumé depuis le thread latéral

Demander au thread latéral de transmettre mes instructions au fil principal

Je peux ensuite clarifier une instruction, résoudre un blocage, ajouter du contexte ou demander au thread latéral de renvoyer des directives mises à jour au fil principal.

Pour les projets comportant plusieurs étapes ou flux de travail parallèles, je maintiens également un progress-dashboard.html. C'est un artefact de projet personnalisé plutôt qu'une interface utilisateur intégrée de Codex. Il peut afficher :

• l'objectif actif
• les étapes terminées
• les preuves
• les blocages
• les décisions
• les mises à jour récentes

Lorsque je reviens après plusieurs heures, je peux comprendre l'état du projet sans lire chaque thread de travailleur. Codex peut également déployer le tableau de bord en tant que Site afin qu'il reste accessible à distance.

Résumé

J'utilise cette structure lorsqu'un projet est susceptible de découvrir de nouvelles informations, d'impliquer plusieurs éléments de travail indépendants ou de nécessiter des preuves provenant de plus d'un environnement.

Le flux de travail suit un cycle simple. Codex transforme la conversation initiale en une feuille de route, active une étape, délègue le travail et vérifie le résultat avant de passer à la suivante. Les threads locaux gèrent les vérifications qui nécessitent ma machine, tandis que les mises à jour et les tableaux de bord m'aident à reprendre le projet sans avoir à tout reconstruire à partir de zéro.

L'important est de maintenir l'état du projet suffisamment à jour pour que la prochaine décision reflète ce que Codex a réellement appris.

Essayez-le

Collez ceci dans un nouveau thread Codex :

Coordonnez ceci comme un projet de longue durée.

Commencez par m'interviewer sur ce que j'essaie de construire. Laissez-moi décrire des idées et des contraintes approximatives de manière conversationnelle, puis transformez cette discussion en un plan initial.

Créez GOALS.md comme feuille de route partagée. Organisez-la autour d'étapes, avec le résultat attendu, le périmètre, les décisions, les blocages et les preuves requises pour chacune.

Définissez et maintenez un seul objectif en mode Objectif à la fois. L'objectif actif doit correspondre à l'étape en cours.

Gardez ce thread concentré sur l'objectif, les contraintes, les décisions et l'état du projet. Déléguez l'implémentation à des sous-agents ou à de nouveaux threads.

Exigez que les travailleurs renvoient des conclusions, des changements et des preuves plutôt que des transcriptions complètes.

Utilisez des threads séparés lorsque je peux vouloir inspecter, continuer ou réviser le travail plus tard. Utilisez des sous-agents pour les tâches limitées qui n'ont pas besoin de leur propre historique visible.

Après chaque étape, utilisez un thread séparé pour auditer GOALS.md par rapport à l'état actuel et exécutez /review sur l'implémentation. Mettez à jour la feuille de route avant d'activer l'objectif suivant.

Utilisez des threads locaux pour les tests Computer Use qui dépendent de mon navigateur, de mes applications de bureau, de mes permissions, de mes identifiants ou de l'état de mon appareil.

*Lorsque l'état du projet change, rapportez uniquement : - Ce qui est fait - Ce qui vient ensuite - Tout blocage*

Maintenez progress-dashboard.html lorsque le projet s'étend sur plusieurs étapes ou travailleurs. Ne déclarez pas l'achèvement tant que les preuves convenues n'existent pas.

Alternativement, vous pouvez également prendre un Appshot de cet article et demander à Codex :

Créez une compétence Codex réutilisable nommée orchestrate-projects à partir de cet article.

Conservez ces pratiques :

*- laissez Codex m'interviewer et créer les plans initiaux - utilisez GOALS.md comme feuille de route basée sur des étapes - gardez un seul objectif en mode Objectif actif à la fois - gardez le fil principal concentré sur la coordination - auditez la feuille de route et exécutez /review après chaque étape - utilisez des threads séparés pour les travaux auxquels je peux vouloir revenir - utilisez des threads locaux pour les tests Computer Use - rapportez l'avancement via des mises à jour concises, Slack et progress-dashboard.html*