Faut-il être plus ambitieux en développement logiciel ? Le débat du post-IA
Sommaire
En bref
- Dan Luu commente pgrust et d'autres projets qui repoussent les limites techniques classiques, rendus possibles par les capacités accrues (LLMs, accélérateurs, outils modernes).
- L'idée centrale : les développeurs peuvent maintenant tenter des choses qui semblaient auparavant trop ambitieuses, mais la vraie question est ce qu'on en fait.
- Le débat HN se divise entre ceux qui voient une opportunité de bâtir différemment et ceux qui craignent que l'ambition technique ne remplace pas l'ambition produit.
Ce que dit la source
Luu observe que Michael Malis et d'autres construisent des projets (pgrust, optimisations du compilateur Rust, moteurs regex sur mesure) autrefois jugés trop importants en envergure pour être faisables par une ou deux personnes. Son argument : les outils modernes (LLMs notamment) ont tellement accéléré certains flux de travail que des réécriture entières, des optimisations profondes, deviennent réalisables en heures ou en jours au lieu de mois. Même si pgrust échoue à court terme, les bugs Postgres qu'il a découverts valent déjà l'effort. Luu reconnaît que 99 % des projets IA-générés sont du bruit, mais c'est sans conséquence pour un bâtisseur : l'existence de beaucoup de mauvaises choses ne doit pas décourager de faire une bonne chose.
- pgrust a découvert plusieurs bugs sérieux en Postgres (memory safety, numerical, cache format, JSONPath) simplement en testant la couverture du code, montrant qu'une tentative sérieuse améliore l'écosystème même avant un lancement complet.
- Les tâches autrefois laborieuses (regex optimisé, fork ripgrep, modifications du compilateur Rust) ont pris à Luu un single-digit nombre d'heures, quand elles auraient exigé un an ou plus par le passé.
- Hitachi fabrique une pompe à chaleur à 8 000 euros avec des constantes hardcodées qui ne peuvent pas être modifiées et refuse de supporter des fonctionnalités qui figurent dans son propre marketing.
- Plusieurs commentateurs font remarquer que mvp zéro problème : les complications arrivent après, quand il faut gérer intégrations, clients, sécurité, données, maintenant le logiciel s'avère où LLMs aident mais ne résolvent pas seuls.
- Un critique note que reécrire Postgres ou ripgrep est techniquement ambitieux mais n'est pas ambitieux en tant que produit : c'est simplement optimiser une spécification existante.
Dans les commentaires
Débat polarisé mais substantiel : d'un côté, plusieurs commentateurs décrivent des projets réels rendus viables par les LLMs et posent la question légitime de la création de valeur (pas juste la performance) ; de l'autre, plusieurs expriment un scepticisme solide sur la distinction entre l'ambition technique et l'ambition produit, et pointent du doigt la glut de démos sans suite réelle.
- Plusieurs commentateurs contestent que reécrire Postgres ou optimiser ripgrep soit réellement ambitieux : c'est exécuter une spécification connue plus vite, pas inventer quelque chose de nouveau. Un commentateur demande explicitement « quelle est l'une chose que seul vous pouvez spécifier ? »
- Un courant du fil souligne que LLMs résolvent le « 0 à MVP » mais échouent ou demandent du travail humain massif après : gestion de produit, intégrations, sécurité, support client, communication. L'auteur Luu laisse ce sujet de côté.
- Un commentateur fait remarquer que pgrust est une réécriture, pas une innovation ; il interroge si chaque développeur doit construire sa propre Postgres pour « prouver » qu'il est bon, et exprime une certaine fatigue face au ton émotif autour de ces projets IA-générés.
- Une tension implicite sur les orgs : les grandes entreprises optimisent pour réduire les coûts (« 10 devs → 2 ») au lieu de redéfinir ce qu'elles construisent, tandis que les startups bougent plus vite avec des rôles fluides ; peu d'accord sur le chemin à suivre.
Notre lecture
Luu pointe quelque chose de réel : les LLMs et les accélérateurs ont abaissé des barrières techniques qui semblaient insurmontables il y a deux ans. Mais le débat révèle une faille dans le raisonnement. Être capable de faire pgrust en moins de temps ne fait pas de pgrust quelque chose qu'il faut faire. La vraie ambition n'est pas la capacité technique, c'est la pertinence produit. Luu lui-même construit un regex optimisé pour son cas personnel et une fork ripgrep « juste pour s'amuser » : c'est intéressant, mesurable, mais pas ambitieux au sens où on réinvente un besoin. Les commentaires les plus solides pointent que post-MVP reste un gouffre d'ingénierie produit que les LLMs ne comblent pas. Pour une DSI ou un lead technique : cela vaut d'explorer ces nouveaux outils pour accélérer les vraies ambitions (nouvelles catégories, intégrations complexes, architectures hardened), mais pas de confondre vitesse d'exécution et clarté du problème à résoudre.