Ogni pochi mesi la disciplina viene ribattezzata e dichiarata obsoleta. Nel 2023 il lavoro era il prompt engineering, e Andrej Karpathy poteva dire che "il nuovo linguaggio di programmazione più caldo è l'inglese". Nel 2025 il consenso si era già spostato: Tobi Lütke di Shopify sosteneva che "context engineering descrive molto meglio la competenza centrale", perché quello che metti nella finestra di contesto conta più di come formuli la richiesta. Nel 2026 la cornice è cambiata di nuovo, verso l'harness engineering, riassunto dalla regola di Mitchell Hashimoto per gli agenti: "ogni volta che l'agente commette un errore, cambia il sistema in modo che quell'errore non possa più ripetersi a livello strutturale" [1].
Ogni nuovo nome arriva con lo stesso sottotesto: la vecchia competenza è morta, impara quella nuova. Penso che questa lettura sia sbagliata, e che seguirla ti costi. Il prompt engineering non è morto. È stato declassato da "tutto il lavoro" a un componente di un sistema più grande, e si dà il caso che sia il componente più economico, più portabile e a più alto rendimento che possiedi. Se sei un solo dev o un piccolo team, questa è la buona notizia, e quasi nessuno la racconta così.
Voglio renderlo concreto, perché "harness engineering" suona come una disciplina enterprise che richiede un platform team, e alla tua scala non è affatto così.
Le tre ere, e cosa è cambiato davvero
Aiuta vedere la progressione come un unico arco, non come tre mode passeggere [1]:
Prompt engineering (dal 2022 al 2024): "Cosa dovrei dire?" La convinzione era che la qualità delle istruzioni decidesse il risultato. Chain-of-thought, ReAct, esempi few-shot. Mettevi a punto la formulazione a mano e speravi.
Context engineering (2025): "Cosa dovrei mostrargli?" Una volta che i modelli hanno ottenuto tool use, memoria e retrieval, la formulazione contava meno di quello che riempiva la finestra: i documenti giusti, la cronologia giusta, le descrizioni dei tool giuste, strutturati in modo che il modello potesse usarli.
Harness engineering (dal 2026 in poi): "Quale sistema dovrei costruirci attorno?" Gli agenti iterano, chiamano tool e falliscono in modi che un singolo prompt non può correggere. Il lavoro si è spostato sull'impalcatura: i guardrail, i controlli, i cicli di feedback che intercettano un errore e lo rendono impossibile la volta dopo.
L'evoluzione dal prompt engineering al context engineering all'harness engineering, ogni era avvolge la precedente, con il prompt come componente più economico e portabile che possiedi
Nota cosa non è successo a nessuno di questi passaggi: la competenza precedente non è sparita. Il rigore ingegneristico si è spostato. È esattamente il percorso che il software ha sempre seguito, dai documenti di design ai type checker alle suite di test automatici. Ogni strato non ha sostituito il precedente: lo ha avvolto.
La definizione utile di harness è quella brutale: l'harness è tutto ciò che c'è nell'agente tranne il modello [1]. Il modello è il cervello in affitto. L'harness è tutto quello che gli costruisci intorno perché quel cervello in affitto produca lavoro affidabile. E quel "tutto" si ordina in quattro caselle:
Feedforward deterministico: regole che imposti prima dell'esecuzione. Un file .cursorrules, un template di system prompt, una guida di stile che il modello deve seguire.
Feedback deterministico: macchine che giudicano l'output in modo oggettivo. Compilatori, linter, type checker, suite di test.
Feedforward non deterministico: le istruzioni e i vincoli in linguaggio naturale. È qui che vivono i prompt.
Feedback non deterministico: un LLM che giudica l'output prodotto da un LLM. Scoring, eval, il controllo "è davvero buono" che nessun compilatore può fare.
I tuoi prompt possono migliorare. Promptimizer li riscrive e li testa automaticamente.
Un harness lo gestisci già. Solo che non lo chiamavi così
Ecco la parte che la cornice enterprise nasconde ai solo dev. Non devi adottare l'harness engineering. Lo stai già facendo, probabilmente per caso.
Se hai un .cursorrules o un CLAUDE.md nel repo, quello è feedforward deterministico. Se la tua CI esegue un linter e una suite di test prima di fare merge del codice scritto dall'agente, quello è feedback deterministico, ed è il guardrail più potente che hai, perché è oggettivo e gratuito. Se tieni un prompt riusabile che incolli in ogni code review, quello è feedforward non deterministico. Se guardi l'output a occhio e rilanci quando è debole, quella è una versione grezza e manuale di feedback non deterministico.
Quindi la domanda per un piccolo team non è mai "dovrei costruire un harness". Ce l'hai. L'unica domanda è se sia deliberato o accidentale. Un harness accidentale è il prompt che vive in tre file, la regola di lint che nessuno applica, l'eval che esegui a mente e poi dimentichi. Un harness deliberato sono gli stessi componenti, resi espliciti, versionati e riusati. Il divario tra i due non è il budget. È la disciplina, e la disciplina è l'unico input di cui un solo dev dispone tanto quanto un platform team.
La casella più economica da rendere deliberata è il prompt
Guarda di nuovo i quattro quadranti e chiediti dove vanno i tuoi soldi e il tuo tempo. Il feedback deterministico, i compilatori e i linter, lo ottieni perlopiù gratis dalla tua toolchain: esiste già e funziona già. Il feedback non deterministico, gli eval veri, è l'angolo costoso: costruire un set di test rappresentativo e fare scoring richiede impegno, e la maggior parte dei piccoli team ci investe troppo poco.
Ma il rendimento più alto a fronte del costo più basso sta nella colonna del feedforward, e in particolare nel prompt stesso. Un prompt è economico da scrivere, economico da cambiare, e plasma tutto ciò che sta a valle. È anche il componente che viaggia con te quando il modello sottostante cambia, cosa che, come ho già sostenuto, ora succede più o meno ogni due settimane. Il modello è in affitto e viene rimpiazzato di continuo. Il compilatore appartiene al tuo linguaggio. Il prompt è la parte dell'harness che è genuinamente tua, portabile su ogni modello verso cui farai routing.
Ecco perché "il prompt engineering è morto" è esattamente al contrario. In un mondo dove il modello è una commodity e l'harness è il moat, il prompt è il pezzo portante del moat che possiedi davvero e ti porti dietro. Declassarlo a "tutto il lavoro" è sempre stato troppo credito. Liquidarlo adesso è troppo poco.
C'è una trappola da nominare. Il fatto che il prompt sia economico da cambiare è anche ciò che lo rende facile da lasciar marcire. Economico da cambiare significa che tutti lo cambiano, ognuno nella propria copia, per il proprio modello, e sei settimane dopo hai cinque fork e nessuna idea di quale sia quello canonico. L'economicità è un vantaggio solo se la abbini all'unica regola che le impedisce di degenerare in caos: una singola fonte di verità.
Le tecniche che stai leggendo funzionano. Testa subito i tuoi prompt con Prompt Score e vedi il punteggio in tempo reale.
Un harness minimo che un solo dev può davvero gestire
Non ti serve una piattaforma. Ecco l'harness più piccolo che gestirei sopra un qualsiasi workflow basato su LLM, mappato sui quattro quadranti così vedi la copertura. Buona parte la hai forse già; il punto è rendere ogni casella deliberata invece che accidentale.
L'harness a quattro quadranti per un solo dev: feedforward e feedback deterministico e non deterministico, con il prompt evidenziato come l'unica casella che possiedi e ti porti dietro tra i modelli
Scrivi le tue regole una volta sola (feedforward deterministico). Un CLAUDE.md o .cursorrules per progetto, che tenga le convenzioni che il modello continua a sbagliare. Ogni volta che l'agente commette lo stesso errore, aggiungi una riga. È la regola di Hashimoto applicata alla scala del solo dev: cambia il sistema perché l'errore non possa ripetersi.
Lascia che la macchina giudichi ciò che la macchina può giudicare (feedback deterministico). Esegui lint, type check e test sull'output scritto dall'agente in CI prima del merge. È il guardrail più economico e affidabile di tutto lo stack, e intercetta i fallimenti che un revisore umano scorre senza vedere. Non far passare mai codice generato senza.
Tieni i prompt come intento, non come trucchi per il modello (feedforward non deterministico). Scrivi cosa vuoi e i vincoli. Tieni l'impalcatura specifica del modello, il "ragiona passo per passo", il "rispondi in JSON, senza preamboli", in uno strato chiaramente marcato che puoi rimuovere o sostituire, perché quello strato è tarato sulle stranezze di un modello specifico e non sopravviverà a un cambio.
Versiona ogni prompt con il suo modello di destinazione (feedforward non deterministico). Un prompt senza una nota su quale modello sia stato modellato è un rischio la prossima volta che cambi backend. La versione è la memoria di cosa ha funzionato e perché.
Fai scoring prima di fidarti, e prima di cambiare (feedback non deterministico). Tieni un piccolo set rappresentativo di input tuoi e verifica un prompt su quelli quando lo cambi o quando cambi modello. "Buono su un benchmark pubblico" non è "buono sul tuo lavoro". È la casella che la maggior parte dei piccoli team salta, ed è quella che trasforma un cambio di modello da caccia alle regressioni in un pomeriggio di lavoro.
Una fonte di verità per ogni prompt. Non tre repo e due tool di chat. Una copia autorevole che aggiorni una volta e di cui ti fidi ovunque. I fork sparsi sono anche una superficie di sicurezza, come chiarisce il problema della prompt injection agentica: ogni copia non controllata è un altro posto dove un'istruzione può essere infilata di nascosto.
Niente di tutto questo richiede un vendor o un budget. I punti 1 e 2 sono configurazione e CI che probabilmente hai già. I punti dal 3 al 6 riguardano il trattare i tuoi prompt come artefatti gestiti invece che come testo usa e getta, che è perlopiù una decisione.
Perché il cambio di nome continua a succedere, e cosa ignorare
La disciplina viene ribattezzata perché si sposta la frontiera della difficoltà. Quando i modelli riuscivano a malapena a seguire le istruzioni, la parte difficile era la formulazione, quindi abbiamo chiamato la competenza con il nome della formulazione. Quando riuscivano a seguire le istruzioni ma erano affamati delle informazioni giuste, la parte difficile era il contesto. Ora che iterano in autonomia, la parte difficile è il sistema attorno a loro. Il nome insegue il collo di bottiglia del momento, non l'obsolescenza del precedente.
Quello che va ignorato è il funerale implicito. "Context engineering ha sostituito prompt engineering" e "harness engineering ha sostituito context engineering" sono titoli, non architettura. Nel sistema reale coesistono tutti e tre: scrivi comunque il prompt, gli fornisci comunque il contesto giusto, e avvolgi entrambi in un harness che verifica il risultato. Un solo dev che sente "il prompt engineering è morto" e smette di investire nei propri prompt ha buttato via l'asset più economico e portabile che possiede per inseguire quello costoso.
Gli stessi setup multi-agente di Anthropic separano un planner, un generator e un evaluator proprio perché un agente non può valutare in modo affidabile il proprio lavoro [1]. È una decisione di harness, ed è anche, sotto sotto, una decisione di prompt: tre ruoli significano tre prompt scritti con cura, versionati e testati. L'harness non ha abolito il prompt. Gli ha dato un compito da svolgere dentro un sistema.
Il segnale
I nomi continueranno a cambiare. L'anno prossimo ci sarà una quarta parola, e una nuova ondata di post che dichiarano morto l'harness engineering. L'arco sottostante è stabile: costruisci un sistema attorno a un cervello in affitto perché produca lavoro affidabile, e tieni portabili le parti che possiedi.
Per un solo dev o un piccolo team, la mossa è poco glamour ed economica. Rendi deliberato il tuo harness accidentale. Lascia che il compilatore e la suite di test facciano gratis il giudizio oggettivo. E tratta i tuoi prompt, l'unico componente che è genuinamente tuo e ti segue su ogni modello verso cui farai routing, come artefatti gestiti, versionati e testati, invece che come testo che incolli qua e là. Il modello è in affitto. L'harness è il moat. Il prompt è la parte del moat che ti porti dietro.
Keep My Prompts è pensato per gli angoli non deterministici di quell'harness: versiona ogni prompt con il suo modello di destinazione, fagli scoring su sei criteri di qualità prima di fidartene o cambiarlo, e tieni una sola fonte di verità invece di fork sparsi tra i tool. Gratis per iniziare, senza carta di credito.
