J'ai regarde Claude Opus 4.6 passer quatre minutes a rediger un plan d'implementation de 3 000 mots pour un clone 3D de Minecraft entierement fonctionnel — complet avec generation de terrain infinie, un systeme d'inventaire fonctionnel, des reseaux de grottes proceduraux et une IA de mobs. Puis j'ai remis ce plan a Gemini 3.1 Pro et je l'ai regarde coder le tout.
Le resultat avait un mode survie, un mode creatif, des moutons se promenant dans des paysages generes de maniere procedurale, du minerai de diamant cache dans des systemes de grottes souterraines et une barre de vie qui diminuait reellement quand je marchais dans la lave. Un jeu 3D jouable et immersif construit par deux modeles d'IA travaillant en sequence, orchestres via un IDE gratuit, un mardi apres-midi.
Ca n'etait pas cense marcher aussi bien.
J'experimente avec des flux de travail multi-modeles depuis des mois — utilisant differents modeles d'IA pour differentes etapes d'un projet en fonction de leurs forces. La plupart du temps, les resultats sont des ameliorations incrementales. Du code legerement meilleur ici, une iteration legerement plus rapide la. Mais cette combinaison particuliere — Opus pour la reflexion strategique, Gemini pour l'execution, tournant a l'interieur de l'IDE Anti-gravity de Google — a produit quelque chose qui m'a genuinement surpris. Et le tout n'a presque rien coute parce que l'IDE est gratuit.
Pourtant, voici la partie qui continue de me travailler : le flux de travail ne fonctionne que si vous comprenez pourquoi chaque modele excelle la ou il excelle et ou il echoue. Parce que quand vous vous trompez dans la division du travail, le resultat passe d'impressionnant a incoherent rapidement. J'ai appris cela a la dure avant de l'apprendre correctement, et la difference s'est resumee a un insight sur la facon dont ces modeles pensent differemment.
Pourquoi un seul modele d'IA ne suffit plus
Il y a six mois, j'aurais choisi mon modele prefere et l'aurais utilise pour tout. Claude pour la planification ET le codage. Ou Gemini pour la recherche ET l'implementation. Un seul modele, un seul flux de travail, simple.
Cette approche a un plafond, et je l'ai atteint a plusieurs reprises sur des projets complexes.
Le probleme n'est pas qu'un seul modele soit mauvais. Le probleme est que les qualites qui rendent un modele exceptionnel en planification strategique sont souvent en conflit avec les qualites qui le rendent rapide et economique en execution. Le raisonnement profond est lent et couteux. La generation rapide de code est rapide et bon marche mais sujette a la derive architecturale.
C'est la meme raison pour laquelle une vraie equipe logicielle a a la fois des architectes et des developpeurs. Vous ne demanderiez pas a votre architecte senior d'ecrire personnellement chaque ligne de CSS. Vous ne demanderiez pas a un developpeur junior de concevoir l'architecture systeme d'une application distribuee. Differents modes cognitifs, differentes forces, differents roles.
Les modeles d'IA ont atteint le meme point d'inflexion. Opus 4.6 pense comme un architecte senior — methodique, approfondi, couteux par token et capable de maintenir un contexte enorme en memoire de travail. Gemini 3.1 Pro pense comme un developpeur rapide et competent — excellent pour traduire des specifications claires en code fonctionnel, fort sur les taches visuelles et d'UI, et tournant a une fraction du cout.
La question n'est pas "quel modele est meilleur ?" La question est "quel modele pour quel travail ?" Et une fois que j'ai cesse de traiter cela comme un debat philosophique et que j'ai commence a le traiter comme un probleme pratique de conception de flux de travail, tout a change.
Le clone de Minecraft etait mon test de resistance pour cette idee. Un projet assez complexe pour exposer les faiblesses de l'un ou l'autre modele, mais assez concret pour produire un resultat visible et testable. Et j'avais besoin d'un outil gratuit pour orchestrer le passage de relais entre modeles sans construire de pipelines personnalises.
C'est la qu'Anti-gravity est entre en scene.
Anti-gravity IDE — La couche d'orchestration gratuite
L'IDE Anti-gravity de Google est un environnement de developpement agentique, gratuit, qui tourne dans votre navigateur avec rien de plus qu'un compte Google. J'etais sceptique quand j'en ai entendu parler pour la premiere fois — "gratuit" et "puissant" ne partagent generalement pas la meme phrase dans l'espace des outils IA.
Mais la proposition de valeur est reelle. Anti-gravity vous offre deux modes operationnels qui s'alignent parfaitement avec le flux de travail a double modele :
Thinking Mode — concu pour la planification, le raisonnement et la conception architecturale. C'est ici que vit Opus 4.6. Vous lui fournissez une description de projet et il produit des plans d'implementation detailles, des documents d'architecture systeme, des specifications de structure de fichiers et des recommandations strategiques. Il prend son temps. Il est minutieux. Et il utilise cette fenetre de contexte massive pour maintenir toute la portee de votre projet en memoire tout en raisonnant sur les dependances et les cas limites.
Fast Mode — concu pour l'execution de code, l'iteration rapide et la construction. C'est le territoire de Gemini. Une fois que vous avez un plan, Fast Mode le traduit en code fonctionnel avec une vitesse impressionnante. Gemini gere la generation front-end, la logique du jeu, les composants UI et la mise en place du projet sans necessite d'accompagnement constant.
L'IDE supporte egalement la revision humaine dans la boucle, ce qui signifie que vous pouvez approuver ou rediriger la sortie de l'IA a chaque etape. Pour un projet complexe comme un jeu, c'est important — vous voulez detecter les deviations architecturales tot avant qu'elles ne se propagent dans le codebase.
Une mise en garde honnete : le tier gratuit a des limites de debit. Je les ai atteintes deux fois pendant la construction du Minecraft et j'ai du attendre environ quinze minutes a chaque fois avant de continuer. Si vous etes impatient, vous pouvez utiliser une extension OpenCode ou simplement planifier vos sessions autour des limites. La contrainte est reelle mais gerable — et le fait que vous obteniez une planification de niveau Opus et une execution de niveau Gemini pour zero euro rend la pause occasionnelle facile a accepter.
Maintenant, voici le flux de travail qui a produit un clone de Minecraft jouable. Et plus important encore — voici pourquoi chaque etape compte.
Etape un : Laissez Opus reflechir (ne brusquez pas cette etape)
La plus grosse erreur que j'ai commise lors de ma premiere tentative etait de donner a Opus un prompt vague. "Construis un clone de Minecraft" a produit un plan trop generique — une architecture de haut niveau sans la specificite dont Gemini avait besoin pour executer avec precision.
A la deuxieme tentative, j'ai ete specifique. Mon prompt a Opus en Thinking Mode ressemblait a ceci :
"Concois un plan d'implementation complet pour un clone 3D de Minecraft base sur navigateur. Inclus : architecture systeme avec les relations entre composants, recommandations completes de tech stack, structure du moteur de jeu, organisation des dossiers et sous-dossiers, mecaniques de jeu detaillees incluant le placement de blocs, systeme d'inventaire, systeme de sante, eclairage et ombres, IA de mobs avec au moins trois types de creatures, generation procedurale de terrain utilisant le chargement par chunks avec persistance, generation de systemes de grottes avec distribution de minerais, et modes de jeu survie et creatif. Produis le plan en markdown structure avec des sections et sous-sections claires."
Opus a mis environ quatre minutes. Ce qu'il a retourne etait un document dont je serais genuinement fier de presenter lors d'une revue d'architecture. Le plan couvrait :
- Architecture systeme avec des limites de composants claires et des diagrammes de flux de donnees decrits en texte
- Selection du tech stack avec justification pour chaque choix (Three.js pour le rendu, algorithmes de bruit specifiques pour la generation de terrain)
- Structure de fichiers — pas seulement les dossiers de niveau superieur, mais une organisation imbriquee avec la responsabilite de chaque fichier documentee
- Specifications des mecaniques de jeu — placement et suppression de blocs avec detection de collision, slots d'inventaire avec drag-and-drop, systeme de sante lie aux dangers environnementaux et aux degats de mobs
- Algorithme de generation de terrain — terrain infini base sur les chunks avec biomes configurables, generation de reseaux de grottes utilisant le bruit Perlin 3D et regles de distribution de minerais basees sur la profondeur
- Arbres de comportement des mobs — schemas de patrouille, rayon de detection du joueur, logique passive versus hostile
- Modele d'eclairage — ombres dynamiques basees sur la position du soleil, eclairage local base sur les torches dans les grottes
C'est ce que je veux dire quand je dis qu'Opus pense comme un architecte senior. Le plan n'etait pas un schema approximatif. C'etait une specification constructible. Chaque section avait suffisamment de details pour qu'un developpeur competent — ou un modele IA rapide — puisse l'implementer sans deviner l'intention.
J'ai sauvegarde le plan comme fichier markdown. Ce fichier est devenu le pont entre la reflexion d'Opus et l'execution de Gemini.
Voici l'insight critique qui fait que ce flux de travail reussit ou echoue : la qualite du plan d'Opus determine directement la qualite de la sortie de Gemini. Un plan vague produit du code hallucine. Un plan detaille produit une implementation coherente. Le goulot d'etranglement n'est pas le modele de codage — c'est le modele de planification. Investissez votre temps ici.
Etape deux : Laissez Gemini construire (et ne vous mettez pas en travers)
Avec le plan d'implementation charge, j'ai bascule Anti-gravity en Fast Mode et pointe Gemini 3.1 Pro vers la specification.
Les forces de Gemini se sont manifestees immediatement. La phase de mise en place du projet — creation de la structure de dossiers, initialisation des fichiers de configuration, mise en place du pipeline de build — a pris moins de deux minutes. Propre, organise, correspondant exactement a la specification.
La phase de developpement du jeu est la ou les choses sont devenues interessantes. Gemini a travaille le plan section par section :
La generation de terrain est venue en premier. Gemini a implemente le chargement par chunks avec des cartes de hauteur procedurales, et le resultat etait genuinement impressionnant — des collines ondulantes, des plaines plates, des formations montagneuses, le tout genere a l'infini au fur et a mesure que le joueur se deplacait dans le monde. Le chargement des chunks etait assez fluide pour qu'on puisse marcher dans n'importe quelle direction sans lag de generation visible.
Les mecaniques de blocs ont suivi. Placement et suppression precis avec detection de collision, types de materiaux avec des proprietes differentes, et un systeme de curseur qui mettait en surbrillance la face du bloc cible. C'est la que la force front-end de Gemini a brille — le retour visuel etait immediat et satisfaisant.
Le systeme d'inventaire a necessite plus d'allers-retours que prevu. La premiere implementation de Gemini etait fonctionnelle mais visuellement brute. J'ai demande une passe de raffinement avec des references UI specifiques du plan, et la deuxieme iteration etait nettement meilleure — des slots en grille, l'empilement d'objets, le drag-and-drop entre slots.
Les systemes de grottes ont ete le point fort technique. Gemini a traduit la specification de bruit Perlin 3D d'Opus en generation de grottes fonctionnelle qui produisait des reseaux souterrains genuinement explorables. Du minerai de diamant apparaissant aux profondeurs inferieures, du charbon pres de la surface, des bassins de lave au fond — le tout correspondant aux regles de distribution du plan.
L'IA des mobs a produit mon moment prefere. Des moutons errant sur un terrain herbeux, des poussins sautillant pres de l'eau et des mobs hostiles dans les systemes de grottes. Les arbres de comportement de la specification d'Opus etaient simples mais efficaces — les mobs patrouillaient, detectaient le joueur dans un rayon et reagissaient selon leur type.
La phase d'implementation complete a pris environ 40 minutes de temps d'execution Gemini, reparties sur plusieurs sessions (rappelons ces limites de debit). Mon implication etait principalement de la revision — approuver le code genere, rediriger occasionnellement quand Gemini s'ecartait de la specification et tester les fonctionnalites au fur et a mesure qu'elles devenaient operationnelles.
Si vous avez suivi jusqu'ici et vous vous demandez si cela a vraiment produit quelque chose de jouable — oui. Genuinement jouable. Pas jouable au niveau d'un jeu poli, mais jouable au niveau demo. Assez pour explorer, miner, construire, rencontrer des mobs et mourir dans la lave.
Ce qui a fonctionne et ce qui n'a pas fonctionne
Je dois etre honnete sur les imperfections, car elles revelent des choses importantes sur les limites de ce flux de travail.
Ce qui a bien fonctionne :
- La boucle de jeu principale — mouvement, interaction avec les blocs, inventaire — etait solide et reactive
- La generation de terrain etait la fonctionnalite phare ; le monde infini semblait convaincant
- Les systemes de grottes avec distribution de minerais creaient une vraie motivation d'exploration
- Le systeme de sante fonctionnait correctement — les dangers environnementaux et les degats de mobs reduisaient la sante, et la lave etait convenablement fatale
- L'integration sonore a ajoute une bande-son ambiante qui a eleve l'ensemble de l'experience
- Le flux de travail a double mode en lui-meme a prouve le concept : la planification et l'execution sont des taches cognitives differentes qui beneficient de modeles differents
Ce qui n'a pas tout a fait fonctionne :
- Les biomes oceaniques se sont generes comme des sections carrees et uniformes sans la variation organique du terrain terrestre. Le plan d'Opus specifiait une simulation de vagues, mais l'implementation de Gemini etait trop simpliste
- Les arbres se generaient parfois sans blocs de feuilles — des troncs nus debout dans une foret, ce qui semblait plus inquietant que naturel
- Des inconsistances visuelles mineures la ou les limites de chunks se rencontraient, creant des coutures visibles dans certaines conditions d'eclairage
- Quelques problemes de pathfinding des mobs : des moutons marchant occasionnellement dans l'eau et restant coinces, des poules traversant les blocs
Ces imperfections partagent une cause commune : ce sont tous des cas ou l'implementation de Gemini a simplifie ou mal interprete un detail du plan d'Opus. Le plan specifiait une generation organique des oceans ; Gemini a opte pour une approche plus simple basee sur une grille. Le plan specifiait des modeles d'arbres complets avec des algorithmes de canopee ; Gemini a occasionnellement saute la passe de canopee.
C'est le compromis fondamental de l'utilisation d'un modele d'execution rapide : la vitesse se paie en precision sur les cas limites. Gemini reussit les 85% qui sont simples. Les 15% restants — les details nuances, les cas limites, le polissage esthetique — necessitent une intervention humaine ou une passe de raffinement avec un modele plus minutieux.
Ce qui m'amene a la troisieme etape, optionnelle mais puissante.
Etape trois : Faire revenir Opus pour le refactoring
Apres la construction initiale, j'ai selectionne les sections de code problematiques et les ai renvoyees a Opus 4.6 pour debogage et refactoring. Pas tout le codebase — ca aurait ete couteux et inutile. Juste les modules ou l'implementation de Gemini avait des problemes visibles.
Le module de generation d'ocean est alle a Opus avec le prompt : "Ce code de generation de terrain produit des sections d'ocean carrees. La specification demande une variation organique du rivage et un deplacement de surface de type vague. Refactorise pour correspondre a la specification tout en maintenant les performances de chargement par chunks."
Opus a retourne un module refactorise qui a remplace l'eau plate en grille par un algorithme de deplacement de surface base sur le bruit. Les oceans n'etaient toujours pas photorealistes, mais ils sont passes de "manifestement faux" a "stylistiquement adapte a un jeu de voxels." C'est le standard que nous visons.
La correction de la generation d'arbres etait similaire — Opus a identifie que Gemini avait implemente la generation de troncs et la generation de feuilles comme des passes independantes qui se desynchronisaient occasionnellement. La correction etait une fonction de generation unifiee qui garantissait que chaque tronc recevait sa canopee. Elegant, specifique et exactement le type de debogage chirurgical dans lequel Opus excelle.
Ce flux de travail en trois phases — Opus planifie, Gemini execute, Opus refactorise — correspond parfaitement a la facon dont les equipes de developpement performantes travaillent deja. L'architecte concoit, le developpeur construit, l'ingenieur senior revise et affine. La difference est que tout le cycle se deroule en un apres-midi au lieu d'un sprint.
Les calculs de couts qui rendent cela convaincant
Laissez-moi detailler l'economie, car c'est la que l'approche a double modele se justifie vraiment.
Opus 4.6 est cher. On ne peut pas y echapper. La profondeur de raisonnement et la fenetre de contexte massive ont un cout premium. Si j'avais utilise Opus pour la planification ET le codage du clone de Minecraft, le cout en tokens aurait ete substantiel — et le codage aurait ete plus lent que Gemini parce qu'Opus privilegie la minutie plutot que la vitesse.
Gemini 3.1 Pro tourne a un cout par token environ 7 a 8 fois inferieur a celui d'Opus. Pour les taches d'execution — le gros de la consommation de tokens dans tout projet de codage — cette difference de cout est enorme.
En utilisant Opus uniquement pour la planification (peut-etre 15% du total de tokens) et Gemini pour l'execution (les 85% restants), le cout global chute de facon spectaculaire tandis que la qualite de la sortie reste elevee. Le plan fournit les garde-fous qui maintiennent la sortie de Gemini architecturalement solide, et la vitesse de Gemini maintient le projet en mouvement sans bruler le budget.
Dans le tier gratuit d'Anti-gravity, une grande partie de ce cout est absorbee entierement. Je n'ai rien paye pour les sessions de planification et rien pour les sessions d'execution. Les limites de debit etaient la seule friction, et elles etaient gerables.
Meme en dehors du tier gratuit, les calculs fonctionnent. L'utilisation strategique d'Opus pour les taches de planification a haute valeur ajoutee, associee a l'execution de Gemini pour le codage en volume, est la methode la plus rentable que j'ai trouvee pour construire des projets complexes avec l'aide de l'IA.
Conseil professionnel : N'utilisez pas Opus pour des taches que Gemini gere bien. La mise en place de fichiers, la generation de boilerplate, le stylage CSS, l'echafaudage de composants — c'est le point fort de Gemini. Reservez Opus pour les decisions architecturales, le debogage complexe et les situations ou l'IA doit raisonner sur des implications a l'echelle du systeme. Les economies de couts s'accumulent rapidement.
Comment executer ce flux de travail vous-meme
Voici la mise en place pratique, etape par etape.
1. Obtenez l'acces a Anti-gravity IDE. Connectez-vous avec votre compte Google sur la page Anti-gravity de Google. Le tier gratuit vous donne acces au Thinking Mode (Opus) et au Fast Mode (Gemini). Aucune carte de credit requise.
2. Commencez en Thinking Mode. Redigez un prompt de projet detaille. Soyez specifique sur l'architecture, les fonctionnalites, l'organisation des fichiers et les exigences techniques. Plus vous fournissez de details, meilleur sera le plan. Ne dites pas "construis une app." Dites exactement ce que fait l'app, comment elle est structuree et quelles technologies utiliser.
3. Sauvegardez le plan d'implementation. Opus generera un document markdown complet. Sauvegardez-le — c'est la source de verite de votre projet. Chaque prompt ulterieur a Gemini devrait referencer ce plan.
4. Basculez en Fast Mode. Fournissez le plan d'implementation a Gemini et demandez-lui d'executer section par section. Revoyez la sortie a chaque etape. Approuvez ce qui fonctionne, redirigez ce qui ne fonctionne pas.
5. Testez en continu. N'attendez pas la fin pour tester. Au fur et a mesure que Gemini complete chaque module de fonctionnalite, testez-le. Detectez les ecarts tot.
6. Refactorisez selectivement avec Opus. Quand vous trouvez des modules qui necessitent des corrections plus profondes, repassez en Thinking Mode. Donnez a Opus le code specifique et la section pertinente du plan original. Laissez-le refactoriser chirurgicalement.
Pieges courants a eviter :
- Prompts de planification vagues — le mode d'echec le plus courant. Si le plan d'Opus est vague, Gemini va halluciner des details. Poubelle entree, poubelle creative sortie.
- Ne pas revoir la sortie de Gemini — la revision humaine dans la boucle n'est pas optionnelle pour les projets complexes. Gemini peut s'ecarter de la specification, surtout sur les fonctionnalites nuancees.
- Utiliser Opus pour tout — tentant parce que la qualite de sortie est si elevee, mais les penalites de vitesse et de cout ne le justifient pas pour les taches de codage routinieres.
- Ignorer les limites de debit — si vous atteignez une limite du tier gratuit, prenez la pause. Utilisez-la pour revoir ce qui a ete genere jusqu'ici. La pause forcee est souvent productive.
Ce que cela signifie pour la facon dont nous construirons les logiciels
Je veux prendre du recul un instant, parce que construire un clone de Minecraft est amusant mais les implications de ce flux de travail s'etendent bien au-dela du developpement de jeux.
Le schema a double modele — planificateur strategique plus executeur efficient — est un flux de travail de developpement logiciel a usage general. Depuis, je l'ai utilise pour une application de tableau de bord, un service API et un pipeline de donnees. Meme structure a chaque fois : Opus architecte, Gemini construit, Opus affine. Le type de projet n'a pas d'importance. Le flux de travail se transpose.
Ce qui est genuinement nouveau ici, ce n'est pas que l'IA peut ecrire du code. Nous avons ca depuis deux ans. Ce qui est nouveau, c'est que differents modeles d'IA peuvent collaborer sur le meme projet, chacun apportant sa force specifique, orchestres via un outil gratuit que toute personne disposant d'un compte Google peut utiliser.
Il y a douze mois, ce flux de travail aurait necessite des integrations API personnalisees, des scripts de gestion de tokens et une charge d'ingenierie significative rien que pour passer le contexte entre modeles. Maintenant, il suffit de cliquer sur deux boutons dans un IDE.
Je ne vais pas pretendre que c'est parfait. Gemini hallucine encore. Opus reste cher quand vous l'utilisez intensivement. Le tier gratuit a de vraies limitations. Et l'humain dans la boucle — revisant, testant, redirigeant — reste essentiel. Ce n'est pas "l'IA construit votre projet pendant que vous dormez." C'est "l'IA gere les 70% mecaniques pendant que vous vous concentrez sur les 30% creatifs et strategiques."
Mais ces 70% representent l'essentiel du temps. Et les recuperer change ce qu'un seul developpeur peut accomplir en une semaine.
Mon clone de Minecraft a des oceans carres et des arbres occasionnellement sans feuilles. Il y a quelques mois, je n'aurais pas eu de clone de Minecraft du tout. J'aurais eu un fichier README et un generateur de terrain a moitie fini que j'aurais abandonne apres la troisieme soiree parce que l'envergure etait trop grande pour une seule personne.
L'envergure n'a pas change. Ce qui a change, c'est que "une seule personne" signifie maintenant une personne plus un architecte qui ne se fatigue jamais et un developpeur qui ne perd jamais le contexte.
Ouvrez Anti-gravity ce soir. Donnez a Opus un projet que vous repoussez parce qu'il vous semblait trop ambitieux pour un build solo. Lisez le plan qu'il genere. Puis laissez Gemini commencer a construire.
Vous pourriez etre surpris par ce qui apparait sur votre ecran d'ici la fin de la semaine.
Travaillons ensemble
Vous cherchez a construire des systemes IA, automatiser des flux de travail ou faire evoluer votre infrastructure technologique ? J'adorerais vous aider.
- Fiverr (builds personnalises et integrations) : fiverr.com/s/EgxYmWD
- Portfolio : mejba.me
- Ramlit Limited (solutions entreprise) : ramlit.com
- ColorPark (design et branding) : colorpark.io
- xCyberSecurity (services de securite) : xcybersecurity.io
