Skip to main content

7 posts tagged with "Build vs Buy"

View All Tags

Microsoft Just Built a Framework to Test AI Agents.

Divya Manohar
Co-Founder and CEO, DevAssure

Short answer

At Microsoft Build 2026, Microsoft shipped ASSERT (policy-driven agent evaluation) and ACS (runtime agent governance) — because the agent that writes the code cannot be the agent that grades the code. That is the same principle behind DevAssure O2: independent, browser-based testing on every PR, written in plain English, with no scripts to maintain.

At Microsoft Build 2026, Microsoft announced something that quietly confirms the core thesis behind DevAssure: as AI agents take over more of the software development lifecycle, the agent that writes the code cannot be the agent that grades the code.

The announcement was a pair of open-source projects — ASSERT (Adaptive Spec-driven Scoring for Evaluation and Regression Testing) and the Agent Control Specification (ACS) — designed to give developers a portable, framework-agnostic way to evaluate and govern AI agents before their behavior ships to production. Coming from the company now positioning itself as the "agent-first" platform for enterprise development, this is a meaningful signal about where the industry is heading.

I want to walk through what Microsoft actually shipped, why it matters beyond agent safety, and what it means for teams where 30–40% of code is already AI-generated — because the validation gap Microsoft just named at the agent layer is the same gap most engineering teams still have at the application layer.

Google I/O 2026 Went All-In on Agentic Coding. Here's What It Means for Testing.

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?

Why developers should stop writing Playwright tests

Santhosh Selladurai
Co-Founder and CTO, DevAssure

Playwright is one of the best browser automation frameworks ever built. It is fast, reliable, developer-friendly, and powerful. If your team knows exactly what to test, how the UI is structured, which locators are stable, and who will maintain the tests forever, Playwright is an excellent choice.

But that is also the problem.

Most product teams do not struggle because Playwright is weak. They struggle because writing and maintaining browser tests is still manual engineering work:

  • Every test needs scripts.
  • Every script needs locators.
  • Every locator can break.
  • Every UI change needs test maintenance.
  • Every failure needs someone to investigate whether the app is broken or the test is broken.

At some point, the test suite becomes another codebase to maintain.

Agent-based testing changes this model. Instead of writing scripts that tell the browser exactly what to click, type, and assert, you give the agent an objective. The agent understands the application, interacts with the UI, adapts to changes, validates behavior, and reports issues.

That is why developers should start moving away from writing Playwright tests manually.

The Quiet Death of the Test Script

Divya Manohar
Co-Founder and CEO, DevAssure

For twenty years, automated testing meant writing more code. That era is ending — and most teams haven't noticed yet.

The first automated test I ever wrote was in Playwright. It was 2012. It launched a browser, filled in a login form, and checked that the dashboard loaded. It passed. I felt like a wizard.

More than a decade later, the fundamental contract hasn't changed. To test software, you write more software. You describe, in code, what your code is supposed to do. Then you maintain that second codebase forever.

We've built entire careers, conferences, certifications, and consultancies on this premise. Selenium. Cypress. Playwright. Test pyramids. BDD. Page object models. The whole apparatus rests on a single assumption: humans must specify, in writing, what to test.

That assumption is quietly dying.

The Hidden Bill - What It Actually Costs to Use Your Coding Agent as Your Testing Agent

Divya Manohar
Co-Founder and CEO, DevAssure

A CTO told me last month, very pleased with himself:

"We're already paying $200/month per dev for Claude. Testing is basically free now — we just ask Claude to also write the tests."

I asked him to pull up his Anthropic bill. The number was 14x what he'd budgeted at the start of the quarter. And his team still hadn't shipped the regression suite.

This is the most expensive trap in the AI tooling stack right now, and it's expensive precisely because it looks free. If you've already bought a coding agent, asking it to do double duty as a testing agent feels like the obvious move. One subscription, one workflow, one bill.

Except there is no "one bill." There are six.