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)
- Open your tool in the
mood-habit-trackerfolder from Step 0. Stay on themainbranch. - 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.
- While it works, spot the 5 kinds of messages below. (It may only show 1 or 2 of them this time. That's fine.)
- 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.
- Where are the habit names written? (Hint: look for "Drink water".)
- What does the script do when you tap a button?
- 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.
| Part | Where | What it does |
|---|---|---|
| Style | Between <style> and </style> at the top | Colours, 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 |
| Script | Between <script> and </script> at the bottom | The 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) andtasks.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)
| Word | What it means |
|---|---|
| Repo (repository) | A project folder that Git keeps track of |
| File tree | The list of folders and files on the side of the screen |
| Diff | Before-and-after view of a change: + added, − removed |
| Terminal | A text window where you type commands to the computer |
| Command | One typed instruction, like git status |
| Output | What the computer prints back after a command |
| HTML | The words and buttons on a web page |
| Script | Code that makes the page do things when you tap |
| Comment | A note in the code for humans. The computer skips it |
| Error / stack trace | A message saying what broke, and where |
| Branch | A separate line of work, so you can try things safely |
| Commit | A saved snapshot of your changes, with a short note |
When you still don't understand
That's fine. Try these, in order:
- Ask the tool using the prompt at the top.
- Ask for an example: "Show me one button from index.html and explain each part."
- Ask for a picture in words: "Explain it like a recipe."
- 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)
- Kiro: https://kiro.dev/docs/
- Codex: https://learn.chatgpt.com/docs/agent-approvals-security
- Claude Code: https://code.claude.com/docs/en/permission-modes
- Antigravity: https://antigravity.google/docs/artifact-review
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