6 min remaining
0%
Leadership en Temps de Crise

Le problème du Fogbank : Pourquoi nous perdons la capacité de construire des choses

Le problème du Fogbank met en lumière une perte de connaissance critique dans l'ingénierie et le logiciel, menaçant notre capacité à construire efficacement à l'ère de l'IA.

6 min read
Progress tracked
6 min de lecture
AI Generated Cover for: The Fogbank Problem: Why We're Losing the Ability to Build Things

AI Generated Cover for: The Fogbank Problem: Why We're Losing the Ability to Build Things

Je regardais un panel de l'industrie de la défense l'année dernière lorsque le PDG de Raytheon a dit quelque chose qui s'est logé dans mon cerveau comme une écharde. Il expliquait pourquoi il avait fallu quatre ans pour relancer la production de missiles Stinger après que le Pentagone ait passé une commande en 2022.

Ils ont dû sortir des ingénieurs de 70 ans de leur retraite. Pas en tant que consultants, mais en tant qu'enseignants. Les jeunes employés ne savaient pas comment lire des plans en papier de l'administration Carter. L'équipement de test n'existait plus. Les composants de recherche avaient été abandonnés des décennies auparavant. Une commande passée en 2022 ne serait pas livrée avant 2026, non pas à cause du financement, mais parce que les "connaissances" avaient pris leur retraite et étaient décédées.Le Pentagone n'avait pas acheté de nouveaux Stingers depuis vingt ans. Ils pensaient que la capacité resterait simplement... sur l'étagère. Comme si une compétence était un objet physique que l'on peut stocker dans un entrepôt. had retired and died.

The Pentagon hadn't bought new Stingers in twenty years. They assumed the capability would just... stay on the shelf. Like a skill is a physical object you can store in a warehouse.

Puis il y a Fogbank. C'est un matériau classifié utilisé dans les ogives nucléaires de 1975 à 1989. Lorsque le gouvernement a eu besoin de le fabriquer à nouveau pour un programme de prolongation de vie, il a découvert qu'il ne pouvait littéralement pas. Les personnes qui savaient comment le faire étaient mortes ou à la retraite. La documentation existait, mais elle était insuffisante de manière à ne devenir claire qu'après 69 millions de dollars en tentatives échouées.

Ils ont finalement produit un lot. Il était "trop pur". Le processus original s'appuyait sur une impureté accidentelle—quelque chose que personne, pas même les ingénieurs d'origine, ne savait être critique. Le savoir n'était pas seulement perdu. Le contexte profond et non écritde pourquoi le système fonctionnait n'avait jamais été articulé. Il vivait dans les os des personnes qui étaient maintenant parties.

Je dirige des équipes d'ingénierie pour gagner ma vie. Quand je regarde la base industrielle de défense—l'incapacité à fabriquer des obus d'artillerie, les points de défaillance uniques, l'expertise générationnelle qui s'évapore—je ne vois pas seulement une crise militaire.

Je vois le même effondrement exact se produire dans l'ingénierie logicielle.Et cela se produit plus rapidement.

Le dividende de la paix est l'IA

En 1993, après la fin de la guerre froide, le Pentagone a dit aux PDG de la défense de se consolider ou de mourir. Ils ont optimisé pour une efficacité de coût extrême. Ils ont cessé de planifier pour le volume. Ils ont arrêté de former la prochaine génération pour des crises qu'ils supposaient ne viendraient jamais.

Dans le logiciel, notre "dividende de la paix" est l'IA.

Nous sommes à trois ans de ce cycle d'optimisation. Les grandes entreprises technologiques ont gelé les postes d'ingénieurs juniors. Une enquête de LeadDev a révélé que 54 % des leaders en ingénierie croient que les copilotes IA réduiront de manière permanente les recrutements de juniors. Les inscriptions en informatique diminuent dans les meilleures universités.

La logique est séduisante : pourquoi embaucher un développeur junior quand ChatGPT peut générer le code en trente secondes ?

Mais voici les calculs que personne ne veut faire à voix haute. Un développeur junior met trois à cinq ans pour devenir de niveau intermédiaire. Cinq à huit ans pour devenir senior. Une décennie pour devenir architecte. Vous ne pouvez pas acheter ce temps avec de l'argent. Vous ne pouvez pas le compresser avec une invite.

Lorsque les ingénieurs juniors utilisent l'IA pour sauter le processus éprouvant de débogage—lorsqu'ils contournent les erreurs douloureuses qui forgent réellement la compétence—ils ne développent jamais de connaissances tacites. Ils deviennent des "prompteurs IA". Ils peuvent dire à la machine quoi faire, mais ils ne peuvent pas vous dire "pourquoi" la sortie confiante de la machine est architecturale ment erronée. Ils ne peuvent pas sentir le mauvais schéma. Ils ne peuvent pas ressentir la dette technique qui s'accumule.Lorsque ma génération d'ingénieurs seniors partira à la retraite, notre connaissance ne se transférera pas magiquement à l'IA. Comme Fogbank, elle disparaîtra simplement. Et les "prompteurs" laissés derrière ne sauront pas ce qu'ils ne savent pas jusqu'à ce que le système s'effondre. the machine's confident output is architecturally flawed. They can't smell the bad pattern. They can't feel the technical debt accumulating.

