Skip to content
AI Newbie
Menu
Step 1 of 86 min read

Read what your AI coding tool is telling you

Newbie to Tech · Step 1 of 8 · about 5 minutes to read, 10 minutes to do Works with Kiro, Codex, Claude Code or Antigravity. Haven't set up yet? Do Step 0 first. Practice project: https://github.com/jazken/mood-habit-tracker · branch: main (the starter)

Do this now (you can read the rest after)

  1. Open your tool in the mood-habit-tracker folder from Step 0. Stay on the main branch.
  2. Ask it:
I'm new to coding. Please explain index.html in this folder.
Don't change anything. Use short sentences.
Explain it in 3 parts: the style, the page (HTML), and the script.
Explain any tech word in one line.
  1. While it works, spot the 5 kinds of messages below. (It may only show 1 or 2 of them this time. That's fine.)
  2. Whenever a message confuses you, paste this:
Explain what you just did in plain words, like I'm new to coding.
Use short sentences. Tell me:
1. What you changed or ran
2. Why
3. What I should check
4. If anything could go wrong
Explain any tech word in one line.

Check you did it: answer these 3 questions in your own words.

  1. Where are the habit names written? (Hint: look for "Drink water".)
  2. What does the script do when you tap a button?
  3. Why are your taps gone when you refresh the page?

Then write down 3 new words you learned, and what each one means.


Why this matters

AI coding tools talk fast, and they use lots of tech words. Many people just click "yes" and hope. You don't have to. Every tool uses different names, but almost every message is one of 5 kinds. Once you can spot which kind it is, you know what to do next.

What's inside index.html

Your tool should tell you something like this. If it doesn't, ask.

PartWhereWhat it does
StyleBetween <style> and </style> at the topColours, sizes and layout. Big buttons, so a thumb can tap them
Page (HTML)Between <body> and <script>The words and buttons you see: the moods, the habits, the note
ScriptBetween <script> and </script> at the bottomThe actions. It shows today's date and marks the button you tap

The file is full of comments: notes for humans that the browser skips. In HTML they look like <!-- … -->. In the script they start with //. Read them. They explain the code in plain words.

The 5 kinds of messages

1. A plan: "Here's what I'm going to do"

Before a big job, a good tool writes a plan first.

What you do: read it. Does it match what you asked for? If not, say so now. It's much easier to fix a plan than to fix finished code.

In your tool

  • Kiro: a spec, made of three files: requirements.md (what it should do), design.md (how) and tasks.md (a to-do list).
  • Claude Code: switch to Plan mode to get a plan before any edits.
  • Antigravity: in Planning mode, you get an implementation plan. Click Proceed, or comment and click Review.
  • Codex: set it to read-only with /permissions, then ask: "Plan this, don't change anything yet."

2. A file change: "I edited these files"

The tool shows a diff. That's a before-and-after view of a file.

  • Lines starting with + (often green) were added.
  • Lines starting with − (often red) were removed.

What you do: look at which files changed. Did it touch files you didn't expect? Ask why.

3. A command: "I'm going to run this"

A command is a typed instruction to your computer. It runs in the terminal, a text window where you talk to the computer by typing. For example, git status shows what changed in your project. This project needs no installs, so you won't see many commands yet.

After the command runs, you see its output: the text the computer prints back. What you do: if you don't know what a command does, ask before you allow it.

4. An error: "Something went wrong"

Errors look scary, with lots of red text. Much of it may be a stack trace: a list of where in the code things went wrong. The useful part is usually the first or last line.

What you do: don't panic. Ask: "What does this error mean in plain words, and what's the fix?" Errors are normal. Experts get them all day.

5. Asking for your OK: "May I?"

Good tools stop and ask before they do something big.

What you do: while you're learning, say yes just this once, or no. Don't choose "always allow" for things that delete files, send your work online (git push), or use sudo (admin power).

In your tool: the "ask me first" setting

  • Kiro: use Supervised mode (Autopilot is the default). Commands ask Allow / Deny, sometimes with Always allow / Always deny.
  • Claude Code: use Manual mode. Newer versions may start in auto mode. Press Shift+Tab in the terminal to switch.
  • Antigravity: set the review policy to Request review. Permission rules are Deny / Ask / Allow.
  • Codex: the Auto preset edits and runs commands inside your folder without asking. It asks before going outside the folder or using the internet. For "look, don't touch", pick read-only with /permissions.

Safety net: most tools can undo their own file edits:

  • Kiro: checkpoint → Restore
  • Claude Code: /rewind, or press Esc twice

The undo doesn't always cover changes made by commands the tool ran. The surest undo is a Git commit, which you'll learn in Step 3. Codex's own docs say to make Git checkpoints before and after a task.

Your word list (12 words you'll see a lot)

WordWhat it means
Repo (repository)A project folder that Git keeps track of
File treeThe list of folders and files on the side of the screen
DiffBefore-and-after view of a change: + added, − removed
TerminalA text window where you type commands to the computer
CommandOne typed instruction, like git status
OutputWhat the computer prints back after a command
HTMLThe words and buttons on a web page
ScriptCode that makes the page do things when you tap
CommentA note in the code for humans. The computer skips it
Error / stack traceA message saying what broke, and where
BranchA separate line of work, so you can try things safely
CommitA saved snapshot of your changes, with a short note

When you still don't understand

That's fine. Try these, in order:

  1. Ask the tool using the prompt at the top.
  2. Ask for an example: "Show me one button from index.html and explain each part."
  3. Ask for a picture in words: "Explain it like a recipe."
  4. Look it up: https://docs.github.com/en/get-started/learning-about-github/github-glossary

One rule: the AI can be wrong, even when it explains things. If it matters, like deleting files or sending work online, check with a person or the docs first.

Go deeper (pick your tool's docs)

Next: Step 2, Stay in control: plans, approvals, undo.

After you try it

Did this produce something you could use, and what did you have to correct?

Email a reply, or keep a note for yourself. The useful part is the correction — that is the skill, not the first draft.

Email hello@ainewbie.org

Get the AI Newbie Brief