8 ans de désir, 3 mois pour concrétiser — la formule du side project transformée par l’IA

• Un outil de développement de haute qualité pour SQLite, longtemps absent, a pu être finalisé rapidement avec l’aide de l’IA
• L’obstacle majeur a été la construction du parseur, en raison de l’absence de spécification grammaticale officielle et d’une base de code C complexe
• Des agents de codage IA comme Claude Code ont permis d’accélérer l’implémentation initiale, mais un problème de code spaghetti a conduit à une réécriture en Rust
• L’IA s’est montrée très efficace pour la génération de code, le refactoring, l’aide à l’apprentissage et l’amélioration de l’UX, mais a aussi entraîné des effets secondaires comme le retard de conception, la déconnexion du code et l’addiction à la dépendance
• En conclusion, l’IA n’est qu’un outil pour accélérer l’implémentation ; la conception et la direction du logiciel restent de la responsabilité humaine

---

Trois mois pour construire un outil de développement SQLite avec l’IA

• Je voulais depuis longtemps un outil de développement de haute qualité pour SQLite, mais les outils open source existants étaient insuffisants en matière de fiabilité, de vitesse et de flexibilité
  • En maintenant PerfettoSQL, il existait des besoins pour un formateur, un linter, une extension d’éditeur, etc., mais aucun outil adapté n’était disponible
  • Je voulais créer un nouvel outil comme projet personnel, mais la difficulté et le poids du travail répétitif ont repoussé cela pendant des années

Les difficultés du projet

• SQLite ne dispose ni de spécification grammaticale officielle ni d’API de parseur stable
  • En interne, il ne génère pas d’arbre de syntaxe, il a donc fallu extraire directement la logique du parseur depuis le code source
  • Il fallait mapper une à une plus de 400 règles grammaticales, et l’écriture des tests comme le débogage étaient des tâches extrêmement répétitives et fatigantes
• La base de code C de SQLite est complexe et très dense, donc difficile à comprendre
  • La structure est si obscure qu’il a fallu plusieurs jours rien que pour comprendre l’API des tables virtuelles et son implémentation

Le processus de développement avec l’IA

• À partir de la fin 2025, utilisation active d’agents de codage IA comme Claude Code
  • Au début, la majeure partie de la conception et de l’implémentation a été confiée à l’IA, dans une approche de type « vibe-coding »
  • Le résultat fonctionnait, mais la base de code est devenue un enchevêtrement spaghetti d’une complexité impossible à maintenir
• Ensuite, l’ensemble a été réécrit en Rust afin de restructurer le projet
  • L’usage de Rust à la place du C a facilité le développement des composants de plus haut niveau (validateur, language server, etc.)
  • L’IA a été limitée à un rôle d’« outil d’autocomplétion renforcé », tandis que la conception, la revue et les tests ont été directement pilotés à la main
  • Mise en place d’un scaffolding de validation des sorties de l’IA : linting, vérification, automatisation des tests, etc.

Ce que l’IA a rendu possible

• Surmonter l’inertie

  • L’IA découpe le travail en problèmes concrets, ce qui facilite le démarrage
  • Au lieu de « je dois comprendre le parsing SQLite », on passe à « j’examine l’approche proposée par l’IA », ce qui accélère l’exécution

• Vitesse de génération de code et de refactoring

  • Quand les exigences sont claires, l’IA écrit rapidement un code standardisé et cohérent
  • En revanche, sur des conceptions non standard (comme la structure du parseur), elle devient plutôt un obstacle et il faut coder soi-même
  • Après une génération de code à grande échelle, un refactoring continu est indispensable pour préserver la qualité

• Rôle d’assistant d’apprentissage

  • L’IA explique en temps réel de nouveaux concepts comme l’algorithme de formatage Wadler-Lindig
  • Elle permet aussi d’entrer rapidement dans des domaines moins familiers comme Rust ou les extensions VS Code
  • Quand le contexte du projet se perd, des requêtes comme « explique-moi ce composant » permettent une restauration immédiate du contexte

