A veteran Builder's personal account: How I leveraged the multi-Agent development workflow to build an MVP in one week and go online within a month.
As Vibe Coding continuously lowers the threshold of software development, the vision of "everyone being a developer" is evolving from a slogan into a practically achievable possibility: people without a complete engineering background can also build product prototypes with the help of AI; independent developers can schedule multiple models and Agents at the same time, compressing work that used to require a full team into the workload of a single person.
However, as coding becomes increasingly accessible, the issues that truly determine the success or failure of a product have become more prominent: How to identify real demands that users are willing to pay for? How to turn an idea into a minimum viable product quickly? Faced with different models and Agents, how should developers make selections, transmit context and control costs? Does the fact that one person can complete development, operation and promotion with AI really mean that the organizational form of traditional companies will be replaced? In the WAIC 2026 InfoQ media live stream room, we had a series of discussions on these topics with veteran Builder Shougongchuan.
Shougongchuan has been building various products continuously since he graduated from university in 2020, releasing them on his brand website lovstudio.ai, and he is currently promoting YODA, an open-source product for developers. Unlike many people who transition from software engineering to AI Coding, he majored in finance during his undergraduate years, then taught himself computer science due to the needs of data analysis and crawling in investment banking, and finally switched to full-time development. Since October 2024, he has delegated almost all his coding work to AI, following the principle of "99% AI + 1% direction setting".
In his view, AI is indeed making software development a more universal basic capability, but "being able to write code" does not mean everyone will become a professional developer, nor does it mean that anyone can create a commercial product that people will use and pay for simply by learning to call models. Compared with technical skills, demand insight, product judgment, communication competence and personal positioning are becoming more critical dividing lines for Builders.
Transitioning from finance to computer science, until 99% of code is generated by AI
Shougongchuan majored in finance for his undergraduate studies. His first exposure to programming was not because he planned to become a software engineer, but because financial work itself required processing massive amounts of data.
During his investment banking internship, in addition to completing traditional industry research and financial analysis, seniors and mentors also expected interns to master technical capabilities such as data analysis and data crawling. To finish these tasks, he started to teach himself computer science. Around 2017, he gradually found computer science more interesting than finance, so he began in-depth research and finally fully switched to the computer field. In the following years, he spent almost every day thinking about how to write better code.
When generative AI started to enter the programming field, he did not immediately delegate development work to models. Especially in 2023 and the first half of 2024, he believed there was still a clear gap between AI-generated code and his own goals and quality requirements. Models could generate code snippets and complete functions, but they could hardly stably develop a full product, and the generated results often required a lot of rework from developers.
The real turning point came at the end of 2024. With the popularity of Cursor based on models such as Claude Sonnet 3.5, he began to systematically test AI programming tools. The test results made him realize that the quality of model-generated code has crossed a critical threshold: AI is no longer just a completion tool that improves input speed, but a developer that can undertake most practical coding tasks.
Since October 2024, he has gradually stopped writing code manually. For nearly two years, AI has completed the coding of almost all his projects. "Strictly speaking, it is not 100%, but at least 99% of the code has been delegated to models and Agents, and humans only need to be responsible for the 1% at the very beginning and the very end."
This does not mean that technical foundations have lost their value. On the contrary, Shougongchuan believes that the reason why he can adopt Vibe Coding so aggressively is that he has accumulated sufficient software development experience before. He can judge whether the code generated by AI is reasonable, locate the root cause when problems occur, and supplement capabilities for stability, concurrency, testing and maintenance through engineering means after the minimum viable product runs successfully.
For people with no coding experience at all, AI can significantly lower the entry threshold, but it cannot automatically make up for all engineering judgments. What ordinary users need to learn first is not necessarily a certain programming language, but how to accurately express demands, how to communicate with AI, and how to judge whether the model has really completed the task.
Shougongchuan believes that many successful AI products seem to be created by "people who do not understand code", but there is usually still a person behind them who can master AI and understand the boundaries of products and technologies. Even if you do not write code manually, you should at least know how to organize models to complete development.
Real demands do not need to be "chased": People who love life are more likely to create mass-oriented products
"How to find real demands" is a problem that almost all independent developers have to face. Shougongchuan's view is that people who cannot write code may be closer to real mass demands.
The reason is that programmers deal with code, frameworks, databases and development tools every day, and the problems they can think of are often problems of programmers themselves. But programmers usually have strong hands-on abilities: when encountering problems, they will directly write a script or plug-in, and are rarely willing to pay for similar tools. A demand that only serves programmers, even if technically exquisite, may not have a large enough commercial market.
People who cannot write code are closer to real daily life. They will think about where to travel, how to take photos, how to cook, how to organize work, and how to make daily life more convenient. These problems do not seem sufficiently "technical", but may have a larger user group.
Shougongchuan believes that demands do not necessarily need to be deliberately "chased" through research. As long as a person lives earnestly and keeps thinking about how to improve his own life, real demands will emerge naturally. The real difficulty is how to turn the demand into a product after it appears.
For example, he recently used YODA to create a video shooting tool in a very short time. Users can prepare manuscripts in advance. When recording facing the camera, the system will recognize which sentence the user is saying in real time and align the subtitles automatically (existing tools usually scroll the teleprompter at a fixed speed). After the recording is completed, users can directly get a video with matched subtitles, without spending a lot of time adjusting manually.
Shougongchuan showed the product to a friend who often conducts interviews, and the friend said on the spot: "I will transfer 100 yuan to you right now, please launch it as soon as possible." In his opinion, this kind of reaction that users are willing to pay immediately after seeing the product, without the need to explain its commercial value, is a real demand.
Similar product cases are not rare. The popularity of Miaoya Camera also follows this logic: users only need to upload one photo to generate portraits in different styles. The implementation of the "Kitten Fill Light" product is not difficult, but technology alone is not enough, because the idea came from the founder's girlfriend.
Therefore, products do not need to pursue overly complex technologies. Whoever can accurately hit the pain points of daily life in a specific period may quickly gain a large number of users. Breaking away from grand technical narratives, solving even trivial problems, as long as the problems are specific, real, and users know exactly why they need the product, users will be willing to pay for the saved time and energy.
Shougongchuan sums up his demand discovery method in one sentence: "People who love life are more likely to discover mass demands." After AI lowers the implementation threshold, the scarcest resource is no longer just development capabilities, but the ability to enter real scenarios and observe how ordinary people live.
Deliver a 59-point version first: Build MVP in one week, launch a stable version in one month
When it comes to product implementation, Shougongchuan tends to adopt progressive Vibe Coding, rather than completing a huge and rigorous product design before starting development.
He usually puts forward a specific demand to AI first, and lets the model implement it directly. After problems occur, he tells the model "there is a problem here, fix it"; if he wants to avoid similar errors from recurring, he adds constraints to require the model not to adopt the same solution in the future.
The goal of this development method is not to generate a commercial-level product on the first attempt, but to see a runnable version as soon as possible. For Shougongchuan, it is completely acceptable for AI to deliver a "59-point" product first. As long as the general direction is valid, he can decide whether to continue investing according to the actual effect.
The biggest advantage of this method is fast feedback. Many ideas seem valid on paper, but may not be valuable after the prototype is actually made. If you spend a lot of time on architecture design, technology selection and complete testing from the very beginning, you may find after a month that users do not need this product at all. With the help of AI, developers can verify ideas at extremely low cost first: stop in time if the prototype has no value; gradually supplement software engineering capabilities if users respond positively.
Shougongchuan roughly divides product development into two layers: the first layer is the minimum viable product, namely MVP. The core goal of this stage is to verify whether the function can run smoothly and whether the demand is real; the second layer is to add high-concurrency capabilities, automated testing, exception handling and stability design, so that the product can gradually meet production requirements.
For ordinary users with no engineering experience at all, they may prefer AI to directly deliver a "silver bullet" solution: input one sentence of demand, and the model completes demand decomposition, architecture design, coding, testing and deployment. This method is not infeasible, but the development speed may be slower, as the model needs to make more complete plans in the early stage.
For developers who can understand code and take responsibility for the final result, prioritizing speed before stability is usually the most efficient. If the product has extremely high requirements for quality and accuracy, it is more suitable to adopt specification-driven or test-driven methods. Developers first write the demand into detailed specifications, or let AI generate a large number of tests first, and then implement functions according to the test requirements.
The final paradigm to be adopted depends on the user's technical capabilities, product stage and risk requirements.
In terms of technology stack, Shougongchuan usually does not re-select technologies for each project, but prioritizes using familiar combinations: he prefers React for front-end development, Python for back-end development, shadcn/ui for the interface, and usually selects PostgreSQL or Supabase as the database. He even gives Supabase permissions to AI through MCP, allowing Agents to operate the database directly.
This choice also comes from ROI consideration. For Builders who need to see product effects quickly, the benefit of repeatedly evaluating dozens of frameworks is not high. A familiar technology stack is convenient for AI to generate code, and also easy for subsequent manual understanding and maintenance.
However, if there are mature similar frameworks on the market, he will not insist on developing from scratch, but use a Skill called "Solution Architect". This Skill will first search for relevant open-source projects on GitHub to judge whether there is an architecture that can be directly reused. If there is, he will prioritize developing based on the existing solution; after the project goes deeper, he will let AI gradually migrate the code to his more familiar framework. This way, he can not only use mature projects to start quickly, but also avoid long-term maintenance of a completely unfamiliar technical system.
In his view, as model capabilities become stronger and stronger, Harness will keep getting thinner. Developers do not need to tell AI all architecture details in advance. What really needs to be explicitly stated is the information that has not been internalized by the model, such as enterprise red lines, compliance requirements, prohibited operations, and personal special preferences.
He borrows the "Johari Window" to summarize the principle of collaboration between humans and AI: developers need to judge what they know AI knows, what AI does not know, what they do not know AI knows, and what AI does not know. When a developer's understanding of a certain problem is significantly better than AI's, he should guide the model actively and clearly; when the developer is not familiar with the relevant field, he should maintain a certain degree of ambiguity, let AI propose solutions and guide humans to complete exploration.
Following this method, he can usually deliver an MVP within a week, and launch a relatively stable product in about a month. If he only refers to existing products, replaces APIs, modifies the interface and adapts to new company demands, a single person can complete the whole process in one week to one month.
However, the shortening of development time does not mean the disappearance of work. Most of Shougongchuan's energy is spent on debugging. AI generates code quickly, but verifying functions, locating exceptions, handling edge cases and optimizing product experience take up most of his time.
The difficulty of multi-Agent collaboration is not the model, but the context flow
During the development period, Shougongchuan will not assign all tasks to the same model, but divide the work according to the characteristics of different models:
When writing articles, he tends to use Claude Code, because Claude performs better in divergence, language understanding and understanding of human intentions;
When encountering particularly difficult code bugs, he will call the most powerful model in the GPT series, adjust the thinking depth to the highest, and let the model conduct more sufficient reasoning;
For Chinese, poetry and China-specific scenarios, he prioritizes domestic models. Taking DeepSeek as an example, its early models invested a lot in Chinese language and cultural content, and performed better than overseas models in some Chinese tasks.
When acquiring the latest overseas information, Grok is more suitable for processing news and social media content because it can access real-time data on X. This capability can also be partially replaced by crawlers and plugins, but the experience is still different when the model has direct data access.
Shougongchuan uses multiple Agents at the same time, and additionally configures one or two transit services that can access different models. When tasks need to generate images or call specific models, he completes the operation through the transit platform. He believes that the biggest difficulty of multi-Agent collaboration is how the context flows between different tools.
If one Agent completes half of the task and then hands it over to another Agent to continue, the latter must obtain the full context of the previous work. Taking Codex App as an example, users can copy the deep link of a certain task, and then send the link to another session to let it continue based on the original task. Therefore, if different Agents are responsible for different functions of the same product, a shared context needs to be established.
One method is to use files such as Agent.md in the project directory, write the project goals, rules and architecture into it, and let all Agents read it together. Another method is to store information in databases, caches, memory or README files to form a file-level or data-level public storage. This is a bit like inter-process communication in software systems: the problem is not whether a certain Agent is smart enough, but whether it can obtain correct, complete and non-redundant information.
Similar problems exist between different sessions. Users can ask AI to search past chat records and continue working based on a certain conversation. As long as the Agent knows the local storage location of tools such as Codex and Claude, it may read the historical records. But if important information only exists in a certain conversation and does not form a project file or long-term memory, it may still be lost after switching sessions.
Shougongchuan's suggestion for this is that you can precipitate the processing procedures of solved problems that will recur in the future into Skills. The next time you encounter a similar task, the Agent will know how to find information, call tools and complete the processing.
But he reminds that not all errors are suitable to be written into Skills. If the model finally finds a solution after making a mistake, the process can be precipitated; if the problem is still not solved in the end, it means that the original path may be wrong. At this time, you should change your thinking instead of solidifying the wrong process.
Even if the rules have been written into the Skill or the "Agent.md" file of the project, the model may still not comply with them, which is called "context rot": when the context carries too much information, or all rules are marked as important, the model cannot judge the real priority. Therefore, the AI development environment not only needs to add context, but also needs to be able to manage, trim and debug context.
Put different Agents such as Codex and Claude Code into the same workstation
As a builder, Shougongchuan also converted the problems he encountered in development and relevant experience into a product, which is YODA.
YODA originally came from a very direct demand: Shougongchuan found that almost all heavy developers around him do not only use one Agent. Many people use Codex and Claude Code at the same time, and also add Gemini, Grok or Kimi. He judged that in the next one to two years, using multiple Agents at the same time will remain the norm. In that case, developers need a unified entrance, where they can switch Agents freely in the same product, instead of constantly opening different tools, copying files and transferring context. Based on this idea, he found an open-source tool and carried out secondary development on its basis.
The second core capability of YODA comes from the working mode of independent developers who need to manage multiple