IT

Where to start

AI Native Journey for your development team

Measured pilotOn your repositoryNo lock-in

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 phasesTell us about your project

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 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.

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. 01BaselineWe know how the team uses AI today and where it gets stuck.
  2. 02Pilot programOne team works with shared rules, tools and method, and we measure the results.
  3. 03Roll-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

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.

Phase 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
Phase 2, pilot

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.

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
Phase 2, pilot

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.

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
Phase 2, pilot

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.

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
Phase 2, pilot

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.

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
Phase 2, pilot

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.

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
Phase 2, pilot

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.

What we do
  • Training by role
  • Measurement of the agreed metrics
What stays with the team
  • Measured results
  • Roll-out plan
Phase 3

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.

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
Optional module

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.

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 The method: 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

Our way of working with AI, written down and public.Public method

Harness

sf-agents-harness: the tools we use to bring AI into development, open source.GitHub

The note

Our vision for AI, signed by the founders, March 2026.Note from the CTO

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.

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
CEO Stefano MainardiBook 30 minutes CTO Paolo MainardiBook 30 minutes

Updated