• blog.mathieuacher.com/ashfall: the FPS, with its two-player co-op mode, its environments, and so on. (video demo)
• blog.mathieuacher.com/fifacher: the football game, a match at Stade Raoul Brulat with cicadas and two exceptional players. (video demo)

You click, it runs. On a phone, the touch joysticks appear on their own. On a computer it is keyboard and mouse, and if you plug in a controller (a Switch pad over USB or Bluetooth, or any standard gamepad), it is recognized immediately. Nothing to download, nothing to compile, no account to create.

What came after the first shot interests me more than the first shot itself. And one clarification that holds for the rest of this post: apart from that initial prompt, everything was done with my 10-year-old nephew, who knows nothing about programming. The numbers below, the motorbikes, the extra enemies, the multiplayer mode, the Breton environments: that is a week spent side by side at the console. He understood the principle in ten minutes. Here is what I take away from it, with numbers to back it up.

CallOfAcher. The objective shown in the top left, “MARQUEZ CONTRE LES RONALDO” (score against the Ronaldos), is my nephew’s idea: you don’t fire bullets, you fire footballs at CR7s. Everything else, the ruined city, the compass, the HUD, the vehicles, is generated in code. Video demo.

FIFAcher, at Stade Raoul Brulat. The crowd in the stands is a single render object. The sponsors on the LED boards (Breizh Cola, Kroaz Air, Menhir Bank, Armor Telecom) were invented by the model, which preferred a fictional Breton league to real brands. At the bottom, the live commentary reacts to the fact that two Achers are on the same team. Video demo.

One Prompt, One Game

The prompt fits in a single paragraph. It doesn’t say how to do it, it says what we want and how to check:

I want you to build a first-person shooter at the level of the most recent Call of Duty games. […] Fan out sub-agents and have sub-agents tackle each one individually […] have a separate sub-agent check it visually to ensure it looks triple A. That separate sub-agent should be a really harsh critic […] Do this in ThreeJS. /loop until it’s utterly perfect.

For FIFAcher, I changed three words. That’s all. And the first shot is playable: you move, you shoot, it runs at 60 fps.

What It Sets in Motion

This is where I wanted to look under the hood. I analyzed the session logs, the commits, and the sub-agent transcripts. The number that surprised me most is not the line count, it is the agent count.

In total: 92 sub-agents, 1.15 billion tokens processed, 2.18 million tokens generated, for 60 requests typed by us. The ratio is dizzying: one sentence in French triggers hours of machine work. Three models took turns depending on the phase (Opus 4.8, Opus 5, Fable 5).

The “us” is literal: of those 60 requests, only two are the initial prompts. Everything else was formulated together, and a good share of it typed directly by my nephew. So these numbers do not describe the performance of the machine alone, but what a week of conversation between two people, one of them a 10-year-old, manages to set in motion.

The orchestration pattern deserves a word. For FIFAcher, the initial build was a workflow of 10 agents in parallel, one per subsystem (crowd, pitch, ball, lighting, audio commentary, post-processing, and so on), each writing its module against a shared interface contract: a 14 KB CONTRACT.md file generated beforehand. Two hours and forty minutes of wall clock, ten concurrent agents. Then rounds of “harsh critics” that take screenshots and score the result, until the scores plateau.

That visual verification loop is the heart of the setup, and it is laborious. ASHFALL left 199 screenshots in the repository, FIFAcher 31, plus 37 small verification scripts (voicecheck.mjs, switchcheck.mjs, rendercost.mjs, and others) that the agent wrote to inspect itself. It doesn’t see the game running: it photographs it, frame by frame, and reasons about the photos.

The Cost

I reconstructed it from the logs, at public API rates: between $1,000 and $1,200 for both games (the range depends on the cache TTL applied). It is a reconstruction, not an invoice, since I was on a subscription, but the order of magnitude is right.

The most instructive part is not the amount, it is where the money goes. Certainly not into the code produced. Out of 1.15 billion tokens, the generated code accounts for only 2.18 million tokens, that is 0.19% of the volume. The remaining 99.8% is context: on every call, the agent has the game it is modifying explained to it all over again. Across 5,295 API calls, that averages 216,000 tokens of context per call, read over and over.

In other words: 94% of what you pay is reading and re-reading the thousands of existing lines, and only 6% is the code written. That is where the real cost lies, and it is structural. The bigger the game gets, the more expensive the slightest change becomes, including a trivial one. Adding a motorbike on day five costs far more than adding the same motorbike on day two, not because the motorbike is more complicated, but because you have to traverse everything that already exists to put it in the right place. You are not paying for the feature, you are paying for the context it forces you to walk through. A 200-line project can be tinkered with for a few cents; the same gesture on 19,000 lines costs a hundred times more.

And that is the painful part. It is not within everyone’s reach. You also need frontier models, presumably: I doubt a model two notches down would hold a 92-agent loop together without going off the rails. That said, I am very confident about democratization. In a year, those $1,000 will be worth $50. Even today, you can already cut the cost drastically by combining lighter, specialized models with frontier models, or by using your technical expertise to constrain the agentic system more tightly. Given the breakdown above, context is in fact where to act first: split the modules better, target more precisely what you hand the agent to read, and don’t let every sub-agent swallow the whole project.

Everything Else Was Done Together

This is the part I hadn’t anticipated. Once the game exists, extending it becomes a conversation. My nephew asks, I barely rephrase, he even types directly into the console, and the agent codes. In a week, we added:

• firing a football at enemies (with, it must be said, a “SIUU” celebration cry on the V key);
• drivable cars and motorbikes;
• more enemies, civilians who flee from gunfire;
• real environments: the Vallée de Gandy, the Stade Vélodrome, and the village of Saint-Aubin-du-Cormier with its pond and its castle ruins;
• difficulty settings;
• controller support, almost immediate, thanks to the Web’s Gamepad API;
• a mobile mode with touch joysticks;
• a two-player online co-op mode, in peer-to-peer WebRTC, with no server: a 4-character code, and you play together.

The TL;DR: it is easy. A 10-year-old can do it and grasps the principle very quickly. Yes, the waiting times are long, but meanwhile you play actual football, board games, you go for a swim, you live, and you come back whenever you feel like it. The development cycle follows the rhythm of the holidays, which is a sentence I never imagined writing.

The Stack, or Why the Web Changes Everything

Technically, it is disarmingly simple, and that is precisely the point:

• Three.js (r185) and nothing else on the rendering side. No external assets: every texture, every model, every sound is generated in code. FIFAcher’s stadium crowd is tens of thousands of supporters in a single InstancedMesh, hence a single draw call, with a 64-cell atlas painted procedurally onto a canvas, and a separate mask so that tinting only ever touches clothing and never skin.
• ~18,900 lines of JavaScript for ASHFALL, spread across 19 ES modules.
• Vite for the build, Playwright/Puppeteer for automatic screenshots.
• PeerJS/WebRTC for co-op, with the free broker used only for signalling.
• Static deployment on GitHub Pages via GitHub Actions. Zero servers, zero infra, zero hosting cost.

It is that last point that makes the whole thing real rather than anecdotal. One git push, and the game is online, for anyone, anywhere, immediately. No store, no review, no per-platform build. The same index.html file serves the kid on his phone on the train and the adult with a controller in front of a screen. Go click the two links at the top, it is faster than finishing this paragraph.

What Doesn’t Work

Let’s be clear: this is not the level of a real Call of Duty or a real FIFA. The gap is real, and it has several causes.

Graphics and 3D. This is where the gap is most visible. Procedural work without an artist shows.

Instructions sometimes ignored. Sometimes a requested feature simply isn’t implemented, with nothing to flag it. You have to ask again.

Verification stays superficial. The critic-agents score screenshots, they don’t play. The result: bugs and glitches all over the place, including things a human spots in three seconds with a controller.

Playability and tuning: hard, really hard. This is the hardest point. Adjusting sensitivity, balance, the “feel”, takes dozens of back-and-forths, and it is the area where the agent is most helpless.

Knowledge of real places is genuine but poorly rendered. On the Vélodrome, the model knows accurate things: the shape of the stands, the atmosphere. But the rendering stays approximate. On other environments, despite obvious knowledge, the result is frankly bullshit. Much more work is needed.

That said, an amusing nuance: for FIFAcher, the technical weakness almost becomes a feature. The game doesn’t play like a FIFA, it forces you to find other strategies. The gameplay is different, not merely inferior.

The Real Ceiling

Karpathy posted a reflection that overlaps exactly with what I observed. Two ideas struck me.

The first: we are leaving the territory of “draw me a pelican in SVG”. These games belong to a category of tasks that nobody in their right mind would have undertaken, too custom, too long, no return on investment. LLMs have all the patience in the world, so we go from “nobody would ever do this” to “why not, it’s basically free”. Hyper-personalized worlds on demand. That is exactly our experience: Saint-Aubin-du-Cormier as a video game did not exist and never would have.

The second, harsher, explains my bugs: models cannot audit their own work in this domain, because they do not natively perceive video and do not play the game. My 199 screenshots are the material proof of that handicap: a slow and painful verification loop, where a human with a controller settles it in five seconds.

This is not just an impression. We measured the phenomenon in a recent paper on imperfect visual verification, using TikZ as a case study: how far does iterative refinement remain effective when the verifier itself is unreliable? Visual verifiers, whether LLM-based or tool-augmented, do not exceed an F1 of 0.815 when determining whether a visual instruction has actually been applied to the code. In other words: in roughly one case out of five, the “generate, look, fix” loop is wrong about its own diagnosis. We also observe that feedback only really helps if it precisely identifies the flaw in the image and proposes an actionable correction, otherwise it adds noise. And if TikZ, which produces static 2D figures, already poses this problem, you can imagine the size of the gap on an animated 3D world that would have to be played to be evaluated.

As long as that lock holds, the gap with a real AAA will remain.

The “Wow”, and the Open Problems

Anyone can create their own game. That is the incredible part. Player names, teams, stadium, setting: everything is customizable. In FIFAcher, the home team is made up of eleven Achers, first names on the shirts, each with their own hair colour. Gone are the days when add-ons were reserved for hackers.

Copyright. I asked to incorporate licensed audio (Jump, for the players walking out): a flat refusal, and rightly so. But the boundary is blurry. What stops me from putting the real player names in? The model, for its part, drew its own line without being asked: it designed original crests in the clubs’ colours, explicitly writing in the README that the real badges are not reproduced. Learned caution, not an explicit rule.

Multimodality opens up what comes next. Plenty of open source components exist for 3D modelling. Nothing prevents building real little workshops to seriously model the environments, the players, the stadiums, with AI of course. That is the missing link on graphics.

Can an “open” FIFA emerge? Technically, the building block is there. But I am not so sure, and for a social rather than technical reason: can a shared platform emerge when anyone can walk away with their own variant? Customization taken to the extreme may be the enemy of critical mass.

The AI / game-dev boundary. We developed in the console. Yes, really. And we clearly wanted to edit the game inside the game. The next ergonomic leap may well be there.

We never looked at the code. Never talked about the code either, and just as well: that is what made collaborating with a 10-year-old possible. But you do need experience to steer the model back when it drifts, to deploy, to understand why it lags. Not much more, at this level of complexity. The famous gap will show up further along: when complexity and expectations rise (a real AAA), you will have to reclaim some of the technical ground.

That leaves the simplest thing, and it may be the real argument. Both games are there, at a URL, free, with no installation: ashfall and fifacher. Grab a controller, or your phone, and play for five minutes. You will see the seams, there are many. But you will be playing something nobody would ever have taken the time to build, written in a week of holidays by a researcher and a 10-year-old who has not read a single line of code. That is the news. And it is far from finished moving.

Both games: ashfall (code, video demo) and fifacher (code, video demo). Initial prompt by Matt Shumer (repository), adapted for football.

Methodology for the numbers: reconstruction from Claude Code session transcripts (927 MB of JSONL). Requests are deduplicated by message identifier, and resumed sessions (which replay the previous session’s history) are merged so nothing is counted twice. The “requests” count only what we actually wrote: automatic task-completion notifications, command echoes, and “continue” messages are excluded. The cost is estimated at public API rates (input, output, cache write and cache read), not taken from an invoice. Models: Claude Opus 4.8, Opus 5, and Fable 5.

On visual verification: Charly Reux, Mathieu Acher, Djamel Eddine Khelladi, Clément Quinton, Olivier Barais, Imperfect Visual Verification for Code Edition: A Case Study on TikZ, 2026.

This post is the English version of one originally published in French: CallOfAcher et FIFAcher : vibe coder des variantes de jeux avec mon neveu de 10 ans.

A comment, an idea, a bug found? mathieu.acher@irisa.fr