• Amélioration du niveau de finition

  • Elle réduit le coût de développement des fonctionnalités annexes comme une extension d’éditeur, des bindings Python, un playground WASM ou un site de documentation
  • La baisse de charge sur l’implémentation permet de se concentrer sur l’amélioration de l’UX, par exemple les messages d’erreur ou la conception de la CLI

Les effets secondaires de l’usage de l’IA

• Addictivité

  • Une structure de récompense façon machine à sous qui pousse à relancer « juste un prompt de plus »
  • Plus on est fatigué, plus la qualité des prompts baisse, et les résultats se dégradent, créant un cercle vicieux

• Déconnexion vis-à-vis de la base de code

  • Plus il y a de code généré par l’IA, plus on perd le sens de la structure détaillée
  • Quand on perd le contexte, les échanges avec l’IA s’allongent et deviennent inefficaces
  • Comme solution, l’habitude a été prise de relire immédiatement le code généré et de vérifier « ce que j’aurais écrit différemment »

• Retard et érosion de la conception

  • Le refactoring étant facile, il apparaît une tendance à repousser les décisions de conception essentielles
  • Même avec beaucoup de tests, il est difficile de masquer des erreurs de conception fondamentales, et une réécriture complète finit par s’imposer

• Absence de perception du temps

  • L’IA ne comprend pas le contexte temporel ni le processus d’évolution du code
  • Elle peut répéter des erreurs passées ou réexplorer des problèmes déjà résolus, générant de l’inefficacité
  • La documentation peut compenser en partie, mais il reste difficile de consigner complètement l’intention de conception

La relativité de l’usage de l’IA

• Dans les domaines que l’on comprend en profondeur, l’IA excelle et permet une revue rapide ainsi que de l’itération
  • Exemple : la génération de règles de parseur est efficace car il existe une réponse claire
• Dans les domaines partiellement connus, elle est utile comme outil d’apprentissage mais exige une vigilance constante
  • Exemple : l’apprentissage d’un algorithme de formatage
• À l’étape où l’on ne sait pas encore quoi construire, elle est au contraire nuisible
  • Exemple : des boucles improductives apparaissent pendant la phase de conception de l’architecture
• L’IA est forte sur les problèmes vérifiables (compilation, tests qui passent),
  mais faible sur les problèmes sans réponse unique, comme le design ou la qualité d’API

Conclusion

• Si un outil SQLite imaginé depuis 8 ans a pu être réalisé en seulement 3 mois, c’est grâce à l’IA
  • Mais le processus n’a pas été un simple récit de réussite : il s’est accompagné des limites et du coût de la dépendance à l’IA
• L’IA est un accélérateur d’implémentation, mais pas un substitut à la conception
  • Elle répond précisément aux questions techniques, mais manque de mémoire historique, de goût et de sensibilité utilisateur
• La véritable leçon est que, même si l’IA permet de se heurter plus vite aux murs,
  c’est à l’humain qu’il revient d’assumer la direction de la conception et “l’âme du logiciel”
• Ce qu’il faut désormais, c’est partager des cas de projets capables de résister à de vrais utilisateurs et à la maintenance
  • Il ne s’agit pas de simples expériences, mais d’une accumulation d’expériences de développement collaboratif avec l’IA réalistes et durables

[GN⁺]

Avis Hacker News

