Vibe coding: evolve your ERP by describing it, not by coding it
You describe what you want to obtain; the platform builds the field, the view, the rule or the automation, deploys it to a test environment and waits for your validation before production. Changing your system no longer requires knowing how to code, nor waiting for a developer to free up.
The hidden cost of an ERP is not its price: it is the delay
Adding a field, changing a calculation rule, editing a printed document: on a conventional ERP, each of these requests becomes a ticket, then a quote, then a queue. Six weeks later the need has moved on — and the company has already worked around the problem with a spreadsheet.
That delay is what vibe coding removes. Not the development — the delay. You describe the need, the platform builds it, your teams validate it in acceptance, and it goes live the same evening if you decide so.
Six things to know before you start
Select a point to expand it.
What you can do yourself
Most of what blocks day-to-day work is configuration, not heavy development.
- Add a field and display it where you want
- Change a list, form or kanban view
- Create a calculation or control rule
- Automate a send-out, a reminder, an alert
- Adapt a printed document or a template e-mail
- Create a dashboard or an indicator
Acceptance is never optional
This is what separates vibe coding from a code generator: nothing reaches production without passing through a test environment and being validated by a human.
- Built on an isolated branch
- Automatically deployed to acceptance, on your data
- Explicit validation by your teams
- Release blocked until validated
- Backup taken immediately before deployment
- Rollback armed by default
The code produced stays yours
Vibe coding does not create a black box. What is built is standard Odoo code — readable, versioned and exportable.
- Standard Odoo code, not a proprietary format
- Versioned and historised
- Exportable on demand
- Readable by any Odoo developer
- Compatible with version upgrades
- No dependency created on purpose
What it changes on the calendar
The gain is not measured in development hours saved, but in weeks of waiting removed.
- No specification document for a field
- No quote to approve for a minor change
- No queue behind other customers
- Acceptance available the same day
- Release when you decide
- The need is handled while it is still current
When you still need a developer
Being honest about the limits is what makes the tool usable with confidence.
- An integration with an external system not covered
- A genuinely complex business algorithm
- A massive, heterogeneous data migration
- An end-to-end functional redesign
- A module intended for distribution
- In those cases: our teams take over
Who is allowed to do what
Opening system changes to non-technical users requires a framework, otherwise disorder is guaranteed.
- Request, validation and release rights kept separate
- Full history: who asked, who validated, when
- Editable scope restricted if you wish
- Alerts on sensitive changes
- Periodic review of accumulated customisation
- Clean-up of what is no longer used
From sentence to production
You describe
In plain language, as you would explain it to a colleague. The platform asks the clarifying questions it needs.
The platform proposes
An explicit plan: what will be created, what will be changed, and what it touches. You see the impact before anything runs.
Acceptance on your data
The change is built, then deployed to a test environment with your real data.
You validate, it ships
Release after your approval, backup taken immediately before, rollback available.
What it replaces in practice
| Common request | On a conventional ERP | With vibe coding |
|---|---|---|
| Adding a field to a customer record | Ticket, quote, scheduling, several weeks | Described, built, tested, validated — within the day |
| Changing a calculation rule | Billable developer intervention | Described in one sentence, tested in acceptance |
| Editing a printed document | Back and forth with the provider | Immediate preview, adjusted live |
| Automating a reminder | An automation project to scope | Rule described, trigger chosen, tested |
| Fixing a configuration mistake | A new ticket, a new wait | Immediate rollback, fix afterwards |
| Knowing what changed and who changed it | Often untraceable | Full history, requester and approver tracked |
Vibe coding does not replace our teams: it frees them from low-value requests so they can concentrate on the ones that matter. For genuinely specific development, see Custom Odoo modules; for a complete business application, Business applications.
Three guarantees you can verify
No unvalidated release
Release to production is technically blocked until acceptance has been approved by an identified human.
Rollback armed
A backup is taken immediately before each deployment, and the previous state can be restored within minutes.
Exportable code
What is built is standard Odoo code — versioned, readable and exportable on demand. No dependency is created.
Vibe coding: your questions
Do I need to know how to code to use vibe coding?
No. You describe the expected result in plain language, as you would explain it to a colleague. The platform asks the clarifying questions it needs and proposes a plan before building anything.
Can it break my production?
No, by construction: nothing is deployed to production without passing through a test environment and being explicitly validated. A backup is taken immediately before the deployment and rollback remains available.
Who owns the code produced?
You do. It is standard Odoo code, versioned and exportable on demand. It is not a proprietary format and any Odoo developer can read it.
Is it compatible with Odoo version upgrades?
Yes. The code produced follows Odoo development standards, which is precisely the condition for an upgrade not to turn into a rewrite project.
Who can request a change?
You decide. Request, validation and release rights are separate, and the editable scope can be restricted. The history keeps who asked and who validated.
What happens if the request is too complex?
The platform says so rather than producing something approximate. An external integration, a complex business algorithm or an end-to-end redesign are handled by our teams.
How many changes can I request?
There is no counter. That is the principle of the Karizma One subscription: no per-ticket billing, no volume cap.
How do we avoid the system becoming a pile of customisation?
Through periodic review. What has been added is historised and measurable, which makes it possible to clean up what is no longer used — an exercise that is impossible when customisation is scattered across several providers.