When my generation of senior engineers retires, our knowledge will not magically transfer to the AI. Like Fogbank, it will just vanish. And the "prompters" left behind won't know what they don't know until the system collapses.

La crise du contexte

En ce moment, la génération de code par IA est incroyablement rapide. Mais la révision de code par des humains est devenue le goulot d'étranglement. La solution prévisible de l'industrie ? Laisser l'IA réviser le code de l'IA.

C'est une erreur catastrophique déguisée en efficacité.

Une IA ne comprend pas votre logique métier. Elle ne connaît pas la dette technique historique de la migration de 2019 qui hante encore votre schéma de base de données. Elle ne sait pas la règle non écrite selon laquelle ceci microservice ne peut jamais appeler celui-là directement à cause d'une contrainte réglementaire d'un client qui est parti il y a deux ans. Elle manque de contexte.

Même si vous documentez tout—Livres de site, Documents de conception logicielle, couverture de test complète—cela ne fonctionne aujourd'hui que parce que les humains qui lisent ces documents possèdent l'expertise tacite pour les interpréter. Les documents sont une carte, mais vous avez toujours besoin de quelqu'un qui comprend le terrain.

Que se passe-t-il lorsque les lecteurs sont des "inviteurs" qui ne comprennent pas réellement les systèmes distribués ? Lorsque la personne qui examine la sortie de l'IA ne peut pas reconnaître que la solution est élégante, correcte, et désastreux pour votre infrastructure spécifique ?

Fogbank a échoué parce que la recette manquait du contexte implicite d'une impureté. Votre logiciel d'entreprise échouera pour la même raison. L'IA générera un code beau et fonctionnel qui détruit lentement et invisiblement l'architecture—car personne en vie ne se souvient pourquoi la contrainte originale existait.

Pourquoi nous avons construit Mercury Bridge

J'ai commencé Mercury Bridge parce que j'ai vu cet écart se creuser en temps réel. D'un côté : la vitesse d'exécution de l'IA qui double tous les six mois. De l'autre : la compréhension contextuelle humaine qui prend une décennie à construire et une retraite à perdre.

Mercury Bridge n'est pas un autre copilote IA. Ce n'est pas un moyen plus rapide de générer du code. C'est un cadre architectural conçu pour capturer, structurer et déployer le contexte commercial profond et implicite de votre organisation.

Voici ce que cela signifie réellement :

Ancrage Contextuel : Avant que l'IA n'écrive une ligne de code ou ne rédige une stratégie, Pont Mercure force l'alignement sur votre logique propriétaire. Il cartographie vos décisions historiques, vos dépendances technologiques, et les "connaissances inconnues" qui maintiennent vos systèmes en fonctionnement—les choses que personne ne documente parce que tout le monde suppose qu'elles sont évidentes.

Combler le fossé des juniors : Parce que nous structurons le contexte d'entreprise de manière si approfondie, lorsqu'un ingénieur moins expérimenté (ou un agent IA) interagit avec le système, il est contraint par des garde-fous établis par vos experts seniors. Nous ne sautons pas le processus d'apprentissage ; nous fournissons un filet de sécurité de mémoire institutionnelle afin que l'apprentissage ne nécessite pas une décennie de cicatrices.

Le Coffre des Décisions : Nous ne stockons pas seulement du code. Nous stockons les décisions derrière le code.Pourquoi cette demande de tirage a-t-elle été approuvée ? Pourquoi avons-nous rejeté cette architecture de base de données en 2024 ? Quelle contrainte d'un contrat client en 2021 affecte encore notre gestion des données aujourd'hui ? En préservant le contexte de la décision, nous veillons à ce que l'IA (et les futurs humains) ne répètent pas les erreurs historiques par ignorance.

La facture arrive

L'industrie de la défense a parié que la paix géopolitique durerait éternellement. Ils ont payé pour ce pari lorsque le monde a changé.

L'industrie du logiciel parie que l'IA progressera suffisamment rapidement pour rendre le jugement humain senior obsolète avant que la génération actuelle ne prenne sa retraite. C'est un pari terrifiant. Si l'IA stagne - et toute technologie finit par stagner - et que vous avez passé cinq ans à licencier des juniors et à compter sur la génération de code synthétique, votre entreprise se réveillera un jour en réalisant qu'elle a oublié comment construire son propre produit.

L'argent n'a jamais été le facteur limitant. La connaissance l'est. Et la connaissance, contrairement à l'argent, meurt avec les personnes qui la détiennent.

Vous devez coder en dur votre contexte avant que les personnes qui le détiennent ne quittent le bâtiment.

— James, Mercury Technology Solutions, Hong Kong, mai 2026