Writing code has become much faster. The cost of a mistake has not changed. That is why the real shift of the last few years is not that AI writes for us, but that checking, testing and controlling now take significantly more effort. Below is how I work with AI on Odoo projects, and why 100% test coverage of customisations stopped being a nice-to-have and became a condition of the work.
What actually changed
The bottleneck used to be writing the code: a developer wrote slowly, then quickly checked something they had just thought through themselves. Now it is the other way round — code appears faster than a human can absorb it. The centre of gravity has moved from writing to verification.
This is not an argument against AI. It is an argument for changing the process: a tool that speeds up one part of the work tenfold automatically turns every other part into the bottleneck.
The main risk: you fix one thing and break another
The most unpleasant property of working with AI in automatic mode is how readily it edits the surrounding code. You ask for a change in one calculation — and along with it, “just in case”, the signature of the calling method is adjusted, the dependency of a computed field changes, and a check that looked redundant quietly disappears.
In an ordinary application you notice immediately. In Odoo you do not, because the consequence is usually not an error but a quietly wrong number: the wrong cost of goods, the wrong tax, the wrong stock balance. Nothing crashes and nothing complains — it simply accumulates until the period close.
The second typical scenario is architectural drift: every iteration is locally sensible, and twenty iterations later the project has three different ways of doing the same thing, none of them documented.
Tests: 100% coverage of customisations
This is the requirement that changed the most. You used to be able to live with tests on the “critical parts”. Now, when code is edited quickly and partly automatically, all custom logic has to be covered by tests — because a test is the thing that records the intent: this is how the system must behave, and any change that breaks it must fail immediately.
What always gets covered on an Odoo project:
- computed fields and their dependencies — the most common source of silent errors and the first thing AI tends to “optimise”;
- accounting logic: journal entries, cost of goods, taxes, payment reconciliation — where a mistake is most expensive;
- document state transitions — confirmation, cancellation, returns;
- parsing of external API responses — against stored sample payloads, with no network calls, so the tests stay fast and stable;
- edge cases: zero, negative values, a different currency, an empty response, a repeated call;
- access rights — the thing nobody checks manually until something unpleasant happens.
A practical detail: a test should verify the business outcome, not that a method was called. “After confirming the order there are three fewer units in stock and a cost-of-goods entry exists” is a useful test. “_compute was called once” is not.
The working cycle: decision → test → code → review
The order matters more than the tool. The same AI produces the opposite result depending on which step it is plugged into.
- A human makes the architectural decision. Where this lives, how it fits Odoo’s mechanics, what happens on upgrade. Before the code, not after.
- Test first, code second. The test describes the expected behaviour in business language and doubles as the specification for generation.
- Generating the code. This is where AI saves the most time — and that is fine.
- Review by someone who knows Odoo. Not “does it work” but “is this how it should be built”.
- Running the whole test suite, not just the new tests. That is what catches the broken neighbour.
Drop step 2 and step 5 turns into guesswork. Drop step 1 and you get the same architectural drift, only faster.
What AI does well and badly in Odoo specifically
Well: routine models and views, migration scripts, parsing response formats, tests written from a description of the behaviour, refactoring against a clear instruction, documentation for code that already exists.
Badly: anything requiring knowledge of the consequences. Computed field dependencies and their effect on performance, the order of operations in accounting, interaction with standard modules, multi-company and access rights. Here the generated version often looks right and is not.
Separately: AI tends to write its “own” logic instead of using the built-in Odoo mechanism. Formally it works, and then it does not survive an upgrade, does not appear in standard reports, and breaks on the first non-typical operation.
What to look for in generated code
- whether another method has appeared that does what an existing one already did;
- whether the ORM is bypassed where staying inside the framework was possible;
- whether computed field dependencies changed “in passing”;
- whether fields and models were added that nobody needs — tomorrow that is dead code;
- whether checks that looked redundant have disappeared;
- whether it will be clear in six months why this was written at all.
The simplest filter: if the developer cannot explain a fragment in their own words, that fragment is not yet part of the project, however neatly it sits in the repository.
Regressions: why this does not work without CI
Tests only pay off if they run automatically. The minimum working set: the full suite on every change, a separate staging database with a copy of real data, and a ban on deploying to production with failing tests. This needs no complex infrastructure — on Odoo.sh it is built in, and on your own server it is a one-off setup.
What this means if you are the client
Three practical conclusions if you are commissioning development:
- Faster does not mean cheaper overall. Savings at the writing stage are easily eaten by months of untangling the consequences.
- Tests are not an optional extra. “Are the customisations covered by tests?” is now a more important question than “how many hours will it take?”.
- AI does not replace qualification. It amplifies it — in both directions. A good developer with AI works faster; a weak one produces faster what will later have to be rewritten.
How to check this in a potential contractor is covered separately: how to choose an Odoo implementation partner. And if the code already exists and nobody knows what is in it — a technical audit of the project.
Frequently asked questions
Do you use AI on client projects?
Yes, as an accelerator. The architectural decisions and the review stay with me, and the custom logic is covered by tests.
Does that make development cheaper?
Partly — the routine really is faster. But part of the time saved moves into testing and control, and that is the right trade.
Why 100% coverage when selective coverage used to be enough?
Code used to change in small pieces and by a human. Now changes are often wider than expected, and only the full suite shows what was affected elsewhere.
Can an existing project be covered with tests?
Yes, and it usually starts with the accounting logic and the integrations — where a mistake costs most. Full coverage is then built up in stages.
How much time do tests take?
Noticeably less than it seems — and many times less than hunting down an accounting discrepancy three months after release.
Programming with AI: Why Tests Now Matter More Than Speed