Search the phrase “AI coding tools vs AI prototyping tools” and the roundups split the category by audience (engineers vs designers) or by interface (chatbot vs no-code builder). Both splits hide what matters to the PM searching the phrase: whether the output ships on the codebase the team is already running, or somewhere else.
Else lets PMs and designers prototype and test inside their actual product, then hand engineering a PR they merge, not rebuild.
The two named buckets
Two pieces of AI tooling have public names in 2026.
AI coding tools are agentic engineering. Karpathy named it at Sequoia Ascent: “you are not writing code 99% of the time, you are orchestrating agents.” Cursor, Claude Code, Windsurf, Copilot, Codex – the engineer opens a prompt, the agent writes against the existing codebase, the engineer reviews and ships. The tool assumes engineer-grade fluency at the terminal and engineer-grade judgment on the diff. The output lands in the repo the team already maintains.
AI design tools are the designer-side shift. Figma Make, Google Stitch, Magic Patterns. A sketch becomes a screen in an afternoon. The output is a visual artifact in the designer’s own surface, ready for review and handoff. The designer never leaves the design environment.
Both buckets stay inside one role. The engineer using Cursor is producing code an engineer will ship. The designer using Figma Make is producing artifacts a designer will hand forward. The artifact lives in the surface its creator already works in — repo, design file.
The third bucket has two flavors most search results merge
The tools branded as “AI prototyping” are not one category. They are two, and the difference is between a prototype that ships and a prototype the team throws away.
Greenfield AI prototyping tools – Lovable, v0, Bolt, Replit Agent were built for 0 to 1. The starting state is a blank canvas. The tool generates a standalone application that looks like a product. Used for what they were built for, they are good at it: spinning up a new app, mocking a flow that does not exist yet, putting something in front of a customer to test a concept that has not been committed to a roadmap.
Brownfield AI prototyping tools – Else, Alloy, Builder.io – were built for prototyping on top of an existing product. They read the real codebase. The components are the ones the product already ships. The data, in some cases, is the data the product already has. The output is a change to a product that already exists, not a new product invented from scratch.
The two flavors look similar at the surface – both call themselves AI prototyping – and they are pointed at different jobs. A PM on a roadmap that already has paying customers does not need a tool that draws a new screen from a blank canvas. They need a tool that tests a change inside the product they already run.
Why the PM gets handed the wrong tool
The PM at a real company has an actual product, an engineering team, and a customer base. The PM did not pick the tool category. The trending tools are usually a greenfield prototyping tool as they capture everyone, not just people that already have a product.
A PM at a Fortune 500 enterprise tech company described what happens after that pick: “the limitation with Lovable is that you have to recreate your design system every time. So, we have a design system that we’ve built out, and every time a designer uses Lovable, they have to recreate that design system in Lovable.” The first hour of the prototype is not a prototype of the feature. It is a prototype of a design system the engineering team already maintains.
A PM at a mid-market platform put it another way: “I’ve used Replit, but it’s kind of imaginary. It’s not real. I can give it background and context on what I’m trying to do, but ultimately, it’s not my product.”
Both PMs hit the same wall. The tool generates something that looks like the product and is not the product. For a PM defending two weeks of work to engineering and a CEO, the distance between “looks like” and “is” is the difference between a prototype that ships and a prototype the team abandons.
The fix is not better prompts inside the greenfield tool. The fix is being in the right bucket.
Agentic prototyping: what the third bucket is doing
Agentic engineering, as Karpathy framed it, is an engineer orchestrating an agent that writes code against the existing repo. PMs are running the same loop on the same kind of repo: they use an agent to write code on top of their own codebase, review the diff, and open the pull request. Engineering reviews and merges.
That is what brownfield AI prototyping does. The agent writes against the real frontend repo. The PM reviews the diff. The output is a pull request, not a Loom video and a Figma reference. Engineering receives an artifact in the form they already review and ship.
Call it agentic prototyping. The shape of the work is parallel to agentic engineering and to the AI design shift: an agent producing artifacts in the surface the team already lives in, a human reviewing the artifact, the output shipping without a rebuild step in between.
Where each tool fits
A PM picking a tool is picking which bucket they are operating in.
If the job is testing a concept that does not exist yet – a new feature that has no product to live inside, a side experiment, a fresh idea before it is on the roadmap – the greenfield bucket is fine. Lovable, v0, Bolt, Replit Agent are all good at what they were built for. The output is a standalone artifact, the conversation is whether the concept is worth roadmap commitment, the prototype is not expected to ship.
If the job is shipping work against an existing codebase that already has engineers, customers, and a design system in place, the greenfield bucket is the wrong bucket. The brownfield is the bucket. Else reads the existing product, inherits the design system and components, and opens a pull request engineering reviews and merges. Alloy and Builder.io are in the same bucket with different specific cuts.
If the job is the engineer’s job – refactor the existing codebase, ship a feature the engineering team committed to – AI coding tools are the right tools. Cursor, Claude Code, Windsurf, Copilot. The PM does not belong in this bucket. Asking a PM to ship a feature through Cursor is asking the PM to do the engineer’s job with the engineer’s tools.
What the resolution looks like on a real team
Drew Muller is the Director of Product Management at Ferry International. He runs a lean team with no embedded designer, and he tested more AI prototyping tools than anyone else across late 2025 and early 2026. He stayed in the greenfield bucket for visual flows – courses, learning paths, things that work cleanly without real data – and used Figma Make and Magic Patterns there. He moved to brownfield prototyping for the business tools that need to behave like the real product. Two pull requests through Else, both reviewed by engineering and merged.
The split is which bucket fits the job. A team running cleanly will use tools from more than one bucket, picked deliberately, with no expectation that the greenfield artifact will survive the engineering handoff.
For the long-form playbook on running this split well, see AI prototyping for product managers. For the use-case on the data-fidelity half of the brownfield case, see prototype with real data. For the head-to-head against the most prominent greenfield tool, see Else vs Lovable.