From status query, verification process to construction isolation, dismantle the engineering conditions that allow Agent to continuously advance development tasks.
In the AI-assisted coding mode, engineers first understand the requirements, locate the code, then use AI to write or modify the code, then run the test and decide the next step. When the team wants to further allow the Agent to autonomously promote planning, construction, testing and correction, the status confirmation, fault triage and result inspection originally completed by engineers also need to be supported by corresponding tools and execution rules.
In October 2026, Meta[How Meta Built Forum With AI-Native Engineering]”, the development practice of the independent group application Forum is introduced. The team made changes around code architecture, simulator status query, automated verification and sandbox construction, trying to reduce engineers’ investment in step-by-step operations. These transformations involve three interrelated issues: how tasks are completed, who controls the execution sequence and where failures occur, and how the operating environment provides trusted status and verification results. Combining the practices of Stripe, OpenAI, Warp and Google, we can further analyze how these conditions are implemented and how existing projects can be transformed step by step.
Find Loop breakpoints
When manually leading development, engineers will confirm that this build is installed, reconnect the simulator after finding it is lost, distinguish code errors from environmental failures, and then determine whether to submit for review. After the Agent takes over, it must first locate the specific breakpoint. How to obtain the code location and running status, how to determine the next step based on the inspection results, and whether the test code enters the production package, all need to be handled by corresponding tools and processes; links that still rely on manual supplementary information or operations will cause the task to stop and wait for others, or continue to advance under the premise of errors.
If compilation is regarded as task completion, the running effect may not be verified. Whether the target page is correct, whether the navigation path is complete, and whether the memory continues to grow after repeated operations all need to be checked. If the task ends after a successful build, the reviewer will have to restart the environment to do the verification, and the coding time saved may be consumed in end-of-line rework.
The execution process may also lack constraints. Writing “run tests after modification” into instructions, or triggering scripts at the end of a session, does not alone guarantee that the results will be processed. The submission phase is still entered after the check fails, indicating that the failure signal does not change the subsequent path.
The object of modification may also be unclear. Agent will refer to existing code patterns, and implicit dependencies and poor implementations may be used by subsequent modifications; static documents cannot explain what the application is currently displaying. Meta has encountered situations where the agent was asked to modify the group homepage, but instead modified the homepage information flow, or guessed the coordinates of the controls in the simulator.
Trial boundary issues also arise as the product nears production. The team hopes to continue producing early prototypes while protecting the official application. Merely turning off the runtime switch does not prove that the prototype implementation has exited the production package.
Use inspection results to control processes
Meta positions the engineer’s responsibilities as setting goals, supervising deviations, and approving results, and gradually allows the Agent to advance the execution steps. At present, some stages are running autonomously, while other stages still require engineers to participate in each iteration.
Before the task begins, the team enforces upstream teardown and machine-readable context, using the plan as a technical specification. For page modifications, the entry point, expected behavior, modification scope and acceptance path need to be clear. At the end of the task, the standard advances to automated testing and visual inspection passing, and the changes come with pre-populated test plans, build and test results, and recorded verification sessions. Navigation Agent can operate running applications, read screens and report regressions.
Meta organizes these tasks using rules, skills, dedicated agents, commands and hooks. Rules save project agreements, Skill provides reusable steps, and dedicated Agents are responsible for checking, commanding connection reproduction, repair, and review processes; hooks run static checks after each round of Agent interaction, check simulator connections before installation, and verify tests before creating merge requests.
These components are constrained in different ways. Rules and Skills require the model to read and follow; hooks are responsible for triggering programs. Runtime constraints are formed only when the execution system reads the check results and accordingly prevents tasks that do not meet the conditions from continuing. Checks not executed, environment unavailable and assertion failures need to be handled separately; missing reports or timeouts cannot be counted as passes. Meta disclosed the trigger timing and did not develop a complete failover implementation.
Stripe in “[Minions: Stripe’s one-shot， end-to-end coding agents—Part 2]”, the process of unattended execution of tasks by the internal coding system Minions and then review of the results by engineers is introduced. The system uses code to define an execution blueprint, and mixes Agent nodes such as “implement tasks” and “fix continuous integration failures” with program nodes such as “run configured static checks” and “push modifications”. Models deal with problems that require understanding the context, and programs perform predetermined steps. This can be organized into a specific repair process:
-
After the Agent modifies the code, the program runs the specified check;
-
If there is a code or assertion error, return to the Agent responsible for correction. If the simulator loses contact, restore the environment and confirm the installation status.
-
After the build and run conditions are met, check the target page, user path, and expected behavior.
After the specified tests and visual inspections are passed, the results and verification materials of the corresponding versions are summarized and modifications to be reviewed are generated; when recovery fails or the budget is exhausted, the “unpassed” or “incomplete” status is retained, and existing changes, errors, and on-site information are saved and returned to the engineer. The latter can keep the branch or draft, but cannot be marked as verified.
Figure 1: Execution branch after one check.
Test plans and videos are helpful for review, but the presence of the material does not equate to correct behavior. The program can check whether the report is complete and whether the version corresponds. The acceptance conclusion must still be supported by actual testing, assertions and visual inspection results.
Repairs also need to pay attention to cost boundaries. Stripe runs some static checks locally, then pushes and runs continuous integration; problems that can be automatically corrected are first handled by the tool, and other failures are given to the Agent for a chance to repair. After the second push and inspection, it is returned to the engineer for review regardless of the result. This one- to two-round upper limit is for complete continuous integration and cannot be directly applied to all tool calls; the number of environment recovery times, timeouts and total task budget need to be agreed separately. Before interrupting and resuming, you should also check whether the push or create merge request has been completed to avoid repeated execution.
Check the code and running status
The process can proceed sequentially and still possibly work around the wrong object. The code level needs to identify modification boundaries, and the operation level needs to confirm application instances, pages, and elements; the two types of basis must be established separately.
Meta has modularized the key architecture to facilitate Agent access while reusing mature infrastructure. For reused parts that are difficult to clearly decouple, the team chooses to re-implement them to reduce the reuse rate in exchange for execution efficiency. The team also pointed out that the Agent will inherit the patterns of the code it reads, so cleaning up existing bad implementations also reduces the chance of subsequent sessions continuing to copy them.
This trade-off can be understood from the scope of modification. If a page handles requests, caching, permissions, and global state at the same time, local changes may touch multiple hidden conditions. After removing the interface and dependency boundaries, it is easier to limit the scope of modifications and check whether they are out of bounds. Rewriting also brings decoupling and regression costs. Existing projects should prioritize paths where high-frequency tasks are repeatedly blocked.
OpenAI[Harness engineering: leveraging Codex in an agent-first world]”, an experiment using Codex to build an internal product from scratch was introduced. In order to constrain the code that the Agent continuously generates, the team uses custom static checks and structural tests to constrain module dependency directions, and writes correction guidelines into error reports; briefly AGENTS.md Points to detailed warehouse knowledge. After receiving the violation location and guidance, the Agent makes modifications and then runs the inspection, reducing the need to rely on manual review to correct repeated violations. These checks cover the coded architectural rules, and business behavior still needs to be additionally verified.
The operating site will change with the operation. For correcting error pages and guessing coordinates, Meta provides tools to read the real-time view hierarchy of the simulator, list visible elements, and query the navigation path of the target page. For example, a group homepage might also contain a stream. Page identity and parent-child relationships help distinguish it from the homepage information flow, not just matching element names. The following is a simplified hierarchy diagram:
当前页面：群组主页
└── 页面根视图
├── 群组标题（可见）
├── 发布入口（可见）
└── 内容区域
└── 群组信息流（可见）
Query results also have a valid range. Reading the current location before navigation, confirming the target page after navigation, and querying again after the operation can reduce the backward propagation of erroneous premises. Re-rendering may invalidate old element identifiers, and the page may change after the process is restarted. The view hierarchy provides the current observation, which cannot be queried once and used until the end of the task, nor can it be independently proven that the corresponding source code has been located.
Parallel execution also requires management of state ownership. OpenAI starts application instances for each work tree and provides temporary, independent logs, indicators, and link tracking environments, and cleans up corresponding resources after the task is completed. This example uses browser tools to observe and manipulate the application.
When migrating this arrangement to mobile, you need to separately associate workspaces, builds, application instances, and observation data, and manage ports, simulators, and test data. Otherwise, even if file modifications have been isolated, two tasks may still operate on the same instance and verify their own code against each other’s running results. Whether the interrupt task retains the site and when to clean up resources also need to be designed separately.
Figure 2: Correspondence between tasks and operating sites.
Stress test applications and isolate prototypes
Conventional unit tests and path inspections mainly cover preset behaviors. After repeated scrolling, page cutting, and media loading, the application may also experience resource growth and status accumulation problems. Meta is configured with stress scenarios of high-frequency scrolling, random browsing groups, fast navigation, and repeated loading of media. It is run routinely between different builds to observe crashes, memory growth, page faults, and interface regressions.
A stress test before going online revealed a memory problem. Agent uses the same stress testing environment to complete reproduction, reduce trigger sequences, propose repair plans, and retest. The architectural choice is decided by engineers.
When reusing, we must first narrow the gap between random discovery and stable reproduction. If only “Memory exception occurred” is left, the next run may go to another path, and it is impossible to determine whether the problem has disappeared or has not yet been triggered. The action sequence, time, input and initial state should be recorded according to the needs of the problem, and the scope of recurrence should be gradually narrowed down. These records assist the investigation and do not alone provide assurance that the external environment has been restored.
Comparable conditions should also be used before and after repair. Devices, system versions, build types, and media loads are different. Memory changes may come from environmental differences. The abnormal resource curves found, the running records of the location trigger conditions, and the retest results after repairs should support corresponding conclusions respectively. The above recording and comparison methods are migration suggestions and cannot be regarded as Meta’s published stress test configuration.
After Forum approached the production stage, the experiment proposed a new delivery boundary: designers and other collaborators continued to use AI to produce prototypes, and the production package only included completed and reviewed functions. The runtime switch controls whether the function is enabled, but cannot independently guarantee that the relevant code and dependencies exit the packaging, linking, or initialization process. Meta uses independent sandbox build variants for this purpose, sharing code libraries, frameworks and design systems. Experimental functions are accessed through plug-ins and reserved slots, and prototype code is excluded from production builds. Collaborators can quickly experiment in the sandbox, and mature implementations can also use the shared infrastructure to migrate to the official version, reducing the cost of re-implementation.
Figure 3: Separation of production and test builds.
This guarantee is for excluded prototype implementations that do not enter the production package and whose code does not execute within that package. Directory independence is still not enough to prove that the exclusion is established. The dependencies, resource collection and registration logic actually used by the production target must be checked to prevent the prototype from being re-introduced.
Changes in the shared framework may still affect formal functions, so regression should be based on the scope of impact; if the impact cannot be clarified, the coverage should be expanded. New build variants, plug-in interfaces, and test matrices also need to be maintained. Prototypes are still subject to review before being moved into production, as well as compatibility, performance and permissions checks.
Maintenance rules and troubleshooting basis
After a single process run, repeated errors and production feedback continue to create maintenance needs. The former is related to whether subsequent tasks wait for manual correction again, and the latter is related to whether online phenomena can form verifiable repair clues.
Meta writes fixes to permanent project rules when the same error is repeated more than twice. Anthropic in the article “[How Warp builds self-improving agents on Claude]”” introduces the development tool team Warp’s approach to maintaining code review and problem triage agents: basic skills perform tasks, regularly run improvement skills collect manual feedback, propose small-scale adjustments, and take effect after review and merger by maintainers.
In Warp’s issue triage example, the maintainer pointed out that the Agent missed issues that could enter the specification design, and explained the reasons. The improved Skill call comes with a Python script that extracts records with feedback, and then proposes modifications to the underlying Skill file. After manual correction is reviewed and written into the basic skill, subsequent tasks can read it, and modifications can be traced and rolled back along with the version record.
When reusing this path, repeated violations that can be objectively determined can be converted into static inspections. The constraint summary and correction entry can still be retained in the prompt, and all instructions do not have to be mechanically deleted just because the program has been checked. Whether the rule modification is effective must be tested in subsequent similar tasks. Acceptance of feedback cannot be equated to quality improvement.
After the application goes live, the investigation also needs to have available evidence. Meta allows the investigation agent to collect clues, generate structured reports and repair suggestions in Forum information flow operation and maintenance, and engineers will judge whether it is a real defect or a product trade-off. The quality of the first type of survey was weak at first, but improved after adding relevant code locations, query examples, and design documents.
Code locations narrow the scope of reading, query examples help obtain operational data, and design documentation provides expected behavior. Subsequent sessions can reuse this data, but the data must still be maintained as the system changes. Reports should also distinguish between observed facts, possible explanations, and unverified conditions to avoid speculation that enters the remediation phase and is taken as a given root cause.
Version is another correspondence. In “The Outer Loop, Insights First: An Ambient Quality Agent That Diagnoses Your Production Agent”, Google introduced the quality diagnosis reference implementation AQuA and used the travel assistant to demonstrate the quality troubleshooting of deployed business agents. This reference implementation saves an immutable source code snapshot indexed by the deployment version during deployment; during on-demand investigation, the failure trace and the corresponding source code are jointly analyzed, and the server verifies the referenced files and line numbers. AQuA itself does not modify the code or create a merge request, and valid references do not prove the root cause.
When the Agent subsequently undertakes the diagnosis, it must also confirm whether the problem still exists in the current branch. Historical session input can be used for replay, but the old database, external interfaces, and dynamic conversation state will not be automatically restored; the parts that can be reconstructed are used for verification, and the remaining dependencies need to be fixed or simulated. Diagnostic reports provide repair input and are not a substitute for repair acceptance.
Transform step by step and test the benefits
Meta’s Forum project achieved the core functional alignment of Facebook Groups within eight weeks; after the aforementioned memory problem was fixed, the memory usage and the number of page faults were reduced by about half. Part of the development phase still requires engineers to participate in each iteration, and all deliverables require final signature from engineers.
The cases of Forum and OpenAI both start from new projects, and there is more room to design module boundaries earlier. Stock systems also contain historical dependencies, implicit rules, and unstable tests, and the benefits must be evaluated together with the costs of decoupling, environment maintenance, and verification. For existing projects, you can first select a type of page modification or component repair with high frequency and clear boundaries, and record the steps at which engineers intervene. Repeatedly specifying the code location, starting environment, specifying the page and explaining the error report will expose different gaps respectively. The order of modification should be determined by the actual breakpoints.
Then fill in the query and execution entrances for these gaps, and then access static inspection, construction and related tests. The execution system needs to read the results, distinguish between code errors and environmental problems, and limit the number of recoveries, timeouts, and task budgets. If the check itself has frequent false positives, its reliability should be improved first, otherwise automatic repair will consume time around false signals.
During the trial run, check one by one whether the corresponding build and application instance have been operated on the task, whether the specified check has been completed, whether the failure has entered the predetermined branch, and whether the reviewer can review the result. While comparing the number of manual pushes, waiting time and rework, you should also observe the return situation. Repeated corrections are gradually accumulated into documents, skills or inspection rules. After confirming that the obstruction is reduced, the execution scope is expanded.
Engineers continue to be responsible for target selection, architectural trade-offs, and final quality judgments. How much work the Agent can continue to advance depends on whether the environment provides verifiable basis for action, a controlled execution path, and verification results that are sufficient to support delivery.
