This replicable AI workflow enables non-technical PMs to develop products from scratch.

You think you have to know how to write code first to develop a product.

But recently, a product manager with no technical background developed an AI tool that went live and turned a profit, leaving professional engineers asking him, "How on earth did you do it?"

The protagonist is Zevi Arnovitz, a PM at Meta. He played music in high school, studied psychology, and has never written a line of code. He said:

The first time I used an AI programming tool, it felt like I suddenly had superpowers.

He really did it. He used AI to assemble a team: he assigned different AIs to be responsible for architecture, design, and error checking, and then used programming tools to make them work together. The final product, StudyMate, is now live and profitable.

His approach was to treat AI not as an assistant but as a team.

You can replicate this method too.

Zevi has made the process and the pitfalls he encountered public. We've organized it into a ready - to - use workflow: whether you use ChatGPT, Claude, Doubao, or Zhipu Qingyan, as long as you're willing to try multi - AI collaboration, you can develop a product from scratch.

Section 1 | The Starting Point Without Coding Skills: Find an AI That Can Challenge You

Zevi didn't start by writing the first line of code.

The first thing he did was to have a dedicated conversation with an AI and then said to the AI:

"You're my CTO. Don't just agree with me all the time."

This conversation would remember all the information about the entire project. He assigned a clear role to the AI: to be responsible for technical decisions, to dare to refute him, and to be accountable for product quality.

This was not about using a tool; it was about finding a partner who could challenge him.

For people without technical skills, this is the real first step.

You don't need to learn how to write code; you need to learn how to collaborate with AI. What does this collaboration rely on? Not technology, but abilities you already have: clearly stating what you want, setting rules, and constantly asking questions to turn vague ideas into clear ones.

Zevi initially chose Claude, not because it was the most powerful, but because it didn't give perfunctory responses. He called Claude "my ideal CTO": it's logical, responsive, not afraid of questions, and never impatient.

This virtual CTO told him:

• Why the function was designed incorrectly;
• Pointed out the loopholes and potential risks in the plan;
• Explained the logic behind technical decisions.

He didn't need to understand the code written by the AI. As long as he asked the AI to explain why it was written that way, what effects it was supposed to achieve, and what the side - effects were, it was like having a tutor by his side to explain the entire product logic clearly.

Don't understand the code?

Just ask the AI to explain it once, then ask again. You don't need to know how to write it; you just need to dare to ask. Gradually, the code won't be scary anymore and will become something you can understand.

So, the first step isn't to learn technology; it's to create a dialogue box with an AI.

Zevi used Claude Project, but this method isn't limited to a specific tool. The key is to find an AI that can remember the project background, work according to your rules, and communicate smoothly. To determine if a tool is suitable, ask yourself three questions:

Can it continuously remember the context?

Can you define the role and stance of the AI?

Can you clearly express your ideas in natural language?

If the answers to all these questions are yes, you've found the right one.

This is the starting point.

Section 2 | Not Using AI, but Assembling an AI Team

Creating a dialogue space is just the beginning.

Zevi's next step was to transform a single AI into an AI team.

In Cursor, he assigned clear responsibilities to each model:

• Technical Lead - Claude: Focuses on architecture, communicates smoothly, and will refute your unreliable plans.
• Bug - fixing Expert - Codex: Doesn't talk much and only focuses on fixing problems.
• Designer - Gemini: Has a creative mind, writes code freely, but produces amazing interfaces.
• Workbench - Cursor: Enables these models to collaborate on the same project.

He even defined the relationships between the AIs. It wasn't a matter of one following the other, but of giving each other feedback: after one AI finished writing code, he'd ask the other AIs to review it, and then ask the first AI to see if their comments were valid.

Why this division of labor?

Because each model has its own flaws. Claude is good at communication but its interfaces aren't very dynamic. Gemini creates amazing designs but the process is chaotic. Codex solves problems quickly but doesn't like to explain.

If you use just one of them, you'll either be held back by its weaknesses or waste time compensating for its deficiencies.

But if you know what each one is good at, you can let each model do only the 20% it's best at, rather than forcing it to complete 100%.

This division of labor was designed by Zevi using prompt words. He broke down the entire development process into reusable commands: from capturing ideas, to executing code, and then to reviewing and improving. Each stage has a clear person - in - charge, and each step can be repeated.

The core of this process isn't to make the AI write code faster, but to make the AIs cooperate better.

If the first step is to learn how to talk to an AI, this section is about learning how to make multiple AIs work together towards the same goal.

Zevi used a combination of different large models. You can mix and match according to the tools available to you. The key is to understand the characteristics of each AI: some are good at logical reasoning, some at creative expression, and some at finding problems. Identify their strengths and let them do what they're best at, and you can assemble your own team.

Section 3 | From Idea to Launch: The Birth of a Real Product

Zevi wasn't just doing a demonstration.

He really developed a live AI application: StudyMate, a learning tool that can automatically generate quiz questions.

"Users upload PDFs, and it can analyze the materials, come up with high - quality questions, and explain why the answers are correct or incorrect. Now, this product is in normal use and generating revenue."

Initially, he only planned to create multiple - choice questions. Later, through research, he found that competitors had started to offer fill - in - the - blank questions. So he decided to add this function right away.

Here's how he ran the entire process:

1. Turn a One - sentence Idea into a Task the AI Can Execute

