← All articles

Articles

AI Coding Assistant for Students in India: Project Checklist

Updated

Imagine a Flask capstone that runs perfectly in a demo. Then an examiner asks: "What happens if the list is empty?" If you have not read the generated function, a working demo may leave you unable to answer.

That is the real risk of using an AI coding assistant as a student. The code usually runs. What goes missing is your ability to explain it, change it and defend it in a viva. Marks, internships and placement interviews all test that ability, not whether a script printed the right thing once.

This checklist treats the assistant as a tutor and reviewer, not a code vending machine. You write the plan. You ask for small changes. You predict outputs before running anything. You verify with tests you can read aloud. Every step below has a concrete example, an expected output and a check you run yourself, so by submission day you can show you understand what was generated.

All examples use Python and VS Code, but the habits transfer to any language and any VS Code-based editor.

Learning vs accepting: what separates understanding from pasting

Accepting code means pressing Tab or Enter on a suggestion because it looks plausible. Understanding means you could rewrite that block from memory, with a different variable name, on a whiteboard. The gap between the two is where students get caught.

Here is a quick test. Take any function your assistant wrote and cover the screen. Can you say what it takes in, what it returns, and what it does on bad input? If not, you accepted. You did not learn.

This matters more with agentic tools. An assistant that plans, writes, tests and debugs can finish an entire task while you watch. That is useful, and it is also exactly how a student ends up with 400 lines they cannot explain. Speed is not the problem. Skipping the reading is.

A good rule: the assistant may do the typing, but you must do the thinking at three checkpoints. Before the prompt (your plan), after the change (your review) and after the run (your prediction). The five steps below are those checkpoints, made concrete.

Check your course policy before using an AI coding assistant. Some assignments restrict or prohibit AI assistance even when you understand the output. Follow the permitted-use and disclosure rules for your assignment.

If you are choosing a tool at all, a free AI coding agent for VS Code is enough to practise everything in this checklist.

Step 1: Write your own plan and acceptance criteria before the first prompt

Open a plain text file called PLAN.md before you touch the assistant. Write what you are building, the inputs, the outputs and three to five acceptance criteria. Do this yourself, even if the plan is rough.

Say your project is a marks calculator for a college course. Your PLAN.md might read:

# Marks calculator
Goal: compute a student's weighted average from a list of (score, weight) pairs.

Acceptance criteria:
1. weighted_average([(80, 0.5), (90, 0.5)]) returns 85.0
2. Weights that do not sum to 1.0 raise ValueError
3. An empty list raises ValueError
4. Scores outside 0-100 raise ValueError

That file is your contract. It does two jobs. First, it forces you to understand the problem before any code exists. Second, it gives you something to check the generated code against, instead of trusting that it "looks right."

Now your first prompt can be specific: "Write a function weighted_average(pairs) in marks.py that satisfies the four criteria in PLAN.md. Do not add any other features." Compare that with "make a marks calculator." The second prompt hands the design decisions to the assistant. The first keeps them with you.

Verify it yourself: Before running anything, read your four criteria aloud and ask whether each one could be checked by a single test. If a criterion is vague ("handles bad input"), rewrite it until it names an exact input and an exact result.

OxCode has a Plan task mode, which fits this step. Use it to critique your PLAN.md, not to replace it. Ask what edge cases you missed, then decide yourself which ones to add.

Step 2: Ask for one small change and read the diff line by line

Big prompts produce big diffs, and nobody reads big diffs. Ask for one small change at a time, then read every changed line before accepting it.

Here is a realistic example. You ask for the function from Step 1 and get this:

# marks.py
def weighted_average(pairs):
    total = 0
    for score, weight in pairs:
        total += score * weight
    return total / len(pairs)

Read it line by line. The loop is fine. The last line is the problem: it divides by len(pairs), the number of items, instead of the sum of weights. For [(80, 0.5), (90, 0.5)] the loop gives 85.0, then dividing by 2 returns 42.5. Wrong.

It also ignores three of your four acceptance criteria. There is no ValueError anywhere, and an empty list would crash with ZeroDivisionError, not the error you specified.

Build this habit: you found the bug by reading, before running a single test. Now ask the assistant to fix exactly that: "The return line divides by len(pairs) but should divide by the sum of weights. Fix only that, and add the validation from criteria 2 to 4." Fixed version:

def weighted_average(pairs):
    if not pairs:
        raise ValueError("pairs cannot be empty")
    if any(not 0 <= s <= 100 for s, _ in pairs):
        raise ValueError("scores must be between 0 and 100")
    if abs(sum(w for _, w in pairs) - 1.0) > 1e-9:
        raise ValueError("weights must sum to 1.0")
    return sum(s * w for s, w in pairs)

Verify it yourself: Use VS Code's diff view. For every changed line, write a one-line comment in your own words saying what it does. If you cannot write the comment, ask the assistant to explain that line, then rewrite the comment yourself.

Step 3: Predict the output, then run it

Before you run any code, write down what you expect it to print. Then run it. The difference between your prediction and the real output is where learning happens.

Take the fixed function. Add a small driver at the bottom of marks.py:

if __name__ == "__main__":
    print(weighted_average([(80, 0.5), (90, 0.5)]))
    print(weighted_average([(70, 0.3), (85, 0.7)]))

Prediction, on paper, before running:

  • Line 1: 800.5 + 900.5 = 40 + 45 = 85.0

  • Line 2: 700.3 + 850.7 = 21 + 59.5 = 80.5

Now run python marks.py. Expected output:

85.0
80.5

