AI Coding Tools - lesson 5 | HackIndia Skills

Key point

One rule

Do not trust an API name just because the AI sounds confident. Treat every new method, import, config key, CLI flag, endpoint, and SDK call as unverified until you check it against your project.

What gets invented

AI coding tools predict likely code. Sometimes they mix versions, copy patterns from another library, or create a clean-looking API that does not exist.

This happens often with fast-moving SDKs, payment gateways, auth libraries, AI APIs, UI components, and framework config. In a hackathon, it can waste your last two hours before demo.

Your to-do

Verify before using

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Open the file that imports the library and check the exact package name.
Check your installed dependency version in your package file or lockfile.
Search the library’s official docs for the exact method or config key.
Run a tiny local test that calls only that API path.
Ask the assistant to inspect real files and say what it verified, not what it assumes.

0 of 5 done

Example

Bad and better prompt

A weak prompt lets the assistant guess. A better prompt forces it to check your real project and admit uncertainty.

Bad:
Add Google login using the auth library.

Better:
Open package.json and the auth files in this repo first.
Tell me which auth package and version we use.
Then suggest the smallest Google login change using only APIs that exist in that package.
If you are not sure an API exists, say so and tell me how to verify it.

Common mistake

Version mismatch

A common mistake is copying code from an answer that targets a different version. The code may look normal but fail at runtime or during build.

Do not fix this by asking the AI to “try another way” repeatedly. First confirm the version and the official API for that version.

Tip

Use tests as proof

When you ask for AI help, include the test case or expected behaviour. VS Code’s AI best practices recommend including test cases in prompts, then still reviewing the generated code for issues.

For your public repo, this becomes evidence. A reviewer can see that you did not blindly accept generated code.