AI Coding Assistant for Beginners: First Setup

Last updated: August 2026

By the end of this walkthrough you will have an AI coding assistant installed in your terminal, and you will have used it to build and run one real Python script: a small CLI tool that reads a CSV file and prints a summary. You will write the prompt, watch the assistant produce the code, read what it wrote, run it, and tighten its permissions so it cannot touch anything you did not approve. The whole thing takes about 20 minutes the first time. The point is not the script. The point is the loop: ask, read, run, verify, repeat. That loop is the skill, and you build it on the first task.

I am using Claude Code for this guide because it runs in the terminal, shows you every file it touches, and asks before doing anything destructive, which makes it a good place to learn the habit of reviewing AI output instead of trusting it blindly. Copilot and Cursor are the other two names you will see, and both are good tools, but they sit inside an editor and hide more of what they are doing, which is the wrong default while you are still building the habit of checking the output.

What you need before starting

• A terminal you are comfortable opening (Terminal on macOS, Windows Terminal or WSL on Windows, any shell on Linux)
• Node.js 18 or later installed (check with node --version)
• Python 3.10 or later installed (check with python3 --version)
• A Claude.ai Pro account or an Anthropic Console account with billing set up
• A new empty folder to work in, so the assistant cannot touch anything important

Step 1: Install Claude Code and sign in

Open your terminal and install the assistant as a global npm package. Per the official setup docs, do not put sudo in front of this, since that causes permission headaches later.

npm install -g @anthropic-ai/claude-code

When that finishes, make a clean folder for this exercise and start the assistant inside it. Starting inside a fresh, empty folder is deliberate: the assistant can only see and edit files in the directory you launch it from, so an empty folder means it cannot wander into your real projects.

mkdir csv-summary && cd csv-summary
claude

The first run opens a sign-in flow in your browser. Log in with your Claude.ai or Console account, approve the connection, and return to the terminal. You should land at a prompt that looks like this:

Welcome to Claude Code

cwd: /Users/you/csv-summary
>

Checkpoint: You see the > prompt and the cwd line points at your new empty folder, not your home directory.

Step 2: Give it one real, specific task

Beginners tend to type something vague like "make a data tool." Vague prompts get vague code. Give the assistant a concrete task with the inputs, the output, and the constraints spelled out. Type this at the > prompt:

Create a Python script called summary.py that takes a CSV file path as a
command-line argument, reads it with the standard library csv module (no
pandas), and prints the number of rows, the column names, and for each
numeric column the minimum, maximum, and average. Then create a small
sample.csv I can test it with. Do not install any packages.

Notice what that prompt does. It names the file, names the input (a CSV path as an argument), names the output (row count, columns, per-column stats), and sets two hard constraints (standard library only, no installs). The assistant will think for a few seconds, then propose creating summary.py and sample.csv.

Checkpoint: The assistant shows you a plan or a diff for two new files, summary.py and sample.csv, and pauses to ask before writing them.

Step 3: Read the diff before you accept it

This is the step beginners skip, and it is the most important one. When the assistant proposes a file, it shows you a diff and waits for you to approve. Do not just hit yes. Read it. You are looking for three things: does it actually use argparse or sys.argv to take the file path, does it use the csv module like you asked, and did it sneak in an import pandas despite your instruction. A reasonable summary.py looks roughly like this:

import csv
import sys
from statistics import mean

def summarize(path):
    with open(path, newline="") as f:
        rows = list(csv.DictReader(f))
    if not rows:
        print("File is empty.")
        return
    columns = list(rows[0].keys())
    print(f"Rows: {len(rows)}")
    print(f"Columns: {', '.join(columns)}")
    for col in columns:
        values = []
        for r in rows:
            try:
                values.append(float(r[col]))
            except ValueError:
                pass
        if values:
            print(f"{col}: min={min(values)} max={max(values)} avg={mean(values):.2f}")

if __name__ == "__main__":
    if len(sys.argv) != 2:
        print("Usage: python3 summary.py <file.csv>")
        sys.exit(1)
    summarize(sys.argv[1])

If you cannot yet read this line by line, that is fine, that is exactly what learning looks like. Ask the assistant to explain any line you do not understand before you accept it. A good prompt is "explain the try/except block in summarize, why is it there." Reading and questioning the code is where the learning happens, not in the accepting.

Checkpoint: You have read the proposed summary.py, you confirmed it uses the csv module and no pandas, and you accepted both files.

