Every article I've written until now was AI-generated. This one isn't. The same habit that let AI write my words let it quietly take over my code — until a production migration raised the stakes enough that I had to change how I worked with it.
The Pattern I Kept Repeating
I have been writing many articles and blog posts till now, but every single one of them was AI generated. But this is my first article that I just want to use my own words. The same problem with my coding. As the AI coding tools like opencode and Claude Code get stronger, I — like many other software engineers — use them in my daily tasks. The pattern was always the same: having a great idea, starting to vibe-code it with Claude, creating a codebase (~1,000 lines of Python code), then starting to feel overwhelmed by the details. What is function X doing? Why does this specific line of code exist? This was the point where I almost lost ownership of the system. Debugging code that you didn't write is difficult. From that point, all of my prompts started to look the same: asking Claude how to improve the system. That, you might also notice, is a vague prompt. It was the main reason why I abandoned repos when only 80% of the roadmap was marked as done.
A Bigger Project, A Bigger Penalty
This was a repeating pattern in almost every single one of my projects — until I got a new job at a new company, and this new project (an Odoo Enterprise migration) was really a big one, bigger than anything before it. As you might guess, it started like always: a great idea, a big architecture, and vibe-coding again. But this time was different, in the sense that losing ownership of the system could come with a real penalty: losing my job. I blamed myself for every prompt I fed to the AI, because I thought I was doing something wrong. I had 10,000 lines of Python code that was running seamlessly, without a problem — and I kept imagining the scene where we'd shipped the product, something failed badly in production, and I couldn't debug it because I hadn't written the code myself.
Asking "Why" Instead of "How"
So this time I approached the problem differently. From the beginning, I tried to ask Claude questions like these, instead of just asking it to fix or improve things:
Odoo's ORM does more than move data — every time a row changes, it also computes derived fields, runs validation, syncs related tables, and logs the change. Raw SQL copies the rows but skips all of that invisible logic. The database looks correct — the numbers are there — but the consistency the app depends on is quietly gone. It's like copying a spreadsheet's values without its formulas: fine until something needs to recalculate.
The fix wasn't "avoid SQL" — at 10,000+ rows, the ORM alone is too slow. It was: use SQL to move the data, then let the ORM finish the job it would've done automatically, so nothing gets skipped.
The constraint wasn't the problem — it was the messenger. A length limit built into Odoo itself was being violated by legitimate data. Dropping it seemed obvious, except Odoo recreates it from its own source code the next time it starts. Deleting it doesn't fix anything, just delays the failure a few seconds.
The real fix had to stop the bad data before it hit the rule, not fight the rule. A trigger — logic that runs automatically before a row saves — shrinks the oversized value at the moment of insertion, so the rule is never actually broken. Arguing with a rule you can't change gets you nowhere; making sure you never hand it something it'll reject does.
Ownership Isn't About Speed
I tried to ask challenging questions and tried to criticize the AI's decisions. I coded at a slower pace compared to previous projects. Every other day, I asked Claude to write a system report of my pipeline, and all I was doing was trying not to lose ownership of the system. At least I didn't blame myself this time just because I was using AI to code for me.
It's not that vibe-coding is wrong: when you have a coding assistant that writes 1,000 lines in just a few moments, that's definitely more efficient than coding without AI. But it's important to ask AI "why" and "how." That's how we can claim ownership of our code.
If you'd like to discuss this — reach me at navid72m@gmail.com.