Prompts pour coder : obtenir du code qui marche

Un prompt de code est une spécification. Le modèle n'a pas vu votre projet, ne sait pas quelle version du langage vous utilisez et ne peut pas demander ce qui doit se passer quand l'entrée est vide. Tout ce que le prompt omet, il le remplit avec le choix le plus courant de ses données d'entraînement, et ce choix le plus courant n'est souvent pas le vôtre. Les prompts ci-dessous laissent au modèle moins de choses à deviner.

Écrire la spécification avant le code

Le bloc ci-dessous demande une petite fonction Python. Chaque partie du prompt répond à une question que le modèle trancherait sinon à votre place. Désactivez les parties une par une et imaginez la réponse sans elles : sans les contraintes, vous risquez d'obtenir une bibliothèque tierce ; sans le contexte, le modèle doit deviner ce qui compte comme une entrée valide ; sans le format, vous risquez de n'avoir aucun test.

Une fonction à partir d'une spécification

EditCopy

Fill inversion

PartsRoleTaskContextConstraintsFormat

Role

Tu es un développeur Python rigoureux qui écrit de petites fonctions testées.

Task

Écris une fonction `parse_duration(text)` qui transforme une chaîne de durée en nombre de secondes.

Context

Les entrées valides ressemblent à "1h30m", "45m", "2h" et "90s" : heures, minutes et secondes, chacune facultative, toujours dans cet ordre. "1h30m" renvoie 5400. Tout le reste, y compris une chaîne vide, est invalide.

Constraints

Python 3.11, bibliothèque standard uniquement. Lève une ValueError pour une entrée invalide, avec l'entrée dans le message. N'accepte pas les décimales comme "1.5h".

Format

Donne d'abord la fonction, puis des tests pytest qui couvrent chaque exemple ci-dessus plus trois entrées invalides. Pas d'explication au-delà d'une phrase.

Try it

Example replyReplies vary between models and runs.

La fonction reconnaît les trois parties facultatives dans l'ordre et rejette une correspondance où les trois sont vides.

import re

_PATTERN = re.compile(r"(?:(\d+)h)?(?:(\d+)m)?(?:(\d+)s)?")

def parse_duration(text: str) -> int:
    match = _PATTERN.fullmatch(text)
    if not match or not any(match.groups()):
        raise ValueError(f"invalid duration: {text!r}")
    hours, minutes, seconds = (int(g) if g else 0 for g in match.groups())
    return hours * 3600 + minutes * 60 + seconds

import pytest
from duration import parse_duration

@pytest.mark.parametrize("text, expected", [
    ("1h30m", 5400), ("45m", 2700), ("2h", 7200), ("90s", 90),
])
def test_valid(text, expected):
    assert parse_duration(text) == expected

@pytest.mark.parametrize("text", ["", "1m1h", "1.5h"])
def test_invalid(text):
    with pytest.raises(ValueError):
        parse_duration(text)

Quatre détails de ce prompt font l'essentiel du travail :

• Des exemples avec leur réponse. "1h30m renvoie 5400" est un test que le modèle peut appliquer à son propre code, et il lève tout doute sur l'unité.
• La version du langage et les bibliothèques autorisées. Sans elles, vous risquez d'obtenir une bibliothèque que vous n'avez pas installée ou une syntaxe plus récente que votre interpréteur.
• Ce qui est invalide, et ce qui doit alors se passer. La gestion des erreurs est facile à oublier pour un modèle quand personne ne la demande.
• Des tests dans la réponse. Ils transforment "ça a l'air juste" en quelque chose que vous pouvez exécuter. Si un test échoue, vous recollez l'échec, ce qui est une bien meilleure relance que "ça ne marche pas".

Le test any(match.groups()) mérite aussi l'attention : le motif seul accepte une chaîne vide, puisque chaque partie est facultative. C'est la ligne du prompt sur la chaîne vide qui fait apparaître ce cas dans le code et dans les tests.

Nommer la version, la stack et ce qui existe déjà

Les modèles penchent vers le style le plus courant de leurs données d'entraînement. En JavaScript, cela peut signifier des require CommonJS dans un projet qui utilise les modules ES ; en Python, une API de bibliothèque qui a changé depuis (Pydantic 1 contre 2 est un cas fréquent) ; et pour tout framework qui évolue vite, le motif d'il y a deux versions majeures. Une ligne suffit en général : "Node 22, modules ES, pas de TypeScript" ou "React 19, composants fonctions, modules CSS simples".

