Debugging process shifts from patching single reports to probing and widening bug classes

Quand on vous signale 1 bug, il y en a toujours plus (le grep qui a démonté mes hypothèses)

La nuit où une fiche élève m'a appris à ne plus regarder la fiche Un mardi de mai 2026, vers 22 h. Catherine me ping depuis Maisons-Laffitte : « ça bug sur Loubna, c'est vite corrigé. » Sentry s'ouvre sur mon téléphone. Cannot read properties of undefined sur la fonction qui rend une feuille d'émargement hebdomadaire. L'enfant n'a pas de nom de famille en base. La main est déjà sur le clavier pour taper l'UPDATE qui rajoute Sebti dans la colonne nom et qui fermerait le ticket en huit secondes. Je ne tape pas l'UPDATE. Je tape une requête plus large, parce qu'un mois plus tôt une autre fiche m'a appris que la fiche n'est jamais le problème. SELECT statut, COUNT(*) FROM contacts WHERE statut = 'inscrit' AND ((nom IS NULL OR nom = '') OR (prenom IS NULL OR prenom = '')); -- → 16 Seize, pas un. Deux fiches au nom et prénom totalement vides, quatorze contacts au prénom vide hérité d'un vieil import Airtable où le champ ne mappait pas, et celui que Catherine venait de voir crasher. Si j'avais patché la fiche, quinze autres feuilles d'émargement seraient tombées au fil des semaines, chacune signalée comme un incident isolé, chacune patchée comme une exception, chacune laissant la classe latente attendre tranquillement la suivante. Le réflexe qu'il faut désamorcer Quand un utilisateur signale un bug, ce qu'il vous donne n'est pas une description du problème. C'est une amorce de sonde, un cas pathologique qui a franchi son filtre cognitif jusqu'à votre Slack. Sa rareté apparente est un artefact de son canal d'observation, pas une propriété du système. Catherine voit ce qui crashe sous ses doigts à Maisons-Laffitte ; elle ne voit pas les quinze fiches dormantes sur les autres ateliers qui crasheront dans trois semaines. Le bon premier geste n'est pas le git diff sur la fiche. C'est la requête GROUP BY qui demande au système combien d'autres lignes portent la même pathologie. Quatre-vingt-dix secondes de probe matérielle, et la nature du fix change radicalement. Pourquoi un agent IA aggrave le risque Quand le patch nominatif coûte huit secondes à générer, le coût marginal apparent de sauter la probe tombe à zéro. L'agent ne va pas vous suggérer de chercher la classe. Il sait répondre à la question posée, et la question posée par votre prompt c'est « corrige cette fiche », pas « cartographie toutes les fiches dans cet état ». Le réflexe humain ancien, la lenteur qui obligeait à formuler, à se demander si l'effort valait la peine pour un cas, disparaît avec l'agent. Il faut le rematérialiser par discipline. Je n'ai pas modifié mon agent. J'ai modifié mon prompt initial. Quand un bug remonte de la prod, le premier message que je tape ne dit jamais « fixe cette fiche ». Il dit « écris la requête GROUP BY qui révèle la classe complète des cas similaires en base ». Le fix vient après, quand la classe est cartographiée. Si la probe ne remonte qu'un cas, ça arrive, le commit le mentionne explicitement, probe pattern : 1/1, comme preuve que la question a été posée. Trois questions avant tout fix Quoi que vous pensiez de votre flair de senior, posez les trois, et posez-les dans l'ordre. Quelle est la classe dont ce cas est l'instance, formulée comme un critère SQL ou un regex de grep, pas comme une intuition ? Combien d'instances la classe contient en prod, à l'instant où vous lisez le ticket ? Le fix proposé traite-t-il la classe ou seulement l'instance signalée ? Si la troisième réponse est seulement l'instance, vous n'avez pas un fix, vous avez un palliatif daté. La classe attend. Le réflexe d'élargissement porte un nom dans le Counterpart Toolkit, *Widen before correcting, cousin de Falsify before fix : github.com/michelfaure/doctrine-counterpart*

19 hours ago

When a user reports 1 bug, there are always more (the grep that broke my assumptions)

The night one student's record taught me to stop looking at the record A Tuesday in May 2026, around 10 p.m. Catherine pings me from Maisons-Laffitte: « ça bug sur Loubna, c'est vite corrigé. » Sentry opens. Cannot read properties of undefined on the function that renders a weekly attendance sheet. The child has no last name on file. My hand is already typing the one-line UPDATE that would write Sebti into the nom column and close the ticket in eight seconds. I don't type the UPDATE. I type a wider query, because another record taught me a month earlier that the record is never the problem. SELECT statut, COUNT(*) FROM contacts WHERE statut = 'inscrit' AND ((nom IS NULL OR nom = '') OR (prenom IS NULL OR prenom = '')); -- → 16 Sixteen, not one. Two rows fully empty, fourteen with a missing first name inherited from a legacy Airtable import where one column never mapped, and the one Catherine had just watched crash. Had I patched the record, fifteen other attendance sheets would have fallen over the following weeks, each one reported as an isolated incident, each one patched as an exception, each one leaving the dormant class waiting quietly for the next. The reflex you have to defuse When a user reports a bug, what they hand you is not a description of the problem. It is a probe seed, a pathological case that crossed their cognitive filter on its way to your Slack. Its apparent rarity is an artefact of their observation channel, not a property of the system. Catherine sees what crashes under her fingers in Maisons-Laffitte; she does not see the fifteen dormant rows on the other ateliers that will crash three weeks from now. The correct first move is not the git diff on the record. It is the GROUP BY that asks the system how many rows share the same pathology. Ninety seconds of material probing, and the nature of the fix changes radically. Why an AI agent makes this worse When the nominative patch costs eight seconds to generate, the apparent marginal cost of skipping the probe drops to zero. The agent will not suggest you map the class. It knows how to answer the question you asked, and the question your prompt encoded was "fix this record", not "chart every record in this state". The old human friction that forced you to weigh whether the effort was worth it for one case vanishes with the agent. You have to rematerialise it by discipline. I did not change my agent. I changed my opening prompt. When a production bug surfaces, my first message never says "fix this record". It says "write the GROUP BY query that reveals the full class of similar cases in the database." The fix comes after, once the class is mapped. If the probe returns only one case — it happens — the commit says so explicitly, probe pattern: 1/1, as proof the question was asked. Three questions before any fix Whatever you think of your senior instinct, ask the three, and ask them in order. What is the class this case is an instance of, expressed as a SQL predicate or a grep regex, not as intuition? How many instances does the class hold in production, right now, as you read the ticket? Does the proposed fix address the class, or only the reported instance? If the third answer is only the instance, you do not have a fix, you have a dated palliative. The class is still waiting. The widening reflex has a name in the Counterpart Toolkit, *Widen before correcting, sibling to Falsify before fix: github.com/michelfaure/doctrine-counterpart*

19 hours ago