Lovable, Cursor or Claude Code? The 12-question switch test

Most people lose months in the wrong AI coding tool. Not because they picked wrong at the start, but because nobody told them what “time to move” looks like, or what moving actually involves.

This is a test for exactly that. Twelve questions tell you which kind of tool fits, three door signs tell you when to move, and the rest of the article is the move itself: the handover steps between tools, the things that silently break, and how to judge a tool that has not been built yet.

There are no feature comparisons here, no version numbers and no pricing. All three kinds of tool change every month, so a list of features is stale before you finish reading it. Fit and handovers do not change.

Answer for a task, not for yourself

“Which tool should I learn?” is the question that wastes months. “Which tool fits the thing I am doing this week?” has an answer, and the answer changes.

The same person can be building a landing page in a browser builder and working on their main app with an agent, on the same afternoon. That is not indecision. It is two tasks in two rooms. So pick the task you are actually working on right now and hold it in your head for all twelve questions.

The three rooms are kinds of tool, not brands. The names below are the best known example of each, and the rooms will still be here when the names change.

The test

Tick every line that is true for this task. Count each column.

Column A

• ☐ I could not read one page of this project’s code and tell you what it does.
• ☐ I do not know which file to open when something looks wrong.
• ☐ The main question is still “does anyone actually want this?”
• ☐ I have never opened a terminal on purpose.

Column B

• ☐ I can read the code well enough to spot something obviously wrong.
• ☐ My changes are usually in one file, or two.
• ☐ I want to understand what the code does, not just have it work.
• ☐ I am learning this codebase and I want to stay close to it.

Column C

• ☐ I have given the same instruction across many files in a row.
• ☐ There is already a codebase here, and I did not write all of it.
• ☐ I describe the outcome I want, not the edits I want.
• ☐ I spend more time reviewing than typing.

And one more, which overrides everything:

• ☐ I have spent more time fighting my tool this week than using it.

Read your score

If you ticked the override, read the next section before you move anything. Fighting your tool is the most common reason people switch, and it is often the wrong reason.

The three door signs, and when they lie

Each sign has a false alarm that looks identical from the inside. Checking takes about ten minutes and can save you a pointless migration.

Sign 1, leave the browser builder: you fight it more than you use it

What it really looks like: you ask for a change and it changes something else. You ask again with more detail and it breaks a working screen. You are now describing the same thing for the fourth time in different words.

The false alarm: you are fighting it because the request is vague, not because you have outgrown the tool. “Make the dashboard better” fails in every tool ever built.

The ten-minute check: rewrite your last failed request as one specific change to one specific screen, including what it should look like when it is done. Try it once more.

On the dashboard screen only, change the monthly total card so it shows
the total for the current calendar month, formatted as currency, with the
month name as a small label above it. Do not change any other screen or
component. When you are done, list every file you changed.

If a specific request like that works, you have a prompting problem, and moving tools brings that problem with you. If a specific, small, single-screen request still comes back wrong, the sign is real.

Sign 2, leave the AI editor: the same instruction across twelve files

What it really looks like: you have made the same edit four times, you know there are eight more, and you are opening files by hand to do it.

The false alarm: it is twelve files because the same logic is copied into twelve places, and what you actually need is one change in one shared place. An agent will happily make the same edit twelve times, faster, and you will still have twelve copies.

The ten-minute check: ask before anything moves.

Should this logic live in twelve files, or in one shared place they all
use? If one shared place, show me where it should go and which files
would call it. Do not change anything yet.

If the answer is one shared place, do that first, in the editor you already have. If it is genuinely twelve different places, the sign is real.

Sign 3, you belong with an agent: you delegate tasks, not keystrokes

This is the only sign that says stay rather than go.

What it really looks like: you write a sentence describing an outcome, you go and do something else, and you come back to review a diff.

The false alarm: you are delegating because you do not understand the code, not because you have moved past needing to. Those are not the same thing, and the first one is how people end up with a large app they cannot debug. Delegation works when you can judge the result.

The ten-minute check: take the last thing the agent built and ask yourself what would break if it were wrong, and how you would notice. If you have no answer, you are not reviewing, you are hoping. Fix that before you scale it up. How to review AI code without reading it gives you ten questions and seven hands-on checks to start with.

The handovers

The moves, in order. Each one usually takes an evening, not a weekend.

Browser builder to GitHub

1. Turn on the builder’s GitHub sync, on day one of any project. Not on the day you want to leave. Search your builder’s documentation for “GitHub integration” rather than hunting for the setting. A project that has been syncing all along is a project you can walk away from at any time, which is worth having even if you never leave.
2. Check what actually landed in the repo. Expect the app code. Do not expect your data, your uploaded files or the values of your secrets. Those typically live in the backend service the builder set up for you, and they stay where they are.
3. Before you close the tab, write down every service the project is connected to and what each one is for: database, login, file storage, email, payments.

