Prompt per programmare con l'IA: codice funzionante

Un prompt per programmare è una specifica. Il modello non ha visto il tuo progetto, non sa quale versione del linguaggio usi e non può chiedere cosa deve succedere quando l'input è vuoto. Tutto ciò che il prompt tralascia, lo riempie con la scelta più comune nei suoi dati di addestramento, e la scelta più comune spesso non è la tua. I prompt qui sotto lasciano al modello meno cose da indovinare.

Scrivi la specifica prima del codice

Il blocco qui sotto chiede una piccola funzione Python. Ogni parte del prompt risponde a una domanda a cui altrimenti risponderebbe il modello al posto tuo. Disattiva le parti una alla volta e immagina la risposta senza di loro: senza i vincoli potresti ricevere una libreria di terze parti, senza il contesto il modello deve indovinare cosa conta come input valido, senza il formato potresti non ricevere test.

Funzione da una specifica

EditCopy

Fill inversione

PartsRoleTaskContextConstraintsFormat

Role

Sei uno sviluppatore Python scrupoloso che scrive funzioni piccole e testate.

Task

Scrivi una funzione `parse_duration(text)` che trasformi una stringa di durata in un numero di secondi.

Context

Gli input validi sono come "1h30m", "45m", "2h" e "90s": ore, minuti e secondi, ciascuno facoltativo, sempre in quest'ordine. "1h30m" restituisce 5400. Qualsiasi altra cosa, compresa una stringa vuota, non è valida.

Constraints

Python 3.11, solo la libreria standard. Solleva ValueError per un input non valido, con l'input nel messaggio. Non accettare decimali come "1.5h".

Format

Dai prima la funzione, poi test pytest che coprano tutti gli esempi qui sopra più tre input non validi. Nessuna spiegazione oltre una frase.

Try it

Example replyReplies vary between models and runs.

La funzione riconosce le tre parti facoltative in ordine e rifiuta una corrispondenza in cui sono vuote tutte e tre.

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)

Quattro dettagli di quel prompt fanno la maggior parte del lavoro:

• Esempi con le loro risposte. "1h30m restituisce 5400" è un test con cui il modello può verificare il proprio codice, ed elimina ogni dubbio sull'unità di misura.
• La versione del linguaggio e le librerie consentite. Senza, potresti ricevere una libreria che non hai installato o una sintassi più recente del tuo interprete.
• Cosa conta come non valido, e cosa deve succedere in quel caso. La gestione degli errori è facile da tralasciare per un modello quando nessuno la chiede.
• I test nella risposta. Trasformano "sembra giusto" in qualcosa che puoi eseguire. Se un test fallisce, incolli il fallimento nella chat, e questo è un seguito molto migliore di "non funziona".

Vale la pena notare anche il controllo any(match.groups()): il pattern da solo accetta una stringa vuota, perché ogni parte è facoltativa. È la riga del prompt sulla stringa vuota che fa comparire quel caso nel codice e nei test.

Indica la versione, lo stack e ciò che esiste già

I modelli tendono verso lo stile più comune nei loro dati di addestramento. In JavaScript questo può significare require di CommonJS in un progetto che usa i moduli ES; in Python, l'API di una libreria che nel frattempo è cambiata (Pydantic 1 contro 2 è un caso comune); e in qualsiasi framework che evolve in fretta, lo schema di due versioni principali fa. Di solito basta una riga: "Node 22, moduli ES, niente TypeScript" oppure "React 19, componenti funzione, semplici CSS modules".

Quando aggiungi qualcosa a un progetto esistente, il modello deve vedere le parti che il nuovo codice toccherà. Incolla la firma della funzione che deve chiamare, la forma dei dati che riceverà e un file esistente che mostri le tue convenzioni. "Usa l'helper db.query(sql, params) dal file qui sotto" ottiene codice che si integra; senza, potresti ricevere una connessione al database scritta da zero. Lascia fuori i file che non hanno niente a che fare con la modifica, perché ogni riga non collegata è qualcosa che il modello potrebbe provare a riusare.

Chiedi un piccolo passo alla volta

L'errore più comune nel "vibe coding", costruire un'app descrivendola a un'IA, è chiedere tutta l'app in una volta. Il modello deve scegliere un framework, un database, una struttura di cartelle e una dozzina di funzionalità in una sola risposta, e una sola risposta raramente contiene codice funzionante per tutto questo, quindi spesso quello che arriva è uno schema. Confronta le due schede.

Tutta l'app in una voltaUn piccolo passo

EditCopy

Creami un'app di to-do con account utente, un database, promemoria e modalità scura.

Try it

Example replyReplies vary between models and runs.

Ecco un'app di to-do full stack con React, Node.js con Express e MongoDB.

Struttura del progetto

todo-app/
  client/   (front end in React)
  server/   (API Express, autenticazione, promemoria)

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

Per l'autenticazione puoi aggiungere JWT con jsonwebtoken, e per i promemoria uno scheduler come node-cron. Fammi sapere se vuoi che completi qualcuna di queste parti.

La prima risposta non è sbagliata, ma è uno scheletro: ha scelto tre tecnologie al posto tuo e ha lasciato il lavoro vero sotto forma di commenti. La seconda è abbastanza breve da leggerla, funziona appena apri il file e ti dà una base funzionante per il passo 2 ("ora salva l'elenco in localStorage così sopravvive a un ricaricamento"). Ogni passo è abbastanza piccolo che, quando qualcosa si rompe, sai quale modifica l'ha rotto.

Questo è prompt chaining fatto a mano: l'output di una richiesta diventa il punto di partenza della successiva. Incolla la versione attuale del file in ogni nuovo passo, così il modello modifica il codice che hai davvero e non quello che ricorda di aver scritto.

Chiedi un piano prima di una modifica grande

Per qualsiasi cosa più grande di una funzione, chiedi prima il piano e poi il codice: "Elenca i file che modificheresti e cosa fa ogni modifica. Non scrivere ancora codice." Un piano si legge in fretta e si corregge in fretta. Se propone una nuova dipendenza che non vuoi o dimentica un file che sai essere coinvolto, lo sistemi con una frase invece di scoprirlo in mezzo a trecento righe di codice.

Controlla quello che ricevi

Il codice generato fallisce in pochi modi prevedibili, e per ognuno c'è un'abitudine di prompting che lo intercetta:

• API inventate. Un modello può chiamare una funzione o importare un pacchetto che non esiste, perché il nome suona plausibile. Cerca gli import che non conosci prima di installarli; allucinazioni dell'IA spiega perché succede.
• Casi limite silenziosi. Codice che funziona nel caso ideale e va in crash con una lista vuota. Elencare i casi limite nel prompt e chiedere i test è la soluzione più economica.
• Modifiche nascoste. Quando chiedi una correzione in un file lungo, il modello potrebbe anche rinominare cose o riorganizzare codice di cui non hai parlato. Aggiungi "cambia solo ciò che serve ed elenca ogni modifica che hai fatto".

Quando il codice gira ma si comporta male, passa a un prompt di debugging: prompt per il debugging spiega cosa incollare. Prima di fare il merge di qualcosa di importante, una seconda passata con un prompt di code review può scovare problemi a cui il prompt di scrittura non aveva pensato.