Shipping Real Apps Without Writing Code: A Non-Technical PM's Cursor and Claude Code Workflow

Zevi Arnovitz is a product manager at Meta, formerly at Wix, with no technical background at all. He did music in high school and was not in a tech unit during his army service. While travelling in Japan around the release of Sonnet 3.5, he watched a video of someone building apps with Bolt or Lovable and felt, in his words, as if someone had told him he now had superpowers.

The moment he got home he opened Bolt without unpacking and has been building ever since. He says he asked Claude to help him set the goal for the episode, and it replied that if people leave thinking he is amazing, he has failed, but if they open their computers and start building, he has succeeded.

His early workflow centred on ChatGPT and Claude projects, which compartmentalise chats with shared instructions and knowledge. Global memory kept mixing his running, product work and studies together, so projects let him keep context clean. Within a project he created a "CTO" with a prompt telling it to own the technical decisions, challenge him and not be a people pleaser.

He did this because early vibe-coding tools were eager to write code immediately, which caused gnarly bugs when changes like payments or database work needed planning first. He also tells a story of ChatGPT agreeing that the JavaScript runtime Bun was just like a state library he uses, then admitting it had assumed he was making things up and riffing along.

Zevi recommends that non-technical people start in a chatbot project, because it puts you in a conversational setting where you take time to learn instead of staring at code. For someone like him, code is the scariest thing to look at, so he frames the whole path as exposure therapy: GPT project first, then Bolt or Lovable, then Cursor in light mode, and eventually a dark-mode terminal.

He moved on from each tool only when he outgrew it. Bolt worked well until he tried to connect payments, at which point he lost control and moved to Cursor. He now uses Claude Code, which runs inside Cursor, and points out that since code is just files on a computer, a single project can move between apps and models.

Sharing his screen, Zevi shows /commands, which are reusable prompts saved in the codebase and invoked by typing a slash and the file name. His pipeline runs through create issue, exploration phase, create plan, execute plan, review, peer review and update docs. He built the backbone with his GPT-based CTO and adds a new command whenever he notices himself repeating something.

The test case is StudyMate, his weekend app that turns uploaded study material into interactive quizzes using Gemini. Having seen competitors offer true-or-false and fill-in-the-blank questions, he wants to add a drag-and-drop fill-in-the-blank format for roughly 30 percent of tests. Using Wispr Flow to dictate, he runs /create issue, answers a few quick clarifying questions, and Claude uses MCP to file a ticket in Linear with a summary, current state and expected outcome.

Days later he would pick it up with the exploration command, passing the ticket as an argument. Claude reads the Linear issue and the codebase, then returns its understanding and clarifying questions about scope, data model, UX and grading. Zevi says this back-and-forth is what separates serious building from simply going along with the vibes, and he spends a lot of time on it.

He also keeps a /learning opportunity command that tells Claude he is a technical PM in the making with mid-level engineering knowledge and asks for an 80/20 explanation. His Claude.md file, loaded into every conversation, describes the workflow and tells the agent to challenge his thinking during exploration.

The create-plan command produces a markdown file with a TLDR, critical decisions and tasks with status trackers that Claude updates as it works. Zevi found the template on Twitter. Because the plan is just a file, he can hand parts of it to different models, and it also stays in the repo as a record of what has already been done in an area.

He often uses Cursor's Composer model for simpler work because it is extremely fast, and says Gemini 3 is unbelievable at UI, so he sometimes splits a plan into backend and frontend. In the demo, Composer executes the plan within minutes, which he says would take a human engineer days. He says he no longer looks at the cost and sees it as tuition for learning.

Asked why he left Lovable and Bolt, Zevi is careful not to badmouth them and notes they move fast. His point is that the underlying models are largely the same, including the Claude models behind Bolt and Lovable. What differs is the harness: those tools add layers that take hard decisions away, such as which database to use or how sign-in works, which makes building easy but gives less control.

Claude Code, by contrast, puts the model directly into your codebase with full tools, and with that comes many decisions you must make. Lenny groups Lovable, Bolt, Replit, Base44 and v0 in the same opinionated bucket, and Zevi agrees. For him, anyone who wants cutting-edge capability and full control is better off in tools like Cursor or Claude Code.

He describes "time machine moments", such as the week he localised StudyMate from Hebrew to English in two days, built a personal site live on a domain in an hour and a half, and prepped for the podcast, all with agents running in parallel. In those moments he feels he is in the future and everything is just an API away.

