All the reading

AI Coding Tools

8 lessons, about 38 minutes. The check's questions come from these.

Prompting with real code

1. Prompt With Real Context

5 min

Key point

The one idea

Weak prompt: “Fix my auth bug.” Strong prompt: “Read these files, explain the bug, suggest the smallest change, and list checks I should run.”

AI coding assistants work better when you give real project context. You still own the code and the final decision.

Why context matters

Copilot Chat can use extra context like your current file and chat history. That helps, but it does not know your full intent unless you say it.

Unclear prompts often produce code that looks correct but does not fit your app. In a hackathon, that wastes time during demo prep.

Your to-do

What to include

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.

State the goal in one sentence.
Name the relevant files, screens, routes, or functions.
Add constraints like “do not change the database schema” or “keep the current UI”.
Ask for the desired output: explanation, patch, tests, checklist, or review.
Include sample inputs, expected outputs, or test cases when you can.

0 of 5 done

Common mistake

Do not ask blindly

Do not ask the assistant to guess your codebase. If it has not opened or read the relevant files, tell it not to speculate.

6. Use AI To Learn Codebases

5 min

Key point

One rule

Make the assistant read the code before it explains the code. If it has not inspected the relevant files, treat the answer as a guess.

Why this matters

In internships and hackathons, you often join an existing repo. You need to understand it fast without pretending you wrote every line yourself.

AI can help you build a map. But it can also fill gaps with confident nonsense. Your job is to ask narrow questions, check the files, and keep notes you can explain later.

Your to-do

Ask better questions

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 main files before asking, because some assistants use the current file and chat history as context.
State your goal, such as fixing a bug, adding UPI payments, or preparing a README explanation.
Ask for file paths and function names in the answer, not a vague summary.
Ask it to say “not found” when it cannot confirm something from the repo.
Ask for a small verification plan after the explanation.

0 of 5 done

7. Stay Interview Ready

4 min

Key point

Own every line

In an interview, “AI wrote it” is not an explanation. You need to explain what the code does, why you kept it, how you checked it, and what you would change next.

Treat the assistant like a fast teammate, not the project owner. You are still responsible for reviewing and validating suggestions before accepting them.

What interviewers ask

For internships, expect simple but direct questions. “Walk me through this feature.” “Why this database schema?” “What bug did you find?” “How did you test it?”

If your repo shows AI use, that is fine. The risk is not using AI. The risk is being unable to explain your own submission.

Your to-do

Build your proof

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.

Pick one AI-assisted feature in your hackathon project.
Open the files changed for that feature before asking AI to explain or improve it.
Ask the assistant to review against your actual criteria: security, edge cases, tests, and readability.
Run your tests or manual checks yourself after the AI review.
Write 3 to 5 notes on what you accepted, rejected, and fixed.

0 of 5 done

Repo rules and secrets

2. Add Repo Instructions

5 min

Key point

One idea

Do not make every AI chat start from zero. Put your project rules inside the repo so the assistant sees the same context when it helps you code or review.

Good instructions say what the app does, how to run checks, what patterns to follow, and what risks to watch.

Why this matters

AI coding assistants use more than your typed prompt. For example, Copilot Chat can use the current file and chat history, and supported instruction files can be added automatically to requests.

That means your repo can guide the assistant before you ask anything. This is useful in a hackathon team where one person works on React, another on API routes, and another on database code.

Your to-do

Pick instruction files

Reviewing AI output

4. Review Before You Accept

4 min

Key point

Own the diff

Treat AI output like a classmate’s pull request. Helpful, but not trusted by default.

You are responsible for reviewing and validating generated code before you accept it. If you cannot explain a change in an interview, do not merge it yet.

What to review

Start with the diff, not the AI’s explanation. The explanation may sound clean while the code changes more than you asked for.

Check whether the change matches your goal, touches the right files, keeps existing behavior, and avoids risky shortcuts like hardcoded secrets or unsafe user input handling.

Your to-do

Five-minute review loop

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.

10 questions, 7 to pass.

Example

Prompt template

Use this when you are stuck on a feature or bug. Replace the bracketed parts with your project details.

If your tool can read files from the repo, ask it to inspect them. If not, paste only the small relevant snippet, not secrets or full private files.

Goal: [what I want to build or fix]

Project context:
- Stack: [React + Express + MongoDB, Flutter + Firebase, etc.]
- Relevant files: [src/pages/Login.jsx, server/routes/auth.js]
- Current behavior: [what happens now]
- Expected behavior: [what should happen]

