Ça dépend énormément de la façon de l’utiliser. Perso je demande à mes agents IA d’expliquer ce qu’ils font, me montrer leurs plans, me dire ce qui se passe dans tel scénario, etc. Quand ils me demandent que faire entre deux possibilités, il m’arrive d’en choisir une troisième. Bref, coding with IA ≠ vibe coding.
Je trouve aussi qu’on ne mentionne pas assez les autres utilisations des IA.
- gestion de versions: dire à un agent « rebase onto origin/main » et le voir résoudre tout seul des conflits qui auraient pu me faciliter le transit intestinal prendre des heures, franchement, c’est un pur bonheur.
- enquête sur des tests parfois rouges et parfois verts : ça ne dérange pas un agent de lancer mille fois mille tests... je veux dire, mille agents de lancer un test mille fois... bon, je vais prendre un chewing-gum.
- relecture de code : recherche de bugs, de scénarios non testés, de commentaires erronés...
- smoke testing : j’ai une API dont la doc n’est pas forcément hyper fiable, je dis à un agent de jouer différents scénarios et me dire ce qui est vraiment pris en compte ou renvoyé (en-têtes, statuts HTTP, structure réelle du payload...). Autant de bugs évités si le comportement réel est légèrement différent de ce à quoi on s’attendrait (API qui ne suit pas exactement les bonnes pratiques...).
# non
Posté par hippocampe . En réponse au journal Un code généré par IA est-il obligatoirement du "AI slop" ?. Évalué à 0 (+2/-2).
Ça dépend énormément de la façon de l’utiliser. Perso je demande à mes agents IA d’expliquer ce qu’ils font, me montrer leurs plans, me dire ce qui se passe dans tel scénario, etc. Quand ils me demandent que faire entre deux possibilités, il m’arrive d’en choisir une troisième. Bref, coding with IA ≠ vibe coding.
Je trouve aussi qu’on ne mentionne pas assez les autres utilisations des IA.
- gestion de versions: dire à un agent « rebase onto origin/main » et le voir résoudre tout seul des conflits qui auraient pu me faciliter le transit intestinal prendre des heures, franchement, c’est un pur bonheur.
- enquête sur des tests parfois rouges et parfois verts : ça ne dérange pas un agent de lancer mille fois mille tests... je veux dire, mille agents de lancer un test mille fois... bon, je vais prendre un chewing-gum.
- relecture de code : recherche de bugs, de scénarios non testés, de commentaires erronés...
- smoke testing : j’ai une API dont la doc n’est pas forcément hyper fiable, je dis à un agent de jouer différents scénarios et me dire ce qui est vraiment pris en compte ou renvoyé (en-têtes, statuts HTTP, structure réelle du payload...). Autant de bugs évités si le comportement réel est légèrement différent de ce à quoi on s’attendrait (API qui ne suit pas exactement les bonnes pratiques...).