Passare da uno strumento di programmazione con IA a un altro non è complicato tanto per il codice che genera. La parte frustrante è dover spiegare di nuovo il progetto: perché abbiamo scelto quell’architettura, su quale branch stiamo lavorando, quali test sono davvero passati, quale PR aspetta una revisione e quali operazioni erano consentite all’Agent precedente.

Ho iniziato a spostare queste informazioni dalle conversazioni a GitHub. Codex, Claude Code, Cursor e ChatGPT nel browser possono essere punti d’ingresso diversi: il nuovo strumento legge prima Issue, branch e PR. Se dispone dei permessi necessari, modifica il codice in un proprio branch; se può soltanto leggere, lascia un commento di revisione.

È quello che chiamo GitHub-first: gli strumenti di IA possono cambiare, ma lo stato del progetto non deve sparire insieme alla chat. Non serve tenere in esecuzione un Bot di coordinamento solo per ricordare l’avanzamento. Posso passare il prossimo compito anche quando ho con me soltanto il telefono.

Memoria della conversazione e contesto tecnico non sono la stessa cosa

Un progetto che dura più giorni accumula decisioni difficili da ricostruire. B può ignorare perché A ha scartato una soluzione. Una sessione nuova vede una CI verde relativa a un vecchio commit e pensa che sia verde anche per l’HEAD attuale. Due persone modificano lo stesso file credendo entrambe di essere responsabili. Incollare dieci pagine di chat nel prompt successivo aiuta per poco, ma aumenta la dipendenza dalla cronologia di uno specifico prodotto.

Distinguo la memoria della chat dai fatti tecnici verificabili. GitHub non trasferisce il ragionamento interno di un modello, né la sua conversazione privata. Può invece conservare quattro categorie di informazioni che il prossimo Agent può leggere, controllare e aggiornare:

• Regole del progetto: AGENTS.md, README e documenti di architettura. Non tutti i client caricano AGENTS.md automaticamente.
• Identità del compito: Issue, task ID, piano, responsabile, checkpoint facoltativo, lavoro completato e verifiche ancora aperte.
• Versione del codice: main, feature branch, SHA di commit e Git Blob. È necessario individuare il branch su cui si sta realmente lavorando.
• Revisione e approvazione: diff della PR, commenti, ACK, CI associata all’HEAD esatto, merge e registrazioni di deployment.

Non occorre costruire un nuovo database JSON. Git segue le modifiche al codice, Issue e PR conservano discussioni e decisioni, mentre un checkpoint opzionale specifica la prossima azione. Credenziali, cache temporanee dei modelli e lock ad alta frequenza non appartengono al repository.

Anziché copiare schermate di conversazioni precedenti, a una sessione nuova consegno un breve prompt di recupero. L’esempio resta in inglese per essere copiato direttamente tra strumenti diversi:

You are the developer for this task. Recover project state read-only first.
Repository: OWNER/REPO
Task: Issue #N, linked PR #M, task ID TASK_ID

Read repository rules, the plan, checkpoint, current feature-branch HEAD,
PR diff, the latest applicable review comments, and checks for that HEAD.
Explain the authorized actions, verified work, and remaining gates.
Stop and report if the branch moved, permissions differ, or orders conflict.
Do not merge, deploy, or change production settings without separate approval.

Chi sviluppa da solo può partire dalla versione leggera: README o AGENTS.md, un Issue o una PR e gli ultimi commit. Aggiungerei checkpoint e validazione Order/ACK soltanto quando il lavoro dura più sessioni, coinvolge più autori o richiede una revisione indipendente.

GitHub come stato condiviso tra strumenti IA e branch paralleli

Il flusso può essere riassunto così. La figura SVG animata all’inizio dell’articolo visualizza la stessa architettura:

