L’avenir de la construction d’applications AI repose sur la sécurité des types

Le code généré par l’IA peut compiler, mais sans sécurité des types stricte, ce succès est extrêmement éphémère. La sécurité des types est la garde-fou qui empêche le code fragile de se dégrader en bogues cachés et en erreurs d’exécution à mesure que le système évolue.

Nous devons commencer à forcer l’IA à respecter les types stricts grâce au contexte, aux instructions, à la vérification et aux boucles de rétroaction. Cela prend quelques heures supplémentaires, mais cela produit du code qui dure.

Le problème des incitations

L’IA veut vous faire plaisir. Elle optimise la fonction de récompense qui lui est donnée, et la plupart du temps, c’est juste « cela compile-t-il ? ». Cela signifie qu’elle coupera tous les coins nécessaires pour obtenir un check vert. Ces raccourcis semblent bien au moment de la compilation, mais ils s’effondrent au moment de l’exécution.

C’est pourquoi l’IA adore any. Ou elle choisit un type large comme string où quelque chose de plus strict, comme un UUID, est attendu. Le code compile, mais la correction est déjà compromise. Pire, l’IA n’a pas souvenir de ce qu’elle a écrit il y a quelques fichiers, donc sans sécurité des types, le projet s’effondre rapidement sous son propre poids à mesure que la complexité augmente.

Les deux types d’erreurs

Lorsque le code généré par l’IA s’exécute, vous voyez généralement deux types de problèmes de sécurité des types :

1. Erreurs de compilation

• Ce qui se passe : Le compilateur détecte une incohérence entre le type déclaré et ce qui a été passé.
• Comment un humain le corrige : Décidez si l’appelant est incorrect (convertissez 42 en string) ou si la signature de la fonction est incorrecte (changez-la pour accepter un type number).
• Comment l’IA « le corrige » : Changez le type d’argument en any. Le problème est « résolu », mais vous venez de supprimer la garde-fou qui aurait pu détecter les erreurs futures.

2. Erreurs d’exécution

• Ce qui se passe : Le compilateur pense que tout va bien (souvent parce que les types ont été assouplis), mais la valeur réelle au moment de l’exécution ne correspond pas à l’hypothèse.
• Comment un humain le corrige : Reprenez la variable à sa source (comme une API ou une requête de base de données) et corrigez le type à la limite pour que les données soient introduites sous forme de string correct.
• Comment l’IA « le corrige » : Sans contexte, elle devine. Peut-être qu’elle entoure tout dans String(…), ou qu’elle élargit simplement le type à nouveau. La panne disparaît à cet endroit, mais maintenant la logique est cassée. Les Number destinés aux mathématiques sont soudainement des strings.

Ce cycle d’erreurs d’exécution → « correction » de l’IA → typage plus lâche se multiplie rapidement. Le résultat est une base de code qui compile et qui lance moins d’erreurs d’exécution, mais qui ne peut pas être fiable. Imaginez un système de planification de soins de santé où les quarts de travail des médecins sont gérés par l’application. Un décalage de type s’infiltre : un int pour les heures est traité comme un string. L’IA « le corrige » en assouplissant le type en any. Le code compile et l’erreur disparaît, mais les calculs de quarts de travail sont silencieusement cassés, ce qui entraîne une double réservation de médecins et laisse un entire aile de l’hôpital sans surveillance.

Le multiplicateur de base de données

Au moment où vous vous connectez à une base de données, les erreurs se multiplient et leurs causes deviennent plus difficiles à retracer. SQL est typé pour une raison. Chaque schéma (INT, TEXT, UUID, BOOLEAN) encode des hypothèses sur vos données.

Lorsque l’IA aplatie tout en string | any, vous perdez ces garanties :

