Redefining the Engineer's Role

Forum, Meta's standalone app built around Facebook Groups conversations, doubled as a test case for a different division of labor. Rather than pointing an AI agent at the coding step in isolation, the team extended it into planning, building, testing, and verification — and the results only compounded once that scope widened.

The contrast comes down to ownership. In a human-in-the-loop setup, the engineer drives each step while the AI assists within it — autocompleting a function, proposing a fix, answering a question — and every iteration moves only as fast as the person at the keyboard. Under human-on-the-loop, the agent owns the cycle: plan, implement, build, test, correct, and repeat, with the engineer setting the goal, monitoring the run, intervening on drift, and approving the outcome. The role shifts from performing steps to owning the result and defending the quality bar. Meta frames this as a direction rather than a completed state — some stages already run autonomously, others still keep a human in every iteration.

Supervision also changes the shape of the work: what was strictly sequential can overlap, freeing engineer time for direction and judgment. That only pays off when the output can be trusted. Unverified generation produces plausible code nobody has confirmed works, and the human cost simply migrates from writing to reviewing nearly-finished-looking work that isn't. Meta therefore set the completion bar at verification instead of compilation: a task is done when automated tests and visual checks pass. Because agents check their own work first, review receives fewer, higher-confidence changes, and everything shipped still carries an engineer's sign-off — attached to build results, test outcomes, and recorded verification sessions.

Four capabilities for an unattended loop

If the engineer steps outside every cycle, the loop must run safely alone. Meta identifies four enablers:

  • Planning as technical specification. Ambiguity a person would resolve by intuition becomes agent failure, so the team invested in upstream decomposition and machine-readable context.
  • Automated verification inside the loop. Build status, unit tests, and UI spec matching feed pass/fail signals directly into the agent loop, enabling asynchronous work that produces ready-to-review pull requests with test plans and recorded verification sessions. How much can be delegated is bounded by how far the verifiers can be trusted.
  • Simulated user testing. Navigation agents operate the live app as a person would, performing actions, reading the screen, and reporting regressions.
  • Agentic production operations. Post-launch, agents automate root-cause analysis: user feedback triggers an investigation into possible regressions, and the analysis goes to engineers for the next decision.

Supporting Machinery and Environment Changes

The operating model rests on five components: Rules encode permanent project instructions — a repeated mistake is corrected once, for everyone; Skills turn team conventions into loadable steps; Agents automate checks that once needed a manual pass; Commands chain skills and agents into workflows that assess complexity, reproduce a bug, plan and implement a fix, open the pull request, and run multi-stage review; and Hooks fire automated triggers such as linting after each agent turn, checking simulator connectivity before install, and validating tests before a pull request exists.

Code and tooling, not prompts

The largest gains came from reshaping the codebase rather than tuning instructions.

Meta kept Forum's architecture deliberately legible, modularizing key pieces so agents could plug in while still benefiting from proven infrastructure. Where modularization wasn't practical, the team rebuilt from scratch, trading reuse for agentic throughput. The reasoning: agents learn from the code they read, so a weak pattern fixed once improves every later session, while a shortcut left in place propagates into everything the agent writes next.

Describing the app to an agent proved to be the main failure mode — edits landing on the home feed instead of the group home screen, guesses at screen coordinates. The fix was giving agents tools to check rather than prose to reason from: reading the live view hierarchy from the simulator, listing the on-screen elements, and resolving the path to a target view before acting. Misdirected edits dropped sharply, and the same give-the-agent-a-check approach was applied everywhere agents touched Meta's systems.

Isolation through a separate build flavor

As Forum moved toward production, the team wanted room for early prototypes and agent experiments without exposing the shipping app — a stronger guarantee than feature gating, which leaves prototype code in the production build. The answer was a separate build flavor: a sandbox app sharing the same codebase, frameworks, and design system as production, but compiling prototype code out of the production build via a plugin/socket architecture.

Three benefits followed: designers and cross-functional partners could prototype with AI tools without an engineer per change; sandbox work ports directly to production with no rebuild; and no prototype code can crash the production app because it physically isn't in that build. The pattern preserves fast AI iteration even after real users depend on the app.

Stress Testing and Feed Investigation

The same environment made the agent a tester. Rather than targeting a specific defect, Meta built repeatable stress scenarios that mimic real usage — aggressive scrolling, random group browsing, rapid navigation, repeated media loading — and ran them routinely across builds. The consistent signals they yield (crashes, memory growth, page faults, UI regressions) let the agent triage anomalies, narrow to the triggering sequence, and dig into root cause. One run uncovered a memory issue: the agent isolated a repro, proposed a fix, and verified it during development, before users were affected. The change materially reduced on-device memory growth and page faults across repeated stress sessions. Engineers retained architectural decisions, but detection and regression monitoring became automated and repeatable.

Two more applications of human-on-the-loop followed. On the building side, agents mapped architectural options and trade-offs while engineers evaluated and chose — the definition of a good outcome stayed human, as a product judgment the system shouldn't set for itself. On the operating side, questions that once went to whichever engineer knew the code path now go to an investigation agent that assembles findings and posts a write-up with suggested fixes; after hand-scoring a batch of real investigations, the team settled on a workflow where the agent compresses mechanical work and an engineer validates whether a finding is a real bug or an intentional trade-off.

Quality in these investigations turned on context, not prompting. One category of inquiry stayed weak until the agent received the same pointers to relevant code, example queries, and design docs a new engineer would get on day one — after which its quality jumped. Unlike human onboarding, the training happens once and every future session inherits it.

Measured Outcomes

  • Early quality. The autonomous stress-testing loop caught the memory issue during development rather than post-launch, roughly halving memory use and page faults.
  • Velocity. Forum reached core feature parity with Facebook Groups in eight weeks, with AI absorbing much routine implementation while engineers focused on architecture, product decisions, and quality.
  • Lasting leverage. After launch, agent-driven investigation assisted engineers in triaging and root-causing user feedback.