This analysis organizes the evidence behind managing an AI Team Instead of Editing the Version Myself, then explains the practical implications, trade-offs and current limits.
Read the evidence below as a decision trail: what changed, why it matters, which trade-offs shaped the result, and where the conclusion still depends on context.
I made an immersive redesign of my website, with three pages online, SEO 100, and the URL unchanged. But this article does not talk about how I code, but about a more valuable thing: I did not modify the version myself, I was the PM directing an AI collaboration structure with a clear division of roles. The real skill lies not in knowing how to use tools, but in knowing how to design a collaboration structure.
Being able to use AI is not a threshold, being able to design a collaborative structure for AI is
Nowadays, "writing programs with AI" is no longer uncommon. There are many people who know it, and the tools are getting easier and easier to use. If my article is to tell you "I revamped my website using Claude Code", then it has no value, because everyone can say this.
The real gap is further upstream: when you face a project that requires brand judgment, front-end implementation, and visual design, how do you organize these abilities? What most people do is to throw all the questions into the same dialog box and let the AI think about the brand, write CSS, and adjust animations at the same time. The result is that each character is half-assed because they interfere with each other in the same context.
I did it differently this time. I positioned myself as a PM and split the AI into several roles with clear responsibilities, allowing each role to maintain its own boundaries, push back, and isolate context from each other. This article talks about how and why this collaboration structure is designed.
Let’s make it clear first: which ones are real agents and which ones are the role hats I wear?
Before I break down the collaborative structure, I have to make one thing clear, otherwise the credibility of the entire article will collapse.
There are many articles on the Internet that say "I used an AI team to do I am not like that this time, and I don’t want to package it like that, because this kind of packaging will fail as soon as it is questioned.
- The brand manager really has an independent agent definition.It has an independent role definition file (already included in version control), with its own hard rules and its own acceptance model. This part can be displayed and quoted, and is a truly independent character.
- The front-end engineer and art designer are the "role hats" I wear plus the cross-stage division of labor. They are not three agents who are online at the same time.The engineering role is responsible for porting the prototype into the framework and implementing it; the art role corresponds to scene vision and animation (scene videos are AI-generated material). They are working modes that I switch between at different stages, not separate programs that run independently.
Why be so careful about telling this boundary? Because the real value of this article never lies in the number of "how many agents I ran", but in "how do I cut roles, set boundaries, design push back and acceptance". Calling role hats honestly as role hats is the real skill - it proves that what I'm talking about is the design of a collaborative structure, not a show off of the number of tools.
How to break down PM: the outcome is determined, but the how is uncertain
The first core skill in commanding an AI team is to clearly distinguish "what instructions I should give" and "what instructions I should not give."
What I give to each role is outcome (what result is to be achieved), not how (how to do it specifically). The difference between the two determines whether you are a PM or an out-of-bounds engineer.
Give a practical example of a navigation bar:
- ✓ The outcome I should say: "Nav is reduced from 4 items to 2 items, and the mockup is aligned."
- ❌ What I shouldn’t have said: “Change the array on line 23 of Layout.js, use useState to manage the mobile menu, and add a certain className.”
What's the difference? When I say outcome, I reserve the right to judge "should this be done" and leave the "how" to the role responsible for implementation. It can be achieved in its own way, and it can be reversed if it is unreasonable. When I say how, I actually reduce myself to a remote remote control keyboard. The AI just follows the instructions. Once my instructions are wrong, it silently implements the errors.
This discipline I flagged in the vault as a recurring collaboration misstep: the PM role crossing the line into the how level. I deliberately kept it this time during the revision—brand managers don’t write CSS, engineers don’t make positioning decisions for the brand, and artists don’t decide the information architecture. Each role makes decisions only within its own area of responsibility.
Why I require every character to "talk back"
The second core skill is the requirement to push back.
An AI that only accepts everything is the most dangerous partner. Because it will implement your vague or even wrong instructions intact, and you will not find anything wrong until the results come out. By then, rework costs have already been incurred.
So my rules for engineering roles are: when encountering vague instructions, push back first, ask questions, and don't just follow them silently. This is not to make it difficult, but to advance the matter of "problem discovery" before implementation. A character who can say before taking action, "There are two solutions to your request with different consequences, which one do you want?" is much more valuable than a character who immerses himself in doing it.
The brand manager's push back is designed to be more aggressive. Its role definition contains these hard rules, which I will excerpt directly:
"Existing documents should be treated as 'hypotheses to be challenged,' not confirmed facts."
"Your job is not to sort out what I said, but to force me to make a choice I haven't made yet: provide options and consequences. I choose, and you don't decide for me."
What these two items mean is: I don’t want an assistant who can retell things for me, organize them for me, and make me feel good. I want an opponent who will force me to face decisions I haven't thought through yet. The default behavior of AI is to cater. If you want it to do the opposite, it must be clearly written in the role definition.
Multi-perspective acceptance: the same result, viewed with three eyes
The division of roles is not only used for "doing", but also for "acceptance".
The brand manager's acceptance model is to go through each item one by one from the brand perspective. Guardrail: For items that pass, explain in one sentence why it is true; for items that fail, point out which brand decision it violates, give specific directions for modification, and mark the severity - blocker (blocking the line), should-fix (should be repaired), nitpick (minor fault).
The value of this set of acceptance is that it is two completely different sets of eyes from the "project acceptance". The project acceptance asks "whether it runs well and whether there are bugs"; the brand acceptance asks "whether this screen violates our brand decision." For the same revision result, just because it can pass project acceptance does not mean that it can pass brand acceptance. Multi-perspective acceptance focuses on this gap of "technically correct, but wrong in positioning".
handoff loss: how to transfer characters without distortion
When you divide work into multiple roles, there will inevitably be handoffs between roles. And handover is lossy.
When character A's mental reasoning (why he makes this judgment) is passed to character B, if only a summary is passed, the details of that reasoning will be lost. What B got was a conclusion without context, and it was easy to proceed based on a wrong understanding.
I labeled this phenomenon in the vault as "multi-agent handoff fidelity loss" - the loss of fidelity in multi-agent handoffs. There are two countermeasures: structured briefing during handover (structured handover instructions, not just a random sentence), and reference to the original evidence, do not just send a summary. Allow B to go back and look at the original materials that A relied on at the time, instead of just trusting the second-hand conclusion given by A.
In this structure, I (PM) play the role of the bridge layer, not the messenger. The courier is only responsible for moving words from A to B; the bridge layer is responsible for ensuring that the reasoning is not distorted during the transfer. This difference is the key to whether this entire collaborative structure can be established.
What this means
I think the real ceiling for a person’s use of AI is not whether you can use the latest tools, but whether you can design a collaboration structure. Tool capabilities are public and available to everyone; collaboration structure design capabilities are not. The former puts you on the same starting line as everyone else, while the latter is where the gap widens.
I also think that this matter has nothing to do with "how many agents were run". The only agent I am running independently this time is the brand manager, and the others are role hats I wear. But this does not affect the conclusion - the focus has never been on the number of agents, but on whether the roles are clearly defined, the boundaries are strictly guarded, and the push back mechanism is designed well enough. A person who can design a collaboration structure, even if he only uses one agent and a few role hats, can produce better results than "opening five dialog boxes at the same time to ask random questions."
Finally, what I want to say is: the role of PM will not disappear in the AI era, but will increase in value. Because when the capabilities of the execution side are greatly supplemented by AI, what is scarce becomes the judgment-based capabilities of "determining outcomes, designing and accepting, controlling handoff losses, and retaining key decision-making rights." AI cannot currently do these things, and this is exactly where a person should spend his or her time when facing an AI team.
Context isolation is not a limitation, it is a feature
The third and most counter-intuitive design: I deliberately asked the brand manager to "forbid discussing implementation."
Its hard rules read:
"It is forbidden to discuss implementation: no discussion of Three.js, no discussion of CSS, no discussion of scroll implementation, no discussion of component architecture. When the topic is brought to engineering, write it down and bring it back to brand issues."
Sounds like self-defeating martial arts - why ban a character from talking about technique? The answer is: Once the brand judgment is hijacked by "whether this can be done technically", it will be interrupted by "can it be done" before "should it be done" is clearly thought out.
The correct sequence is: first determine whether the brand should do this. Once this judgment is established, then go to the engineering level to discuss "how to do it and whether it is feasible." If the brand manager is allowed to think about positioning and implementation at the same time, he will self-examine every brand decision, and the judgment of output will be diluted by engineering feasibility.
The same logic is used in reverse for the engineering role: when it encounters ambiguous instructions, it has to push back instead of silently following them, so that a problematic brand instruction will not be silently turned into already written code.
Therefore, the essence of context isolation is to prevent each character's judgment from being contaminated by the considerations of other characters. Role boundary = context isolation = prevent "PM from overstepping the boundaries and writing how", and also prevent "tools from taking away the decisions that people should make". This is not about tying your hands, it is about letting each hand do what it is best for.
Practical questions and boundaries
If a person uses AI to revamp a website, what capabilities should he invest in most?
It’s not about learning the latest tools or frameworks, but learning to design a collaboration structure: how to divide work into roles with clear responsibilities, how to set boundaries, how to push each role back when it’s ambiguous, and how to design multi-perspective acceptance. Tool capabilities are available to everyone, but the ability to design collaborative structures is what widens the gap.
What is "the outcome is determined but not the how"? Why is it important?
Defining outcome is to tell AI "what result is to be achieved" (for example, Nav is reduced from 4 items to 2 items), and determining how is to tell it "specifically how to change which program". When you only give outcome, you retain the right to judge and leave the implementation to the responsible role, and it can also infer unreasonable requirements; when you give how, you are equivalent to downgrading yourself to a remote keyboard, and the instructions will be silently implemented if there are errors.
Why should AI characters be deliberately "forbidden to discuss implementation"?
Because once brand judgment is hijacked by "whether it can be done technically", it will be interrupted before "should it be done". The correct sequence is to first determine whether it is appropriate for the brand, and then go to the engineering level to discuss how to do it. Context isolation prevents each character's judgment from being contaminated by the considerations of other characters. This is a feature, not a limitation.
What to take away
The article's value is in the evidence and trade-offs behind managing an AI Team Instead of Editing the Version Myself, not in treating the conclusion as universal.