I Built an AI Development System for My Team

I opened the repository of a multi-tenant billing project we had been developing for months. I cloned it onto a new machine, installed the system, and typed \/run-task<\/code> without saying anything else.<\/p>

In two minutes, I had the complete map: Laravel 12 with multi-tenancy, Vue 3 on the front end, MySQL, Sanctum for auth. It detected the test commands, marked the tenant configuration folders as critical zones, and registered the Laravel MCP on its own. All before touching a line of code.<\/p>

I didn't explain anything. It read it on its own.<\/p>

That moment confirmed that what I had built in the previous months was worth it.<\/p>

By the end of the year, I realized something uncomfortable: I was spending more time correcting the AI than the time I saved using it.<\/p>

It wasn't a problem with the tool. It was a problem with how I was using it.<\/strong><\/p>

Every time I opened a project, Claude started from scratch. No context. Without knowing what stack we used, which folders not to touch, how to run the tests. I explained it. Implemented something. I reviewed it. Something was off. I corrected it. Explained again. The cycle repeated until the "saved" time no longer existed.<\/p>

In December and January, just when the AI agents' topic exploded, I decided that if I was going to keep using these tools seriously, I needed to build something better.<\/p>

Thus, the onMedia Dev System<\/strong> was born.<\/p>

The Real Problem<\/h2>

When you work with AI in development, there are three frictions that no one mentions much:<\/p>

The context is always lost.<\/strong> Each session starts from scratch. No matter how many times you've explained the project — next time, it knows nothing.<\/p>

Projects overlap.<\/strong> If you work on several projects at once, as is our case at onMedia, chaos grows. Which configuration applies to which? Can this colleague use the system without disrupting their flow?<\/p>

The AI implements and plans at the same time.<\/strong> That sounds good in theory. In practice, mixing roles creates inconsistency. If you ask it to think and execute simultaneously, it does both halfway.<\/p>

---

The Solution: Separate Roles<\/h2>

The central idea of the system is simple: Claude doesn't implement. It orchestrates.<\/strong><\/p>

There are two tools working together:<\/p>

• Claude Code<\/strong> — orchestrates, plans, and reviews. It's the brain.<\/p><\/li>

• OpenCode<\/strong> — implements the code. It's the hands.<\/p><\/li><\/ul>

  Claude decides what needs to be done and how. OpenCode executes it. Claude then reviews if it's correct. No one does two things at once.<\/p>

  This solved the quality problem almost immediately.<\/p>

  ---

  The Workflow in Practice<\/h2>

  When I start a new feature, I write \/run-task<\/code> in Claude Code. This triggers a five-step pipeline that runs on its own:<\/p>

  1. Check<\/strong> — verifies that the system is properly configured<\/p><\/li>

  2. Context<\/strong> — reads the project and builds the map (more on this below)<\/p><\/li>

  3. Plan<\/strong> — Claude plans what needs to be done, file by file<\/p><\/li>

  4. Implement<\/strong> — OpenCode executes the plan<\/p><\/li>

  5. Review<\/strong> — Claude reviews the result, runs the tests, approves or rejects<\/p><\/li><\/ol>

     At the end of step 5, the system hands off to me: "test this and tell me what you found." I test. If there's something to adjust, I write \/iterate "what I found"<\/code> and the cycle repeats without having to rebuild anything. When everything is fine, \/close<\/code> archives the plan and saves what was learned in memory.<\/p>

     Three commands. No ceremony.<\/p>

     ---

     Automatic Discovery<\/h2>

     This is the detail that changed my day-to-day the most.<\/p>

     The first time you run \/run-task<\/code> on a project, the system launches the Explorer — a sub-agent whose sole job is to understand the project from scratch, assuming nothing.<\/p>

     The Explorer opens the dependency files (composer.json<\/code>, package.json<\/code>, requirements.txt<\/code>, docker-compose), traverses the folder structure, detects the test commands, and with all that generates a .ai\/context.md<\/code> file that is committed to the repo.<\/p>

     That file is the source of truth. Stack with versions, routes, entry points, conventions, which folders are read-only. The next time someone opens that project — me, a colleague, tomorrow's session — the system already knows everything.<\/p>

     No need to explain anything ever again.<\/p>

     And if the project is Laravel, it installs and registers the Laravel MCP automatically, so Claude can consult models, routes, and schema in real-time without me doing anything.<\/p>

     ---

     Multi-Project Without Conflict<\/h2>

     We work with over 100 clients. Having an AI system that gets confused between projects is not an option.<\/p>

     The solution was simple: each project has its own context in a .ai\/<\/code> folder within the repository. The system lives there, isolated. It knows nothing about the other projects and doesn't interfere with them.<\/p>

     Moreover — and this was important to share with colleagues — the system does nothing until you activate it.<\/strong> There's no invasive configuration that takes control of Claude Code from the start. It sleeps in the project until you write \/run-task<\/code>. This means a colleague can have the system installed without changing anything in their usual flow, and activate it when they want to try it.<\/p>

     ---

     The Memory<\/h2>

     There's one more detail I find valuable to mention.<\/p>

     The system has persistent global memory. An SQLite database that lives on your machine and is shared among all projects. Every time \/close<\/code> archives a plan, it saves what was learned: errors that appeared, decisions made, patterns that worked.<\/p>

     The next time you start a similar project, the system already has that base. It never starts from scratch again.<\/p>

     <\/p>

     <\/p>

     What Changed<\/h2>

     It wasn't the speed of code writing. That improved, yes, but it's not the main change.<\/p>

     What changed is that I stopped being the interpreter between the project and the AI. Before, I was the one who knew the context and had to convey it in each session. Now the system knows it. I just direct.<\/p>

     The problem I had in December — more time correcting than saving — disappeared. Not because the AI is better, but because the system surrounding it is smarter.<\/p>

     ---

     If you work with Claude Code or are thinking of starting to use it seriously for development, the system is available for installation. In the coming days, I will share how to install it step by step.<\/p>

     Do you use AI in your development flow? What is the friction that is hardest for you to resolve?<\/p>