This is not a story about weak agents. It is about a multi-agent harness that burned tokens and time before the product work did. I am keeping a series of AI adoption failures. This first piece stops at OpenCode.
Copilot felt like pairing
I have used AI as a developer for a long time. The first tool was GitHub Copilot. Visual Studio is my main IDE, so it arrived naturally. Early on it felt closer to pair programming than to vibe coding. The practical upside was how quickly new frontier models showed up. Even without picking models myself, Copilot was a window into them.
Why I still write dense prompts
Before the vibe-coding wave, I had already shipped an Android app through a no-code style loop. That showed me how far an agent-like workflow could go. A few short prompts were not enough. I had to spell out almost every development decision the way I would if I were coding myself. That is still my baseline for running agents. I do not write thin prompts.
Skipping Cursor for OpenCode
When vibe coding got loud, I switched tools. I skipped Cursor. It did not feel different enough from Visual Studio plus Copilot, and I did not want to lock into one large frontier stack. Instead of jumping straight to Claude or Codex, I chose OpenCode.
OpenCode fit. I could use recent patterns such as Claude-style skills, stay off a single-model leash, and try plugins and sub-agents freely.
I expected shared files to carry the context
In OpenCode, I set up sub-agents like a small development team. The PM handled planning and orchestration, the senior developer handled architecture, and the junior developer wrote code. I also added a designer and a reviewer. Each agent shared its output files with the others.
I expected those roles and documents to carry the PM’s plan through design, implementation, and review. Instead, the other agents often lost the context of that plan. Giving them access to the same output files did not keep the intent of the plan intact.
The reviewer also handed work off frequently. Those handoffs led to duplicate work, and once the flow became tangled, it kept repeating tasks without resolving the tangle. Dividing the roles left us spending more time redoing work instead of moving to the next stage.
I added rules and steps to reduce the repetition. That also gave the agents more procedure to follow. Alongside the product work, I was continually repairing the flow that was supposed to keep that work moving.
Cost arrived first
It still did not last. Cost stopped me.
A single agent had felt too thin, which was how I got into building the harness. Multi-agent token use was far higher than I expected. Repeating work after context was lost and repairing the handoffs kept consuming time and tokens. Even while I tried to cut the harness down, I felt I was spending more on that effort than on the product work. That is when I stopped.
This is a recollection of that work, not a controlled comparison of cost or the share of duplicate tasks. The failure I want to record is specific to the roles and shared-file workflow I built: I could not keep the plan’s context and the work’s continuity intact. It is not a verdict on OpenCode’s overall performance.
Tokens and time poured into the harness while the product work waited.
Looking back, that was my first clear AI adoption failure.
Why I moved to Codex
I dropped the overgrown harness and moved to Codex to start clean. I was already comfortable with GPT in open-source tooling, and Claude blocking OpenCode auth at the time also pushed me away. Codex felt like the open-source-adjacent path I wanted next.
The only judgment I want from this chapter is this: if the multi-agent harness becomes the product, you can lose to it before you ship your own. The next chapter picks up after the move to Codex.
