- Meta reports that its small Forum team used AI agents across planning, building, testing and operations, and that automated verification limited how much work could be handed over.
- Meta says weak checks do not remove the constraint. They move it from writing code to reviewing code that looks finished and isn't.
- Leaders should ask what counts as done, who signs off, and whether agents can check real system state.
When AI writes the code, the hard question changes. It stops being "how fast can we type?" and becomes "how do we know it works?" Meta's engineering team has just published an account of building a new app that answers the second question directly. The account is worth reading for the idea behind it, not only the speed.
What Meta reported
Meta Engineering described how a small team built Forum, a standalone app for going deeper into Facebook group conversations. Meta's engineers gave an AI agent a real role in the work, well beyond autocomplete. Meta says its measure of success was not code volume. It counted verified, production-ready changes: ones that build, pass tests and survive review.
According to Meta, the app took eight weeks to match Facebook Groups on its core features. Meta credits AI with much of the repetitive build work, which left engineers free to concentrate on system design, product choices and quality.
From helper to supervised worker
Meta contrasts two modes. In the older one, a person steers every step and the AI offers help along the way. In the newer one, the agent cycles through planning, building, testing and fixing by itself. The engineer defines the target, monitors progress, intervenes if the agent goes off course, and gives the final approval.
Meta calls the second mode "human-on-the-loop". It says this is a target, not a finished state. Some stages run autonomously today. Some still need a person present in every cycle.
The idea: trust is the bottleneck
Here is the lesson. AI does not remove the bottleneck in software work. It moves it. Meta's point is that thin checks do not eliminate effort. They push it onto reviewers, who must read code that looks complete but does not work.
Think of a factory that doubles its output but keeps one inspector. The pile of unchecked goods grows, and the inspector becomes the limit. Meta's answer was to build the inspection into the line. Put simply, the amount of work Meta can delegate to the loop depends on how far it trusts the automated checks.
How the loop checks itself
Meta describes several mechanisms. Build status, unit tests and checks that the screen matches the design spec feed pass or fail signals straight to the agent. A task counts as complete only after automated tests and visual checks pass.
Agents also test the live app. Meta built navigation agents that use the app the way a person would. They act, read the screen and report regressions. Meta also ran repeatable stress scenarios, such as aggressive scrolling, rapid navigation and repeated media loading.
One run exposed a memory problem. Meta says the agent isolated a way to reproduce it, proposed a fix and verified it, all before users saw the app. Meta reports that this roughly halved memory use and page faults.
Each shipped change still gets a human approval. Meta says it focused on making that approval quick, by attaching build results, test outcomes and recordings of verification sessions to every change.
The environment mattered more than the prompts
Meta says its biggest gains came from changing code and tooling, not prompts. Three examples stand out.
First, agents get tools, not descriptions. Meta's main problem was that the agent lost its bearings in the app. Asked to change the group home screen, it might edit the home feed instead. Meta gave it ways to read the live screen and list what was actually there before acting. Misdirected edits dropped sharply, Meta says.
Second, context beat clever wording. One category of investigation stayed weak until the agent received what a new engineer would get on day one: pointers to code, example queries and design documents. Quality jumped.
Third, prototypes were kept out of production. Meta added a second build of the app, a sandbox that uses the same code, frameworks and design system as production. A plugin architecture strips the prototype code out of the production version altogether. Designers could experiment freely. Meta notes that no prototype code could crash production because it did not exist in that build.
What to keep in perspective
This is Meta's own account of its own project. The numbers are self-reported, and the article does not give the team's size or a baseline for comparison. The memory fix is one example, not a measured trend.
Meta adds that after the agent investigates user feedback, an engineer still decides whether the finding is a genuine bug or a deliberate trade-off. Meta also says that defining what a good outcome looks like remains a human product judgment.
Questions to put to your engineering leaders
If your teams are adopting coding agents, these questions test whether you are gaining speed or just creating a review backlog.
What does "done" mean for an AI-written change? Compiling is not enough. Which tests and visual checks must pass before a person sees it?
Who signs off, and what evidence arrives with the change? Build results and test records make approval faster and more reliable.
Can agents check real system state, or do they guess from descriptions? Meta's main failure came from guessing.
Is there a hard wall between prototypes and production? A feature flag still ships the code. A separate build does not.
Without cheap checks, AI can produce plausible code faster than a team can review it. That is our reading of Meta's account: the teams that gain most will be those that make checking cheap.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Meta Engineering.
