La tua missione, se deciderai di accettarla: gli agenti che lavorano sul tuo codice non si fermano quando chiudi il laptop. Non possono. Consegna l’operazione a una macchina che non dorme mai, non si chiude mai, non va mai in blackout a metà run. Questo messaggio non si autodistruggerà. Nemmeno la pipeline in esecuzione alle 3 di notte senza di te.

Il lavoro è cambiato sotto al laptop

Per anni l’argomento per uscire dal laptop era un disagio personale: la batteria arriva al 3% a metà refactor, è addormentato nell’altra stanza quando finalmente scatta la soluzione, a un caffè rovesciato di distanza da un pomeriggio molto brutto. Problemi reali, ma sopravvivibili. Commit spesso, backup, spera per il meglio.

Non è più questo l’argomento. Il lavoro stesso ha cambiato forma. Gli agenti non fanno solo autocomplete mentre guidi la tastiera, prendono un ticket, scrivono il codice, aprono la PR, da soli, secondo un programma, mentre sei a cena. A un agente non importa che il laptop su cui gira sia andato in sleep alle 23, tranne che importa, perché quando il laptop dorme, l’agente smette di esistere a metà task. Il failure mode non è “ho perso la sessione.” È “la run che doveva girare durante la notte non è girata, e nessuno se n’è accorto fino al mattino.”

Un laptop è progettato per la portabilità. Non è mai stato progettato per essere il runtime di un processo che deve continuare a lavorare quando nessuno lo sta guardando. E lungo la strada, il lavoro vero, dotfiles, segreti, branch a metà, stato locale, run di agenti in corso, è finito a vivere sull’unica macchina più probabile da trovare addormentata, scarica, o fuori uso proprio quando qualcosa doveva girare.

Estrazione: portare il dev environment fuori dal laptop, del tutto

L’obiettivo della missione non è “usa anche un homelab.” È dismettere il laptop come luogo dove vive il development environment, punto. Il laptop continua a esserci, ma ora è un client, una tastiera e uno schermo che chiamano una sessione. Il lavoro vero si sposta su un mini PC sempre acceso sull’homelab: basso consumo, nessuno stato di sleep, nessun coperchio da chiudere.

C’è una seconda complicazione che rende questo non negoziabile: non c’è un laptop solo, ce ne sono tre, in rotazione, più qualsiasi nuova distro Linux che sta girando in testa questa settimana. Legare il dev environment a una singola macchina significa ricostruirlo ogni volta che cambia l’hardware o il sistema operativo sotto. Legarlo a una scatola sempre accesa significa che non importa quale laptop sia aperto o quale distro si stia testando in questo momento: connettiti, e l’ambiente è esattamente come è stato lasciato.

L’ambiente stesso è impacchettato in Docker, costruito in tre livelli così che nulla di importante resti mai intrappolato su una singola macchina fisica:

  1. Immagine (pubblica): una base devcontainer Ubuntu LTS più il toolchain. Niente di personale dentro. Questo livello potrebbe essere open-sourced così com’è.
  2. Stato (privato, bind-mounted): ~/code, cache, .claude, la chiave age. Questo è l’unico livello che conta davvero, e vive su un mount, non cotto dentro un’immagine.
  3. Dotfiles (templated): .bashrc, .gitconfig, applicati all’avvio del container invece che congelati in uno snapshot.

Niente qui è un’immagine dorata che hai paura di toccare. Il container è usa e getta, ma tenuto in esecuzione deliberatamente. Il mount di stato è l’unica cosa che vale la pena proteggere, ed è a un rsync di distanza dallo spostarsi su qualsiasi scatola sostituisca questa. Non è invulnerabile nemmeno lui: non è ancora sullo stesso rsync notturno cross-site, già provato su questo homelab per Immich e Home Assistant, con alert Telegram in caso di fallimento, che protegge tutto il resto qui. Portarlo su quello stesso binario è il prossimo passo, non un ripensamento.

