Replit Agent 3: what to check before using an app it builds

Replit introduced Agent 3 on 10 September 2025. Its launch announcement described longer autonomous work, browser-based app testing and the ability to build agents and automations. Those features made it easier to move from a written brief to a working prototype.

A prototype still needs a business owner and a release decision. The useful question is whether the application does the required job, protects its information and can be maintained when something changes.

What the announcement established

Replit's Agent 3 announcement said the agent could periodically test an app in a browser and attempt fixes. It also described extended autonomous sessions and generated automations. These were the vendor's launch claims, not an independent Blue Canvas benchmark or a guarantee for every task.

This article is about that Agent 3 release. Product modes, limits and pricing can change; check the current Replit product and account settings before starting paid work. A longer run is not itself evidence of a better application.

Give it a testable brief

Describe the user, the job and the boundary. “Build a booking system” leaves important decisions unstated. A more useful brief identifies who may create a booking, who can see it, how conflicts are handled and what should happen if saving fails.

List the screens and records the first version needs, then list what is out of scope. Specify whether the app is a demonstration with fictional data or a system intended for real use. Keep public launch, paid services and external messages as separate decisions.

• What must a user be able to complete?
• What information is required and who may access it?
• Which actions change a record or contact another person?
• What should happen when information is missing or contradictory?
• How will you tell that the task was completed correctly?

A fictional booking prototype

Suppose a small workshop wants a demonstration showing available sessions. Use invented people and sample dates. First ask for browsing sessions and adding a booking to a test database. Do not connect payment, live email or a real customer list simply to make the demonstration feel complete.

Write acceptance cases before testing: a session with space; a full session; two people requesting the last place; an invalid date; an interrupted save; and a user trying to view someone else's booking. A happy-path screenshot covers only the first of these.

Check the result through the interface and inspect the saved records. A success message with no database entry is a failure. So is an entry created twice after a retry. Record the expected and actual behaviour for each case.

Check more than the screen

The agent's own browser tests are useful evidence, but they are not independent acceptance. Ask what was tested and inspect the output. Include a reviewer who understands the business process and, for consequential software, someone competent to review its technical design.

Review authentication, permissions, validation and the boundaries between users. Check where secrets are stored, which external services receive data and which dependencies the app uses. Verify any licence or commercial restrictions relevant to those components.

The NCSC secure AI development guidance treats security as work across design, development, deployment and operation. A generated app needs that lifecycle too.

Separate test and production

Keep test credentials and fictional records separate from production access. Review the changes before connecting an app to live data. Confirm who owns the hosting account, domain, source code, database and third-party subscriptions.

Before launch, demonstrate a backup and recovery procedure appropriate to the application. Decide who receives failure alerts, who can disable the app and how the existing manual process will work during an outage. Document the release so a future maintainer can understand it.

Measure the whole development job

Compare the time needed to specify, generate, inspect, correct and maintain the application. Include service charges and the effort spent resolving failed attempts. A quickly generated interface can still be expensive if its underlying behaviour needs extensive repair.

Use the same brief and acceptance cases when comparing coding tools. Keep successful and unsuccessful attempts in the record. Avoid treating a selected vendor demonstration as a prediction of delivery time for your project.

When it is worth exploring

A bounded prototype can help a team test an idea and identify missing requirements. The case is weaker when the process is unclear, the data cannot be used safely or nobody can take responsibility for the finished system.

For a separate tool comparison, see Claude Code versus Codex. For help turning a prototype into a scoped project, explore AI consultancy or book a free conversation.