Step 4: Run the code yourself and verify the output

The assistant can write code. It cannot tell you the code is correct. Only running it can do that. Approve the files, then run the script against the sample CSV from your own terminal:

python3 summary.py sample.csv

You should see something like this, with numbers that match your sample.csv:

Rows: 4
Columns: name, age, score
age: min=22.0 max=41.0 avg=31.50
score: min=78.0 max=95.0 avg=86.25

Now verify it by hand. Open sample.csv, count the data rows yourself, and confirm the row count matches. Pick the age column and check that the min and max really are the smallest and largest values in the file. This 30-second manual check is the entire discipline. If the assistant miscounted or skipped the header row, you catch it here, not in production. If the numbers are wrong, tell the assistant exactly what you expected versus what you got, and it will fix the bug.

Checkpoint: The script runs without an error and the row count and at least one min/max match what you counted by hand.

Step 5: Iterate with a follow-up change

Real work is never one prompt. Now extend the tool to prove you can drive a change through the same loop. Back at the > prompt, ask:

Add a --top flag that takes a number N and also prints the N rows with
the highest value in the score column, sorted highest first. Keep using
only the standard library.

Read the new diff the same way you did in Step 3, accept it, then run and verify again:

python3 summary.py sample.csv --top 2

Confirm it prints exactly two rows and that they really are the two highest scores in your file. You just completed a full edit cycle: request, review, run, verify. That is the same cycle professional developers run dozens of times a day. The tools get more powerful, but the loop does not change.

Checkpoint: The --top 2 output shows the two highest-scoring rows and you confirmed them against the file.

Step 6: Lock down permissions so the assistant cannot surprise you

By default Claude Code asks before editing files or running shell commands, which is what you want while learning. But you can make those guardrails explicit and persistent so you are never one stray keystroke away from auto-approving everything. Create a project settings file in your folder:

mkdir -p .claude

Then ask the assistant to write a restrictive config, or create .claude/settings.json yourself with this content:

{
  "permissions": {
    "allow": ["Read"],
    "ask": ["Edit", "Write", "Bash"]
  }
}

This says: reading files is fine without asking, but every edit, file write, and shell command must stop and get your approval. The permission modes documentation covers the full set of modes, including plan mode, which lets the assistant propose a plan without touching anything. As a beginner, stay in a mode that always asks. The convenience of auto-approval is a trap this early: the whole point of these first tasks is that you see and approve every change.

Checkpoint: Your folder contains .claude/settings.json, and the next edit or command the assistant tries triggers an explicit approval prompt.

Where this breaks

The claude command is not found after install. This almost always means your npm global bin folder is not on your PATH, or Node is older than version 18. Run node --version first. If Node is fine, run npm config get prefix to find where global packages land, and make sure that folder's bin directory is on your PATH. Reopening the terminal after fixing PATH is the step people forget.

The script errors with "No such file or directory." You are running python3 summary.py sample.csv from a different folder than the one the files were created in. Run ls (or dir on Windows) and confirm both summary.py and sample.csv are listed before you run the script. The assistant creates files in the folder you launched it from, nowhere else.

You accept every diff without reading it. This is the real failure mode, and it is invisible because the code usually works. If you find yourself hitting yes reflexively, slow down and force the habit: for the first month, type the line "I read this" before accepting any diff. The students who build real skill are the ones who can explain what the assistant wrote, not just run it. If you want the deeper argument for why active reading beats passive accepting, our Python for adults guide makes the case.

The output numbers look wrong but you are not sure. Trust your hand-count over the assistant. If the row count is off by one, the usual culprit is the header row being counted as data, or a trailing blank line in the CSV. Tell the assistant the exact discrepancy ("you reported 5 rows, I count 4 data rows plus a header") and it will correct the logic. Vague feedback like "the count is wrong" gets vague fixes, so the prompting skill from prompt engineering for professionals pays off here too.

What to build next

The natural next step is to point this same loop at a larger task: a multi-file project where the assistant edits several files at once and runs your tests. Our Claude Code tutorial walks through a bigger build with the same ask-read-run-verify discipline, and once you are comfortable there, how to use Claude at work shows how to fold these tools into real day-to-day tasks.

If you want to build this with someone watching your screen and catching mistakes in real time, that is literally what my sessions are. Book a free Discovery Call and bring this project to it.

These tutorials come from the actual curriculum I teach 1-on-1. Every code block is tested before it ships.