Using Manus to Transform Manus: Practices and Reflections on Building an AI-Native Organization - 53AI-AI Knowledge Base|Enterprise AI Knowledge Base|Large Model Knowledge Base|Forward Deployed Engineer|FDE

Scan the QR code with WeChat

Add your dedicated advisor

Save

Published: 2026-10-27 09:25:20 Views: 1973

Editor's Recommendation

The Manus team's hands-on experience implementing AI Native organizational transformation, unlocking a brand-new paradigm of human-AI collaboration. 1. Real work scenarios and visible changes from the entire Manus team deeply using their in-house AI tools 2. How the product and engineering teams used AI to rebuild development workflows and eliminate cross-role collaboration friction 3. Cutting-edge exploration and thinking on human-AI collaboration models in an AI Native organization

Yang Fangxian

Founder of 53AI / Most Valuable Expert of Tencent Cloud (TVP)

In September, while the Manus team was going all-in on developing Manus 2.0, something happened one day that left a deep impression on me.

I gave an engineer a few requirements and bugs, and went over a while later to check on progress. I saw a row of Codex and Manus sessions open on his computer. I clicked into one at random—the input in these sessions was the exact text of the requirements I had just sent him on Slack, word for word.

In the past, when an engineer received a requirement, they would first analyze it themselves, then start writing code. Now, whether it's a new requirement or a new bug, people basically hand it straight to AI. The AI finds the relevant code on its own, then makes the changes itself. Throughout the process, the part done manually by humans is shrinking, while directing AI to do the work and taking responsibility for AI's results takes up an ever-larger share.

What surprised me even more was when I suddenly realized that our engineers' typical work rhythm is one person handling a dozen or twenty requirements at the same time. These days, many companies use AI to write code and boost development efficiency—nothing unusual there. But even so, one engineer handling a dozen or twenty requirements simultaneously is still a bit extreme. At today's Manus, it has become the norm.

As the team used Manus and various AI tools more and more deeply, and as Manus 2.0 unlocked more new capabilities, that scene I saw behind an engineer's screen was just a microcosm. From product and engineering to go-to-market, operations, and every other team, changes were gradually taking place: how the organization is structured, the relationship between people and AI, how information flows, and the boundaries of each person's capabilities were all being quietly adjusted, even reshaped.

My feelings were complicated. There was excitement—happiness and pride at the team's continuous iteration and change. But also unease: is this pace right? Is it fast enough, or too fast? Could this way of working bring problems we haven't seen?

I tried to work with colleagues to compile some of Manus's recent AI Native practices and explorations. The process of change itself is valuable—as a company building AI agents, Manus holds itself to one requirement and one pursuit: "eating our own dog food" and exploring the boundaries of AI usage. Beyond the product, Manus also faces an inevitable exploration: since work today and in the future assumes AI collaborating with humans by default, how should an organization that enables humans and AI to collaborate more smoothly operate?

Due to space constraints, this article only covers three teams. It records the practices and thinking happening inside us right now—it is an exploratory process, not our final answer on AI Native.

In the past, when a requirement came in, it was first reviewed, then split between frontend and backend development. After writing, everyone would align interfaces and hunt for problems together—so-called "integration testing"—and finally test and ship.

The biggest friction was in integration. Frontend and backend each had to understand the requirement separately, then agree on interface rules. When understandings diverged, they had to communicate and revise repeatedly. Often it wasn't that people weren't trying hard—it's just that it's very hard for people to align perfectly with each other.

Manus had this problem too. So we thought: since AI can write code across the stack, could the division of labor be blurred? If one person fully understands the requirement and then drives the frontend, backend, and mobile implementations, the friction of cross-stack coordination can be reduced.

But the code was scattered across different repositories. Even with one person in charge, the AI still couldn't see the whole picture in a single context.

We built a code repository called Manus-mono, referred to below as Mono. It didn't merge the code together; instead, it provided a unified entry point, paired with a manual written for AI: what each repository does, how they work together, and what standards engineering follows. When the AI needs to change something, it pulls the corresponding repository.

Mono grew step by step, with each step solving a problem exposed by the last:

