A project-based course on building the environment, state management, verification, and control mechanisms that make AI coding agents work reliably. > This course is available in 15 languages: English, 简体中文, 繁體中文, 日本語, 한국어, Español, Français, Русский, Deutsch, العربية, Tiếng Việt, Oʻzbekcha, Türkçe, Portuguese (BR), Українська. Choose your language from the badges above.
Tools
Tools
No tool list yet. Remote servers get one after the first health check.
Copy the stdio config for Cursor, Claude Desktop, Claude Code, or VS Code on this page. It uses the publisher's install, not a PlugMCP proxy.
Does Learn Harness Engineering need an API key?
No required environment variable is listed on this record.
What transport does Learn Harness Engineering use?
Learn Harness Engineering runs locally over stdio.
When was Learn Harness Engineering last checked?
Last checked 2026-11-11. A project-based course on building the environment, state management, verification, and control mechanisms that make AI coding agents work reliably. > This course is available in 15 languages: English, 简体中文, 繁體中文, 日本語, 한국어, Español, Français, Русский, Deutsch, العربية, Tiếng Việt, Oʻzbekcha, Türkçe, Portuguese (BR), Українська. Choose your language from the badges above.
From the publisher
Documentation
🆕 What's New — August 2026
Frontier Harness Design Breakdowns — new section (4 breakdowns)
What
Details
New section
Frontier Harness Design Breakdowns — Apply the course's five-subsystem framework (instructions, tools, environment, state, feedback) to reverse-engineer how four frontier products build real harnesses.
Pi
How Pi builds its harness — a minimal kernel, programmable expansion, and context engineering behind "ask Pi to build what you want."
Full translation coverage across all supported languages.
Key idea: The course gives you a framework; these breakdowns show you how the same principles actually play out in production harnesses.
Graph Engineering Update — 1 new lecture, 1 new project
What
Details
Lecture 14
From Single Loops to Graph Engineering — Why a single loop grows into a graph: the four stacked layers (prompt → context → loop → graph) and where harness sits in that stack, the four parts of a graph (nodes, edges, shared state, routing), why in-loop checkpoints can't fix the three structural failures at scale (Goodhart, blindness upward, conflict), a framework-agnostic six-step walkthrough for building your first graph, graph vs. workflow, anchors, which open-source "graph engineering" projects existed before the name vs. after it, the orchestration tax, and when a graph is actually worth drawing.
Project 08
Draw Your Workflow as a Graph — Three progressive experiments: draw your maker-checker loop as an explicit graph, add a parallel fan-out/fan-in node, then add a conditional rollback edge and a human-approval node.
Key idea: A loop is a graph with one node. When your task needs specialization, parallelism, shared state, verification, and recovery — it has stopped being a loop. It's a graph.
🆕 What's New — July 2026
Loop Engineering Update — 1 new lecture, 1 new project
What
Details
Lecture 13
Why You Need to Stop Prompting Your Agent — From /goal to the six primitives of loop engineering (automations, worktrees, skills, connectors, sub-agents, external state), the generator/evaluator split, four silent costs, and a step-by-step guide to building your first loop.
Project 07
Build Your First Automated Loop — Three progressive experiments: goal loop, timer loop, and maker-checker loop. Compare manual vs. automated, measure intervention reduction, and learn to step outside the loop.
Code templates
goal-template.md, loop-state-template.md, maker-prompt.md, checker-prompt.md — drop-in templates for building loops immediately.
All 15 languages
Full translation coverage across all supported languages.
Key idea: Harness engineering builds the vehicle. Loop engineering designs the road it drives on — and you design the road from outside the car.
Learn Harness Engineering is a course dedicated to the engineering of AI coding agents. We have deeply studied and synthesized the most advanced Harness Engineering theories and practices in the industry. Our core references include:
Quick start? The skills/harness-creator/ skill can help you scaffold a production-grade harness (AGENTS.md, feature lists, init.sh, verification workflows) for your own project in minutes.
A comprehensive course outline and introduction to core philosophies, providing a clear path to get started.
📖 Immersive Lectures
Deep dives into real-world pain points and hands-on projects (like Project 01) for an immersive learning experience.
🗂️ Ready-to-Use Resource Library
Templates and reference configurations designed to solve common pitfalls in multi-turn AI agent development, such as context loss and premature task completion.
PDF Coursebooks
The repository now includes a PDF build pipeline for the course content.
Run npm run pdf:build to generate the currently configured PDF coursebooks locally.
Output files are written to artifacts/pdfs/.
Run npm run screenshots:readme if you want to refresh the README preview images.
GitHub Actions workflow release-course-pdfs.yml can build the PDFs and publish them to GitHub Releases.
The Model Is Smart, The Harness Makes It Reliable
There's a hard truth most people learn the hard way: the strongest model in the world will still fail on real engineering tasks if you don't build a proper environment around it.
You've probably seen this yourself. You give Claude or GPT a task in your repo. It starts well — reads files, writes code, looks productive. Then something goes wrong. It skips a step. It breaks a test. It says "done" but nothing actually works. You spend more time cleaning up than if you'd done it yourself.
This isn't a model problem. It's a harness problem.
The evidence is clear. Anthropic ran a controlled experiment: same model (Opus 4.5), same prompt ("build a 2D retro game editor"). Without a harness, it spent $9 in 20 minutes and produced something that didn't work. With a full harness (planner + generator + evaluator), it spent $200 in 6 hours and built a game you could actually play. The model didn't change. The harness did.
OpenAI reported the same thing with Codex: in a well-harnessed repository, the same model goes from "unreliable" to "reliable." Not a marginal improvement — a qualitative shift.
This course teaches you how to build that environment.
THE HARNESS PATTERN
====================
You --> give task --> Agent reads harness files --> Agent executes
|
harness governs every step:
|
+--> Instructions: what to do, in what order
+--> Scope: one feature at a time, no overreach
+--> State: progress log, feature list, git history
+--> Verification: tests, lint, type-check, smoke runs
+--> Lifecycle: init at start, clean state at end
|
v
Agent stops only when
verification passes
What Harness Engineering Actually Means
Harness engineering is about building a complete working environment around the model so it produces reliable results. It's not about writing better prompts. It's about designing the system the model operates inside.
A harness has five subsystems:
┌────────────────────────────────────────────────────────────────┐
│ THE HARNESS │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌────────────────────┐ │
│ │ Instructions │ │ State │ │ Verification │ │
│ │ │ │ │ │ │ │
│ │ AGENTS.md │ │ progress.md │ │ tests + lint │ │
│ │ CLAUDE.md │ │ feature_list │ │ type-check │ │
│ │ feature_list │ │ git log │ │ smoke runs │ │
│ │ docs/ │ │ session hand │ │ e2e pipeline │ │
│ └──────────────┘ └──────────────┘ └────────────────────┘ │
│ │
│ ┌──────────────┐ ┌──────────────────────────────────────┐ │
│ │ Scope │ │ Session Lifecycle │ │
│ │ │ │ │ │
│ │ one feature │ │ init.sh at start │ │
│ │ at a time │ │ clean-state checklist at end │ │
│ │ definition │ │ handoff note for next session │ │
│ │ of done │ │ commit only when safe to resume │ │
│ └──────────────┘ └──────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────┘
The MODEL decides what code to write.
The HARNESS governs when, where, and how it writes it.
The harness doesn't make the model smarter.
It makes the model's output reliable.
Each subsystem has one job:
Instructions — Tell the agent what to do, in what order, and what to read before starting. Not one giant file; a progressive disclosure structure the agent navigates on demand.
State — Track what's been done, what's in progress, and what's next. Persisted to disk so the next session picks up exactly where the last one left off.
Verification — Only a passing test suite counts as evidence. The agent cannot declare victory without runnable proof.
Scope — Constrain the agent to one feature at a time. No overreach. No half-finishing three things. No rewriting the feature list to hide unfinished work.
Session Lifecycle — Initialize at the start. Clean up at the end. Leave a clean restart path for the next session.
Why This Course Exists
The question isn't "can models write code?" They can. The question is: can they reliably complete real engineering tasks inside real repositories, over multiple sessions, without constant human supervision?
Right now, the answer is: not without a harness.
WITHOUT HARNESS WITH HARNESS
============== ============
Session 1: agent writes code Session 1: agent reads instructions
agent breaks tests agent runs init.sh
agent says "done" agent works on one feature
you fix it manually agent verifies before claiming done
agent updates progress log
Session 2: agent starts fresh agent commits clean state
agent has no memory
of what happened before Session 2: agent reads progress log
agent re-does work agent picks up exactly where it left off
or does something else entirely agent continues the unfinished feature
you fix it again you review, not rescue
Result: you spend more time Result: agent does the work,
cleaning up than if you you verify the result
did it yourself
The questions this course actually cares about:
Which harness designs improve task completion rates?
Which designs reduce rework and incorrect completions?
Which mechanisms keep long-running tasks progressing steadily?
Which structures keep the system maintainable after multiple agent runs?
Lectures: 13 conceptual units explaining the theory behind harness engineering.
Projects: 7 hands-on projects where you build an agentic workspace from scratch.
Resource Library: Copy-ready templates (AGENTS.md, feature_list.json, init.sh, etc.) to use in your own repositories today.
Quick Start: Improve Your Agent Today
You don't need to read all 14 lectures before you start getting value. If you're already using a coding agent on a real project, here's how to improve it right now.
The idea is simple: instead of just writing prompts, give your agent a set of structured files that define what to do, what's been done, and how to verify the work. These files live inside your repo, so every session starts from the same state.
YOUR PROJECT ROOT
├── AGENTS.md <-- the agent's operating manual
├── CLAUDE.md <-- (alternative, if using Claude Code)
├── init.sh <-- runs install + verify + start
├── feature_list.json <-- what features exist, which are done
├── claude-progress.md <-- session progress (historical filename; agent-agnostic)
└── src/ <-- your actual code
Grab the starter templates from the Resource Library and drop them into your project. That's it. Four files, and your agent sessions will already be significantly more stable than running on prompts alone.
claude-progress.md is a generic, repository-local session progress log; the
name is retained for compatibility with the course examples. It is not tied to
Claude Code and is not updated automatically by any agent. Codex, OpenHands,
Antigravity, and other coding agents can use the same file when their root
instructions tell them to read it at startup and update it before handoff.
Capstone Project: A Real App
All six course projects revolve around the same product: an Electron-based personal knowledge base desktop app.
┌──────────────────────────────────────────────────────┐
│ Knowledge Base Desktop App │
│ │
│ ┌──────────────┐ ┌──────────────────────────────┐ │
│ │ Document List│ │ Q&A Panel │ │
│ │ │ │ │ │
│ │ doc-001.md │ │ Q: What is harness eng? │ │
│ │ doc-002.md │ │ A: The environment built │ │
│ │ doc-003.md │ │ around an agent model... │ │
│ │ ... │ │ [citation: doc-002.md] │ │
│ └──────────────┘ └──────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Status Bar: 42 docs | 38 indexed | last sync 3m │ │
│ └─────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────┘
Core features:
├── Import local documents
├── Manage a document library
├── Process and index documents
├── Run AI-powered Q&A over imported content
└── Return grounded answers with citations
This project was chosen because it combines strong practical value, enough real-world product complexity, and a good setting for observing before/after harness improvements.
Each course project's starter/solution is a complete copy of this Electron app at that evolutionary stage. P(N+1)'s starter is derived from P(N)'s solution — the app evolves as your harness skills grow.
Learning Path
The course is designed to be done in order. Each phase builds on the last.
Phase 1: SEE THE PROBLEM Phase 2: STRUCTURE THE REPO
======================== ==========================
L01 Strong models ≠ reliable L03 Repository as single
execution source of truth
L02 What harness actually means
L04 Split instructions across
| files, not one giant file
v
P01 Prompt-only vs. |
rules-first comparison v
P02 Agent-readable workspace
Phase 3: CONNECT SESSIONS Phase 4: FEEDBACK & SCOPE
========================== =========================
L05 Keep context alive L07 Draw clear task boundaries
across sessions
L08 Feature lists as harness
L06 Initialize before every primitives
agent session
|
| v
v P04 Runtime feedback to
P03 Multi-session continuity correct agent behavior
Phase 5: VERIFICATION Phase 6: PUT IT ALL TOGETHER
===================== ============================
L09 Stop agents from L11 Make agent's runtime
declaring victory early observable
L10 Full-pipeline run = L12 Clean handoff at end of
real verification every session
| |
v v
P05 Agent verifies its own work P06 Build a complete harness
(capstone project)
Phase 7: AUTOMATE THE LOOP
==========================
L13 Stop prompting your agent —
design loops instead
|
v
P07 Build your first automated loop
(goal loop, timer loop, maker-checker)
Phase 8: STRUCTURE THE SYSTEM
=============================
L14 Draw the system as a graph —
nodes, edges, shared state, routing
|
v
P08 Draw your workflow as a graph
(explicit graph, parallel fan-out/fan-in,
rollback edges, human-in-the-loop)
Each phase takes about a week if you're going part-time. If you want to go faster, phases 1–3 can be done in a long weekend.
Syllabus
Lectures — 14 conceptual units, each answering one core question
PROJECT EVOLUTION
=================
P01 Prompt-only vs. rules-first You see the problem
|
v
P02 Agent-readable workspace You restructure the repo
|
v
P03 Multi-session continuity You connect sessions
|
v
P04 Runtime feedback & scope You add feedback loops
|
v
P05 Self-verification You make the agent check itself
|
v
P06 Complete harness (capstone) You build the full system
|
v
P07 Your first automated loop You step outside the loop
|
v
P08 Draw your workflow as a graph You draw the system as a graph
Each project's solution becomes the next project's starter.
The app evolves. Your harness skills grow with it.
Resource Library
English — templates, checklists, and method references
Every project compares weak vs. strong harness results
What matters is the measured difference, not how many docs were written
Skills
This repository also includes reusable AI agent skills that you can install directly into your IDE or agent workspace.
harness-creator: A skill that helps you scaffold a production-grade harness for your own project in minutes.
Tools
Zero-dependency utilities you can run without installing Node.js.
audit-harness.sh: A shell-based audit script that checks an existing repo against all five harness subsystems (L03–L12). Exits 0 when all CRITICAL items pass. No Node.js required — complements harness-creator's validate-harness.mjs.
# Run directly on any repo
curl -fsSL https://raw.githubusercontent.com/walkinglabs/learn-harness-engineering/main/tools/audit-harness.sh | bash -s -- /path/to/your/repo
# Or after cloning
bash tools/audit-harness.sh /path/to/your/repo
Other Courses
Our team has also created other courses! Check them out:
Hands-on Modern RL: An open-source, hands-on curriculum bridging the gap from basic RL concepts to LLM alignment, RLVR, and advanced Agentic systems.
Modern LLM Notebook: A hands-on course for building modern LLMs from scratch in PyTorch, with 23 runnable Jupyter Notebooks covering tokenizers, attention, MoE, RLHF, inference, evaluation, and distillation.
Acknowledgments
This course was inspired by and draws ideas from learn-claude-code — a progressive guide to building an agent from scratch, from a single loop to isolated autonomous execution.
