Milestone path

Use this page as the learner route through the curriculum. The lessons are the source material. The milestones tell you what you should be able to do before moving on.

You do not need to feel ready before you start. Keep the first project small, work in public artifacts, and let proof decide when a milestone is complete.

The path at a glance

Milestone 0: Get oriented

Usefulness: this milestone keeps beginners from treating the agent like a black box.

You are not trying to become an AI researcher here. You are learning just enough to make better choices in the next milestone:

• what to ask the agent to do,
• what context to give it,
• when a task needs retrieval, tools, vision, or a normal coding pass,
• when a local or open-weight model might matter,
• what risks to check before you let the tool edit a repo.

If you already know LLMs, agents, RAG, context windows, open weights, and multimodal models, skim this milestone and move to Milestone 1. If those terms are fuzzy, spend 30 to 60 minutes here. It will make the rest of the course much easier.

If Git, terminal commands, or programming language basics are the harder part, start with Beginner prep: Git, terminal, and language basics first.

Read:

• The AI map
• LLMs: just enough to be dangerous
• What makes an agent
• Multimodality
• The model zoo

Do this:

mkdir -p agentic-course/artifacts
cd agentic-course
cat > artifacts/00-orientation.md <<'EOF'
# Orientation

What is an LLM?
What makes a workflow agentic?
What should stay in context?
When would I use a frontier model?
When would I use a local or open-weight model?
What is one risk I need to watch?
EOF

You are ready to move on when you can explain the answers without copying the lesson text.

Milestone 1: Get comfortable in the CLI

Usefulness: this milestone makes the terminal agent feel like a normal workbench instead of a strange chat box.

By the end, you should know how to start the tool, stop it, approve or reject work, give it repo instructions, add one small reusable procedure, and use that setup to build one tiny thing. Claude Code is the main path in the course. Use CLI variants if your room is using Codex CLI, Gemini CLI, or Coco.

Read:

• What is agentic engineering?
• Install your tool
• Your first session
• Staying in control
• Context and the second brain, just the CLAUDE.md / AGENTS.md setup
• The no-slop standard, just the skill/checklist idea

1. Start the CLI in a real repo

Do this in a repo you can safely inspect:

git status --short

# start your selected tool
claude
# or: codex
# or: gemini

Ask the agent to inspect the project and summarize how to run it. Do not ask it to make a large change yet.

Use this prompt:

Read this repo and orient me.

Tell me:
1. what the project does,
2. how to run it,
3. how to test it,
4. the files I should understand first,
5. what you would avoid changing without permission.
Do not edit files yet.

2. Learn the CLI controls

Before you let the agent edit anything, make sure you can answer this:

The exact command surface changes. The habit does not: start in the repo, ask for orientation, approve carefully, read the diff, run proof.

3. Add project instructions

The agent should not have to rediscover your repo rules every session. Add the first instruction file now.

For Claude Code:

cat > CLAUDE.md <<'EOF'
# Project instructions

What this project does:
Main commands:
- run:
- test:
- lint:

Repo rules:
- Ask before changing dependencies.
- Keep changes small and reviewable.
- Show `git diff` before calling work done.
- Include the proof command or manual check used.

Do not touch:
- secrets
- production data
- generated files
EOF

For Codex or mixed-tool teams:

cat > AGENTS.md <<'EOF'
# Project instructions for agents

What this project does:
Main commands:
- run:
- test:
- lint:

Repo rules:
- Ask before changing dependencies.
- Keep changes small and reviewable.
- Show `git diff` before calling work done.
- Include the proof command or manual check used.

Do not touch:
- secrets
- production data
- generated files
EOF

If your team uses both, keep AGENTS.md as the tool-neutral source and copy or symlink the relevant parts into CLAUDE.md.

4. Add one tiny skill or checklist

A skill is a reusable procedure. Use one when you have a repeated habit you want the agent to follow the same way every time.

For Claude Code, project skills can live under .claude/skills/<skill-name>/SKILL.md. Start with a tiny review skill:

mkdir -p .claude/skills/review-diff
cat > .claude/skills/review-diff/SKILL.md <<'EOF'
---
name: review-diff
description: Use when reviewing agent-created code changes before the user accepts them.
---

# Review diff

When this skill is used:

1. Run `git status --short`.
2. Run `git diff`.
3. Summarize changed files in plain English.
4. Flag risky changes, unrelated edits, missing tests, and unclear behavior.
5. Name the proof command that should run next.
6. Do not say the work is done unless proof exists.
EOF

If your CLI does not support skills, make the same content a checklist:

mkdir -p agent-checklists
cp .claude/skills/review-diff/SKILL.md agent-checklists/review-diff.md

Then tell the agent:

Use the review-diff skill or checklist before I accept this change.

5. Build one tiny thing with the setup

Now use the CLI, instruction file, and review skill together. Pick a change small enough to finish in one sitting:

• fix one typo in UI copy,
• add one log line,
• add one README example,
• add one CLI flag,
• add one validation check,
• add one tiny test.

Use this prompt:

