99% people are using /goal and loops wrong. The hype they hear is "long-running loops prompting autonomous agent": point it at a task, walk away, come back to working code. But top agentic engineers have been doing that without /goal for 6 months (when GPT-5.2 and Opus 4.5 came out). It's called harness engineering + spec-driven development: build a harness for agent to observe the problem write a tight spec with all the test cases let Codex or Claude Code loop unattended until it meets every one. I kick these off overnight constantly — 2-5 hours a run. In April one chewed through a Turbo build-cache bug across our Vercel monorepo and had it green by morning. No /goal is actually required. So what's /goal actually for? Here's what one single prompt did while I was away: ~30 hours, 6,300 lines of code, 92k pages crawled, $40 spent on APIs Clone the core loop of another product — entire architecture reverse-engineered from scratch Our version's output was ~50× better than the reference product on the same queries. (This is a new data layer that'll power newsjack.sh - the open-source news-intel skills I've been working on) The secret is loss function development (LFD): you write the agent a target to optimize toward, not a spec to build. This is a concrete example of Peter's tweet, operationalized. The spec used in spec-driven development now becomes the starting point, no longer the finish line. It took me some experimenting to get this right. But here's the entire playbook — but we need to start with how badly it went first so you understand how to design these /goals. The agent cheated 3 times. Everything started with what I always do: a spec. I simply pointed codex at the other product's public website - "how can we build this ourselves?". In 30 minutes it came back with a full system design and test cases - the spec. But this time, I tried a different prompt. "/goal implement until your output matches theirs exactly" And here's what happened: Loop 1 (5 minutes) The agent grabbed the eval set, generated seed data that mirrored it, and declared victory in five minutes. "100%" recall, zero generality — a search engine that could only find the 30 things I'd handed it lol. Fix → blind it. Eval hidden during the run, revealed only at scoring, with a per-item miss list. Loop 2 (20 minutes) - blind, 30 items. I blinded the agent from eval set, but it learned by miss instead — every "you didn't find X" became a keyword next cycle. A few loops in: it used exactly 30 keywords, one per item, and it "won" again. Fix → widen the eval set. Hundreds of items to score against, too many to enumerate. Loop 3 (30 minutes) - blind, 200 items. After adding 200 items to the new eval set, agent cheated again. Funny enough, the agent enumerated anyway. The keyword list ballooned into the hundreds, each term a precise lure for the next miss. Three rounds, three cheats. That's when it clicked: the agent was simply optimizing. The cheating wasn't a bug in the agent. It was a bug in my target: I told it where to go and left every shortcut wide open. Every cheap path you don't fence off is a direction the optimizer will sprint down. And my initial target and skipped all the fences. Loop 4 (30 hours) - blind, 200 items, hard limits. So I started blocking directions. Cap the keyword list, blind the eval, widen the date — each fix closed one more cheap path, until the only direction left that moved the number was getting genuinely better at the task. It stopped cheating. Then it ran. ~30 hours of compute, 92k pages crawled, ~$40 in tokens, 6,300 lines of code. It turns out the product we were referencing was the floor, not the ceiling: we ended up surfacing ~50× the results on the same queries. (The full journey and receipts here for those curious) Loss function development (LFD) - the anatomy of a good loss function When most people try to build a product, they are using agents to go from zero to shipped in a few hours. But the catch is what comes after — the long tail. Edge cases the spec never imagined surface only in production, one error log at a time. You fix them one by one. The cases you don't catch in logs get reported by users, which is the most expensive way to find a bug. I've automated the cheap end of this. My OpenClaw agent Zoe watches error log every day and spawns Codex on new errors as they roll in and create PRs — about as tight as that loop gets. (Full setup documented here) The tail still takes months. That's why building a good product still takes time even with agents doing the work. LFD fast-forwards the tail. If you can get real expected-output examples up front — what good looks like, at scale — you run the soak before you ship: hundreds of edge cases hit the agent in one optimization run, not one quarterly drip of bug reports. And the reason this is suddenly feasible is that for more and more problems, those examples are just sitting in public. Spec-driven development: Build this. Make the tes