Writing code is now easy, Lenny notes, and the hard part is reviewing it. Zevi manually QAs the feature first, then runs /review so Claude checks its own work. He then opens Codex and Cursor and has each review the same branch, and in the demo Claude reports a critical prompt bug along with several high and medium issues.

His peer review command then tells Claude, in effect, that it is the dev lead and that other team leads found issues in its code. Claude must not accept them at face value, because it has more context, and must either explain why a finding is wrong or fix it. He pastes in results as dev lead one and dev lead two, and repeats until no issues remain.

Zevi imagines each model as a person. Claude is the communicative, opinionated CTO; Codex is the hoodie-wearing coder who closes the door for two hours and returns with the bug fixed; Gemini is the artsy scientist whose process is terrifying to watch but whose design is excellent. Playing to strengths and covering weaknesses with other models is, for him, a game changer, and sometimes Claude gets sassy and insists a finding is by design.

Zevi says constant postmortems are critical. Early on he would keep hitting a problem until it worked and move on, but he has learned that updating documentation and tooling is one of the biggest productivity hacks. When Claude makes a serious mistake, he asks what in its system prompt or tooling caused it, then has it update those so the mistake does not recur.

He applies the same logic to success: understanding what you did and what you could have done better, and iterating on prompts to watch the responses improve, is one of the things that separates people who are merely okay with AI from people who know how to use it. His final step in each feature is updating documentation so the next change in that area goes smoothly, followed by testing and user testing.

Zevi also mentions his brother, an entrepreneur who helps seniors with technology, who learned the same way and replaced the Zapier and Airtable tools he paid for with a self-built CRM and automation system. His message is that for curious, optimistic, hardworking people this is the best time to be a builder.

For a PM at a company with hundreds of people, Zevi says the first step is making the codebase AI-native, which technical colleagues must do. His own repo has many markdown files explaining to agents how to work in each area and how the code is structured. With that in place, he thinks PMs should still avoid heavy database migrations but can ship contained UI changes, open a PR and hand it to a developer for final polish.

He expects titles and responsibilities to collapse as everyone becomes a builder, as context windows grow and models improve. For now he suggests treating it as a collaborative learning opportunity with the dev team, warning that many developers are skeptical and it will take sales work. Teams that invest in their AI workflow, he says, will be a few years ahead and glad of the weeks they spent.

Lenny raises the fear that AI makes PMs' skills atrophy and fills the world with polished slop. Zevi strongly disagrees. When colleagues said he was outsourcing his thinking, he thought it the worst way to look at it. He believes the PM's job is not to have the right answers or be the smartest in the room but to harness whatever gets users the right solution fastest.

He treats AI as a smart mentor who is always available and never judges you. But he stresses ownership: if you show something in a product review and say sorry, AI built that, it is your mistake. To reduce slop he gives the AI context on his writing style and the problem, as you would brief a junior, and runs Cursor's deslop command over code afterwards.

For junior PMs, he adds, AI lets you play at a much higher level. At Wix he never worked on company-wide marketing or onboarding strategy, but on his side product he makes all those decisions and gets reps. In his view, AI only makes you worse at your job if you are using it wrong.

Zevi says people growing up professionally with AI reach for it first. When Meta invited him to interview, he created a Claude project as a coach, fed it frameworks from Ben Erez, ran mock interviews, and built a Base44 quiz game to practise product segmentation. He used Perplexity's Comet browser to analyse a free question bank and prioritise the most-asked questions, and had Claude play the candidate to show a strong answer.

Still, he says the biggest game changer was human mock interviews arranged by cold outreach on LinkedIn, which for the very competitive Meta PM process he thinks cannot be skipped. Lenny adds that research he is preparing with Noam Segal found people also use AI to record interviews and get feedback, filling a gap because nobody tells you what you did badly.

In Failure Corner, Zevi recalls his first product review at Wix, where he worked alone for hours, hoping to wow a team of strong PMs, and failed miserably. He realised they expected him to be a 10x learner, not a 10x PM. He then picked a mentor for each colleague's strength, so his next review felt like a shared success for them as well.

He closes by calling this the best time to be a junior, because you can leave school and bootstrap a startup with friends. A curious, hardworking and kind communicator, he says, has an unfair advantage. In the lightning round he recommends The Fountainhead, Shoe Dog and Mindset, and shares the mottos "you can just do things" and his brother's "nobody knows what the fuck they're doing."