Google Turns Harness Engineering Into a Free 2-Hour Course, With All Timestamps Marked

Google has released a free 2-hour course on Harness engineering, going from 0% to 100%. The tweet is from codila, and the course includes complete timestamps. In the replies, someone mentions that the instructor is Annie; in the video she is sitting at a desk with a Google logo in the background. If you want to save time, start with this progress table.

• 0% / 0:29: Starting Harness engineering from zero
• 15% / 11:08: Building your first agent the right way
• 30% / 28:08: Eval engineering, building a Chief of Staff agent
• 65% / 1:00:13: Loop engineering
• 100% / 1:23:19: A graph system that can run 24/7 and improve itself

See the course clips in the original tweet.

codila offers a judgment in the tweet: many people keep trusting an agent that looks right, when what really needs upgrading is the Harness, so that it can test, judge, and rewrite the agent until it is usable. This framing is closer to actual engineering practice than swapping in a stronger model. Model capability is of course important; when agents are slow, flaky, or forgetful, they are often stuck at the harness: no tests, no independent judgment, no rewrite path after failure. Most teams are busy swapping models and end up stuck because no one writes tests.

The course places Eval engineering at 28:08, and there is a reason for that position. In the replies, a developer also says that Evals should be the first thing you learn before building an agent. One commenter mentions their own approach: every piece of content a bot writes is scored by a small, cheap model to judge how strong the AI flavor is, and if it exceeds a threshold, it gets rewritten. Whether the model is smart or not is beside the point; checks are only valuable if they happen every time.

Another long article by codila takes Loop engineering one step further: Graph engineering. The article opens with a quote from Peter Steinberger, asking whether people are still talking about loops or have already moved on to graphs. A single loop is try, check, adjust, repeat. It can optimize one metric, but it cannot see whether the metric itself is going off track. The article gives a customer service example: ticket resolution rate rises for several months while satisfaction is falling. Goodhart's law. A loop can only see its own metric.

The graph approach is to draw the work as nodes and edges. A node is an agent or a task, and an edge is a dependency. A common mistake is treating 'then' as an edge. First summarize a file, then check the weather; the weather task does not read the summary, so these two tasks can run in parallel. The test is very crude: does the next step actually read the previous step's output? If not, there is no edge. If no data passes between two boxes, they are independent.

The article gives a dynamic workflow procedure for Claude Code: open the repository, paste a prompt from Anthropic, have one agent per route file check for missing auth checks, then add an independent verifier, starting with a limit of 20 files. After running, /workflows shows fan-out, verify, and synthesize. The result is a report, with no need to open twenty chat windows. A single workflow can fan out to up to 1,000 agents, with at most 16 running at the same time. This number comes from the feature limit; there is no rhetorical flourish in the tweet.

But graphs most easily break in two places. First, a graph can agree with itself. An agent checking its own output will go easy on itself, so the verifier needs an independent context. If you hand the executing agent's conversation to the verifier as-is, it is just agreeing with itself in a different font. Second, parallel agents can step on each other. When the Bun team fanned out a large migration to many agents, the agents used shared git commands in the same workspace and overwrote each other. The fix is structural: disable unsafe commands and give each group an isolated worktree. Before fanning out, you need to answer: where does each agent work, how are results merged, and what happens to conflicts?

Bun's Zig-to-Rust migration later became a case study. The figures in codila's article are: about 50 workflows, a peak of 64 agents running in parallel, 535,000 lines of Zig converted into more than 1 million lines of Rust, taking 11 days, costing about $165,000, and still requiring people to design and monitor it. Simon Willison's link is also in the article. The scale is real, and so are the price and the supervision. In public discussion, some also question whether so much AI-written code can be safely reviewed.

So graph should not be the default answer. If the task is small, a single bug fix, needs step-by-step approval, is still exploratory, or the steps are truly serial, a single agent or a single loop is cheaper. The clue for judging is in the first step: if you cannot find two boxes without arrows between them, there is no graph to draw. Graphs are for buying width: doing independent work at the same time. If the work is not wide, the graph itself is not wrong.

The course is worth watching, especially for AI practitioners with a development background. General users can watch it too, but don't treat graph as magic. The real takeaways are a few hard things: tests must actually run, the verifier must have a clean context, workers must be isolated, and rules must be frozen. Models will change; these do not. The course link is in the tweet, and the video is the one above. Saving it for later is fine too—the timestamps are already marked.