01Service · Products
Vibe Coding and AI-Based ProductsAn AI product that does not start from scratch.
We write the standard the whole company builds software to with AI, and build the core your AI products then run on. The next project starts from the standard, and the next product starts from the core.
Vibe Coding is building software with AI inside a written standard the AI reads before it works, and that fails whatever departs from it.
What arrives
- A repository template every new application is born from
- The first application in production built to the standard, alongside your team
- An agentic core every new product reuses
How it is boughtTwo projects: the standard for building with AI, and the core for AI products.
02Who it is for
Does any of this sound familiar?
- Everyone builds with AI their own way: a different tool, different instructions, a different architecture.
- The application ships fast, only its author can maintain it, and one area's application does not talk to the next.
- The first AI product worked in the demo, and the second started from scratch.
- Nobody can say where an answer came from, and the cost shows up on the invoice before it shows up on any dashboard.
When a wrong answer reaches the people using the product, the person who answers for it is you.
03At the end
Where the company stands when the work is done.
Every new application is born from the same template, and anyone on the team can maintain it.
The next AI product starts from the core already running, not from scratch.
Every answer cites its source, and no model change gets in without passing the scoring.
04Instead of
What usually gets tried first, and where it stops.
Letting each area build its own way
Where it stops
It ships fast, and each application becomes a system only its author understands.
Hiring a different team for each product
Where it stops
Each product arrives with its builder's architecture, and the next one starts from scratch.
Buying an off-the-shelf agent platform
Where it stops
It solves the building, but not the data, the evaluation questions or who answers for each agent.
05In your market
The same problem, under the name it has in your sector.
Real Estate
The credit team built its own analysis tool with AI, and only its author can maintain it. When an assistant answers an investor about the portfolio, the answer has to cite the contract the number came from.
Non-profit Sector
Every campaign got an application built with AI, and none of them talks to the donor base. When an assistant answers a donor about their own gift, the answer has to cite the record it came from, and the personal data stays masked.
Franchises and Multi-Unit Retail
Each unit or area built its own tool with AI, and the network can maintain none of them. When an assistant answers a franchisee about stock or the till, the answer has to cite the sale the number came from.
06The proposal
Two ways to engage, and the second is born from the first.
One module governs how the company builds software with AI; the other is what runs for the people using the product. Both are built in your repository and your cloud, with your team.
Engaging both
When both are bought, the core is born from the first module's repository template and clears the same checks. And when the product reads company data, it reads it through the data governance delivery and follows the same access policy.
07Module 1
Vibe Coding on the DDC Framework
For when several areas already build with AI, each its own way.
A project in six stages, from the survey to the handover, with the standard approved by the technical owner before the AI starts reading it.
Delivery
What stays with you
The starting point
- A survey of the repositories, the applications the areas built and the path from an idea to production
- A measurement, on your own repository, of how much of what the AI produces the team can review, integrate and test (the absorption ceiling)
The standard, written once
- The business layer: what the company is, its domain vocabulary and what it refuses
- The product layer: voice, design system and who each application is built for
- The engineering layer: technologies with pinned versions, data and API contracts, and security, validation and testing rules
See the rest
- The operations layer: environments, deploy, release, rollback and monitoring
What the AI reads before it works
- Rules the agent loads, always active or scoped to a part of the code, each pointing to the source (rules)
- Instructions per technology and per practice, loaded when the work calls for them (skills)
- Agents that write, review and test code, one per development role, each with what it reads and the tools it may use
What fails the work
- Checks inside the agent's own session that block what a rule forbids before the commit (gates)
- Checks running in your own continuous integration, each one able to fail
Every new application to the standard
- A repository template with the standard inside, from which every new application is born
- The standard path of a new application, from spec and plan to review and deploy, with a decision record for each choice
- The first application in production built to the standard, alongside your team
The handover
- A catalogue of the company's applications, with the owner and operating manual of each
- A working agreement for AI-assisted delivery: what is governed, what is reviewed, what is blocked
- Maintainers of the standard named on the team and trained to update it
Stages
How it works, stage by stage
Stage 1: Survey and measurement
We start from what already exists: repositories, the areas' applications and the path from idea to production. On your own history we measure how much the team can review, integrate and test, which is the real limit.
Done when there is a measure of how much the team can review, integrate and test today.
Stage 2: The standard, written with you
We write the standard for business, product, engineering and operations with you. The technical owner approves it before the AI starts reading it.
Done when the technical owner approves the standard.
Technical detail
The standard follows the four layers of the DDC Framework and becomes the harness: the contexts, rules and agents the AI reads before it works.
Nothing moves on without your approval.
Stage 3: What the AI reads
The AI starts working from the standard, without anyone having to repeat it on every request.
Done when the team's AI works from the standard in every active repository.
Technical detail
Rules, instructions and agents that point to that source and never repeat it.
Stage 4: The checks
Automated checks fail the work that departs from the standard before it reaches production.
Done when each check has already failed at least one case on purpose.
Technical detail
They fail work in the agent's session and in continuous integration. Each one proves it can fail before its silence counts for anything.
Stage 5: Template and first application
Every new application is born from the template and follows the same path. We build the first with the team; the team builds the second and we review it.
Done when the first application is in production and the second was born from the template.
Stage 6: Handover
We stay with the team as it maintains the standard and reviews the new applications.
Done when the team updates the standard without us.
Participation
Who from your team takes part
- A sponsor
- A technical owner who decides the standard
- One person from each area that builds with AI
- Your repositories
Measurement
How you know it worked
Measured in your own operation, before and after.
- Active repositories carrying the four layers, over all active repositories
- New applications created from the repository template, over all new applications
- Time from an approved idea to the first production version of a new application, before and after
- Review findings a rule already forbade, before and after
- Deliveries that clear the checks on the first attempt
- Size of the review queue, measured in your own repository before and after
- Rework per delivery, counted in the project's own history
- Applications in production with no named owner or no operating manual
- Time until a new person ships their first change inside the standard
- Updates to the standard made by the team itself after the handover
08Module 2
Agentic Core for AI Products
For when the second AI product is about to start from scratch again.
A project in five stages, from the problem and the data to operation, with the core's design approved before anything is built.
Delivery
What stays with you
Before the architecture
- A map of the problem and the data: the task the product solves, who uses it, and every source the agent consults, with owner, quality, legal basis and who may see it
- A set of real questions, with the expected answer and the source, written with your specialists (the evaluation set)
- The core's design, with a decision record for each choice
The core
- An agentic core running in your repository, which every new product reuses instead of copying
- The product's agents and the instructions they load, versioned, with a step limit and a cost budget per run
- Connections to your systems, each checking what it receives, including MCP servers (tools and connectors)
See the rest
- Fixed sequences of steps handled as a flow, kept apart from the agent (workflows)
- A knowledge base that reads your documents, searches by meaning and by keyword, returns only what the person asking may see, updates when a source changes and always cites where the answer came from
- Short- and long-term memory, with a limit, a retention period and deletion at the data subject's request
The limits
- Limits on input, output and action: the retrieved passage treated as untrusted input, personal data masked, an unsourced answer replaced by saying it was not found, reserved actions handed back to whoever approves (guardrails)
- A record of every call: path, cost, response time and the passages consulted, with the score of each (telemetry)
The first product and the next
- The first product in production on the core
- A product template your team uses to start the next one
- Automated scoring of answers at every change (evals), and the check that fails a change of prompt or model that takes the score out of the accepted band
See the rest
- An operating manual per product agent, with a named owner on the team (runbook)
Stages
How it works, stage by stage
Stage 1: Problem and data
We start from the task the product has to solve and work back to the data the agent will consult and who may see each part. With your specialists we write the real questions, the expected answer and its source.
Done when the real questions, with the expected answer and the source, are written with the specialists.
Stage 2: Core design
We design what each agent does, how far it goes and how much each run may cost. The board approves the design before anything is built.
Done when the board approves the core's design.
Technical detail
Each agent with a narrow contract, a step limit and a budget per run; what is a fixed sequence becomes a flow, not an agent.
Nothing moves on without your approval.
Stage 3: Building the core
We build in your repository and your cloud, with your engineers, and the core stays with them.
Done when the core runs in your cloud, operated by your engineers.
Technical detail
Agents, tools, workflows, knowledge base, memory, guardrails and evals.
Stage 4: First product
The first product goes into production on the core, and your team starts the second while we are still in the room.
Done when the first product is in production and the second has already started.
Stage 5: Scoring and operation
No change gets in without passing the scoring, and each agent passes to an owner on the team.
Done when each agent has an owner on the team and the scoring runs without us.
Technical detail
The scoring runs on every change of prompt or model, and the score has to stay inside the accepted band.
Participation
Who from your team takes part
- A sponsor
- A product owner for the first product
- Domain specialists on the evaluation set
- An owner per data source
- Your engineers building alongside us
Measurement
How you know it worked
Measured in your own operation, before and after.
- Answers citing the source that supports them, over all answers
- Evaluation-set questions answered within the accepted band, at every change of prompt or model
- Regressions the scoring catches before they reach a user, and the ones that reach them
- Cost per completed task, tracked for each product
- Time for the second product to reach production, compared with the first
- Products running on the same core without copying an agent, a connection or an index
- Products still running after we leave, checked on the anniversary of the delivery
09After the handover
What keeps running without us.
The team keeps the standard and the core without us: the checks keep failing whatever departs from the standard, the scoring keeps rating every change, and each agent stays with an owner on the team.
10Questions
Common questions
Do you build the product for us?
We build with your team, in your repository and your cloud, and everything stays with them. We build the first application together; the team builds the second and we review it. On the core, your team starts the second product while we are still in the room.
Are we locked into one AI model?
The core's design records each choice and the reason for it. Changing models is a change like any other: it gets in when the automated scoring runs and the score stays inside the accepted band.
How do we know the agent's answer is right?
Every answer cites its source; without one, the agent says it did not find it. Before any architecture, we write real questions with your specialists, with the expected answer, and every change is scored against them.
Who from our team needs to be involved?
A technical owner who decides the standard, engineers who build the core with us, a product owner and specialists who write the evaluation questions. That team is who carries the work on after the handover.
11Other services
The other services we offer
12Contact
Tell us how the next product will be born
Tell us what you want to build and who will develop it. Giulliano Soares is who answers.
- Speak with the microphone on
- Type whenever you prefer
- The contact is recorded at the end
Where would you like to start?
Type, or tap Talk by voice.