GH-600 Agentic AI Developer: guida completa

GitHub Certified: Agentic AI Developer — codice esame GH-600 — è la certificazione per chi non si limita a usare un assistente AI, ma mette agenti a lavorare dentro il ciclo di vita del software di produzione, con GitHub come sistema di riferimento e piano di controllo. Non è un esame sul prompt engineering: è un esame su architettura, permessi, memoria, misurazione e guardrail. È la certificazione GitHub più recente, ed è anche quella che invecchia più in fretta, perché il prodotto che c’è sotto cambia di continuo.

Cosa valida il GH-600

La descrizione ufficiale è netta: dimostrare competenza nel distribuire, far funzionare, integrare e governare agenti AI in flussi SDLC di produzione, garantendo affidabilità, sicurezza e velocità. Tradotto in attività, le responsabilità elencate sulla pagina della credenziale sono cinque: far girare flussi di lavoro con agenti dentro l’SDLC, supervisionare il comportamento autonomo con i controlli di GitHub, valutare e correggere gli output degli agenti usando scansioni e artefatti, configurare agenti custom e coordinare l’esecuzione multi-agente in sicurezza.

I dati d’esame verificati alla fonte sono questi: 120 minuti, esame proctored, punteggio minimo 700, livello Intermediate, ed è offerto solo in inglese. Due precisazioni che valgono più di quanto sembri. La prima: il numero di domande non è pubblicato né sulla pagina della credenziale né sulla study guide, quindi chi ti dà una cifra esatta la sta stimando. La seconda: la pagina ufficiale avverte che l’esame è erogato da Microsoft, ma esame e certificazione sono mantenuti da GitHub — e questo, come vedrai più avanti, ha conseguenze pratiche.

A chi si rivolge

Il profilo di riferimento non è il principiante dell’AI: è chi già lavora nel ciclo di sviluppo e ora deve renderne automatizzabile una parte senza perderne il controllo. La study guide chiede esperienza con l’SDLC, con i workflow e i controlli di GitHub e con le pratiche di qualità, sicurezza e code review; in più, esperienza con coding agent (GitHub Copilot in testa), con i server MCP e con la personalizzazione degli agenti: custom instructions, custom agent, tool e setup step di Copilot.

È quindi una certificazione di frontiera fra tre ruoli: sviluppatore, platform o DevOps engineer e chi si occupa di sicurezza e governance. Se vieni dall’uso quotidiano di Copilot, il salto più grosso lo farai sui domini di governo; se vieni dalla piattaforma, lo farai sulla parte di valutazione e tuning. Se non hai ancora basi su Copilot, ha senso passare prima dal GH-300 GitHub Copilot e poi tornare qui.

Il concetto trasversale: dichiara sempre la superficie

È la cosa che distingue chi passa da chi si perde. Un agente su GitHub può girare su quattro superfici distinte, e la stessa capacità esiste su una e non sull’altra:

Una domanda d’esame che descrive un sintomo — un tool fallisce e vorrei correlarlo alle mie tracce distribuite — ha risposte diverse a seconda della superficie: sull’SDK esistono eventi di errore per singola invocazione e l’export OTLP, mentre la vista enterprise delle sessioni ragiona a granularità di sessione. Prima di scegliere la risposta, chiediti sempre su quale superficie sta girando lo scenario.

I sei domini d’esame con i pesi ufficiali

Architettura degli agenti e processi SDLC (15-20%). Quali passi si danno a un agente, come si definiscono input, output e criteri di successo, e come si riconoscono gli anti-pattern. Il cuore è la separazione fra pianificazione ed esecuzione: far produrre all’agente un piano strutturato, validarlo e impedire l’azione finché il piano non è stato controllato e approvato. Ci sta dentro anche il grado di autonomia e la produzione di artefatti ispezionabili dagli strumenti di sviluppo normali.

Strumenti e interazione con l’ambiente (20-25%). È il dominio più pesante e il più pratico: identificare e configurare i tool e i loro permessi, aggiungere un server MCP come strumento, configurare il server MCP remoto di GitHub, i registry e le allow list. Poi il perimetro di esecuzione: limitare un agente a un repository, invocarlo da un workflow CI, dargli uno scope per branch, abilitarlo a creare branch e pull request. Infine la parte robusta: error handling, retry, rollback, percorsi di escalation e tracciabilità delle azioni compiute.

Memoria, stato ed esecuzione (10-15%). Scegliere fra memoria a breve termine, a lungo termine ed esterna; limitarla a ciò che serve al compito; definire regole di scadenza, potatura e reset. E poi il problema vero delle esecuzioni lunghe: il drift. Registrare progressi e decisioni come artefatti durevoli, riprendere il lavoro senza rifare i passi né contraddire le decisioni precedenti, ed evitare il contesto in conflitto o stantio quando lo stato passa fra strumenti e ambienti.

