--- title: "AI Native Journey: l'AI nel team di sviluppo | SparkFabrik" url: "https://www.sparkfabrik.com/it/ai-native-journey/" lang: "it" type: "service" date: "2026-10-03" lastmod: "2026-10-30" description: "Porta l'AI nel modo in cui il tuo team sviluppa: prima regole e costi visibili, poi il metodo sul tuo codice. Baseline, pilota misurato, roll-out." keywords: ["AI Native Journey","AI nel team di sviluppo","adozione AI sviluppo software","training on the job AI","spec driven development","AgentOps"] image: "https://www.sparkfabrik.com/images/og/ai-native-journey.webp" translations: en: "https://www.sparkfabrik.com/en/ai-native-journey/index.md" schema: {"@context":"https://schema.org","@id":"https://www.sparkfabrik.com/it/ai-native-journey/#service","@type":"Service","areaServed":[{"@type":"Country","name":"Italy"},{"@type":"Place","name":"Europe"}],"audience":{"@type":"Audience","audienceType":"CTO, Engineering Manager, Platform Team"},"description":"Porta l'AI nel modo in cui il tuo team sviluppa: prima regole e costi visibili, poi il metodo sul tuo codice. Baseline, pilota misurato, roll-out.","name":"AI Native Journey","provider":{"@id":"https://www.sparkfabrik.com/#organization"},"serviceType":"AI Native Journey","url":"https://www.sparkfabrik.com/it/ai-native-journey/"} --- # AI Native Journey per il tuo team di sviluppo. 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. [Le fasi](https://www.sparkfabrik.com/it/ai-native-journey/#fasi) [Scrivici del tuo progetto](https://www.sparkfabrik.com/it/contatti/) - Pilota misurato - Sul tuo repository - Nessun lock-in ## 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](https://www.sparkfabrik.com/it/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. - **Regole prima della formazione**: Settings, permessi e budget sono attivi prima che il team cominci. - **Training on the job**: Si impara sulle funzionalità e sui bug del tuo progetto, e il lavoro consegnato resta al team. - **Risultati misurati**: Metriche e valori di partenza si concordano prima del pilota e si confrontano alla fine. - **Un processo definito**: Ogni fase si chiude con una tua decisione, con un referente dedicato e incontri settimanali. ## Tre fasi, ognuna chiusa da una tua decisione. Configuriamo gli strumenti prima di formare il team, e misuriamo prima di estendere il metodo. 1. **Baseline** Sappiamo come il team usa l'AI oggi e dove si blocca. 2. **Programma pilota** Un team lavora con regole, strumenti e metodo comuni, e misuriamo i risultati. 3. **Roll-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](https://www.sparkfabrik.com/it/ai-native-journey/#percorso) ## 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. 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 2. **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. - Da dove viene: [AgentOps: governare e monitorare gli agenti AI in produzione](https://www.sparkfabrik.com/it/blog/agentops-governare-e-monitorare-gli-agenti-ai-in-produzione/), [Claude Code Usage](https://playbook.sparkfabrik.com/ai-development/claude-code-usage) - 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 3. **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. - Da dove viene: [Spec driven development: oltre il vibe coding](https://www.sparkfabrik.com/it/blog/guida-allo-spec-driven-development/), [sf-agents-harness](https://github.com/sparkfabrik/sf-agents-harness) - 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 4. **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. - Da dove viene: [Talks on my Machine: AI Native Engineering](https://www.sparkfabrik.com/it/eventi/tomm-ai-native-engineering/) - 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 5. **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. - Da dove viene: [AI e DevOps: le nuove frontiere per lo sviluppo software](https://www.sparkfabrik.com/it/blog/ai-devops-intelligenza-artificiale/) - 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 6. **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. - Da dove viene: [I moduli Drupal AI Guardrails che manteniamo](https://www.sparkfabrik.com/it/servizi/drupal/drupal-certified-partner/) - 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 7. **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. - Da dove viene: [Formazione](https://www.sparkfabrik.com/it/servizi/consultancy-design/formazione/) - Cosa facciamo: Formazione per ruolo, Misura delle metriche concordate - Cosa resta al team: Risultati misurati, Piano di roll-out 8. **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. (opzionale) - 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 9. **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. (opzionale) - Da dove viene: [AI Development](https://www.sparkfabrik.com/it/servizi/ai-development/) - 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. [Scrivici del tuo progetto](https://www.sparkfabrik.com/it/contatti/) [Il metodo: AI Native Engineering](https://www.sparkfabrik.com/it/ai-native-engineering/) 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. - [Playbook](https://playbook.sparkfabrik.com/ai-development/overview), Metodo pubblico: Il nostro modo di lavorare con l'AI, scritto e pubblico. - [Harness](https://github.com/sparkfabrik/sf-agents-harness), GitHub: sf-agents-harness: gli strumenti con cui integriamo l'AI nello sviluppo, open source. - [La nota](https://www.sparkfabrik.com/it/chi-siamo/ai-vision/), Nota del CTO: La nostra visione sull'AI, firmata dai fondatori, marzo 2026. ## 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. - Partire da un Journey: [Cloud Native Journey](https://www.sparkfabrik.com/it/cloud-native-journey/): Le fasi per portare il team sul cloud native. - Confrontare i servizi: [Formazione](https://www.sparkfabrik.com/it/servizi/consultancy-design/formazione/): Workshop e corsi. - Confrontare i servizi: [AI Development](https://www.sparkfabrik.com/it/servizi/ai-development/): L'AI nei prodotti. ## 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](https://www.sparkfabrik.com/it/contatti/) - CEO: Stefano Mainardi, [Prenota 30 minuti](https://calendar.app.google/5N7BejeB8h1HpkYs7) - CTO: Paolo Mainardi, [Prenota 30 minuti](https://calendar.app.google/gwe2fWtNU1aL31JCA) Aggiornato il 30 ottobre 2026. --- *Questa è la versione in Markdown della pagina, per facilitare la lettura da parte di AI e crawler. Visita [https://www.sparkfabrik.com/it/ai-native-journey/](https://www.sparkfabrik.com/it/ai-native-journey/) per la versione completa con immagini e interazioni.*