• Let the AI see the whole picture. We filled in business knowledge beyond the standalone repositories, making cross-repository collaboration possible, and supported parallel development via Git worktree.
• Let the AI verify locally. In the past, every code change took 5 to 10 minutes to push to the test environment. Now, a complete Manus can run on a local machine, and verification takes only seconds.
• Let the AI investigate production issues. Under permission controls, Mono can read production logs, configurations, and exception records to get the information needed to debug bugs.
• Let the AI complete the release process. For the steps where releases tend to get stuck, we kept expanding the AI's operational capabilities, but approval authority remains with humans.
• Let the AI do end-to-end verification. Once verification became the new time-consuming step, we had Mono walk through the real flow with test accounts, checking results in the browser and on mobile simulators.

Gradually, Mono became like a knowledge base paired with a super administrator who knows all the rules. The more people use it, the more knowledge it accumulates. For example, ops colleagues were often asked to help with releases and found it annoying, so they wrote the release process into Mono. From then on, everyone knew how to do it—and could even have AI do it.

I love this example: a small thing one person did to free themselves up ended up making the whole company a bit faster.

By now, the team has reached a consensus: for a single requirement, one person can write every platform. The most vivid example: our mobile team has always been just 7 people, simultaneously responsible for 2 products with 4 mobile apps in total, keeping pace essentially in sync with the web version.

The adoption of a tool and the philosophy behind it within a company depends on the tool itself, but also heavily on the company's culture and organizational structure.

At Manus, pushing Mono forward met almost no resistance. I think there are three reasons:

1. Exploring the boundaries of AI usage is inherently one of our pursuits. This means such exploration gets encouraged, and there are always people pushing it forward.

2. The team cannot tolerate inefficiency. For tasks that need to be repeated, and for things AI can already judge and handle efficiently, if they're still done manually, acceptance is very low.

3. The organization is flat enough. This means most decisions, whether top-down or bottom-up, can quickly reach the entire organization.

So what about the teams beyond engineering?

The "old-school" product development process goes like this: the product manager has an idea, does research, looks at competitors, finds data, then works with designers on prototypes and interfaces. Then review, engineering scheduling and development, and finally acceptance testing, QA, and launch.

Many people are on this chain, and information gets lost a little with each person it passes through. From the same requirements document, the prototypes produced by product and design could be completely different.

But what's even more painful is misaligned priorities. What matters most to one person isn't necessarily what matters most to another. The more people involved, the worse the misalignment.

After Claude Code and Codex appeared, engineers' efficiency soared, but a new problem emerged: not enough product managers—there wasn't time to supply enough high-quality requirements.

It's a subtle moment: in the past, engineering resources were always the bottleneck; now, for the first time, it's flipped.

Internally, our first attempt was to have a small number of engineers become Builders: one person responsible for the entire process from discovering a problem to shipping it, reducing communication loss and priority misalignment during handoffs. But at the time, engineers who understood both technology and product judgment were not that common.

So we launched an internal program to blur the boundaries between roles, letting product managers edit code directly. But two problems remained: handoffs still existed—after a product manager made changes and passed them to engineering, the engineers couldn't necessarily pick things up right away; and product managers lacked an engineering perspective. So at that time, product managers could only change copy and interactions, not the underlying logic.

Mono solved both problems.

First, it has built-in standards and confirmation requirements. Any change involving model calls or costs must, per the standards, be confirmed with the responsible colleague before the code is modified.

Second, we built our own code review bot that uses the best model to review all code, with dedicated check rules for critical modules like payments. Mono can also use test accounts to walk through flows like registration and payment while recording the screen step by step. Product managers watch the recordings and can point out what's wrong.

Here's a story to share.

One of our product managers was working on a speech-to-text feature. She first had Manus test over a dozen models, then picked one to integrate. Next, she got the frontend code through Mono, built a Demo following the existing design standards, and had Manus generate images for every scenario users might encounter. She checked them one by one, and had Manus fix whatever was wrong.

After the fixes, she used Manus's video editing feature to turn the Demo into a video. The plan was clear enough that she decided to finish building the feature. She completed the interfaces for both the web and desktop versions herself.

Throughout the process, human involvement was concentrated in three types of judgment: choosing the model, reviewing the Demo from product and design perspectives, and having engineers with release authority review the code.

A single product manager took a feature from model selection all the way to launch. A year ago, this was nearly impossible.

