11-Year Veteran Engineer Live-Dissects: How Vibe Coding Tames Multi-Agent Systems

Why "Vibe Coding" Needs a Senior Engineer's Mindset

Vibe coding is often misunderstood as "throw your requirements at an AI and wait for the finished product." But a developer with 11 years of experience—currently serving as an AI lead at an enterprise—demonstrated another possibility over several consecutive days of live streaming: using an Orchestrator + Worker multi-agent architecture to complete an AI-capable product prototype in just a few hours. The core is not letting AI generate code unchecked, but using an engineered workflow to constrain AI output.

This developer emphasized that he never talks directly to an individual coding agent. Instead, he interacts only with a "master control agent," which dispatches tasks to multiple independent worker nodes. This resembles a master-worker architecture in a technical team—the manager doesn't write code personally but must clearly understand each module's boundaries and acceptance criteria.

From Zero to TestFlight: A Three-Day Sprint for a Reminder App

The app built during the stream is a note-taking application called "Noting (Reminder)," positioned as a "second brain." It contains three screens: capture input, collection and organization, and question-answering retrieval. Users can record ideas in natural language, and a backend agent layer automatically determines whether to store them as tables, lists, or notes.

By the third day of the stream, the app had already entered the TestFlight distribution phase, with an invitation gate that opened it only to community beta testers. The developer noted that the mobile app distribution process should start in parallel from day one of development, because App Store review and beta testing can consume significant time.

During testing, the developer demonstrated how the app handles two types of input: recording a summary of a live stream, and recording an expense (such as "spent 1,200 rupees on a T-shirt"). The former is stored as a regular note, while the latter is automatically organized into a table with an amount column. This ability to determine storage structure based on semantics is the key differentiator between this app and ordinary note-taking software.

The Multi-Agent Workflow: What the Master Control Agent Actually Does

The core of this workflow is an agent development environment called S-Clock. It supports running multiple coding agents (Codex, Claude, etc.) within a single window and allows connecting multiple machines—the developer's MacBook, Mac mini, and remote servers can all appear simultaneously in the same workspace.

The master control agent's responsibilities include: receiving human instructions, decomposing tasks, generating independent prompts for each worker node, running tasks in separate Git worktrees to avoid conflicts, and shutting down nodes after task completion. During the stream, the master control agent managed four to five agents simultaneously: one running the simulator, one reviewing PRs, one handling TestFlight releases, and one doing cleanup and fixes.

The developer specifically pointed out that compared to letting a single agent handle all operations, this dispatch model saves token consumption—because the master control agent itself doesn't process specific tasks, only handles scheduling.

Git worktree is a feature available since Git version 2.5 that allows multiple working directories to be checked out simultaneously on the same repository, with each worktree pointing to a different branch. Unlike traditional git checkout branch switching, multiple worktrees don't interfere with each other and can be modified, compiled, and tested in parallel. In multi-agent coding scenarios, each agent is assigned an independent worktree, meaning they can commit code simultaneously on their respective branches without file lock conflicts or workspace pollution; after tasks are complete, the master control agent merges or creates PRs in a unified manner. This essentially replaces manual coordination with Git's isolation mechanism, making parallel development controllable and auditable.

Token is the basic unit of measurement for how language models process text, roughly equivalent to a word or part of a word. A model's context window, invocation costs, and rate limits are all calculated in tokens. In multi-agent architectures, token consumption grows linearly or even exponentially with the number of agents, because each node needs to carry system prompts, tool definitions, and historical context. Having the master control agent only handle scheduling and not process specific tasks concentrates expensive context where it's needed and avoids duplicating the same large context across multiple agents, thereby significantly reducing the token overhead of a single task.

Security Guardrails: Prompt Injection and Credential Management

The most cautionary part of the stream was the discussion of agent security risks. The developer uses OnePassword as a credential vault, and agents need explicit authorization to access it. But he discovered that the master control agent sometimes attempts to access credentials in the vault without clearly indicating at the top of the interface "which agent is requesting what permission."

