Vibecoding in Practice: Prompt Slot Design and On-Demand Multi-Agent Loading

In AI engineering, there's a common yet easily overlooked design principle: each Agent should do as little as possible. Especially in pipeline-style multi-Agent collaboration, functional Agents should follow the "Single Responsibility" principle — if an Agent can do just one thing, never make it do two. This article, based on a vibecoding practice session by Bilibili creator "Powang," breaks down the core ideas behind Prompt template and Slot design, and how to distinguish "deterministic tasks" from "non-deterministic tasks" to properly allocate responsibilities between code and AI.

The Root Problem: Mixed Output Confuses the Model

The story starts with a real engineering scenario. In a script voice synthesis project, the author needed to integrate two TTS (Text-to-Speech) engines — Alibaba Cloud and Volcano Engine — while outputting a single, unified result.

The Diversity and Differences Between TTS Engines TTS (Text-to-Speech) is the technology that converts text into natural-sounding speech. The two major commercial engines in China are Alibaba Cloud TTS (based on its proprietary acoustic model and speech codec) and ByteDance's Volcano Engine TTS (based on the Volcano Speech Open Platform). These two engines differ significantly in API call formats, voice parameter naming conventions, emotion tagging systems, and their support for SSML (Speech Synthesis Markup Language). For example, Alibaba Cloud TTS's voice ID system and Volcano Engine's speaker field naming conventions are completely different, and each has its own schema for expressing emotional intensity. This heterogeneity is precisely what makes "having one Agent output two formats simultaneously" a high-cognitive-load task.

The intuitive first approach was to cram all the decision logic into one big prompt — tell the model: if this character belongs to the Alibaba engine, output using structure A; if it belongs to Volcano Engine, output using structure B, then have it produce mixed output in a single pass.

The problem surfaced quickly. Say a script has Character A (Alibaba) speaking the first line, Character B (Volcano) speaking the second, then back to Character A (Alibaba) for the third... The LLM's attention gets heavily consumed by constantly determining "which engine does this character belong to, and what output structure should I use."

Why Mixed Output Drains LLM Attention Modern large language models (LLMs) are based on the Transformer architecture, whose core computation unit is the Self-Attention mechanism. When generating each token, the model must "allocate" attention weights across the entire context window to decide which historical information is most relevant. When a prompt contains multiple sets of format rules simultaneously, the model must dynamically determine "which rule applies right now" at every generation step — essentially introducing a continuous "rule-switching" competition at the attention layer. Research shows that having conflicting or alternating format constraints in context significantly increases the model's hallucination rate and format error rate, because the model must maintain awareness of two rule sets rather than focusing on the semantics of a single task. This is why "multi-rule mixed prompts" are typically less stable in practice than "single-rule specialized prompts."

The author captured it perfectly: "Even a human would get confused doing this." Constantly switching between output rules for different engines not only wastes compute, but also leads to frequent errors.

Core Principle: Deterministic Tasks for Code, Non-Deterministic Tasks for AI

How do you break out of this? The author offers a judgment criterion every AI engineer should internalize:

First ask yourself: Is this a deterministic task?

• If it's deterministic (has clear rules, requires no semantic understanding) → handle it with code;
• If it's non-deterministic (requires semantic understanding or model reasoning) → hand it to AI.

The Engineering Boundary Between Deterministic and Non-Deterministic This judgment framework is fundamentally a precise recognition of "what computers are good at vs. what language models are good at." Deterministic tasks are characterized by an exhaustible, rule-driven mapping from input to output — like a lookup table: "Character A → Alibaba Engine → voice ID=xxx." These are best handled by code: fast execution, predictable results, zero hallucination risk. Non-deterministic tasks, by contrast, involve ambiguity, require contextual understanding, or demand creative reasoning — for example, "based on the script context, determine what emotional tone the character should use for this line." Stuffing deterministic tasks into a Prompt is like using a sledgehammer to crack a nut — it wastes your token budget (and thus increases API costs) while introducing unnecessary instability. This principle directly parallels the traditional software engineering idea of "don't do data routing at the business logic layer."

Back to the example: "which character uses which voice, and which line do they speak" — this is fundamentally a deterministic mapping. The relationship between characters and engines is predefined and doesn't require the model to "understand" or "decide" anything.

Since it's deterministic, it should be stripped out of the prompt and handled by code logic. This directly informs the refactoring of the "performance direction" (voice synthesis guidance) module. The author had AI first locate this module, clarify the current voice guidance logic and how it fits into the overall architecture, laying the groundwork for the subsequent restructuring.

