Réécriture du parseur Recursive Descent de pycparser à l’aide d’un agent de codage LLM

Résumé :

• Cet article décrit le processus de remplacement complet de pycparser, un parseur du langage C fonctionnant depuis près de 20 ans sur la base de PLY (Python Lex-Yacc), par un parseur Recursive Descent écrit manuellement avec l’aide d’un agent de codage LLM (Codex).
• Le projet a permis de supprimer la dépendance externe à PLY, de réduire la difficulté de maintenance et d’améliorer les performances de 30 %, démontrant ainsi l’utilité concrète des LLM pour le refactoring de grands volumes de code legacy.
• Il souligne aussi l’importance des revues itératives menées par un développeur humain et du prompt engineering pour corriger les problèmes de qualité du code généré par le LLM, notamment en matière de lisibilité et de complexité.

Résumé détaillé :

1. Contexte et motivation
   pycparser est un important projet open source qui enregistre environ 20 millions de téléchargements par jour. Jusqu’ici, il utilisait la bibliothèque PLY pour traiter la grammaire C99, mais plusieurs problèmes se sont accumulés :

• Problème de dépendance : la bibliothèque PLY n’étant plus maintenue (archivée), elle créait des risques en matière de sécurité et de maintenance.
• Complexité grammaticale : avec la prise en charge des standards récents comme C11 et C23 ainsi que des extensions de grammaire, les conflits reduce-reduce propres à YACC sont devenus fréquents, rendant les extensions difficiles.
• Évolution philosophique : avec le temps, l’auteur s’est convaincu qu’un parseur Recursive Descent écrit à la main offrait plus d’avantages qu’un parser generator en matière de compréhension et de maintenance.

2. Processus de collaboration avec le LLM (Codex)
   L’auteur a décidé de confier ce travail au LLM, estimant qu’il lui faudrait plus d’une semaine pour le faire seul. La robuste suite de tests de plus de 2 500 lignes de pycparser a servi de garde-fou pour valider les résultats du LLM.

• Portage initial : à partir du prompt « laisse le lexer tel quel et remplace uniquement le parser par un Recursive Descent », Codex a travaillé pendant plus d’une heure et a produit un prototype qui passait les tests.
• Améliorations itératives : le code initial était fonctionnellement parfait, mais sa lisibilité était faible et il abusait de la gestion des exceptions pour contrôler le flux d’exécution, entre autres défauts de qualité. L’auteur a largement utilisé les branches Git et affiné le code au fil de dizaines de commits.

3. Résultats et enseignements

• Gain de performance : le parseur écrit manuellement s’est révélé environ 30 % plus rapide que l’ancienne version basée sur YACC.
• Qualité du code et maintenance : les LLM ont tendance à produire du code paresseux ou complexe, mais ils répondent efficacement lorsque le développeur donne des consignes claires (par exemple « remplace X par Y », « ajoute des commentaires »).
• Importance du typage statique : lors d’un travail ultérieur, l’ajout d’annotations de type Python a amélioré la précision des propositions du LLM. L’auteur anticipe que les agents de codage seront encore plus performants à l’avenir dans des langages fortement typés comme Rust ou TypeScript.

4. Conclusion
   À travers ce projet, l’auteur a confirmé que les LLM ne sont pas de simples gadgets, mais des outils capables d’augmenter concrètement la productivité par un facteur supérieur à 10. Une tâche qui aurait demandé environ 30 à 40 heures a été terminée en 4 à 5 heures, et l’auteur évalue très positivement la valeur des LLM comme catalyseurs aidant les développeurs à entrer dans le flow.