IDE, web, CLI: scegliere il giusto environment Claude Code

Claude Code esiste in cinque forme: CLI nel terminale, desktop app (Mac/Windows), web app su claude.ai/code, extension VS Code, extension JetBrains. Sono interfacce diverse sullo stesso modello sottostante, ma ottimizzano workflow diversi. Scegliere male ti costa attrito gratuito; scegliere bene rende il lavoro fluido.

Disclaimer di indipendenza: non sono affiliato ad Anthropic. Sul portfolio uso principalmente CLI (per workflow GSD) + VS Code extension (per inline editing). Web app e desktop sono setup secondari.

Le cinque forme in breve

• CLI: terminal-native. Full file system access. MCP stdio nativo. Slash command + skill + GSD workflow strutturati. Ottimo per workflow batch + automation.
• Desktop app: GUI standalone Mac/Windows. Full file system access. MCP support. UX più amichevole di CLI per chi non vive nel terminale.
• Web app (claude.ai/code): cloud-only, no setup locale. Project mode con custom instructions persistenti. MCP support limitato (no stdio, solo HTTP remote). Ottimo per chat + drafting.
• VS Code extension: integrazione editor inline. Pair-programming durante coding. CLI underneath per MCP + skill. Ottimo per modifiche localizzate guidate.
• JetBrains extension: simile VS Code, per IntelliJ / WebStorm / PyCharm. Pattern analogo.

Decision matrix per scenario

Setup misto raccomandato

Sul portfolio uso questo setup:

1. CLI come primary: tutti i workflow GSD (/gsd-plan-phase, /gsd-execute-phase), skill custom, MCP, sub-agent.
2. VS Code extension come secondary: durante coding manuale (review post-execute, refactor mirato, debug). L'extension usa il CLI underneath, quindi MCP + skill restano disponibili.
3. Web app per quick check: quando ho una domanda veloce non legata al progetto specifico ("dimmi come funziona X pattern in linguaggio Y"). Zero context overhead di setup.

Desktop app e JetBrains: non li uso. Non c'è gap che riempiono nel mio setup. Sono validi per altri profili (sviluppatori Java/Kotlin che vivono in IntelliJ trovano l'extension JetBrains più fluida).

Differenze MCP

• CLI / Desktop: stdio MCP nativo (server come subprocess locale). Full ecosystem.
• VS Code / JetBrains ext: stdio MCP via CLI underneath. Funziona ma config va su CLI level.
• Web app: solo HTTP remote MCP. Niente stdio. Limita drasticamente ecosystem disponibile.

Per workflow MCP-heavy (sul mio portfolio uso 8 MCP server), CLI è l'unica scelta ragionevole.

Differenze file system access

• CLI / Desktop / IDE ext: full file system come l'utente che lancia. Lettura/scrittura senza permessi extra.
• Web app: solo file caricati esplicitamente nella sessione. Nessun accesso al file system locale.

Per workflow su repository codice, web è limitato. Per drafting o domande generali, va benissimo.

Costo

API call: stesso prezzo cross-environment. La fattura mensile non cambia se usi CLI vs web vs IDE ext: dipende dai token consumati, non dall'interfaccia.

Subscription Claude Pro (~€20/mo) include accesso a tutte le forme. Niente sub-pricing per CLI vs ext.

UX latency

Differenze pratiche di latency UX:

• CLI: startup ~200ms, response streaming immediato.
• Desktop: startup ~1s, response streaming immediato.
• Web: startup browser tab (variable), response streaming immediato post-prompt.
• IDE ext: integration overhead ~500ms-1s per round-trip.

Differenze piccole, ma cumulative su sessioni intense. Per workflow che richiedono 50+ prompt/sessione, CLI vince in throughput.

Workflow ibrido tipico (giornata reale)

1. Mattina: tmux con Claude Code CLI + repository terminale, lancio /gsd-execute-phase per Wave 2 in background.
2. Mentre Wave 2 gira: apro VS Code, durante coding manuale uso extension per query inline (rename refactor, fix typo).
3. Pranzo: claude.ai su mobile per leggere un thread di doc tech non legato al progetto.
4. Pomeriggio: torno su CLI per review + plan-checker iter 2 + commit batch.

Tre environment in una giornata, ognuno per il caso d'uso giusto. Zero friction di switching perché ognuno è ottimizzato per quel micro-workflow.

Anti-pattern: forzare un environment per ogni cosa

Forzare CLI per tutto: anche per chat veloci richiede aprire terminal, navigare path, attendere startup. Overhead inutile per query throwaway.

Forzare web per tutto: zero file system access = devi copy-paste codice sempre. Overhead enorme per workflow su repository.

Mix sano: scegli environment in base al task, non al gusto.

Cosa ho imparato scrivendo questo articolo

La cosa che ho realizzato è che la scelta dell'environment è una micro-decisione che fai 50 volte al giorno. Non ci pensi esplicitamente; aprire CLI vs aprire web vs cliccare extension VS Code = scelte fatte in automatico. Se le fai bene, accumuli minuti risparmiati. Se le fai male, accumuli attriti.

Secondo insight: il mio uso si è stabilizzato a 3 environment dopo sperimentazione iniziale (anche con desktop + JetBrains). Per altri profili professionali (es. Java/Kotlin in IntelliJ) la distribuzione sarebbe diversa. Non c'è "il setup giusto" universale: c'è il setup giusto per il tuo workflow.

Anti-pattern evitati

• Mono-environment. Diversità nel kit di lavoro paga.
• Aprire CLI per chat throwaway. Web ha zero startup, vincela.

Una storia ricevuta che vale la pena condividere

Sezione segnaposto. Setup ibridi originali sono benvenuti via federico@federicocalo.dev.

← Cluster precedente: Hooks system Prossimo cluster: Cost optimization →