Valutazione, analisi degli errori e tuning (15-20%). Definire esiti attesi e vincoli operativi, scegliere segnali qualitativi e quantitativi, generarne di automatici con gli strumenti di scansione. Poi risalire alla causa: individuare i fallimenti da log, piani, tracce, output e artefatti di workflow, e classificarli fra errori di ragionamento, uso sbagliato degli strumenti e problemi di contesto o di ambiente. Il tuning che ne segue tocca istruzioni, workflow, vincoli, uso della memoria e accesso agli strumenti.

Orchestrazione multi-agente (15-20%). Applicare un pattern di orchestrazione, isolare gli agenti per l’esecuzione parallela e risolvere i conflitti: modifiche sovrapposte allo stesso codice, lavoro duplicato, output contraddittori. Ci sono dentro anche l’osservabilità (artefatti rivedibili, decisioni e handoff documentati, analisi a posteriori), il riconoscimento di esecuzioni fallite, parziali o bloccate, i pattern di recupero con rollback e human-in-the-loop, e il ciclo di vita: aggiungere, sostituire e ritirare agenti senza interrompere i flussi attivi e senza perdere l’auditabilità.

Guardrail e responsabilità (10-15%). Classificare le azioni per rischio operativo, di sicurezza e di conformità, e assegnare livelli di autonomia proporzionati. Bloccare ciò che viola le policy, limitare permessi e contesti di esecuzione al minimo privilegio, richiedere autorizzazione esplicita per le azioni irreversibili — e insieme non moltiplicare le approvazioni che non riducono davvero il rischio. La documentazione del cloud agent è la lettura giusta per questo dominio: le mitigazioni descritte lì (revisione umana obbligatoria delle pull request, push su un solo branch, accesso a internet limitato, commit firmati) sono esattamente il modello mentale che l’esame chiede.

Come prepararsi

1. Parti dalla study guide, ma non fermarti lì. Elenca i sei domini con i pesi e usali come checklist. Attenzione a due dettagli: la study guide si intitola Developing in Agentic AI Systems mentre la certificazione si chiama GitHub Certified: Agentic AI Developer, e alcuni link alla documentazione che contiene puntano a pagine che nel frattempo sono state spostate. Non è un problema di contenuto, è un segnale di quanto in fretta si muove questa materia.
2. Costruisci una tabella delle superfici. Per ogni capacità — permessi dei tool, allow list MCP, memoria, telemetria, approvazioni — segna dove esiste e dove no. È l’esercizio che rende gran parte delle domande banali.
3. Fai girare davvero un agente. Assegna un’issue al cloud agent, aggiungi un server MCP con una allow list stretta, guarda i log di sessione e la pull request in bozza. I domini su errori, memoria e guardrail si capiscono in un pomeriggio di pratica meglio che in tre giorni di lettura.
4. Ragiona per rischio, non per comodità. Quasi tutte le domande a scenario si risolvono chiedendosi qual è l’azione irreversibile qui, e chi la autorizza.
5. Chiudi con le simulazioni. Il percorso di preparazione GH-600 su CertUp segue i sei domini modulo per modulo; quando lo hai finito, passa alla simulazione d’esame GH-600 per trovare le aree deboli. Un avviso onesto: la nostra sessione estrae 50 domande in 120 minuti con soglia 700, dove durata e soglia sono quelle ufficiali e il numero di domande è una convenzione nostra, dato che GitHub non lo pubblica. Le domande sono in inglese come all’esame vero, con la spiegazione in italiano; usiamo scelta singola, scelta multipla e griglie sì/no, e non riproduciamo i tipi interattivi che puoi provare nel sandbox ufficiale.

Due cose che le fonti ufficiali non dicono, o dicono in modo discorde

Vale la pena scriverle invece di far finta di niente. Il prezzo non è pubblicato: la pagina della credenziale dice che dipende dal paese o dalla regione in cui l’esame viene erogato, e lo vedi al momento della prenotazione su Pearson VUE. Sulla validità le fonti ufficiali divergono: la study guide riporta la riga standard del catalogo Microsoft (“le certificazioni associate, expert e specialty scadono ogni anno e si rinnovano con un assessment online gratuito”), ma la stessa pagina della credenziale dice che la certificazione è mantenuta da GitHub, e la documentazione GitHub sulle certificazioni non indica una durata per questa credenziale — al momento non la elenca nemmeno fra le proprie. Finché le due pagine non si allineano, l’unica risposta corretta è: controllala tu prima di pianificare il rinnovo.

In sintesi

Il GH-600 certifica una competenza che un anno fa non esisteva come mestiere: far lavorare agenti dentro il processo di sviluppo senza rinunciare al controllo. È un esame a scenario, pesato sugli strumenti e sull’ambiente, che premia chi ha davvero configurato un MCP server, letto un log di sessione e deciso quali azioni un agente non può compiere da solo. Se stai costruendo il tuo percorso GitHub, confronta questa credenziale con le altre nella scheda della certificazione su CertUp — e ricordati che su questa, più che su ogni altra, la fonte ufficiale va riaperta prima di prenotare.