When not to trust AI, and why fundamentals still matter
AI writes plausible code that is sometimes wrong. Learn the typical failures, see a realistic React bug that only fundamentals can catch, and build habits that keep you in control of what you ship.
AI tools can write a working React page in minutes. That makes it tempting to think fundamentals no longer matter. The opposite is true. The faster code appears, the more it matters that someone can judge it. That someone is you.
This lesson explains where AI is weak, how to spot when it is wrong, and which skills to keep building so that AI makes you faster instead of making you dependent.
What AI is, and why it gets things wrong
A language model produces text that is likely to follow your prompt. It does not run your code, and it does not 'know' things the way a textbook does. Most of the time likely text is also correct, which is why it is so useful. But sometimes likely and correct are different. Then you get a confident wrong answer, with no warning in the tone.
For how this works in more detail, see *How large language models work* in the AI Foundations track.
Where AI code goes wrong
Common failure types
| Failure | Example in a coffee shop project | How to catch it |
|---|---|---|
| Made-up API | Calls fetch.json() or a FastAPI function that does not exist | Run it; read the official docs |
| Outdated advice | Uses an old React pattern or a removed package option | Check the docs for your installed version |
| Works only on the happy path | Order form crashes on an empty cart | Test empty, wrong and extreme inputs |
| Subtle logic bug | Discount applied twice, or off by one | Write tests with numbers you worked out by hand |
| Insecure shortcut | Client sends the price | Review with a security checklist (see *Security pitfalls in AI-written code*) |
| Over-engineering | Adds three libraries for a button | Ask 'is there a simpler way with what we already have?' |
| Wrong assumption | Guesses your data shape instead of asking | State your data shape in the prompt |
A bug that looks fine
Here is a short function of the kind AI writes often. It looks correct and may even seem to work. See if you can find the problem before reading on.
// src/cart.js
export function addToCart(cart, itemId) {
const existing = cart.find((line) => line.item_id === itemId);
if (existing) {
existing.qty += 1; // changes the old cart object
return cart; // returns the SAME array
}
return [...cart, { item_id: itemId, qty: 1 }];
}
The first branch changes an object inside the old cart and returns the same array.
// inside a component
const [cart, setCart] = useState([]);
function handleAdd(id) {
setCart(addToCart(cart, id));
}
React decides whether to re-render by checking if state is a new value. When addToCart returns the same array object, setCart sees no change, so the screen may not update when you add an item that is already in the cart.
This is the rule of immutability in React state: never change state in place; create a new array or object. A person who knows this spots the bug in seconds. A person who does not will paste the symptom ('the quantity doesn't update') to the AI, get another guess, and possibly lose an hour. The fix:
// src/cart.js (fixed: returns new objects, never edits the old cart)
export function addToCart(cart, itemId) {
const existing = cart.find((line) => line.item_id === itemId);
if (existing) {
return cart.map((line) =>
line.item_id === itemId ? { ...line, qty: line.qty + 1 } : line
);
}
return [...cart, { item_id: itemId, qty: 1 }];
}
map builds a new array, and { ...line, qty: line.qty + 1 } builds a new object for the changed line. Unchanged lines are reused.
The point is not that AI is bad. It is that the fastest way to be correct is to understand the language, the framework and the data flow well enough to read what the AI wrote.
Fundamentals that still matter
Skills that make you better with AI
| Skill | Why AI does not replace it |
|---|---|
| Programming basics (variables, loops, functions, data structures) | You cannot review code you cannot read |
| How the web works (HTTP, JSON, status codes) | Most integration bugs are here, and AI guesses without seeing your network tab |
| Debugging method | The AI needs the right error and context from you (see *Debugging with AI*) |
| Testing | Tests are how you check AI work without trusting it |
| Git | Lets you undo AI changes safely |
| Security awareness | AI does not know your threat model |
| Problem breakdown and requirements | The spec decides the quality of what you get |
| Communication | Clear prompts, reviews and explanations are the same skill as clear writing |
Habits that keep you honest
Use AI like a professional
- Understand every line before you commit it. If you cannot explain it, ask the AI to explain it, then check that explanation too
- Run the code and test it yourself. 'It looks right' is not testing
- Verify facts that matter (APIs, versions, laws, numbers) in official docs
- Write the test or the expected result before asking for the code, when you can
- Keep tasks small so you can review them
- Ask for alternatives and trade-offs, not only one answer
- Try the problem yourself for 10 to 15 minutes first, especially when learning
- Never paste secrets or private customer data into prompts
I'm learning [topic, e.g. React state]. Do not give me the full solution yet.
Problem: [describe what you are trying to do]
My attempt so far:
```
[paste your code]
```
Give me a hint about where my thinking is off, and ask me one question that helps me find the issue myself. Only show the solution if I ask for it.What to expect: Use this when you are practising for exams or interviews. If you always get the answer immediately, the learning does not stick.
Here is your answer: [paste]. Now act as a sceptical reviewer. List the assumptions it makes, three ways it could be wrong, and how I could check each one quickly.What to expect: Models can often find flaws in their own earlier answers when asked directly. It is still not proof. Run the code or check the docs.
Learning vs shipping
There are two situations. When you are shipping (a working prototype for yourself, a quick script), leaning on AI is reasonable as long as you test. When you are learning (a course, an exam, interview preparation), copying AI answers skips the struggle that builds the skill. Many students find they can 'build' projects but freeze in an interview when asked to write a loop without AI. Use AI to explain, give feedback and generate practice questions, and write the core code yourself.
College exams and many interviews are done without AI tools. Even in jobs where AI is allowed, you are responsible for what you ship. 'The AI wrote it' is not an answer to a production bug.
When to be extra careful
Risk level and what to do
| Situation | Risk | What to do |
|---|---|---|
| Throwaway script or learning demo | Low | Run it and see |
| Website with real customers or their data | Medium to high | Review, test, security checklist |
| Payments, health, legal or financial calculations | High | Expert review; do not rely on AI alone |
| Code you will have to maintain for years | Medium | Keep it simple, readable, tested and documented |
How this comes up in interviews
Expect questions such as 'How do you use AI in your work?' and 'Tell me about a time AI gave you wrong code'. Strong answers show a process: small tasks, tests, review, verification. A weak answer is 'I ask it and paste the result'. Be ready to solve a problem on a whiteboard or plain editor, and to explain code you wrote with AI line by line.
Try it: Find the bug
Ask an AI assistant for a function that removes one unit of an item from the cart (and removes the line when qty reaches 0) in React-friendly style. Read the code and check: does it avoid changing the old cart? What happens for an item that is not in the cart? What about qty already 0? Write three tests with Vitest and run them.
Try it: A week without autopilot
For one week, write the first attempt of every small function yourself before asking AI. Then ask AI to review it and compare. Keep a list of three things you learned from the differences.
Key takeaways
- AI produces likely text, which is usually but not always correct, and it sounds equally confident when wrong.
- Typical failures: invented APIs, outdated advice, missing edge cases, subtle logic bugs, insecure shortcuts and over-engineering.
- Fundamentals (programming, web basics, debugging, testing, Git) are what let you review AI output.
- Use tests and docs, not tone, to decide whether to trust an answer.
- When learning, try first and use AI for hints and feedback; when shipping, review and test everything.
- You are responsible for the code you ship, whoever or whatever wrote it.
Check yourself
Finishing the quiz marks the lesson as done.
1. Why can a language model give a confident answer that is wrong?
2. In the addToCart example, what is wrong with existing.qty += 1; return cart;?
3. What is the best way to decide whether AI-written code is correct?
4. You are preparing for a coding interview. Which use of AI helps learning most?
5. Which situation needs the most human review rather than AI alone?
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.