Green Tests, Broken Apps: The AI Testing Trap

A green CI dashboard is one of the most reassuring things a developer can see. It is also, increasingly, a lie.

That's not a hot take—it's the practical consequence of a problem Marlene Mhangami, senior developer advocate at Microsoft and GitHub, laid out at the AI Engineer conference: when you ask an AI agent to write your tests, it tends to write tests that confirm what the code does, not tests that verify what the user is supposed to experience. Your test suite passes. The behavior you promised your users? Nobody checked.

I cover security for a living, so let me translate that into my language: untested behavior is unknown behavior. And unknown behavior is attack surface. The logic errors that slip past a confident green dashboard are exactly the kind of thing that ends up as a CVE eighteen months later—not because someone wrote malicious code, but because nobody ever asked whether the system did what it claimed. "Self-affirming tests," Mhangami calls them. In security, we call the result "unexpected code paths." Those paths get found. Just not always by you first.

The volume problem

GitHub's own Octoverse data puts some scale on this. According to Mhangami's talk, about a billion commits were pushed to GitHub in 2025—the platform's biggest year ever. At the AI Engineer conference, Mhangami cited a recent tweet from GitHub COO Kyle Dагel claiming the platform is currently seeing around 275 million commits per week. That figure hasn't been confirmed in any official GitHub release as of this writing—Mhangami was clear it came from a tweet, not a formal report—but if you extrapolate it forward, you land somewhere around 14 billion commits by year's end. That extrapolation is my math, not GitHub's claim, but the direction of travel isn't in dispute.

A growing share of those commits are AI-co-authored. Some agents sign their commits (Copilot and Claude do; Codex doesn't, though GitHub says it can track AI involvement through other signals). More code, faster, from agents that work tirelessly and make consistent, patterned mistakes.

The question Mhangami asks—and that a referenced Stanford study of 120,000 developers attempts to answer (the study was surfaced at AI Engineer 2024; I've not been able to locate a formal publication link, and I'd recommend treating it as directional rather than definitive until the citation is pinned down)—is whether all this output actually makes developers more productive. The answer, per that research: it depends entirely on the state of the codebase. Clean codebases amplify AI gains. Messy ones amplify entropy. One case study in the talk showed a team whose PR volume went up while code quality declined, with so much time lost to rework that net productivity improved by roughly one percent. One percent. They'd have been better off being slightly more careful the first time.

What TDD was always supposed to fix

Test-driven development has been around long enough to have been declared dead. DHH—David Heinemeier Hansson, creator of Rails—wrote the obituary in 2014, arguing that TDD's obsession with unit tests and code coverage was producing brittle, implementation-coupled test suites that didn't actually verify system behavior. (The post is findable if you search "DHH TDD is dead"; I'm not linking a specific URL because the piece has moved around, and I'd rather you find the current canonical location than a dead link.) The critique landed. The industry largely agreed that coverage metrics were being gamed, that renaming a method could shatter a test suite without breaking any actual functionality, and that the question "does this code pass its tests" had drifted dangerously far from "does this software work."

Mhangami's argument is that AI makes the underlying problem worse—and also, if you structure it right, gives you the tools to fix it faster than ever.

The approach she's advocating is red-green TDD applied at the behavioral layer: write failing end-to-end tests against the expected user experience before you write any code, then generate code to make those tests pass, then spend your real human time on the refactor. The AI handles the mechanical phases. You handle the judgment call about whether the result is actually good.

The tool she's using to anchor that behavioral layer is Playwright, Microsoft's open-source browser automation framework. Playwright tests don't ask whether a method returns the right value. They ask whether a user who types "Furby" into a search bar sees Furby in the results. They click the buttons. They check the filters. They validate what a real person would experience, at the browser level, in the actual interface.

"When I run these functionality tests," Mhangami said during a live demo, "I can see actively that the agent has written this code, the code is working as I expected, the app is working as I expected."

That's a different claim than "the unit tests pass." It's a claim about the system.

The security layer nobody mentions at dev conferences

Here's what I find conspicuously absent from most conversations about AI code quality: the security implications aren't downstream of the quality problem. They are the quality problem, manifesting in a different context.

When AI generates self-affirming tests—tests that verify the code does what it does, rather than what it should—you end up with behavior that exists but was never specified, never tested against a real requirement, and never reviewed for edge cases. That's not just a UX bug waiting to happen. Authentication logic that works for the happy path but breaks under unexpected input. Access control that passes unit tests but fails when a user hits an endpoint in a sequence nobody anticipated. Search filters that return correct results in test but leak data when parameters are malformed.

I'm not saying Playwright solves these problems directly—it doesn't. Browser-level end-to-end testing won't catch a SQL injection flaw or a broken authorization check. But the discipline Mhangami is describing—start with the behavior you expect, then make the code match it, then review whether the code is actually good—is the same discipline that separates software you can reason about from software that surprises you. Security teams live in the territory of software that surprises people. I'd rather developers spend less of their time there.

What to actually do Monday morning

Mhangami closed with practical guidance, and I'm going to own these as direct recommendations rather than just relay them, because they're good:

Commit before you let the agent make changes. If you don't, the agent loses context about the prior state of your code and may not be able to roll back intelligently. This sounds trivial. It will save you an afternoon.

Write one test per feature, not one test per method. The trigger for a new test should be an incoming feature request, not a new class method. That's the mental model shift Mhangami is advocating, and it's the right one.

Add Playwright screenshots to your PRs. Playwright captures screenshots during test runs automatically. Dropping those into your pull request gives reviewers visual evidence of what the UI was actually doing when tests passed. This is a two-minute habit that makes code review meaningfully better.

For state-heavy applications, use Playwright Agents. Running the Playwright agents setup installs three specialized agent files—a planner, a generator, and a healer—with instructions pre-built for handling complex state. If you've been fighting with Playwright on stateful flows, this is the thing to try first.

Headless mode is fine for CI; headed mode is useful for debugging. You don't need to watch the browser on every run. But when something fails and you can't figure out why, watching the agent actually click through your interface is a faster diagnostic than reading stack traces.

You can connect Playwright to your agent via the Playwright MCP server, the CLI tool, or Playwright Agents directly. The MCP server is the most straightforward integration if you're working in GitHub Copilot's CLI environment, which is what Mhangami demoed.

One flag: During the demo, Mhangami referenced a Microsoft tool—she appeared to say "WorkIQ"—that she described as a GitHub Copilot skill for pulling M365 data (Outlook, PowerPoint, etc.) directly into the terminal. I can't verify "WorkIQ" as a current, publicly documented Microsoft product name; it may be an internal name, a very new release, or something I'm mishearing from the conference audio. If you're trying to replicate this part of the demo, I'd check Microsoft's current Copilot extensions documentation rather than searching for that specific name.

The actual answer

More code and better software are not on the same trajectory right now. But they could be—if the industry decides that "the agent shipped it" is not a sufficient answer to "did anyone check that it works."

Mhangami's framework isn't a magic fix. Behavioral tests can still miss things. Refactoring still requires judgment that agents don't reliably have. But the sequence she's describing—behavior first, code second, human review third—is how you build software you can actually stand behind. The alternative, which is letting AI write both the code and the tests that confirm the code, is how you build a dashboard that looks good right up until it doesn't.

A green test suite is evidence. It's not proof. Know the difference, and build accordingly.

---

Rachel "Rach" Kovacs is Buzzrag's cybersecurity and privacy correspondent.