Vibe Coding With Cursor and Windsurf: Berman’s 2025 Workflow

In this March 2025 tutorial, Matthew Berman shares lessons from roughly 100 to 150 hours of “vibe coding”: giving coding agents broad instructions and having them implement applications. He uses Cursor and Windsurf, stresses that the workflow has limitations, and describes how clearer specifications, project rules, tests and version control helped him work through them.

His setup at the time relied mainly on Claude 3.7 Sonnet, often with extended thinking, and sometimes used Grok 3 to draft specifications. Anthropic released Claude 3.7 in February 2025 and [retired it from the Claude API in February 2026](https://docs.anthropic.com/en/docs/about-claude/model-deprecations). Model availability, editor menus and provider settings in the video are historical, so check current product documentation.

Berman shows the 2025 model-selection interface and a custom OpenAI-compatible provider endpoint. He recommends choosing models that support the tools and function-calling behavior required by the agent. API credentials should be kept private, and present-day provider support and configuration may differ from the interface shown.

Before asking an agent to implement a project, Berman recommends writing a detailed specification. In his example he asks another model to draft a Twitter-like application with a Python backend, then reviews the proposed behavior, database schema and endpoints. He advises revising the specification to reflect what the user actually wants before passing it to the coding agent.

Project rules express recurring constraints: preferred technologies, conventions and workflows. Berman found them useful when an agent attempted to fix a SQL problem by silently switching to a JSON file, making the application appear to work while bypassing the intended database. Explicit constraints can help the agent distinguish a repair from an unwanted architectural change.

Cursor project rules in the example live in `.cursor/rules` as `.mdc` files, separate from user-wide settings. Berman manually attaches some rules because he is unsure which load automatically. [Current Cursor documentation](https://docs.cursor.com/context/rules-for-ai) distinguishes always-applied, automatically attached, agent-requested and manual rules; activation depends on configuration.

The video includes a sponsored segment for Mammouth, which Berman describes as a service offering access to multiple AI models. His quoted $10 monthly price and model list are 2025 promotional claims, not a guarantee of current pricing, model availability or plan limits.

His coding-pattern rules ask the agent to prefer simple solutions, look for existing functionality before adding duplicates and keep the code organized. He explains that agents sometimes wrote a second implementation instead of fixing one already present. He also asks that changes stay within the scope of the requested work and avoid introducing a new technology before trying the existing approach.

A separate rule calls for development, test and production environments to remain distinct. Berman encountered tests affecting development data and production code pointing at local resources. Making environment boundaries explicit helps the agent understand where each configuration and database belongs, though instructions alone do not enforce isolation.

Berman asks the agent not to leave behind unnecessary one-off scripts and suggests considering refactoring when files reach 200–300 lines. He acknowledges that this length is not a universal software rule; the useful goal is maintainability, not splitting code mechanically or risking breakage solely to meet a line count.

He also tells the agent to keep mock or stub data out of development and production behavior. One failure he saw was a scraper silently falling back to fake data after a real request failed, hiding the problem. He reserves mocks for tests and adds a rule against overwriting his `.env` file after having to replace lost keys.

A stack rule records his preference for Python on the backend, HTML and JavaScript on the frontend, SQL rather than JSON file storage, separate environment databases, hosted Elasticsearch and Python tests. These are choices for his project, not requirements for all applications. Writing them down makes accidental technology changes easier to spot.

His workflow rules repeat the need to focus on the task, test major behavior and avoid changing a working architecture without instruction. He asks the agent to consider other areas affected by a change. Berman then pastes a reviewed application specification into a new agent chat as a starting point.

Long conversations accumulate context, and Berman finds that performance can deteriorate as the chat grows. Starting a new conversation can help, but loses information unless relevant details are carried forward. He reattaches his workflow, stack and coding rules and recommends experimenting to find when a fresh chat is useful.

He recommends narrow requests and frequent testing. He favors end-to-end tests that exercise behavior as a user would, but unit and integration tests can also be useful for different failure modes. A passing test is not enough if the agent changed the test or production behavior incorrectly; inspect what was changed and try the application yourself.

Berman favors well-documented, popular technologies because he expects agents to have more material to work from. His example prompt asks for a maximum tag length of 20 characters, asks the agent to check for existing code and requests tests. The agent lists directories, reads files and searches before explaining and making changes.

The 2025 editor offered different levels of command approval. Berman says he used an automatic “YOLO” mode for experiments, but warns that unrestricted execution can push code or deploy to production. Approval settings, isolated environments and review matter even for a new project because agents can still affect connected services or credentials.

The agent runs tests, investigates a failure and returns a summary; Berman notices mock-repository changes that illustrate why he reinforced his environment rules. He reviews the outcome rather than treating the agent’s summary as proof. He also uses new chats when accumulated context becomes unwieldy.

Berman says he sometimes asks the agent to commit changes and deploy to Heroku. In his experience an iteration could take two to fifteen minutes, including running and fixing tests. He suggests using separate branches or editor windows for parallel work, then merging carefully; that timing is an anecdote from his 2025 setup.

He occasionally requests low-risk refactoring of long files and switches between thinking and non-thinking modes. As his project grew, however, even small changes sometimes required many iterations. He thinks the rules and practices would have helped him get further had he established them earlier.

Berman describes an asynchronous rhythm: give an agent a task, do something else, then return to review the result and iterate. He wishes for a fully hosted phone interface that would make this easier while away from his computer. That is a 2025 product wish, not a statement about what is available now.

His final practical advice is to commit often, so there are recoverable checkpoints when a change goes wrong. He also shows the editor’s chat checkpoint feature. Git history and editor checkpoints have different scopes, so users should understand what a restore will change before using it.

After his 100–150 hours of experiments, Berman concludes that agents lower the barrier to building software and encourages viewers to try. He expects the tools to improve, while his own examples show the continuing need to specify goals, inspect changes, test behavior and control deployment.