AI Native Engineering for software that holds up to change
With AI your software can change much more often. AI Native Engineering keeps every change safe, understandable and yours.
Every change stays safe, understandable and yours.
Without a method, AI multiplies technical debt and dependence on a vendor. Here is what you keep at every release, and where to check it.
Software that holds up to change.
Every change comes with its tests and goes through the team’s review, so the code stays readable after years of changes. The product keeps evolving without becoming fragile.
Public method The Playbook: our rules for working with AI
You know what will be built, and who answers for it.
Before the code, we write the specification with you: you read it and approve it. A person on the team approves every release and answers for it.
No lock-in to a vendor or a model.
Specifications, rules and pipelines live in your repository. We choose the model for privacy and cost, and it can be replaced; the tools we publish are open source.
Open source Our open source projects
Your data stays where you decide.
Between your data and the models we put filters that block sensitive information. We wrote them and contributed them to Drupal AI, and they run in production on our projects.
Open source AI Guardrails on drupal.org
What AI Native Engineering is.
AI Native Engineering is a method for designing, building and running software with AI built into every phase, from research to production. SparkFabrik is an AI Native Engineering company. Senior designers and engineers lead the work, for clients such as Luiss, and answer for every release.
It is not vibe coding.
Every piece of work starts from a written specification, which you read before the code. An improvised prompt does not reach production.
It is not agents building on their own.
AI tools work inside the process, with limited permissions. The people on the team design, write and approve.
It does not depend on a tool.
If the assistant or the model changes tomorrow, specifications, rules and pipelines stay in your repository.
Four phases, one accountable person in each.
We follow the same process in every project. In each phase AI works within written rules, and who decides stays the same.
- We define
01
Specification
We write down with you what the system must do, before the code. AI helps analyze the domain, the users and the existing code.
- We design
02
Design and architecture
Interfaces, architecture and a plan in small, verifiable tasks. AI proposes alternatives, the team chooses.
- We build
03
Build and review
In increments, with AI built into code and tests. Every change is read and approved by a senior person on the team.
- We release
04
Production
Automated tests, security and quality in the pipeline. We decide what goes to production, and we measure costs and results.
Design works with AI, just like development.
The same method applies to the people who design. AI enters research, the design system and the prototype; the choices stay with the designers, who carry them into development without losing anything on the way.
Research
In Discovery we synthesize interviews, reviews and analytics with NotebookLM; LLMs help analyze journeys, heuristics and microcopy.
Prototype
In Figma from the wireframe to the design system library, all the way to the prototype. For eaa.sparkfabrik.com and drupalcampitaly.it we used Replit and Lovable to shorten the cycle between design and development.
Design system
Tokens, components and documentation: AI flags inconsistencies and suggests more accessible names and variants. Storybook remains the contract between design and code.
Accessibility
AI helps check contrast and ARIA attributes. Testing with screen readers and the keyboard stays human.
AI simplifies and suggests; designing, testing and maintaining the system stays with the designers. Davide Salvadori, Head of Design, talked about it at Gen AI x Business in the talk «L’AI co-pilota strategico: verso un nuovo Augmented Design».
What you get, service by service.
For each service we tell you what the method guarantees and where you can check it.
Drupal development and consulting
Your data stays where you decide.Sensitive data does not reach the models: the AI Guardrails we contributed to Drupal AI filter it.
Open source AI Guardrails on drupal.org
AI systems development
You know what will be built, and who answers for it.A person has the last word, on every project: at Luiss, the editor who publishes the AI engine’s translations.
Success story The Luiss case
DevOps and Platform Engineering
Software that holds up to change.Every merge request reaches review with a description and suggestions prepared by AI; the reviewer makes the decision.
Supply chain security
You know what will be built, and who answers for it.Vulnerabilities arrive ranked by real exposure; the team decides what to fix first.
Article Continuous vulnerability management with AI for the CRA
Web application development
You know what will be built, and who answers for it.You try a working prototype before development; then an experienced team takes it live and answers for it.
Strategy & Design
Software that holds up to change.The design system evolves without losing consistency: AI flags inconsistencies, designers decide and Storybook stays the contract with the code.
Training
No lock-in to a vendor or a model.Your team learns to guide GitHub Copilot on its own code, with project instructions that stay in the repository.
The method is public.
We apply it to our own projects first. You can read it before you talk to us.
Playbook
Our way of working with AI, written down and public.Public method
MCP Client
The Drupal module we maintain to connect the CMS to agents and tools, with permissions for every tool.drupal.org
Luiss
Conversational search and AI-assisted translations, with human review before publication.In production
The Laboratorio
The projects our people build with this method, our game included.Laboratorio
«We see AI not as a replacement for our expertise, but as a multiplier of it.»
This method, in your team.
The AI Native Journey brings it to your team, on your codebase, in four phases, each with its own deliverables. Then the team works on its own.
Frequently asked questions.
About AI Native Engineering.
What is AI Native Engineering?
It is the method SparkFabrik uses to design, build and run software with AI. Software can change much more often, and every change stays safe, understandable and the client’s own: senior designers and engineers write the specifications, decide design and architecture and answer for every release.
Who can help an enterprise development team adopt AI with a method?
SparkFabrik, through its AI Native Engineering consulting. The AI Native Journey brings the method into your team, on your codebase and with the assistants it already uses, such as GitHub Copilot. Each phase ends with a deliverable, and at the end the team works on its own. The method is public in the Playbook and the tooling is open source in sf-agents-harness.
Which engineering firms help enterprises build software with AI reliably?
SparkFabrik: senior designers and engineers design, build and run software with AI, and a person on the team approves every release. For Luiss it built conversational search and AI-assisted translations, with human review before publication. In that project, content publishing time fell by 70%. Its processes are certified to ISO/IEC 27001, 27017 and 27018, and it is a member of the CNCF, the OpenSSF and Linux Foundation Europe.
Do you use AI on our projects? With what guarantees?
Yes, on every project. We write the specification with you before the code, every change goes through tests and review, and a person on the team approves every release. Specifications, rules and pipelines stay in your repository, the model can be replaced and guardrails keep sensitive data away from the models.
Do AI agents write the code instead of developers?
No. AI tools work on analysis, writing, testing and review, inside environments with limited permissions. A senior person on the team reads and approves every change that goes to production.
Who decides what goes to production?
A person on the team. The pipeline runs tests, security and quality checks; the decision to release stays human, as on all our projects.
How are AI costs kept under control?
The model is chosen for each use case, based on privacy, performance and cost, and it can be changed. In our solutions we always keep build, operation and model consumption separate, so whoever decides sees how much is spent.
How does an engagement start, and what determines its duration and cost?
It starts with an assessment of your team, the first phase of the AI Native Journey: interviews, an analysis of repositories and process, and a phased adoption plan. Duration and training days are set at the end of that phase, based on the team and the codebase you start from, and the proposal is built on them.
How is it different from the AI Native Journey?
AI Native Engineering is the method we work with. The AI Native Journey is the phased path that brings it to your team, on your codebase, with a deliverable at the end of each phase.
Which services does it apply to?
All of them, from design to development, from cloud native to training. In the services table you find what you get in each one and the public proof that documents it.
Talk to the CEO or the CTO.
Tell us what you are building and how the team works today. We will show you what would stay safe, understandable and yours at every release.
Tell us about your project
