What is the difference between release QA and autonomous QA?

Release QA typically validates software late in the cycle — often with full regression suites, manual sign-off, and exceptions when deadlines slip. Autonomous QA validates each pull request inside the development workflow: an agent like DevAssure O2 reads the diff, maps impact, runs only relevant behavioural checks, and reports on the PR without maintaining thousands of scripts.

Why do PR bottlenecks hurt developer productivity more than slow coding?

Developers with strong testing discipline often ship 2–3 production-ready PRs per week. Others spend days on flaky UI tests, broken locators, environment instability, and CI reruns unrelated to their change. PR queue time and missed first-pass green builds are what leadership metrics (PR velocity, patch-after-freeze rate) actually measure.

What does “run everything” testing cost engineering teams?

When impact radius is unknown, CI defaults to running entire suites — thousands of tests for a small UI change. That drives high compute cost, multi-hour feedback loops, slower merges, and pressure to bypass gates or patch after release. Impact-aware validation reduces scope to what the change can break.

How does DevAssure O2 validate a pull request without test frameworks?

O2 is an autonomous testing agent: it understands the code change, identifies affected flows, generates and runs behavioural tests in a real browser, and posts results on the GitHub pull request. Teams add devassure-ai/devassure-action@v1 to pull_request workflows — no checked-in Playwright or Cypress inventory required.

Can O2 replace release managers choosing between speed and quality?

The goal is to remove that trade-off at the PR boundary. Validation runs continuously per change with outcome-focused checks instead of script maintenance. Release trains move when PRs pass meaningful gates on first attempt, not when someone approves skipping flaky jobs.

How do engineering leaders measure if quality systems help or hurt velocity?

Track PR velocity per developer, percentage of PRs passing validation on first attempt, green build rate at first pass, time in queue, release delays attributed to quality, and patch requests after feature freeze. If those worsen while sprint velocity looks fine, testing friction is the bottleneck.

How do I test AI-generated code on a pull request?

Add a pull_request GitHub Action that validates the diff. Static analysis and unit tests help but miss user-visible regressions. An autonomous agent like DevAssure O2 reads the PR, generates behavioural E2E tests, runs them in a browser, and posts a check — without you authoring Playwright specs.

Why does asking Cursor to write tests not fix vibe-coded PRs?

The coding agent and the test author share the same assumptions. Tests often assert what the model intended, not what the running app does. PR-level testing needs an independent agent that evaluates the change cold, like a user would.

Is this different from CodeRabbit or AI code review?

Yes. Review tools analyse source. A testing agent exercises the deployed or preview app — catching broken checkout flows, wrong totals, and missing validation that never appear as obvious diff comments.

Does DevAssure O2 work with Cursor and GitHub together?

Yes. Install the Invisible (QA) Agent from Open VSX in Cursor for pre-push feedback, then add devassure-ai/devassure-action@v1 on pull_request. Same O2 agent in the IDE and CI.

What preview URL does O2 need for a vibe-coded PR?

A reachable staging or Vercel preview URL for that PR branch — the same URL you would manually click through. O2 drives the app in a browser; it does not merge code without a running environment.

Does autonomous PR testing work with monorepos?

Yes. The agent reads the PR diff, so only packages and paths touched in that change are in scope. In a Turborepo or Nx monorepo, a change limited to apps/web still maps to web flows — you are not forced to run the entire company-wide suite on every PR.

Does this work with private GitHub repositories?

Yes. Add DEVASSURE_TOKEN as a repository secret and run devassure-ai/devassure-action@v1 in your private repo the same way as a public one. The agent runs inside your GitHub Actions runner; source stays in your environment per your secret and network policies.

Can I auto-test Next.js, React, or Vue pull requests?

Yes. The agent validates a running app (staging preview, Vercel preview URL, or local URL exposed to CI). Framework does not matter — React, Next.js, Vue, Svelte, and Rails SPAs all work as long as the PR deploy or preview is reachable from the runner.

Do I need existing Playwright or Cypress tests?

No. That is the point of autonomous PR testing: tests are generated from the diff for that PR. You can keep legacy suites in parallel during migration; O2 does not require them to exist first.

How is this different from only adding Playwright to GitHub Actions?

Playwright in Actions runs tests you already wrote and must maintain. An autonomous agent generates and executes tests from the change itself — no checked-in spec files, no selector updates when a designer moves a button.

What if my team already has a full E2E suite?

Many teams run both: legacy suite on a schedule or nightly, and an autonomous agent on every PR for change-scoped validation. That catches gaps where nobody wrote a test for the feature you just shipped.

38 posts tagged with "CI/CD"

View All Tags

Why We Built DevAssure O2 for PRs

Badri Varadarajan

Co-Founder and COO, DevAssure

Short answer

Engineering velocity is rarely limited by how fast people write code. It is limited by testing friction on pull requests — flaky suites, run-everything CI, and release gates that force a choice between speed and quality. DevAssure O2 was built to validate every PR from intent and impact inside the developer workflow, without maintaining brittle test scripts.

For years, I led teams focused on engineering productivity and release management across startups and enterprises. My primary job was not just shipping features — it was ensuring release trains moved predictably, developers remained productive, and quality gates did not become velocity killers.

One thing became very clear over time:

Engineering velocity was rarely limited by coding speed. It was limited by testing friction.

Catch Vibe-Coded PR Bugs Before Merge

Divya Manohar

Co-Founder and CEO, DevAssure

Short answer

Vibe-coded PRs break production because speed outruns validation: the diff looks fine in review, but behaviour regresses. Fix it at the pull request with an agent that tests the running app on each PR — not with more AI-written unit tests or line-by-line review alone.

You merged on Friday. Checkout looked fine in the diff. By Monday, support tickets say promo codes stop applying after a failed payment retry.