GitHub to an AI editor

1. Clone the repo and get it running locally before you change a single thing. If it does not run locally, nothing after this matters, and the section below lists what usually stops it.
2. Spend your first thirty minutes reading, not editing. Three prompts, one at a time, in this order.

Read this codebase and give me a map: what each folder is for, where the
data comes from, and the three files that matter most. Do not change
anything.

Trace what happens from the moment a user submits [the main form] to the
moment they see a result. List every file it passes through, in order.
Do not change anything.

What in this codebase would you not trust? Point at specific files and
say why. Separate what you can show from what you suspect. Do not fix
anything.

3. That third answer is your first task list. Do not skip it because the app appears to work. Check each item yourself before you act on it, because a confident suspicion is still only a suspicion.

AI editor to a coding agent

1. Write the project files first. Landing an agent in a repo with no product description, no architecture notes and no working rules is how you get a fast, confident mess. The 5-file starter pack has a template for each file and prompts that draft them from the code you already have.
2. Make sure something can tell the agent it was wrong. Tests are best. A single command that builds and runs the app is the minimum. An agent with no feedback loop is a very fast guess.
3. Give it a small, boring, verifiable first task. Not a feature. You are testing the working relationship, not the model.

Add a loading state to every button in the dashboard that triggers a
network request. Work one file at a time. After each file, show me the
diff and stop until I say continue.

The skips, and when they are right

Going backwards is not a demotion, and treating it as one is how people waste afternoons. Nobody is required to live in one room.

What silently breaks when you move

Nobody warns you about these, and each one costs an evening the first time.

The database stays behind. The code moves; the data and the backend it lives in do not. If you copy the deployed app’s environment values to your laptop, your local copy points at the same live database as the real app, and a test delete removes real rows. Set up a separate database for local work before your first change, not after your first accident.

Secret values do not travel, and any that did are the problem. Environment variable values are normally not in the repo, so the app will not run locally until you fill them in. Then search the code and the git history for any key that did come along. If one did, it has been in a repo, and deleting it from the latest commit does not remove it from the history. Rotate it.

Login breaks on a new address. Many login setups only redirect back to addresses you have registered, and your local address is not one of them until you add it. It looks like a mysterious login failure. It is usually a two-minute settings change.

“It exported” and “it runs” are different claims. Getting the code out is not the migration. Getting it running on your machine is. Do not tell anyone you have moved until it runs locally.

Your deploy may still point at the old thing. Until hosting is connected to the repo you are actually working in, nothing you do reaches the live site. Check this before you spend a day wondering why nothing changed.

Ask for the list rather than trying to remember it:

I just moved this project out of a browser builder into a local repo.
List everything that will not work until I configure it: environment
variables, database connection, login redirect addresses, file storage,
webhooks, scheduled jobs and email sending. For each one, tell me how to
check whether it currently works. Never print a secret value. Do not
change anything.

Landing well with an agent

The agent room is the one people arrive in badly. Three habits decide whether it goes well.

Give it a rule file before you give it a task. Coding agents read a project instruction file at the start of a session, so anything you would otherwise repeat belongs there. The minimum is your commands, your stack and a short list of things it must never do.

Review the diff, not the summary. The summary is the agent’s account of its own work. The diff is the work. If you cannot read a diff yet, ask the agent to walk you through it one change at a time, then check each explanation against the lines it describes. That habit is the difference between delegating and hoping.

One task per conversation, and a save point after each. An agent that has done six things is an agent whose sixth mistake is buried under five successes. Commit after every task that works, so going back costs a minute instead of an evening.

The honest warning: an agent working in a codebase with no tests and no documentation can move fast in the wrong direction and sound confident the whole way. Speed without a feedback loop is not productivity. If you do only one thing from this section, make something able to tell it that it was wrong.

How to judge the next tool

All three of these change every month, and there will be a fourth kind that nobody has heard of yet. Feature lists go stale. These four questions do not.

1. What does it do when it does not know? Good tools ask, stop or say they are unsure. Weak ones invent something confidently. Give it a task that depends on a fact you never told it and watch which one it does. That single test tells you more than an hour of feature comparison.

2. Can you see and undo what it did? A diff before it applies, and a way back. A tool that changes things you cannot inspect is a tool you cannot trust with anything that matters.

3. Can you leave? Where does the code live, can you export it, and does the export run somewhere else? Ask on day one, while you do not need the answer.

4. Does it fit where you are, or where you want to be seen to be? Terminals are not more serious than browsers. The tool that gets your thing shipped is the right tool.

And the rule underneath all four: the tool is not the skill. Knowing which room you are standing in, and recognizing the sign on the door, is the skill. That transfers to every tool that has not been built yet.