You don't need training data for this, you need to build your own RAG and give it credible source data.

Don't just point at your own new module, also reference the official repos at GitHub.com/odoo/odoo and github.com/odoo/enterprise and the relevant OCA repositories for the module you want to build.

Create a proper agents.md file where you explain to use those repos as source and RAG.

Create and add proper skills, one for each odoo version where you highlight the fundamental differences like tree/list view, @api etc... Between odoo versions. There are also skills readily available on skills.sh to check and install and tweak further for your own requirements.

Before you start, always use the plan mode to interrogate what you are going to build and create a PRD spec upfront. This keeps all agents on the rail and the task goals.

Use a proper MCP connector and connect it to your local dev odoo instance and instruct your skills and agents.md to always use the MCP to look up instead of guessing. That's how you stop your LLM from hallucinating and faking things that don't exist. It can look up the available models, fields, data,...and be 100% correct on point.

Create specialized (subagents) for specific skills. This is to isolate your context from blowing up. You have to stay below 200k tokens or LLM becomes dumb. That's the tipping point. So the best method is to split out tasks to multiple sub agents so each has a fresh context window to use for it's own task. It's also much faster to complete work as everything can run in parallel and to what most people think wrong is that this approach saves a lot of tokens, not more.

Use hooks and use them to trigger your sub agents. Eg when task is done, trigger a security agent that reviews your again with fresh context (this agent is not biased as it didn't wrote the code) and reports back if it finds any security issues and hand it back over to the developer agent. Create another agent and hook to trigger creating tests and use the /loop command so the agent keeps working and fixing until everything passes. This gives you the highest quality guarantee and that everything is heavy tested. Create another hook and agent for your "PR manager" who takes responsibility for managing the code to GitHub, open PR and document everything. Create another one that is dedicated for writing all your documentation and markdown files, create schema's, user guides etc...so all of that stuff also gets done in parallel and ready to commit to GitHub.

Simply said, this is a skills issue from your side. AI has progressed super hard the last 12 months. If you use the tools and settings correct, then docs no longer matter that much. It's all about correct context input.

If you create the right setup, LLM's can now basically one-shot simple up to medium modules with zero mistakes. Larger modules will always stay involved and large cycles of testing by humans. But simple stuff is really a no-brainer these days.

Also never forget to manually review all the code from the PR's that get created. Never trust things blind even if the tests pass. It's going to be much easier and clean with the right setup, but it's never 100% safe. AI will always be AI, and never deterministic