- Browser builders such as v0 and Replit lead from a description to a working app with publishing.
- Cursor and Claude Code work on your repository: they read code, plan changes and perform them.
- The choice depends on whether you start from scratch or extend existing code, and who will maintain it.
There are so many tools for building apps with AI that it is easy to get lost. Under various names two clearly different approaches hide: browser-based builders that create a working app from a description, and coding agents that work on code in an editor or terminal. This text compares four example tools based on their own documentation and does not judge the quality of generated code, because that depends on the task and changes with every model version.
Two families of tools
v0 describes itself as an AI agent that helps create real code and full-stack apps. From a single prompt you can add features, refine a design and create live prototypes, then deploy to production or open a pull request for review. The documentation also lists a GitHub integration, a design mode and one-click deployments on Vercel’s infrastructure. Replit leads the user from a conversation with an agent to a published site: the basic path is describing an idea, designing the site and publishing, and beyond that the documentation shows non-programming uses too, such as data analysis or preparing a report.
Cursor presents itself as a coding agent for building ambitious software: it helps understand a codebase, plan and build features, fix bugs and review changes, and additionally offers rules, MCP servers, subagents and cloud agents. Claude Code works in a terminal, VS Code and JetBrains extensions, a desktop app and in a browser; it reads code, edits files and runs commands. I describe the details of its work in the article on coding agents.
| v0 | Replit | Cursor | Claude Code | |
|---|---|---|---|---|
| Family | Browser builder | Browser builder and agent | Coding agent in an editor | Coding agent in a terminal and IDE |
| Starting point | A description or a mockup | A conversation with an agent | An existing repository | An existing repository |
| Publishing | One-click deployment or a pull request | Publishing a site from the tool | Through your own deployment process | Through your own deployment process |
| For whom | Fast prototypes and interfaces | An idea to a working site | Developers extending code | Developers and teams with a terminal |
| Extras | GitHub, databases, MCP | Integrations with tools | Rules, MCP, subagents, cloud | CLAUDE.md, hooks, subagents, MCP |
How to choose
Start with the question of the starting point. If you have no code and want to see a working prototype within an hour, a browser builder is the shortest route, and you can still review the code later. If you have a repository and want to extend it while keeping tests, review and change history, work in an agent that operates on that repository. The second question concerns maintenance: a prototype generated in a tool you do not understand will be hard to fix in half a year. The third concerns the team: when several people work on the code, a shared review process is needed, so a pull request and configuration in the repository outweigh one-off generation.
- 01GoalA prototype for show or a product to maintain?
- 02Starting pointFrom scratch or existing code?
- 03ToolA builder or an agent on a repository.
- 04CodeCan you see it and export it?
- 05ReviewA pull request and tests before deployment.
- 06MaintenanceWho will fix it in half a year?
Three example situations
An entrepreneur wants to check over a weekend whether anyone will sign up for a waiting list for a service. They need a page with a form, not a system, so a browser builder is enough and the code is secondary. A developer extends an existing application and wants to speed up refactoring and tests: she needs an agent working in the repository, with change review and team configuration. A team wants to automate small fixes and ticket review: it combines an agent in the repository with rules and MCP servers, and uses a builder only for mockups. In each of these situations the selection criterion is not a ranking of tools but who will maintain the result and for how long.
Pitfalls common to all
Whatever the tool, the same risks recur. Generated code can contain security flaws, such as keys in client code or missing authorization, so review it before deployment; I develop this theme in the AI code security hub. Dependencies added by the tool are somebody else’s code that also needs checking. User data needs separate attention: do not enter real data into a prototype without understanding where it is stored. And finally cost: many tools bill usage in credits or tokens, so check the price list before starting a project at scale. A practical scenario for a first prototype is in the article A prototype in one evening.
Last checked: 20 October 2026. Descriptions come from the tools’ documentation of that day; features and prices change quickly.