We see this as a huge shift from Human in the loop to Human on the loop. Before, AI did 70% to 80% of the work and humans filled in the rest; now, what AI can complete has increased dramatically. Humans design the rules, supervise the work of multiple AIs, judge methods and results at key checkpoints, step in when necessary, and take responsibility for the outcome.

Worth mentioning here: Manus 2.0 greatly improved video production capabilities—it can both generate videos from images and create animations with code. As a result, some product managers now deliver requirements not as traditional PRDs or design mockups, but as a complete video.

In a few minutes, the video conveys the key information about a feature: what scenarios users will use it in, how the interface is designed, what happens after a click, how different states and edge cases are handled, and the implementation logic behind it.

I don't know if other companies do this. From our experience, video really does make it easier for upstream and downstream teams to align. Design, engineering, and QA watch the same demo and more easily understand "what the final product should look like," without having to explain repeatedly to different people. After I shared this at an internal product meeting, more and more colleagues started writing requirements this way. Below is the Product Requirements Video (PRV) for the voice input feature.

Now, about half of our product managers can independently complete requirements and ship them, and every product manager has submitted code through Manus. Designers have recently started writing code too. In Manus 2.0, most of the interface visible to Manus Studio users was written by a product manager. The Video Editor was also written by a product manager.

Writing this, I feel moved. Behind these stories are colleagues who, over the past few months, proactively pushed the boundaries of their own capabilities. This is what I'm proudest of about the team.

The marketing team has also made some attempts. Here are two recent examples.

The marketing team often does content collaborations. A single collaboration involves making contact, confirming the partnership, reviewing scripts, approving prices, contract and payment, then publication tracking and performance review. Ad campaigns also have a long process: reviewing data across multiple platforms, creating campaigns, uploading assets, then analyzing results and making adjustments.

These steps are scattered across email, contract platforms, internal approvals, project spreadsheets, and various platform backends. People constantly "move" information between systems: a contract is signed, so someone updates the spreadsheet status; content is published, so someone notifies the relevant colleagues.

With few people and long processes, most energy gets consumed by coordination and process, while the creative work that truly needs ideas and judgment gets squeezed out. We had the same problem.

Using Manus to improve Manus started in the marketing team with a very small problem: we found that after a collaboration or ad was published, we often didn't know right away. The news had to pass through several layers of people, and by the time we learned of it, it was already a bit late.

So we first had AI write scripts to automatically detect when content was published. Knowing the publication time, we then wanted to see the performance data; and since we could see the data, we went back and reviewed past collaborations too.

Next, we connected the processes. Once steps like contract signing and internal approval were completed, the system sent a signal, and the AI would update progress and reach out to relevant colleagues to move things to the next step.

Manus built these features into an internal website. To humans, it's data, dashboards, and calendars; to AI, it's a set of callable tools—AIs that know how to use these tools in their work have become our digital colleagues.

The biggest difference between a digital colleague and an ordinary tool is that it genuinely participates in the team's workflow.

It receives and organizes work like a colleague. Many colleagues approach it at the same time, so it talks to everyone in a single "workbench" Session, then breaks out specific tasks and delegates them to other Sessions to run in parallel. This way, its own "attention" doesn't get maxed out. There are lots of messages in Slack, and it doesn't reply to every one immediately. It first judges: does this message concern me? If so, it sorts them into "interrupt what I'm doing" and "handle after finishing." We didn't teach it these rules—the AI designed them itself during development.

It gets new information into execution faster. Before, when the team had a new strategy or product insight, it had to be explained at a weekly meeting and then written up in a brief. Now, the marketing lead just forwards the discussion to it and says "learn this." It adjusts its knowledge accordingly, and every subsequent execution makes use of it.

It remembers long-term goals. Once, colleagues were discussing two projects in Slack and momentarily couldn't remember what stage one of them was in. Nobody @-mentioned it, but it proactively reminded them: "B is still in testing—should we wait for A's results before looking at B?"

When I first heard about this, I was delighted. In that moment, it didn't seem like a tool, but like a colleague who had been listening attentively to the meeting all along.

It proactively aligns across teams. After the product team released the 3D model generation and rigging features, it proactively asked about the features' conditions of use. Only by asking did it learn that rigging currently supports seven categories of objects, such as fish, snakes, and quadrupeds. It noted down these details, so when introducing the feature externally later, it could describe it accurately.

