[🧑‍💻] Faire vite avec l’IA et faire un travail professionnel, ce n’est pas la même chose

✨ Résumé de GPT-5.6 Sol 　

J’ai accéléré l’implémentation avec l’IA et des harnesses, mais négligé la cohérence de la planification, du design et de la documentation, puis revu mon arrogance devant le travail réalisé dans Figma et le manuel d’une équipe externe.

Il faut vraiment rester humble.

Il y a quelques jours, en voyant un système de travail que l’entreprise avait confié à une équipe externe et dont la réalisation avait pris pas mal de temps, j’ai honnêtement pensé : « Si je l’avais fait, j’aurais terminé beaucoup plus vite… »

La vitesse gagnée avec l’IA et les harnesses

Même si le vibe coding avec l’IA a plusieurs failles, je pensais qu’il pouvait être suffisamment amélioré. En avançant aussi soigneusement que possible sur une base TDD et en construisant de bons harnesses pour éviter la répétition des problèmes, cela devrait être possible. En regardant les Big Tech vraiment engagées dans l’IA, je me suis aussi dit que la part des développeurs qui codent directement pourrait continuer à diminuer.

Bien sûr, cette opinion n’a pas du tout changé. Si l’IA est bien utilisée, si les tests et les harnesses sont correctement posés, et si les structures de prévention de récurrence sont construites avec soin, la vitesse et la qualité du développement peuvent beaucoup changer.

Mais j’ai senti que je devais revenir sur l’arrogance derrière « j’aurais terminé beaucoup plus vite… »

Ces derniers temps, je développe souvent ainsi : je travaille en aller-retour avec des agents, j’améliore continuellement la structure de harness engineering, j’empêche la récurrence de divers problèmes, j’ajoute de nouvelles fonctionnalités, je reçois du feedback et je corrige à nouveau. Pour les tâches répétitives, je crée des agents worker/coordinator et je les exécute.

Mon développement avait oublié la cohérence

Cette routine m’a donné une vitesse de développement élevée et des changements de direction rapides, et elle a plutôt bien empêché la réapparition de problèmes similaires. Mais elle était faible pour relier tout le produit sous une même philosophie de planification et de design. Je pouvais pousser l’implémentation rapidement, mais la cohérence du design, des fonctions et de la planification restait très faible.

Je ne vois pourtant pas cela comme une limite native du vibe coding. C’est plutôt que je n’ai pas encore suffisamment intégré les critères de planification, de design et de documentation dans mon harness engineering.

Le professionnalisme vu dans Figma et le manuel

En revanche, en voyant cette équipe externe utiliser activement Figma pour consigner différentes structures d’écran et conserver des descriptions et des flows, quelque chose est devenu clair. Il y avait un professionnalisme différent de ma manière de foncer sans structure suffisante. La forte cohérence de leurs documents de planification et de leur livrable inspirait une vraie confiance.

Ce professionnalisme apparaissait aussi dans le manuel GitBook. Je pensais seulement : si je construis bien, les utilisateurs se débrouilleront ; si l’UI/UX est intuitive, cela suffira. Je n’avais jamais imaginé créer un guide pour le personnel interne.

Bien sûr, si l’UX est bonne et si les boutons d’aide sont placés exactement là où on les attend, je me demande encore honnêtement si un guide est vraiment nécessaire.

Bref… je pense encore que minimiser l’usage des LLM et coder directement est une culture de développement assez ancienne et difficile à recommander. Mais j’ai clairement compris que je ne suis pas encore à un niveau professionnel qui me permettrait de les prendre de haut et de les descendre en flammes.

Toujours rester humble. Toujours apprendre.