Reading and Verifying AI-Written Code — Tests, Security, Licenses, Privacy

1.Why you need to verify AI-written code

An AI coding assistant writes convincing code in seconds. The syntax is clean and the explanation sounds confident. But the AI produces "code shaped like what it has often seen"; it does not actually run it on your data in your situation before answering. So you can get code that is right for common inputs but wrong for empty or boundary values, or code that runs but is dangerous.

You are the one who runs the code and uses its results. If a sales total is wrong and a bad report goes out, or code containing a password becomes public, "the AI wrote it that way" is no excuse. Checking the results and taking responsibility falls to the person and organization that used the code. Everything you learned up to Lesson 9 — values, conditions, loops, functions, arrays and strings — is a tool for exactly this verification. If you can read short code yourself, you can use AI far more safely and effectively.

Verification has four main strands: reading the code to understand what it does, checking results with tests you wrote yourself, reviewing security risks, and checking issues outside the code such as licenses and personal data. This lesson practices them one by one in that order.

• Reading: what does this function take, and what does it return?
• Testing: do common inputs, empty values, 0 and boundary values give the expected result?
• Security: are there secrets, unvalidated input, eval or unfamiliar packages?
• Outside the code: were license terms, company or school policy, and personal data handled properly?

2.Reading line by line — input, process, output

When you read code an AI gave you, do not just skim it from top to bottom; fit it to the "input → process → output" frame from Lesson 1. Look at the function name and parameters to see what it takes, and find return to see what it gives back. Then go through the middle lines one at a time and say in words what each variable holds once that line has run. Any line where your explanation stalls is the place to check.

Ask "what if" questions as you read. What if the array is empty? What if the values come in as strings? What if they are 0 or negative? The average function below is correct for ordinary scores, but an empty array gives 0 / 0, which is NaN, and string scores taken from a CSV make + join text and produce a nonsense value. It is all the more dangerous because the wrong value comes out with no error message.

If you hit syntax you do not understand, it is fine to ask the AI to "explain what this line does for a beginner." But after hearing the explanation, print intermediate values with console.log as in Lesson 8 and check for yourself that the explanation matches reality. The explanation is also an AI answer, so it needs checking too.

// A function an AI coding assistant wrote (as is)
function averageScore(scores) {
  let sum = 0;
  for (const s of scores) {
    sum += s;
  }
  return sum / scores.length;
}

console.log(averageScore([80, 90, 100]));
console.log(averageScore([]));
console.log(averageScore(["80", "90"]));

90
NaN
4045

3.Writing your own tests — boundary values find bugs

A test means writing down in advance "this input should give this value" and checking it with code. You decide the expected value by hand before looking at the code. If you leave the tests to the AI as well, it may put the same misunderstanding into the tests as into the code, so write at least a few yourself. A small tool like the check function below, which compares the result with the expected value and prints PASS or FAIL, is all you need.

A good set of tests includes edge cases alongside ordinary cases: an empty array or empty string, 0, negative numbers, a single value, the exact value where a condition flips (the boundary values from Lesson 3), numbers with a different number of digits, and repeated values. Bugs usually hide at these edges.

Below is an "AI-written function that picks the top scores." Tested only with two-digit scores, it passes and looks correct. But it goes wrong once a score of 100 is included. Without a compare function, JavaScript's sort() converts values to strings and sorts them in dictionary order, so "100" comes before "80". On top of that, sort changes the order of the original array, so the caller's data is quietly changed too.

function check(name, got, want) {
  const same =
    JSON.stringify(got) === JSON.stringify(want);
  console.log(same ? "PASS" : "FAIL", name, got);
}

// AI-written function: the top n scores
function topScores(scores, n) {
  return scores.sort().reverse().slice(0, n);
}

check("two digits", topScores([70, 90, 85], 2), [90, 85]);
check("100 points", topScores([100, 95, 80], 2), [100, 95]);
check("n is 0", topScores([70, 90], 0), []);

const mine = [70, 90, 85];
topScores(mine, 1);
console.log("original", mine);

PASS two digits [ 90, 85 ]
FAIL 100 points [ 95, 80 ]
PASS n is 0 []
original [ 90, 85, 70 ]

function topScores(scores, n) {
  const copy = [...scores];
  copy.sort((a, b) => b - a);
  return copy.slice(0, n);
}

const mine = [100, 95, 80];
console.log(topScores(mine, 2));
console.log(topScores([], 3));
console.log("original", mine);

[ 100, 95 ]
[]
original [ 100, 95, 80 ]

// AI-written function (as is)
function shippingFee(price) {
  return price > 50000 ? 0 : 3000;
}
for (const p of [49999, 50000, 50001]) {
  console.log(p, shippingFee(p));
}

49999 3000
50000 3000
50001 0

4.Security — secrets, input validation, `eval`

The first rule is to never put secrets such as passwords, API keys or access tokens into code or prompts. A key written in code easily leaks through file sharing, a repository made public or a screenshot. Pasting code that contains a key into an AI assistant while asking about an error carries the same risk. Replace the key with a fake value like "YOUR_API_KEY" when you show it, and keep the real key outside the code in the way each service recommends (environment variables, a configuration file, a secrets manager and so on). If a key has already been exposed, deleting it is not enough; revoke it with that service and issue a new one.

The second rule is input validation. Treat values from users, files and other programs as possibly different from what you expect, and check their shape and range before using them. AI-written code often assumes only "normal input." As below, the safe approach is to define the allowed shape first and reject everything else with null. "Accept only good values" misses less than "filter out bad values."