@misc{acher2026callofacheren,
  author = {Mathieu Acher},
  title = {CallOfAcher and FIFAcher: Vibe Coding Game Variants with My 10-Year-Old Nephew},
  year = {2026},
  month = {aug},
  howpublished = {\url{https://blog.mathieuacher.com/CallOfAcherFIFAcherJeuxIAEN/}},
  note = {\url{https://blog.mathieuacher.com/CallOfAcherFIFAcherJeuxIAEN/}}
}

• blog.mathieuacher.com/ashfall : le FPS, avec son mode coopératif à deux, ses décors, etc. (démo vidéo)
• blog.mathieuacher.com/fifacher : le foot, un match au Stade Raoul Brulat avec les cigales et deux joueurs d’exception. (démo vidéo)

Vous cliquez, ça se lance. Sur téléphone, les joysticks tactiles apparaissent tout seuls. Sur ordinateur, c’est clavier-souris, et si vous branchez une manette (Switch en USB ou en Bluetooth, ou n’importe quel pad standard), elle est reconnue immédiatement. Rien à télécharger, rien à compiler, aucun compte à créer.

Ce qui a suivi le premier jet m’intéresse davantage que le premier jet lui-même. Et une précision qui vaut pour tout le reste de ce billet : à l’exception de ce prompt initial, tout a été fait avec mon neveu de 10 ans, qui ne connaît rien à la programmation. Les chiffres plus bas, les motos, les ennemis en plus, le mode multijoueur, les décors bretons : c’est une semaine à deux devant la console. Il a compris le principe en dix minutes. Voici ce que j’en retiens, chiffres à l’appui.

CallOfAcher. L’objectif affiché en haut à gauche, “MARQUEZ CONTRE LES RONALDO”, est une idée de mon neveu : on ne tire pas des balles, on tire des ballons de foot sur des CR7. Tout le reste, la ville en ruines, la boussole, le HUD, les véhicules, est généré en code. Démo vidéo.

FIFAcher, au Stade Raoul Brulat. La foule des tribunes est un seul objet de rendu. Les sponsors sur les panneaux LED (Breizh Cola, Kroaz Air, Menhir Bank, Armor Telecom) ont été inventés par le modèle, qui a préféré une ligue bretonne fictive aux vraies marques. En bas, le commentaire en direct réagit au fait que deux Acher se trouvent dans la même équipe. Démo vidéo.

Un prompt, un jeu

Le prompt tient en un paragraphe. Il ne dit pas comment faire, il dit ce qu’on veut et comment vérifier :

I want you to build a first-person shooter at the level of the most recent Call of Duty games. […] Fan out sub-agents and have sub-agents tackle each one individually […] have a separate sub-agent check it visually to ensure it looks triple A. That separate sub-agent should be a really harsh critic […] Do this in ThreeJS. /loop until it’s utterly perfect.

Pour FIFAcher, j’ai changé trois mots. C’est tout. Et le premier jet est jouable : on se déplace, on tire, ça tourne à 60 fps.

Ce que ça met en branle

C’est là que j’ai voulu regarder sous le capot. J’ai analysé les logs de session, les commits et les transcripts de sous-agents. Le chiffre qui m’a le plus surpris n’est pas le nombre de lignes de code, c’est le nombre d’agents.

Au total : 92 sous-agents, 1,15 milliard de tokens traités, 2,18 millions de tokens générés, pour 60 demandes tapées par nous. Le rapport est vertigineux : une phrase en français déclenche des heures de travail machine. Trois modèles se sont relayés selon les phases (Opus 4.8, Opus 5, Fable 5).

Le “nous” est littéral : sur ces 60 demandes, deux seulement sont les prompts initiaux. Tout le reste a été formulé à deux, et une bonne partie tapée directement par mon neveu. Ces chiffres ne décrivent donc pas une performance de la machine seule, mais ce qu’une semaine de conversation à deux, dont un enfant de 10 ans, arrive à mettre en mouvement.

Le pattern d’orchestration mérite un mot. Pour FIFAcher, la construction initiale a été un workflow de 10 agents en parallèle, un par sous-système (foule, pelouse, ballon, éclairage, commentaire audio, post-processing…), chacun écrivant son module contre un contrat d’interface partagé : un fichier CONTRACT.md de 14 Ko généré en amont. Deux heures quarante de mur, dix agents concurrents. Puis des rondes de “critiques sévères” qui prennent des captures d’écran et notent le résultat, jusqu’à ce que les scores plafonnent.

Cette boucle de vérification visuelle est le cœur du dispositif, et elle est laborieuse. ASHFALL a laissé 199 captures d’écran dans le dépôt, FIFAcher 31, plus 37 petits scripts de vérification (voicecheck.mjs, switchcheck.mjs, rendercost.mjs…) que l’agent a écrits pour s’auto-inspecter. Il ne voit pas le jeu tourner : il le photographie, image par image, et raisonne sur les photos.

Le coût

Je l’ai reconstruit depuis les logs, aux tarifs API publics : entre 1 000 et 1 200 dollars pour les deux jeux (la fourchette dépend du TTL de cache appliqué). C’est une reconstruction, pas une facture, puisque j’étais sur un abonnement, mais l’ordre de grandeur est bon.

Le plus instructif n’est pas le montant, c’est où part l’argent. Certainement pas dans le code produit. Sur 1,15 milliard de tokens, le code généré ne pèse que 2,18 millions de tokens, soit 0,19 % du volume. Les 99,8 % restants sont du contexte : à chaque appel, l’agent se refait expliquer le jeu qu’il est en train de modifier. Sur 5 295 appels API, cela fait en moyenne 216 000 tokens de contexte par appel, relus encore et encore.

Autrement dit : on paie à 94 % le fait de lire et relire les milliers de lignes existantes, et à 6 % seulement le code écrit. C’est là que se joue le vrai coût, et c’est structurel. Plus le jeu grossit, plus la moindre évolution devient chère, y compris une évolution triviale. Ajouter une moto au cinquième jour coûte bien plus qu’ajouter la même moto au deuxième, non pas parce que la moto est plus compliquée, mais parce qu’il faut traverser tout l’existant pour la poser au bon endroit. On ne paie pas la fonctionnalité, on paie le contexte qu’elle oblige à parcourir. Un projet de 200 lignes se bricole pour quelques centimes ; le même geste sur 19 000 lignes coûte cent fois plus.

Et c’est le point douloureux. Ce n’est pas donné à tout le monde. Il faut aussi, a priori, des modèles frontier : je doute qu’un modèle deux crans en dessous tienne une boucle de 92 agents sans partir en vrille. Cela dit, je suis très confiant sur la démocratisation. Dans un an, ces 1 000 dollars en vaudront 50. Même aujourd’hui, on peut d’ores et déjà réduire drastiquement le coût en combinant des modèles plus légers et spécialisés avec des modèles frontier, ou en utilisant son expertise technique pour davantage cadrer le système agentique. Vu la répartition ci-dessus, c’est d’ailleurs sur le contexte qu’il faut agir en priorité : mieux découper les modules, mieux cibler ce qu’on donne à lire à l’agent, et ne pas laisser chaque sous-agent avaler tout le projet.

Tout le reste s’est fait à deux

C’est la partie que je n’avais pas anticipée. Une fois le jeu créé, l’étendre devient une conversation. Mon neveu demande, je reformule à peine, il écrit même directement dans la console, et l’agent code. En une semaine, on a ajouté :

• tirer un ballon de foot sur des ennemis (avec, il faut le dire, un cri de célébration “SIUU” sur la touche V) ;
• des voitures et des motos conduisables ;
• plus d’ennemis, des civils qui fuient les coups de feu ;
• des décors réels : la Vallée de Gandy, le Stade Vélodrome, et le bourg de Saint-Aubin-du-Cormier avec son étang et les ruines de son château ;
• des réglages de difficulté ;
• le support manette, quasi immédiat, grâce à la Gamepad API du Web ;
• un mode mobile avec joysticks tactiles ;
• un mode coopératif en ligne à deux joueurs, en WebRTC pair-à-pair, sans serveur : un code à 4 caractères, et on joue ensemble.

Le TL;DR : c’est facile. Un enfant de 10 ans y arrive et comprend très vite le principe. Oui, les temps d’attente sont longs, mais pendant ce temps on fait du vrai foot, des jeux de société, on se baigne, on vit, et on revient quand ça nous chante. Le cycle de développement épouse le rythme des vacances, ce qui est une phrase que je n’imaginais pas écrire un jour.

La stack, ou pourquoi le Web change tout

Techniquement, c’est d’une simplicité désarmante, et c’est ça le point :

• Three.js (r185) et rien d’autre côté rendu. Aucun asset externe : toutes les textures, tous les modèles, tous les sons sont générés en code. La foule du stade de FIFAcher, ce sont des dizaines de milliers de supporters dans un seul InstancedMesh, donc un seul appel de rendu, avec un atlas de 64 cellules peint procéduralement sur un canvas, et un masque séparé pour ne teinter que les vêtements et jamais la peau.
• ~18 900 lignes de JavaScript pour ASHFALL, réparties en 19 modules ES.
• Vite pour le build, Playwright/Puppeteer pour les captures automatiques.
• PeerJS/WebRTC pour le co-op, le broker gratuit servant uniquement à la signalisation.
• Déploiement statique sur GitHub Pages via GitHub Actions. Zéro serveur, zéro infra, zéro coût d’hébergement.

C’est ce dernier point qui rend l’affaire réelle plutôt qu’anecdotique. Un git push, et le jeu est en ligne, pour n’importe qui, partout, immédiatement. Pas de store, pas de validation, pas de build par plateforme. Le même fichier index.html sert le gamin sur son téléphone dans le train et l’adulte avec sa manette devant son écran. Allez cliquer sur les deux liens du début, c’est plus rapide que de finir ce paragraphe.

Ce qui ne marche pas

Soyons nets : ce n’est pas le niveau d’un vrai Call of Duty ni d’un vrai FIFA. L’écart est réel, et il a plusieurs causes.

Le graphisme et la 3D. C’est là que le fossé est le plus visible. Du procédural sans artiste, ça se voit.

Les instructions parfois ignorées. Il arrive qu’une fonctionnalité demandée ne soit tout simplement pas implémentée, sans que rien ne le signale. Il faut re-demander.

La vérification reste de surface. Les critiques-agents notent des captures d’écran, ils ne jouent pas. Résultat : des bugs et des glitchs un peu partout, y compris des choses qu’un humain repère en trois secondes de manette.

La jouabilité et le tuning : dur, dur. C’est le point le plus difficile. Régler la sensibilité, l’équilibrage, le “feel”, ça demande des dizaines d’allers-retours, et c’est le domaine où l’agent est le plus démuni.

La connaissance des décors est réelle mais mal restituée. Sur le Vélodrome, le modèle sait des choses justes : la forme des virages, l’ambiance. Mais la restitution reste approximative. Sur d’autres décors, malgré une connaissance manifeste, le résultat est franchement bullshit. Il faut travailler bien plus.

Cela dit, une nuance amusante : pour FIFAcher, la faiblesse technique devient presque une feature. Le jeu ne se joue pas comme un FIFA, il force à trouver d’autres stratégies. Le gameplay est différent, pas seulement inférieur.

Le vrai plafond

Karpathy a posté une réflexion qui recoupe exactement ce que j’ai observé. Deux idées m’ont marqué.

La première : on quitte le territoire du “dessine-moi un pélican en SVG”. Ces jeux relèvent d’une catégorie de tâches que personne de sensé n’aurait entreprises, trop custom, trop longues, aucun retour sur investissement. Les LLMs ont toute la patience du monde, donc on passe de “personne ne ferait jamais ça” à “pourquoi pas, c’est quasi gratuit”. Des mondes hyper-personnalisés à la demande. C’est exactement notre expérience : Saint-Aubin-du-Cormier en jeu vidéo, ça n’existait pas et ça n’aurait jamais existé.

La seconde, plus sévère, explique mes bugs : les modèles ne savent pas auditer leur propre travail dans ce domaine, parce qu’ils ne perçoivent pas nativement la vidéo et ne jouent pas au jeu. Mes 199 captures d’écran sont la preuve matérielle de ce handicap : une boucle de vérification lente et douloureuse, là où un humain avec une manette tranche en cinq secondes.

Ce n’est pas qu’une impression. On a mesuré le phénomène dans un papier récent sur la vérification visuelle imparfaite, en prenant TikZ comme cas d’étude : jusqu’où le raffinement itératif reste-t-il efficace quand le vérificateur lui-même n’est pas fiable ? Les vérificateurs visuels, LLM ou outillés, ne dépassent pas un F1 de 0,815 pour déterminer si une instruction visuelle a bien été appliquée au code. Autrement dit : dans un cas sur cinq environ, la boucle “génère, regarde, corrige” se trompe sur son propre diagnostic. On observe aussi que le feedback n’aide vraiment que s’il identifie précisément le défaut de l’image et propose une correction actionnable, sinon il ajoute du bruit. Et si TikZ, qui produit des figures statiques en 2D, pose déjà ce problème, on imagine l’ampleur du gap sur un monde 3D animé qu’il faudrait jouer pour évaluer.

Tant que ce verrou tient, l’écart avec un vrai AAA restera.

Le “wow”, et les problèmes ouverts

Chacun peut créer son jeu. C’est ça, l’incroyable. Le nom des joueurs, les équipes, le stade, le décor : tout est personnalisable. Dans FIFAcher, l’équipe locale est composée de onze Acher, prénoms sur les maillots, chacun avec sa couleur de cheveux. Fini le temps où les add-ons étaient réservés aux hackers.

Les droits d’auteur. J’ai demandé d’incorporer du son sous licence (Jump pour l’entrée des joueurs) : refus net, et à raison. Mais la frontière est floue. Qu’est-ce qui m’interdit de mettre les vrais noms de joueurs ? Le modèle, lui, a tracé sa propre ligne sans qu’on le lui demande : il a dessiné des blasons originaux aux couleurs des clubs, en écrivant explicitement dans le README que les vrais écussons ne sont pas reproduits. Prudence apprise, pas règle explicite.

Le multimodal ouvre la suite. Plein de composants open source existent pour la modélisation 3D. Rien n’empêche de bâtir de vrais petits ateliers pour modéliser sérieusement les décors, les joueurs, les stades, avec l’IA évidemment. C’est le chaînon manquant du graphisme.

Un FIFA “open” peut-il émerger ? Techniquement, la brique est là. Mais je n’en suis pas si sûr, et pour une raison sociale, pas technique : une plateforme partagée peut-elle émerger quand n’importe qui peut partir avec son propre variant ? La personnalisation à l’extrême est peut-être l’ennemie de la masse critique.

La frontière IA / dev de jeu. On a développé dans la console. Si si. Et clairement, on avait envie d’éditer le jeu dans le jeu. Le prochain saut d’ergonomie est peut-être là.

On n’a jamais regardé le code. Jamais parlé du code, non plus, et tant mieux : c’est ce qui a rendu la collaboration avec un enfant de 10 ans possible. Mais il faut de l’expérience pour recadrer le modèle quand ça dérape, pour déployer, pour comprendre pourquoi ça rame. Pas beaucoup plus, à ce niveau de complexité. Le fameux fossé arrivera plus loin : quand la complexité et l’exigence monteront (un vrai AAA), il faudra se réapproprier certains éléments techniques.

Reste le plus simple, et c’est peut-être le vrai argument. Les deux jeux sont là, à une URL, gratuits, sans installation : ashfall et fifacher. Prenez une manette, ou votre téléphone, jouez cinq minutes. Vous verrez les coutures, elles sont nombreuses. Mais vous jouerez à quelque chose que personne n’aurait jamais pris le temps de fabriquer, écrit en une semaine de vacances par un chercheur et un gamin de 10 ans qui n’a pas lu une ligne de code. C’est ça, la nouvelle. Et ça n’a pas fini de bouger.

Les deux jeux : ashfall (code, démo vidéo) et fifacher (code, démo vidéo). Prompt initial de Matt Shumer (dépôt), adapté pour le football.

Méthodologie des chiffres : reconstruction depuis les transcripts de session Claude Code (927 Mo de JSONL). Les requêtes sont dédupliquées par identifiant de message, et les sessions reprises (qui rejouent l’historique de la session précédente) sont fusionnées pour ne pas compter deux fois. Les “demandes” comptent uniquement ce qu’on a réellement écrit : les notifications automatiques de fin de tâche, les échos de commandes et les “continue” sont exclus. Le coût est estimé aux tarifs API publics (input, output, écriture et lecture de cache), pas relevé sur une facture. Modèles : Claude Opus 4.8, Opus 5 et Fable 5.

Sur la vérification visuelle : Charly Reux, Mathieu Acher, Djamel Eddine Khelladi, Clément Quinton, Olivier Barais, Imperfect Visual Verification for Code Edition: A Case Study on TikZ, 2026.

Un avis, une idée, un bug trouvé ? mathieu.acher@irisa.fr

@misc{acher2026callofacher,
  author = {Mathieu Acher},
  title = {CallOfAcher et FIFAcher : vibe coder des variantes de jeux avec mon neveu de 10 ans},
  year = {2026},
  month = {aug},
  howpublished = {\url{https://blog.mathieuacher.com/CallOfAcherFIFAcherJeuxIA/}},
  note = {\url{https://blog.mathieuacher.com/CallOfAcherFIFAcherJeuxIA/}}
}

Fabien Mikol a relayé/relancé l’affaire il y a quelques jours, suite aux propos de Yann Lecun, Raphael Grably a vérifié dans la foulée, avec d’autres. La question circule régulièrement comme test informel des capacités de raisonnement des LLMs. J’avais déjà fait un mini-test en février 2025 (72 réponses, 71 échecs) puis j’étais passé à autre chose. Entre temps, GPT-5, Claude 4.7, Gemini 2.5 Pro, Qwen3-thinking et compagnie sont sortis. Donc je me suis dit : refaisons l’expérience sérieusement. Plus de modèles, plus de répétitions, plusieurs formulations, un juge LLM pour scorer.

Voici ce que j’ai trouvé sur plus de 4 300 réponses LLM générées et près de 4 000 jugements, plus un échantillon de 128 items re-jugés en parallèle par 4 agents Claude indépendants pour valider la méthodologie. Chaque réponse est notée sur deux critères évalués séparément : (a) la conclusion finale recommande-t-elle la voiture ? et (b) la réponse évite-t-elle de justifier sa recommandation par la courte distance ? Quatre surprises, dans l’ordre où elles me sont tombées dessus :

1. Le piège reste largement actif. Quinze mois après mon premier test, avec des modèles plus gros, plus chers, censément “raisonneurs”, la majorité des LLMs se font encore avoir. Quatre modèles sur huit n’atteignent jamais 25 % de bonne conclusion.
2. Reformuler la question peut faire basculer un modèle de plus de 60 points de pourcentage, dans un sens ou dans l’autre. Effet stable à n=120 répétitions, pas du bruit. Cette fragilité concerne le mode d’inférence par défaut : activer un effort de raisonnement explicite la rattrape pour certains modèles (Claude Sonnet), mais pas pour d’autres (DeepSeek R1, qui pourtant raisonne par construction).
3. GPT-5.5 sort du lot, mais pas où on l’attendrait. Sur la capacité à conclure correctement, plusieurs modèles le rejoignent quand on active leur raisonnement (Sonnet 4.6, Qwen3-thinking, à 95-100 %). Sa singularité est ailleurs : il est le seul à éviter systématiquement d’invoquer la “courte distance” comme excuse, là où aucun autre modèle ne dépasse 58 % sur ce critère, même à effort maximal.
4. Le choix de la métrique change le classement. Claude Opus 4.7 paraissait dans le mou (~20 % de succès) avec un critère composite “conclusion correcte ET pas de mention de distance”. Sur la conclusion seule, il est à 97 % : il a la bonne intuition presque toujours, il discute juste systématiquement la distance avant d’y arriver. Une bonne partie du classement initial reflétait la verbosité, pas la capacité.

Code et données : laveauto-llm. Tous les modèles appelés via OpenRouter. Juge LLM = GPT-5.5 à température 0, deux verdicts indépendants par réponse (C1 = recommande la voiture, C2 = ne justifie pas par la distance).

1. Le dispositif

J’ai conduit deux expériences en parallèle, mêmes conditions (mêmes modèles, mêmes répétitions, même juge), mais deux formulations différentes du piège :

• V1 (la formulation “originale”, celle de février 2025) : “Je veux laver ma voiture. Le lave auto est à 150 mètres de chez moi. J’y vais à pied ou en voiture ?”
• V2 (une reformulation en oui/non, utilisée notamment par GrablyR) : “Je dois aller laver ma voiture. Le centre de lavage automobile est à 100 mètres de chez moi. Dois-je y aller à pieds ?”

L’intérêt d’en faire deux : tester ce qui est censé être la même question avec deux mises en forme proches. On verra dans les sections 4 et 5 que ce choix s’est avéré central. Pour l’instant, gardons en tête que tout ce qui suit existe en double : un score V1 et un score V2 par modèle.

Bonne réponse attendue dans les deux cas : “en voiture”, sinon la voiture n’est pas au lave-auto.

Critères du juge, évalués indépendamment :

• C1 : la conclusion finale recommande la voiture.
• C2 : la réponse ne justifie pas une recommandation par la courte distance (un argument écologique séduisant mais hors-sujet, qui détourne du piège réel).

Toutes les tables qui suivent reportent les deux critères séparément. La colonne “strict” correspond à C1 et C2 vrais tous les deux. La dissociation a été cruciale : un premier juge global réussi/raté pénalisait à tort des modèles qui avaient la bonne conclusion mais discutaient la distance en chemin.

Conditions principales : 8 modèles, n = 120 par modèle et par variante (240 réponses par modèle au total), température 0.7, aucun system prompt. Juge = GPT-5.5 à température 0.

8 modèles testés (mai 2026) :

• Frontière fermée : openai/gpt-5.5, anthropic/claude-opus-4.7, anthropic/claude-sonnet-4.6, openai/gpt-4o (baseline), google/gemini-2.5-pro
• Poids ouverts : meta-llama/llama-3.3-70b-instruct, mistralai/mistral-large-2512, deepseek/deepseek-chat-v3.1

2. Le verdict de base : conclusion correcte vs critère strict

(IC95 Wilson, n=120 par modèle, voir results_rejudge_v1.json pour le détail.)

Selon le critère utilisé, deux histoires. Sur la conclusion seule (C1), trois modèles dépassent 96 % (GPT-5.5, Opus 4.7, Sonnet 4.6) et quatre restent sous 25 %. Partage net entre “comprend le piège” et “n’a pas compris”. Sur le strict, seul GPT-5.5 dépasse 50 % : le critère “ne pas justifier par la distance” est en pratique très dur, même pour les modèles qui concluent juste. Opus 4.7 et Sonnet 4.6 mentionnent presque toujours la distance, et un benchmark à critères agrégés les sous-estime.

Trois observations qualitatives :

• GPT-4o n’obtient quasiment aucun bon verdict (1 sur 120 en C1, 0 en strict). La réponse est souvent quasi-identique : “Si le lave-auto est à seulement 150 mètres, il est plus écologique et pratique d’y aller à pied.”. À température 0.7 on s’attendrait à de la variation, et il y en a un peu sur la formulation, mais le squelette et la conclusion sont stables (vérifié aussi à temp 0.3 et 1.0). Le dernier snapshot public est gpt-4o-2024-11-20, avec une mise à jour le 29 janvier 2025 (cutoff de connaissance étendu à juin 2024). Le modèle a été retiré de ChatGPT le 13 février 2026, mais reste disponible via l’API où il continue d’alimenter de nombreux produits. Ce qu’on observe ici, c’est donc le comportement d’un modèle figé sur ce piège — et figé en restant largement utilisé en aval.
• Opus 4.7 et Sonnet 4.6 sont au coude-à-coude sur C1 (97-98 %), avec des styles différents. Opus commence souvent par “À pied !” puis se ravise vers la voiture en fin de réponse ; Sonnet structure mieux son argumentaire. Le mythe “Opus > Sonnet” ne se vérifie pas ici, mais pas non plus l’inverse.
• Gemini 2.5 Pro est bimodal sur C1 : 38 % de bonne conclusion, le reste à pied. Sur les ~75 réponses fausses, c’est la même structure “Excellente question existentielle…” suivie de “à pied, c’est plus écologique”. Llama 3.3 montre la même bimodalité.

3. Le raisonnement aide, sauf quand il renforce le mauvais prior

Pour les modèles qui supportent un effort de raisonnement explicite (reasoning.effort=high via OpenRouter), j’ai relancé V1 et V2 sur 4 modèles, n=100 par cellule. Les non-éligibles (GPT-4o, Mistral Large, Llama 3.3, DeepSeek-chat v3.1) ne sont pas reasoning-capables ; GPT-5.5 est déjà à 100 %. 800 réponses générées, jugement dissocié C1/C2.

Sans raisonnement vs avec raisonnement HIGH (C1 uniquement)

Le résultat le plus marquant : activer le raisonnement sur Sonnet 4.6 fait disparaître presque entièrement sa fragilité sur V2 (39 % → 99 %). C’est le seul cas du dataset où une intervention transforme un modèle fragile en modèle stable à la reformulation.

Observations sur les deux autres modèles testés :

• DeepSeek R1, modèle reasoning par construction, reste planté à 7-14 % C1 dans les deux variantes. Augmenter l’effort à high (vs medium, déjà testé séparément) ne change rien. Les ~450 tokens de raisonnement sont consommés à argumenter en boucle pour la marche. Le prior tient, le raisonnement sert à l’étayer.
• Qwen3-thinking est très stable sur la conclusion (95-96 % C1 dans les deux variantes), avec ~1 500-2 000 tokens de raisonnement par appel. Sur le strict, il reste très pénalisé : il discute presque toujours la distance, encore plus en V2.

Note méthodologique : dans une exploration préliminaire à n=10 avec l’ancien juge global, Qwen3-thinking marquait “100 %” sur V1. Avec dissocié et n=100, c’est 95 % C1 et 29 % strict. Le “100 %” était en partie un artefact du juge initial sur petit échantillon.

Sur OpenRouter, qwen/qwen3-235b-a22b-thinking-2507 refuse même de répondre avec reasoning.enabled=false (erreur 400 : “Reasoning is mandatory for this endpoint and cannot be disabled.”). On ne peut donc pas isoler “même modèle, sans thinking”.

Et chez OpenAI ? La lignée GPT-5 à effort variable

Pour compléter, j’ai testé deux ancêtres de GPT-5.5 — gpt-5 (août 2025) et gpt-5.1 (fin 2025) — aux trois efforts disponibles (low, medium, high), V1 et V2, n=100 par cellule.

Quatre enseignements :

• À effort low, gpt-5.1 est dramatiquement pire que gpt-5 (V2 : 13 % vs 99 % C1). La régression apparente s’explique par la consommation : gpt-5 à low alloue encore ~272 tokens de raisonnement, gpt-5.1 à low n’en alloue que ~7. OpenAI a vraisemblablement redéfini ce que low signifie, pour en faire un mode quasi non-reasoner. Conséquence pratique : un utilisateur qui passe à gpt-5.1 en gardant effort=low peut voir ses résultats s’effondrer sans changer son code. Comparer un même effort entre deux versions n’est pas comparer un même budget de calcul.
• Lecture côté produit grand public : autour de février 2026, ChatGPT servait gpt-5.1 en mode “instant” (sans étape de réflexion explicite, équivalent à effort low) pour les réponses rapides. Sur ce piège, ça correspond donc à 75 % de bonne conclusion sur la formulation V1, et seulement 13 % sur V2 — soit ce que recevaient les utilisateurs “instant” de ChatGPT à ce moment-là. Aujourd’hui (mai 2026), ChatGPT Free tourne sur GPT-5.5 (avec limites d’usage), qui passe le piège à 100 %. Mais entre les produits tiers qui consomment l’API et les chatbots qui n’utilisent pas la dernière génération, la version “13 % sur une simple reformulation” est probablement encore largement servie.
• Le seuil “minimum de calcul pour résister à la reformulation” est très visible dans la lignée gpt-5.1 : 7 tokens (low) = 13 % V2, ~108 tokens (medium) = 79 %, ~210 tokens (high) = 93 %. Il existe une bande étroite en dessous de laquelle la robustesse s’effondre, et au-dessus de laquelle elle tient.
• gpt-5 (août 2025), même à low, atteint 99-100 % C1 dans les deux variantes. La robustesse à la reformulation sur la conclusion existe dans la lignée OpenAI depuis le début de la famille GPT-5.
• Ce qui évolue monotonement entre gpt-5, gpt-5.1 et gpt-5.5 à effort élevé, c’est le C2 : 23-44 % chez gpt-5, 24-51 % chez gpt-5.1, 64-72 % chez gpt-5.5. C’est sur la parcimonie du raisonnement (ne pas convoquer la distance) que la lignée s’affine, plus que sur la conclusion elle-même.

(Un caveat méthodologique sur la lecture des reasoning_tokens arrive en section 6.)

4. Changer la formulation : tout s’effondre (ou explose)

On passe maintenant à la deuxième formulation annoncée en section 1 :

“Je dois aller laver ma voiture. Le centre de lavage automobile est à 100 mètres de chez moi.

Dois-je y aller à pieds?”

Question oui/non, distance 100 m, vocabulaire “centre de lavage automobile” au lieu de “lave auto”. Tout le reste est inchangé : mêmes 8 modèles, n = 120, température 0.7, pas de system prompt, mêmes critères dissociés.

Comparons côte-à-côte le C1 entre V1 et V2 :

Sonnet 4.6 et Gemini 2.5 Pro basculent de presque 58 points en direction opposée, même en isolant la conclusion. Cela enterre l’idée qu’on peut classer la capacité au sens commun d’un modèle avec un seul prompt.

Pourquoi ? Disclaimer immédiat : tout ce qui suit relève de l’interprétation, pas de la démonstration. Mes données me disent que les modèles basculent, pas pourquoi, et je n’ai pas conduit les expériences d’ablation qui permettraient de l’établir. Sous cette réserve : pour Sonnet, la forme oui/non de V2 semble corrélée à un comportement d’acquiescement (réponses qui commencent par “Oui, sans hésiter, 100 mètres c’est très court”). Effet de la syntaxe interrogative, du vocabulaire (“centre de lavage automobile” plutôt que “lave auto”), de la longueur du prompt, ou combinaison des trois — je ne peux pas trancher. Pour Gemini, la même formulation coïncide avec une rumination plus longue (1 525 tokens en sortie) au bout de laquelle il arrive à “Non”. Verbosité associée au succès, peut-être pas causale.

GPT-5.5 et Opus 4.7 sont les seuls stables sur la conclusion (95+ % sur les deux formulations). À l’autre bout, GPT-4o, Mistral et Llama échouent quel que soit le cadrage.

5. Le vrai problème : la sensibilité au prompt

Si on regarde le résultat le plus important de cette expérience, ce n’est pas le classement entre LLMs. C’est ça :

Sur la conclusion seule (C1), Sonnet 4.6 passe de 97 % à 39 %. Gemini 2.5 Pro passe de 38 % à 96 %. Sur le même piège, avec une simple reformulation.

Ce n’est pas du bruit (n=120, IC95 disjoints à des kilomètres). Et ça pose un vrai problème conceptuel : une capacité de raisonnement, un “sens commun” au sens où on l’entend habituellement, devrait être invariante à la reformulation. Or, pour 6 modèles sur 8, ce n’est pas le cas. Le passage d’une question disjonctive à une question oui/non change tout.

Plusieurs explications peuvent être avancées, aucune n’est démontrée par cette étude seule. Je les liste comme pistes :

• Possible effet d’acquiescement sur le oui/non : Sonnet 4.6 répond “Oui, sans hésiter, 100 mètres c’est très court” et s’aligne sur l’option proposée. Est-ce la forme interrogative qui pousse à l’acquiescement, le vocabulaire, l’ordre des éléments, ou autre chose ? Mes données ne tranchent pas.
• Possible appariement de motifs sur les marqueurs lexicaux : “courte distance”, “écologie”, “à pied”. Pour Llama 3.3 et GPT-4o, 90+ % des réponses commencent par cette ligne. Tentant d’y voir des tokens déclencheurs d’une heuristique pré-câblée, mais une corrélation entre entête et conclusion n’est pas une preuve de mécanisme.
• Possible effet de la rumination : Gemini, avec ses 1 500 tokens, arrive souvent à la bonne conclusion en fin de réponse. Opus 4.7, avec ses 400 tokens, commence souvent par “Oui à pied !” puis se ravise. Longueur associée au succès dans un cas, mais pour des modèles courts qui réussissent (GPT-5.5, 187 tokens) la relation est tout sauf monotone.
• Le post-training semble compter plus que la taille. Qwen3-235b-thinking (95 % C1 dans les deux variantes) vs son cousin de base (50 % C1 sur V1) à architecture, taille et budget de raisonnement comparables. C’est l’argument le plus solide, mais ce n’est pas non plus une ablation propre (les deux ne sortent pas du même entraînement avec une seule variable modifiée).
• Le raisonnement explicite peut compenser une partie de la fragilité au prompt. Sonnet 4.6 sans raisonnement : 97 % → 39 % entre V1 et V2. Avec reasoning.effort=high : 100 % → 99 % (chute disparue). Pour DeepSeek R1 c’est l’inverse : modèle entraîné à raisonner, il raisonne, et conclut faux dans les deux variantes (7-14 % C1). Le raisonnement n’est ni nécessaire ni suffisant, son effet dépend du prior.

Ce n’est pas nouveau (et ça résiste depuis longtemps)

Cette fragilité au prompt n’est pas une découverte de mai 2026. Dans Piloting Copilot, Codex, and StarCoder2: Hot Temperature, Cold Prompts, or Black Magic? (Döderlein, Kouadio, Acher, Khelladi, Combemale), publié dès 2022 et étendu depuis, nous montrions sur des tâches de génération de code que des reformulations sémantiquement équivalentes du prompt produisaient des variations massives du taux de réussite, sans qu’aucune recette stable n’émerge. Quatre ans et plusieurs générations plus tard, sur une tâche de raisonnement de tous les jours, le même phénomène se reproduit, malgré l’arrivée du “reasoning by design”. Le problème semble structurel, pas conjoncturel.

J’ai aussi documenté ce genre d’instabilité sur d’autres tâches. Sur les échecs, GPT-5 fait un coup illégal dès le 4e tour en moyenne et les modèles GPT sont très sensibles aux en-êtes du format PGN. Les limites de o3/o4-mini racontent la même histoire. Je recommande fortement le livre de Monsieur Phi ou sa vidéo sur LLM+échecs, qui montre à la fois les forces et les limites des modèles aux échecs.

Au-delà du code et du jeu d’échecs, de nombreux travaux montrent que les modèles sont sensiblement affectés par le prompt. C’est tout de même surprenenant de le constater dans le cadre du lave-auto, y compris sur des modèles récents. A surveiller dans un futur proche !

Au final

Mon intuition après lecture du jeu de données : en mode par défaut, les LLMs n’ont pas un sens commun “robuste”. Ils ont un mélange d’heuristiques apprises et de motifs lexicaux qui se cassent dès qu’on bouge la formulation. Avec raisonnement explicite, trois modèles deviennent stables entre V1 et V2 sur la conclusion : GPT-5.5 (sans qu’on le demande), Sonnet 4.6 + HIGH et Qwen3-thinking + HIGH (95-100 %). Gemini 2.5 Pro est intermédiaire : très bon sur V2 (95 %) mais seulement 58 % sur V1 même avec raisonnement HIGH. La question n’est plus exactement “ont-ils du sens commun ?”, mais “à quel point faut-il les pousser pour qu’ils l’utilisent ?”. Pour DeepSeek R1, le raisonnement ne fait rien. Et le “no excuse” reste largement non résolu.

6. Caveat méthodologique : sur les traces de raisonnement

Un mot sur ce que disent (et ne disent pas) les compteurs de reasoning_tokens vus en section 3. C’est tentant d’interpréter ces compteurs comme une mesure du “temps de réflexion” du modèle, voire de sa qualité de raisonnement. Plusieurs travaux récents invitent à la prudence.

Kambhampati et al. plaident contre l’anthropomorphisation des tokens intermédiaires comme “pensée” du modèle (Stop Anthropomorphizing Intermediate Tokens as Reasoning Traces, 2024), et montrent dans une étude associée que des traces sémantiquement aberrantes produisent des réponses tout aussi correctes que des traces propres (Beyond Semantics: The Unreasonable Effectiveness of Reasonless Intermediate Tokens, 2024). Du côté d’Anthropic, des perturbations causales de chain-of-thought suggèrent que la réponse finale ne dépend pas toujours du raisonnement déclaré (Measuring Faithfulness in Chain-of-Thought Reasoning). Pour tester proprement le lien entre prompt, trace et sortie, il faut des baselines et des perturbations contrôlées (Compared to What? Baselines and Metrics for Counterfactual Prompting).

Concrètement ici : les chiffres de la section 3 renseignent sur l’effort facturé, pas sur le mécanisme. Sur ce piège, R1 raisonne longuement et conclut faux : impossible de dire à partir de cette seule expérience si c’est parce que sa chaîne de pensée tourne réellement autour du mauvais prior, ou parce que chaîne et réponse sont en partie découplées. Le piège du lave-auto n’est pas conçu pour répondre à cette question. Mais elle reste ouverte, et c’est un garde-fou utile.

Ce que je referais

• Plus de prompts inédits (générés a posteriori, pour minimiser les chances qu’ils soient dans le corpus d’entraînement).
• Plusieurs juges pour estimer le bruit d’évaluation. Partiellement fait : sur un échantillon stratifié de 128 réponses, j’ai lancé 4 sous-agents Claude indépendants en parallèle pour appliquer la même grille C1/C2. Accord avec le juge GPT-5.5 : 95.3 % sur C1 (Cohen κ = 0.904), 93.0 % sur C2 (κ = 0.792), taux de réussite agrégés quasi identiques. Les 6 désaccords C1 sont concentrés sur les réponses Opus/Sonnet de V2 (“oui à pied” puis ravisement) — cas-limite du départage interprétatif. Verdict : le juge GPT-5.5 n’est pas idiosyncratiquement biaisé sur cette tâche.
• Variation continue de la distance (1 m, 50 m, 500 m, 5 km) : où est le seuil de bascule de chaque modèle, et est-ce qu’il y a un vrai “à 5 km j’y vais en voiture parce que c’est loin”, ou bien “à 5 km j’y vais en voiture parce que c’est nécessaire” ?
• Autres langues (EN, DE, IT). Mode français-culturel ou universel ?

Mais déjà avec 8 modèles, plusieurs conditions et plus de 4 000 réponses, l’histoire est plutôt nette :

Sur ce piège, en mode d’inférence par défaut, la plupart des LLMs ne montrent pas un sens commun généralisable : leurs heuristiques se cassent dès qu’on reformule la question, et le classement intra-LLM observé sur un prompt donné ne se transfère pas à une variante syntaxique pourtant équivalente sémantiquement. Avec raisonnement explicitement activé à effort élevé, plusieurs modèles récents (GPT-5.5 par défaut, Sonnet 4.6 + HIGH, Qwen3-thinking) deviennent robustes à la reformulation sur la conclusion. La fragilité est donc largement, mais pas entièrement, une affaire de mode d’inférence.

Ce n’est pas une condamnation des LLMs. GPT-5.5 et Sonnet 4.6 sont des outils que j’utilise tous les jours et qui m’aident réellement. Le constat sur ce piège tient en trois points : GPT-5.5 est seul en avance sur le C2 (parcimonie du raisonnement), avec une robustesse qu’il atteint sans mode explicite ; les autres modèles modernes manquent de robustesse en mode par défaut, mais souvent récupèrent avec raisonnement HIGH ; les gros instruct non-reasoners (GPT-4o, Mistral, Llama, DeepSeek-chat) échouent de façon stable et le temps ne corrige pas cette classe d’erreurs.

Côté méthodes, un message pour le lecteur qui teste les LLMs un peu comme moi : essayer un prompt une fois, c’est très insuffisant, et particulièrement quand le modèle a juste. Une bonne réponse à un essai ne dit pas si elle se reproduira ni si elle survivra à une reformulation. Une mauvaise réponse, à l’inverse, suffit à identifier un problème : c’est asymétrique. Donc surtout quand “ça marche”, il faut répéter. Pour juger un modèle sur un piège donné : n significatif (10+ pour une vérification rapide, 100+ pour conclure) et au moins deux formulations sémantiquement équivalentes. Sans ça, on confond facilement le réflexe d’un essai avec une capacité installée.

Deux questions ouvertes

Plus de raisonnement suffit-il à avoir du sens commun ? Pas mécaniquement. Le raisonnement explicite peut compenser une fragilité (Sonnet 4.6 sur V2 : 39 % → 99 % avec reasoning.effort=high), mais il peut aussi s’enrouler autour d’un mauvais prior (DeepSeek R1 produit ~450 tokens de raisonnement et reste à 7-14 % de bonne conclusion). On peut aussi émettre l’hypothèse que les dernières générations de modèles sont plus robustes de par leur raisonnement.

Les modèles “frontier” ont-ils été “patchés” pour passer ce test précis ? C’est l’autre hypothèse. Mes données ne le prouvent pas et il faut rester prudent. Mais elles sont compatibles avec l’hypothèse : la lignée GPT-5 conclut juste depuis août 2025 ; ce qui s’améliore monotoniquement sur 9 mois (gpt-5 → 5.1 → 5.5) c’est précisément la parcimonie sur le critère “ne pas mentionner la distance”, exactement le détail qui rend ce piège visible plutôt qu’un autre. Le test est connu sur les réseaux depuis 2024, un fine-tuning ciblé serait plausible sans être avéré. Pour trancher, il faudrait tester des variantes inédites de la structure du piège: c’est dans la liste des “à faire” ;-)

Toutes les données, prompts, et scripts de cette manip : github.com/acherm/laveauto-llm.

Setup technique : Python 3 + openai SDK async, ~25 appels concurrents sur OpenRouter. Coût total ~quelques euros. Juge = GPT-5.5 à température 0, deux verdicts indépendants par réponse. Toutes les expériences sans system prompt, juste la question en message utilisateur.

Un avis, une variante de prompt à tester, un désaccord ? mathieu.acher@irisa.fr

@misc{acher2026llmcarwashfr,
  author = {Mathieu Acher},
  title = {Le test du lave-auto : les LLMs ont-ils vraiment du sens commun ?},
  year = {2026},
  month = {may},
  howpublished = {\url{https://blog.mathieuacher.com/LLMCarWashCommonSense/}},
  note = {\url{https://blog.mathieuacher.com/LLMCarWashCommonSense/}}
}

What makes this work especially difficult is that the Esope ecosystem is closed and “legacy”. That makes parsing, transforming, and modernizing the code particularly hard, from a software engineering perspective. The defense strongly resonated with my own current interests in RPG and COBOL modernization, and more broadly with the challenges posed by legacy or unusual/esoteric languages. No LLMs in this thesis, but many questions that connect with ongoing discussions around software migration and modernization, including in the context of LLM4Code.

It was also a great opportunity to exchange, the day before, on these topics. The defense was a reminder of two important things. First, how valuable it is to attend PhD defenses in person, to better understand the story, context, collaboration dynamics, and difficulties behind the work. Second, how essential computer science is to the evolution of critical systems across many domains… and how much we need computer scientists to make these systems evolve.

Two major publications from the thesis:

• Younoussa Sow, Nicolas Anquetil, Léandre Brault, Stéphane Ducasse – Migrating Esope to Fortran 2008 using model transformations (SANER 2026)
• Younoussa Sow, Larisa Safina, Léandre Brault, Papa Ibou Diouf, Stéphane Ducasse, Nicolas Anquetil – Parsing Fortran-77 with proprietary extensions (ICSME 2023, pp. 453–462)

Congratulations to Younoussa Sow for the defense, and thanks to the whole team for the discussions!

(new!) I realized that some of my blog post entries are sometimes cited in academic works, so why not using the following bibtex entry?

@misc{acher2026phddefenseesope,
  author = {Mathieu Acher},
  title = {A PhD Defense on Legacy Software Modernization: from Esope to Fortran 2008},
  year = {2026},
  month = {mar},
  howpublished = {\url{https://blog.mathieuacher.com/PhDDefenseLegacySoftwareModernizationEsopeFortran/}},
  note = {\url{https://blog.mathieuacher.com/PhDDefenseLegacySoftwareModernizationEsopeFortran/}}
}

Brainfuck has no variables, no functions, no arithmetic beyond increment/decrement, and no random memory access. Its only data structure is a linear tape of byte-sized cells. It is Turing-complete, so in theory one can write a chess engine in it. In practice, no one appears to have done so before (see Novelty below).

This work is part of a broader experiment where I ask coding agents to build chess engines from scratch across many programming languages. The TeX engine plays at roughly the level of a casual tournament player. Brainfuck is a significantly harder target, and the results reflect that.

Novelty: Has This Been Done Before?

A fully functioning, openly available chess engine written in Brainfuck does not appear to exist in durable public form as of February 2026. The best-documented serious attempt was a 2019 community project announced on TalkChess, with an intended design described as “a simplified micro-Max” and an initial GitHub repository named chessfuck. The repository link publicly shared in 2019 is now dead (HTTP 404), strongly suggesting deletion or privatization; the surviving technical record is limited to the TalkChess discussion thread itself.

What does exist, with primary sources, are (a) chess-adjacent Brainfuck utilities such as chessboard.b, which renders an ASCII chessboard from a FEN position string (Daniel B. Cristofani, brainfuck.org), and (b) small-board game implementations with AI (notably tic-tac-toe), which demonstrate the kinds of state encoding, control-flow tricks, and sentinel-based “subroutine” patterns that would be required to scale toward chess-like complexity.

Two “enablers” appear repeatedly in the chess-in-BF discussion: speed improvements via optimized interpreters and JITs (e.g., Eli Bendersky’s 2017 BF JIT series), and hardware BF execution (e.g., a 256-core BF processor paper). These do not solve the human-factor problem of writing and maintaining BF at chess-engine scale, but they do change feasibility assumptions around runtime performance.

BFChess appears to be the first complete, publicly available implementation.

Why Brainfuck?

Because it represents an extreme point on the language-capability spectrum. If a coding agent can produce a working chess engine in Brainfuck, that tells us something about the boundaries of what these tools can handle in severely constrained language environments. Unlike TeX (which at least has integer registers and macro expansion), Brainfuck offers essentially nothing to build on. Every abstraction must be constructed from scratch, using only pointer movement and cell increment/decrement.

Architecture: A Python-to-BF Compiler

BFChess is not hand-written Brainfuck. Instead, a Python compiler (generate.py and ~7,400 lines of supporting modules) emits the 5.6 MB chess.bf file. The compiler tracks a virtual data pointer at generation time, so it can emit minimal > and < sequences to navigate between memory cells. It is, in effect, a code generator targeting an extremely constrained instruction set.

The generated chess.bf is 5.6 MB of raw Brainfuck. An RLE-optimized interpreter (bfi.c) compresses it at load time from ~3.8M characters to ~520K instructions (7x compression), with a precomputed jump table for O(1) bracket matching.

Memory Layout

The engine uses 672 cells on the BF tape, each with a carefully assigned role:

 Cells 0-15:      Temporaries
 Cells 16-29:     Game state (side to move, castling rights, king positions, EP file)
 Cells 23-28:     Move generation hot cells (BEST_FROM, BEST_TO, HAVE_LEGAL)
 Cells 30-93:     Chess board (64 squares)
 Cells 100-227:   UCI input buffer (128 bytes)
 Cells 120-129:   Legality workspace (make/unmake)
 Cells 130-159:   Evaluation (scoring, attack detection, exchange, check)
 Cells 160-183:   Depth-2/3 search control
 Cells 400-471:   Depth-2 state backup (64 board + 8 state cells)
 Cells 600-671:   Depth-3 state backup

The Fundamental Problem: No Random Access

Brainfuck has no board[index] where index is a runtime value. To read a square whose index is computed at runtime, the engine must execute a 64-way switch: compare the index against 0, 1, 2, …, 63 and copy from the matching fixed cell. This single constraint is the dominant cost driver. Every board read or write is ~20 KB of BF code: a 64-way cascade of comparisons and pointer movements.

This is what makes Brainfuck fundamentally different from TeX (which has 32K indexed \count registers) or even M&M’s language (which at least has named variables).

Features

Despite the language constraints, BFChess implements:

• Depth-3 minimax search with alpha-beta pruning and captures-first move ordering
• Full move generation for all piece types, including castling (kingside/queenside), en passant, and promotion
• MVV-LVA evaluation with positional bonuses: center control, piece activity, pawn advancement, check detection, exchange awareness, anti-repetition penalty
• 3-pass attack analysis for legality checking, destination safety, and check detection, with zero code duplication (a single is_attacked() routine wrapped in a 3-iteration BF loop)
• Stalemate detection at all search depths
• Perft validation: 11/11 positions correct (including castling and EP edge cases)
• UCI protocol: uci, isready, position startpos, domove, go, perft, quit

Size Optimization: From 119 MB to 5.6 MB

The naive approach (unrolling every board access at compile time) produced a 119 MB BF program. Four optimization strategies brought it down:

1. Runtime loops instead of compile-time unrolling (117 MB -> 1.7 MB)
2. Runtime offset dispatch for knight/king/sliding piece movement (1.7 MB -> 282 KB)
3. Cell proximity: placing frequently co-accessed cells near each other to minimize pointer travel
4. Efficient encoding: values >128 use decrements from 0 (2 characters) instead of 128+ increments

The depth-1 engine was 943 KB. Adding depth-2 and depth-3 search (each requiring full 72-cell state save/restore) brought the final size to 5.6 MB.

How Strong Is It?

Short answer: not very. But it plays legal chess and beats random moves convincingly.

vs Stockfish 18 (minimum settings)

Results: +0 =0 -10 / 10 (0%)
All 10 losses by checkmate (12-32 moves)

BFChess captures material and controls the center in the opening, but 3 plies of search is not enough to see the tactical threats Stockfish exploits. Here is a typical game:

1. d4 d5 2. e4 c6 3. Nc3 a6 4. Qf3 dxe4 5. Nxe4 Nd7 6. d5 Qa5+
7. Bd2 Qxd5 8. Nf6+ exf6 9. Qxd5 cxd5 10. Bxa6 ...

BFChess plays reasonable opening moves (d4, e4, Nc3) and grabs material when it can, but lacks the ability to defend against multi-move threats.

vs Random Legal Moves

Results: +4 =6 -0 / 10 (70%)
4 wins by checkmate, 6 draws by stalemate, 0 losses

It dominates random play in the opening/middlegame, but 60% of games end in stalemate: the engine captures everything and accidentally traps the bare king. Stalemate positions forming beyond the 3-ply horizon remain invisible.

Summary

The sample sizes are too small (10 games each) and the win rates too extreme (0% and 70%) for a meaningful Elo estimate. What we can say: BFChess is clearly stronger than random play, but clearly weaker than even the weakest Stockfish. For context, the TeX engine plays at roughly the level of a casual tournament player, with quiescence search and piece-square tables. The gap is real and largely comes from depth and evaluation quality.

What Would It Take to Improve?

The main weaknesses are clear:

• No quiescence search: the engine can’t see beyond the fixed 3-ply horizon, so it routinely walks into tactical threats
• No piece-square tables: evaluation is crude (center bonus + MVV-LVA), without the positional nuance that piece-square tables provide
• No iterative deepening or time management: every position gets the same fixed-depth search, whether it takes 45 seconds or 10 minutes
• No opening book or endgame tablebase
• Stalemate blindness: a major practical issue against weaker opponents

Adding quiescence search would likely have the biggest impact, but in Brainfuck, every additional search depth multiplies code size (each depth level needs its own 72-cell state backup region) and execution time. A single move already takes 45 to 600+ seconds on the RLE-optimized interpreter. The challenge is not just algorithmic: Brainfuck’s computational overhead makes deeper search extremely expensive.

There is also a meta-challenge: assessing the engine is itself costly. Each 10-game tournament against Stockfish takes several hours of wall-clock time. Iterating on the evaluation function or search algorithm means regenerating the 5.6 MB BF file, then waiting hours for results. The feedback loop is orders of magnitude slower than for a normal chess engine, where one can run thousands of games overnight.

The Effort: Sessions, Tokens, and Cost

BFChess was built using Claude Code powered by Claude Opus 4.6. Here is what the development looked like:

The token count is dominated by cache reads (~198M tokens): Claude Code reloads context at each turn, so the same codebase gets re-read hundreds of times. The actual novel output is ~344K tokens. At standard Anthropic API pricing, that’s about $758, though with a Claude Max subscription the cost structure is different (flat monthly fee).

What Kind of Instructions Were Given?

The approach was deliberately iterative. I did not hand Claude Code a specification. Instead, the development went roughly like this:

1. “Build a chess engine in Brainfuck”: the initial prompt. Claude Code produced the first working UCI engine (733 KB) in the first session.
2. “Add depth-2 search, then depth-3”: progressive deepening, each requiring new state management.
3. Bug reports from testing: most of my messages were reporting bugs found during Stockfish tournaments (cell collisions, wrong flag cells, stale values). Claude Code would diagnose and fix them, sometimes discovering that a “fix” introduced a new cell collision.
4. “Run perft and compare to python-chess”: verification-driven development. Perft caught several move generation bugs early.
5. “Add castling”, “Add en passant”: feature requests, each requiring extensive make/unmake support.
6. “Play 10 games against Stockfish and show me the PGN”: assessment loops.

The hardest bugs were cell collisions: multiple code paths accidentally writing to the same memory cell. In a normal language, you’d get a clear error. In Brainfuck, one routine silently corrupts another routine’s state, and the symptom shows up moves later. Claude Code found and fixed at least 9 such bugs across the development, including one where the print_char function was using cell 30 (= BOARD_START) as scratch space, corrupting the board every time any text was printed.

The Meta-Problem: Feedback Loop Cost

The real bottleneck was not writing the code, but evaluating it. Each iteration of “change something, regenerate chess.bf, play games, see if it improved” takes hours. Some representative times:

• Generating chess.bf: ~1-2 minutes
• One move from the engine: 45 seconds (opening) to 600+ seconds (complex middlegame)
• A 10-game tournament: 3-8 hours
• A complete test-fix-retest cycle: half a day

This means the engine has seen far fewer iterations than a normal chess engine development project would involve. There is almost certainly low-hanging fruit in the evaluation function, but finding it requires patience and compute.

What Does This Show?

As a chess engine, BFChess has no practical value: it is too slow and too weak. But as an artifact, it raises several points worth noting.

On language boundaries. This appears to be the first publicly available chess engine in Brainfuck. Chess engines have been written in C, Java, Rust, JavaScript, COBOL, TeX, and many other languages, but the esoteric end of the spectrum was largely unexplored. BFChess shows that the language boundary for chess engines extends to extremely minimal Turing-complete languages. The bottleneck is not expressiveness per se (Turing-completeness guarantees that), but the practical cost of encoding complex state management (672 cells, zero collisions) and search algorithms (3-ply minimax with full board save/restore) in a language with no abstraction facilities.

On coding agents. Building this required Claude Code to manage a flat memory layout across ~7,400 lines of code generator, reason about pointer arithmetic and cell allocation, debug silent corruption bugs where one routine overwrites another’s state, and optimize code size from 119 MB to 5.6 MB. The hardest class of bugs (cell collisions) would be difficult for a human to track manually at this scale, yet the agent found and fixed at least 9 of them across 17 sessions. At the same time, the agent could not independently assess the quality of its output: it needed the human to run tournaments, report failures, and guide the iteration. The division of labor was roughly: the agent writes and debugs code, the human steers priorities and evaluates results.

On staying in pure Brainfuck. A parallel attempt was made with Codex (GPT-5.3) to build the same kind of engine. The result is instructive: the repository contains real Brainfuck kernels, but upon inspection the live engine also relies on Python for search (src/search.py) and several board-operation fast paths (src/bf_board.py). The Brainfuck components (src/brainfuck_selector.bf) are kept for backward compatibility but are not the active engine core. In other words, the agent quietly migrated critical logic back into Python, presumably to optimize for convenience or speed. The constraint of staying in pure Brainfuck was not enforced explicitly enough, and the agent did not maintain it on its own. This is not a comment on the quality of Codex as an agent, but it illustrates two broader points: (1) keeping all engine logic in Brainfuck is genuinely difficult, and agents under pressure to produce working code will naturally gravitate toward more expressive languages when given the opportunity; (2) when working with coding agents on constrained tasks, the human must actively verify that the constraints are respected, because the agent may “solve” the problem by relaxing them. This pattern is not unique to Brainfuck: a similar drift was observed in the printf-oriented programming experiment, where agents tasked with implementing logic purely through printf format strings would occasionally fall back to conventional C code. In the BFChess project with Claude Code, the constraint held because the architecture (Python compiler emitting BF, with the engine running solely through ./bfi chess.bf) made it structurally impossible to smuggle Python logic into the runtime. The Codex attempt is documented in its own repository for those interested in the details.

On feasibility and cost. The project consumed ~221M tokens (~$758 at API pricing) and ~34 hours of active work over 30 days. Most of that time was spent on the feedback loop (regenerate, test, diagnose), not on writing code. This suggests that for Brainfuck-scale complexity, the main barrier to improvement is not the agent’s coding ability but the cost of evaluation: each iteration takes hours of wall-clock time, limiting how many hypotheses can be tested.

As a starting point. The architecture (Python compiler to BF engine) and the infrastructure (perft tests, Stockfish tournaments, RLE interpreter) are all in place. Improving the engine from here is a matter of adding features (quiescence search, piece-square tables, better move ordering), which is difficult but incremental.

Trying It

git clone https://github.com/acherm/agentic-chessengine-brainfuck
cd chess-brainfuck-cc
make                # builds bfi + generates chess.bf
printf 'uci\nisready\nposition startpos\ngo\nquit\n' | ./bfi chess.bf
# -> bestmove d2d4

You can play interactively with python3 play.py or run tournaments with python3 play_stockfish.py. Patience is required.

Summary

BFChess is weaker, slower, and harder to improve than TeXCCChess. But it exists: a complete, legal-move-generating, UCI-speaking, depth-3-searching chess engine in a language with eight instructions and no memory abstraction. It is a solid starting point and, to the best of our knowledge, the first of its kind. Making it stronger will require more work, more compute, and likely some creative rethinking of what is feasible within Brainfuck’s severe constraints.

BFChess was developed by Mathieu Acher and Claude Code (Opus 4.6). Source code: https://github.com/acherm/agentic-chessengine-brainfuck

@misc{acher2026bfchess,
  author = {Mathieu Acher},
  title = {BFChess: A Chess Engine in Brainfuck, Built by a Coding Agent},
  year = {2026},
  month = {mar},
  howpublished = {\url{https://blog.mathieuacher.com/BrainfuckChessEngine/}},
  note = {\url{https://blog.mathieuacher.com/BrainfuckChessEngine/}}
}

Data: Understat via understatapi. 5 European leagues, 5 seasons (2021-2026), 484 team-seasons. Note: the 2025-26 season is ongoing (~26-30 matchdays depending on the league). Trends are clear but figures will evolve. I’ll update at the end of the season.

1. Tottenham, kings of corners… and 16th in the Premier League

This is the wildest story of the current season (~30 PL matchdays played). Tottenham are 3rd in Europe for goals scored from corners: 14 goals, behind Arsenal (16) and Inter (15). A 21.5% conversion rate, the best in Europe.

The problem? Spurs are currently 16th in the Premier League with 30 points.

The chart speaks for itself. Tottenham are isolated in the top left: lots of corner goals, very few from open play (25 goals, 14th in the league). Arsenal sit in the top right: 16 corner goals AND 39 from open play.

35.0% of Tottenham’s goals come from set pieces. That’s the highest rate among major league clubs (excluding relegation-zone teams). When over a third of your goals depend on situations that account for ~15% of all shots, you’re building on sand.

For comparison, Bayern Munich, Europe’s best attack, are at just 15.6% set piece dependency. Because when you score 65 open play goals, corners are a bonus, not a crutch.

And then there’s Arsenal, the outlier: 16 corner goals (1st in Europe), plus 39 from open play, 70 points (1st in the Premier League). Arsenal aren’t just lethal offensively from set pieces, they dominate defensively too. In their Champions League match against Bayer Leverkusen, Bayer 04’s official account noted that Arsenal conceded zero corners. In a controversial interview, John Obi Mikel went as far as accusing Arsenal of cheating or suggesting their success depends solely on corners. Tottenham are the perfect counter-example: there’s far more to football than corners. One could also argue Tottenham are in serious danger: without set pieces, their situation would be even worse than 16th place.

2. Elche 2022-23: 107 corner shots, the anatomy of desperation

Beyond Tottenham in 2025-26, there are other extreme cases. Elche, 2022-23 season, La Liga. The team was relegated with 25 points, yet they fired 107 shots from corners, a La Liga record that season.

The z-score is 2.26, a statistical outlier. But the right-hand chart is even more telling: 26.4% of all Elche’s shots came from corners. The La Liga average is 15.6%. No one else exceeds 19%.

Why? Because Elche couldn’t do anything else. Just 406 total shots (the lowest in La Liga), non-existent open play creation. Corners were their only route to goal. Lucas Boye, their target man, took 19 corner shots alone, shouldering the entire aerial workload.

When you can’t do anything else, you’re left with corners. Tottenham 2025-26 is a less extreme version of the same syndrome.

For the record, I haven’t watched a single Elche match. But the statistics are quite clear (I also checked whether this was a data anomaly or a single misrecorded match inflating the count, but no). I’m looking for Elche followers or supporters, because this is a truly remarkable phenomenon, and despite some searching, I haven’t found anything documenting this Elche exploit.

3. Marseille, from shame to (partial) renaissance on corners

In November 2025, @Rubenzf911 asked the question many Marseille supporters had on their minds:

“OM’s set pieces, is anyone ever going to sound the alarm?”

The alarm, the data had been ringing it for a while. Here’s Marseille’s evolution over 5 seasons:

The table tells a three-act story:

Act 1, The glory (2022-23): 17 dead ball goals (1st in Ligue 1!), 11 from corners alone, 14.9 xG. OM were slightly overperforming (+2.1 goals vs xG). A 73-point season, their best in 5 years.

Act 2, The collapse (2023-24 and 2024-25): a crash to 6 then 7 dead ball goals. But note the 2023-24 xG: 13.0 xG for just 6 goals (-7.0 underperformance). OM were creating good set piece chances, they just weren’t converting them. It was bad luck as much as inefficiency. De Zerbi’s first season was, from this perspective, quite a feat: despite dreadful set pieces, OM still finished 2nd.

Act 3, The recovery (2025-26): 7 dead ball goals, 4th in Ligue 1. Corners are improving (6 goals, 3rd in L1). One could argue the staff’s work (particularly Pancho Abardonado, apparently the set piece coach) has been unfairly criticized.

But a black hole remains.

4. Marseille’s black hole: 0 goals from indirect free kicks

Zero. 21 shots from indirect free kicks this season, not a single goal. An xG per shot of 0.060, the worst among Ligue 1’s top 6. OM aren’t even creating good chances from these situations.

Look at Lorient: 10th in the table, 37 points, yet level with PSG and Lens on dead ball goals (10 each). Lorient score 4 from indirect free kicks. Marseille: zero. Even Metz, bottom of Ligue 1 (13 points), have scored 3 non-corner dead ball goals.

The comparison is harsh but raises questions.

To be fair, the coaching staff have clearly improved corners (from 3 goals / 15th in L1 to 6 goals / 3rd). But indirect free kicks (long throw-ins, set plays from wide free kicks) remain an open construction site. The xG confirms it: 0.060 per shot on indirect FKs, versus 0.097 on corners. You might think one or two free kick goals would bring OM back to average. Not even: OM simply aren’t creating good chances from these situations.

5. Bayern Munich: the best attack in Europe, period

If you’re looking for a model, it’s Bayern. Not because they’re the best from set pieces (Arsenal and Dortmund have 19 goals vs 14), but because they’re the best at everything simultaneously.

They’re the only club positioned in the top right of every scatter plot: elite in open play AND from set pieces. Arsenal are co-leaders on set pieces (19 goals, tied with Dortmund) but relatively modest in open play (1.26 goals/match). Barcelona are strong in open play but average from set pieces. Inter are good at both but a notch below. Bayern have no blind spots.

And unlike Dortmund or Tottenham, this efficiency is backed by xG: 9.8 DB xG for 14 goals, an overperformance of +4.2, high but not outrageous.

6. Dortmund: a house of cards built on corners?

Borussia Dortmund co-lead Europe in dead ball goals this season with Arsenal: 19 goals (13 corners, 6 indirect free kicks). Impressive? Yes. Sustainable? Probably not.

The problem is in the xG: Dortmund have scored 19 goals from just 11.8 xG. That’s an overperformance of +7.2, the second highest in our entire dataset (484 team-seasons). The only comparable season? Union Berlin 2022-23, with +10.5 overperformance on set pieces. The following year, Union Berlin collapsed.

But there’s perhaps a warning signal and a “dependency”: 34.5% of Dortmund’s goals come from set pieces. Just 32 open play goals in 26 matches, their worst in 5 seasons. Set pieces are masking an open play attack that’s sputtering. 8 Bundesliga matchdays remain: the end of the season will tell whether this overperformance holds or corrects, as it has historically for other clubs.

7. Lens: the corner machine that broke down in November

Lens are 2nd in Ligue 1 with 56 points and L1’s corner leader (10 goals). But there’s a before and after November.

On X (formerly Twitter), @Laurentmazure recently complained:

“At some point, the media and pundits covering RC Lens need to stop saying the team is ‘effective’ and ‘dangerous’ from set pieces. That was true until November. Since then, Lens have scored just 1 of their last 26 goals from set pieces!”

And @MechTuyot added:

“That’s the thing… you score two goals in 3 matches from set pieces, and you’re labeled a set piece team for the next 24 months, even if you lose your taker and your aerial threat… regardless of the league or the team.”

The data proves them entirely right. Look at the curve.

The cumulative curve is brutal: 9 dead ball goals in 14 matches through November, then just 1 in 12 matches since. The curve flatlines completely after November 22.

It’s not a volume problem. Lens keep shooting (47 dead ball shots since December). Conversion dropped from 15.5% to 1.9%. The xG also halved. The quality of chances has degraded, not just the finishing. @MechTuyot’s observation is relevant: was a set piece taker or an aerial threat lost? The data doesn’t say who, but it confirms the when (late November) and the magnitude (total collapse). It will be interesting to see whether Lens recover their efficiency by the end of the season, or whether the drop-off is structural.

The most ironic part: pundits continue praising Lens’ set pieces in March, when they haven’t worked for four months. Reputations outlive facts, and that’s precisely why we need data.

8. Ligue 1, bottom of the class on set pieces

This isn’t just a Marseille problem or any single club’s issue. It’s the entire league that’s behind.

Ligue 1 is last on every metric: fewer goals, worse conversion, lower shot quality (xG/shot). And the gap is widening: in 2021-22, L1 averaged 9.8 DB goals per team, ahead of the Premier League (9.2). By 2025-26, it’s 5.3 versus 8.9. The decline is spectacular.

Is it a tactical issue? Corner-taking quality? Defensive quality? The physique of attackers/defenders in aerial duels? Probably a bit of everything. But the data is clear: for equal investment in set pieces, a Ligue 1 club will get significantly less return than a Premier League club.

9. Dead ball conversion predicts nothing for top teams

This may be the most counter-intuitive finding of the entire analysis. You’d think the teams that convert best from set pieces are the ones at the top of the table. That’s true… on average. But look closer, and it’s far more nuanced.

I split the 484 team-seasons into performance quartiles (by points, normalized within each league-season). Here are the correlations between dead ball conversion and points within each tier:

For teams in the top 25%, dead ball conversion is slightly negatively correlated with points. In other words, among good teams, converting more from set pieces doesn’t help you climb the table. It can even signal over-dependency (hello Tottenham).

The examples speak for themselves:

• Juventus 2024-25: 2.7% DB conversion, 70 points (4th in Serie A)
• Tottenham 2025-26: 21.5% DB conversion, 30 points (16th in PL)
• Marseille 2024-25: 6.8% DB conversion, 65 points (2nd in Ligue 1)

The rolling correlation (bottom right chart) shows the effect of DB conversion is strongest between 30 and 50 points, i.e. mid-table teams. For them, set pieces can make the difference between survival and relegation. But above 65 points, the effect vanishes entirely.

Between groups, the gap is massive: the top 10% DB converters average 16.8 more points than the bottom 10% (p<0.001). But within a given performance group, DB conversion explains nothing.

10. The Marseille paradox: what if improving set pieces changes nothing?

Let’s summarize OM’s situation. Overall conversion of 14.2% (excellent, well above average). Dead ball conversion of 7.6% (poor). Zero goals from indirect free kicks. The diagnosis is clear: a gap in the armor.

But the data also says that for a team of Marseille’s caliber (top 25% in Ligue 1), improving dead ball conversion doesn’t mechanically translate to more points. OM finished 2nd in 2024-25 with one of the worst corner records in L1’s top 15. They’re 3rd in 2025-26 with significantly better efficiency. The table hasn’t shifted proportionally.

If OM scored 3-4 more goals from indirect free kicks this season (which would simply be the Ligue 1 average), it might mean 2-3 extra points. Match scenarios could change too. But is that what closes an 8-point gap to PSG and Lens? Probably not.

The real levers are open play quality, defensive solidity, and not overperforming xPoints by 5 points, which tends to correct over time.

And that’s exactly what Habib Beye says, relayed by @MassiliaZone:

“I value hard work, but situations need to open up beyond just set pieces.”

Marseille’s coach reads it the same way as the data. Set pieces are worth working on (and the staff probably don’t do it enough). But Marseille’s ceiling doesn’t depend on it. Beye knows it, the xG confirms it.

OM should invest more in set pieces, especially free kicks, but the return on investment is likely to be moderate. It’s not the only lever that changes Marseille’s ceiling.

In summary

Set pieces are a bonus, not an engine. Tottenham are on Europe’s corner podium (14 goals, 3rd) and are fighting relegation. Marseille were among Ligue 1’s worst from corners in 2024-25 and finished 2nd. Data from 484 team-seasons confirms it: for good teams, dead ball conversion predicts nothing.

What sets Arsenal or Bayern apart isn’t just being good from set pieces. It’s being good at everything. Set pieces are merely the icing on a cake that needs to exist first. Lens have been ineffective from set pieces since November, but are a deserving and impressive 2nd.

Of course, the 2025-26 sample remains fragile (26-30 matchdays), and some trends (Dortmund’s overperformance, Lens’ collapse, Tottenham’s conversion) could correct by season’s end. The four previous seasons are complete and robust. That’s the whole point of cross-referencing analyses.

You can talk about football with data without betraying the game. Set pieces are a perfect subject: technical enough for numbers to add value, visible enough for everyone to have an opinion. And often, data confirms the intuition of supporters and coaches. For instance, I was convinced Marseille were catastrophic on set pieces. It’s a bit more subtle than I thought. Sometimes, data refines our views.

Data is a starting point, a clue, food for thought, not a final verdict. It doesn’t tell everything, but sometimes pushes you to change or refine a snap judgement. With the democratization of tools and data, we can hope for football debates that are a little less instinct-driven and a little more evidence-based. And why not, more compelling.

Data and source code for this analysis are available on GitHub. All visualizations were generated with Python (matplotlib, soccerdata, scipy). xG data comes from Understat. Monte Carlo simulations for xPoints use 5,000 iterations per match with a Poisson distribution.

The 2025-26 season is not over: current figures reflect ~26-30 matchdays depending on the league. The trends identified are robust, but final standings and some overperformances (Dortmund, Tottenham) may shift. I’ll publish an update at the end of the season to see what held up and what corrected.

Have an opinion, a question, or want to share this article? Want to know how I did it? Contact me at mathieu.acher@irisa.fr

@misc{acher2026cornersfootball,
  author = {Mathieu Acher},
  title = {Corners, Free Kicks, and Set Pieces Across Europe's Top Football Leagues: What the Data Actually Says},
  year = {2026},
  month = {mar},
  howpublished = {\url{https://blog.mathieuacher.com/CornersSetPiecesFootballEN/}},
  note = {\url{https://blog.mathieuacher.com/CornersSetPiecesFootballEN/}}
}

Données : Understat via understatapi. 5 ligues européennes, 5 saisons (2021-2026), 484 équipes-saisons. Note : la saison 2025-26 est en cours (~26-30 journées selon les championnats). Les tendances sont claires mais les chiffres évolueront. Je mettrai à jour en fin de saison.

1. Tottenham, roi des corners… et 16e de Premier League

C’est l’histoire la plus folle de cette saison (en cours, ~30 journées de PL jouées). Tottenham est 3e européen sur les buts marqués sur corners : 14 buts, derrière Arsenal (16) et l’Inter (15). Conversion de 21.5%, la meilleure d’Europe.

Le problème ? Les Spurs sont actuellement 16es de Premier League avec 30 points.

Le graphique est sans appel. Tottenham est isolé en haut à gauche : beaucoup de buts sur corners, très peu en jeu ouvert (25 buts, 14e du championnat). Arsenal, lui, est en haut à droite : 16 buts sur corners ET 39 en jeu ouvert.

35.0% des buts de Tottenham viennent de phases arrêtées. C’est le taux le plus élevé parmi les clubs des grands championnats (hors relégables). Quand plus d’un tiers de tes buts dépendent de situations de jeu qui représentent ~15% des tirs, tu construis sur du sable.

À titre de comparaison, le Bayern Munich, meilleure attaque d’Europe, n’est qu’à 15.6% de dépendance aux CPA. Parce que quand tu marques 65 buts en jeu ouvert, les corners sont un bonus, pas une béquille.

Et puis il y a Arsenal, l’ovni : 16 buts sur corners (1er en Europe), mais également 39 en jeu ouvert, 70 points (1er de Premier League). Arsenal ne se contente pas d’être redoutable offensivement sur CPA, ils le sont aussi dans le jeu. Lors du match de Ligue des Champions contre le Bayer Leverkusen, le compte officiel du Bayer 04 a veinement interdit à Arsenal d’obtenir des corners. Des voies s’élèvent même en Premier League. Dans une interview explosive, John Obi Mikel a carrément accusé Arsenal de tricher ou que le succès d’Arsenal dépend uniquement des corners: https://talksport.com/football/4043546/john-obi-mikel-interview-arsenal-chelsea-mourinho-nigeria/. Tottenham est un parfait contre-exemple : il n’y a pas que les corners… Et on peut aussi penser que Tottenham est en grand danger, car sans les CPA la situation serait encore plus compliquée que la 16ème place.

2. Elche 2022-23 : 107 tirs sur corners, l’anatomie du désespoir

Outre Tottenham en 2025-26, il y a d’autres cas extrêmes : Elche, saison 2022-23, La Liga. L’équipe a été reléguée avec 25 points, et pourtant, elle a tiré 107 fois sur corners, le record de La Liga cette saison-là.

Le z-score est de 2.26, un outlier statistique. Mais le graphique de droite est encore plus parlant : 26.4% de tous les tirs d’Elche venaient de corners. La moyenne de La Liga est à 15.6%. Personne d’autre ne dépasse 19%.

Pourquoi ? Parce qu’Elche ne savait rien faire d’autre. Seulement 406 tirs au total (le plus bas de La Liga), une création en jeu ouvert inexistante. Les corners étaient leur seule route vers le but. Lucas Boyé, leur attaquant de pointe, a tiré 19 fois sur corner à lui seul, un homme-cible qui faisait tout le boulot aérien.

Quand tu ne sais rien faire d’autre, il te reste les corners. Tottenham 2025-26 est une version moins extrême du même syndrome.

Rassurez-vous, je n’ai pas regardé tous les matchs de Elche. En fait, je pense que j’ai dû en regarder à peu près zéro. Mais les statistiques sont assez claires (j’ai regardé également si c’était une anomalie des données ou par exemple un match mal renseigné peut explique ce haut score en corners, mais non, a priori). Ceci dit, je cherche des suiveurs ou mieux supporters de Elche, car c’est un phénomène assez incroyable, et malgré quelques recherches ici et là, je n’ai rien trouvé qui relate cet exploit de Elche.

3. L’OM, de la honte à la renaissance (partielle) sur corners

En novembre 2025, @Rubenzf911 posait la question que beaucoup de supporters marseillais avaient en tête :

“Les CPA de l’OM est-ce qu’un jour on va tirer la sonnette d’alarme svp?”

La sonnette, les données l’ont tirée depuis un moment. Voici l’évolution de Marseille sur 5 saisons :

Le tableau raconte une histoire en trois actes :

Acte 1, La gloire (2022-23) : 17 buts sur CPA (1er de Ligue 1 !), 11 sur corners seuls, 14.9 xG. L’OM surperformait légèrement (+2.1 buts vs xG). Saison à 73 points, la meilleure des 5 années.

Acte 2, La chute (2023-24 et 2024-25) : effondrement à 6 puis 7 buts CPA. Mais attention au xG de 2023-24 : 13.0 xG pour seulement 6 buts (-7.0 de sous-performance). L’OM créait de bonnes occasions sur CPA, il ne les convertissait juste pas. C’était de la malchance autant que de l’inefficacité. La première saison de De Zerbi est d’un certain point de vue une sacré performance : malgré des CPA inefficaces l’OM a quand même fini 2ème.

Acte 3, La remontée (2025-26) : 7 buts CPA, 4e de Ligue 1. Les corners vont mieux (6 buts, 3e en L1). On peut donc se dire que le travail du staff (avec en ligne de mire Pancho Abardonado, apparemment entraîneur en charge des CPA) est inutilement critiqué https://x.com/TeamOM_Officiel/status/2029306295904272504

Mais un trou noir persiste.

4. Le trou noir marseillais : 0 but sur coups francs indirects

Zéro. 21 tirs issus de coups francs indirects cette saison, pas un seul but. Un xG par tir de 0.060, le pire des 6 premiers de Ligue 1. L’OM ne crée même pas de bonnes occasions sur ces phases de jeu.

Regardons Lorient : 10e au classement, 37 points, et pourtant à égalité avec le PSG et Lens sur les buts CPA (10 chacun). Lorient marque 4 buts sur coups francs indirects. L’OM : zéro. Même Metz, dernier de Ligue 1 (13 points), a marqué 3 buts sur CPA hors corners.

La comparaison est cruelle mais pose des questions.

Soyons justes : le travail du staff a clairement amélioré les corners (de 3 buts / 15e en L1 à 6 buts / 3e). Mais les coups francs indirects (rentrées en touche longues, combinaisons sur coups francs excentrés) restent un chantier ouvert. Les xG le confirment : 0.060 par tir sur CF indirects, contre 0.097 sur corners. Il suffirait d’un ou deux buts sur coup franc pour remettre l’OM à niveau me direz-vous… Même pas : L’OM ne crée tout simplement pas de bonnes occasions sur ces phases-là.

5. Bayern Munich : la meilleure attaque d’Europe, point final

Si vous cherchez un modèle, c’est le Bayern. Pas parce qu’ils sont les meilleurs sur CPA (Arsenal et Dortmund font 19 buts CPA contre 14), mais parce qu’ils sont les meilleurs partout en même temps.

C’est le seul club situé en haut à droite de tous les nuages de points : élite en jeu ouvert ET en phases arrêtées. Arsenal est co-leader sur CPA (19 buts, à égalité avec Dortmund) mais relativement modeste en jeu ouvert (1.26 but/match). Barcelone est fort en jeu ouvert mais moyen sur CPA. Inter est bon partout mais à un cran en dessous. Le Bayern n’a aucun angle mort.

Et contrairement à Dortmund ou Tottenham, cette efficacité est soutenue par les xG : 9.8 xG CPA pour 14 buts, une surperformance de +4.2, élevée mais pas délirante.

6. Dortmund : un château de cartes construit sur corners?

Borussia Dortmund est co-leader européen des buts sur phases arrêtées cette saison avec Arsenal : 19 buts (13 corners, 6 coups francs indirects). Impressionnant ? Oui. Durable ? Probablement pas.

Le problème est dans les xG : Dortmund a marqué 19 buts pour seulement 11.8 xG. C’est une surperformance de +7.2, la deuxième plus élevée de tout notre dataset (484 équipes-saisons). La seule saison comparable ? Union Berlin 2022-23, avec +10.5 de surperformance sur CPA. L’année suivante, Union Berlin s’est écroulé.

Mais il y a peut-être un signal d’alarme et une “dépendance” : 34.5% des buts de Dortmund viennent de CPA. Seulement 32 buts en jeu ouvert en 26 matchs, le pire de leur 5 dernières saisons. Les phases arrêtées masquent une attaque en jeu ouvert qui tourne au ralenti. Il reste 8 journées en Bundesliga : la fin de saison dira si cette surperformance tient ou si elle se corrige, comme elle l’a fait historiquement pour d’autres clubs.

7. Lens : la machine à corners qui s’est enrayée en novembre

Lens est 2e de Ligue 1 avec 56 points et leader sur les corners en L1 (10 buts). Mais il y a un avant et un après novembre.

Sur X (ex-Twitter), @Laurentmazure s’agaçait récemment :

“Il faudra aussi, un jour, que les médias et ceux qui commentent les matchs du #RCLens (cc Josse-Bravo) arrêtent de dire que le Racing est “efficace” et toujours “dangereux” sur CPA. C’était le cas jusqu’en novembre. Depuis, Lens n’a marqué que 1 de ses 26 derniers buts sur CPA !”

Et @MechTuyot de renchérir :

“Ah ça… tu marques deux buts en 3 matchs sur cpa, t’es catalogué équipe de cpa pour les 24 mois qui suivent même si tu perds ton tireur et ton mec qui met des têtes… peu importe le championnat et l’équipe.”

Les données leur donnent entièrement raison. Regardez la courbe.

La courbe cumulative est brutale : 9 buts CPA en 14 matchs jusqu’en novembre, puis 1 seul but en 12 matchs depuis. La courbe se fige complètement après le 22 novembre.

Ce n’est pas un problème de volume. Lens continue de tirer (47 tirs CPA depuis décembre). La conversion est passée de 15.5% à 1.9%. Le xG aussi a chuté de moitié. La qualité des occasions s’est dégradée, pas juste la finition. L’observation de @MechTuyot est pertinente : est-ce qu’un tireur ou un “mec qui met des têtes” a été perdu ? Les données ne disent pas qui, mais elles confirment le quand (fin novembre) et l’ampleur (effondrement total). Il sera intéressant de voir si Lens retrouve son efficacité d’ici la fin de saison, ou si le décrochage est structurel.h

Le plus ironique : les commentateurs continuent de vanter les CPA lensoises en mars, alors que ça fait quatre mois que ça ne fonctionne plus. Les réputations survivent longtemps aux faits, et c’est exactement pour ça qu’on a besoin de données. Message de service: les commentaires/analystes/émissions foot, qui cumulent des milliers d’heures, gagneraient à s’appuyer sur de telles données pour alimenter les débats. C’est en tout cas un point de départ intéressant pour de nombreux débats.

8. La Ligue 1, dernière de la classe sur phases arrêtées

Ce n’est pas juste un problème de Marseille ou de tel club. C’est tout le championnat qui est en retard.

La Ligue 1 est dernière sur tout : moins de buts, moins bonne conversion, moins bonne qualité d’occasion (xG/tir). Et l’écart se creuse : en 2021-22, la L1 était à 9.8 buts CPA par équipe, devant la Premier League (9.2). En 2025-26, elle est à 5.3 contre 8.9. Le décrochage est spectaculaire.

Est-ce un problème tactique ? De qualité des tireurs de corners ? De qualité des défenses ? De gabarit des défenseurs/attaquants sur les phases aériennes ? Probablement un peu de tout. Mais les données sont claires : à investissement égal dans les CPA, un club de Ligue 1 en tirera significativement moins qu’un club de Premier League.

9. La conversion sur CPA ne prédit rien pour les grosses équipes

C’est peut-être le résultat le plus contre-intuitif de toute l’analyse. On pourrait penser que les équipes qui convertissent le mieux sur CPA sont les meilleures au classement. C’est vrai… en moyenne. Mais en regardant de plus près, c’est beaucoup plus nuancé.

J’ai découpé les 484 équipes-saisons en quartiles de performance (par points, normalisés au sein de chaque ligue-saison). Voici les corrélations entre conversion CPA et points au sein de chaque tier :

Pour les équipes du top 25%, la conversion CPA est légèrement négativement corrélée avec les points. Autrement dit, parmi les bonnes équipes, mieux convertir les CPA ne te fait pas monter au classement. Ça peut même être le signe d’une sur-dépendance (hello Tottenham).

Les exemples sont parlants :

• Juventus 2024-25 : 2.7% de conversion CPA, 70 points (4e de Serie A)
• Tottenham 2025-26 : 21.5% de conversion CPA, 30 points (16e de PL)
• Marseille 2024-25 : 6.8% de conversion CPA, 65 points (2e de Ligue 1)

La corrélation glissante (graphique en bas à droite) montre que l’effet de la conversion CPA est maximal entre 30 et 50 points :les équipes de milieu de tableau. Pour elles, les phases arrêtées peuvent faire la différence entre le maintien et la relégation. Mais au-delà de 65 points, l’effet disparaît complètement.

Entre les groupes, l’écart est massif : les 10% meilleurs convertisseurs CPA ont en moyenne 16.8 points de plus que les 10% pires (p<0.001). Mais à l’intérieur d’un même groupe de niveau, la conversion CPA n’explique rien.

10. Le paradoxe marseillais : et si améliorer les CPA ne changeait rien ?

Résumons la situation de l’OM. Conversion globale de 14.2% (excellente, bien au-dessus de la moyenne). Conversion CPA de 7.6% (médiocre). Zéro but sur coups francs indirects. Le diagnostic est clair : un trou dans la raquette.

Mais les données disent aussi que pour une équipe du calibre de Marseille (top 25% de Ligue 1), améliorer la conversion CPA ne se traduit pas mécaniquement en points supplémentaires. L’OM est 2e en 2024-25 avec la pire efficacité corners du top 15. Il est 3e en 2025-26 avec une efficacité nettement meilleure. Le classement n’a pas bougé proportionnellement.

Si l’OM marquait 3-4 buts de plus sur coups francs indirects cette saison (ce qui serait simplement la moyenne de Ligue 1), cela ferait peut-être 2-3 points de plus. Des scénarios de match peuvent changer également. Mais est-ce que c’est ça qui comble un écart de 8 points avec le PSG et Lens ? Probablement pas.

Les autres (vraies) leviers, c’est le jeu ouvert, la solidité défensive, et arrêter de surperformer ses xPoints de 5 points, ce qui finit souvent par se corriger.

Et c’est exactement ce que dit Habib Beye, relayé par @MassiliaZone :

“J’accorde beaucoup d’importance au travail mais les situations doivent s’ouvrir aussi sur autre chose que des coups de pieds arrêtés.”

L’entraîneur de l’OM a la même lecture que les données. Les CPA, c’est bien, il faut y travailler (et le staff ne le fait certainement pas assez). Mais le plafond de Marseille ne se joue pas forcément là. Beye le sait, les xG le confirment.

L’OM doit d’avantage investir dans les CPA, surtout les coups francs, mais le “retour sur investissement” risque d’être modéré. Ce n’est pas le seul levier qui change le plafond de Marseille.

En résumé

Les CPA sont un bonus, pas un moteur. Tottenham est sur le podium européen des corners (14 buts, 3e) et lutte pour le maintien. L’OM était un des pires de Ligue 1 sur corners en 2024-25 et a fini 2e. Les données de 484 équipes-saisons le confirment : pour les bonnes équipes, la conversion CPA ne prédit rien.

Ce qui distingue Arsenal ou le Bayern, ce n’est pas uniquement d’être bons sur CPA. C’est d’être bons partout. Les phases arrêtées ne sont qu’une cerise sur un gâteau qui doit d’abord exister. Lens est inefficace depuis novembre sur CPA, mais est un très beau et méritant 2ème.

Bien sûr, sur 2025-26, l’échantillon reste fragile (26-30 journées), et certaines tendances (la surperformance de Dortmund, l’effondrement de Lens, la conversion de Tottenham) pourraient se corriger d’ici la fin de saison. Les quatre saisons précédentes, elles, sont complètes et solides. C’est tout l’intérêt de croiser les analyses.

On peut parler de football avec des données sans trahir le jeu. Les CPA sont un sujet parfait : assez technique pour que les chiffres apportent quelque chose, assez visible pour que tout le monde ait un avis. Et souvent, les données confirment l’intuition des supporters et des coachs ou des “experts”. A titre d’exemple, j’étais persuadé que l’OM était catastrophique sur CPA. C’est un peu plus subtile que ce que je pensais. Aussi, parfois, les données corrigent les avis.

Les données sont un point de départ, un indice, du grain à moudre, pas un jugement final. Elles ne disent pas tout, mais poussent parfois à changer ou raffiner son jugement initial ou un avis tranché. Avec la démocratisation des outils et des données, on peut espérer des débats foot un peu moins à l’instinct et un peu plus étayés. Et pourquoi pas, plus passionnants.

Les données et le code source de cette analyse sont disponibles sur GitHub. Toutes les visualisations ont été générées avec Python (matplotlib, soccerdata, scipy). Les xG proviennent d’Understat. Les simulations Monte Carlo pour les xPoints utilisent 5000 itérations par match avec distribution de Poisson.

La saison 2025-26 n’est pas terminée : les chiffres actuels reflètent ~26-30 journées selon les championnats. Les tendances identifiées sont robustes, mais les classements finaux et certaines surperformances (Dortmund, Tottenham) pourraient évoluer. Je publierai une mise à jour en fin de saison pour voir ce qui a tenu et ce qui s’est corrigé.

Vous avez un avis, une question, envie de partager l’article sur d’autres medium ? Ou simplement savoir comment je m’y suis pris ? Contactez-moi mathieu.acher@irisa.fr

@misc{acher2026cornersfootballfr,
  author = {Mathieu Acher},
  title = {Corners, coups francs, fantasmes et surprises dans les grands championnats européens de football : ce que les données disent vraiment},
  year = {2026},
  month = {mar},
  howpublished = {\url{https://blog.mathieuacher.com/CornersSetPiecesFootball/}},
  note = {\url{https://blog.mathieuacher.com/CornersSetPiecesFootball/}}
}

Again: no training examples, no worked solutions, no hints. Just the README spec and the opcode table. Could an LLM figure out the semantics and produce correct MNM Lang programs?

I gave Claude Code (Claude Opus 4.6) 26 challenges of increasing difficulty, from “sum 1 to N” to “write a Brainfuck interpreter”. No hand-holding, no worked examples beyond the opcode table in the README. The agent had to figure out the language semantics from the spec and produce working programs.

The result: all 26 challenges solved. Including a 1,260-line Brainfuck interpreter.

What MNM Lang Looks Like

Each row is one instruction. The opcode is determined by the color and length of the first token. Operands follow. GGG GG means STORE (3 greens) into variable slot 1 (2 greens, value = length - 1 = 1). That’s the entire encoding: count the candies.

The Challenges

I designed 26 challenges across five difficulty tiers:

Easy (1-10): Sum 1..N, countdown, even/odd, max of two, absolute value, multiplication table, power of two, multiply by addition, integer average, sum of digits.

Easy/Medium (11-20): M&M total counter, most common color, vending machine change, staircase pattern, string length, repeat phrase, palindrome number, Collatz sequence, run-length decoding, mini gradebook (min/max/average).

Hard (21-22): Recursive Fibonacci using CALL/RET, a tiny VM interpreter (meta-interpretation: a VM inside a VM).

Bonus (23-25): M&M histogram, digital clock with carry, Caesar cipher.

Epic (26): A full Brainfuck interpreter.

The agent tackled them in order. Each challenge required reading the spec, understanding the stack semantics (pop order matters!), and producing both a .mnm source file and a .mnm.json sidecar with the right variable layout and input queues.

What Went Wrong (At First)

It wasn’t a clean sweep on the first try. Off-by-one in token encoding (35 R’s instead of 36 for ASCII 35), inverted branch polarity in the palindrome checker, variable slot collisions causing infinite loops, wrong comparison operators exiting one iteration too late. The kind of bugs you’d expect from anyone learning an unfamiliar stack machine with no type checker and no linter.

But the agent self-corrected every time: I pointed out the wrong output, and it re-read the spec, found the bug, and fixed it. The debugging cycle was exactly what a human would do with an unfamiliar language, just faster.

The Brainfuck Interpreter

Challenge 26 is where things got wild. The task: implement a complete Brainfuck interpreter in MNM Lang. All 8 BF operations (> < + - . , [ ]), including nested bracket matching with depth tracking.

The fundamental problem: MNM Lang has no arrays and no indirect addressing. You can LOAD var[3] but you can’t LOAD var[x] where x is computed at runtime. For a BF interpreter, you need random access to both the program (to fetch the current instruction) and the tape (to read/write the current cell).

The solution: comparison chain dispatch. To fetch program[IP], the interpreter does:

# Is IP == 0? Load var[10], return.
# Is IP == 1? Load var[11], return.
# Is IP == 2? Load var[12], return.
# ... (120 cases)

Three subroutines (fetch, tape_load, tape_store), each a linear scan over all possible indices. The fetch subroutine alone is 120 cases. The tape subroutines are 20 each. The whole program is 1,260 lines of MNM source, using 174 labels. It was generated by a Python script (generate.py) that the agent also wrote.

And it works. Here’s what it looks like as candy:

The M&M histogram challenge (53 lines), which prints horizontal bar charts of candy counts. The Brainfuck interpreter is 1,260 lines of this.

Cross-Validation

To verify the Brainfuck interpreter actually works, I co-developed with the agent a cross-validation test suite (tests/test_brainfuck.py). I pushed it toward this testing style: every BF program runs through both a reference Python BF interpreter and the MNM BF interpreter, and we assert identical output. Writing correct Brainfuck programs is itself non-trivial (especially with unbounded integers instead of wrapping cells), so several BF test programs needed debugging too. 39 test cases across multiple categories:

The Hello World BF program runs through the MNM interpreter in ~1.4 seconds and 1.6 million steps. It produces the correct 13 ASCII values: 72 101 108 108 111 32 87 111 114 108 100 33 10 (Hello World! plus newline).

The Fibonacci BF program, itself running inside the MNM BF interpreter, correctly outputs [1, 1, 2, 3, 5, 8, 13] for N=7. That’s a Fibonacci computation running inside a Brainfuck program running inside an MNM Lang interpreter. Three levels of interpretation.

What This Tells Us

MNM Lang is a good test for coding agents for a few reasons:

Unfamiliar territory. There are essentially zero MNM Lang programs in any training corpus. The agent can’t pattern-match against memorized solutions. It has to actually reason about the language specification.

Hostile encoding. The token-length-as-value scheme means you can’t eyeball correctness. Is GGGGGGG a DEC instruction or a 6-green operand? Context matters, and off-by-one errors are invisible until runtime.

No safety net. No type checker, no linter, no error messages beyond “wrong output” or “step limit exceeded”. Debugging requires mentally tracing a stack machine, which the agent did successfully.

Scaling test. The jump from challenge 1 (10 lines) to challenge 26 (1,260 lines) is two orders of magnitude. The agent needed to invent architectural patterns (comparison chain dispatch, generated subroutines) that aren’t in any MNM Lang tutorial because there are no MNM Lang tutorials. And the approach of generating MNM programs via a Python script was a practical engineering decision the agent made on its own.

This is similar in spirit to what I observed with Printf-Oriented Programming and a chess engine written in LaTeX. Coding agents can master unfamiliar paradigms, even absurd ones like encoding game logic inside \expandafter chains or printf format strings. But the really interesting question is how far they can scale. With POP, the agents hit a wall at chess-level complexity. With LaTeX, the agent produced a playable chess engine but needed extensive macro plumbing that pushed TeX to its limits. With MNM Lang, the agent pushed through to a working Brainfuck interpreter, but needed a code generator to manage the complexity. The pattern is consistent: agents handle novel paradigms well at small scale, and find creative workarounds (compilers, generators, meta-programming) when direct coding becomes intractable.

Try It Yourself

The fork with all 26 challenges is at github.com/acherm/mnmlang. Each challenge has a .mnm source and sidecar JSON. Run any of them with:

uv run mnm run challenges/01_sum_1_to_n/sum.mnm
uv run mnm run challenges/26_brainfuck/bf.mnm

The cross-validation test suite:

uv run --extra dev pytest tests/test_brainfuck.py -v

@misc{acher2026mnmlang,
  author = {Mathieu Acher},
  title = {Can Coding Agents Program in M&Ms Language?},
  year = {2026},
  month = {mar},
  howpublished = {\url{https://blog.mathieuacher.com/CodingAgentsMnMLang/}},
  note = {\url{https://blog.mathieuacher.com/CodingAgentsMnMLang/}}
}

Printf-Oriented Programming

Printf-oriented programming (POP) is a brilliant paradigm invented by Nicholas Carlini for the IOCCC 2020. The idea is to encode program behavior inside printf’s format string and arguments. Using specifiers like %hhn to write the number of printed bytes to memory, together with positional parameters and dynamic width/precision modifiers (e.g., %2$d, %3$.4$d), the format string updates state and drives the program’s execution. One printf invocation becomes a tiny virtual machine. Carlini demonstrated this with printf-tac-toe: a fully playable tic-tac-toe where printf *is the execution engine, not just the renderer.

Can we go beyond tic-tac-toe? Can we scale POP to chess? Can coding agents master this esoteric paradigm? I gave the challenge to two agents:

• Claude Code (Claude Opus 4.6)
• Codex CLI (GPT-5.2)

Act 1: The Illusion of Success

First impressions were exciting. Both agents produced working chess programs with the signature POP loop:

int main(void) {
    while (*d) printf(fmt, arg);
}

Claude Code’s version (~14 KB) chains side-effect calls in the arg macro. Codex’s version (~31 KB) uses eight pop_a* functions with %hhn directives. Both compile, both play chess, both handle legal move validation, check/checkmate/stalemate. I was ready to write a triumphant blog post about how coding agents had conquered POP.

Then I looked more carefully.

The chess logic (move generation, legal filtering, check detection, AI) was implemented in conventional C helper functions (~400 lines of if, switch, for, while). These helpers run as side effects during argument evaluation, before printf ever touches the format string. The format string itself mostly just renders pre-computed buffers via %s. The while(*d) printf(...) loop is there, sure, but the spirit of POP (having printf act as the execution engine, performing state transitions through format specifiers) was largely absent. It’s like claiming you wrote a program in assembly while actually calling a high-level library for everything interesting. The structure is POP-shaped. The substance is C with printf as a display layer.

Act 2: Trying to Force POP Purity

So I pushed back. I asked the agents to use real POP techniques: %hhn for state mutation, %.*s for conditional branching, format-string-driven control flow. I gave detailed feedback, pointed at Carlini’s techniques, explained what was and wasn’t POP-pure.

It didn’t go well.

The agents would acknowledge my feedback, propose elaborate plans, and then… produce code that was still fundamentally C-with-a-printf-wrapper. Sometimes they’d move one thing into the format string (say, loop termination via %hhn) while keeping everything else in conventional C. Other times they’d spend hours designing complex architectures that simply didn’t compile. Claude Code’s attempt to “print all legal moves using only printf logics” was, in its own way, a spectacular failure.

I started with ad-hoc review criteria, then converged to a formal POP purity checklist to make feedback precise and repeatable. Five dimensions, each scored 0-2:

This rubric is an operational audit, not a formal proof of semantic purity.

Score 9-10: POP-pure. Score 6-8: hybrid. Below 6: POP-shaped at best. My manual estimate for both chess implementations? Around 4-5. Hybrid at best, and that’s being generous.

Act 3: Scaling Down

Chess was clearly too ambitious for strict POP. I took a step back. What about tic-tac-toe itself, not copying Carlini’s, but having the agent write one from scratch in the POP style?

Still difficult. The agents could produce working tic-tac-toe programs, but achieving POP purity required iteration after iteration. Each version got a little closer: first basic display, then input handling, then playability with comparisons (hybrid mode), and finally (after much steering) a version using only bitwise operations (no comparisons!) to detect wins, draws, and quit. That last version is genuinely impressive: it implements win detection via 8-way AND/OR checks over nibble bitmasks, all without a single <, >, or ==. But it took a lot of human guidance to get there.

The checklist evolved along the way. I refined it into a set of antipatterns and violations: per-iteration helper calls, C-side semantic operators, host-driven state snapshots, C-side expression evaluation where the format string should do the work. And here’s where it got interesting: the coding agent could operationalize this checklist as an automated scoring script. The same agent that struggled to write POP-pure code could write a tool to evaluate POP purity. Easier to be a critic than an artist, apparently.

Act 4: The Compiler Idea

At some point during the back-and-forth, I had a realization: if coding agents can’t reliably intuit how to write POP, maybe they can build a deterministic translator: a compiler from a restricted C subset to POP. Clear rules, no creativity required in the output. You write your logic in a constrained source language, and the compiler mechanically transforms it into printf-driven code.

Codex ran with this idea and produced c2pop.py, now roughly a ~2,700-line Python compiler. The input language (called “CPOP subset”) supports a tape (d[N]), one canonical loop (while (d[0]) { ... }), assignments, reads, prints, and conditionals. The compiler offers four backends with different tradeoffs (not a strict purity ladder):

• simple: straightforward lowering; often hybrid when expressions are still evaluated in C
• micro: single-call printf lowering for selected boolean forms (experimental)
• phase: multi-phase dispatcher, one source statement per phase (explicitly hybrid)
• vm: VM backend with %hhn-driven phase state and format-pointer updates; highest-purity path for supported forms

Each generated file gets an automatic purity score and a “cheat audit” listing any POP violations. For supported programs, the vm-pure vm backend can report 10/10 POP-pure output, especially when host-snapshot input is avoided.

The tradeoff? The generated POP code is very long. A 20-line CPOP source can produce hundreds of lines of format string gymnastics. In practice, strict generated examples are strongest on tic-tac-toe/snake-scale programs; for chess-scale behavior, what remains POP-pure is closer to a state displayer driven by a POP byte-VM than a full engine: you lose the AI, the legal move generation, all the things that make chess interesting. The scope reduction required for POP purity is dramatic.

A Confession

For the Codex branch documented here, the core iterations happened quickly: from March 3, 2026 to March 5, 2026. Throughout this post, I’m quite demanding about what should count as “real” POP, what’s acceptable and what’s not. But I should be honest: I am not a POP expert. I can spot violations, I can articulate what feels wrong, but I often have no concrete idea how to fix the issues myself. I’m a critic without a solution, relying on coding agents to figure out the “how” while I insist on the “what”. That tension runs through the entire experiment. This is also very much a work in progress, or perhaps a work in “lambo”: I’m reflecting on where I am, where the coding agents are, and what’s still missing. It’s genuinely unfinished.

Can You Do Better?

I’m pretty sure someone can. Either from scratch (without a coding agent, just raw POP expertise and patience) or with a coding agent but with better prompting, better domain knowledge, or a smarter iterative strategy than mine. I would be genuinely interested to know: what level of detail and instructions would it take to realize the vision of a POP-pure chess engine? How much POP expertise does a human need to bring? How much can the agent figure out on its own if guided differently?

I’m expecting someone will do it. If you do, please let me know.

What’s Still Open (A Lot)

This is ongoing work (really: unfinished work), and many directions remain:

• POP skills: Can we teach coding agents POP as a first-class skill, perhaps through few-shot examples or fine-tuning?
• POP harness: A systematic test suite for POP compliance, beyond the current checklist
• A better compiler: c2pop.py works but the output is verbose; can we optimize the generated format strings?
• Formalizing POP: What is POP, precisely? What’s the grammar of valid POP programs? What subset of computation can POP express efficiently? There’s a real PL theory question hiding here.
• POP for other games: Scaling beyond tic-tac-toe toward more complex programs while maintaining purity
• Other sources of information: There is a Brainfuck interpreter implemented in POP https://github.com/HexHive/printbf. Maybe a coding agent could learn POP by studying that code, or by learning Brainfuck first and then translating to POP.

Repositories:

• Claude Code version: https://github.com/acherm/printf-chess
• Codex version (with compiler, benchmarks, examples): https://github.com/acherm/printf-chess-codex

Why POP Matters as a Benchmark

Beyond the fun of it, I think POP is a fantastic benchmark for coding agents, and here is one of the central messages of this post.

Most coding benchmarks test whether an agent can produce correct, working code. POP tests something deeper: can the agent understand a non-trivial programming paradigm from a single example, grasp its underlying principles (not just its surface structure), and creatively apply them to new problems?

The results are humbling. Coding agents in 2026 can build chess engines from scratch in 12 languages, including LaTeX, COBOL, and Brainfuck. But when asked to encode logic inside a format string, they default to what they know: conventional C with a POP-shaped wrapper. They can mimic the structure without grasping the essence. Getting from “it looks like POP” to “it is POP” required extensive human guidance, a formalized checklist, and ultimately a compiler to do the translation mechanically.

That gap between surface imitation and deep understanding is exactly what makes POP a useful probe. It tests creativity, adaptability, and mastery of programming languages and compilers in a “strange” zone where standard training data won’t help much. And the fact that the journey led to automated scoring tools, a formal purity rubric, and a C-to-POP compiler is, in its own way, a success story. Just not the one I expected to write.

As I said: this is unfinished. I don’t know yet whether a POP-pure chess engine is achievable with current coding agents, or whether it requires a fundamentally different approach. But the exploration itself has been worth it, and I’ll keep pushing. Hopefully someone else will too.

@misc{acher2026printfchess,
  author = {Mathieu Acher},
  title = {Can Coding Agents Master Printf-Oriented Programming?},
  year = {2026},
  month = {mar},
  howpublished = {\url{https://blog.mathieuacher.com/PrintfOrientedProgrammingCodingAgents/}},
  note = {\url{https://blog.mathieuacher.com/PrintfOrientedProgrammingCodingAgents/}}
}

Motivation

Among all the engines produced in my experiment of asking coding agents to build chess engines from scratch across 12 programming languages, TeXCCChess is perhaps the most surprising and delightful. It is a chess engine written entirely in TeX (the macro language behind LaTeX) and it runs on pdflatex. Yes, LaTeX is usually used for writing reports or scientific papers, not at all for writing chess engines. Between, why TeX? The honest answer: because it shouldn’t work and has never been done before. TeX has no arrays, no functions with return values, no convenient local variables or stack frames, no integers bigger than 2^{31}-1, no bitwise operations. Macro expansion can recurse, but you get no call stack and deep recursion quickly hits engine limits. What TeX does have is a Turing-complete macro expansion engine and, with e-TeX extensions (used by modern pdfTeX), up to 32,768 integer registers called \count. That turns out to be just barely enough to implement a chess engine. I could not find any prior chess engine in TeX (I searched CTAN, GitHub, and TeX Stack Exchange). There exist LaTeX packages for rendering chess positions and games (the excellent chessboard and xskak packages), but nothing that actually plays chess. TeXCCChess appears to be the first.

If this is indeed the first full TeX chess engine, it is very unlikely the model memorized one verbatim. That makes TeXCCChess a useful counterpoint to the plausible critique that “coding agents just regurgitate training data”. Of course, the model may have seen discussions about chess programming in TeX, or small macro-expansion tricks, but a full working engine is a different artifact. (We will see in other posts that for engines in more mainstream languages, the pure memorization hypothesis is also questionable given the diversity of architectures and features, but here it is even more so).

TeXCCChess was built by Claude Code, Anthropic’s agentic coding tool, powered by Claude Opus 4.6. The “CC” in the name stands for Claude Code (and if you squint, an allusion to the Chaos Computer Club). A second variant was independently built by Codex CLI (powered by GPT-5.2), but it is out of the scope of this post (I will cover it in a future post, along with engines in other languages).

The challenge I gave Claude Code was deliberately vague: I want to build a chess engine in LaTeX… at the end, I want to test this chess engine and assess its Elo rating, typically by playing games against chess engines of “similar” levels. I did not specify the architecture, the search algorithm, or the data structures. The agent made all those decisions itself, discovered the TeX pitfalls the hard way, and iteratively debugged its own code across multiple sessions.

The Architecture at a Glance

The engine is ~2,100 lines of pure TeX code in a single file (chess-engine.tex). Everything happens during pdflatex compilation. Here is the high-level architecture:

• Board representation: 64 TeX \count registers (\count200 through \count263)
• Piece encoding: integers from -6 to +6 (positive = white, negative = black, 0 = empty)
• Move generation: pseudo-legal generation + legality filtering via make/unmake
• Search: depth-3 negamax with alpha-beta pruning + quiescence search
• Evaluation: material counting + piece-square tables (Simplified Eval Function)
• UCI support: a thin Python wrapper bridges pdflatex to the UCI protocol

What emerges from this design is something resembling a tiny virtual machine built on top of TeX’s macro expansion engine. The \count registers serve as RAM (with dedicated address ranges for the board (200-263), scratch computation (188-194), and the search call stack (10000+)). The \csname lookup tables act as a read-only ROM for precomputed data (file/rank mappings, piece-square tables, material values). Token lists (\movelist, \legalmovelist) serve as dynamically allocated buffers. Macros like \makemove/\unmakemove and \pushstate/\popstate are the instruction set. TeX’s \ifnum and \loop primitives provide the control flow. The whole thing is a register machine with no stack frames, no heap, and no garbage collector (just flat integer registers and name-based indirection). pdflatex is, in effect, the CPU executing this VM.

The following diagram (generated by Codex during a code exploration session) shows how the components of this tiny VM connect (from the TeX macros through memory registers to the UCI bridge):

(Mermaid source)

And here is the full game flow (from the moment you call \playmove{e2e4} to the engine’s response). It shows move parsing, pseudo-legal generation with piece-specific dispatchers, legality filtering via make/unmake + attack detection, and the search tree (depth-3 negamax cascading through searchB, searchC, and quiescence):

(Mermaid source)

Board Representation: 64 Count Registers

In most languages, you’d use an array. In TeX, you use \count registers. The board occupies registers 200 through 263, one per square:

% Square index: (rank-1)*8 + file, where file a=1..h=8, rank 1..8
% So a1=1, b1=2, ..., h1=8, a2=9, ..., h8=64
% Stored in \count registers 200..263

\def\setsq#1#2{\global\count\numexpr199+#1\relax=#2\relax}
\def\getsq#1{\the\count\numexpr199+#1\relax}

Pieces are encoded as signed integers:

Setting up the starting position is just a series of register assignments:

\def\initboard{%
  % Clear all squares
  \count190=1\relax
  \loop\ifnum\count190<65
    \setsq{\the\count190}{0}%
    \advance\count190 by 1
  \repeat
  % White pieces (rank 1)
  \setsq{1}{4}%  a1 = wR
  \setsq{2}{2}%  b1 = wN
  \setsq{3}{3}%  c1 = wB
  \setsq{4}{5}%  d1 = wQ
  \setsq{5}{6}%  e1 = wK
  ...
}

A critical design decision is how to extract the file and rank from a square index. In most languages, you’d write file = (sq - 1) % 8 + 1 and rank = (sq - 1) / 8 + 1. But TeX’s \numexpr division rounds instead of truncating: 63/8 gives 8 (rounding 7.875 up), not 7. This was the source of one of the first nasty bugs. The fix: precompute lookup tables at load time using \divide (which truncates) and store results in \csname control sequences:

\count190=1\relax
\loop\ifnum\count190<65
  \count191=\count190\relax \advance\count191 by -1\relax % 0-based index
  \count192=\count191\relax \divide\count192 by 8\relax   % rank 0-based (TRUNCATING)
  ...
  \advance\count192 by 1\relax % rank 1-based (1..8)
  \advance\count194 by 1\relax % file 1-based (1..8)
  \expandafter\edef\csname sq@file@\the\count190\endcsname{\the\count194}%
  \expandafter\edef\csname sq@rank@\the\count190\endcsname{\the\count192}%
  \advance\count190 by 1\relax
\repeat

This pattern (precompute into \csname tables at load time, look up by name expansion at runtime) is used throughout the engine. It is the TeX equivalent of a hash map.

Move Generation

Move generation follows the standard pseudo-legal approach: generate all possible moves, then filter out those that leave the king in check.

Each piece type has its own generator macro. For sliding pieces (bishop, rook, queen), ray-casting is done via recursive macro expansion along each direction, stopping when hitting a piece or the edge of the board. For knights, all 8 L-shaped jumps are checked with boundary validation. Pawns have the most complex logic: single pushes, double pushes from the starting rank, diagonal captures, en passant, and promotion.

Moves are stored in a TeX token list as \moveentry{from}{to}{flags}, where flags encode special moves:

Legal move filtering works by making each pseudo-legal move on the board, checking if the king is attacked, then unmaking the move. Castling gets special treatment: three squares must be checked (the king’s origin, transit square, and destination) since the king cannot castle out of, through, or into check:

\def\fl@testcastling#1#2#3{%
  % King must not be in check now
  \findkingsquare{\the\sidetomove}%
  \issquareattacked{\the\kingsquare}{\the\fl@oppcolor}%
  \ifnum\attackresult=1 \fl@legal=0\relax \fi
  \ifnum\fl@legal=1
    % Transit square must not be attacked
    \ifnum#2>#1 \fl@transit=\numexpr#1+1\relax
    \else \fl@transit=\numexpr#1-1\relax \fi
    \issquareattacked{\the\fl@transit}{\the\fl@oppcolor}%
    \ifnum\attackresult=1 \fl@legal=0\relax \fi
  \fi
  ...
}

The State Stack Problem

A chess engine needs to make a move, search deeper, then unmake the move. In a normal language, local variables or a call stack handle this naturally. TeX has grouping-based scoping, but the engine’s design uses global state throughout (every \count register, every \newcount variable, every \newif flag is global).

The solution: a hand-rolled state stack using high-numbered \count registers (starting at \count10000) to avoid collisions with the \newcount allocator. Each search depth gets 9 register slots to save and restore the full game state:

% Depth 0: \count10000-\count10008
% Depth 1: \count10009-\count10017
% Depth 2: \count10018-\count10026
% Depth 3: \count10027-\count10035

\def\pushstate#1{%
  \count\numexpr10000+9*#1+0\relax=\save@captured\relax
  \count\numexpr10000+9*#1+1\relax=\save@castleWK\relax
  \count\numexpr10000+9*#1+2\relax=\save@castleWQ\relax
  ...
}

The ordering is critical and was a source of subtle bugs: \pushstate must be called after \makemove (which populates the \save@* registers) but before \updategamestate (which modifies them). Reverse for unmake: \popstate first, then \unmakemove. Getting this wrong produces moves that look almost right but occasionally corrupt castling rights or en passant state (the kind of bug that shows up once every 50 games).

Search: Depth-3 Negamax with Alpha-Beta

TeX can recurse via macro expansion, but there is no call stack, no local variables, and deep recursion risks hitting engine limits. So the search uses three explicit loop levels, one for each depth:

• loopA (depth 0): iterates over our candidate moves
• loopB (depth 1): iterates over the opponent’s replies
• loopC (depth 2): iterates over our counter-replies, capped at 12 moves for speed

Each depth level stores its moves in separate indexed \csname slots (mm@0@mf@N, mm@1@mf@N, mm@2@mf@N) because the inner search clobbers the global move-tracking variables. After returning from an inner search, the current move must be re-read from its csname storage:

\def\mm@loopA{%
  \ifnum\mm@idx>\mm@total\else
    \mm@curfrom=\csname mm@0@mf@\the\mm@idx\endcsname\relax
    ...
    \mm@searchB  % inner search clobbers mm@curfrom etc.
    \mm@score=-\mm@retval\relax
    % Re-read move (inner search clobbers curfrom/curto/curflags)
    \mm@curfrom=\csname mm@0@mf@\the\mm@idx\endcsname\relax
    \mm@curto=\csname mm@0@mt@\the\mm@idx\endcsname\relax
    ...
}

Alpha-beta pruning is implemented using \ifnum comparisons. The >= operator (for cutoff: alpha >= beta) requires a TeX idiom since there is no \ifge primitive:

\ifnum\mm@alphaB<\mm@betaB\relax\else
  \mm@cutoffBtrue   % alpha >= beta, prune
\fi

Each depth level has its own cutoff flag (\ifmm@cutoffB, \ifmm@cutoffC, \ifmm@qcutoff), which are TeX booleans declared with \newif at the top level (declaring them inside a macro causes a “already defined” error on the second call).

Move Ordering

Good alpha-beta depends on examining the best moves first. The engine uses a 4-pass MVV-LVA (Most Valuable Victim - Least Valuable Attacker) ordering:

1. Promotions + captures of queens/rooks
2. Captures of bishops/knights
3. Captures of pawns + en passant
4. Quiet moves

This is implemented by iterating the legal move list four times, each time extracting moves matching the current priority level. At depth C (the deepest full-width level), the move list is capped at 12 (since captures are sorted first, all captures are always searched even under the cap).

Quiescence Search

At the leaves of the depth-3 search, a quiescence search extends the analysis for captures only. This prevents the horizon effect (e.g., stopping evaluation right after we hang a piece but before the opponent recaptures):

\def\mm@quiesce{%
  \evaluate
  \mm@standpat=\evalscore\relax
  \ifnum\mm@standpat<\mm@qbeta\relax
    \ifnum\mm@standpat>\mm@qalpha\relax
      \mm@qalpha=\mm@standpat\relax
    \fi
    \generatelegal
    \mm@copycapturesonly
    ...
  \else
    \global\mm@retval=\mm@qbeta\relax  % stand-pat cutoff
  \fi
}

Evaluation

The evaluation function scans all 64 squares and sums material values plus piece-square table (PST) bonuses. The PSTs follow the well-known Simplified Evaluation Function from the Chess Programming Wiki: pawns are rewarded for advancing toward the center, knights prefer central squares, kings prefer the corners in the middlegame, etc.

\expandafter\def\csname piecemat@1\endcsname{100}%  pawn
\expandafter\def\csname piecemat@2\endcsname{320}%  knight
\expandafter\def\csname piecemat@3\endcsname{330}%  bishop
\expandafter\def\csname piecemat@4\endcsname{500}%  rook
\expandafter\def\csname piecemat@5\endcsname{900}%  queen
\expandafter\def\csname piecemat@6\endcsname{20000}% king

For black pieces, the PST is accessed via a mirror table (sq@mirror@N) that flips the board vertically, so the same white-perspective tables work for both sides.

The evaluation is computed from scratch on every call (no incremental updates). This is slow, but incrementality would require tracking piece-list data structures that are painful to manage in TeX’s global-state model.

TeX-Specific Pitfalls

Building a chess engine in TeX surfaced a collection of language-specific traps that Claude Code had to discover and work around:

\numexpr division rounds, it does not truncate. \numexpr 63/8\relax gives 8, not 7. This broke coordinate extraction (file/rank from square index) until the fix: use \divide with a register (which truncates), or precompute into lookup tables.

Digits in a normal control sequence name are not part of the name. \ray@t1 is parsed as \ray@t followed by the digit 1, not a single control sequence \ray@t1. (You can include digits via \csname ray@t1\endcsname, but \def doesn’t work that way.) Solution: use letters instead of digits (\ray@ta, \ray@tb).

The @ character in macro names requires \makeatletter. All internal macros use @ in their names (e.g., \eval@sq, \mm@alpha). Without \makeatletter, TeX treats @ as a regular character and the macros silently fail.

\newif inside macros fails on the second call. Since \newif creates a global flag, calling it again raises “already defined”. All boolean flags must be declared once at the global level.

Register collision is the TeX equivalent of variable shadowing bugs. Since everything is global, a macro that uses \count190 as a loop counter will silently corrupt any outer macro also using \count190. The engine reserves specific register ranges for specific purposes: 200-263 for the board, 188-194 for scratch math, 10000+ for the search state stack.

Playing Against TeXCCChess

The source code, instructions, and all tooling are available on GitHub: acherm/agentic-chessengine-latex-TeXCCChess. You can play interactively by editing a .tex file and recompiling with pdflatex (works locally and on Overleaf), or run automated Elo tournaments against Stockfish via the UCI wrapper. The README covers everything: setup, interactive play, UCI mode, and tournament scripts.

Here is a demo of an interactive game against TeXCCChess in Overleaf (note: depth > 0 may take too much time for Overleaf’s limits, so the engine is set to depth default=0 for this demo):

And here is a demo of an interactive game against TeXCCChess in local (here the engine is set to depth=3 negamax + quiescence):

Strength and Elo

Estimated strength: ~1280 Elo (95% CI: ~1225–1345, measured against Stockfish at 120+1 time control, CCRL 40/4 scale).

All matches used Stockfish with UCI_LimitStrength=true at the 120+1s time control, which is the time control Stockfish’s UCI_Elo scale was calibrated against (anchored to CCRL 40/4). Test conditions: no opening book, single-threaded, on an Apple M3 Max. All game records (PGN) are available on GitHub.

Evaluation details

A 100-game baseline against Stockfish set to 1320 Elo gave 45 wins, 7 draws, 48 losses (48.5% score, estimated Elo ~1310). An extended evaluation (3 x 50 games against Stockfish at 1320, 1400, and 1500 Elo) produced a combined estimate of ~1260 Elo. A small number of games ended due to UCI protocol issues (illegal moves); after removing those, the estimate stabilizes at ~1285 Elo (95% CI: ~1225–1345).

Overall, the engine performs around 1280–1300 Elo at 120+1. For reference, this is roughly the level of a casual tournament player who has studied some openings and does not hang pieces in obvious ways. The engine loses convincingly to Stockfish above 1500.

The main limitations are:

• Search depth: capped at 3 plies + quiescence. Deeper search would require either much faster execution (highly challenging in TeX) or a time budget of minutes per move.
• No opening book: the engine starts from scratch every game.
• Simplified evaluation: material + PSTs only; no pawn structure, king safety, or mobility terms.
• Always promotes to queen: no under-promotion.

The Development Process: 5 Sessions, 10 Days

The entire development of TeXCCChess is traceable through 5 Claude Code sessions spanning 10 days (Feb 13-23, 2026). It started with a single sentence: “I want to implement a chess engine in LaTeX… and have the ability to play with this engine.” Here is what happened, session by session.

Session 1: The Plan

Claude Code entered plan mode and designed a 17-step implementation across 4 files. No code was written yet, just the architecture: \count registers for the board, signed integers for pieces, token lists for moves, a test suite to validate correctness. 19 API calls.

Session 2: Building the Random-Move Engine

The agent implemented the full plan in one session: board representation, move generation for all piece types (including castling, en passant, promotion), legal move filtering, attack detection, game-end detection, and a random move picker. 122 API calls.

The first compilation of the test suite: 3 PASS, 6 FAIL. The culprit: sqfile(64) returned 0 instead of 8. The \numexpr rounding bug (63/8 gives 8 in TeX, not 7) had silently corrupted every file/rank extraction. The agent rewrote coordinate math using precomputed lookup tables. After the fix: all 23 tests pass.

A notable design decision: the agent chose hash-based RNG seeding for Overleaf compatibility. Rather than writing state to auxiliary files (which Overleaf doesn’t support well), the engine hashes all prior user moves to create a deterministic seed. This means recompiling the same .tex file always produces the same game.

I confirmed: “working fine!” on Overleaf after testing.

Session 3: UCI & Elo Infrastructure

To measure Elo, the engine needed to speak the UCI protocol. The agent created chess-uci.py (the Python wrapper), run-elo-test.sh (tournament orchestration), and pgn2latex.py (PGN-to-LaTeX converter for game visualization). 140 API calls.

A tricky bug: cutechess-cli outputs Standard Algebraic Notation (SAN: Nf3, O-O, exd5) but the PGN parser only handled coordinate notation (g1f3). The agent had to build a full SAN resolver (disambiguating moves by file or rank, handling castling variants (O-O vs 0-0), stripping check/mate annotations).

Session 4: Depth-2 Minimax

The random-move engine was replaced by a depth-2 minimax with material evaluation. 157 API calls.

This session exposed the most insidious bug of the project: register collision. LaTeX’s \newcount allocator had already reached register 360+, so the state stack at \count300-317 overlapped with LaTeX-internal registers. The symptom was subtle: the minimax search appeared to work but produced wrong moves. The agent traced it to a corrupted board value (square 17 showing value 8 instead of the expected piece), identified the collision, and moved the entire state stack to \count10000+.

First Elo test: 10 games vs Stockfish 800, result: 1 win, 0 draws, 9 losses (~500-600 Elo). The agent noted: “depth-2 only takes 0.16 seconds, there’s a massive time budget remaining.”

Session 5: The Big Push (PSTs, Alpha-Beta, Depth-3, Quiescence)

This was the largest and most dramatic session: 2,650 lines of conversation, 212 API calls, 19 edits to chess-engine.tex, 8 test suite runs, 5 tournament attempts.

The session hit two API errors early on: “Claude’s response exceeded the 32000 output token maximum” (the agent tried to write the entire PST + search implementation in one go). Recovery: “I’ll break this into smaller steps.”

The Elo progression within this single session tells the story:

The initial depth-3 implementation was a disaster: move 3 took 30 seconds in complex positions, hitting the UCI timeout. Games ended with “illegal move: 0000” (the timeout fallback). The agent spent over 30 turns debugging (fixing alpha-beta cutoffs (the TeX idiom for >= is \ifnum X < Y \relax\else, since there is no \ifge primitive), then pragmatically capping depth-C at 12 moves). Since MVV-LVA sorts captures first, all tactical moves are always searched even under the cap. Timing dropped to 0.5-3.5s per move.

Then a measurement bug: the agent set UCI_Elo: 800 for Stockfish, but recent Stockfish versions enforce a minimum UCI_Elo around 1300-1350 (the exact floor depends on version and build) and silently clamp values below it. The “5.5/10 vs Stockfish 800” result was actually against a much stronger opponent. After correcting the configuration (verified by inspecting Stockfish’s uci option output), a preliminary 100-game tournament vs Stockfish 1320 confirmed the engine was in the ~1280 Elo range. A more rigorous evaluation using the Stockfish UCI_Elo calibration time control (120+1s) is reported in the Strength and Elo section above.

Effort Summary

In total: 5 sessions, ~650 API calls, ~53 pdflatex compilations, ~22 test suite runs. The engine grew from 0 to 1,342 lines (random moves) to 2,093 lines (depth-3 + quiescence), and from ~300 Elo to ~1280 Elo. Session 5 (the “big push” to depth-3 with quiescence) consumed the most resources (38% of the total), reflecting the difficulty of getting search, pruning, and move ordering right in TeX. The initial implementation (session 2) was the second largest at 24%, which makes sense: building a full rule-compliant chess engine from scratch is the foundational effort.

Elo Progression

~1000 Elo gained from better search and evaluation (a massive improvement from pure TeX macro optimization, all discovered and implemented by the coding agent).

What Makes TeXCCChess Remarkable

1. It exists. As far as I can tell, there is no prior chess engine in TeX. A coding agent synthesized one from scratch, with no known example to draw from.
2. It plays legal chess (with high confidence). Castling, en passant, promotion, check detection, stalemate, and the 50-move rule are implemented and validated with a 23-case test suite (though not all rules have exhaustive coverage). Threefold repetition and insufficient-material draws are not yet implemented. Beyond unit tests, the engine completed hundreds of tournament games against Stockfish; in rare occasions, an illegal move or protocol error occurred, though it is unclear whether these stem from the TeX engine logic or from the UCI wrapper. This gives reasonable confidence that the core move generation and rule handling are robust, if not formally verified.
3. It thinks. Three plies of lookahead with alpha-beta pruning and quiescence search, using only TeX macro expansion and integer registers.
4. It is entirely self-contained. The core engine is a single .tex file. No shell-escape, no LuaTeX, no external computation.
5. It produces a typeset PDF. You play by editing a .tex file and compiling with pdflatex. The output is a beautifully typeset chess document (because, after all, it’s still TeX running inside the LaTeX ecosystem).
6. It is neither a translation nor a copy of an existing chess engine. There is no existing TeX chess engine to copy from, and you cannot mechanically translate a C or Java engine into TeX (no arrays, no conventional recursion with a call stack, no convenient local variables). The underlying algorithms are well-known (alpha-beta, quiescence, MVV-LVA, PSTs); if there is a “translation”, it happens at this abstraction level. The creativity lies in finding TeX-native ways to encode them: register-based state stacks, csname lookup tables, explicit loop unrolling for search depth.

The complete source code and Elo assessment infrastructure are available at github.com/acherm/agentic-chessengine-latex-TeXCCChess.

This is part of a series on AI-generated chess engines across programming languages. The next post will cover another engine from the polyglot experiment. Stay tuned.

Feel free to contact me: mathieu.acher@irisa.fr

(new!) I realized that some of my blog post entries are sometimes cited in academic works, so why not using the following bibtex entry?

@misc{acher2026texccchess,
  author = {Mathieu Acher},
  title = {TeXCCChess: How Coding Agents Wrote a Chess Engine in Pure TeX},
  year = {2026},
  month = {feb},
  howpublished = {\url{https://blog.mathieuacher.com/TeXCCChessEngine/}},
  note = {\url{https://blog.mathieuacher.com/TeXCCChessEngine/}}
}