Using AI Well as a Developer

A practical guide for developers

01 / AI Fundamentals

What is AI?

AI works by guessing the next word. It reads your text, guesses what comes next, adds it — then guesses again.

Your prompt → AI model
guess next word → Response ↻ repeats

It does not look up facts. It writes what sounds right. That's why it's useful — and why it can be wrong.

Think of it like autocomplete that has read the whole internet.

Go deeper: 3Blue1Brown — But what is a GPT? The Illustrated Transformer OpenAI Tokenizer

01 / AI Fundamentals

Tokens & the context window

Two words you'll hear a lot. Once they click, AI makes more sense.

TOKEN

A token is a piece of a word — about ¾ of a word in English. AI counts cost and limits in tokens, not words.

"unhappiness" → un · happi · ness = 3 tokens

CONTEXT WINDOW

Everything the AI can see right now — fixed size:

…earlier chat falls out ✕

System rules

Files you pasted

Your question ← new in

New text enters the bottom. When it's full, the oldest falls out — the AI "forgets" it.

Claude holds ~1M tokens — about a whole codebase. Big, but still has a limit.

Tip: paste only the file you need, not the whole project. New topic? Start a new chat — a clean window works better.

More: See text turn into tokens — OpenAI Tokenizer Claude — Context windows

01 / AI Fundamentals

Models & effort

Same question, different settings → different answer. You pick the settings.

Model size

Small
fast & cheap ↔ Large
smarter, but slower & costs more

Use the smallest model that still does the job. No need for the biggest model to rename a variable.

Effort

How much the AI thinks before it answers.

Low effort Question→Answer High effort Question→[ thinks… ]→Answer

LOW EFFORT

Fast, first answer. Good for simple tasks — rename, format, a quick question.

HIGH EFFORT

Thinks step by step first. Good for hard problems — tricky bugs, design, logic.

Tip: simple task? Low effort — fast & cheap. Hard problem? Let it think.

More: Claude — Effort

01 / AI Fundamentals

What AI is good and bad at

It guesses, it doesn't remember. That's why it's good at some things and bad at others.

GOOD AT

Repetitive, boilerplate code
Explaining code you don't understand
Rewriting code from one language to another
First drafts, cleanups, tests

BAD AT

Exact math and counting
New facts it was never trained on
Your private code it has never seen
Anything it says with confidence but you haven't checked

Rule: if it sounds like a fact — a name, a number, a version — check it. More on that later.

02 / AI Tools & Claude

AI tools across the dev loop

Lots of AI tools out there. Each fits a different part of your day.

Step	AI helps with	Tools (e.g.)
Understand	explain code, answer questions	ChatGPT, Claude, Cursor
Write	autocomplete, generate code	GitHub Copilot, Cursor, Windsurf
Build / refactor	multi-file edits, run commands	Claude Code, Cursor, Codex
Test & review	write tests, find bugs, PR text	Claude, Copilot, CodeRabbit

Different jobs, different tools. Today we go deep on Claude.

02 / AI Tools & Claude

Chat vs agent

Two ways to use Claude.

Chat You ask→Claude answers→you do the next step Agent You give a goal→Claude reads, runs, edits, repeats→done

CHAT

Quick questions, explaining code, small snippets. You drive each step.

AGENT (Claude Code)

Give it a goal — it works across many files on its own, then hands back the result.

Chat answers. Agent does. You still own what it ships.

02 / AI Tools & Claude

CLAUDE.md

Give Claude your project's context — once.

A file named CLAUDE.md in your repo. Claude reads it every session, so you don't repeat yourself.

# CLAUDE.md Stack: Next.js + TypeScript, use pnpm Test: pnpm test Avoid: never edit /generated

Keep it good

Start with /init — it writes a draft for you.
Keep it short. Too long → Claude ignores it.
Add what Claude can't guess. Skip what it can read in the code.
Commit it, so your team shares it.

Write it once. Claude remembers it every chat in this project.

More: Claude Code — Best practices

02 / AI Tools & Claude

Where CLAUDE.md lives

Drop a CLAUDE.md at different levels. Claude reads them all and stacks them.

Why it helps: shared team rules and your personal ones live side by side, no conflict.

~/.claude/CLAUDE.md all your projects (personal) my-app/ ├─ CLAUDE.md this project — commit, team shares ├─ CLAUDE.local.md just you — add to .gitignore └─ backend/ └─ CLAUDE.md extra rules, only in this folder

One file can pull in others: @README.md, @docs/api.md.

Closer to the code = more specific. Claude stacks them: general → specific.

02 / AI Tools & Claude

Commands & skills

Bottle a task once, reuse it forever — two ways to do it.

COMMANDS

Shortcuts you trigger by name. Write a prompt once, run it anytime.

/review → check security + tests /test → write tests for a file

Lives in .claude/commands/review.md

SKILLS

A folder that teaches Claude a repeatable task. Loads itself when the task matches.

e.g. "make a .docx" → loads your doc formatting rules.

Lives in .claude/skills/<name>/SKILL.md

	Command	Skill
Who triggers it	You	You + Claude
What it is	a prompt	a folder

Same idea — a skill is a command's bigger sibling Claude can trigger too.

More: Claude Code — Commands Claude Code — Skills

02 / AI Tools & Claude

Handy ones to know

Type / in Claude Code to see them all. A few you'll reach for:

COMMANDS (built-in)

/init — write a starter CLAUDE.md
/clear — wipe context, start fresh
/compact — shrink a long chat
/simplify — tidy up the code you changed
/model — switch model

SKILLS (bundled)

