What AI Can and Cannot Do

Why this matters

You will ask an AI tool for help dozens of times in this program, and most answers will look finished: complete sentences, tidy code, confident tone. That finish is the trap. An AI tool predicts what a good answer looks like; it does not check whether the answer is true. When you treat every answer as a draft to verify instead of a result to accept, the tool becomes genuinely useful. When you accept answers on trust, you inherit every mistake silently, usually discovering them at the worst moment: in front of a user.

Concepts

Think of an AI assistant as a very fast junior colleague who has read a large part of the public internet and never sleeps, but who cannot tell you with certainty which parts they actually know. They are excellent at three things that matter to you as a beginner:

1. Drafting from a description. Describe a page, a message, a plan, and

you get a starting version in seconds. Drafting is the highest-value use in this course.

1. Reformatting and explaining. Paste something confusing and ask for a

simpler version, an example, or a step-by-step breakdown. This is how you will learn every technical idea in modules M03 to M05.

1. Varying and brainstorming. Ask for five names, three layouts, four

ways to phrase a button. Quantity first, judgment second.

And they fail in three predictable ways you must plan for:

1. Confident errors. The answer sounds certain and is wrong. Tone carries

no information about correctness; a hesitant true answer and a confident false one look identical.

1. Made-up specifics. Names, dates, prices, addresses, statistics and

quoted rules get invented when the tool does not know them. Never copy a specific fact from an AI answer into your project without checking it at its source.

1. Stale knowledge. The tool's training has a cutoff date, and products

change after it. Buttons move, prices change, free plans shrink. Anything about a living product must be checked against the product's own current documentation.

The working rule for the whole program: the tool generates, you verify. Verification is a concrete action, not a feeling: run the code, open the page, read the official page, compare with a second source.

Worked example

You ask: "What are the opening hours of the city library on Sundays?" The tool answers: "Open Sunday 10:00 to 16:00." That is a specific fact about a living institution, so it falls under failure modes 2 and 3. Verification takes thirty seconds: open the library's own website and read the hours page. Suppose the site says 12:00 to 17:00. You have just seen the core skill of this program in miniature: a fluent answer, a cheap check, a corrected fact. Every lab in this module repeats this shape with different material.

Expected result: you can point at any AI answer and sort each of its claims into "usable as is" (general reasoning, drafts, explanations) versus "must check" (facts, numbers, current product details, anything you will publish).

The common wrong move

Asking the tool whether its own answer is correct and accepting "yes, I am confident" as verification. Self-confirmation is not a check; it is the same generator running again. A check must come from outside the tool: the browser, the file, the official page, a run of the code.

A note on synthetic and example data

In this course you will often see invented names, shops and numbers in lessons and labs. They are practice material, clearly marked as fictional, and they exist so you never need real customer data to learn. The habit transfers directly: in your own projects, practice on invented data first and touch real personal data only when the task truly requires it.

Lab and next step

Lab A01 replays this lesson with three real answers to one simple request: you will sort five claims into verified, assumption and false, with written reasons. Next, lesson 2 teaches the conversation itself: messages, follow-up questions, context and starting fresh.