---
title: "AI Native Journey: AI in your development team | SparkFabrik"
url: "https://www.sparkfabrik.com/en/ai-native-journey/"
lang: "en"
type: "service"
date: "2026-10-03"
lastmod: "2026-10-30"
description: "Bring AI into the way your team builds software: rules and visible costs first, then the method on your code. Baseline, measured pilot, roll-out."
keywords: ["AI Native Journey","AI in the development team","AI adoption in software development","AI training on the job","spec driven development","AgentOps"]
image: "https://www.sparkfabrik.com/images/og/ai-native-journey-en.webp"
translations:
  it: "https://www.sparkfabrik.com/it/ai-native-journey/index.md"
schema: {"@context":"https://schema.org","@id":"https://www.sparkfabrik.com/en/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":"Bring AI into the way your team builds software: rules and visible costs first, then the method on your code. Baseline, measured pilot, roll-out.","name":"AI Native Journey","provider":{"@id":"https://www.sparkfabrik.com/#organization"},"serviceType":"AI Native Journey","url":"https://www.sparkfabrik.com/en/ai-native-journey/"}
---

# AI Native Journey for your development team.

Bring AI into the way your team builds software. First we set up the tools and make costs visible, then we apply the method to your code and measure the results.

[The phases](https://www.sparkfabrik.com/en/ai-native-journey/#fasi)

[Tell us about your project](https://www.sparkfabrik.com/en/contact-us/)

- Measured pilot
- On your repository
- No lock-in

## Your developers already use AI. Each in their own way.

The AI Native Journey is a program for adopting AI in software development: your team learns to use it in every phase of the work, together with our engineers. SparkFabrik is an [AI Native Engineering](https://www.sparkfabrik.com/en/ai-native-engineering/) company: it uses the same method on client projects and is a member of CNCF, OpenSSF and Linux Foundation Europe.

Different tools, configurations that differ from one workstation to the next, no shared memory of the project. Results depend on the person, and nobody sees usage and costs.

Buying another tool does not change the result. Neither does a course, if the everyday work then stays the same.

**You need a common method, adopted by your team on your codebase, that stays when we leave.**

## A team that works well with AI.

By the end your team works with AI in every phase, and the work done is its own.

- **Rules before training**: Settings, permissions and budgets are in place before the team starts.
- **Training on the job**: You learn on your project's features and bugs, and the work delivered stays with the team.
- **Measured results**: Metrics and starting values are agreed before the pilot and compared at the end.
- **A well-defined process**: Every phase closes with your decision, with a dedicated contact person and weekly meetings.

## Three phases, each closed by your decision.

We set up the tools before we train the team, and we measure before we extend the method.

1. **Baseline** We know how the team uses AI today and where it gets stuck.
2. **Pilot program** One team works with shared rules, tools and method, and we measure the results.
3. **Roll-out (optional)** The practice extends to the other teams and to the rest of the company.

At the end of every phase you decide whether to go on, with us or with another supplier. The optional module “From the team to the product” is added when needed.

[The phases in detail](https://www.sparkfabrik.com/en/ai-native-journey/#percorso)

## The phases in detail.

The three phases, step by step: for each step you find **what we do, what stays with your team** and which published work it comes from.

1. **Baseline**: We know how the team uses AI today and where it gets stuck. A survey and interviews with the team, a review of the configuration, of the usage and cost data and of a sample of pull requests. We compare the rules on data and code with what happens in everyday work.
   - What we do: Team survey and interviews, Review of the settings, MCP servers and plugins in use, Available usage and cost data, A sample of pull requests made with AI, Constraints on data, licenses and company policies
   - What stays with the team: Baseline with the main bottleneck, Pilot team chosen, Metrics with their starting values
2. **Governance and costs**: Rules and costs are in place before the team starts. We configure the managed settings and permissions of Claude Code, Codex or OpenCode, the approved MCP servers and plugins, the models and the budget per team. Telemetry with OpenTelemetry shows usage and costs, without collecting the content of prompts.
   - Where it comes from: [AgentOps: governing and monitoring AI agents in production](https://www.sparkfabrik.com/en/blog/agentops-governing-monitoring-ai-agents/), [Claude Code Usage](https://playbook.sparkfabrik.com/ai-development/claude-code-usage)
   - What we do: Managed settings and separate work accounts, Models and budget per team, Telemetry on usage, tokens and costs
   - What stays with the team: Versioned configuration, Usage and cost dashboard, Policies on data and code
3. **Context, specifications and harness**: The project stops living in people's heads. We write architecture, conventions and instructions into the repository in AGENTS.md, valid for every tool. Every non-trivial piece of work starts from a specification, and your team maintains the catalogue of skills and plugins.
   - Where it comes from: [Spec driven development: beyond vibe coding](https://www.sparkfabrik.com/en/blog/spec-driven-development-guide/), [sf-agents-harness](https://github.com/sparkfabrik/sf-agents-harness)
   - What we do: Architecture and conventions written in the repository, Spec driven development and ADRs, Context valid for any AI tool, Catalogue of skills and plugins, with versions and review
   - What stays with the team: Versioned project context, Specification template, Guide for the catalogue maintainers
4. **Development and integrations**: The team delivers real features, with AI inside the work. We work on the pilot team's backlog, side by side, in environments with permissions limited to what is needed. We choose the MCP servers for ticketing, documentation and internal APIs by the agreed metrics.
   - Where it comes from: [Talks on my Machine: AI Native Engineering](https://www.sparkfabrik.com/en/events/tomm-ai-native-engineering/)
   - What we do: AI in analysis, writing and refactoring, MCP servers chosen by the metrics, Scoped environments and permissions
   - What stays with the team: First features delivered, Integrations in place, Team trained on real work
5. **Review, testing and delivery**: Nothing goes to production without checks and without a person's approval. Every change, written by hand or with AI, goes through the pipeline the team already uses: tests, automated checks and review before release. Commits made with an agent declare it.
   - Where it comes from: [AI and DevOps: the new frontiers of software development](https://www.sparkfabrik.com/en/blog/ai-devops-artificial-intelligence/)
   - What we do: Review rules for code written with AI, AI review in CI, before the human one, Tests and checks in CI/CD, Approval by a team member on every release
   - What stays with the team: Pipeline with the checks, Written review rules, Traceable commits made with AI
6. **Security and guardrails**: The rules on data and code become automatic. We write down, and then put in the pipeline, what AI tools may touch, which data may leave and how the code is checked. We assess whether a gateway to the providers is needed and whether to add open-weight models running locally for the most sensitive code.
   - Where it comes from: [The Drupal AI Guardrails modules we maintain](https://www.sparkfabrik.com/en/services/drupal/drupal-certified-partner/)
   - What we do: Data that leaves and data that stays, Dependence on model providers, Code supply chain
   - What stays with the team: Usage policy, Active guardrails, Automated checks in the pipeline
7. **Training and results**: The pilot closes with measured results. Training by role on your code: developers, tech leads, the maintainers of skills and plugins, management. At the end of the pilot we compare the metrics with their starting values.
   - Where it comes from: [Training](https://www.sparkfabrik.com/en/services/consultancy-design/training/)
   - What we do: Training by role, Measurement of the agreed metrics
   - What stays with the team: Measured results, Roll-out plan
8. **Roll-out**: The practice extends to the rest of the company. We extend the practice to every development team, one wave at a time, and to the non-technical functions. We train internal leads who carry on without us. (optional)
   - What we do: Waves for the development teams, Guidelines for product, sales and administration, Train-the-trainer
   - What stays with the team: Trained internal leads, Materials for each wave
9. **From the team to the product**: After the method, AI enters the product. Once the team works with the method, we start from a use case of your product and take it to a PoC. (optional)
   - Where it comes from: [AI Development](https://www.sparkfabrik.com/en/services/ai-development/)
   - What we do: AI Discovery on your process, From PoC to MVP
   - What stays with the team: PoC of an AI feature in the product, Plan towards the MVP

## Your team, autonomous at the end.

Context, environments and rules stay in your repository and the team knows how to use them, so you do not depend on us.

1. **Weekly meetings**: Every week we review progress with the team and with whoever decides.
2. **Working implementations**: The value lies in what is delivered: context, pipelines, features.
3. **Dedicated contact person**: Theory, operations and support all go through one named person.

**It starts with a baseline of your team.** Phase 1 shows where the team starts, where it gets stuck and how to measure the pilot. [Tell us about your project](https://www.sparkfabrik.com/en/contact-us/) [The method: AI Native Engineering](https://www.sparkfabrik.com/en/ai-native-engineering/)

The proof

## The method is public.

We work this way too: policies managed by the organization, separate profiles for personal use, rules on models and limits. It is all in the public playbook.

- [Playbook](https://playbook.sparkfabrik.com/ai-development/overview), Public method: Our way of working with AI, written down and public.
- [Harness](https://github.com/sparkfabrik/sf-agents-harness), GitHub: sf-agents-harness: the tools we use to bring AI into development, open source.
- [The note](https://www.sparkfabrik.com/en/who-we-are/ai-vision/), Note from the CTO: Our vision for AI, signed by the founders, March 2026.

## Frequently asked questions.

About the AI Native Journey.

### What is the AI Native Journey?

A three-phase path that brings AI into the way your team builds software: baseline, measured pilot program and optional roll-out. Rules and visible costs come before training, and every phase closes with your decision. It has the same shape as the Cloud Native Journey: training on the job, deliverables for each phase and a dedicated contact person.

### Who is it for?

Engineering managers, CTOs and platform teams who already have AI tools, but where everyone uses them in their own way, without common rules and without knowing how much they cost.

### How long does it take?

It depends on the team and on the code it starts from. The duration and the number of training days are defined at the end of phase 1, Baseline.

### Which tools do you work with?

Claude Code, Codex, OpenCode, GitHub Copilot: we start from what the team already uses. Rules and skills are in open formats, AGENTS.md and Markdown, so the method does not depend on one tool or one model.

### What stays with the team at the end?

- Versioned configuration, permissions and budgets
- Usage and cost dashboard
- Project context and conventions in the repository
- Specification template
- Environments and permissions configured
- Pipeline with checks and review rules
- A team that works with the same method

### What about the security of code and data?

AI tools work with scoped permissions, the code goes through the same checks as any other code and a person on the team approves every release. In phase 2 these rules are put in writing and made automatic.

### How do you measure the results?

With metrics agreed before the pilot: adoption, lead time from ticket to merge, rework, traceability of commits made with AI, cost and tokens per task.

### Can we stop after a phase?

Yes. Every phase closes with your decision, and what we built stays in your repositories.

### How is it different from training?

Training teaches. The Journey works on your code and your team's backlog: at the end you keep delivered features and rules in the pipeline.

## Where to go next.

- Start from a Journey: [Cloud Native Journey](https://www.sparkfabrik.com/en/cloud-native-journey/): The phases to bring the team to cloud native.
- Compare the services: [Training](https://www.sparkfabrik.com/en/services/consultancy-design/training/): Workshops and courses.
- Compare the services: [AI Development](https://www.sparkfabrik.com/en/services/ai-development/): AI in products.

## Talk to the CEO or the CTO.

Tell us how your team works today and on which project. We will tell you where phase 1 would start.

[Tell us about your project](https://www.sparkfabrik.com/en/contact-us/)

- CEO: Stefano Mainardi, [Book 30 minutes](https://calendar.app.google/5N7BejeB8h1HpkYs7)
- CTO: Paolo Mainardi, [Book 30 minutes](https://calendar.app.google/gwe2fWtNU1aL31JCA)

Updated October 30, 2026.

---

*This is the Markdown version of the page, to facilitate reading by AI and crawlers. Visit [https://www.sparkfabrik.com/en/ai-native-journey/](https://www.sparkfabrik.com/en/ai-native-journey/) for the full version with images and interactions.*