The PR was 400 lines, mostly written by Cursor in an afternoon. Two approvals. Green CI — because unit tests passed and nobody had an E2E check for that path.

Automatically Test Every Pull Request

Divya Manohar

Co-Founder and CEO, DevAssure

Short answer

To automatically test every pull request on GitHub in 2026, add a pull_request workflow in GitHub Actions. The usual path is Playwright or Cypress plus tests you write and maintain. The alternative is an autonomous testing agent that reads the PR diff, generates E2E tests for that change, runs them, and posts a check — with zero test files in your repo.

Every team wants E2E tests on every PR. Almost none actually has them — because someone has to write those tests, fix them when the UI changes, and defend a thirty-minute CI job that still flakes.

If you are the developer opening the PR, that someone is often you, after hours, clicking re-run on a red check you do not trust.

Add Power to Your TestRail Test Cases with DevAssure

Santhosh Selladurai

Co-Founder and CTO, DevAssure

Your team already plans and tracks tests in TestRail. The gap is execution: turning those cases into reliable UI automation without a second script suite to maintain. DevAssure closes that loop—fetch cases from TestRail, run them in a real browser with an AI agent, and optionally sync results, defects, and videos back to TestRail.

Every TestRail workflow in this guide is available in two places: the @devassure/cli for terminals and CI/CD, and the DevAssure VS Code extension (VSCE) for interactive runs from the IDE. Configure once—credentials and post-result settings are shared between both.

Google I/O 2026: Agentic Coding and QA

Divya Manohar

Co-Founder and CEO, DevAssure

TL;DR

Google I/O 2026 shifted from AI-assisted to agentic coding — Antigravity 2.0, Managed Agents, Gemini 3.5 Flash, and more. Generation got massive investment; validation did not. Engineering leaders need a quality layer that scales with agent output: independent testing on every PR, not more human review. That is what DevAssure O2 is built for.

Google I/O 2026 made one thing unmistakably clear: the era of AI-assisted coding is over. The era of AI-agentic coding has begun.

The keynote opened with a line I have been thinking about since:

"We've transitioned from AI that simply assists you, to agents that can independently navigate complex tasks across your entire workflow."

What followed was a two-hour parade of agent-first announcements: Antigravity 2.0, the Antigravity CLI and SDK, Managed Agents in the Gemini API, Gemini 3.5 Flash, WebMCP, Chrome DevTools for agents, an Android migration agent that converts entire React Native apps to Kotlin, and vibe-coding Android apps directly in Google AI Studio.

Most commentary since has focused on productivity. How fast can you ship? How many agents can you orchestrate in parallel? How much code can Gemini 3.5 Flash produce per minute?

I want to focus on a different question — one Google did not spend much time on during the keynote:

Who tests what the agents produce?

Vibe Coding Quality Gap: Use a Test Agent

Divya Manohar

Co-Founder and CEO, DevAssure

TL;DR

Vibe coding ships features in minutes - but AI-generated code has 1.7× more production issues than hand-written code, and asking the same AI to write tests repeats the same blind spots. The fix is not more tests; it is an independent testing agent that reads each PR cold. DevAssure O2 validates vibe-coded diffs at PR speed with zero scripts to maintain.

Last week I watched a developer build an entire payment integration in 35 minutes using Cursor.

User authentication. Stripe checkout. Webhook handling. Invoice generation. All wired up and functional.

In 2023, that is a week-long sprint. In 2026, it is a Tuesday morning before standup.

Then we ran DevAssure's O2 Agent on the PR.

Focus on the merge gate? Read the companion: Why your vibe-coded PR keeps breaking production — the handoff from coding agent to CI, not the quality-gap theory.

Shift Left Failed. Autonomous Testing Is What Comes Next.

Divya Manohar

Co-Founder and CEO, DevAssure

TL;DR

For a decade, shift left meant developers write more tests earlier. That overloaded engineers, bloated suites, and barely moved the bug needle. Autonomous testing keeps the timing - tests at the pull request - but changes the mechanism: an agent reads the diff, generates scoped tests, runs them, and leaves nothing to maintain. DevAssure calls this shift smart: AI handles execution; humans handle judgment.

For a decade, the testing industry rallied behind a simple mantra: shift left.

Find bugs earlier. Test sooner. Put quality in the hands of developers.

The theory was sound. A bug caught in development costs roughly 10× less than one found in production. Move testing to the left of the timeline, and you save money, ship faster, and improve quality.

But here is what actually happened:

Set Up Vibe Testing on Every Pull Request

Divya Manohar

Co-Founder and CEO, DevAssure

TL;DR

You can add agent-driven E2E testing to your repository in under two minutes by dropping one GitHub Actions workflow file into .github/workflows/. Once it is in, every PR triggers an AI agent that reads the diff, generates targeted end-to-end tests, runs them on real browsers, and posts results back as a GitHub check. No Playwright scripts, no Cypress maintenance, no QA bottleneck. This guide walks through the exact setup, what each stage does, and how to verify it is working.

Every team that adopted vibe coding eventually hits the same wall: code ships faster, but validation does not keep up. This post is the implementation manual for closing that gap on every pull request.

How to Test Cursor-Generated Code

Divya Manohar

Co-Founder and CEO, DevAssure

TL;DR

Cursor lets you ship features roughly 5× faster, but AI-generated code contains 1.7× more major issues than hand-written code, and 63% of developers using AI tools now spend more time debugging. The fix is automated end-to-end (E2E) testing that runs inside your IDE and on every pull request. DevAssure's Cursor extension plus GitHub Action gives you both — with zero test scripts to maintain.

Cursor changed the default for how features get built. What has not changed is that untested code still breaks production — it just gets there faster.