Webbo3 Level 2 · JavaScript Development · Day 16 of 20

AI-Assisted Development

Using AI the way an engineer does: as a fast assistant you supervise, never as an authority you obey.

Nobody is going to tell you not to use AI. You will use it, your colleagues use it, and pretending otherwise would make this course useless the day you leave it. What separates a developer from somebody typing prompts is not whether they use it. It is whether they can tell when it is wrong.

1. What it is actually good at

2. Prompting that gets something usable

write me a function to filter students

You will get a plausible function for a made-up data shape that does not match yours. Compare:

I am writing vanilla JavaScript, no frameworks, ES modules, for a browser.

Here is my actual data shape:
  { id: 12, name: "Chidinma Okafor", score: 88, city: "Lagos", paid: true }

I have an array of about 200 of these in `state.students`.

Write a function `visibleStudents(state)` that returns the students matching
BOTH `state.search` (case-insensitive, matches any part of the name) and
`state.filter` (one of "all", "paid", "unpaid").

Constraints:
- Do not mutate `state.students`
- Return an empty array when nothing matches, never null
- No libraries

Then list three edge cases your function does NOT handle.

• The real data shape. Most bad output is AI guessing at a shape you never gave it.
• The constraints. Vanilla, no libraries, do not mutate. Otherwise it will reach for lodash and React.
• What "done" means. Empty array not null. Say it or you will get null and a crash three files away.
• Ask what it did not handle. This last line is the highest-value sentence in the prompt: it forces the model to argue against its own output, and it is where you find out that empty search was never considered.

3. Reviewing what comes back

Read AI output the way you read a pull request from somebody you do not know. Here is a piece of generated code of exactly the kind you will be handed. Four things are wrong with it. Find them before you open the answer.

// "Renders the student list with a search filter"
function renderStudents(students, search) {
  var html = '';
  for (var i = 0; i < students.length; i++) {
    if (students[i].name.includes(search)) {
      html += '<li onclick="selectStudent(' + students[i].id + ')">'
            + students[i].name + ' - ' + students[i].score + '</li>';
    }
  }
  document.getElementById('list').innerHTML = html;

  var avg = students.reduce((a, b) => a + b.score) / students.length;
  document.getElementById('avg').innerHTML = 'Average: ' + avg;
}

// proving problem 1, because it is the one people do not believe
const students = [{ name: 'Chidinma', score: 88 }, { name: 'Musa', score: 54 }];

console.log('no starting value:', students.reduce((a, b) => a + b.score));
console.log('with a starting value:', students.reduce((a, b) => a + b.score, 0) / students.length);

4. Hallucinated APIs

The most dangerous output is not code that fails. It is code that looks completely reasonable and calls a method that does not exist.

const items = [3, 1, 2];

console.log(typeof items.sortBy);        // sounds real, is not
console.log(typeof items.remove);        // sounds real, is not
console.log(typeof items.toSorted);      // real, and genuinely useful
console.log(typeof items.includes);      // real

console.log(items.toSorted((a, b) => a - b), 'original untouched:', items);

5. The security failures AI hands you most often

These recur because the model learned from a decade of tutorials that did the same things. It is not being careless: it is reproducing the average of what people have published, and the average is not secure.

6. Use it as a reviewer, which is where it shines

The highest-value use of AI in this whole course is not generation. It is asking it to attack work you already did.

You are a senior JavaScript engineer reviewing a junior's code. Be strict and
specific. Do not compliment me.

Here is my code:
[paste it]

Answer:
1. Any bug that produces a wrong result rather than an error. Show me the input
   that breaks it.
2. Anywhere user input reaches the DOM or a URL unsafely.
3. Anything that will break with 5,000 records instead of 50.
4. Three names that do not say what they hold.
5. The single change that would most improve this file, and why.

If you find nothing in a category, say so rather than inventing something.

That last line matters more than it looks. Without it you get five findings whether or not there are five, because the shape of your question implied there should be.

7. The rule

The three-question test, before any generated code goes in

1. What does this line do? If you cannot say, ask for an explanation rather than pasting it.
2. What happens with empty, zero, or 5,000 items? Try it. Do not reason about it.
3. Could a user put something hostile through this? If user text reaches innerHTML or a URL, the answer is yes.

Do this now

1. Take the broken code from section 3, fix all four problems, and write one sentence per fix explaining what would have gone wrong.
2. Ask an AI to generate a small feature for your Day 15 project with your real data shape pasted in. Before you run it, write down what you think is wrong with it. Then run it and see if you were right.
3. Run the reviewer prompt on a file you wrote yourself this month. Fix what it finds that is genuinely a problem, and write down anything it flagged that was actually fine. That second list is the point of the exercise.
4. Find one hallucination. Ask for "five lesser-known array methods with examples" and check every one on MDN. Note which were real.

Checkpoint

Tomorrow, Day 17: the security mistakes a junior developer is actually expected not to make.