Open Code Practical Guide: Building an AI Coding Team with Multi-Agent Systems

From Skepticism to Fully Embracing AI Coding

Eleven months ago, Anthropic CEO Dario predicted that "within three to six months, AI will write 90% of developers' code." At the time, many people thought it was unrealistic—including the author of this article, a seasoned engineer. Back then, he refused to let AI write his code at all, using it only for auxiliary tasks at most.

But today, he not only has a group of AI coding agents handling complex tasks, but has integrated them—along with skill systems, sub-agents, and various configuration options—into Open Code. This open-source project with over 100,000 stars has become a benchmark in the AI coding agent space.

What is an AI Coding Agent? An AI Coding Agent is an autonomous software development system built on large language models (LLMs) that can understand natural language requirements, generate code, execute tests, and iteratively fix issues. Unlike early code completion tools (such as the initial version of GitHub Copilot), agent systems have "tool calling" capabilities—they can proactively read and write files, execute terminal commands, and call external APIs, forming a complete perception-decision-execution loop. Behind this capability leap are breakthroughs in function calling and context window expansion from models like GPT-4 and Claude 3. It's precisely this paradigm shift from "passive completion" to "active execution" that has turned Dario's prediction from fantasy into something increasingly resembling reality.

What is Open Code: From Side Project to Open Source Benchmark

Open Code was originally called Terminal AI Agent, created by a developer in their spare time. Later, well-known developers Dex and Adam joined, and they even secured the opencode domain. Charm, a terminal open-source tools company, became interested in the project and wanted to hire all three.

The key turning point: Dex and Adam rejected Charm's offer. They wanted Open Code to remain open source, free from the commercialization pressure that VC funding would bring. They ultimately rewrote Open Code from scratch, while Charm's version was later renamed to Crush.

This decision reflects a deeper tension in the current AI tools landscape: VC capital pursues monetization, while the developer community values tool neutrality and sustainability. Similar tensions have appeared in the history of frontend tools like Prettier and ESLint—once core tools are fully controlled by commercial companies, the community faces the risk of being "locked in." Open Code's ultimate choice to join Anomaly, a "startup studio" model rather than a traditional VC path, represents a compromise seeking balance between funding support and community control.

Today, Open Code belongs to Anomaly (which includes projects like SSD and OpenTof), backed by Y Combinator and PayPal co-founder Max Levchin. While there is VC funding involved, the developers retain more control.

Core Architecture: How the Main Agent and Sub-Agents Collaborate

Dual-Layer Agent System Explained

Open Code's multi-agent system is divided into two layers: the main agent and sub-agents.

Main agents include:

• Plan (Planning Agent): Read-only and planning-only, responsible for overall solution design—even if you ask it to execute, it won't
• Builder (Building Agent): Responsible for actual code writing and execution

Sub-agents are modules dedicated to handling specific tasks, callable at any time and running in the background. Open Code comes with two general-purpose sub-agents: one that can perform operations, and one (Explore) primarily responsible for code reading and exploration.

This layered design has theoretical grounding in software engineering. Separating "planning" from "execution" is similar to the classic Command Query Responsibility Segregation (CQRS) pattern—the read-only Plan agent won't accidentally modify the codebase, reducing the risk of irreversible errors. The specialization of sub-agents corresponds to the Single Responsibility Principle: the clearer the task boundaries, the lower the probability of model hallucination, since it doesn't need to frequently switch between multiple cognitive domains.

Practical Configuration for Custom Sub-Agents

Running opencode agent create launches an interactive wizard that lets you describe the agent's responsibilities, set permission scopes, and then automatically generates a complete definition file. The generated file contains configuration items including instructions, plans, examples, principles, and context specifications.

But be clear-eyed about this: it's essentially prompt injection, and quality depends entirely on how you write your prompts. Beyond permission restrictions, nothing can absolutely prevent it from going off-track—bypassing rules does happen.

So why use sub-agents at all? Two core reasons:

1. Division of labor reduces hallucinations: The more specific the task, the fewer mistakes the model makes
2. Easier process tracking: Each sub-agent's work can be independently viewed and debugged

Building an AI Coding Team: Role Assignment and Real-World Results

