Relax. Planifiez avant de rédiger vos prompts.

J'ai récemment compris quelque chose au sujet d'un ancien gestionnaire.

Il essayait sans cesse de me convaincre d'utiliser Kiro.

« Bassel, utilise Kiro. »

Ma réaction immédiate était simple :

« C'est quoi, ce foutu Kiro? »

À l'époque, je ne comprenais pas pourquoi il insistait. Je savais déjà travailler avec l'IA. Discrètement, et en mettant temporairement de côté toute l'humilité nécessaire, j'avoue que je suis très bon pour rédiger des prompts.

Je peux parcourir visuellement un projet, comprendre sa structure, donner des instructions détaillées à un agent IA et le regarder réaliser quelque chose de complexe à une vitesse surprenante. Je n'ai souvent pas besoin de répondre à vingt questions de suivi. Je sais fournir suffisamment de contexte dès le départ.

Le résultat apparaît. Ça fonctionne. Deux petites hallucinations se cachent peut-être quelque part, mais rien ne semble brisé lors de mon inspection rapide.

Alors, je livre.

Rapide. Propre. Terminé.

Du moins, c'est ce que je me disais.

Mon gestionnaire avait remarqué le problème

Un bon gestionnaire ne fait pas que célébrer votre rapidité. Il remarque les habitudes qui pourraient finir par transformer cette rapidité en problème.

Mon ancien gestionnaire comprenait que je pouvais obtenir rapidement des résultats avec l'IA. Il comprenait aussi quelque chose qui m'échappait : produire du code fonctionnel et comprendre la solution complète sont deux réussites différentes.

C'est pour cela qu'il répétait :

« Bassel, utilise Kiro. »

Kiro écrit du code comme bien d'autres outils d'IA. Sa vraie valeur vient du fait qu'il vous encourage à définir le travail avant de demander à l'IA de l'exécuter.

Son processus de spécification peut décomposer une fonctionnalité en exigences, en conception technique et en tâches de réalisation avant le début du codage. Selon la situation, il peut partir du comportement souhaité ou de l'architecture technique. La documentation officielle de Kiro décrit ce processus comme un parcours structuré de l'idée à la réalisation.

En termes simples, Kiro me forçait à planifier.

Et apparemment, j'avais besoin qu'on m'y force.

Rédiger des prompts et planifier sont des compétences différentes

Un bon prompt peut contenir beaucoup de détails. Il peut décrire la base de données, l'interface, la validation, les tests, la sécurité et le comportement attendu.

Un prompt détaillé peut quand même cacher une réflexion insuffisante.

Quand tout est regroupé dans une immense instruction, il devient facile de manquer des contradictions. Vous pouvez demander deux fonctionnalités qui ne peuvent pas coexister proprement. Vous pouvez décrire le scénario idéal en oubliant les permissions, les situations d'échec, les migrations, l'accessibilité ou la rétrocompatibilité.

Puis l'IA commence immédiatement la réalisation.

La vitesse est impressionnante, mais elle peut masquer l'incertitude. Vous regardez les fichiers apparaître, les tests s'exécuter et les composants s'afficher. Ce mouvement donne l'impression que le problème a déjà été compris.

Parfois, il a seulement été interprété.

La planification crée une pause entre le désir de quelque chose et sa réalisation. Pendant cette pause, vous pouvez demander :

• Quel problème cherchons-nous vraiment à résoudre?
• Quel comportement le système doit-il prendre en charge?
• Que doit-il explicitement refuser de faire?
• Quelles décisions influencent l'architecture?
• Qu'est-ce qui pourrait briser les fonctionnalités existantes?
• Comment saurons-nous que la réalisation est correcte?

Kiro formalise cette pause. Son processus axé d'abord sur les exigences produit des exigences, une conception technique et une liste de tâches à réviser avant l'exécution. La conception peut couvrir les composants, les modèles de données, les interfaces, la gestion des erreurs et la stratégie de test. Le guide de Kiro sur l'approche axée sur les exigences explique cette progression.

L'IA effectue toujours une grande partie du travail. La différence, c'est que vous avez plusieurs occasions de repérer les mauvaises hypothèses avant qu'elles deviennent du code.

Le problème de la restauration rapide

Pensez aux prompts sans planification comme à de la restauration rapide.

Vous avez faim. Vous commandez quelque chose. Ça arrive presque immédiatement. C'est bon, et le problème immédiat disparaît.

Vous n'avez pas appris comment le repas a été préparé. Vous ne savez pas nécessairement ce qu'il contient. Vous ne remarquez peut-être même pas ce qui manque, parce que votre attention est concentrée sur la rapidité avec laquelle la faim a disparu.

C'est ce qu'on peut ressentir quand l'IA réalise quelque chose rapidement.

Vous demandez une fonctionnalité. Elle apparaît. Vous la parcourez deux fois. Rien n'explose.

Livré.

Mais qu'avez-vous appris?

Comprenez-vous pourquoi la base de données a été structurée ainsi? Pouvez-vous expliquer le modèle d'autorisation? Savez-vous quelles hypothèses l'agent a faites? Que se passe-t-il quand un autre développeur doit modifier la fonctionnalité six mois plus tard?

La restauration rapide a sa place. Parfois, c'est exactement ce qu'il vous faut. Les prototypes, les expériences, les outils jetables et les idées préliminaires n'exigent pas toujours de spécification formelle.

L'erreur commence quand on en mange chaque jour en appelant ça de la nutrition.

Les deux hallucinations « inoffensives »

Je traitais les petites hallucinations de l'IA comme du bruit de fond.

L'IA a mal compris deux détails? Très bien. La fonctionnalité marche quand même.

Une hallucination peut survivre à un test rapide et causer des dégâts plus tard. Un champ de base de données fabriqué, une hypothèse incorrecte sur une API, une règle de permission incomplète ou un comportement de cadriciel inventé peuvent rester discrets jusqu'à la mise en production.

Les bogues les plus dangereux semblent souvent tout à fait raisonnables. Ils représentent des décisions que personne n'a prises consciemment.

Une étape de planification rend ces décisions visibles.

Au lieu de découvrir une hypothèse dans une demande de fusion contenant trente fichiers modifiés, vous pouvez la repérer dans un document d'exigences ou de conception, quand elle tient encore en une phrase.

C'est beaucoup moins coûteux à corriger.

La rapidité reste précieuse

Je garde les prompts rapides dans ma façon de travailler. C'est l'une de mes forces, et il serait insensé de prétendre le contraire.

La leçon, c'est que la vitesse gagne en valeur quand elle a une direction.

Planifier n'exige pas de passer trois semaines à rédiger un document pour un bouton. L'effort de planification doit correspondre au risque et à la complexité de la tâche. Kiro propose même des processus de spécification plus rapides lorsqu'un processus d'approbation complet serait excessif. Sa documentation sur les spécifications distingue les spécifications détaillées de fonctionnalités, les spécifications rapides et les processus de correction de bogues.

L'objectif est une exécution réfléchie, sans bureaucratie inutile.

Pour un petit ajustement visuel, donnez vos instructions et avancez. Pour l'authentification, les paiements, l'architecture de base de données, les permissions, les migrations ou une fonctionnalité qui façonnera le reste du produit, ralentissez.

Définissez les exigences.

Révisez la conception.

Découpez le travail en tâches.

Puis laissez l'IA aller vite.