Colleagues reviewing scripts and prices have also started proactively asking it to look things over together. The reason is simple: a person can only review so much material in a short time, while it has seen all the historical records. But the final call is still made by humans.

Normally, the digital colleague uses the internal website we built—whatever features the site has, that's what it uses. If the site isn't good to use, it can only make do, or tell us, and then we fix the site.

But we didn't want to be the middlemen. So we opened a feedback interface on the website. When it finds something awkward to use, it can submit a request directly through this interface. As soon as a request comes in, it automatically triggers a Manus development task. This uses Manus 2.0's Automations feature: it can automatically start a task upon receiving an external notification.

This way, the digital colleague can not only work with existing systems, but when it encounters a feature the system doesn't support, it can even file a request with Manus—so in the future, it will be able to use that new feature.

There's a common shift across all these scenarios: many things that used to require "finding someone to ask" no longer require interrupting that person. Within Manus, we've gradually formed some shared understandings.

For product and development questions, ask AI first. A colleague built a Slack bot with Mono that runs on a cloud computer; when it receives a task, it processes it and then replies in the original message thread. The people who use it most are non-engineering colleagues. To find out how a feature works, where the copy lives, or whether something has shipped, there's no need to first figure out who owns it—just ask the bot directly.

To check progress, open a Session. Previously, engineers' progress lived inside their own AI conversations. Others had to ask them directly, and once they were off work, no one could see the progress. So we built a collaboration feature, currently internal-only: members of the same project can see each other's Sessions by default, and can also request to join a conversation and speak.

For example, an engineer first completes a large amount of work with AI, then a product manager enters the same Session to adjust spacing, styling, and copy. The two of them and the AI take turns pushing things forward. For others to post messages in your Session, your approval is still required; we're still refining this part of the permission design.

〔A diagram of an engineer, a product manager, and a designer collaborating in the same Session. The content is fictional and not a real work Session.〕

I want to emphasize one point here: when I say "no longer need to ask people," I don't mean reducing person-to-person communication. What I think matters more is reducing the "interruptions" in organizational collaboration and the resulting loss of time and energy.

Make decisions, or even just look at what needs your decision. One colleague on the team who uses AI the most probably has the most "extreme" working method. He has one master Manus Session dedicated to a single task: listing the things that need his decision, along with recommended options. While everyone else is having a heated discussion in Slack, he doesn't need to open Slack, and rarely opens the code repository. He just asks AI: "What needs my decision right now?" AI lists a few items, explains where each one is stuck, and he makes the call.

I use this method myself. I have more than twenty to-dos every day, and I've shared in some settings that I have ADHD—for me, the hardest part is "getting started." Now, I hand all my to-dos to a dedicated Manus project, which breaks each one into independent tasks. What it can do, it starts directly. What it's unsure about, it comes to ask me for context, such as which product manager should follow up. Then it does a round of research using information from Slack, Gmail, and Notion, and hands the requirements together with the research results to the corresponding product manager. What the product manager receives is no longer a one-line to-do, but a plan with full context. For me, this isn't just a change in efficiency. It has greatly reduced my daily anxiety of "not knowing where to start."

At the beginning of the month I shared on WeChat Moments: the company's AI spending in September exceeded $10,000 per person. Not everyone used that much—a few individuals used seventy to eighty thousand dollars on their own.

After I posted that, some people questioned whether the spending was excessive. I read all these questions carefully. Today I'll answer this question head-on:

First, this money buys not headcount, but time and attention. As a team grows, communication costs rise. What AI saves is each person's attention, giving everyone fuller control over what they're responsible for.

Second, it's expensive because we use the best models, which is the core way to understand AI's boundaries. The colleague in charge of engineering efficiency told me that our code review bot has been in use for quite a while, and in the past six months he hasn't heard of a single production incident caused by merging problematic code—keep in mind that since AI coding became widespread, our daily code commit volume has been enormous. So in this scenario we used the most powerful model available at this stage, which both solved our problem and helped us understand how far the current models' capability boundaries have evolved. He thinks this may be the company's most cost-effective expense.

Third, costs will come down through the product. As more and more development work is done on Manus Studio—our own product—we can see from internal usage data where tokens are being wasted. As we improve the product, waste decreases and costs fall accordingly. Users will benefit from this too.

