That 4-Hour Anthropic Course: Watch 33:21 First

Lunar's tweet says Anthropic released a 4-hour free course, framed around landing a $500,000 AI engineering job. The chapters include 00:15 how to prompt Claude, 33:21 what makes Claude worse at code, 01:33:39 how Anthropic uses Claude day to day, and 02:50:56 a fix that makes Claude smarter. The tweet also says the course can replace about 10 paid engineering courses.

The video and original tweet are here: Lunar's original tweet. Whether the course is worth watching from beginning to end is another matter, but the 33:21 chapter is worth opening first. A commenter below said his worst runs usually start with pasting half a repo into the context. Later he kept prompts short and let Claude read the code itself; the bill went down and the code actually got better. This observation lines up with Whitemon's article.

In this article, Whitemon breaks AI agent failures into three layers: harness, loop, and graph. His 30-second version is: the harness gives the model hands, memory, and walls; the loop gives it a check that can actually fail; the graph gives the work a shape. The three layers correspond to environment, evidence, and process. The opening line of the article—"Same model, same prompt, completely different results"—is talking about that ring of things outside the model.

He also quotes Karpathy's tweet from late last year. Karpathy said he had never been this far behind as a programmer, and the bits programmers contribute are becoming sparser and sparser. He listed a string of things: agents, subagents, prompts, contexts, memory, modes, permissions, tools, plugins, skills, hooks, MCP. Whitemon's judgment is that this list is not one thing; it is three layers mashed into one sentence. Once separated, "AI agents are unreliable" becomes an ordinary engineering problem.

Harness

The harness is everything around the model that lets it do real work. Whitemon gives a clean definition: take the model out of the architecture diagram, and everything left is the harness. Terminals, tests, browsers, project memory, permissions—all of it counts. The model weights do not change; change the harness, and the agent can run tests, open PRs, and modify features in a repo.

He breaks a decent harness into six parts: contract, map, tools, memory, walls, traces. The most important part of the contract is done_when. Without this field, the agent will quietly solve an easier problem and then say it is done. The map is a root file like AGENTS.md that tells the agent where things are, instead of dumping all the docs into context. Context is an attention budget. Treat it like a warehouse and it will run out quickly. Tools should be narrow; ten narrow tools are better than forty overlapping ones. Memory writes decisions, dead ends, and risks into files instead of leaving them in the chat log. Walls are permissions. Asking politely does not work. Traces make failures readable.

Whitemon also mentions a "write it twice" approach. Write an important rule once as a guide the agent can read, and once as a check in CI that cannot be bypassed. For example, if the guide says "UI code must not query the database directly," add a lint check in CI that fails when src/ui/** imports src/db/**. The guide explains why; the check still works on the day the model ignores the guide.

He quotes Mitchell Hashimoto saying that a general-purpose agent harness is better than every built-in chat box in every product he has tried. He also quotes Claude's tweet: Anthropic productized managed agents, with the model responsible for reasoning, the sandbox for execution, and session logs that remain after either side goes down.

Loop

With a harness, the agent can work independently for an hour. Then it says, "Fixed, the tests should pass." Notice the word "should." The harness gives the agent capability; nothing yet makes it honest.

The loop is about evidence. Whitemon breaks the loop into trigger, goal, state, action, evidence, feedback, and stop. The core line: do not loop on confidence, loop on evidence. The agent saying it is done is not a stop condition. The tests passing is. Evidence also has strength levels: deterministic tests are strongest, observable traces next, an independent reviewer next, and self-reporting is weakest. A loop is only as reliable as what it accepts as proof.

He recommends writing the check before writing the code. The check must fail once against the current code. A test that passes before the fix proves nothing. If you cannot write the check, you do not yet understand the task. Feedback must also be specific; do not just give a red. Say what was expected, what was actually seen, where to look, and which paths have already been tried. Expected and saw turn a red light into a direction. Dead ends keep the third attempt from circling back to the first.

The loop also needs an exit. A retry cap, a token budget, and escalation to a human when the same result appears twice. Claude Code's /loop is a productization signal; when Boris Cherny announced it, he gave examples of scheduled tasks. But tools are tools, and the rule remains: the loop must revolve around evidence.

Graph

A graph is nodes, edges, and state. A node is a bounded piece of work, one input and one output. An edge is a real dependency: this node's output feeds that node's input. State is what survives between nodes. Whitemon puts it plainly: a loop is just a graph with one node and one edge pointing back to itself. A graph does not replace a loop. You need a graph only when multiple loops have to hand work off to each other.

He gives an early-start test. For every arrow, ask: if B starts before A finishes, what breaks? If the answer is "nothing breaks," delete the arrow and let them run in parallel. A billing audit can start before the fix lands; a PR cannot open before the fix lands. The former is a habit; the latter is a dependency.

There are also four ways to split. If failures can be separated, split into two nodes. Every worker needs its own context; four agents sharing one context is just one agent wearing four hats. Use code where the answer should not change; merging, sorting, deduplicating, and counting are ordinary functions. Freeze nodes that pass a gate; on failure, rerun only that node.

Rohit said in a tweet that the biggest gap in loop engineering is an agent doing the work and grading it too, with no one catching the errors. A graph uses independent steps to review output, so a bad step fails on its own. Peter Steinberger asked, "Are we still talking about loops, or have we already moved to graphs?" and the timeline quickly picked it up. Whitemon also warns that most tasks do not need a graph. If five nodes can be compressed back into one loop without losing anything, compress them back. LangGraph and Google ADK have long been doing nodes, edges, and shared state. The words are new; the actions are real. Do not draw a twelve-node graph before you have watched an agent do the work once.

Which Layer to Fix First

Whitemon gives a diagnostic table. Copy-pasting between chat and terminal: fix the harness's tools. Retrying paths already tried: fix the harness's memory. "Done" is not trustworthy: fix the loop's checks. Retries burn budget on the same error: fix the loop's feedback and exit. Every step is correct but the whole thing is slow: fix the graph's shape. One failure reruns everything: fix the graph's gate. The same kind of error comes back every week: fix all layers.

There is no prompt row in the table. Writing "be careful not to duplicate work" in a prompt is a hope. A splitting rule in the scheduler is structure. Next quarter's model will read the prompt differently; the tests read the same way.

He also lists five common mistakes: building a graph too early; having the same model write and grade; treating "keep trying" as a loop; treating the harness as a drawer; blaming the model. The last one is especially common. A broken API, stale state, an ambiguous tool schema, or no exit condition cannot be saved by switching models.

Back to 33:21

That chapter in the Anthropic course about what makes Claude worse at code is the same thing as Whitemon's map and context budget. Long prompts and half a repo stuffed into context do not make the model smarter; they eat its attention. One commenter watched this chapter first, shortened the prompt, and let the model read the code itself; both the bill and the output got better. This is more useful than "adding IMPORTANT." Someone called all-caps IMPORTANT the bargaining stage of agent development—harsh, but accurate.

Models will change every quarter. Contracts, tools, tests, state files, and gates will remain, and every time a failure is attributed to the right layer, they will get better. The harness gives the agent capability, the loop makes it honest, and the graph makes it organized. Next time an agent says "done," first ask which layer said it. The $500,000 figure can be set aside. The truly valuable thing is in the system.