Google's Free Two-Hour Course: Build a System from Scratch That Improves Itself

Google has released a free two-hour course on harness engineering. The timeline is sliced very finely:

• 0:29 Harness engineering from scratch
• 11:08 Properly building your first agent
• 28:08 Using a chief of staff agent for eval engineering
• 1:00:13 Loop engineering
• 1:23:19 A self-improving graph system that won't stop

Anatoli Kopadze wrote this when reposting: I've seen $500 courses whose first 15 minutes didn't cover what this course covers. The course was made by @anniewangtech; he added in a reply telling people to go follow her.

The course is worth watching. But the thinking behind the course is worth understanding before the course itself. Anatoli himself wrote a long piece on Graph Engineering that maps out the background, where the pitfalls are, and when not to use it.

A graph is just two things

Boxes are called nodes. One agent does one job, one input, one output. Arrows are called edges. One job waits for another job's result because the latter needs what the former produced. An edge only counts if data really flows across it.

Nodes do work; edges pass results. That's the whole vocabulary.

For a node to be usable, it needs a contract: a bounded piece of work, a defined input, a defined output. If the output is a wall of free text, then only a human can read that node. If the output has a fixed shape, the next node can pick it up without guessing.

The fake-edge test

Look at your current workflow and ask, step by step: does this step really need the result of the previous step?

If yes, the edge is real, and the order stays. If no, the edge is fake, and the two sides can run at the same time.

A simple example: review file A for bugs, then review file B for bugs. It reads as two steps, but checking B doesn't look at what A returned at all. They're serial only because you typed them in that order. Run them in parallel, and total time equals the slower file, not the two added together.

You can find two or three fake edges in almost any workflow. Each one is time thrown away for nothing.

A 40-step linear process has 40 sequential failure points, and latency is the sum of 40 steps. Draw the same 40 things as a graph, and the real dependencies are usually three to five edges; the time to finish equals the slowest layer. Five minutes becomes fifteen seconds. The model didn't change; the lines did.

The diamond

You don't need a hundred shapes. Serious agent systems repeatedly produce the same graph: work fans out, several workers dig in parallel, something checks what they dug up, and finally it's synthesized into one answer.

Fan out to gather breadth, use plain code to do the reduce and compress the data, and have one strong model do the synthesize and write the answer. Claude's research feature runs on exactly this: a main agent plans the angles, workers collect in parallel, findings are checked, and a report lands in front of you.

Once you see the diamond clearly, the question changes from 'how do I make the agent take more steps' to 'where do I split and where do I merge?' Only the second question scales.

Checkers can't share context

Models checking their own work are too lenient. Almost every test of AI self-evaluation points to the same thing: models miss most of their own errors.

So the agent doing the work can't check its own work. Hang an independent node off to the side whose only job is to try to kill that finding. If it survives, move on. If it dies, it ends here.

But the checker needs clean context. Show it the worker's chat log, and it isn't checking; it's nodding along to itself in a different font. An agent graph that shares context is just a single loop wearing clothes—slower to collapse and more expensive.

Separate three perspectives: is it correct, is it new, is the source real. Three different lenses catch things ten identical lenses can't.

Three ways to collapse

Context collapse. A thousand nodes fan out and dump all one thousand outputs into the final step; the window blows up before synthesis even starts. The fix is layered fan-in: summarize each batch first, and merge summaries, not the raw pile.

Fake independence. Two nodes' prompts don't mention each other, but they write to the same file or hit the same rate-limited API. That's a hidden edge. When the Bun team first fanned big work out to multiple agents, they shared one workspace and overwrote each other. The fix is isolated space for each worker; audit shared resources, not just shared data.

Silent failure. In a chain, one failure stops everything—annoying but obvious. In a graph, one dead node out of two hundred can slide into a report that looks complete. The fix is to count inputs at every merge step; if the count doesn't match, report it, rather than synthesizing half the data and calling it complete.

Anchors

The deeper pit is the graph itself.

Every node looks at another node's report, the audit checks against the financial numbers, and the finances come from the same system. Everything agrees, and nothing has been verified.

This graph will fail in the same way as a single loop, just later, more expensively, and with all green lights.

Topology doesn't buy truth. A graph needs anchors—things that can't be argued with. Tests that actually ran, revenue that actually landed, customers who actually stayed. Some rules need to be frozen, especially the ones the optimizer most wants to change.

The bill

The Bun case is written up in Anatoli's article: one engineer used this setup to rewrite the runtime, translating 535,000 lines into more than a million lines, in about 11 days. Roughly 50 workflows, up to 64 agents running at the same time. The bill was about $165,000, with human design and someone watching the whole time—and there were also criticisms that so much AI-written code couldn't be safely reviewed.

In the comments, someone worried about that number and asked how they could afford to do it in a small repo. Anatoli replied, where did you see that price? Once numbers get passed around, even the author may not recognize them.

This is a heavy-usage pattern. Only teams with budget, caps, and monitoring can play with it. Start at small scale, see what one run costs, then decide whether to expand.

When not to use it

Don't use a graph when the task is small, when every step needs approval, when you haven't figured out what you're looking for, or when the steps are truly serial. A graph buys breadth, not judgment. The test is still the fake-edge test: if you can't find two tasks that don't depend on each other, there's no graph to build; one loop is enough.

The course is the entry point: two hours, free. In Anatoli's words, the model was never the bottleneck; the lines you draw are. Tonight, take a sheet of paper, draw your workflow, and look for which arrows have no data following after them. Delete them.

The course was made by @anniewangtech. Anatoli's original article and the course link are on X.