AI-generated code today often looks correct. UIs render, buttons work, and data appear on the dashboard. The problem comes when users interact with the app: they find broken interactions or APIs and fail quietly. These aren’t superficial issues.<\/p>\n\n\n\n
This is a real problem with the current AI paradigm: it optimizes for the appearance of correct code rather than actual correctness. Applications look finished, but don\u2019t work. Agent 3 from Replit tackles this with self-testing using REPL-based verification. It executes code, tests it, and fixes it in a tight feedback loop.<\/p>\n\n\n\n
In this article, let’s understand Replit Agent Self-Testing, how to eradicate Potemkin functionality with Agent 3, how REPL provides real validation, and how to build your own self-testing systems.<\/p>\n\n\n\n
TL;DR<\/strong><\/p>\n\n\n\n Replit Agent self-testing is a practical way to verify AI-generated code by actually running and testing it inside a live REPL environment. Instead of assuming the code works, the agent checks how it behaves, catches failures, and keeps improving it through repeated testing until the application works as expected.<\/p>\n\n\n\n Currently, AI agents are used to produce entire applications: all parts from the UI components down to the back end, usually in a single workflow. For example, an agent can scaffold an interface, link to an API<\/strong><\/a>, and then simulate a complete user workflow in a system with very little human intervention.<\/p>\n\n\n\n The main problem is that most of these systems proceed linearly: the agent creates code, assumes it works, then continues to the next step without properly checking whether the system actually works when tested under real conditions.<\/p>\n\n\n\n Most of the output provided by current agents doesn’t guarantee that the various parts connect properly or behave as expected. As the systems become larger, these mistakes become progressively worse and can start to affect the whole system.<\/p>\n\n\n\n AI agents can produce finished-looking application output that actually does not work. These are called Potemkin interfaces because they look complete but are not functional beneath the surface. The UI<\/strong><\/a> displays correctly, buttons will respond, and dashboards display data, but there is no actual system logic to support these operations or deal with data correctly.<\/p>\n\n\n\n The result is the appearance of a working system without any actual mechanism that validates correctness. Without verification, the agent will continue building upon an unstable foundation and producing a system that will not work.<\/p>\n\n\n\n Self-testing is required. Otherwise, agents optimize for what looks correct rather than what actually works.<\/p>\n\n\n\n Traditional validation methods like syntax checks or unit tests often miss how applications behave in real user scenarios. <\/p>\n\n\n\n Agent 3 <\/strong>represents a shift towards execution-based testing. Instead of asking if the code looks like valid code, it determines if the code actually executes successfully under realistic circumstances. This is done by incorporating environments, web browsers, and feedback loops to match the user’s experience.<\/p>\n\n\n\n The REPL allows for continuous execution with state and tests workflows by reusing previous execution, not from scratch, with the context refreshed after every step. The agent can use variables and sessions as the user can.<\/p>\n\n\n\n let orderId = await createOrder(cartItems);<\/p>\n\n\n\n console.log(“Order created:”, orderId);<\/p>\n\n\n\n \/\/ later in the same session<\/p>\n\n\n\n let status = await getOrderStatus(orderId);<\/p>\n\n\n\n if (status !== “confirmed”) {<\/p>\n\n\n\n throw new Error(“Order verification failed”);<\/p>\n\n\n\n }<\/p>\n\n\n\n Here, the agent retains the orderId <\/strong>across steps and verifies it later, enabling multi-step validation.<\/p>\n\n\n\n The system in Agent 3 performs iterative development and testing in a tight loop.<\/p>\n\n\n\n Agent 3 first writes code, executes it using the REPL, checks the execution with signals during runtime, and corrects it if necessary. The process then loops back again until a correct execution has been reached.<\/p>\n\n\n\n This is not a one-time test case; this is a full cycle of a multiple-stage process that makes iterative corrections until success.<\/p>\n\n\n\n To better understand how self-testing AI agents and REPL-based verification work in real-world scenarios, you can explore this GenAI ebook<\/strong><\/a> as a practical reference.<\/p>\n\n\n\n Agent 3 decouples the generation part from the testing part into separate agents. The main agent handles features, the planning part, and the testing sub-agent tests the implemented features.<\/p>\n\n\n\n The testing sub-agent executes workflows, simulates user behaviors, and gives the test results to the main agent, preventing the system from being overloaded.<\/p>\n\n\n\n An order agent has implemented the features of an order system. The agent then checks the behavior of these new features through a full verification.<\/p>\n\n\n\n\n
What Is Replit Agent Self-Testing?<\/h2>\n\n\n\n
How AI Agents Build Applications Today<\/strong><\/h2>\n\n\n\n
The Real Issue: Potemkin Interfaces<\/strong><\/h2>\n\n\n\n
The Shift: Validation Through Execution Instead of Static Validation<\/strong><\/h2>\n\n\n\n
How the REPL Is So Powerful<\/strong><\/h3>\n\n\n\n
Example: Stateful verification using REPL<\/strong><\/h3>\n\n\n\n
How Agent 3 Performs Self-Testing<\/strong><\/h2>\n\n\n\n
Hidden Architecture: Dual-Agent System<\/strong><\/h2>\n\n\n\n
\n AI systems<\/strong> that separate code generation<\/strong> from testing<\/strong> tend to be more reliable<\/strong>.\n
\n This is because a dedicated testing agent<\/strong> evaluates the application\u2019s actual behavior<\/strong> independently, rather than trusting the generated code blindly.\n<\/div>\n\n\n\nAn Example: A Full Self-Testing Workflow<\/strong><\/h2>\n\n\n\n