Don't Let Your AI Agent Break Odoo

AI agents write Odoo modules now — and break things with confidence

AI coding agents are genuinely useful for Odoo development: they scaffold modules, extend models, write views and tests. But every experienced Odoo developer has seen the other side: the agent confidently edits an inherited model, removes a field or reshapes a view — and something breaks two modules away, in code the agent never opened.

This is not a prompt-engineering problem. It is structural.

An Odoo codebase is a graph, not a tree

Odoo's power comes from its inheritance machinery, and that same machinery is what makes it opaque to an AI agent:

• _inherit and _inherits delegation extend models across module boundaries
• view inheritance via XPath patches views defined in other modules
• manifest depends chains pull in modules you never look at
• computed fields with @api.depends create invisible data dependencies
• OCA and community addons hook into all of the above

The result: dependencies span modules you never opened. No context window holds the whole graph, and grep does not find indirect links. When an agent edits an inherited model or removes a field, it cannot see the blast radius — which views break, which overrides stop working, which downstream modules silently misbehave.

And because the code changes every minute the agent works, a one-shot analysis is stale almost immediately.

The fix: a live dependency graph, served to the agent over MCP

Continuous dependency analysis turns the codebase into a queryable dependency graph that stays fresh as the code changes. The graph is exposed to the coding agent over the Model Context Protocol (MCP), so before each edit the agent can ask structural questions:

• What calls this method — and what overrides it?
• Which views inherit this view?
• What breaks if I change this field?
• What is the impact of this migration step (say, Odoo 19 → 20)?

A concrete example: an agent is asked to remove a field that a dozen modules depend on. Blind, it deletes the field and the damage surfaces at runtime. Graph-aware, it queries the change impact first, sees the dependent views and computed fields, and either adapts them all — or tells you why the change is riskier than it looks. The graph stops the mistake before the edit, not after the crash.

Works with the agent you already use

The pattern is agent-agnostic: the same MCP interface works with Claude Code, Codex and Gemini CLI. There is no vendor lock-in — you ground whichever agent your team uses in the real, current architecture of your Odoo instance and its addons.

Honest about the limits

Static analysis of a dynamic framework is approximate. Dynamic dispatch and runtime inheritance order are estimated, not proven. But surfacing 90% of the blast radius before an edit beats a clean crash after it.

We use this ourselves

Softagram runs its own operations on Odoo, and we develop our own modules exactly this way: Softagram Analyzer builds the dependency graph, an MCP server serves it to our coding agents, and re-analysis keeps it fresh as the code changes. This page describes our daily workflow, not a concept.