New Toys for Product Builders

Yesterday I introduced you to the concept of Vibe Coding. Today, let’s explore the tools that follow this philosophy and see how they might transform our work methods.

Let me start by sharing my practical experience. It all began when GPT first emerged, still just a chat interface at that time. I was coincidentally interested in Rust, so I casually asked a few personalized questions:

1. If you were an experienced Rust developer, what would be the best learning path?
2. What should I keep in mind when practicing TDD in Rust projects?
3. If I’m creating a Rust project from scratch, how should I organize my code? What standards should I follow?

When I got to the third question, something clicked. I suddenly had a thought: “Since it knows everything, why not just let it write code for me? I’ll just describe requirements and verify functionality.”

With this idea, I remembered a bash script I’d written before—a beancount statement import tool—and wondered if I could rewrite it in Rust. Once I had this concept, I started formulating my requirements.

The Three-Step Requirements Process

Step One: Business Requirements My original need, also known as business requirements, is typically a rough, general idea or expectation from a customer/user. For example: “I want to implement a beancount statement import tool.”

Step Two: Product Requirements Usually, product managers take business requirements and refine them through organization, filtering, evaluation, and design. After confirming with clients, they form product requirements. For example: “Which types of statements need to be imported? Alipay, WeChat, bank cards?”

Step Three: Functional Specification Next comes the detailed design phase, called the functional specification, typically written in an SRS (Software Requirements Specification) document. It includes specific functional module designs, detailed interaction flows, and testable acceptance criteria. For example: “Alipay and WeChat statement format definitions, command-line feature design, potential issues, etc.”

These three steps are all too familiar to product managers and developers.

Here’s the key question: could I use large language models to implement these three steps? Could I just state my original requirements and have it produce product requirements and detailed functional specifications?

I won’t keep you in suspense—the conclusion is that large language models do this exceptionally well. They completely understand my requirements, working diligently without complaints or objections.

But effective prompting requires some techniques. Rather than rehashing common advice found everywhere online, I’ll share some insights from my experience.

The “Three-Pronged Approach” to Prompting

• Empathy: You read that right—communicating with large language models requires empathy. Consider issues from their perspective. For instance, when discussing requirements for a beancount statement import tool, I first asked if it knew what beancount was, then evaluated its response before proceeding with my questions.
• Encouragement and Guidance: Large language models aren’t infallible and benefit from encouragement and guidance. If a response veers off track, suggest: “Don’t rush to answer; take a step back and reflect, or try thinking about this differently.” If responses improve, offer appropriate encouragement—subsequent answers will likely be even better.
• Pressure and Urgency: For challenging issues, consider conveying your pressure to the model. For example: “I’m in serious trouble. If I don’t solve this today, I might lose my job. You’re my only hope. My problem is: xxx. Please do everything possible to help me.” Once, I told a model: “I need to demonstrate functionality to my boss tomorrow, but I’m stuck on command-line parameter parsing. You must save me!” In response, it not only provided code but also optimized error handling.

Today’s language models are increasingly intelligent, making these prompting techniques less crucial than before. Nevertheless, these three approaches might help you in critical situations.

Thinking more deeply, the effectiveness of this “three-pronged approach” likely stems from the fact that the training data for large language models comes from humans themselves.

The “three-step” requirements process and the “three-pronged approach” to prompting form the foundation for using “Vibe Coding” tools.

Tool Categories

Semi-Automated

Semi-automated approaches combine requirement descriptions with manual coding, suitable for developers with coding experience. These tools typically use IDE+AI assistance, such as GitHub’s Copilot, Cursor, Windsurf, and Cline.

Among these, Cursor offers the strongest capabilities, supporting code indexing and rule definitions at both global and project levels.

When starting a project from scratch, I recommend organizing project documentation as follows:

• Create a docs folder in the project root directory
• Create an introductory document intro.md: basic project introduction
• Create a product requirements document PRD.md: generated by the AI based on basic project information
• Create a functional requirements specification SRS.md: generated by the AI based on PRD.md
• Create a technical design document tech-design.md: generated by the AI based on the three previous files

Of these four files, only intro.md requires manual writing; the AI generates the others, which humans then verify and modify.

The directory structure looks like this:

docs/
├── intro.md
├── PRD.md
├── SRS.md
└── tech-design.md

At this point, the manual work is essentially complete. The next step is to open a chat window, select Agent mode, and direct the AI using the three-pronged prompting approach discussed earlier.

The new version of Cursor supports defining multiple project rules. You might try using these files as rules, incorporating them into context before asking questions.

Fully Automated + Manual Debugging

Fully automated modes particularly suit product managers. Whether you have detailed product requirements or just a one-sentence need, these tools can build your project. Currently, such products follow two technical approaches:

1. Multi-role mode: Simulating real development teams, where agents replace roles like project managers, product managers, developers, and testers.
2. Single-role mode: One agent handles all responsibilities.

Various tools cater to these approaches:

Multi-role mode:

• MGX: A multi-agent AI platform designed to simulate real software development team workflows.
• CrewAI: A multi-agent AI platform focused on building and deploying automated workflows.
• CodeGPT: An AI agent platform specializing in software development, offering various tools to enhance development efficiency.
• Relevance AI MAS Builder: A no-code multi-agent system builder allowing users to create AI roles for automating collaborative tasks.

I’ve used both MGX and CrewAI. MGX is the commercialized version of MetaGTP[5], developed by a Chinese team. The free version has daily usage limits, allowing you to experience product features and development processes, but requires payment for complete MVP development.

Single-role mode:

• Replit: Supports multiple programming languages with real-time collaboration and AI assistance. Its Replit Agent allows users to generate code through natural language descriptions, ideal for learning, prototyping, and small-scale projects.
• Bolt: An AI-driven online development tool by StackBlitz, focusing on full-stack web application development.
• Lovable: An AI-driven application builder focusing on generating web applications from natural language descriptions.
• Codeium: An AI-driven coding assistant primarily integrated into IDEs, but also offering its own IDE, Windsurf.
• Bubble: A no-code platform with AI capabilities, particularly suitable for non-technical users building web applications.

I tested both Replit and Bolt, creating a web management service for the restic backup tool—essentially an MVP version. Here are screenshots of projects generated by both products:

• The Replit-generated project features clickable top-level menus, local deployment capability, mock data, but no backend logic implementation. Overall generation is quite fast, about 10 minutes, though the code structure appears somewhat scattered.

  

• The Bolt-generated project has clickable main menu pages with mock data but no backend logic implementation. The interface design is more modern.

  

Conclusion

The conditions for AI-assisted programming and Vibe Coding have matured. From the popular Cursor to the startup Bolt, these new toys are reshaping our work methods.

As a product manager, you can quickly validate ideas; as a developer, you can have AI write 80% of your code, leaving the remaining 20% for coffee breaks and debugging. (The new version of Cursor even added a sound notification feature when an agent completes a task—it “dings” to remind you when you’re enjoying your coffee, combining efficiency with ritual.)

In the future, the development paradigm will shift from “team co-creation” to “human-machine co-creation.” Are you ready? Why not start today by picking a tool and trying it out? After all, technology won’t wait, and the disruption has already begun.

👇Scan the QR code with WeChat to follow “91WiseRead” for daily updates and growth together.

👇Welcome to add me as a WeChat friend to discuss growth stories together.