Italiano EN English

AI Native Journey per il tuo team di sviluppo

Pilota misuratoSul tuo repositoryNessun lock-in

Porta l’AI nel modo in cui il tuo team sviluppa. Prima configuriamo gli strumenti e rendiamo visibili i costi, poi applichiamo il metodo sul tuo codice e misuriamo i risultati.

I tuoi sviluppatori usano già l’AI. Ognuno a modo suo.

L’AI Native Journey è un programma per adottare l’AI nello sviluppo software: il tuo team impara a usarla in ogni fase del lavoro, insieme ai nostri engineer. SparkFabrik è una tech company di AI Native Engineering: usa lo stesso metodo nei progetti dei clienti ed è membro di CNCF, OpenSSF e Linux Foundation Europe.

Strumenti diversi, configurazioni diverse da una postazione all’altra, nessuna memoria condivisa del progetto. I risultati dipendono dalla persona, e uso e costi non li vede nessuno.

Comprare un altro strumento non cambia il risultato. Un corso nemmeno, se poi il lavoro di tutti i giorni resta uguale.

Serve un metodo comune, adottato dal tuo team sul tuo codice, che resti quando ce ne andiamo.

Un team che lavora con l’AI, a regola d’arte.

Alla fine il tuo team lavora con l’AI in ogni fase, e il lavoro fatto è suo.

Tre fasi, ognuna chiusa da una tua decisione.

Configuriamo gli strumenti prima di formare il team, e misuriamo prima di estendere il metodo.

  1. 01BaselineSappiamo come il team usa l’AI oggi e dove si blocca.
  2. 02Programma pilotaUn team lavora con regole, strumenti e metodo comuni, e misuriamo i risultati.
  3. 03Roll-out (opzionale)La pratica si estende agli altri team e al resto dell’azienda.

Alla fine di ogni fase decidi tu se proseguire, con noi o con un altro fornitore. Il modulo opzionale «Dal team al prodotto» si aggiunge quando serve.

Le fasi nel dettaglio

Le fasi nel dettaglio.

Le tre fasi, passo per passo: per ogni passo trovi cosa facciamo, cosa resta al tuo team e da quale lavoro già pubblicato viene.

Fase 1

Baseline

Sappiamo come il team usa l’AI oggi e dove si blocca.

Survey e interviste al team, lettura della configurazione, dei dati d’uso e costi e di un campione di pull request. Confrontiamo le regole su dati e codice con quello che succede nel lavoro di tutti i giorni.

Cosa facciamo
  • Survey e interviste al team
  • Review di settings, MCP e plugin in uso
  • Dati d’uso e costi disponibili
  • Un campione di pull request fatte con l’AI
  • Vincoli su dati, licenze e policy aziendali
Cosa resta al team
  • Baseline con il collo di bottiglia principale
  • Team pilota scelto
  • Metriche con i valori di partenza
Fase 2, pilota

Governance e costi

Regole e costi sono attivi prima che il team cominci.

Configuriamo settings gestiti e permessi di Claude Code, Codex o OpenCode, MCP e plugin approvati, modelli e budget per team. La telemetria con OpenTelemetry mostra uso e costi, senza raccogliere il contenuto dei prompt.

Cosa facciamo
  • Settings gestiti e account di lavoro separati
  • Modelli e budget per team
  • Telemetria su uso, token e costi
Cosa resta al team
  • Configurazione versionata
  • Cruscotto di uso e costi
  • Policy su dati e codice
Fase 2, pilota

Contesto, specifiche e harness

Il progetto smette di vivere nella testa delle persone.

Scriviamo nel repository architettura, convenzioni e istruzioni in AGENTS.md, valide per ogni strumento. Ogni lavoro non banale parte da una specifica, e il catalogo di skill e plugin lo mantiene il tuo team.

Cosa facciamo
  • Architettura e convenzioni scritte nel repository
  • Spec driven development e ADR
  • Contesto valido per qualsiasi strumento AI
  • Catalogo di skill e plugin, con versioni e review
Cosa resta al team
  • Contesto di progetto versionato
  • Template di specifica
  • Guida per chi mantiene il catalogo
Fase 2, pilota

Sviluppo e integrazioni

Il team consegna funzionalità vere, con l’AI dentro il lavoro.

Lavoriamo sul backlog del team pilota, fianco a fianco, in ambienti con permessi limitati a quello che serve. I server MCP verso ticketing, documentazione e API interne li scegliamo in base alle metriche concordate.

Cosa facciamo
  • AI in analisi, scrittura e refactoring
  • Server MCP scelti sulle metriche
  • Ambienti e permessi circoscritti
Cosa resta al team
  • Prime funzionalità consegnate
  • Integrazioni attive
  • Team formato sul lavoro reale
Fase 2, pilota

Review, test e delivery

Niente va in produzione senza controlli e senza l’approvazione di una persona.

Ogni modifica, scritta a mano o con l’AI, passa dalla pipeline che il team usa già: test, controlli automatici e review prima del rilascio. I commit fatti con un agente lo dichiarano.

Cosa facciamo
  • Regole di review per il codice scritto con l’AI
  • Review con l’AI in CI, prima di quella umana
  • Test e controlli in CI/CD
  • Approvazione di una persona del team su ogni rilascio