Quand vous ajoutez du code à un projet existant, le modèle doit voir les parties que le nouveau code va toucher. Collez la signature de la fonction qu'il doit appeler, la forme des données qu'il recevra et un fichier existant qui montre vos conventions. "Utilise l'utilitaire db.query(sql, params) du fichier ci-dessous" donne du code qui s'intègre ; sans cela, vous risquez d'obtenir une nouvelle connexion à la base de données écrite de zéro. Laissez de côté les fichiers sans rapport avec la modification, car chaque ligne étrangère est quelque chose que le modèle peut essayer de réutiliser.

Demander une petite étape à la fois

L'échec le plus courant du "vibe coding", construire une application en la décrivant à une IA, consiste à demander toute l'application d'un coup. Le modèle doit choisir un framework, une base de données, une arborescence et une dizaine de fonctionnalités en une seule réponse, et une réponse unique contient rarement du code fonctionnel pour tout cela : ce qui revient est souvent un squelette. Comparez les deux onglets.

Toute l'appli d'un coupUne petite étape

EditCopy

Fais-moi une appli de todo avec comptes utilisateurs, base de données, rappels et mode sombre.

Try it

Example replyReplies vary between models and runs.

Voici une application de todo full stack avec React, Node.js avec Express et MongoDB.

Structure du projet

todo-app/
  client/   (front end React)
  server/   (API Express, authentification, rappels)

server/index.js

const express = require("express");
const mongoose = require("mongoose");
const app = express();
app.use(express.json());
// ... auth routes, todo routes and the reminder scheduler go here

Pour l'authentification, vous pouvez ajouter des JWT avec jsonwebtoken, et pour les rappels un planificateur comme node-cron. Dites-moi si vous voulez que je complète l'une de ces parties.

La première réponse n'est pas fausse, mais c'est un squelette : elle a choisi trois technologies à votre place et laissé le vrai travail sous forme de commentaires. La seconde est assez courte pour être lue, fonctionne dès que vous ouvrez le fichier et vous donne une base solide pour l'étape 2 ("maintenant, enregistre la liste dans localStorage pour qu'elle survive à un rechargement"). Chaque étape est assez petite pour que, quand quelque chose casse, vous sachiez quelle modification l'a cassé.

C'est du chaînage de prompts fait à la main : la sortie d'une demande devient le point de départ de la suivante. Collez la version actuelle du fichier à chaque nouvelle étape, pour que le modèle modifie le code que vous avez réellement et non celui qu'il se souvient avoir écrit.

Demander un plan avant une grosse modification

Pour tout ce qui dépasse une fonction, demandez d'abord le plan et ensuite le code : "Liste les fichiers que tu modifierais et ce que fait chaque modification. N'écris pas encore de code." Un plan se lit et se corrige vite. S'il propose une nouvelle dépendance dont vous ne voulez pas ou oublie un fichier que vous savez concerné, vous le corrigez en une phrase au lieu de le découvrir à travers trois cents lignes de code.

Vérifier ce qui revient

Le code généré échoue de quelques façons prévisibles, et à chacune correspond une habitude de prompt qui la repère :

• Des API inventées. Un modèle peut appeler une fonction ou importer un paquet qui n'existe pas, parce que le nom sonne plausible. Vérifiez les imports inconnus avant de les installer ; hallucinations de l'IA explique pourquoi cela arrive.
• Des cas limites passés sous silence. Du code qui marche dans le cas nominal et plante sur une liste vide. Lister les cas limites dans le prompt, et demander des tests, est la solution la moins coûteuse.
• Des modifications discrètes. Quand vous demandez une correction dans un long fichier, le modèle peut aussi renommer des choses ou réorganiser du code sur lequel vous n'aviez rien demandé. Ajoutez "ne modifie que ce qui est nécessaire et liste chaque modification faite".

Quand le code tourne mais se comporte mal, passez à un prompt de débogage : prompts pour déboguer explique quoi coller. Avant de fusionner quoi que ce soit d'important, une seconde passe avec un prompt de revue de code peut repérer des problèmes auxquels le prompt d'écriture n'avait pas pensé.