I’ve been thinking about the difference between having AI help you code versus having AI run the loop while you supervise it. Meta’s team working on Forum just published something that crystallizes why this distinction matters more than we talk about.
The shift from human-in-the-loop to human-on-the-loop sounds like semantics. It isn’t. With human-in-the-loop, you drive every step. The AI autocompletes a function, suggests a fix, answers a question. You stay in motion. With human-on-the-loop, the agent plans, implements, builds, tests, corrects, and iterates on its own. You set the direction, watch the run, step in if it drifts, and approve the result. Your job transforms from executing steps to owning outcomes.
This matters because it changes what bottlenecks the work. Right now, most AI coding tools optimize for throughput at the point of generation. More tokens, bigger models, fancier prompting. But if you measure success by verified, production-ready changes, not lines written, you realize that generation was never the constraint. Verification is.
The Verification Gap
Plausible code that doesn’t work is a familiar problem. An AI generates something that compiles, looks finished, and passes a quick read. Then an engineer spends two hours debugging it. Or discards it entirely. You’ve optimized the wrong thing.
The Forum team inverted this. They set the bar not at compilation but at verification. A task is complete only once automated tests pass and visual checks succeed. They built agents that check their own work before an engineer sees it. What reaches review is smaller, higher-confidence output. Less gets generated. Less gets discarded. Every shipped outcome still carries human sign-off, but that sign-off is fast because it’s well-evidenced: build results, test outcomes, recorded verification sessions.
This is the real multiplier. Not better prompts. Architecture.
Building Systems Agents Can Navigate
I found three design principles here that feel broadly applicable:
First, architectural legibility over inherited complexity. Agents learn patterns from the code they read. Leave a weak pattern in your codebase and every future agent session will replicate it. Fix it once and every future agent inherits the fix. The team even chose to rebuild from scratch in places, trading reuse for agentic throughput. That sounds expensive until you realize how much rework it prevents downstream.
Second, give agents tools to check state directly, not descriptions to reason from. Instead of describing the app, they gave the agent tools to read the live view hierarchy, list elements actually on screen, look up view paths. Misdirected edits dropped sharply. Check before acting, not after guessing.
Third, build-level isolation. As Forum matured, they kept a separate build flavor that shares codebase and frameworks with production but compiles prototype code out entirely via a plugin architecture. Agents can iterate wildly while production stays strictly limited to reviewed work. Architectural decisions like this compound. Early choices about tooling and structure shape what becomes possible with AI later.
Verification as Stress Testing
Here’s what surprised me: adapting the environment didn’t just make the agent faster to build with. It made the agent a continuous tester. They set up stress scenarios that mimic real user behavior - aggressive scrolling, random browsing, rapid navigation, repeated media loading - and ran them routinely across builds. The agent triages anomalies, narrows to the triggering sequence, investigates root cause. One run surfaced a memory issue that materially reduced on-device memory growth and page faults across repeated sessions.
This is verification as a lens on quality. You’re not pointing the agent at one specific defect. You’re building repeatable signals that feed back into the development loop. The agent becomes a quality system, not just a code generator.
What Ownership Actually Means
The operational dimension matters too. After launch, when users submit feedback, agents help automate root-cause analysis. They investigate possible regressions and forward structured findings to engineers. Engineers validate whether something is a real bug or an intentional trade-off. The mechanical work gets compressed.
But here’s the thing: the leap in quality came from context, not prompting. One investigation category stayed weak until they gave the agent the same pointers to relevant code, example queries, and design docs they’d give any new engineer on day one. Quality jumped. You train once and every future session inherits it.
This pattern - systematic context, repeatable signals, human judgment on trade-offs - feels like the actual future of how teams will work with AI. Not chatbots and autocomplete. Systems where agents run the mechanical loops and humans own the outcomes that matter.
The question isn’t whether AI can generate code faster. It’s whether we’re building systems where the verification signal is tight enough for agents to operate safely inside them. Most teams haven’t answered that question yet.