Phone / browser / local IDE / cloud coding agent
                       |
             Read GitHub task facts
                       |
       AGENTS.md · Issue · plan · checkpoint
                  branch · PR
                       |
              Check permission scope
                       |
         Feature branch A     Fix branch B
                  |                |
                commit           commit
                  |                |
                 PR A             PR B
                     \           /
                   review + CI per HEAD
                           |
                  Human approval to merge
                           |
                          main

I punti d’accesso non possiedono automaticamente gli stessi permessi GitHub. Alcune integrazioni possono soltanto cercare e leggere; altri Coding Agent possono modificare file, creare branch e aprire PR nel proprio ambiente di esecuzione. Questa descrizione si riferisce a ottobre 2026 e non significa che io abbia verificato singolarmente tutte le capacità attuali dei prodotti citati. Prima di iniziare controllo i permessi effettivi read, write, comment, merge e deploy dell’account e dell’integrazione.

Per esempio, un Agent nel cloud può occuparsi della funzionalità A, una sessione dal browser può proporre modifiche ai documenti e Codex in locale può correggere un’interfaccia. Condividono le stesse regole, ma scrivono separatamente in feature/A, docs/B e fix/C; le modifiche si incontrano nelle PR.

Isolare i branch non elimina i conflitti logici. Due branch possono cambiare la stessa API o dipendenza. Preferisco un solo autore effettivo per ogni branch di lavoro e, prima di un merge, ricontrollo la base comune, i file coinvolti, la CI recente e gli eventuali test di integrazione. La documentazione sulle Pull Request e quella sui branch protetti descrivono i controlli già disponibili in GitHub.

Per gestire diverse directory di lavoro sulla stessa macchina esiste Git Worktree, approfondito nel mio articolo su Git Worktree. Qui la domanda è diversa: come possono strumenti IA differenti riprendere lo stesso compito GitHub e ricongiungere i risultati in modo verificabile?

Passaggio tra strumenti: controllare prima Issue, branch e PR

Il prompt fornisce soltanto il punto d’ingresso. Il nuovo Agent deve poter rispondere sulla base del repository: qual è l’HEAD attuale, cosa ha consegnato il precedente responsabile e chi può scrivere adesso?

Per iniziare basta un piccolo AGENTS.md nella radice del progetto. Deve indirizzare alla documentazione e ai comandi di test esistenti, non sostituirsi a un intero manuale:

# AGENTS.md

- Stack and architecture: see README.md and docs/architecture.md
- Install and test: follow the current commands in README.md
- Task entry points: GitHub Issue and linked PR
- Optional state: tasks/<TASK_ID>/checkpoint.json
- Before editing: verify task ID, branch, and live HEAD
- Prefer one writer for each feature branch
- Merges and deployments need separate approval

Per i compiti più lunghi aggiungo, quando serve, un checkpoint.json. I nomi dei campi derivano da un checkpoint realmente presente nel mio progetto; gli identificativi e gli SHA seguenti sono segnaposto pubblici:

{
  "task_id": "TASK_ID",
  "phase": "P2",
  "status": "IN_PROGRESS",
  "branch": "feat/TASK_ID",
  "commit_sha": "REPLACE_WITH_LAST_VERIFIED_40_HEX_SHA",
  "pr": "https://github.com/OWNER/REPO/pull/N",
  "verification": { "merge": { "status": "NOT_AUTHORIZED" } },
  "next_action": "Read current HEAD and review comments before resuming"
}

È un esempio minimo, non la copia del mio checkpoint privato e nemmeno uno schema universale pronto per qualsiasi repository. Non va aggiornato dopo ogni commit per principio. In un compito piccolo possono bastare commenti su Issue e PR; io lo aggiorno durante passaggi importanti, verifiche o blocchi.

C’è una trappola nella gestione degli SHA: checkpoint.commit_sha identifica l’ultimo commit di codice verificato, non necessariamente il commit che contiene il checkpoint e nemmeno l’HEAD corrente. Se il codice è stato verificato nel commit A e il checkpoint viene salvato in B, il file può riferirsi ad A. Non può conoscere in anticipo l’hash del commit B che lo conterrà. E non esiste uno scarto fisso di un solo commit.

