Measuring AI's Impact on a Growing Odoo Team

Over the rollout period, the AI-assisted part of the team grew from 3 to 12 engineers. Against that, my own measurements across the same window:

Metric	Change	How it was measured
Delivery speed	+35–55%	Cycle time per comparable ticket, before vs after adoption, on similar Odoo module work
Code review	~4× faster	Average time actually spent reviewing a PR — review effort, not queue or wait time — before vs after CodeRabbit’s first pass
AI-assisted headcount	3 → 12	Engineers working inside the Claude Code + CodeRabbit workflow

These are personal measurements over a real rollout, not an audited study — cycle time on ERP work is noisy, and I normalise against comparable tickets rather than claiming a controlled experiment. But the direction and the size of the move are consistent enough to act on.

There is a confounder I won’t hide. This team was built from scratch over the same window: the founding three were at different levels, and the group grew to twelve. Some of the delivery gain is a team maturing, not a tool — the two are entangled in that number. That is exactly why I trust the review figure more than the delivery one: the review change tracks a mechanical first pass I can point to directly, while the delivery figure carries people getting better at their jobs alongside whatever the tooling did.

The interesting part is not the numbers. It is why they held — because the naive version of this does not.

---

The trap: raw velocity

The default story of AI adoption is “the model writes code, so we ship faster.” Taken literally, that is a trap. An assistant accelerates whatever surface you point it at. Point it at an 11k-line Odoo god-class with business logic welded into _inherit, and you get framework-coupled, untestable code — faster. That is not delivery speed. That is faster tech debt, and it shows up two migrations later.

So the speedup was never treated as a property of the tool. It was treated as a property of the structure the tool operates inside — and that claim is not specific to Odoo. Swap in any framework with a god-class and a review queue and the shape holds; Odoo is only where I measured it. Two structural bets did the actual work.

---

Bet 1 — a boundary the AI can operate on

Business logic that matters — payroll, VAT, depreciation — is isolated from the framework behind a clean boundary (a hexagonal / ports-and-adapters split). The dependency direction points inward, toward the domain: Odoo depends on the domain, never the reverse.

This is not architecture for its own sake, and it is not applied everywhere — plain CRUD stays in Odoo, where isolating nothing would just buy ceremony. The point is narrower and it is what makes the metrics real:

• An assistant working on a pure, framework-free domain unit produces code you can actually unit-test at Python speed — no Odoo boot to check a formula. And testable output tends to be reviewable output: the isolation that lets you assert on a formula is the same isolation that lets a human, or a bot, reason about it. That is a strong correlation, not an identity — but it is the one you want on your side.
• The same assistant pointed at a god-class produces plausible code that no one can verify cheaply. Unverifiable output does not accelerate anything; it defers the cost.

The architecture is what gives AI a surface where speed and correctness are not in tension.

---

Bet 2 — gates velocity cannot outrun

The “4× faster review” number is the one people misread. It is faster review, not skipped review — and it is measured review effort, the average time a reviewer actually spends on a PR, not wait time in a queue. CodeRabbit plus a defined review standard runs a first pass on every PR — security-shaped checks for Odoo (CSRF/SSRF, safe_eval, ACL), naming, obvious defects — before a human looks. By the time a human arrives, the mechanical pass is already done; what’s left is judgment. That is where the 4× comes from: not fewer eyes, but each pair of eyes spending its time on what only a human can weigh.

Without that gate, AI velocity produces more PRs than a growing team can review well, and review becomes the bottleneck — or worse, review quality quietly drops to keep up. The gate is what lets throughput and the quality bar move together instead of trading off.

---

What we deliberately did not do

Let it rip — AI without gates. The fastest way to more commits and slower systems. Rejected: the whole point was measurable delivery, which includes the code still being sound after the next migration.

Hexagonalise everything. A valid pattern, rejected on economics. The cost of isolation has to match the value of the code isolated; on reference tables and CRUD it does not. Scope was kept to calculation-dense, high-value logic.

Methodology alone. Spec discipline is necessary but not sufficient — a clean process still points the assistant at a god-class if the architecture underneath is fused. Process gives you what to build; the boundary gives the AI a surface it can build on safely.

---

What it buys

• Speed that survives migrations, because the accelerated code lives behind a boundary instead of inside the framework that keeps changing.
• Review that scales with headcount, because the mechanical pass is automated and humans review judgment.
• A faster path to productivity for new engineers — a clean domain surface plus an automated first-pass reviewer is a far gentler on-ramp than a god-class and a queue of manual reviews.

---

Tradeoffs I accept

• The measurement is mine and imperfect. Cycle time on ERP work is noisy; I trust the direction and magnitude, not a decimal place. I would rather publish an honest range than a false precision.
• The boundary has a maintenance cost — a mapper between domain and framework is a real artifact to keep, justified only where the logic behind it is valuable enough to protect.
• The gate adds latency — an automated review pass is not free on every PR. It is worth it precisely because it moves the human review earlier and lighter, not because it is invisible.

The headline is that AI moved the numbers. The part worth keeping is that it only moved them because the speed was put somewhere it could be trusted.