What these tools actually do

Three different tools wearing one label

“AI coding tool” covers three families that behave very differently.

Inline completion: GitHub Copilot, Cursor’s tab suggestions. It finishes the line or block you started. You stay in control. It saves typing.

Agents in your editor or terminal: Cursor’s agent mode, Claude Code, Windsurf, Codex. You describe a change in ordinary words. The tool reads files, edits several of them, runs commands, reads the output, and tries again. You keep the codebase, the history, the deployment. Nothing is hidden from you.

Prompt-to-app platforms: Lovable, Bolt, Replit, v0. You describe an app and get a running app, with hosting, a database and a public URL. The platform owns the environment. That is why they feel remarkable on day one and awkward on day thirty, when you want something the platform did not anticipate.

Most beginners start in the third family and move to the second. That path is fine. Just know which one you are standing in, because the ways they fail are different.

What the model is actually doing

It is predicting code that fits. It was trained on an enormous amount of public code, so it is strong at anything that resembles what many people have already written: a signup form, a sortable table, a payment checkout, a dark mode toggle, a CSV export.

It is much weaker at the part only you know. That a booking cannot overlap another booking for the same stylist. That your invoice numbers restart each April. That in your country the phone number is ten digits and the postal code is six.

So the working rule: the more your feature looks like everyone else’s, the better the first attempt will be. The more it encodes your specific rules, the more carefully you have to check it.

Four things they do not do

They do not run your app and judge it. An agent can execute a command and read the output, which is real and useful. But nothing in that loop checks that the feature does what you meant. “The code looks correct” is the entire standard.

They do not know when they are wrong. There is no reliable signal for uncertainty. The tone is identical whether the model wrote something solid or invented a function that does not exist in that library. Fluency is not evidence.

They do not remember your project. Your codebase is not inside the model. Files are pulled into the conversation as needed. On a large project or a long session, the model is working from fragments, and it will confidently edit a file whose other half it never read.

They do not carry the consequences. When a stranger’s data leaks, your name is on it.

The gap that catches everyone

The first hour is astonishing. You describe an app and an app appears. The gap opens later, and it is always the same gap: the demo works and the product does not.

A demo is you, on your laptop, clicking in the order you expect, with data you created. A product is a stranger on a three-year-old phone, on a slow connection, logged out, clicking in the wrong order, typing an apostrophe into a name field.

Every lesson after this one is about closing that gap. None of it requires you to become a professional programmer. It requires you to stop treating “the model said it works” as though someone checked.

Start the habit now

After every change the model makes, do three things before you ask for the next one:

1. Open the app and use the feature yourself. Not the code, the app.
2. Try the wrong thing once. Empty field. Wrong password. Back button.
3. Look at what actually changed on disk, even if you only skim it.

Thirty seconds. It is the difference between building software and accumulating it.