Chi riprende il lavoro deve leggere di nuovo da GitHub l’HEAD effettivo e confrontarlo con la versione verificata e le modifiche successive. Due SHA diversi non indicano automaticamente un errore. Nell’ACK i campi observed_head_sha e new_head_sha rappresentano la vecchia versione controllata e quella nuova consegnata. Il rifiuto di una Order obsoleta è una verifica distinta.

AGENTS.md custodisce le regole, Issue e PR ospitano discussioni e revisioni, checkpoint riassume facoltativamente l’avanzamento. Se un client non carica AGENTS.md da solo, lo si chiede esplicitamente nel prompt di ingresso.

Ho reso open source il nucleo del protocollo di passaggio più rigoroso che uso nei miei progetti. Non serve per la variante leggera, ma chi vuole leggere come Order/ACK si collegano a un HEAD, come vengono riconosciute le istruzioni scadute e come funzionano i test offline può consultare codice e verificatori:

vxime/conversation-memory-hub

Il repository contiene protocollo, validatori ed esempi. Non è un servizio ospitato che riattiva automaticamente altre chat IA, né una copia centralizzata degli stati dei progetti. Issue, branch e PR continuano a risiedere nei rispettivi repository GitHub.

Un PR reale: FIX_REQUIRED, ACK e revisione indipendente

Un diagramma può creare un’illusione rassicurante: due agenti rispondono «ricevuto» e crediamo che il passaggio sia riuscito. Ho ricontrollato una vera PR privata che modificava documentazione. Il revisore B ha individuato due problemi, lo sviluppatore A ha corretto il testo e comunicato un nuovo HEAD; B ha esaminato quella versione prima di permettere l’avanzamento. La decisione finale di fare merge è rimasta separata e umana.

FIX_REQUIRED, ACK e ADVANCE sono convenzioni dei commenti del mio progetto, non stati nativi delle PR GitHub. Indicano rispettivamente la richiesta di correzione, la risposta dello sviluppatore con la nuova versione e il via libera del revisore dopo una nuova verifica. STALE_ORDER segnala istruzioni riferite a un HEAD non più attuale.

La PR riguardava soltanto un piano di audit Runner in modalità lettura: non installava alcun Runner. Il difetto F-001 era concreto: l’audit avrebbe dovuto verificare trigger rischiosi di GitHub Actions, per esempio issue_comment, ma il comando elencava soltanto i nomi dei file workflow.

# Original plan: names only; the YAML triggers remain invisible.
gh api "repos/OWNER/REPO/contents/.github/workflows" --jq '.[].name'

Dai nomi dei file non si può capire se il blocco on: del YAML include issue_comment. F-002 correggeva un riferimento errato a una sezione del documento. Il piano aggiornato fissava lo SHA dell’audit, leggeva i veri trigger YAML e alla fine verificava che l’HEAD non fosse cambiato. Ho confrontato le due versioni della documentazione; la guida ufficiale agli eventi di Actions chiarisce perché quei trigger sono rilevanti.

A ha lasciato l’ACK e il nuovo HEAD nei commenti della PR originale. B ha verificato i due interventi contro quel nuovo HEAD e soltanto allora ha pubblicato ADVANCE. Il passaggio fra le due sessioni IA è stato guidato da una persona: nessuna chat è stata riattivata automaticamente e decideResume() non è stato installato come controllo GitHub Actions o Git hook locale. Per lavori semplici bastano normali commenti PR con lo SHA preciso.

Ecco i campi essenziali estratti dall’ACK reale, con ID e SHA privati sostituiti:

{
  "protocol": "ai-supervisor/ack/v1",
  "task_id": "TASK_ID",
  "order_id": "REPLACE_WITH_ORDER_ID",
  "decision_received": "FIX_REQUIRED",
  "observed_head_sha": "REPLACE_WITH_OLD_HEAD",
  "new_head_sha": "REPLACE_WITH_NEW_HEAD",
  "executed": [
    "F-001: Inspect workflow triggers at a pinned SHA",
    "F-002: Correct the audit plan's section reference"
  ]
}

Il protocollo originale comprende campi aggiuntivi e controlli di integrità. Il punto utile è che A lascia una traccia del vecchio HEAD a cui si riferivano le osservazioni di B e del nuovo HEAD che consegna. B può esaminare la modifica vera, anziché fidarsi di un semplice «fatto».

La PR modificava soltanto documenti; non risultava una CI riuscita per l’HEAD in esame, né un audit eseguito sul VPS di produzione. Questo dimostra un passaggio di revisione tracciabile, non un sistema autonomo pronto per qualsiasi attività.

STALE_ORDER: un’istruzione vincolata al vecchio HEAD deve fermarsi

Una Order è un’istruzione strutturata che B lascia in un commento Issue/PR: lega task ID, branch di destinazione, observed_head_sha, rilievi e azioni consentite o vietate. Il campo order_id nell’ACK rimanda a quell’istruzione.

In una prova negativa separata, l’Order si riferiva a un vecchio HEAD di main. Il repository è poi avanzato. Recuperando la vecchia Order, A avrebbe dovuto interrompersi con STALE_ORDER invece di modificare codice diverso secondo istruzioni scadute.

Ho verificato l’Order archiviata, il nuovo HEAD e il controllo di obsolescenza del codice decideResume(). All’epoca A ha comunicato di essersi fermato, ma quella segnalazione è stata riportata da una persona, non pubblicata da A come ACK GitHub indipendente. È una prova negativa utile, non una verifica end-to-end su tutti i client IA.

La regola pratica è semplice: B vincola task, branch, HEAD e permessi; A legge l’HEAD corrente prima di agire. Se è cambiato, si ferma e chiede una nuova verifica a B. Un’istruzione corretta ieri potrebbe essere sbagliata per il codice di oggi.

Per questo continuo a preferire una revisione indipendente. Un Agent che produce un diff plausibile e una seconda sessione che verifica la modifica contro l’HEAD effettivo sono due fatti diversi. Per i meccanismi più generali di ownership e stato multi-agent rimando al mio articolo sull’orchestrazione degli Agent.

Collaborare dallo smartphone non trasforma GitHub in un computer gratuito

La comodità reale è che non devo tenere acceso un Mac soltanto per seguire il progetto né mantenere un bot residente come coordinatore. Dal telefono, se il client ha i permessi, posso leggere PR e commenti e passare l’azione successiva. La modifica del codice, la build e i test richiedono comunque un Cloud Agent, Runner o ambiente locale autorizzato.

Anche i costi vanno separati. Ripetere il contesto e mantenere servizi dedicati può sprecare tempo e risorse operative; inferenza dei modelli, quote Chat/Codex/API e CI comportano invece costi distinti. Non ho misurato un risparmio di Token con un confronto equivalente, quindi non propongo percentuali inventate.

Il mio blog ha inoltre una pipeline GitHub Actions → Self-hosted Runner. L’articolo sullo sviluppo da dispositivi diversi e il deployment descrive quella fase successiva. Qui affronto la domanda precedente: come sapere se un’altra persona o un altro strumento sta riprendendo davvero lo stesso compito?

Per una modifica a basso rischio di un solo file bastano spesso un Agent e un branch. Quando il lavoro si estende su più giorni, strumenti e persone, checkpoint, responsabilità dei branch, revisioni indipendenti e permessi precisi diventano più importanti. Per me GitHub-first non significa che i modelli condividano magicamente una memoria: significa che i fatti tecnici restano in un luogo dove il prossimo sviluppatore può trovarli e ripartire.