• Mauvaises écritures : insérer « true » dans un champ booléen compile, mais corrompt la base de données.
• Mauvaises lectures : la requête renvoie NULL, mais l’IA a supposé un string, ce qui conduit à une panne d’exécution.
• Relations cassées : si une clé de relation est attendue sous la forme d’un UUID mais que l’IA la traite comme un string et envoie des valeurs de rebut, les jointures ne planteront pas mais ne renverront pas de données. Cela cache les erreurs jusqu’à ce qu’elles apparaissent plus tard sous forme de résultats manquants ou incohérents..

C’est pourquoi les équipes sérieuses utilisent des langages typés et imposent la sécurité des types de la base de données à l’API. Si vous ne le faites pas, la base de données cesse de vous protéger et les problèmes cachés se multiplient.

Pourquoi les équipes matures imposent un typage strict

Le typage strict n’est pas fait pour ralentir les développeurs. C’est fait pour rendre l’évolution possible.

Les types :

• Encodent l’intention dans le code.
• Rendre les réfactorisations sûres et prévisibles.
• Attrapent des classes entières de bogues avant qu’ils n’atteignent la production.
• Montrent aux futurs développeurs (et à l’IA) exactement comment utiliser une fonction ou un objet.

Sans sécurité des types, la négligence de l’IA se multiplie. Avec elle, la même IA produit du code que vous pouvez faire confiance et étendre.

Comment forcer l’IA à respecter la sécurité des types

Vous devez traiter l’IA comme un jeune ingénieur. Rapide, talentueux, mais imprudent sans direction.

Fournir le bon contexte

Donnez-lui les interfaces et les types qu’il peut utiliser. Montrez des exemples d’utilisation. Soyez opiné sur la bonne façon de structurer le code.

Donner des instructions strictes

Faites clairement savoir à l’IA de ne pas utiliser any, de ne jamais autoriser unknown, et de faire en sorte que chaque méthode, objet et variable soit typé. Attendez-vous à ce qu’il ait du mal à suivre ces instructions (surtout au premier passage).

Imposer avec la vérification

Comme lors de la révision du code d’un jeune développeur, vous devez vérifier le code de l’IA. Conceptionnez des règles de vérification personnalisées qui définissent ce que « bon code » signifie pour vous. Faites passer les échecs de vérification au modèle jusqu’à ce qu’il passe. Cela peut prendre plusieurs tours, mais cela déplace la fonction de récompense vers l’inclusion de la sécurité des types.

Itérer avec des vérifications

Erreurs de compilation, journalisation d’exécution, tests de clic. Chaque itération force l’IA à resserrer les types et à se rapprocher d’un code de qualité de production.

Une meilleure façon de construire

J’ai appris que sacrifier la vitesse de génération brute pour une qualité supérieure paie au final. Cela signifie lutter pour une tolérance zéro pour les types any, imposer plusieurs boucles de rétroaction et des règles de vérification strictes que l’IA doit passer avant d’appeler le code « terminé ». Cela prend un effort constant, mais c’est la seule façon de maintenir la qualité sans la laisser décliner.

Plus tôt, j’ai mentionné un point clé : une fois que l’IA commence à patcher les erreurs d’exécution en assouplissant les types, vous entrez dans un cycle vicieux. Chaque correction enlève une autre garde-fou, et le résultat se multiplie en une base de code qui compile mais qui est fragile et non maintenable. L’inverse est également vrai : si vous forcez l’IA à respecter la sécurité des types à chaque passage, vous créez un cycle vertueux. Chaque itération resserre les garde-fous, la base de code devient plus propre, et la qualité se multiplie en quelque chose que vous pouvez faire confiance et construire.

C’est le système que je crois apporte une qualité de code durable. Chaque itération est conçue pour resserrer les normes, et non pour les affaiblir. C’est la même raison pour laquelle les meilleures équipes d’ingénieurs choisissent des langages fortement typés. La sécurité des types est la garde-fou de base pour la maintenabilité, et laisser l’IA l’ignorer garantit que votre application n’atteindra jamais le niveau de production.