Il container resta in esecuzione, ma il tmux grezzo dentro non è più il meccanismo. Quel livello è astratto dietro agent-deck :

# ssh nel mini PC (via Tailscale), poi:
agent-deck

Eseguilo, e ogni sessione è esattamente dove era stata lasciata, stessi processi in esecuzione, stesso scrollback, indipendentemente da quale dispositivo si sta riconnettendo. Ancora in valutazione se resterà lo strumento giusto per questo o se qualcosa di più specializzato prenderà il suo posto, ma alla scatola non importa quale: finché qualcosa di durevole si trova tra “ho chiuso il coperchio del laptop” e “il processo ha continuato a girare,” la missione regge.

Nemmeno i segreti viaggiano dentro l’immagine. Sono cifrati a riposo con sops e age, decifrati solo nel mount di stato a runtime. La chiave age stessa è l’unico passo deliberatamente manuale in un setup altrimenti riproducibile: è stata messa sulla scatola a mano, una volta, durante il setup, non generata o distribuita da nessuno script, e non qualcosa che l’automazione tocca di nuovo. Perdi il container, non perdi stato. Perdi il laptop, non perdi stato.

Insediamento: il livello homelab su cui gira tutto questo

Niente di tutto questo doveva essere esotico. Il mini PC gira Proxmox, tenuto deliberatamente noioso: un hypervisor pulito, ogni servizio nel suo LXC o VM sopra, niente di fatto a mano che non debba esserlo. Qualche anno fa mettere in piedi questo sarebbe stato l’intero progetto, un weekend perso tra stranezze di driver e tooling sconosciuto. Oggi, script di installazione mantenuti dalla community trasformano “aggiungi un nuovo servizio” nello scegliere una voce da una lista, e un assistente AI legge gli stessi log, YAML, e config che leggerebbe un systems engineer, poi spiega cosa non va in linguaggio semplice invece che farti reverse-engineering a mezzanotte. La barriera per far girare infrastruttura vera in casa è crollata mentre tutti erano occupati a guardare i chatbot.

Due pezzi di quel livello hanno già avuto il loro approfondimento: Docker in LXC: sto sbagliando tutto? copre l’architettura dei container che gira davvero su questa scatola Proxmox, e The Home Assistant Supremacy copre come tenere sincronizzate due case di Home Assistant. Questo pezzo dà per scontato che quel livello esista e resti noioso. Parla di cosa gira sopra.

Rendezvous: un solo centro di comando, diversi agenti

L’errore sarebbe pensare che questo sia solo “Claude Code, ma da remoto.” In pratica, il mini PC fa girare diverse CLI di agenti fianco a fianco: Claude Code, opencode, e pi, ognuna a fare lavoro diverso nello stesso momento. agent-deck sta già facendo il doppio lavoro come livello di sessione sopra, ed è ciò che tiene tutto questo gestibile anche qui: un’unica TUI, sessioni multiple di agenti, passa dall’una all’altra senza perderne nessuna.

Sopra a questo, il remote-control nativo di Claude Code trasforma qualsiasi dispositivo (un telefono, un tablet, un altro laptop del tutto diverso) in un terminale verso una sessione persistente. Nessun client SSH da configurare a mano, nessuna VPN da ricordarsi di accendere, nessun “fammi prima tornare alla scrivania.”

Non è un numero da vetrina. Programmare da un telefono o un tablet è diventato tecnicamente capace abbastanza da smettere di essere il fattore limitante, non perché sia uno stunt ma perché il lavoro non aspetta una scrivania. Ciò che lo rende davvero usabile, nel lungo periodo, non è il telefono: è avere un unico posto centralizzato a cui ogni dispositivo si ricollega. Una fix iniziata su un tablet in una sala d’attesa e finita su un laptop quella sera è la stessa sessione, non due frammenti disconnessi da riconciliare dopo.