/code-review — find bugs in your diff
/security-review — check for vulnerabilities
/debug — diagnose a problem
doc skills — make .xlsx .docx .pptx .pdf

Built-ins save time. Your own commands & skills save your team's habits.

More: Claude Code — Commands Claude Code — Skills

02 / AI Tools & Claude

Always-on vs load-on-demand

	CLAUDE.md	Skills
Loaded	Always, every session	Only when the task matches
Scope	One project	Reusable anywhere
Answers	"What is this project?"	"How do I do this task?"
Format	One file	A folder (instructions + files)
Best for	Standing project context	Specific repeatable procedures

Why NOT a massive CLAUDE.md

Always loaded — every line costs tokens & context, every message.
More rules = weaker adherence — critical instructions get diluted by trivial ones.
It goes stale — nobody maintains a 300-line file; Claude then follows rules that aren't true.

Rule of thumb: true all the time → CLAUDE.md. Only sometimes → a skill or the prompt. Aim for ~20-40 focused lines.

03 / Prompting

The 4-part formula

1. ROLE
the lens→ 2. CONTEXT→ 3. TASK→ 4. FORMAT

WORKED EXAMPLE — all four parts

Role: Act as a React performance reviewer. Context: My dashboard re-renders infinitely. useEffect depends on a filter value held in useState. Task: Find the bug, fix it, explain the cause in one sentence. Format: Fixed code first, then the explanation.

POWER MOVES

"Think step by step first"
"Give 3 options with tradeoffs"
"What are you assuming about my code?"

AVOID

"fix this" with no code
pasting 500 lines with no context
accepting the first answer blindly

Iterate: the first answer is a draft. Follow up: "good, but handle the null case" / "make it more concise."

03 / Prompting

Why the formula works

Each part removes a different kind of ambiguity. The model guesses less, so the answer gets more useful.

ROLE Viewpoint, tone, depth, tradeoffs. Senior React reviewer.

CONTEXT Facts it should not guess. Next.js bug after filter change.

TASK Exact job + success criteria. Find root cause + smallest fix.

FORMAT Output shape you can use. Code first, then one-sentence why.

Template: Role: Act as a [specific reviewer / expert]. Context: [facts, code, constraints, errors]. Task: [what to do + what success means]. Format: [exact output shape].

Mismatch: frontend role + DB schema still answers, but may over-focus UI/API and miss backend details. Role = viewpoint, not skill lock.

Go deeper: OpenAI — Prompting Anthropic — Prompting best practices Google Cloud — Introduction to prompting

03 / Prompting

Choose the prompt language

Match the language to the job.

Metric	English	Thai
Tokens per sentence	baseline (1x)	~4.3x more
Tokens per word	~0.75	2-3x higher
Accuracy on hard tasks	baseline	up to ~24% lower

Code, errors, docs, API names → English. Learning, planning, discussion → Thai is fine. Paste error messages as-is.

Research: SeaLLMs — arXiv 2312.00738 Typhoon Thai LLM — PDF MMLU-ProX — multilingual benchmark Low-resource token dynamics

04 / Verification

Looks right isn't always right

AI can sound sure and still be wrong. Treat every answer as a draft until checks pass.

FAKE API Looks real, but does not exist. check docs

VERSION Old and new syntax get mixed. check package.json

LOGIC Confident answer, broken behavior. npm test

DIFF Unexpected files or broad edits. git diff

CI Types, lint, tests must pass. typecheck + lint

It's not wrong every time — that's the danger. You can't tell when, so check every time.

04 / Verification

Catch it in action

AI hands you this. It looks fine.

const reversed = str.reverse();

Run it →

TypeError: str.reverse is not a function

Strings have no .reverse() — it only looked real. The fix:

const reversed = [...str].reverse().join("");

A 30-second run beats an hour debugging in prod.

05 / Responsible Use

Use it well, use it safely

LIMITS Don't lean on AI for things you can't check, own, or review. auth, payments, security

DATA Never paste secrets, customer data, or private code into public AI. use approved tools

BAD: const key = 'sk-live-abc123...' GOOD: const key = process.env.API_KEY

AI is the assistant. You are the engineer. You own what you ship.

06 / Adapt as a Developer

The daily dev loop with AI

1. Understand
the codebase→ 2. Debug
with AI→ 3. Tests
& docs→ 4. PR desc
& review

EXAMPLES — three prompts = one full loop

1. "Explain what this function does and what could go wrong." 2. "Write a Jest test covering the happy path + 2 failure cases." 3. "Write a PR description: what changed, why, how to test. <100 words."

EVERYDAY WINS

Explain confusing error messages
Rubber-duck debugging 2.0
Review your code before you push
"Explain like I'm new, then show an example"

WHAT CHANGES

AI handles boilerplate; you handle judgment, architecture & tradeoffs. The skill shifts from writing code to knowing what good looks like.

AI doesn't replace developers who understand the problem. It replaces time spent on boilerplate.

Demo

Try the full loop in a small repo

The demo uses a tiny project so everyone can practice the same workflow without touching production code.

Read
the code→ Ask AI
for help→ Make a
small change→ Run checks
& review diff

WHAT TO PRACTICE

Give AI enough context before asking for code
Keep the task small and easy to review
Run the app or tests before trusting the answer

THE RULE

Use AI to move faster, then verify like the owner of the code.

Open demo repo →

The goal is not a perfect AI answer. The goal is a better developer loop.

Wrap-up

Take three things with you

USE IT

Pick the right tool, give it context, let it draft the boring parts.

VERIFY IT

Looks right isn't right. Run it, check it — every time.

OWN IT

AI assists. You're the engineer. You ship it, you answer for it.

Open Claude today. Try one thing from this talk on real work.