Of course, all of this stems from the team's own standards and aspirations that I mentioned earlier: "eating our own dog food" + exploring the boundaries of AI usage. We also believe costs will keep falling. The way of working that costs $10,000 a month today might only cost a few hundred dollars two years from now. And the new ways of working and organizing accumulated along the way are an even more valuable asset.

These experiments and problems have also revealed some product opportunities for us. The pitfalls we've encountered are likely ones our peers will face too.

First, the Session itself will become a work object for multi-person collaboration. In the past, one person had one task, completed it through one conversation, then moved on to the next task; now, one person raises a question, a designer proposes a solution, an engineer implements it, and a product manager continues operating it—all of this can happen within the same Session. It carries an entire piece of work, needs clearer state transitions, and may also need a better management dashboard.

Second, cross-device collaboration. We can already let one person manage multiple computers through an Agent; the next step is connecting local and cloud environments and supporting collaboration between colleagues. The goal is to let ideas flow more smoothly into output, so work can keep progressing even when you're not at your computer.

Third, Agents proactively discovering solutions. Once inside a company's systems and knowledge base, an Agent shouldn't just execute assigned tasks—it can also use existing tools, knowledge, and resources to find solutions people hadn't thought of.

These are the things Manus needs to do well next. We'll try them ourselves first, then put them in users' hands.

Back to that striking image from the beginning: an engineer handing requirements directly to AI while running a dozen tasks in parallel.

This isn't just an efficiency gain—it's a change in how organizations operate. In the past, organizations passed information through division of labor and hierarchy; how much a person could accomplish depended on how many people and resources they could mobilize. Now, we spend more effort supplying AI with context and preparing tools, then making judgments and decisions.

AI's level of completion is already very high, but "what to do" is still decided by people. We've even joked about this: since Manus can do so much, do we even need to come to the office—can we just let our respective Agents work together? Of course not. A company's key questions still need to be raised, discussed, and decided by people.

A company's atmosphere, philosophy, and trust between people come from day-to-day磨合 and shared experiences at critical moments.

So, our current takeaway is: in an AI Native organization, the role of people hasn't shrunk—it has become more focused. Define problems, judge quality, decide what's worth doing, and be accountable for the results. And one very important point: grow together with AI.

People still matter, so we're still hiring. People's abilities and value remain absolutely essential in this way of working.

As I write this, a curiosity suddenly strikes me: if I write about this topic again in six months or a year, what will our way of working look like? I don't have an answer. AI's capability boundaries are still expanding, and organizations must keep exploring how to work in concert with it.

Every company has different goals, structures, ways of working, and cultures. There may be no standard answer, and no ultimate form, for how an AI Native organization should operate. But for a company like Manus—an AI agent company—exploring how humans and AI work together is an inevitable proposition.

We will keep answering this question.

53AI, the top service provider for enterprise LLM deployment

Products: scenario implementation consulting + LLM application platform + industry solutions

Commitment: free POC validation, cooperation only after results meet the bar. Zero-risk LLM deployment, delivered to 160+ mid-to-large enterprises

Loading...

Scan to consult

Scan to log in

By logging in, you agree to the 53AI Website Terms of Service

Terms of Service

Welcome to the [53AI Official Website] (hereinafter referred to as "this website" or "we"). This Membership Service Agreement (hereinafter referred to as "this Agreement") is a legal agreement entered into between you (hereinafter referred to as "Member" or "User") and [Shenzhen Bosi Xiechuang Network Technology Co., Ltd.] regarding the registration, login, and use of this website's membership services.

Before you register or log in, please be sure to carefully read and fully understand the contents of each clause, especially the clauses that exempt or limit liability, intellectual property clauses, and dispute resolution clauses. Such clauses will be highlighted in bold for your attention. When you successfully log in to this website via WeChat Official Account authorization, SMS verification code, or other means, you are deemed to have fully understood and agreed to accept the entire contents of this Agreement.

I. Definitions

This website: refers to the website with the domain name [53ai.com] and related mobile pages, operated by [Shenzhen Bosi Xiechuang Network Technology Co., Ltd.].

Membership services: refers to the knowledge base article access, content search, and other related value-added services provided by this website to registered members.

Knowledge base content: refers to the digital content resources published on this website, including but not limited to text, charts, data, research reports, industry analyses, etc.

