The O9X app has been live since March 2026. Development started in November 2025. Around 20 members of my team now use it daily across business operations.
I felt an overwhelming sense of satisfaction that I had actually built a working app using AI, despite my limited coding knowledge. I had spent long hours debating with AI, reading blog posts, and watching videos on how to build a production-ready app with AI. After some initial hesitation, my staff slowly started appreciating the benefits.
Soon they started sharing feedback, improvements, and bugs. I spent one to two hours daily adding new features and fixing issues. A system slowly came into place, and it made me confident. The kind where I felt entitled to share my opinions on what works and what does not.
Around a week ago, I came across a blog post by Cloudflare. They shared their new process to review code changes using AI. It was part of their Code Orange: Fail Small project.
Cloudflare is a behemoth with battle-hardened engineers and a strong engineering culture. I use Cloudflare myself to host my app. Reading the post made me more aware of what it actually takes to run a production-ready app regularly.
Despite their peer review process, engineering discipline, and experience, they still had failures that resulted in outages. So they built an AI code review system to catch what their existing process might miss. I did not come to some sudden realisation, but a small idea was planted.
The next day, I was transferring some old notebook entries to Obsidian. I came across two notes. One was from Philip Tetlock’s research on prediction, and the other was from Annie Duke’s Thinking in Bets.
Tetlock’s research explains why real experts express uncertainty in their predictions. The more they know, the more clearly they see how many things can go wrong. A novice is often more confident because he views everything through a single lens.
One of the core arguments of Thinking in Bets is simple: never judge the quality of a decision by its outcome. Luck plays a big role in outcomes. So we are never fully clear whether the result came from a good process, superior skill, or luck.
My app was working with limited issues. Every new feature or change I made was reviewed by AI in a separate session. AI did flag multiple issues, which I fixed.
My staff shared their feedback for improvements and bugs, and they were fixed or incorporated into the app. But none of this made the real quality of my app’s codebase clear. I was judging the quality of the codebase on one simple observation: it was working without obvious issues.
Running proves something. It just proves less than I was treating it as proof of.
Enough articles, videos, and opinions have now been shared on how non-engineers can code with the help of AI. I consumed a lot of that material and built my own process to develop O9X. The process looked sound from the outside.
I would think about the problem, gather the necessary information, make a proper plan with AI assistance, and create a clear document for Claude Code or Codex to build from. Once the work was done, I would start another session to review it. Then I would fix the bugs it found, test the feature myself, fix anything else I noticed, logged it and push my code for deployment. .
I followed this process almost daily. Soon, a functional app was ready. It had flaws and edge cases, but I kept fixing them through the same process.
The issue I realised is that every change AI makes today might break a feature I built a month ago. Forget AI, even I cannot recall a decision I made last week. AI and I both review the current change, but neither of us naturally remembers the full chain of old decisions.
That slowly accumulates. Old assumptions remain inside the codebase. A schema decision from month one can create a quiet problem in month five.
I am not a software engineer who has spent years building and maintaining production systems. AI is a great tool to build something now. But maintaining the system is my responsibility, not AI’s.
So over the last two weeks, I have stopped adding features. Instead, I have moved into an audit phase. That transition was not easy.
I rarely audit anything that shows no signs of breakage. I live under the assumption that no news is good news. But working now and fragile underneath are not mutually exclusive.
Inspired by the Cloudflare post, I am building my own AI audit system. I am undertaking a complete documentation-first audit across every domain of the codebase. I do not yet know whether it will surface real fragility.
That is the honest answer. This is not a solution. It is a bet on method.
For now, the only thing that matters is that I caught myself being confident about something I had insufficient basis to be confident about. That is not a small thing to notice.