Vibe coding senza perdere controllo: cos'è l'harness

Che cos'è l'harness

Harness significa imbracatura, ma nel lavoro con agenti AI indica il sistema che tiene il modello dentro un perimetro utile. Il modello è il motore che genera codice, ragiona e propone modifiche. L'harness è ciò che gli sta intorno: istruzioni, contesto, strumenti, test, permessi, regole di sicurezza, memoria, log e criteri per capire se il lavoro è finito.

• Istruzioni: cosa deve fare l'agente, come deve lavorare e quali regole seguire.
• Contesto: file, documenti, esempi e decisioni che servono davvero al task.
• Strumenti: terminale, IDE, repository, browser, MCP, CLI, test e build.
• Verifiche: test automatici, review, checklist, preview e criteri di accettazione.
• Limiti: cosa non deve leggere, modificare, cancellare, eseguire o pubblicare.

Perché il modello non basta

Quando scegli un tool AI per programmare è naturale guardare subito il modello: Claude, GPT, Gemini o un modello specializzato per coding. Conta, ma non decide tutto. Lo stesso modello può produrre risultati molto diversi se lavora in una chat vuota, in un IDE con contesto del repository, in un agente con test automatici o in un ambiente con regole e permessi chiari.

• Un buon modello senza contesto può inventare soluzioni fuori progetto.
• Un modello più economico con test e istruzioni pulite può fare bene task ripetitivi.
• Un agente con strumenti sbagliati perde tempo anche se il modello è forte.
• Il problema spesso non è 'AI scarsa', ma 'AI lasciata lavorare senza binari'.

Quando il vibe coding basta

Per un prototipo piccolo non serve trasformare tutto in processo. Se stai creando una landing, una demo, un tool personale o una prima versione da mostrare, il vibe coding libero è spesso la scelta giusta. Ti permette di capire in fretta se l'idea ha senso, se il flusso è comprensibile e se vale la pena investire altro tempo.

• Il progetto è reversibile e puoi buttarlo via senza danni.
• Non ci sono dati sensibili, pagamenti, permessi complessi o utenti reali.
• Vuoi imparare, esplorare o mostrare un'idea, non costruire fondamenta definitive.
• Il codice è abbastanza piccolo da essere letto o rifatto se serve.

Quando inizia a rompersi

Il vibe coding si rompe quando continui ad aggiungere funzioni sopra una base che nessuno ha davvero controllato. All'inizio l'AI sembra velocissima. Poi arrivano bug che tornano, file modificati senza motivo chiaro, costi che crescono, dipendenze casuali e parti del progetto che funzionano solo finché nessuno le tocca.

• Ogni correzione crea un altro problema in una parte diversa.
• Non sai più quali file sono importanti e quali sono residui di esperimenti.
• L'AI propone refactor grandi senza spiegare rischi e verifiche.
• La preview funziona, ma non sai se auth, permessi, dati e deploy sono solidi.
• Il costo non è solo abbonamento: è tempo perso a inseguire errori opachi.

Il primo harness non è complicato

La buona notizia è che non devi partire da una piattaforma enterprise. Il primo harness può essere molto semplice: un file di istruzioni, pochi comandi affidabili, test minimi, backup e una checklist prima di chiedere all'AI modifiche importanti. È abbastanza per trasformare un flusso caotico in un lavoro più controllabile.

• Crea un file con stack, comandi validi, convenzioni e cose da non toccare.
• Chiedi all'agente un piano prima di modifiche multi-file.
• Fai eseguire test, lint o build prima di accettare una patch.
• Se non ci sono test, chiedi prima quali test minimi aggiungere.
• Usa checkpoint, branch o versioni salvate prima di cambiamenti grandi.

Prompt pratico:

Sto facendo vibe coding su questo progetto.

Prima di aggiungere nuove feature, costruisci un harness minimo:
1. dimmi quali file devo capire
2. proponi le regole da mettere in AGENTS.md o README
3. indica quali test o comandi verificano che tutto funzioni
4. segnala rischi su dati, sicurezza, costi o deploy
5. proponi il prossimo task più piccolo e verificabile

Non modificare codice finché non approvo il piano.

I pezzi che contano davvero

Un harness utile non è una lista infinita di strumenti. È un modo per rispondere a cinque domande prima che l'agente lavori: cosa deve sapere, cosa può fare, quali strumenti può usare, come capiamo se ha ragione e quanto può costare l'iterazione. Se queste domande restano vaghe, il progetto dipende troppo dalla fortuna del prompt.

• Contesto: cosa serve al task e cosa invece crea rumore.
• Regole: convenzioni, stile, file protetti, limiti e priorità.
• Tool: terminale, test, browser, repo, MCP o CLI quando servono davvero.
• Evals e test: controlli automatici o rubriche per parti non deterministiche.
• Osservabilità: log, diff, file modificati, comandi eseguiti e costo stimato.

Quali tool aiutano di più

Non tutti gli strumenti aiutano nello stesso modo. Lovable, Replit, Bolt e v0 sono forti quando vuoi passare da idea a prototipo visibile. Cursor è più naturale quando vuoi restare dentro l'IDE e lavorare sul codice con contesto. Claude Code, ChatGPT Codex, OpenCode e Antigravity diventano più interessanti quando il lavoro richiede repository, terminale, test, task multi-file o flussi più agentici.

• Lovable, Replit, Bolt e v0: ottimi per vedere rapidamente una prima app.
• Cursor: utile quando vuoi un IDE AI-first con contesto del codebase.
• Claude Code: forte per lavoro da terminale, refactor, test e task lunghi.
• ChatGPT Codex: naturale se lavori già con ChatGPT, review, CLI, IDE e workflow OpenAI.
• OpenCode e Pi Agent: interessanti se vuoi più controllo su provider, terminale e setup.
• Antigravity: da valutare quando vuoi orchestrazione visuale e flussi multi-agente.

Regola pratica

Se il progetto serve solo a capire un'idea, resta leggero. Se deve durare, essere condiviso o toccare utenti, dati o soldi, aggiungi harness prima di aggiungere altre feature. Non è burocrazia: è il modo per continuare a usare l'AI senza perdere il controllo del progetto.

• Idea nuova e rischio basso: vibe coding libero.
• Prototipo promettente: istruzioni, checkpoint e comandi di verifica.
• Progetto con utenti reali: test, review, permessi e limiti chiari.
• Team o repository grande: agenti con contesto curato, workflow e responsabilità esplicite.

Domande frequenti