Huit ans de désir, trois mois de construction avec l'IA

Huit ans de désir, trois mois de construction avec l'IA

Lalit Maganti propose l'un des meilleurs écrits longs sur l'ingénierie agentique que j'ai vus depuis longtemps.

Ils ont passé huit ans à réfléchir et trois mois à construire syntaqlite, qu'ils décrivent comme des "outils de développement de haute fidélité que SQLite mérite".

L'objectif était de fournir des outils de linting et de vérification rapides, robustes et complets pour SQLite, adaptés à une utilisation dans des serveurs de langage et d'autres outils de développement : un analyseur, un formateur et un vérificateur pour les requêtes SQLite. J'ai moi-même ressenti le besoin de ce type d'outil dans le passé, d'où mon projet sqlite-ast, qui était (de loin) moins prêt pour la production.

Lalit avait procrastiné sur ce projet pendant des années, en raison de la monotonie inévitable de devoir travailler à travers plus de 400 règles de grammaire pour aider à construire un analyseur. C'est exactement ce type de travail fastidieux dans lequel les agents de codage excellent !

Claude Code a aidé à surmonter ce premier obstacle et à construire le premier prototype :

L'IA m'a essentiellement permis de mettre de côté tous mes doutes sur les appels techniques, mon incertitude quant à la construction de la bonne chose et ma réticence à commencer en me donnant des problèmes très concrets à résoudre. Au lieu de dire "Je dois comprendre comment fonctionne l'analyse de SQLite", c'était "Je dois amener l'IA à suggérer une approche afin que je puisse la déchirer et construire quelque chose de mieux". Je travaille beaucoup mieux avec des prototypes concrets à manipuler et du code à examiner qu'en réfléchissant sans fin à des conceptions dans ma tête, et l'IA me permet d'atteindre ce point à un rythme que je n'aurais jamais pu imaginer auparavant. Une fois que j'ai fait le premier pas, chaque étape suivante était tellement plus facile.

Ce premier prototype codé par ambiance a bien fonctionné comme preuve de concept, mais ils ont finalement décidé de le jeter et de recommencer à zéro. L'IA a bien fonctionné pour les détails de bas niveau mais n'a pas produit une architecture cohérente de haut niveau :

J'ai constaté que l'IA me faisait procrastiner sur des décisions de conception clés. Comme le refactoring était facile, je pouvais toujours dire "Je m'en occuperai plus tard". Et comme l'IA pouvait refactoriser à la même échelle industrielle qu'elle générait du code, le coût de différer semblait faible. Mais ce n'était pas le cas : différer les décisions a corrodé ma capacité à penser clairement car la base de code restait confuse entre-temps.

La deuxième tentative a pris beaucoup plus de temps et a nécessité beaucoup plus de prise de décision humaine, mais le résultat est une bibliothèque robuste qui peut résister à l'épreuve du temps.

Il vaut la peine de prendre le temps de lire tout cela - c'est plein d'inconvénients non évidents à travailler intensivement avec l'IA, ainsi qu'une explication détaillée de la manière dont ils ont surmonté ces obstacles.

L'idée clé que j'ai retenue concerne la faiblesse de l'IA en matière de conception et d'architecture :

Lorsque je travaillais sur quelque chose dont je ne savais même pas ce que je voulais, l'IA était quelque part entre inutile et nuisible. L'architecture du projet était le cas le plus clair : j'ai passé des semaines au début à suivre l'IA dans des impasses, explorant des conceptions qui semblaient productives sur le moment mais se sont effondrées sous l'examen. Avec le recul, je me demande s'il n'aurait pas été plus rapide de réfléchir sans l'IA du tout.

Mais l'expertise seule ne suffit pas. Même lorsque je comprenais un problème en profondeur, l'IA avait toujours du mal si la tâche n'avait pas de réponse objectivement vérifiable. L'implémentation a une bonne réponse, du moins à un niveau local : le code compile, les tests passent, la sortie correspond à ce que vous avez demandé. La conception ne l'est pas. Nous débattons encore de l'OOP des décennies après son essor.