• J’ai trouvé rafraîchissant de voir une vision équilibrée du AI coding
  C’est une expérience à laquelle la plupart des développeurs sérieux peuvent s’identifier — au début, on est impressionné par la capacité de l’IA à écrire du code, puis on se rend compte plus tard que la base de code est devenue un chaos de spaghetti code
  Certains ne font même pas de revue de code et proclament que « le codage manuel est terminé », tandis que d’autres concluent que « le AI coding ne sert à rien »
  Mais la réalité se situe quelque part entre les deux. L’IA peut être un formidable accélérateur de productivité, mais il faut l’intégrer correctement au workflow et garder un humain dans la boucle

  • J’utilise moi aussi Claude comme interface principale de codage depuis trois mois
    Au départ, c’était un prototype, mais il a vite évolué en véritable service. Ensuite, j’ai eu du mal à faire le ménage lors du refactoring pour supprimer tout le code inutile
    Malgré tout, c’est grâce à ce prototypage rapide que le produit actuel existe. Claude s’est aussi révélé utile pour remettre de l’ordre dans le code, un peu comme une tronçonneuse
    Récemment, j’ai ajouté un type checker via un hook pre-commit et corrigé 90 erreurs en seulement deux heures.
    Le AI coding est impressionnant, mais pour du code de production, la revue et le jugement humains restent indispensables
  • Ce que j’ai particulièrement aimé dans cet article, c’est son point de vue équilibré
    Cela dit, comme il s’agit d’un projet greenfield individuel, il est difficile de l’appliquer tel quel au développement en équipe
    Malgré tout, si l’on construit un prototype en partant du principe qu’il sera jeté, un peu de spaghetti code me paraît acceptable.
    Le vrai problème, c’est que l’auteur a cru pouvoir en faire un vrai produit.
    Mais cet échec lui a probablement permis d’apprendre une meilleure conception
  • En réalité, je pense que ces réactions extrêmes correspondent aux étapes que traverse toute personne découvrant le AI coding
    D’abord l’émerveillement, puis la déception, et enfin l’équilibre.
    On dirait presque une version IA du modèle de Kübler-Ross
  • À l’inverse, je pense que l’obsession de la qualité du code est un angle mort à l’ère de l’IA
    Bien sûr, la qualité compte, mais la qualité du code en soi devient moins centrale
    Le nombre de codes ne nécessitant pas de maintenance, comme les apps personnelles, augmente, et les capacités de conception de l’IA progressent vite
    Au final, la « vérité du AI coding » continue d’évoluer, et ce mouvement ne s’arrêtera pas
  • Je pense qu’il y a deux raisons pour lesquelles ce type d’article réaliste est rare
    Premièrement, la plupart des développeurs profitent tranquillement de gains de productivité de 2 à 50 % sans ressentir le besoin d’en parler
    Deuxièmement, le vrai AI coding est ennuyeux et peu spectaculaire visuellement.
    En fin de compte, les LLM ne sont qu’un outil qui évite d’avoir à mémoriser le boilerplate, mais l’essence du code reste la même

• J’ai rencontré le même problème avec la génération de tests par IA
  Avoir plus de tests rassure, mais en réalité ils ne couvrent pas bien les edge cases
  En particulier, lorsqu’on refactorise du code legacy sans tests, les tests générés par l’IA vérifient seulement que ça fonctionne, sans garantir la cohérence du comportement
  Ce problème était particulièrement marqué dans des apps React. C’est pourquoi je réfléchis à une approche qui combine BDD + développement guidé par les spécifications avec l’IA

  • J’ai l’impression qu’écrire de bons tests est 10 fois plus difficile que coder lui-même
    Les tests unitaires reposent sur une conception créative des mocks, les tests d’intégration sur la manipulation des données, et les tests e2e sur la stabilité des sélecteurs
    Ce type de jugement créatif reste encore difficile à reproduire pour l’IA
  • Il ne faut pas se laisser tromper par les chiffres de couverture
    Même avec 97 % de couverture, il restait de nombreux trous dans l’espace logique des entrées.
    Récemment, j’ai automatisé avec des agents IA des techniques classiques comme l’equivalence partitioning, et je les ai appliquées à 60 modèles
  • Je recommande une approche consistant à spécifier le comportement du système avec TLA+, puis à relier le code à la spécification
    L’essentiel est d’isoler autant que possible les fonctions pures pour tester complètement la correspondance entre entrées et sorties