Cosa resta al team
  • Pipeline con i controlli
  • Regole di review scritte
  • Commit fatti con l’AI tracciabili
Fase 2, pilota

Sicurezza e guardrail

Le regole su dati e codice diventano automatiche.

Mettiamo per iscritto, e poi in pipeline, cosa gli strumenti AI possono toccare, quali dati possono uscire e come si verifica il codice. Valutiamo se serve un gateway verso i provider e se affiancare modelli open-weight in locale per il codice più sensibile.

Cosa facciamo
  • Dati che escono e dati che restano
  • Dipendenza dai fornitori di modelli
  • Supply chain del codice
Cosa resta al team
  • Policy d’uso
  • Guardrail attivi
  • Verifiche automatiche in pipeline
Fase 2, pilota

Formazione e risultati

Il pilota si chiude con risultati misurati.

Formazione per ruolo sul tuo codice: sviluppatori, tech lead, chi mantiene skill e plugin, management. A fine pilota confrontiamo le metriche con i valori di partenza.

Cosa facciamo
  • Formazione per ruolo
  • Misura delle metriche concordate
Cosa resta al team
  • Risultati misurati
  • Piano di roll-out
Fase 3

Roll-out

La pratica si estende al resto dell’azienda.

Estendiamo la pratica a tutti i team di sviluppo, un’ondata alla volta, e alle funzioni non tecniche. Formiamo referenti interni che continuano senza di noi.

Cosa facciamo
  • Ondate per i team di sviluppo
  • Linee guida per product, sales e amministrazione
  • Train-the-trainer
Cosa resta al team
  • Referenti interni formati
  • Materiali per ogni ondata
Modulo opzionale

Dal team al prodotto

Dopo il metodo, l’AI entra nel prodotto.

Quando il team lavora con il metodo, partiamo da un caso d’uso del tuo prodotto e ne facciamo un PoC.

Cosa facciamo
  • AI Discovery sul tuo processo
  • Dal PoC all’MVP
Cosa resta al team
  • PoC di una funzione AI nel prodotto
  • Piano verso l’MVP

Il tuo team, autonomo alla fine.

Contesto, ambienti e regole restano nel tuo repository e il team li sa usare, quindi non dipendi da noi.

  1. Incontri settimanali

    Ogni settimana facciamo il punto con il team e con chi decide.

  2. Implementazioni funzionanti

    Il valore sta nelle cose consegnate: contesto, pipeline, funzionalità.

  3. Referente dedicato

    Teoria, operatività e supporto fanno capo a una persona sola.

Si parte dalla baseline del tuo team.

La fase 1 dice da dove parte il team, dove si blocca e come misurare il pilota.

Le prove

Il metodo è pubblico.

Lavoriamo così anche noi: policy gestite dall’organizzazione, profili separati per l’uso personale, regole su modelli e limiti. È tutto nel playbook pubblico.

Domande frequenti.

Sull’AI Native Journey.

Cos’è l’AI Native Journey?

Un percorso in tre fasi che porta l’AI nel modo in cui il tuo team sviluppa software: baseline, programma pilota misurato e roll-out opzionale. Regole e costi visibili vengono prima della formazione, e ogni fase si chiude con una tua decisione. Ha la stessa forma del Cloud Native Journey: training on the job, deliverable per ogni fase e un referente dedicato.

A chi è rivolto?

Agli engineering manager, ai CTO e ai platform team che hanno già strumenti AI, ma ognuno li usa a modo suo, senza regole comuni e senza sapere quanto costano.

Quanto dura?

Dipende dal team e dal codice da cui si parte. La durata e il numero di giornate di formazione si definiscono alla fine della fase 1, Baseline.

Con quali strumenti lavorate?

Claude Code, Codex, OpenCode, GitHub Copilot: partiamo da quello che il team usa già. Regole e skill sono in formati aperti, AGENTS.md e Markdown, quindi il metodo non dipende da uno strumento o da un modello.

Cosa resta al team alla fine?
  • Configurazione, permessi e budget versionati
  • Cruscotto di uso e costi
  • Contesto e convenzioni del progetto nel repository
  • Template di specifica
  • Ambienti e permessi configurati
  • Pipeline con controlli e regole di review
  • Un team che lavora con lo stesso metodo
E la sicurezza del codice e dei dati?

Gli strumenti AI lavorano con permessi circoscritti, il codice passa dagli stessi controlli di qualunque altro codice e una persona del team approva ogni rilascio. Nella fase 2 queste regole vengono messe per iscritto e rese automatiche.

Come misurate i risultati?

Con metriche concordate prima del pilota: adozione, lead time da ticket a merge, rilavorazione, tracciabilità dei commit fatti con l’AI, costo e token per compito.

Possiamo fermarci dopo una fase?

Sì. Ogni fase si chiude con una tua decisione, e quello che abbiamo costruito resta nei tuoi repository.

Che differenza c’è con la formazione?

La formazione insegna. Il Journey lavora sul tuo codice e sul backlog del team: alla fine restano funzionalità consegnate e regole in pipeline.

Dove andare dopo.

Parla con il CEO o con il CTO.

Raccontaci come lavora oggi il tuo team e su quale progetto. Ti diciamo da dove partirebbe la fase 1.

Scrivici del tuo progetto

Aggiornato il