Il laptop, a questo punto, smette di essere infrastruttura. È una tastiera con uno schermo attaccato. Sostituiscilo domani e non si perde nulla, perché nulla di importante c’è mai stato sopra.

Perché sono state le pipeline a forzare la questione

Sessioni interattive che sopravvivono a un coperchio chiuso è un nice-to-have. Questa è la parte che non è opzionale: insieme al lavoro interattivo, ci sono ora multiple pipeline automatizzate di agenti in esecuzione su questa scatola, non presidiate, secondo un programma. Una mina e reclama ticket, apre pull request, mentre nessuno guarda. Un’altra gira in continuazione, a caccia di bug in tutta la codebase e sistema quello che trova, nel suo ciclo autonomo. Nessuna delle due chiede permesso per partire. Nessuna delle due aspetta una tastiera.

La giornata lavorativa di uno sviluppatore ha una forma: siediti, programma, fermati. Quella di un agente no. Parte, aspetta, gira, ispeziona, modifica, testa, fa commit, e ricomincia, su un orologio che non ha niente a che fare con gli orari di scrivania di nessuno. Non è più un workflow di sviluppo, è un carico di lavoro da server che capita scriva codice, e ha bisogno della stessa cosa di cui ha bisogno ogni altro carico di lavoro da server: una macchina che è accesa quando deve essere accesa, che qualcuno la stia guardando o no.

Un laptop che va in sleep durante la notte non mette in pausa educatamente una pipeline, semplicemente fallisce in silenzio nel farla girare. Nessuno se ne accorge fino a quando la PR attesa la mattina dopo non c’è, o un bug che doveva essere trovato e sistemato durante la notte è ancora lì alle 9 del mattino. Non è un fastidio di persistenza della sessione, è un requisito rigido: questa classe di lavoro non può girare su una macchina che non è garantita essere accesa. Il mini PC sempre acceso non è un upgrade qui, è la soglia minima.

Cosa compra davvero la missione

  • Basta con “avevo l’idea ma il laptop dormiva nell’altra stanza.” La sessione che era aperta alle 23 è ancora aperta alle 7 del mattino, su qualunque dispositivo sia più vicino.
  • Ogni pipeline gira che ci sia o no un laptop aperto in casa. Mining di ticket, caccia ai bug, qualsiasi cosa venga dopo: il lavoro schedulato e non presidiato degli agenti non dipende più dal ricordarsi di lasciare un coperchio alzato.
  • Cambiare laptop, o saltare da una distro all’altra, non costa nulla. Tre laptop in rotazione e una distro Linux occasionale da provare smettono di essere una ragione per ricostruire qualcosa, l’ambiente vive sul mini PC, non su qualunque macchina capiti sia aperta oggi.
  • Il workspace sopravvive all’hardware. È portabile su qualsiasi scatola sostituisca questo mini PC, non legato a una singola macchina fisica che ti porti dietro e potresti perdere.
  • È riutilizzabile, non personale. La divisione a tre livelli (immagine, stato, dotfiles) non è un hack una tantum, è un pattern che chiunque faccia girare un homelab potrebbe adottare.

Status: operazione in corso

Piena trasparenza dal campo: questo non è un appliance finito, è un rollout attivo. Il design a tre livelli è stabilito, ma qualche decisione è ancora aperta: quale Ubuntu LTS fissare, se inoltrare un SSH agent o fare bind-mount diretto di ~/.ssh, e se il prossimo host per questo sarà un LXC leggermente annidato o una VM semplice. Niente di tutto ciò cambia la missione. Cambia la tattica.

Missione compiuta: il laptop è dismesso come luogo dove vive il lavoro, tenuto in vita solo come client, e le pipeline che avevano bisogno di una scatola sempre accesa finalmente ce l’hanno. Obiettivo in corso: il workspace stesso diventa abbastanza portabile da poter essere consegnato a chiunque voglia far girare la stessa strategia sul proprio homelab.