Manus's Zhang Tao: Using Mono to Let One Person Complete Full-Stack Development

Series explainer: Manus co-founder Zhang Tao on "Using Manus to transform Manus: practices and reflections on transforming an AI-native organization"

01 - R&D: AI is not just an assistant; it can also run the entire process

Manus-mono: giving AI a full-stack map The common pain point for traditional product and R&D teams is generally that people are not aligned during front-end and back-end joint debugging, not coding itself. Mono does not merge multiple repositories into one large repository; instead, it creates a unified entry point plus a manual for AI to read, so that one person, carrying the same agent context, can complete front-end, back-end, and mobile development all the way through; approvals still remain with humans.

Where things used to get stuck Requirements review → front-end and back-end write separately → joint debugging → testing and launch. The biggest loss is in joint debugging: both sides interpret the requirements separately and then agree on interfaces; once interpretations diverge, repeated changes follow. Manus wanted to blur the division of labor (one person thoroughly understands the requirements and then pushes each client) but code was scattered across multiple repositories, so AI still could not see the whole picture.

What Mono is A unified entry point, with the manual clearly stating: the responsibilities of each repository, how they cooperate, and R&D standards. Whichever part needs changing, pull the corresponding repository. The article emphasizes that it grew step by step, with each step solving the bottleneck of the previous one: 1. See the whole picture: supplement business knowledge and enable cross-repository collaboration; Git worktree supports parallelism. 2. Local verification: the complete Manus can run locally, and verification goes from waiting 5–10 minutes for a test environment to a few seconds. 3. Check production: read logs, configurations, and exceptions within permissions. 4. Go through release: fill in operational capabilities for steps that easily get stuck; approval authority still remains with humans. 5. End-to-end verification: test accounts go through real flows, and results are viewed in browsers and mobile simulators.

The more people use it, the more knowledge there is. Operations engineers disliked always being called to do releases, so they wrote the release process into Mono; one person saves effort, and the whole company gets a bit faster. The consensus became: for one requirement, one person can write all clients. Example: 7 people on mobile support 2 products and 4 apps, with progress basically in sync with the web version.

Mono effect comparison: the entire codebase shares one agent Without Mono: each requirement takes about 5 people + 5 agents (product, design, front-end, back-end, and mobile each with independent contexts), and output then relies on manual handoff across teams; the process is requirements → design → development → integration → testing → operations release, with many stages.

With Mono: each requirement takes about 1 builder + 1 agent with shared context. The Mono vertical bar lists the repository map, development standards, interface standards, release process, and production debugging, and notes "written and used by the whole team." The process is compressed into: submit requirement → full-stack build → local verification → launch after approval.

Why it could be pushed forward at Manus Zhang Tao attributes it to three points: they were already exploring the boundaries of AI; they could not stand repetitive work and things AI could already do still being done manually; and the organization is flat enough that decisions from top to bottom can be rolled out quickly.