Skip to main content
pre.dev’s key differentiator: agents cannot mark a task as complete until it passes verification. Not “the code compiles” — the agent drives your app in a real browser, exercises the feature end to end, and captures screenshot evidence before a PR opens.

​
What drives verification

Verification isn’t generic smoke testing. Each user story in your spec carries acceptance criteria — concrete, testable statements of what “done” means. Those criteria are what the agent verifies against, so the checks map directly to what you asked for.
During verification the agent’s editing tools are disabled. It can observe and report, but it cannot quietly patch code to make a check pass — fixes happen in a separate coding pass, then verification runs again.

​
The verification gate

Every completed task passes through the full pipeline before a pull request is opened:
1

Agent writes code

The build agent implements the task based on the specification.
2

Static checks

Type checking, linting, and tests must pass — if any fail, the agent fixes and retries.
3

Browser flows

The agent drives the running app in a real browser, exercising each acceptance criterion as a multi-step flow.
4

Design review

UI files are scanned for accessibility, dark-mode, layout, and placeholder issues.
5

PR opened

All checks passed — a pull request is created with verified, working code.

​
Static checks

The baseline gate, adapted to your stack:
For typed projects, full compilation must pass — no type errors, no missing imports, strict mode when configured. Python projects get mypy/pyright, Rust gets cargo check, and so on.
Code must pass your project’s configured linter (ESLint, Prettier, ruff, clippy, …) — consistent formatting, no unused variables, style guide compliance.
New tests must pass and existing tests must not break.
Verification rules are detected from your project configuration (tsconfig, eslint config, pytest.ini, etc.) — you don’t configure anything manually.

​
Browser flows

For anything with a UI, static checks aren’t enough. The agent drives your app in a real browser using scripted multi-step flows — the same way a user would:
  • Navigate to a page, then move between pages through the app’s own links and buttons
  • Fill forms and type into inputs
  • Click buttons and links (resolved by visible text or selector)
  • Wait for elements to appear after an action triggers a load
  • Evaluate JavaScript to assert the outcome — row counts, toast text, updated state
A flow that interacts with the app must assert its outcome in the same flow. Filling a form in one step and checking a count in a separate, unrelated flow proves nothing causally — the platform enforces that cause and effect are demonstrated together.
If a step fails, the flow stops and reports exactly which step broke and why — the agent adjusts and re-runs the remaining steps.

​
Screenshot evidence

Before/after screenshots are captured automatically around every flow. They appear as cards on the flow’s message in chat, so you can watch verification happen, and they’re collected in your project’s screenshot feed — the most recent one even becomes the thumbnail on your Preview button.

​
Design review

Alongside functional checks, an automated design review scans the UI files written in the session and returns issues with file, line number, severity, and a suggested fix:
  • Accessibility — missing alt text, unlabeled inputs, icon-only buttons without labels, removed focus outlines, click handlers without keyboard support, undersized touch targets, heading-hierarchy skips
  • Typography — missing font fallbacks, text too small to read on mobile
  • Layout — content-clipping overflow, fixed widths that break on mobile, z-index conflicts, inconsistent spacing scales
  • Color & dark mode — hardcoded colors without dark-mode variants, low-contrast text
  • Component states — buttons missing hover, disabled, or cursor styles
  • Leftover placeholders — lorem ipsum, TODO comments in rendered markup, example.com URLs, and hardcoded credentials
Errors must be fixed before the task completes; the review re-runs to confirm.

​
Verifying auth and roles

Apps with authentication get verified as real signed-in users. The agent provisions temporary test accounts on demand — and for role-based access control, it can create a separate test user per role (admin, member, employer, job-seeker, whatever your app defines) and sign in as each one to confirm that role-gated routes show the right thing to the right user.
Repeated verification of the same role reuses the same test user, so state you set up as “admin” persists across checks.

​
Verification before the PR

A pull request only opens after the acceptance pass finishes — the PR body lists the completed stories, and the evidence behind them (browser-flow steps, before/after screenshots, static-check results) lives in the chat feed and the project’s screenshot gallery. You review the PR knowing every story it lists was exercised, not just generated.

​
Why this matters

Without a verification gate, AI-generated code often has:
  • Type errors that surface only at build time
  • Features that compile but don’t actually work when clicked
  • UI that looks broken in dark mode or on mobile
  • Role checks that were never exercised
  • Placeholder text that ships to production
pre.dev eliminates these by making verification a gate — not an afterthought. The agent iterates until everything passes; you only see the final, verified result.

​
What’s next?

Pull Requests

Verified work ships as a PR — review and merge on your terms.

Preview & Hosting

See the verified build live at your project’s URL.