II. Account Registration and Login

Login methods: This website supports the following login methods, and you may choose according to your actual circumstances:

WeChat Official Account authorization login: You agree to authorize your WeChat OpenID information to this website for the purpose of creating or linking a member account.

SMS verification code login: You need to provide a real and valid mobile phone number and complete identity verification and login/registration via SMS verification code.

Account security: Your account is for your personal use only; gifting, lending, renting, transferring, or selling it is prohibited. Any losses caused by account theft or password leakage due to your improper safekeeping shall be borne by you.

Real-name authentication: In accordance with relevant laws and regulations, we may require you to complete real-name authentication for certain features. If you refuse to provide it, you may be unable to use some or all of the services.

Protection of minors: If you are under 18 years of age, please read this Agreement accompanied by your legal guardian and use this service only with the guardian's consent.

III. Service Content and Standards

Knowledge base access rights: After logging in, members have the right to browse and search relevant articles and content in this website's knowledge base online, within the scope of permissions corresponding to their membership level.

Service changes: We have the right to adjust, change, or terminate part of the service content based on business development needs, and will provide advance notice via website announcements, Official Account messages, and other means.

Prohibited conduct: When using the services, you must not engage in the following:

Using technical means to bulk crawl, download, or re-store knowledge base content;

Using knowledge base content for commercial purposes or disseminating it to third parties without authorization;

Interfering with the normal operation of this website or infringing upon the legitimate rights and interests of other users;

Publishing illegal or non-compliant information or engaging in activities that violate public order and good morals.

IV. Intellectual Property Statement

Ownership of rights: The intellectual property rights of the layout design, software code, and other content in this website's knowledge base belong to [Company Full Name] or the original rights holders, and are protected by laws such as the Copyright Law of the People's Republic of China.

Limited license: This website grants members a non-exclusive, non-transferable, non-sublicensable general license, limited to online access to knowledge base content for personal study and research purposes only.

Infringement liability: Without written permission, no organization or individual may copy, repost, excerpt, mirror, compile, or otherwise use the above content in any form. Once discovered, we reserve the right to pursue legal liability.

V. Personal Information Protection

We value the protection of your personal information. For information on how we collect, use, store, and protect your personal information, please read the Privacy Policy separately.

The information you provide through WeChat Official Account authorization or mobile phone verification will be processed by us strictly in accordance with the Personal Information Protection Law, and used only for necessary purposes such as identity verification, service provision, and security verification.

You may at any time exercise your rights to access, correct, and delete personal information and withdraw your authorization consent through website settings or by contacting customer service.

VI. Disclaimer

Content accuracy: Knowledge base content is for reference only and does not constitute professional advice. We make no express or implied warranties regarding its completeness, accuracy, or timeliness, and you should make your own judgment and bear the risks of use.

Force majeure: We shall not be liable for breach of contract for service interruptions or delays caused by force majeure such as natural disasters, changes in policies and regulations, network failures, or third-party platform interface anomalies (such as WeChat interface maintenance or carrier SMS channel failures).

Third-party links: This website may contain links to third-party websites. The content and services of such websites are not under our control, and you should assess the risks yourself.

VII. Liability for Breach of Contract

If you violate this Agreement, we have the right to take measures such as warnings, feature restrictions, service suspension, or account cancellation depending on the severity of the circumstances, and reserve the right to demand compensation for losses.

If your breach of contract causes us to suffer administrative penalties, third-party claims, or reputational damage, you shall bear full liability for compensation (including but not limited to fines, damages, attorney fees, notarization fees, etc.).

VIII. Governing Law and Dispute Resolution

The formation, execution, and interpretation of this Agreement shall be governed by the laws of mainland China.

Any dispute arising from or in connection with this Agreement shall first be resolved through friendly negotiation between the parties; if negotiation fails, either party may file a lawsuit with a people's court with jurisdiction in [Company Location].

IX. Miscellaneous

This Agreement constitutes the entire agreement between the parties regarding this service and supersedes any prior oral or written agreements.

If any clause of this Agreement is found to be invalid or unenforceable, it shall not affect the validity of the other clauses.

We have the final right to interpret this Agreement and reserve the right to modify it at any time within the scope permitted by law. The modified Agreement takes effect immediately upon publication, and continued use of the service shall be deemed acceptance of the revised content.