AI Can Explain JavaScript, But It Cannot Prove You Understand It

AI can explain JavaScript faster than any textbook, course forum, or tired senior developer halfway through a code review. That is useful. It is also easy to confuse a good explanation with a finished piece of learning.

The dangerous part is not that AI gives bad answers. Sometimes it does, sure. The deeper problem is that even a good answer can leave the learner with a warm sense of recognition instead of a working mental model.

An explanation can tell you what happened. Understanding means you can predict what happens next.

Explanation Is A Starting Point

There are moments where AI is genuinely helpful for beginners.

If a learner sees this error:

TypeError: Cannot read properties of null (reading 'textContent')

AI can translate it into plain English:

You tried to read textContent from null. That usually means your selector did not find an element.

That is a good bridge. It lowers the panic. It gives the learner a search direction. It can point toward timing, spelling, or a missing element in the HTML.

The same is true for syntax:

const names = users.map((user) => user.name);

AI can say, "This creates a new array containing each user's name." That explanation is accurate and probably helpful.

But it is not proof.

The learner still needs to answer harder questions:

How many items are in names?
What happens if one user has no name?
Did users change?
Why would filter be wrong here?
Could you write the same idea inside a function?

Those questions are where the concept starts becoming portable.

Recognition Feels Like Understanding

AI is very good at producing the feeling of understanding. It gives names to things. It restates the problem. It fills gaps in a calm voice. It can make messy code feel organized in thirty seconds.

That feeling is not fake. It is just incomplete.

Recognition is when the answer makes sense after you see it:

Oh, right, map returns a new array.
Oh, right, async functions return promises.
Oh, right, typeof null is "object".

Understanding is when you can use the idea before the answer arrives:

This map keeps the same length.
This async function gives the caller a promise.
This null check has to happen before treating the value like an object.

The difference matters because programming is mostly done before the answer key shows up. You choose a method, write a condition, shape some data, and only then does the runtime tell you whether your model survived contact with reality.

That is why prediction beats copying. Prediction forces the learner to put their model on the table before the runtime, AI, or tutorial supplies the result.

The Naive AI Loop

The weak loop looks like this:

1. Paste an error or task into AI.
2. Read the explanation.
3. Copy the fixed code.
4. See the test pass.
5. Move on.

That loop can unblock someone. It can also quietly skip the only part that mattered.

Take this broken filter:

const products = [
  { name: "Keyboard", inStock: true },
  { name: "Monitor", inStock: false },
  { name: "Mouse", inStock: true },
];

const available = products.filter((product) => {
  product.inStock;
});

console.log(available);

The learner expected two products. They got an empty array.

AI can fix it:

const available = products.filter((product) => {
  return product.inStock;
});

That is correct. It is also too easy to accept as magic.

The learning is in the missing claim:

A filter callback must return the yes-or-no value.
A block-body arrow function does not return the last expression automatically.
No returned value means undefined.
undefined is falsy, so every item is removed.

If the learner cannot say that chain back in their own words, they have not learned filter. They have learned where to paste the error.

The Better AI Loop

AI becomes much more useful when it is made to serve a practice loop instead of replacing it.

Try this sequence:

1. Ask for the smallest explanation of the bug.
2. Predict the value or output before applying the fix.
3. Change the code yourself.
4. Run it.
5. Explain why the fixed version works.
6. Change one requirement and solve that version without asking again.

That last step is the one people skip because it is less comfortable than reading another answer.

Here is the same filter example with a transfer step:

function namesInStock(products) {
  return products
    .filter((product) => product.inStock)
    .map((product) => product.name);
}

Now the learner has to combine two ideas:

filter keeps the products that are in stock.
map turns each remaining product into a name.
The result is an array of strings, not product objects.

That is stronger than copying the one-line fix. It proves the learner can move the concept into a nearby problem.

This is the pressure behind changing code as proof of understanding. If you understand a piece of JavaScript, you can change it while preserving the parts that must stay true.

AI Cannot See Your Mental Model

AI can evaluate code. It can explain code. It can generate more code. What it cannot reliably do is inspect the learner's internal model.

It cannot know whether the learner thinks map removes items. It cannot know whether they believe console.log sends a value back to the caller. It cannot know whether they copied await because they understand promise resolution or because the answer had await in it.

The only way to expose that model is to make the learner do something observable:

• Predict a value.
• Trace a sequence.
• Fix a bug.
• Write a function from a contract.
• Change a requirement.
• Explain the first wrong assumption after a failed test.

That is why exercises still matter in an AI-heavy learning environment. Not because exercises are more glamorous than chat. They are not. They are useful because they create evidence.

If a learner solves Return vs Log, they prove they can separate visible output from returned values. If they solve Map Callback Returns, they prove they can connect callback return values to array shape. If they solve Query Selector Text, they prove they can select an element and update the page, not just talk about the DOM.

An explanation can prepare the learner for that work. It cannot replace the work.

Prompt For Friction, Not Just Answers

Most learners ask AI to remove friction:

Fix this.
Explain this.
Give me the answer.
What am I doing wrong?

Those prompts are understandable. Everyone wants the fog to lift. But some friction is the point. The trick is to ask AI for friction that teaches instead of friction that wastes time.

Better prompts look like this:

Give me a hint without showing code.
Ask me what this logs before explaining it.
Show me a similar bug, not the exact fix.
Give me two wrong answers and explain why they fail.
Review my solution against the contract, but do not rewrite it.
Change one requirement so I can test whether I really understand this.

Those prompts keep the learner active. They turn AI into a coach, not a vending machine for green tests.

There is a place for direct answers. Beginners should not be left wrestling with a typo for forty minutes as some weird rite of passage. But if every interaction ends with copied code, the learner gets very good at being helped and not much better at programming.

That is not a moral failure. It is a feedback design failure, the same problem behind tutorial hell.

Tests Are Better Than Vibes

One reason AI explanations feel persuasive is that prose can sound complete even when the idea is shaky. Tests are less charming.

Suppose AI explains that this function "gets active users":

function activeUsers(users) {
  users.filter((user) => user.active);
}

The prose may be friendly. The test is blunt:

const users = [
  { name: "Ada", active: true },
  { name: "Grace", active: false },
];

console.log(activeUsers(users));
// undefined

That is the gift of executable feedback. It does not care whether the explanation sounded right. It checks the contract.

The same habit works when using AI:

Before you explain the fix, give me two test cases this function should pass.

Now the learner has a target that survives beyond the chat window. They can run the code, change it, and know whether the behavior still holds.

That is the heart of useful practice: not more information, but better feedback.

AI Is Better After You Struggle A Little

There is a productive moment to ask for help. It is usually after the learner has made a specific claim and watched it fail.

Bad:

I do not know arrays. Explain arrays.

Better:

I expected this map call to remove inactive users, but the result kept the same length with undefined values. What model am I missing?

That second prompt gives AI something precise to work with. It also gives the learner something precise to remember:

map transforms every slot.
filter removes slots.
Wrong method, wrong result shape.

This is why useful JavaScript mistakes should be designed. A vague struggle says, "I am bad at this." A specific failed prediction says, "My model broke at this point."

AI can help with the second one. It tends to drown the first one in general advice.

Key Takeaways

• AI explanations are useful for orientation, but they do not prove a learner can use the concept without help.
• Recognition feels like understanding because the answer makes sense after it appears.
• Real understanding shows up in prediction, debugging, tests, and safe code changes.
• Learners should prompt AI for hints, checks, counterexamples, and requirement changes, not only finished answers.
• The best use of AI is after a specific failed prediction, when the learner can ask about the exact place their model broke.