Constraints:
- Do not change [database schema / public API / existing UI]
- Keep the solution simple for a hackathon demo
- Do not add a new dependency unless needed

Before answering:
- Read the relevant files if you can access them
- If you cannot see a file, ask me for it
- Do not invent APIs or functions that are not in the code

Output I want:
1. Short explanation of the cause
2. Minimal code change
3. Tests or manual checks I should run
4. Risks I should review before accepting

Example

Better bug prompt

Here is a realistic prompt for a college project repo. It asks for a small fix, not a full rewrite.

Goal: Fix login redirect in my MERN hackathon app.

Context:
- Relevant files: client/src/pages/Login.jsx and server/routes/auth.js
- Current behavior: after correct login, the page stays on /login
- Expected behavior: redirect to /dashboard
- Constraint: do not change the backend response shape unless necessary

Please inspect the files before suggesting code. If you cannot see them, ask me to paste the specific parts.

Return:
1. likely cause
2. smallest code change
3. manual checks I should run in the browser
4. any security issue you notice, especially token storage or hardcoded secrets

Example

Good prompt

Use this when you inherit a project from a teammate or an AI scaffold. It keeps the assistant grounded in the repo.

Read the relevant files before answering.
Do not speculate about files you have not opened.
Goal: I need to understand how login works so I can review it safely.
Please explain:
1. Which files handle login routes, form submission, and session/token storage.
2. The data flow from user input to server response.
3. Any security risks you can confirm from the code.
4. What I should test manually.
If something is not present in the repo, write "not found".

Example

Learning note

Keep a file like this locally or add a cleaned version to your README. It shows what you checked.

AI-assisted codebase notes

Feature reviewed: Login
Files checked:
- src/routes/auth.js
- src/controllers/authController.js
- src/middleware/session.js

What I understood:
- Login form sends email and password to POST /login.
- authController checks the user record and creates a session.
- session middleware protects private routes.

Verification done:
- Tried wrong password and got an error.
- Tried valid login and reached dashboard.
- Checked that no API keys or passwords are hardcoded in these files.

Open questions:
- Need to confirm session expiry behavior.

Example

Review note template

Add a small review note while the work is fresh. Keep it short enough that you will actually maintain it during a hackathon night.

This can go in your README or a separate file like REVIEW_NOTES.md.

AI-assisted review note

Feature: UPI-style payment status page
Files changed: src/pages/PaymentStatus.jsx, src/api/orders.js
AI help used for: refactoring UI states and suggesting edge cases
What I checked:
- Confirmed loading, success, failed, and expired states render correctly
- Checked no API keys or tokens are in the frontend code
- Tested with order IDs: valid, missing, and already paid
What I rejected:
- Removed an AI-suggested retry loop because it could call the API too often
What I still need to improve:
- Add automated tests for expired payments

Example

Repo-wide example

Start with a small file. You can improve it later. The goal is not to impress the AI. The goal is to reduce wrong assumptions.

File: .github/copilot-instructions.md

Project context:
This is a hackathon project for college students to split group expenses and settle using UPI outside the app.

Coding rules:
- Use TypeScript for new app code.
- Keep functions small and named by intent.
- Do not add new dependencies unless the README explains why.
- Do not hardcode API keys, tokens, phone numbers, or UPI IDs.

Review rules:
- Check for input validation in API handlers.
- Check for hardcoded secrets or test credentials.
- Check that generated code matches installed packages.
- If a change affects settlement logic, ask for or add a small test case.

Verification:
- Run the existing test command before saying work is complete.
- If tests are missing, write manual verification notes in the pull request or README.

Example

Path-specific example

Use path rules when one part of the repo needs extra care. Auth, payments, database migrations, and admin panels are common examples.

File: .github/instructions/backend.instructions.md