The author used Open Code to assemble a complete automated engineering squad:

• Team Lead: Coordinates and delegates tasks, orchestrating collaboration between agents
• Product Manager: Read-only exploration, understanding user stories and requirements
• Backend Developer: Responsible for core code implementation
• QA Tester: Advances automated testing in parallel
• Code Reviewer: Independently reviews code quality and standards

Once launched, the team lead collects requirements and continuously delegates tasks. You can watch sub-agents interact in real-time—the lead asks the product manager to clarify requirements, code review works in parallel, and testing progresses simultaneously.

After several weeks of actual use, approximately 95% of cases work smoothly. The secret is continuously tweaking sub-agent prompts in their respective configuration files to ensure they match your workflow.

The Cost of Multi-Agent Architecture

Multi-agent systems are not without drawbacks, the most critical being token economics. Each agent needs to carry system prompts, conversation history, and tool definitions into the context window, causing token consumption to grow multiplicatively. Taking Claude 3.5 Sonnet as an example, at approximately $3 per million input tokens, a single multi-agent collaboration on complex tasks can consume hundreds of thousands of tokens. This is why the "on-demand loading" design of Skills (discussed later) has practical engineering value—it's essentially a resource scheduling strategy for the context window, avoiding stuffing all capabilities into every conversation.

Specific costs include:

• Significantly increased token consumption—longer instructions mean higher costs
• Reviewing sub-agent outputs and figuring out where changes landed isn't always efficient
• For most simple tasks, a single agent may be the better choice

Skills System: On-Demand Capability Extension Mechanism

Skills are essentially on-demand prompt injections, distinct from system prompts that permanently occupy the context window. If you're not touching AWS, you don't load the AWS skill—only call it when needed, effectively saving on token overhead.

A skill typically includes a Markdown file (defining the name and instructions) and may reference other files like GitHub Actions configurations or Kubernetes deployment templates. The benefit is that the community has already organized standards and workflows for you—for example, a Jira skill will have authentication methods, API endpoints, and board-viewing scripts all documented.

However, be aware: quality varies wildly in the skills marketplace, which claims to have nearly 500,000 skills—this exponential growth does look like a bubble. When choosing skills, it's best to follow trusted sources and carefully review content before use. This is quite similar to the early expansion of the npm ecosystem—the number of packages grew explosively, but the "left-pad incident" and supply chain attacks followed. In the AI skills scenario, a malicious or low-quality skill file can directly influence an agent's behavioral decisions—the risk is not to be underestimated.

Security Solution: Replacing Static Keys with JWT Ephemeral Tokens

Security is the most easily overlooked issue with AI coding agents: every agent will eventually need credentials—API keys, tokens, database passwords. Most people just stuff them into environment variables and call it done, but this is a security liability that will eventually bite.

Consider these scenarios: your computer gets stolen, a key gets committed to a public repository, someone social-engineers their way into your CI pipeline. Static keys persist indefinitely, and so do the permissions they grant.

The solution is JWT ephemeral tokens. JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting claims between parties. Its core advantages lie in "stateless verification" and "short-lived validity": the token itself carries an expiration time (exp field), allowing servers to verify legitimacy without querying a database—verification is extremely fast and horizontally scalable. In AI agent scenarios, combining OAuth 2.0's "client credentials flow" or machine-identity frameworks like SPIFFE/SPIRE enables dynamic issuance and automatic rotation of agent identities—the agent initiates an access request, gets a short-lived token after identity verification that expires in minutes, compressing the attack surface of static key leaks to a minute-level time window.

This fundamentally changes the security equation for multi-agent systems—you can build as many sub-agents and skills as you want with more confidence, otherwise they're running around carrying permanent keys, just creating more attack targets.

Multi-Platform Operation: Terminal, Web, and iPad Coverage

Open Code is no longer just a terminal tool—it supports multiple runtime modes:

• Terminal TUI: Wezterm or Ghostty recommended, with image drag-and-drop parsing support
• Web Interface: Launches on a local port, exposable externally via Ngrok—works on iPad too
• Neovim Plugin: Call agents directly from your editor
• Native App (beta): Built-in terminal, experience close to an IDE
• GitHub Integration: In PR reviews