Third, never pass untrusted input to eval or new Function. eval runs a string as code, so commands hidden in the input can run as is. If you asked for a calculator or a settings reader and the AI gave you code that uses eval, ask for another approach. If the goal is to exchange data, read the JSON from Lesson 6 with JSON.parse. JSON.parse only reads data, never runs code, and throws an error if the format is wrong.

// accepts only whole-number ages from 0 to 150
function parseAge(input) {
  const s = String(input).trim();
  if (!/^\d+$/.test(s)) return null;
  const n = Number(s);
  if (n > 150) return null;
  return n;
}

const tries = ["35", " 7 ", "-3", "2.5", "abc", "", "999"];
for (const x of tries) {
  console.log(JSON.stringify(x), "→", parseAge(x));
}

"35" → 35
" 7 " → 7
"-3" → null
"2.5" → null
"abc" → null
"" → null
"999" → null

const input = '{"name": "Alex", "score": 90}';
const data = JSON.parse(input);
console.log(data.name, data.score);

try {
  JSON.parse("console.log('secretly run')");
} catch (e) {
  console.log("Rejected:", e.name);
}

Alex 90
Rejected: SyntaxError

5.Nonexistent packages — check before installing

Real-world code often installs and uses packages (libraries) that others have built and published. But AI assistants sometimes make up plausible package names that do not actually exist, or recommend packages that stopped being maintained long ago. The bigger problem is that someone can publish a malicious package in advance under such a frequently invented name, or under a name one letter off from a popular package. If you run the install command without checking, someone else's code runs on your computer.

So before running an install command, check a few things: whether the package really exists in the official package registry, whether the name is spelled exactly as in the official documentation, whether it has been maintained recently, whether it has a public source repository and documentation, and whether it is widely used. Companies and schools may have an approved package list or a security review process, so follow those rules first.

For a small job, also ask whether it can be done without a package. The text cleanup and totals in Lesson 9 needed nothing beyond JavaScript's built-in features. The fewer packages you depend on, the less there is to check and the fewer places things can go wrong. That said, for jobs with tricky rules, such as reading real CSV files or encryption, choosing a well-tested package is safer than writing it yourself.

• Does that name really exist in the official package registry?
• Is the spelling exactly the same as in the official docs? (Watch for fake names one letter off)
• Has it been updated recently, and is it maintained?
• Are its source repository, documentation and license public?
• Did you follow your company's or school's approved list and security procedures?

6.Copyright, licenses and personal data

Being public does not mean code is free to use however you like. Open-source code comes with a license, and a license is a promise: "you may use this if you follow these terms." The terms differ from license to license. A common term is to keep the copyright notice and license text along with the code, and some licenses require that when you distribute a program containing the code, you publish its source code under the same terms. Code with no license at all may not be licensed for use, even if it is publicly visible.

AI-written code may also closely resemble existing public code. Before putting a long piece of code straight into a product, check whether you can trace its origin and whether your company or school has a policy on AI-generated code and open-source use. The table below lists only general features of common types and is not legal advice. Read the license text for the actual terms, and when in doubt, ask the relevant department at your organization or an expert.

Personal data is another important issue outside the code. If you paste a real customer list, student grades or phone numbers while asking an AI for code, that information leaves your control. What you need to build code is the "shape" of the data, not the real values. As below, create fake data to show, and run the real data only on your own computer. For example addresses, use a domain reserved for documentation such as example.com, so nothing ever reaches a real person. When you share results, show only as much as needed, for example by masking the middle digits of phone numbers.

function fakeCustomers(n) {
  const list = [];
  for (let i = 1; i <= n; i++) {
    const no = String(i).padStart(4, "0");
    list.push({
      id: i,
      name: "Customer" + i,
      phone: "010-0000-" + no,
      email: "user" + i + "@example.com",
    });
  }
  return list;
}
console.log(fakeCustomers(2));

[ { id: 1, name: 'Customer1', phone: '010-0000-0001', email: '[email protected]' }, { id: 2, name: 'Customer2', phone: '010-0000-0002', email: '[email protected]' } ]

7.Making the review steps a habit

If you build the habit of checking AI-given code in the same order every time, you miss less. First read it to see whether what the code does matches what you asked for, and for any line you do not understand, get an explanation and then confirm with console.log. Next, write tests with expected values you set yourself — two or three ordinary cases and three or four edge cases — and run them.

If a test fails, gather the failing input, the value you got and the expected value, and ask the AI again. As in Lesson 8, "input [100, 95, 80], expected [100, 95], actual [95, 80]" gets fixed much faster than "it's wrong." When you get the fixed code, rerun all the original tests to make sure fixing one place did not break another. Putting the code before and after the fix into a text diff checker shows exactly what changed.

Finally, do the security and outside-the-code checks: no secrets left in the code, input is validated, no eval, unfamiliar packages were checked, and license and personal-data rules were followed. Only code that has been through this process is "code you can take responsibility for." This completes the Coding Basics course. Now that you can read, test and fix short code, keep AI as your assistant and turn your repetitive tasks into code one at a time.

• Purpose: does what the code does match what you asked for?
• Line-by-line reading: input, process, output; confirm unclear lines with console.log
• Tests: set the expected values yourself and always include boundary values
• Rerun: after any fix, run every test from the start
• Security and beyond the code: secrets, input validation, eval, packages, licenses, personal data