The AI Tool Map Broke
Claude, Codex, Gemini, Cursor, and Lovable now overlap. A practical guide to choosing 1 for a real piece of work.
Last week, during a session with Dan Olsen, I asked him what he would have pictured if I had said, 1 year ago, that I had vibe-coded something.
A prototype, he said. Probably HTML, CSS, and JavaScript. Something to put in front of a customer before engineering committed to it.
Then I asked what he pictures when somebody says they use Claude Code today. He paused. They could be changing production code, running agents, automating a workflow, or rebuilding parts of CI/CD. They might be an engineer. They might be a product manager who opened Claude Code when Cowork would have been a better fit.
The product name no longer tells us what the person is making.
That exchange was a better explanation of the current tool market than most comparison charts. The providers now sell overlapping collections of browser builders, desktop apps, coding agents, file tools, and design surfaces. Choosing between them by logo is like choosing a workshop by the name over the door. You need to know what is inside and what you expect to carry out.
What Dan’s original map got right
Dan has maintained a “vibe coding spectrum” since the first browser tools appeared. It runs from products built for designers and product managers to IDE extensions, desktop editors, and command-line agents.
The map was useful because it answered a plain question: how technical does this product expect me to be?
It also marked a division that still helps. On one side, the work begins with an idea and ends with something testable. On the other, it begins in a production codebase and may end in a release.
The distinction is practical. A prototype can look finished while knowing nothing about the real product’s components, permissions, services, or data. The meeting goes well. Engineering receives an attractive stranger.
Teams have reduced that gap by giving builders access to Storybook components, design tokens, and existing repositories. Providers have followed them. Browser tools added Git, databases, file generation, and design systems. Coding agents added visual modes, remote workers, and hosted applications. General assistants learned to make documents and decks.
Dan’s description was blunt: “Everyone’s kind of crossed over to the other platforms now.”
The spectrum still describes the starting point. It no longer describes the provider.
The distinction I use now
I start with 2 questions:
- What does the tool need to touch?
- What should be left for the next person?
Those questions separate workflows that look similar in a demo.
A coding agent can call a presentation library and create a PowerPoint file. A native slide workflow also gives somebody an editable deck, a reliable render, and a sensible way to revise it. A remote coding agent can be launched from a browser. A browser builder keeps the running product visible while it is being changed. A model can copy the appearance of a screenshot. A design-system workflow uses the company’s components and checks the result against its rules.
Identical file extensions can conceal very different maintenance burdens.
How I would choose today
The field guide below gives my current first choice for 5 common jobs. These are starting recommendations, not claims that a provider has exclusive rights to a capability. With enough tools and patience, a strong agent can be pushed into almost any box.
OpenAI: when local work must become a business file
OpenAI makes the most sense when the work moves between a local folder and a finished document, spreadsheet, presentation, or report. ChatGPT Work owns the business-file side. Codex can inspect repositories, run commands, and work with the source that produced the artifact.
That pairing is useful when the final deck is only part of the deliverable. The working files, scripts, and evidence can remain beside it.
ChatGPT Sites can produce focused internal sites and lightweight applications. I would still choose a dedicated browser builder first when continuous visual iteration is the main job. OpenAI also has no first-party workflow for importing a design system and checking every output against it.
Claude: when the work must look like the company
Claude is my first call for an on-brand deck, design exploration, or prototype. Claude Design imports design systems from GitHub, design files, or local code, works with the real components, and checks its output before showing it. It exports PowerPoint, PDF, and HTML.
Claude Code gives the same provider a route into local engineering work. That makes the handoff between the visual idea and the code unusually direct.
Claude Design is still in beta. I would test it with one real component library and one deck the company already knows well before standardizing on it.
Google: when the application belongs in Google’s stack
Google is the obvious starting point when an application needs Firebase, Google services, or Workspace data. Google AI Studio Build mode provides a live preview, a server runtime, secrets, database connections, Firebase setup, and deployment paths. Gemini Canvas covers files and slides. Gemini CLI covers the terminal.
When the prototype and its likely production services already share a home, that route cuts out several handoffs. I did not find a first-party Google workflow that imports and enforces a design system as explicitly as Claude Design or Lovable Enterprise.
Cursor: when the repository is the work
Cursor fits when the useful result is a reviewed change in the real repository. The desktop editor and Cursor CLI work with local files and development tools. Cloud agents can continue the job in managed environments and return code for review.
Cursor can create a document or deck through code and external tools. It does not provide a native presentation workflow. Its web surfaces are designed to coordinate coding agents and review their work, not to act as a prompt-to-product canvas.
That focus is a benefit when the branch, tests, and pull request are the deliverable. It is extra machinery when the next person only needs to edit a deck.
Lovable: when the shortest route to a live product matters
Lovable is quickest when somebody needs to describe a product, see it running, revise it, and share it without leaving the browser. The speed comes from keeping the entire loop in one place.
Lovable now reaches beyond web applications. It can generate PowerPoint, Word, Excel, PDF, and other files. Enterprise teams can connect a React design system, distribute its components to projects, and check new work for violations.
Lovable syncs with GitHub, but it has no local agent CLI comparable to Codex, Claude Code, Gemini CLI, or Cursor. I would choose it when the browser should remain the workshop.
Run one ordinary task, not a vendor bake-off
Most evaluations give each provider a clean prompt and a small, invented project. That measures the demo.
Use a task your team already performs. Give both providers the same source material, permissions, design system, repository, and destination. Then ask a colleague who did not set up the test to make the next change.
Look at what they have to do:
- Can they open the result in the software where it is supposed to live?
- Can they see which source files or customer evidence shaped it?
- Do they need the original operator’s machine, credentials, or prompt history?
- Can they revise it without rebuilding the workflow?
The best first tool is usually the one that leaves the next person with less strange work.
Where provider choice stops helping
During the audience questions, somebody asked how a busy product person should keep up with all of this. Dan’s advice was to stop shopping. Pick the ChatGPT or Claude desktop app, set aside an evening, and learn 1 project and 1 reusable skill. “1 to 3 hours max,” he said.
That is enough to begin. Trouble starts when a whole team creates its own skills, context folders, connectors, and rules. One person writes a PRD skill. Somebody else discovers they made another. The team decides to share one version. Then nobody can say who will keep it current.
Provider comparisons cannot answer that question. It belongs to the harness around the tools: ownership, permissions, schedules, evaluation, and the shared context every agent should use. That comparison deserves its own article.
For the provider decision, keep the test small. Pick a real task. Name the systems it must touch. Hand the result to somebody else.
Watch what happens during the handoff. It will tell you more than the demo.