Using the project instructions, make one tiny improvement that can be reviewed in under ten minutes.

Before editing:
1. tell me the file you plan to touch,
2. tell me the proof command or manual check,
3. wait for my approval.

After editing:
1. show the diff summary,
2. run or name the proof,
3. use the review-diff skill or checklist before saying it is ready.

After the change, read the diff yourself:

git status --short
git diff

6. Centralize the lesson

Capture:

• What command starts the project.
• What command tests it.
• What files look important.
• What permission mode you used.
• What you would not let the agent change without review.
• Whether you used CLAUDE.md, AGENTS.md, or both.
• The first skill or checklist you added.
• What tiny thing you built with it.
• What the agent got wrong or needed to be told.
• Where you centralized that lesson for the next run.

This centralization step is the feedback mechanism. If the agent missed the test command, add it to CLAUDE.md or AGENTS.md. If the review checklist caught something useful, improve the skill. If the project has a repeated workflow, turn it into a playbook. The point is that every learner makes the shared instructions better, so the next person starts ahead instead of repeating the same correction.

You are ready to move on when you can start the CLI, orient it on a repo, build one tiny change, inspect the diff, and point to the shared instruction or skill update that will help future sessions.

Milestone 2: Pick a real slice

This is where the course becomes yours. Pick one project you care about enough to finish, but small enough that the first version can be boring.

Good first slices:

• Add one command to a CLI.
• Fix one bug and add one regression test.
• Build one small internal utility.
• Clean one dataset and write one validation check.
• Add one route, one screen, or one report.

Write the brief before you build:

cat > artifacts/01-project-brief.md <<'EOF'
# Project brief

Problem:
Smallest useful slice:
Inputs:
Output:
Done check:
Proof command:
Risk to review:
What I will not change in this slice:
EOF

Use Data + AI practice labs if you do not have a project yet. Start with Lab 12 for a mixed or beginner room.

You are ready to move on when the project fits on one page and the done check is not a feeling.

Milestone 3: Build with control

This is the first real build loop: plan, edit, review, prove, ship.

Read:

• Plan before you build
• Build it, step by step
• Ship it

Run the loop:

git status --short

# after the agent proposes or makes a slice
git diff

# run the proof for your project
npm test
# or: pytest
# or: make test
# or: your project-specific check

Capture:

• The plan you approved.
• The diff you accepted.
• The proof command output.
• One thing you rejected or changed.
• The next smallest slice.

You are ready to move on when another person can read your proof and understand what shipped.

Milestone 4: Make quality repeatable

Agentic work gets useful when quality is not based on memory or luck. This milestone adds the standards.

Read:

• The brief
• Evals
• Context and the second brain
• The no-slop standard
• Design discipline

Install the working artifacts:

mkdir -p decisions
touch AGENTS.md HANDOFF.md artifacts/eval.md artifacts/review.md artifacts/design-note.md

If you use Claude Code, CLAUDE.md can sit next to or instead of AGENTS.md. If you use Codex, keep AGENTS.md as the main instruction file.

Capture:

• A better brief for the next slice.
• At least one eval or test.
• A project context file the agent can read.
• A no-slop review note.
• A design note if the work has a user-facing surface.

You are ready to move on when a fresh agent session can read the project context and give back a useful summary.

Milestone 5: Scale the workflow

Now you are no longer asking one agent for one answer. You are coordinating work.

Read:

• Orchestration
• Review gates
• Where to go next

Try one parallel plan:

cat > artifacts/parallel-plan.md <<'EOF'
# Parallel plan

Goal:
Workstream A:
Workstream B:
Shared files:
Review gate:
Merge order:
Proof:
EOF

You are ready to move on when you can split work without losing review control.

Milestone 6: Operate in the real world

This is the customer, team, and production layer. You are learning how to make agentic work survive outside your laptop.

Read:

• The harness wars
• The application taxonomy
• Coordinating with agents and humans
• Staying current: the intel-watch pattern
• The team shape
• The problems in every layer
• Discovery and scoping the engagement
• Communicating to non-engineers
• Observability and cost discipline
• Security and compliance for AI products
• The handoff playbook

Build the final package:

mkdir -p decisions runbook
touch HANDOFF.md runbook/operate.md runbook/security.md runbook/cost.md

Your final walkthrough should answer:

• What problem did you solve?
• What did the agent do?
• What did you review?
• What proof exists?
• What risks remain?
• What would the next engineer do tomorrow?

You are done with the full path when someone else can clone the repo, read the handoff, run the proof, and continue the next slice without you sitting next to them.

Pick your pathway

Once the core loop is clear, choose the practice path that matches the learner.

Use Job pathways + AISOFT offerings when you want to translate the work into role readiness, portfolio stories, or team enablement.

How to use this with a mentor

Bring three things to every review:

• Your current artifact folder.
• The latest diff.
• The proof command or evidence.

The review is simple:

1. Show the brief.
2. Explain what the agent did.
3. Walk the diff.
4. Run or show proof.
5. Name the risk.
6. Write the next slice.

That is the whole course in miniature.