• À long terme, je pense que la vraie valeur de l’IA réside dans son rôle d’outil d’amplification de la compréhension
  Par exemple, analyser les règles d’un code C complexe et en documenter la structure
  Si cette extraction de connaissances devient possible, on pourra automatiser la documentation d’API, le mapping de règles, l’analyse de bugs et même l’optimisation d’architecture
  Au final, la capacité à structurer le contexte deviendra plus importante que celle de générer du code

  • Les façons d’utiliser l’IA varient énormément selon les personnes
    ① le modèle oracle omniscient, qui se contente de donner les exigences et laisse générer toute l’application
    ② le modèle outil d’assistance, qui avance ligne par ligne dans l’IDE en vérifiant chaque proposition
    Pour construire un service durable, l’option ② est de loin la plus réaliste

• La phrase « l’architecture émerge quand des morceaux locaux interagissent » m’a marqué
  L’IA est forte dans l’exécution locale, mais faible dans les phases de conception ambiguës
  En réalité, c’est aussi le cas des développeurs humains. La conception est une succession de compromis sans bonne réponse absolue

  • Il m’est déjà arrivé d’aboutir à une conclusion de conception après une longue conversation avec une IA
    Elle m’a notamment beaucoup aidé sur la conception SQL pour ClickHouse
    Grâce à l’approche d’inclusion SQL basée sur des templates qu’elle a proposée, j’ai réduit les duplications et amélioré les performances
    Cette approche existait peut-être déjà, mais j’aurais eu du mal à la trouver sans IA

• Cet article paraît crédible parce qu’il repose sur 250 heures d’effort réel
  Je pense qu’un projet de cette ampleur représente un modèle réaliste de véritable programmation système assistée par IA

• La formule « le AI coding, c’est comme une machine à sous » me parle énormément
  J’ai moi aussi un accès illimité à des agents IA au travail, et quand on se dit « encore un prompt »,
  on se retrouve soudain à avoir passé 12 heures dessus. C’est une expérience très addictive en immersion

• C’est probablement la période la plus difficile du AI coding en ce moment
  Des choses inimaginables il y a encore six mois sont désormais possibles
  Je mène des projets dans plusieurs langages, et l’IA produit du code si vite que
  désormais, c’est la vitesse de revue qui devient le goulot d’étranglement
  Dès qu’un certain niveau de tests passe, on commence à se demander : « est-ce que c’est suffisant ? »
  Dans mes prompts, je précise des attributs de qualité comme les principes SOLID, le couplage et la cohésion
  Je demande à l’IA des idées de refactoring, et si elles sont bonnes, je dis simplement : « OK, exécute »
  Au final, l’essentiel reste l’art de concevoir les prompts
  Mais je pense que d’ici peu, l’IA appliquera ce type de garde-fous qualité par défaut

  • On m’a aussi demandé pourquoi je travaillais sur des projets dans plusieurs langages
    Le langage lui-même n’est pas le goulot d’étranglement des performances, mais expérimenter de nouveaux langages aide à apprendre

• Cela rappelle la philosophie de Fred Brooks : « build one to throw away »
  L’IA est idéale pour créer rapidement cette première version jetable
  Attendre immédiatement une qualité production est une approche naïve
  La bonne méthode consiste à construire vite, apprendre, puis refactorer ensuite
  Je partage aussi l’idée que, lorsqu’on est fatigué, les prompts deviennent plus flous et les résultats se dégradent

  • Il est toutefois intéressant de noter que Brooks s’est ensuite rapproché de l’idée d’amélioration incrémentale (iterative refinement)

• J’ai été surpris d’apprendre que le parseur SQL de SQLite n’avait pas été généré avec lemon
  Quand j’ai porté pikchr en Go, j’ai d’abord porté lemon, mais SQLite ne construit même pas d’arbre syntaxique
  En lisant la documentation de lemon, on a l’impression qu’il s’agit d’un manque de définition du problème au stade de la conception

• Je suis moi aussi totalement d’accord avec la conclusion de cet article
  C’est un bon exemple qui montre la réalité du AI coding avec honnêteté, sans exagération