Tutorial: Cline in VS Code con approval manuale su ogni azione

Cline (ex Claude Dev) usato in VS Code per generare boilerplate e test con revisione manuale di ogni diff. Configurazione multi-provider, disattivazione auto-approve, gestione del file di config per team PMI.

Open SourceAITutorial Open SourceAIAgenticTutorialClineVS CodePMI

Note preliminari

Questo tutorial è fornito “as-is”. Prima di usarlo in un repository attivo:

  • Provate su un branch dedicato, non su main.
  • Backup (o push remoto) del branch di partenza prima di far agire l’agente.
  • Non inserite secrets nei prompt. Cline spedisce i contenuti al provider LLM configurato.
  • Disattivate l’auto-approve per le azioni distruttive finché non avete preso confidenza con l’agente.
  • La sintassi delle modalità e delle impostazioni è cambiata più volte tra versioni: controllate la documentazione corrente del progetto.

Cosa è Cline

Cline — inizialmente pubblicato come Claude Dev, rinominato nell’autunno 2024 — è un’estensione open source per VS Code (github.com/cline/cline) che trasforma l’editor in un agente di coding. A differenza di un semplice autocomplete, Cline può leggere e scrivere file, eseguire comandi in terminale, avviare browser headless per ispezionare l’app in esecuzione. Ogni azione proposta viene mostrata in un pannello laterale e richiede approval.

Il modello di interazione predefinito è volontariamente conservativo: l’utente valuta ogni singolo diff e ogni comando prima che venga applicato. È la configurazione adatta a team PMI che introducono assistenti AI senza voler rinunciare al controllo sul codice scritto.

Caso d’uso: generare un endpoint REST con test in un microservice Node

Scenario: team di 3 sviluppatori su un microservice Express/TypeScript. Dobbiamo aggiungere un endpoint GET /api/v1/invoices/:id con validazione e test. Vogliamo che Cline produca codice, ma che ogni file scritto sia rivisto prima di passare alla CI.

1. Installazione

Da VS Code: Ctrl+Pext install saoudrizwan.claude-dev (ID storico dell’estensione, mantenuto per compatibilità). Dopo l’installazione l’icona Cline compare nella barra laterale.

2. Configurazione provider senza esporre la chiave

Cline supporta Anthropic, OpenAI, OpenRouter, Google, Bedrock, Ollama locale. La chiave si inserisce dalle Settings dell’estensione, non nel .vscode/settings.json del workspace (che può essere committato per errore).

VS Code → Settings → Extensions → Cline → API Provider: [Anthropic | OpenRouter | Ollama | ...]
VS Code → Settings → Extensions → Cline → API Key: <chiave>

Per ambienti dove la chiave non deve toccare il disco, avviate VS Code con la variabile d’ambiente già esportata (supporto variabile dipendente dalla versione) o usate Ollama locale, che non richiede chiavi.

3. Disabilitare l’auto-approve

Nella sezione Auto-approve delle impostazioni dell’estensione, tenete disattivate almeno:

  • Execute commands
  • Edit files outside the workspace
  • Use the browser

Mantenete eventualmente attivo solo il read su file del workspace, che è l’unica azione non distruttiva. Su repository con codice di produzione, anche l’Edit files va tenuto su approval manuale finché il flow dell’agente non è consolidato.

4. Prompt di avvio

Nel pannello Cline:

“Nel progetto corrente (src/), aggiungi l’endpoint GET /api/v1/invoices/:id. Deve: (a) validare che :id sia un UUID v4; (b) restituire 404 se il record non esiste; (c) restituire l’oggetto come JSON. Aggiungi un test di integrazione in tests/invoices.test.ts che copre i due rami. Non toccare file fuori da src/routes, src/validators e tests/.”

Note sul prompt:

  • Vincoli espliciti sui path: limita il blast radius dell’agente.
  • Criteri di accettazione misurabili (validazione UUID, codici HTTP, test su entrambi i rami).
  • Richiesta esplicita del test: un agente non istruito a scrivere test spesso non ne scrive.

5. Revisione dei diff

Cline mostra i diff proposti con “Save” / “Reject” per ogni file. Per ogni file:

  1. Leggere il diff completo.
  2. Verificare che non venga introdotto codice in node_modules/, dist/ o altri percorsi non richiesti.
  3. Se il test include un setup non necessario (es. mock di DB che già esistono), rifiutare il file e ri-istruire con prompt più stretto.

6. Commit granulare

Subito dopo l’approval dei diff, commit manuale con messaggio umano. Evitare di aggregare più sessioni Cline nello stesso commit: se qualcosa è rotto, il git bisect ringrazierà.

Limiti e avvertenze

  • Costo token non trascurabile: Cline invia molto contesto al modello per ogni azione. Su repository di discrete dimensioni, una singola sessione lunga può superare facilmente il costo di un’ora di lavoro di un junior. Monitorate il consumo.
  • Auto-approve su comandi è una tentazione pericolosa: basta un prompt ambiguo per vedere l’agente eseguire rm -rf “di pulizia” in una directory di build. Lasciatelo disattivato per default.
  • Non sostituisce la code review: il fatto che l’agente abbia scritto il codice non esime dalla review in pull request. Può, anzi, renderla più necessaria, perché pattern ripetitivi generati dall’agente tendono a nascondere assunzioni non verificate.
  • Versione della configurazione: se salvate un .clinerules o .clineignore nel repo, documentatelo nel README: chi clona deve sapere che la repo è “AI-assisted” e con quali regole.

Link: github.com/cline/cline


Stefano Noferi — Founder e CEO/CTO di noze
Tech Entrepreneur — AI Governance & Security Architect

Vuoi supporto? Sei sotto attacco? Stato dei servizi
Vuoi supporto? Sei sotto attacco? Stato dei servizi