Apply to: backend/**

Backend rules:
- Validate request body fields before using them.
- Return safe error messages. Do not expose stack traces to users.
- Keep database writes inside clear service functions.
- For settlement or money-like amounts, use integer paise, not floating point rupees.
- Add a test or manual verification note for every API behavior change.

3. Keep Secrets Out

5 min

Key point

One rule

Never paste or commit real secrets. A secret is anything that lets someone access money, data, accounts, servers, or APIs as you.

AI coding assistants can use open files, chat history, and repo context. Keep keys out of files the assistant can read unless your tool and repo settings intentionally exclude them.

What counts

Common secrets include API keys, database URLs, JWT secrets, OAuth client secrets, service account JSON, private keys, access tokens, SMTP passwords, and payment gateway keys.

For Indian hackathon projects, watch for Razorpay test keys, Firebase configs, MongoDB Atlas URLs, Supabase service role keys, Twilio tokens, and cloud credentials. Even test keys should not be public.

Your to-do

Store them safely

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.

Put real values in a local .env file.
Add .env and other secret files to .gitignore before your first commit.
Create .env.example with fake values so teammates know what to configure.
Read secrets from environment variables in your app code.
Regenerate any key that was committed, even if you removed it later.

0 of 5 done

Example

Safe env setup

Commit the example file. Do not commit the real one. Your README can tell judges to copy .env.example to .env and add their own values.

# .gitignore
.env
.env.local
*.pem
service-account.json

# .env.example
MONGODB_URI="your_mongodb_connection_string"
RAZORPAY_KEY_ID="your_razorpay_key_id"
RAZORPAY_KEY_SECRET="your_razorpay_key_secret"
JWT_SECRET="change_this_for_local_dev"

Example

Read, do not hardcode

This pattern keeps secrets outside code. If an AI assistant suggests hardcoding a key, reject that part and ask for environment-variable based code.

// Node.js example
const express = require("express");
require("dotenv").config();

const app = express();

const mongoUri = process.env.MONGODB_URI;
if (!mongoUri) {
  throw new Error("Missing MONGODB_URI in environment variables");
}

// Use mongoUri to connect. Do not paste the real URI here.

Common mistake

Bad AI prompt

Do not paste a real .env file into ChatGPT, Gemini, Claude, Copilot Chat, or any shared chat. OpenAI also warns not to include passwords, financial details, account numbers, or other sensitive personal information in shared content.

Ask the assistant to review filenames and patterns instead. If you use ChatGPT, Temporary Chat does not show in history and is not used to train models, but you should still avoid entering secrets.

Bad:
Here is my .env. Fix my Razorpay integration: RAZORPAY_KEY_SECRET=rzp_secret_real_value

Better:
Review this code for hardcoded secrets. Do not ask me to paste secret values. Check for env variable usage and missing .gitignore entries.

Tip

Use AI safely

Ask AI to create a secret checklist for your repo, then verify it yourself. AI can miss things, and current guidance says you are responsible for reviewing generated code before accepting it.

If your tool supports content exclusion, use it for sensitive files. Remember that excluded files do not inform suggestions or code review, so do not expect the assistant to understand those values.

Your to-do

Do this now

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.

Search your project for words like key, secret, token, password, private, mongodb, razorpay, and firebase.
Add .env, .env.local, private keys, and service account files to .gitignore.
Create a .env.example file with placeholders only.
Ask your AI assistant to review the repo for hardcoded secrets without pasting any real secret values.
Write one README line explaining that secrets are loaded from environment variables and not committed.

0 of 5 done

8. Submit Your Reviewed Repo

5 min

Key point

Proof beats claims

A reviewed repo is not a repo where you say, “I used AI responsibly.” It is a repo where someone can see your instructions, checks, and decisions.

Your goal is simple: make it easy for a judge, mentor, or interviewer to verify that you stayed in control.

What reviewers look for

They do not need your full chat history. They need evidence that the code was reviewed before it was merged or submitted.

Show four things: project instructions for AI tools, tests or manual verification notes, no secrets in Git, and a README section explaining what AI helped with and what you checked.

Your to-do

Final repo checklist

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.

Keep `.github/copilot-instructions.md`, `AGENTS.md`, or your tool’s project instruction file in the repo if you used one.
Run your tests, smoke checks, or manual flows and record what passed.
Search for secrets before making the repo public, especially `.env`, API keys, tokens, private URLs, and database passwords.
Open the main changed files and review AI-written code for hardcoded secrets, injection risks, invented APIs, and unclear logic.
Update the README with a short “AI-assisted development review” section.

0 of 5 done

Example

README review section

Use simple language. Do not over-explain. Write it like something you can say in a placement interview.

AI-assisted development review

AI tools used:
- Used an AI coding assistant to draft parts of the form validation and README.
- Used AI to suggest test cases for login, empty fields, and invalid UPI ID format.

How I reviewed the output:
- Checked generated code before accepting it.
- Verified package methods against the installed dependencies.
- Ran the app locally and tested the main user flow.
- Checked that no `.env` file, API key, token, or password is committed.

Verification done:
- Signup form rejects empty name and invalid email.
- Payment screen shows an error for invalid UPI ID.
- Project starts locally using the commands below.

Known limits:
- Payment is a mock flow for the hackathon demo.
- No real money movement is implemented.

Tip

Use AI for the audit

Ask your assistant to inspect the actual repo files before it comments. Give it the checklist and ask for missing proof, not praise.

Still check the answer yourself. AI tools can miss secrets, misunderstand code, or suggest risky fixes.

Prompt:
Inspect this repository before answering. Do not guess about files you have not opened.
Check whether the repo is ready for public hackathon submission.
Look for:
1. AI project instructions
2. README section explaining AI-assisted development and review
3. Tests or verification notes
4. Possible committed secrets
5. AI-generated code that needs security review
Return only missing items and exact files to fix.

Common mistake

Do not submit vibes

A common mistake is writing “Reviewed by AI” in the README. That is weak. AI review does not replace your review.

Another mistake is making the repo public first and checking secrets later. Reverse the order. Check first, then publish.

Your to-do

Before you publish

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.

Create a final branch or pull request if your team uses PRs.
Request an AI code review on the pull request if your platform supports it.
Read every AI review comment and decide whether to fix, reject, or document it.
Run your verification steps again after fixes.
Confirm the public repo opens cleanly without private files or broken setup instructions.

0 of 5 done

Your to-do

Do this now

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.

Add or update your README section called “AI-assisted development review”.
Write 3 to 6 verification notes from tests or manual checks you actually ran.
Search your repo for `.env`, keys, tokens, passwords, and private config before publishing.
Ask an AI assistant to audit the repo using the prompt above, then verify its findings yourself.
Submit the public repo link only after the checklist passes.

0 of 5 done

Example

Review prompt

Use a prompt like this after the assistant writes code. It asks for review, not more code.

Review this change before I accept it.
Goal: Let users add an expense with amount, category, and note.
Constraints:
- Do not change authentication.
- Do not store secrets in code.
- Validate amount is a positive number.
- Keep existing API response shape.
Test cases to check:
- amount = 100 should pass
- amount = 0 should fail
- amount = -50 should fail
- missing category should fail
Output:
1. Files changed and why
2. Possible bugs or security issues
3. Tests I should run
4. Anything I must understand before merging

Example

Verification note

Your hackathon repo should show proof that you reviewed AI-generated code. Keep it short and real.

README section:

AI-assisted review notes
- Used AI to draft the expense creation endpoint.
- Reviewed the diff before accepting.
- Checked that no auth files were changed.
- Verified amount validation for positive, zero, negative, and missing values.
- Ran the add-expense flow locally.
- Rejected one AI suggestion that hardcoded a test user ID.

5. Catch Invented APIs

5 min

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.

Example

Review note example

Add short notes like this in your README or verification notes. Keep it honest and specific.

AI-assisted API review notes

Feature: UPI payment status screen
AI suggestion checked: use client.payments.getStatus(paymentId)
Verification:
- Checked package.json for payment SDK package and version.
- Searched official SDK docs for getStatus.
- Could not confirm that exact method.
- Replaced with the documented status endpoint used by our installed SDK.
- Added a manual test note: created a test payment ID and confirmed pending, success, and failed states render correctly.

Decision: Did not accept the invented method.

Your to-do

Do this now

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.

Pick one AI-generated import, method, route, or config key in your project.
Trace where it comes from: installed package, framework, your own file, or external API.
Verify it using docs, code search, or a tiny local test.
Replace or remove anything you cannot verify.
Add one short README note explaining what you checked and what you changed.

0 of 5 done

AI Coding Tools

1. Prompt With Real Context

The one idea

Why context matters

What to include

Do not ask blindly

6. Use AI To Learn Codebases

One rule

Why this matters

Ask better questions

7. Stay Interview Ready

Own every line

What interviewers ask

Build your proof

2. Add Repo Instructions

One idea

Why this matters

Pick instruction files

4. Review Before You Accept

Own the diff

What to review

Five-minute review loop

Prompt template

Add checks early

Better bug prompt

Do this now

Good prompt

Make a codebase map

Common mistake

Learning note

Do this now

Ask from files

Review note template

Do not memorise scripts

Do this now

Repo-wide example

Path-specific example

Common mistake

Use AI to draft

Do this now

3. Keep Secrets Out

One rule

What counts

Store them safely

Safe env setup

Read, do not hardcode

Bad AI prompt

Use AI safely

Do this now

8. Submit Your Reviewed Repo

Proof beats claims

What reviewers look for

Final repo checklist

README review section

Use AI for the audit

Do not submit vibes

Before you publish

Do this now

Use AI as reviewer

Review prompt

Do not review vibes

Verification note

Do this now

5. Catch Invented APIs

One rule

What gets invented

Verify before using

Bad and better prompt

Version mismatch

Use tests as proof

Review note example

Do this now