Claude Opus 4.7 vs GPT-5.5 — divergence fondamentale des prompts¶
Resume¶
Thread viral (8.2K likes, 1.3M vues). OpenAI et Anthropic publient simultanement des guides de prompt engineering. Observation : les deux modeles evoluent dans des directions opposees. Claude Opus 4.7 devient hyper-literal (fait exactement ce qu'on dit). GPT-5.5 devient autonome (on donne le but, il trouve le chemin). Les modeles ne sont pas "devenus betes" — ils ne tolerent plus l'ambiguite.
Analyse detaillee des deux directions¶
Claude Opus 4.7 — le contractuel¶
Source : guide de migration Anthropic (docs.anthropic.com)
| Changement | Impact |
|---|---|
| Suivi d'instructions hyper-literal | "Formate la 1ere section en tableau" → ne formate QUE la 1ere. Il faut dire "toutes les sections" |
| Longueur calibree sur la complexite percue | Question simple = reponse courte. Si le pipeline attend une longueur fixe, il faut l'expliciter |
| Moins d'appels outils par defaut | Prefere raisonner. Pour forcer : effort high/xhigh ou prompt explicite |
| Ton direct, moins de validation | Plus de "Great question!". Moins d'emoji. Persona "assistant chaleureux" disparue |
| Moins de sous-agents spawnes | Fait plus inline. Prompter explicitement pour le fan-out |
| Effort = levier principal | low = minimum, xhigh = exhaustif. Plus important que pour tout modele precedent |
| Temperature supprimee | temperature, top_p, top_k retournent 400. Comportement guide par prompt + effort uniquement |
| Prefill supprime | Plus possible de pre-remplir la reponse. Utiliser structured outputs ou system prompt |
Recommandations Anthropic : - Expliciter le scope ("appliquer a TOUTES les sections, pas juste la premiere") - Exemples positifs > instructions negatives - Tags XML pour la structure (<instructions>, <context>, <example>) - Pour les reviews code : "reporte TOUS les problemes, meme incertains" au lieu de "reporte seulement les importants" (le literalisme supprime les vrais bugs)
GPT-5.5 — l'autonome¶
Source : guides OpenAI (cookbook.openai.com, developers.openai.com)
| Changement | Impact |
|---|---|
| Raisonnement interne (reasoning tokens) | Pense avant de repondre via tokens invisibles. Factures en output. PAS optionnel |
| Prompts courts, orientes resultat | "Define the outcome and leave room for the model to choose an efficient solution path" |
| NE PAS ecrire "think step by step" | Le raisonnement est interne et automatique. L'ajouter gaspille des tokens et degrade la qualite |
| Pattern : goal + constraints + output contract | Donner le but, les contraintes, le format de sortie. Pas les etapes intermediaires |
| Ton plus chaleureux par defaut | Reponses plus lisibles, moins de scaffolding necessaire |
| Hierarchie developer > user | Messages developer (system) = definition de fonction. Messages user = arguments. CONSTITUTIONAL.md → developer message |
Parametre text.verbosity | low pour la concision, remplace les instructions de prompt |
Recommandations OpenAI : - Commencer par le prompt le plus court qui preserve le contrat - Separer la personnalite du style de collaboration - Pour les workflows agentiques : definir ce qui constitue la completion et comment verifier, PAS prescrire l'execution - Supprimer l'injection de date (le modele connait la date UTC courante)
Synthese comparative¶
| Dimension | Claude Opus 4.7 | GPT-5.5 |
|---|---|---|
| Philosophie | "Dis exactement ce que tu veux" | "Dis ce que tu veux, pas comment" |
| Longueur prompts | Plus longs, plus explicites | Plus courts, orientes resultat |
| CoT | Controlable (effort) | Automatique (invisible) |
| NE PAS faire | Laisser le scope implicite, negations vagues, scaffolding anti-paresse | Ecrire "think step by step", sur-specifier le process |
| FAIRE | Scope explicite, tags XML, exemples positifs, tuner effort | Goal + constraints + output contract, hierarchie developer/user |
| Temperature | Supprimee (erreur 400) | Remplacee par reasoning.effort |
| Metaphore | Rediger une specification formelle | Rediger une user story avec criteres d'acceptation |
| Mode d'echec | Fait MOINS qu'attendu (parce qu'on n'a pas demande) | Fait PLUS qu'attendu (parce qu'on a laisse de la marge) |
Pertinence ProbatioVault¶
Impact fort — nos prompts doivent etre adaptes.
Pour Claude (orchestration, code, implementation)¶
- Nos prompts structures avec tags XML sont bien adaptes. L'assemblage cache-first (blocs statiques d'abord, dynamiques ensuite) est valide pour Opus 4.7.
- Supprimer le scaffolding anti-paresse. Si
gov-implougov-acceptcontiennent "sois exhaustif", "ne saute pas d'etapes", "utilise toujours tes outils" → reduire. Opus 4.7 peut sur-reagir a un langage agressif qui etait necessaire pour Opus 4.5. - Reviews code : demander TOUT, pas filtrer. "Reporte tous les problemes, y compris les incertains, avec confiance et severite" au lieu de "reporte seulement les importants". Le literalisme supprime les vrais bugs avec un filtre agressif.
- Effort = nouveau levier principal. Remplacer la table temperature-par-etape par effort-par-etape :
- Gates (factuel) :
effort: highouxhigh - Step 0 (creatif) :
effort: medium - Step 6b (code) :
effort: high
Pour GPT-5.5/Codex (reviews, specs, gates)¶
- Simplifier les prompts de gate. Au lieu d'instructions step-by-step detaillees : donner le goal (trouver les ecarts de conformite), les contraintes (scorer sur ces 8 axes), le contrat de sortie (YAML verdict avec champs specifiques).
- Supprimer "think step by step" de tous les prompts Codex. GPT-5.5 le fait en interne. L'ajouter gaspille des tokens.
- Hierarchie developer/user. CONSTITUTIONAL.md → developer message (system). Documents de gate specifiques → user message.
- Effort par etape : Gates ⅗/8 :
high. Spec/tests steps ½ :medium.
Table temperature → effort (remplacement)¶
| Etape | Ancien (temperature) | Nouveau Claude (effort) | Nouveau GPT (reasoning.effort) |
|---|---|---|---|
| 0 (Besoin) | creatif | medium | medium |
| 1, 2 (Spec, Tests) | 0.4 | medium | medium |
| 3, 5, 8 (Gates) | 0.1 | high / xhigh | high |
| 4 (Plan) | equilibre | medium | medium |
| 6b-c (Code) | 0.1 | high | high |
| 7 (Acceptabilite) | 0.1 | high | high |
| 9 (REX) | creatif | medium | medium |
La question philosophique¶
"Le LLM promettait le langage naturel. Maintenant il exige de la pensee structuree. On entraine les humains a devenir des machines ?"
Reponse nuancee : les deux modeles acceptent toujours le langage naturel. Ce qu'ils ne tolerent plus, c'est l'ambiguite. C'est une evolution, pas une regression. Les requetes vagues produisaient deja des resultats inconsistants avec GPT-4o — on ne le remarquait pas parce que les modes d'echec etaient plus doux.
La vraie divergence est entre deux paradigmes : - Claude : execution contractuelle. Prompt = specification formelle. - GPT-5.5 : poursuite autonome de but. Prompt = user story avec criteres d'acceptation.
Pour quelqu'un qui utilise les deux au quotidien, le mode cognitif alterne entre "specificateur" et "product owner". Ni l'un ni l'autre n'est "devenir une machine" — les deux sont des modes que les ingenieurs pratiquent deja dans leur travail avec des humains.