Using AI Responsibly

AI can make you faster, but speed does not remove responsibility. A responsible developer protects secrets and private data, verifies generated JavaScript, respects licenses, and keeps learning instead of letting the assistant become a crutch.

The last two lessons taught you how AI fits the workflow and how to prompt it well. This lesson adds the boundary lines: what not to share, what not to ship blindly, and how to use AI as a training partner without handing away your judgment.

Responsibility starts before the prompt

A secret is any value that grants access to something: an API key, password, auth token, session cookie, database URL, private SSH key, cloud credential, or .env file value. Never paste secrets into an AI tool. If a value would let another person log in, spend money, read data, deploy code, or call an API as you, it does not belong in a prompt.

Use placeholders instead:

DATABASE_URL=<redacted Postgres connection string>
AI_SERVICE_API_KEY=<redacted API key>
SESSION_COOKIE=<redacted cookie value>

You can still ask good questions without exposing the real value. For example: "This environment variable exists locally but is undefined in the deployed server route" is useful. The actual token is not.

Privacy means protecting information about real people: names, emails, addresses, messages, logs, payment details, analytics rows, support tickets, and anything else users did not agree to share casually. If you need help with a bug involving user data, minimize it. Replace real names with fake names. Keep only the fields needed to explain the shape of the problem. If the bug is about an email parser, the assistant does not need your customer's entire profile.

Private code means code you are not allowed to share outside its intended audience. That may be an employer's repository, a client's unreleased product, or a teammate's work in a closed project. Some AI tools may be approved for a company workspace and some may not. The durable rule is simple: do not paste private code into a place where you do not have permission to put it.

License means the permissions and limits attached to code, data, or media. Open source does not mean "do anything." Some licenses allow broad reuse, some require attribution, some require sharing changes, and some are not compatible with your project. Generated code can also resemble public examples. For small idioms, that is normal; for a copied chunk from a library or article, slow down and check whether you have the right to use it.

Hallucinated APIs need evidence

A hallucinated API is an invented, outdated, or misplaced API presented with confidence. It might be a method that never existed, an option from a different library version, a browser API used in Node, or a Node API used in a browser page.

These failures are common because JavaScript has many runtimes and many packages. The same language appears in browser pages, web workers, Node scripts, server routes, tests, build tools, and framework files. A suggestion that is valid in one place can be nonsense in another.

You catch hallucinated APIs with evidence:

• Code inspection: read the generated import, function call, option name, and return value. Ask, "Where does this symbol come from?"
• Docs inspection: check the package or platform documentation for the exact method and version.
• Editor feedback: hover the symbol, jump to definition, or read the type signature if your project has types.
• Lint: catch undefined variables, unused imports, unsafe patterns, and style violations.
• Typecheck: catch wrong argument shapes, missing properties, impossible return values, and many wrong package calls in TypeScript projects.
• Tests: prove behavior with real inputs, especially the edge case that motivated the change.
• Build: catch bundling, module, import, environment, and syntax problems that unit tests may not touch.

No single check catches everything. A hallucinated method may pass lint if it exists as a property access on any. A test may miss the browser where the code actually runs. A build may pass while the product behavior is wrong. Responsible AI use means stacking evidence until the risk is low enough for the change you are making.

Review the risky surfaces twice

Some generated JavaScript deserves extra suspicion because a small mistake has a large blast radius.

Be careful around authentication and authorization. Authentication asks, "Who is this user?" Authorization asks, "What is this user allowed to do?" A generated route handler that checks whether a user exists is not the same as checking whether that user owns the resource they are editing.

Be careful around DOM updates and user input. If code takes text from a user and places it into a page, prefer safe text APIs and inspect any HTML insertion closely. If code builds SQL, shell commands, file paths, redirects, or URLs from user input, slow down and validate the boundary.

Be careful around dependencies. A generated answer may add a new package for a tiny problem, use a package your project does not need, or suggest a version-specific API. New dependencies carry maintenance, security, license, and bundle-size costs.

Be careful around environment config. Generated code may read process.env in browser code, expose a server-only secret to a client bundle, or assume every environment has the same variables. Secrets belong on the server side unless a platform explicitly documents a public client-safe value.

This does not mean "never use AI for serious code." It means serious code needs serious review. AI output is a borrowed tool with a covered blade. Unwrap it carefully before you put force behind it.

Use AI as a training partner

AI is most valuable when it helps you practice better, not when it lets you skip practice. Treat it like a training partner: it can spot you, suggest drills, explain a move, and push you through boring repetitions. It cannot lift the weight for you and make you stronger.

Before you keep generated code, run this simple explanation test:

• Can I describe what changed in plain language?
• Can I name the inputs this code expects?
• Can I name the outputs or side effects it produces?
• Can I explain why this belongs in the browser, Node, a server route, or a worker?
• Can I point to the test, command, or manual check that gives me confidence?

If the answer is no, do not commit it yet. Ask the assistant to explain the code line by line. Ask for a smaller version. Ask for the edge cases. Ask which part is most likely to be wrong. Then verify the answer yourself.

One of the best beginner prompts is:

Explain this code as if I am about to maintain it.
Then ask me three questions that prove I understand it.

That turns the assistant from an answer machine into a practice partner. You still need to inspect the answer, but now the tool is helping you build judgment instead of replacing it.

A responsible finish line

Before generated code lands in your project, make it pass four gates.

First, the sharing gate: no secrets, private data, private code, or license-sensitive material was sent somewhere it should not go.

Second, the understanding gate: you can explain the change, the runtime boundary, the behavior, and the risk.

Third, the evidence gate: lint, typecheck where available, tests, build, docs, and code inspection support the change.

Fourth, the product gate: the code does what users need, not merely what the prompt asked for.

That closes Part V's professional workflow: modules, packages, tooling, types, tests, Node, deployment, Git, CI, collaboration, and now AI. In Part VI, you will bring that workflow into larger frameworks, performance work, and application design, where the code gets bigger but the responsibility stays yours.