The Pulse
GitHub porta Agentic Workflows nell’anteprima pubblica di Actions
GitHub ha portato Agentic Workflows nell’anteprima pubblica, consentendo agli agenti di programmazione di eseguire automazioni dei repository all’interno di GitHub Actions. Gli sviluppatori descrivono le attività in Markdown, mentre l’esten
AI.info Team ·
Bastano due file per trasformare un’istruzione in linguaggio naturale relativa a un repository in un workflow GitHub Actions funzionante: un file Markdown che descrive l’attività e un file lock compilato che Actions esegue. GitHub rende ora disponibile questo modello in anteprima pubblica con GitHub Agentic Workflows, integrando gli agenti di programmazione nel sistema di automazione usato per test, distribuzione e manutenzione dei repository.
GitHub ha annunciato l’anteprima pubblica l’11 giugno 2026, dopo aver presentato il progetto come anteprima tecnica a febbraio. L’azienda afferma che i workflow possono gestire attività come il triage delle issue, l’analisi degli errori di integrazione continua e gli aggiornamenti della documentazione, affidandole ad agenti di programmazione all’interno di GitHub Actions.
La documentazione attuale di GitHub descrive la funzionalità come un modo per definire in Markdown l’automazione di un repository e selezionare l’agente di programmazione che la eseguirà. L’estensione gh aw compila la configurazione in un workflow standard di GitHub Actions.
Le istruzioni in Markdown diventano processi di Actions
Agentic Workflows separa la descrizione dell’attività dai meccanismi di esecuzione. Gli sviluppatori indicano in linguaggio naturale il risultato desiderato, aggiungono la configurazione per trigger, permessi, strumenti e output consentiti, quindi usano l’estensione della CLI di GitHub per generare il workflow eseguito in Actions.
Nel precedente annuncio dell’anteprima tecnica, GitHub indicava Copilot CLI, Claude Code e OpenAI Codex come possibili motori per gli agenti, a seconda della configurazione. La documentazione attuale descrive anche l’uso di Claude Code, OpenAI Codex o Google Gemini CLI, con la relativa chiave API archiviata come segreto del repository, se necessario.
L’esempio proposto da GitHub genera un rapporto quotidiano sullo stato del repository. Il workflow può esaminare issue, pull request, discussioni, release e modifiche al codice, quindi pubblicare un rapporto per chi si occupa della manutenzione. Altri esempi includono riassumere e assegnare etichette alle issue in arrivo, mantenere la documentazione allineata al codice, migliorare la copertura dei test, indagare le esecuzioni CI non riuscite e produrre rapporti periodici sullo stato del repository.
I permessi predefiniti di sola lettura limitano le modifiche degli agenti
GitHub presenta la funzionalità come un’estensione dei controlli già presenti in Actions, non come un sostituto delle pipeline deterministiche di build e release. Agentic Workflows riutilizza i gruppi di runner e i vincoli delle policy, aggiungendo controlli pensati per circoscrivere le azioni degli agenti.
Secondo GitHub, per impostazione predefinita gli agenti operano con permessi di sola lettura. Le operazioni di scrittura passano attraverso gli «output sicuri», un insieme di operazioni approvate, come creare una pull request o aggiungere un commento a una issue. Il sistema utilizza anche un container isolato, una lista di strumenti consentiti, l’isolamento della rete e un processo separato di rilevamento delle minacce, che esamina le modifiche proposte prima che vengano applicate.
Le pull request non vengono unite automaticamente. La documentazione e i materiali di lancio di GitHub prevedono una fase di revisione umana tra la modifica proposta da un agente e la sua accettazione nel repository.
«La parte difficile non è mai stata convincere un agente ad aprire una pull request. È fidarsi abbastanza da unirla.»
May Walter, CTO, Hud.io
GitHub punta sulle attività ripetitive nei repository
La funzionalità è pensata per attività che richiedono capacità di giudizio, ma seguono schemi ricorrenti. Chi si occupa della manutenzione potrebbe chiedere a un agente di individuare le nuove issue più importanti; un team della piattaforma potrebbe usarlo per indagare errori ricorrenti nei test; oppure un gruppo di ingegneria potrebbe incaricarlo di aprire pull request circoscritte, per il refactoring e il miglioramento dei test.
Nell’annuncio di febbraio, GitHub ha descritto l’approccio come «IA continua», sottolineando che dovrebbe affiancare l’integrazione e la distribuzione continue. I workflow YAML tradizionali restano responsabili di build, test e release deterministici; il livello agentico gestisce le attività difficili da esprimere con sole regole fisse.
Alex Devkar, vicepresidente senior di Ingegneria e Analytics presso Carvana, ha dichiarato che l’azienda usa i workflow per attività di ingegneria che coinvolgono più repository.
«Con GitHub Agentic Workflows possiamo ampliare il modo in cui applichiamo gli agenti a progetti di ingegneria concreti su larga scala, comprese le modifiche che interessano più repository. La flessibilità e i controlli integrati ci danno fiducia nell’utilizzare workflow agentici nei sistemi complessi di Carvana.»
Alex Devkar, vicepresidente senior, Ingegneria e Analytics, Carvana
Costi e revisione restano parte del progetto
Agentic Workflows consuma capacità dei modelli e può comportare costi di fatturazione. La documentazione di GitHub sull’anteprima tecnica affermava che un’esecuzione standard di Copilot comportava in genere due richieste premium: una per il lavoro dell’agente e un’altra per il controllo dei guardrail degli output sicuri. I team possono configurare i modelli utilizzati e dovrebbero iniziare con output a basso rischio, come commenti, bozze e rapporti, prima di consentire la creazione di pull request.
Nell’anteprima pubblica, la definizione del workflow resta sotto controllo del codice sorgente. GitHub consiglia ai team di trattare le istruzioni in Markdown come codice, esaminare le modifiche, mantenere l’ambito circoscritto e apportare evoluzioni in modo ponderato.
GitHub presenta la funzionalità come un modo per integrare gli agenti nei processi del repository che gli sviluppatori già monitorano attraverso i log di Actions, le pull request e le impostazioni delle policy. Il fatto che sia in anteprima pubblica significa anche che la funzionalità può cambiare; l’azienda invita gli utenti a provarla seguendo la documentazione e la procedura di avvio rapido prima di adottarla per modifiche a rischio più elevato.