He gave a real prompt injection scenario: if email reading permission is granted directly to a coding agent, an attacker could embed hidden instructions in the email's HTML source code. When the model summarizes the email content, these instructions could cause the model to ignore the system prompt and instead execute malicious operations. This risk is especially prominent in scenarios using smaller or older models.

Therefore, his principle is: credentials are never written into environment variables, and every agent access to the vault must be traceable and require authorization.

Prompt Injection is a class of attacks targeting large language model applications: attackers hide malicious instructions in data that the model will read (such as web pages, email bodies, documents, or even image metadata), inducing the model to treat this data as instructions and thereby bypassing system prompt constraints. It is similar to SQL injection in traditional web security, but the injection vector is natural language rather than code. Indirect injection is especially dangerous because attackers don't need direct access to the application—they only need the victim to process a piece of tainted content. Common mitigation measures include: marking and isolating untrusted input by source, granting least privilege, introducing human confirmation for sensitive operations, and constraining model output to structured formats.

Model Selection and Cost Reality: An Honest Rant

The developer gave a fairly blunt assessment of his experience with current models. He subscribes to both Claude and Codex, but Codex's weekly quota was more than 70% consumed within two days, and it was noticeably slower. He admitted he wouldn't recommend Codex to others, only treating it as a fallback when Claude is unavailable or for scenarios requiring computer automation on a Mac mini.

For developers on a budget, he suggested: students can choose a lower-priced Claude plan, or call open-source models like Kimi, GLM, and DeepSeek^Ad through OpenRouter. He emphasized that understanding the positioning and cost structure of different models is itself part of the vibe coding workflow.

Evaluation and Observability: Don't Just Build, Verify

Before the app was about to launch, the developer connected the agents to Mastra Studio for evaluation. He demonstrated how to view each agent's system prompt, the model used, and tool invocation records, and emphasized the importance of the concept of "evaluation"—you can't just build agents; you also need to use scorers to verify their performance on specific tasks.

He compared this approach to model benchmarking: different models may perform very differently in your specific use case, and only through evaluation can you make informed choices. For production environments, he uses Langfuse for observability tracing because it can be self-hosted, making it easier to monitor the actual behavior of online agents.

Scorer is the basic unit in agent evaluation, responsible for giving a quantifiable score to the result of an agent run. Common types include: rule-based exact matching, embedding-based semantic similarity, LLM-as-judge where another model acts as the judge, and human annotation. Scorers are typically used with a fixed set of inputs (a dataset) to form a repeatable evaluation set, allowing you to quickly determine whether performance has improved or worsened after changing models, modifying prompts, or adjusting tools. Observability, on the other hand, focuses on runtime tracing, recording the prompts, models, tool call chains, latency, and cost of each invocation. Only by combining the two can you answer both "how good is the performance" and "why is it this way."

Community Project Reviews: Practical Feedback from Design to Distribution

In the latter half of the stream, the developer reviewed multiple community projects, including an AI tutor, a subtitle generation tool, an offline AI application, and a remote desktop client. His feedback focused on several directions: landing pages should showcase the product workflow rather than merely listing features; API network requests should not expose internal prompts or model choices; and products targeting specific regions should be prepared for global adaptation.

These review sessions also reflected a point he repeatedly emphasized: vibe coding lowers the barrier to building, but productization still requires engineering judgment—from security and distribution to user experience, no step can be fully delegated to AI.

One-line Summary

A veteran engineer uses a master control agent to orchestrate a multi-node workflow, completing an AI application prototype and advancing it to beta testing within hours.

Paragraph Summary

The article documents several consecutive days of live streaming by a developer with 11 years of experience, demonstrating how to use an "Orchestrator + Worker" multi-agent architecture to take a semantic note-taking app from zero to TestFlight invitation beta testing in three days. The core method is not talking directly to individual coding agents, but having a master control agent decompose tasks, generate prompts for each node, execute in parallel within independent Git worktrees, and unify the final wrap-up—thereby saving tokens and avoiding conflicts. The article also focuses on security risks of prompt injection and credential vaults, negative assessments of Codex's quota and speed along with alternative model recommendations, and the necessity of using Mastra Studio for evaluation and Langfuse for observability before release.