The cost of saying yes has changed: GitHub relance le débat sur le vrai bottleneck

In plain terms

Coder n'est plus le goulot. Décider oui/non - à un ticket, une feature, un flag - l'est. Un billet du GitHub Blog remet le trade-off au centre : l'IA a effondré le coût de production, elle augmente le coût des mauvais oui.

Contexte

Le 17 juillet 2026, GitHub Engineering publie « The cost of saying yes has changed ». Le fond : le coût marginal d'écrire une fonctionnalité a plongé, mais chaque « oui » ajouté au périmètre engage une surface qui, elle, ne rétrécit pas - bugs, dépendances, dette d'ops, surface d'attaque.

Les données

Le billet ne s'appuie pas sur un benchmark chiffré, mais sur une observation d'équipe : les tickets « acceptables » explosent quand la production est bon marché. La proposition centrale : réintroduire un coût de décision explicite, en jugeant chaque « oui » comme si le code était déjà écrit - ce qui reste, ce sont les coûts d'ownership (bugs, dépendances, ops, surface d'attaque).

Analyse

La bascule est structurelle. Depuis quinze ans, le débat DX portait sur la vélocité d'exécution - CI, monorepo, code review. L'IA renverse le problème : la vitesse d'exécution est offerte, la vitesse de décision devient rare. C'est un déplacement du bottleneck de la main-d'œuvre vers le jugement. Corollaire pour l'architecture : chaque abstraction accueillie devient une hypothèse à défendre pour dix ans, non plus une contrepartie de coût de développement.

Scénarios

• Discipline reconquise : les équipes qui traitent le « oui » comme une décision d'archi, pas comme une réponse à un besoin utilisateur, sortent avec une base plus mince et plus lisible.
• Prolifération : celles qui laissent l'IA générer sans filtre voient leur dette technique doubler à budget constant, avec un coût de maintenance qui explose avant qu'un CFO ne le remarque (fil token-budget-caps).
• Milieu de gué : la plupart s'installent dans un statu quo où l'IA rend l'existant plus vite mais ne change pas la doctrine de périmètre.

So what

Pour un CTO : ré-écrivez votre définition de « ready » et de « done » avant fin d'année. Pour un ingénieur : le levier n'est plus « produire », c'est « refuser », et il n'est jamais explicité dans une fiche de poste. Pour un dirigeant : le prochain gain de productivité IA est bloqué non par la stack mais par un process de priorisation qui date de l'ère où la rareté était le code.