Split Traffic, Not Responsibilities: Calling Both Engines in Parallel

The concrete approach: instead of having the model reason about engine assignment, split the traffic at the code layer directly.

With only two engines in the system, extract content by engine — Alibaba content goes to Alibaba, Volcano content goes to Volcano — then send them to two independent Agents via dual-path dispatch: the Volcano Agent only handles Volcano content, and the Alibaba Agent only handles Alibaba content.

This way, each Agent returns to its "single responsibility," attention is no longer fragmented, and output stability and accuracy improve significantly.

Transplanting the Single Responsibility Principle (SRP) to AI Agents The Single Responsibility Principle (SRP) was first introduced by software engineer Robert C. Martin ("Uncle Bob") in his object-oriented design theory, with the core statement: "A module should have only one reason to change." In traditional software engineering, SRP primarily guides the design boundaries of classes and modules, preventing the emergence of "God Classes" — classes that take on too many responsibilities and become a maintenance nightmare. Transplanting SRP to AI Agent design maps perfectly: the more responsibilities an Agent carries, the more complex the rules it must maintain in its prompt, the more frequently the model must balance competing objectives, and the less stable its outputs become. A "single-responsibility" Agent is not only easier to debug (when output fails, the responsibility chain is clear), but also easier to replace or upgrade independently — aligning with the classic software engineering goals of "high cohesion, low coupling."

Slot Design: Eliminating "Missed Updates" at the Architecture Level

But a new problem emerged. Now that the performance direction was split into two versions — one for Alibaba, one for Volcano — the system carried a maintenance risk:

If a future update only modifies the Volcano version but not the Alibaba version (or vice versa), the system's output becomes inconsistent — and this kind of bug is extremely hard to track down.

The author's solution was to eliminate this risk from the start — through Slot design.

What Is Prompt Slot Design

The core idea of Prompt Slot design is "base template + variable slots":

1. Extract the common parts: Take the shared, universal instructions for voice performance that both Alibaba and Volcano use, and build them into a base prompt template;
2. Isolate the differences: Inject the format differences and output structure variations caused by each engine's different backend model through slots;
3. Centralized maintenance: When you need to adjust the overall voice performance logic, change only the base template in one place, and both engines automatically sync; the engine-specific differences are isolated in their slots, so you don't need to update each one individually when modifying the base template.

The Engineering Origins of Slot Design The concept of slots (Slots) or placeholders in software engineering has a long history, most prominently seen in template engines — such as Jinja2, Handlebars, and Mustache in web development. The core paradigm of these tools is "separating invariant structure from variable data": the HTML skeleton exists as a fixed template, with dynamic content injected at runtime via {{variable}}-style slots. Prompt engineering borrows this idea, treating prompts as "parameterizable programs" rather than "static strings." In mainstream AI development frameworks like LangChain and LlamaIndex, the PromptTemplate class is a standardized implementation of this design pattern — developers define templates with placeholders and pass in specific variable values at call time to fill them in. The engineering value of this design is that it decouples "the logical structure of a Prompt" from "its specific parameters," allowing both to evolve independently. This dramatically reduces maintenance costs when reusing across engines or scenarios, and makes Prompt version management (e.g., Git tracking) much cleaner — template changes and parameter changes can be treated separately.

This approach preserves each engine's differentiated handling capability while eliminating the "missed update" risk of maintaining two separate copies. Change one place, both sides sync — inconsistency is ruled out at the architecture level.

Methodology Summary: Templates Handle Tasks, Slots Handle Differences

The core of this practice session can be distilled into one sentence:

When differences originate from the backend (e.g., Volcano Engine and Alibaba Cloud use different underlying models, leading to different format requirements or implementation details), use prompt templates + slots to handle them — templates own the task itself, slots own the downstream variability.

The engineering value of this pattern manifests across four dimensions:

• Single responsibility: Each Agent does only one thing — attention stays focused, output is more stable;
• Clear division between code and AI: Deterministic logic goes to code, semantic understanding goes to AI — each does what it does best;
• High maintainability: Common logic is abstracted into templates, differences are isolated in slots — no duplicate maintenance, no missed updates;
• Good extensibility: If a third engine is added in the future, you only need to add a new slot configuration — no need to refactor the overall logic.

For developers building multi-model, multi-backend AI applications, this "on-demand loading" approach to Prompt design offers a clear engineering paradigm: before writing a single line of prompt, think through what's fixed and what's variable — then use architecture to separate them. That's far more reliable than piling everything into one omnipotent mega-prompt.

Key Takeaways