He voiced a requirement: "I want to add a fill - in - the - blank function. It'd be great if users could drag and drop options, with two blanks and six options."

After listening, the AI started asking questions:

What's the difficulty level of these fill - in - the - blank questions? Are they for beginners or advanced users?

Should the UI style continue the current minimalist style or be more interactive?

How many points should be awarded for a correct answer? Should there be a time limit for answering?

After several rounds of conversation, the AI organized the requirements into a structured task record: the name of the function, the core requirements, the technical points, and the questions to be confirmed were all clearly written, and development could start right away.

2. Don't Write Code Yet; Understand the Problem First

After getting the task record, the next step wasn't to start writing code directly but to let the AI scan the codebase and analyze the scope of influence.

The technical assessment report provided by the AI:

• Affected modules: database, quiz engine, front - end interaction, and prompt word system
• Technical difficulties: the existing logic only supports multiple - choice questions, and the judgment rules for fill - in - the - blank questions are completely different
• Potential risks: the drag - and - drop function may conflict with mobile device adaptation

In this step, no code was written, but all the technical risk points were identified.

3. Development, Review, and Testing in One Go

Zevi asked the AI to turn the technical analysis into an execution plan and then assigned it to different AIs:

• Modify the database structure → Assign to an AI good at back - end development
• Rewrite the quiz judgment logic → Also assigned to the back - end AI
• Implement drag - and - drop interaction → Assign to an AI good at front - end development
• Full - link testing → Finally, have the bug - checking AI conduct the acceptance

After each AI finished its part, Zevi would ask the other AIs to review it: the AI that wrote the code would self - review, the other AIs would pick out flaws from their own perspectives, and then the first AI would judge if these comments were reasonable.

He said:

"I don't expect the AI to write perfect code. I just want to be able to arrange for someone to point out the problems after it's done."

After all the code passed the review, it entered the testing phase. Zevi manually tested the core process, and then asked the AI to check the edge cases: how to handle blank answers? What if the user abandons the drag - and - drop halfway? Will there be problems on mobile devices?

4. Launch and Then Review

After passing the test, the function was launched.

It took less than a week from the idea to the launch. Now, this fill - in - the - blank function is up and running in StudyMate, and real users are using it.

But Zevi didn't stop there.

After the launch, he did something that many people overlook: he asked the AI to review the entire development process.

1. Which stage was initially misunderstood?
2. Which prompt words could be written more clearly?
3. Can we be faster the next time we encounter a similar requirement?

Then he updated these experiences in the prompt word library and development documents. The next time he builds a function, it'll be smoother and faster.

This is Zevi's complete process.

It's not a demo, not a proof of concept, but a real product that's launched, has users, and can make money.

From requirements to launch, Zevi broke down the development process into verifiable small steps, let multiple AIs do their own jobs, and left records at each step. This process can be replicated, iterated, and continuously optimized.

This is the complete process of how a non - technical PM developed a product from scratch.

Section 4 | Eight Instructions, a Replicable Workflow

The most valuable aspect of Zevi isn't the product he developed, but that he turned each stage into a standard process that anyone can follow.

This isn't a theoretical methodology that just inspires you; it's a real - world tool list:

• Quickly record ideas: Without interrupting your current work, capture inspirations, bugs, and feature ideas, and automatically generate work orders
• Exploration stage: Let the AI understand the requirements and identify key problems. Don't rush to write code; think through the problems first
• Plan formulation: Break down tasks into executable steps and generate a plan document to track progress
• Plan execution: Strictly follow the steps without skipping or improvising
• Self - review: Let the AI check the code it wrote, find bugs and potential risks, and don't overlook marginal issues
• Mutual review: Have multiple models review each other, pick out flaws from different perspectives, and discover blind spots
• Document update: Record decisions and solutions so that the AI can refer to them in the next build
• Learning opportunity: Let the AI explain concepts and logic you don't understand and turn problems encountered into learning opportunities

Zevi wrote each stage as a fixed operation. You don't need to remember every detail; just tell the AI which step to execute, and it'll know what to do.

This workflow can be gradually upgraded. Start with the simplest conversational AI, figure out the process in the chat box; after getting familiar, connect to programming tools and try execution and review; if you want to go deeper, use different AIs to handle different modules; finally, assemble an AI team to complete the product collaboratively

You don't need to do everything at once. The key is to establish a work method that can be repeated: turn ad - hoc decisions into reusable processes and turn vague ideas into clear steps.

In this way, each stage can be verified, each result can be reviewed, and each process can be improved.

It's not about learning a specific tool; it's about learning to design your own work mode.

Start with a dialogue box, start with a prompt word.

Conclusion | The Gap Between "Can't" and "Can" Is Just a Workflow

Zevi's story shows that not knowing how to write code isn't an obstacle to developing a product.

The key is whether you have a replicable workflow.

From creating a dialogue box, to making multiple AIs collaborate, and then to turning the process into commands, this method doesn't rely on talent, isn't limited to a specific tool, and only requires you to take action.

Zevi spent a year finding this way.

Now, this path is right in front of you.

📮Reference Materials:

https://www.youtube.com/watch?v=1em64iUFt3U&t=1s

https://www.lennysnewsletter.com/p/the-non-technical-pms-guide-to-building-with-cursor

This article is from the WeChat official account "AI Deep Researcher". Author: AI Deep Researcher. Republished by 36Kr with authorization.