COVER STORY
More instructions. Less reliable work?
A game developer’s failed rulebook exposes the limits of adding instructions. The next step is to rethink where information, judgment and checks belong.
The failure hidden inside an 800-line rulebook
Start with the actual project. Liu Junyi was building a Cocos Creator game for WeChat. The client, server, protocol and product requirements lived in four repositories, with different roles handing work to one another. To keep AI on track, he expanded a Skill and its instructions from over 500 lines to over 800 and added rules it was supposed to obey. Steps still went missing; requirements disappeared between stages. 13
This was not a controlled comparison of long and short prompts. It does not establish 800 lines as a failure threshold. The revealing detail is one concrete mistake: the decoration system allowed at most 20 placed items to be returned to inventory in a batch. Task decomposition turned that into “return all,” and the implementation faithfully did exactly that.
The constraint lost its provenance. An implementer who sees only the previous agent’s summary cannot tell whether “all” is a product decision or an omission in the handoff. Another instruction to follow requirements does not restore the missing information.
01 / WHERE THE LIMIT DISAPPEARED
20 → all: a constraint lost in a handoff
- REQUIREMENTAt most 20
A limit is part of the task
- TASK SUMMARYReturn all
The limit vanishes in translation
- IMPLEMENTATIONFaithfully wrong
Matches the summary, violates the requirement
Check the original bounds → cite the design → reread it during implementation
Based on the author’s batch-return example, not a model benchmark.[13]
The author rebuilt the work around a staged workflow called x-flow. Specialist roles remained, but designs, tasks and implementations were connected to inspectable artifacts, with human review at important transitions. The valuable change was not simply more stages. It was the ability to trace a decision back: check the design against requirement boundaries, make tasks cite the design, and have implementation read it again. That gives the missing “20” a chance to surface before a user encounters the bug.
Some rules belong in code. Some knowledge can wait
The same case describes an import between game packages that worked in the editor but crashed on a real device’s first load. Repeating the lesson in a prompt asks the model to remember it every time. A checking script can identify the violation before submission. 13
When a condition can be checked reliably, let a program check it. This does not mean encoding every product decision. Whether a design is good or a feature deserves to exist still requires judgment. Whether a file exists, protocol versions agree, or an import path is allowed often does not.
02 / WHERE RULES BELONG
The whole manual need not travel every time
- ALWAYSCore constraints
- Goal, authority and boundaries
- ON DEMANDSkills & references
- Stage-specific procedures, knowledge and history
- ON ACTIONTools & scripts
- Versions, paths, preconditions and schemas
- AT HANDOFFPeople & acceptance cases
- Real experience, tradeoffs and consequential exceptions
Editorial synthesis: carry less repeated material while giving constraints a reliable home.[13][16]
The figure is this issue’s synthesis of the case. It makes two kinds of room: keep permanent instructions short enough to notice, and retrieve stage-specific material when it becomes useful. Knowledge is retained without carrying the whole library into every exchange.
Memory also needs conditions, dates and evidence. Facts about code should come from the current code. Frequently used advice can be stale; a rarely invoked publishing constraint can still be essential. Prune a rule because it is obsolete or a stronger mechanism now enforces it, not simply because it has few recent hits.
A subagent can parallelize work and restart understanding
Another central reading comes from Anthropic. For some enterprise systems, it recommends folding closely related subagents into a main loop, moving specialist procedures into Skills and tools. Handoffs can lose context and add latency. It also retains reasons to use subagents: context isolation, independent parallel work and conflicting tool environments. 16 Official article
Consider support for a customer asking about both an order and its arrival. If two specialists keep exchanging information about the same order, their synchronization cost may outweigh the complexity they remove. One agent holding the full conversation and using two lookup tools might work better. Two departments do not automatically require two reasoning loops.
The opposite is possible too. A reviewer may benefit from a fresh context that does not inherit the implementer’s explanation. Independent investigations can finish separately before synthesis. And a single loop can make parallel tool calls: parallelism alone does not require more agents.
03 / CONTEXT & BOUNDARIES
Keep shared understanding together
Keep one shared context
One goal and shared data: fewer summaries to exchange.
Split independent work
Each has bounded inputs and outputs; synthesis still needs checking.
Conceptual structures, not a speed comparison. One loop can also call tools in parallel.[16][06]
My preferred question is whether the information needs to stay together. If each next step repeatedly needs the preceding step’s reasoning, try combining them. If a task has independent inputs, a clear deliverable and a result the main agent can check, delegation may earn its place. Boundaries should follow the work’s dependencies, not the appeal of a complete organization chart.
Why does another architect still favor several agents?
An InfoQ translation of a Carlos Kelkboom interview supplies a useful counterpoint. Keep the architecture and skeleton understandable to a human, then let agents explore implementations. When generated code becomes unintelligible, he prefers restarting in isolation to accumulating more patches. 06
Several agents independently exploring one problem differ from several agents successively rewriting one requirement. The first arrangement purchases alternatives at the cost of duplicated work and comparison. The second divides stages at the cost of information loss between them. Neither improves simply by adding people-shaped roles.
The Tencent case did not remove all specialist roles either. Separate repositories, protocol boundaries and human coordination were genuine constraints. Summarizing that article as “never use multiple agents” would reverse its lesson.
An extra role should be able to explain its benefit: what interference it isolates, what independent error it finds, or what measurable wait it removes. “It looks more like a team” is not yet a benefit.
Did the simplification preserve what already worked?
A faster merged system is only half a result. In Anthropic’s support example, a merge reduced latency but dropped a delivery date the earlier system supplied. Repeated runs exposed the failure. 16
Keep a small set of real tasks with explicit inputs, required outcomes, constraints and final artifacts. Change one structural choice at a time. Then inspect which tasks changed from failure to success, and which changed from success to failure, rather than relying on one average.
04 / CHECK THE CHANGE
Beyond the average: which task regressed?
What improved?
Keep the input, result and reproducible check.
What was lost?
An order is found, but its delivery date is missing.
Repeat the same task
Intermittent omissions count; do not pick only the best run.
A proposed checking method, not measured results. Also record completion, latency, cost and rework.[16]
Tencent’s article on the full development workflow appeared in last issue’s Sunday addendum and falls within this issue’s formal save window. Its focus on requirements, collaboration and delivery fits here: faster generation can move the bottleneck into waiting, checking and rework. 01
The practical goal is to remove instructions, roles and repetition that do not improve delivery, while making the remaining checks effective. A line count or an agent count is not the finish line.