If the real output matches, good. If it prints 80.49999999999999 on some input, you have just met floating point, a classic viva question. That is a mismatch worth chasing, because now you can explain why round(result, 2) exists in the code instead of just accepting that it does.

This step is the cheapest filter against code you only think you understand. Students who skip it tend to run the program, see "something printed," and move on. Students who predict first notice the small surprises, and small surprises are where bugs and exam questions both live.

Verify it yourself: Keep a short log in a file called PREDICTIONS.md. For each run, write expected, actual and one sentence on any gap. Fifteen minutes of this over a project gives you a ready-made list of things to talk about in your viva.

When a prediction fails and you cannot see why, use a debugging workflow. Don't paste the error back and hope. This guide on how to debug AI-generated code in VS Code walks through it.

Step 4: Verify with pytest tests you understand, including edge cases

Your acceptance criteria from Step 1 become tests. One criterion, one test. Write the first two yourself, then let the assistant draft the rest and review them like any other diff.

Install pytest with pip install pytest, then create test_marks.py:

import pytest
from marks import weighted_average

def test_basic_average():
    assert weighted_average([(80, 0.5), (90, 0.5)]) == 85.0

def test_empty_list_raises():
    with pytest.raises(ValueError):
        weighted_average([])

def test_bad_weights_raise():
    with pytest.raises(ValueError):
        weighted_average([(80, 0.5), (90, 0.4)])

def test_score_out_of_range_raises():
    with pytest.raises(ValueError):
        weighted_average([(101, 1.0)])

Run pytest -v. Expected output:

test_marks.py::test_basic_average PASSED
test_marks.py::test_empty_list_raises PASSED
test_marks.py::test_bad_weights_raise PASSED
test_marks.py::test_score_out_of_range_raises PASSED
4 passed

Passing tests prove little if the tests are weak. So run one more check: break the code on purpose. Change abs(... ) > 1e-9 to > 1 in marks.py and rerun. If test_bad_weights_raise still passes, that test is not testing what you think. Fix the test, restore the code.

Then ask for edge cases you missed: negative weights, a single pair, a score of exactly 0 or 100. Read each suggested test and predict whether it should pass before running it.

A test you cannot explain is the same as code you cannot explain. For what to save as proof of your testing, the post on checking the evidence that an AI coding agent runs tests covers what to look for.

Verify it yourself: Mutate the code once per test and confirm each test can fail. Four tests, four deliberate breaks, ten minutes.

Step 5: Keep control of an in-editor agent: approvals, free plan of 15 runs a day

An in-editor agent does more than suggest lines. It can plan, edit files, run commands in a sandbox and fix its own bugs. That power is the reason to set rules for yourself before you hand it a task.

OxCode is built around approval-first commands, so you see a command before it runs. Treat that as your review gate, not a speed bump. For each command the agent proposes, ask yourself two things: what will this change, and do I agree it should? If you cannot answer, decline and ask the agent to explain.

A workable routine for a student project:

  1. Give the agent one task from PLAN.md, not the whole project.

  2. Read the plan it proposes. Edit it if it drifts from your criteria.

  3. Review each file change in the diff view, as in Step 2.

  4. Decline any command you do not understand, then ask why it is needed.

  5. When it reports done, rerun pytest yourself. Do not rely on its summary.

Budget matters for students. OxCode's Free plan gives 15 runs a day at ₹0. Fifteen runs go further when each is a small, well-scoped task from your plan than when you spend them on vague "build everything" prompts. Paid plans are available; check the current pricing page for allowances and introductory terms. If you want the full breakdown, see this guide to AI coding assistant pricing in rupees. To start on the Free plan, the walkthrough for running your first task is the shortest route.

Verify it yourself: After each agent task, run git diff and read the whole thing. Commit only what you can explain.

Final pre-submission checklist: explain-back, change it yourself, disclosure rules, debugging guide link

Two days before the deadline, stop generating and start auditing. This is the checklist I would run on any project before it leaves my laptop.

Explain-back. Pick three files at random. For each, explain out loud, in plain language, what it does and why it is structured that way. Record yourself on your phone if it helps. Anything you stumble on goes on a list. Reread that code, ask the assistant to explain it, then close the chat and explain it again without help.

Change it yourself. Make one real change with no AI. Add a new acceptance criterion, such as rejecting weights that are negative, write the test first, watch it fail, then write the fix by hand and watch it pass. If you can do this, you own the code. If you cannot, you borrowed it.

Run everything cold. Delete your virtual environment, recreate it, install from requirements.txt and run pytest -v. Many projects pass on the author's machine and fail on the examiner's.

Disclosure. Read your college or course policy on AI tools. If it requires disclosure, write a short note listing which tool you used, for which parts and what you verified yourself. If the policy is silent, disclose anyway. A two-line note in your README costs nothing, and an undisclosed tool found later costs a lot.

Keep your trail. Save PLAN.md, PREDICTIONS.md, your test file and your git history. Together they show your process, which is worth more in a viva than the code.

Debugging fallback. If something still fails late, follow a structured routine instead of re-prompting blindly. The guide on debugging AI-generated code in VS Code is built for that moment.

Conclusion

Your project is only as good as your ability to explain it, so build the explaining into the workflow from day one. Write PLAN.md first, ask for small changes, predict before you run, test with pytest and read every diff.

If you want an AI coding assistant for students in India that fits this habit, install OxCode in VS Code, Cursor or another VS Code-based editor and start on the Free plan with its 15 runs a day. Spend your first run on a single task from your own PLAN.md, approve each command after reading it, and rerun pytest yourself when it finishes. By your next viva, you should be able to explain every line it touched.