Guide

AI for Odoo development: a practical guide

AI agents can write a working Odoo module in minutes, or a plausible one that never installs. The difference is the context you give them and the checks you run afterwards.

Download Assista IDECompare AI tools for Odoo
Updated . Applies to any AI coding tool; Assista-specific tips are marked.

Why Odoo is harder for AI than plain Python

A general model has read a lot of Python, and some Odoo. What it has not read is your project. An Odoo module is spread across Python models, XML views, a security CSV, a manifest and data files, and a field defined in one addon may be extended by three others. A model that only sees the file you have open will guess at the rest: a field that does not exist, a view inheriting from the wrong parent, a model with no access rule. The code looks right and fails at install.

Odoo also changes between major versions. View syntax, ORM APIs and conventions that were correct on Odoo 16 can be wrong on Odoo 18. An AI tool helps with Odoo as far as it knows which version you are on and can see what your project already contains. This guide covers three steps: a project the agent can run, prompts with Odoo context, and a review routine.

1. Set up a project the agent can run

An agent that can start Odoo, install a module and read the log can check its own work. That needs a working development environment: Git, the right Python version for your Odoo version, PostgreSQL, Odoo's system libraries, and Node.js with the LESS compiler for stylesheets. PDF reports also need wkhtmltopdf.

Python versions per Odoo version (from the Assista IDE prerequisites)
OdooPython
20.03.12, 3.13, 3.14
19.03.10, 3.12, 3.13
18.03.10, 3.12
17.03.10, 3.12
16.03.8, 3.10, 3.12
15.03.8, 3.10, 3.12
14.03.8, 3.10

Use a dedicated development database, never a copy of production with real customer data, and a PostgreSQL user that is allowed to create databases. Keep your custom addons in their own folder on the addons_path, separate from Odoo's source, so the agent can tell your code from the framework's.

With Assista: pick an Odoo version from Odoo 11 to 20 and a folder, and Assista IDE downloads Odoo, creates a virtual environment with the packages that version needs, and adds a debug configuration. It shows the PostgreSQL and system-library commands for your operating system. See the prerequisites and the one-click environments feature.

2. Give the agent Odoo context

Most poor AI output for Odoo traces back to a prompt that left out something only you knew. Name these, every time:

  • The Odoo version, and Community or Enterprise. "Odoo 18 Community" changes the answer.
  • The model and the module. "Add a field to sale.order in my module sale_margin_extra", not "add a margin field".
  • What already exists. Attach the model file, the view you want to extend and the manifest, or ask the agent to read them first.
  • The whole change. A new model needs a model file, an import, views, a menu or action, and an access rule. Ask for all of it, and for the manifest and __init__.py updates.
  • Constraints. "Do not modify core modules", "inherit, do not override", "keep it compatible with the existing data".

A prompt that works well looks like this:

Odoo 18 Community. In my module sale_margin_extra, add a computed,
stored field margin_percent to sale.order: (margin / amount_untaxed) * 100,
0 when amount_untaxed is 0. Show it after the margin field in the sale
order form view. Update __init__.py and the manifest if needed, and add
a test that checks the computation.

Ask the agent to plan before it edits when the change spans several files, and read the plan. Catching a wrong inheritance in a plan is cheaper than in a diff.

With Assista: Assista Coder does part of this lookup itself. It lists a model's fields and methods as they are across every addon in your workspace, finds the views, access rights, record rules and reports that touch a model, and can read the status of the Odoo server you started. You can attach files, folders or a selection to the message, and use Chat mode to plan without edits before switching to Agent mode. See Assista Coder.

3. Review what it writes

Treat AI output like a pull request from a new colleague who is fast and confident and has never seen your database. Read the diff, then let tools check what reading misses.

A review checklist

  • Every new model has a line in ir.model.access.csv, and the file is listed in the manifest's data.
  • Every file under data, views and security is listed in __manifest__.py, in an order where references resolve.
  • New Python files are imported in the right __init__.py.
  • Inherited views use an xpath that matches the parent view on your Odoo version.
  • Relational fields name their comodel; computed fields declare @api.depends.
  • View syntax matches the version: no attrs or states on Odoo 17 and later, <list> rather than <tree> on Odoo 18 and later.
  • The module installs and upgrades on a fresh database, and its tests pass.

Lint with pylint-odoo

The OCA's pylint-odoo plugin checks Odoo-specific mistakes, from manifest keys to SQL injection risks:

pip install pylint-odoo
pylint --load-plugins=pylint_odoo -d all -e odoolint path/to/your_module

Install it and run its tests

An install on a fresh database catches missing access rules, broken XML ids and manifest order problems that no linter sees:

./odoo-bin -c odoo.conf -d test_db -i your_module \
  --test-enable --test-tags /your_module --stop-after-init

Then upgrade it once (-u your_module) on a database where it is already installed, to check the change is safe for existing data.

With Assista: the Module Reviewer runs XML validation, a security audit, pylint, an install test, unit tests and a click-through of the module's screens on your machine, and gives you a report. It uses no AI tokens. Assista Coder can also run the tests your IDE knows and report each result.

Mistakes AI tools make most often in Odoo

These come up again and again, whatever the tool. Knowing them makes a review faster, and naming them in a prompt ("add the access rule", "check the xpath against the parent view") prevents most of them.

Overriding instead of inheriting

Asked to change a standard model, a model may redefine it or copy a whole method. In Odoo you extend: _inherit the model, override the method, call super(), and keep your change small. The same goes for views: inherit and use an xpath, never copy the parent view into your module.

Fields and methods that do not exist

A model that has not read your addons will invent plausible field names, or use ones from another version. Ask the agent to list the model's fields first, or attach the files that define them, and check every field it references in the diff.

Security left for later

A new model with no access rule installs with a warning and is unusable for normal users. Record rules for multi-company data are easy to forget. Ask for ir.model.access.csv lines in the same change, and decide yourself which groups get which rights.

Too much in one request

"Build a fleet maintenance module" produces a large diff that is hard to review. Ask for the models first, install and check them, then the views, then the reports. Each step is small enough to read properly, and a failure points at one change.

Raw SQL and sudo

Generated code sometimes reaches for self.env.cr.execute or sudo() to make something work. Both bypass the ORM's access checks. Ask why it is needed, prefer the ORM, and when SQL is unavoidable, use parameters rather than string formatting.

4. Version upgrades need extra care

Migrating a module between major versions is where AI help is most tempting and most risky. The model may mix syntax from two versions. Some changes worth checking by hand:

  • Odoo 17 replaced the attrs and states view attributes with direct expressions such as invisible="state != 'draft'".
  • Odoo 18 list views use <list> instead of <tree>.
  • Odoo 19 ignores _sql_constraints; constraints are declared another way.

Read the official upgrade notes for each version you cross, migrate one module at a time, and run the install and test commands above on the target version. A clean run from an AI checker does not prove a module is safe to migrate.

With Assista: Assista Coder can check an Odoo 18 module for Odoo 19, looking for known renamed or removed fields and for _sql_constraints. Treat an empty result as a starting point, not a guarantee.

5. Keep data and secrets out of prompts

Whatever tool you use, your prompt and the code it needs are sent to an AI model provider. Do not paste production data, customer records or credentials into a prompt. Run agent shell commands against a development database only: an Odoo shell can write to the database as easily as read it.

Where to go next

Sources

Checked . Products change; follow the links for the current details.