Canary Reads the Code, So It Knows What the Bug Will Break

The bug did not look like a bug. It looked like a clean pull request - a small change to how invoices were calculated, the kind of diff a human reviewer skims and approves in under a minute. Nothing in the file view screamed danger. Then Canary ran the flow the way a customer would, and found a $1,600 drift sitting quietly in a construction company's invoicing path, waiting to ship.

That is the pitch, more or less. Canary, a two-person startup in Y Combinator's Winter 2026 batch, calls itself "the first AI QA engineer that understands your codebase." The claim is specific and worth unpacking, because the crowded field of AI testing tools mostly does something different: it looks at the rendered page, scrapes the document object model, or takes screenshots and guesses. Canary starts one layer down, in the source code itself.

// When shipping gets faster than checking

The founders, Aakash Mahalingam and Viswesh N G, arrived at Canary from inside the AI coding boom. Mahalingam was an engineer at Windsurf, building AI coding tools used by Fortune 10 companies. Viswesh had written software at Google and Swiggy on maps and fraud detection. They watched the same thing happen at close range that everyone else has felt: AI made writing code dramatically faster, and the checking that is supposed to follow did not move at the same pace.

Their framing of the gap is blunt. "AI coding tools have made developers 100x faster," their launch reads, "but customer-facing incidents are up 43% YoY, QA hasn't kept up." Pull requests got larger. Reviews still happened in file diffs. And changes that looked clean broke checkout, authentication, and billing once real users touched them.

The insight underneath Canary is that a diff and a user flow are two different things. A reviewer reading a diff sees the lines that changed. A user does not click on lines - they click through checkout, log in, update a setting, and rely on a dozen features that the changed lines quietly feed into. The failures that hurt are second-order: the edit that looks isolated but reaches into billing three files away.

It is a familiar shape of pain. Most engineers can recite the version they lived through: a one-line config change that took down sign-ups, a refactor that passed every unit test and still broke the one flow that mattered on Friday afternoon. The unit tests were green. The pull request was approved. The incident happened anyway, because nobody had time to click through the twenty flows the change quietly touched. Canary's argument is that clicking through those flows is exactly the kind of patient, unglamorous work that should not require a human to stay late.

"Changes that looked clean broke checkout, auth, and billing in production. Reviewers read diffs. Users click buttons."

// A teammate that lives on your pull requests

In practice, Canary connects to a codebase and reads its structure - routes, controllers, validation logic - to build a picture of what the software is meant to do. When an engineer opens a pull request, Canary reads the diff, works out the intent behind the change, and then generates and runs end-to-end tests against a preview version of the app. It comments the results, with recordings, directly on the PR, so the feedback lands where the work is already happening.

Crucially, Canary is built to go past the happy path. Anyone can confirm that the login screen loads. The harder, more valuable work is generating the edge cases designed to break the application - the odd input, the second-order interaction, the flow nobody thought to retest. A second product line handles regression testing: continuously running suites described in plain English, so features that worked yesterday keep working as the code underneath them shifts.

The plain-English part is easy to underrate. Test suites have historically been code that only engineers can read and only engineers can maintain, which means the person who understands a business flow best - the product manager who knows why refunds behave the way they do - has no direct way to encode it. Describing a test in a sentence and having Canary keep it running lowers that barrier, and quietly widens who gets to say what "working" means.

There is a limitation the team is upfront about. Today Canary supports web applications. Mobile testing on device emulators is on the roadmap, not in the box yet.

// The reliability cascade

The part the founders seem proudest of is the least glamorous: infrastructure. Running an AI agent that can actually exercise your app - not just describe it - means building browser fleets, ephemeral environments, data seeding, device emulators, and visual verification. "Solving for infrastructure is a huge part of the problem too," Mahalingam has said, and it is the piece they argue competitors will not simply hand over.

To keep tests trustworthy rather than flaky, Canary uses what it calls a reliability cascade. It reaches for the most deterministic method first, and only escalates to fuzzier, AI-heavier checks when it has to:

The order matters. Screenshot-first tools live at step three permanently, which is where flakiness breeds. By treating vision as a last resort rather than a first instinct, Canary is betting on stability - the difference between a test suite engineers trust and one they learn to ignore.

// Grading its own homework, in public

Benchmarks are easy to assert and hard to publish. Canary published one. QA-Bench v0 pits its agent against GPT-4.5, Claude Code (Opus 4.6), and Sonnet 4.6 across 35 real pull requests, scored on three axes: Relevance, Coverage, and Coherence. The test PRs came from recognizable open-source projects - Grafana, Cal.com, Mattermost, and Apache Superset - rather than toy examples. On coverage, Canary reported leading GPT by 11 points, Claude Code by 18, and Sonnet by 26.

The choice of coverage as the headline metric is telling. A general-purpose model can write a plausible test; the question is whether it tests the right things - the flows a specific change genuinely put at risk. That is the gap between a smart model and a QA engineer, and it is the gap Canary is trying to stand in.

// Where Canary sits

Canary lands in a market with several kinds of incumbent. There are the manual QA teams, slow and expensive but genuinely thoughtful. There are the classic automation frameworks - Playwright, Cypress, Selenium - powerful but requiring humans to write and maintain every test. And there is the new wave of AI testing tools that scrape the DOM or read screenshots. Canary positions itself against all three by reading source code for intent and owning the infrastructure that makes the tests run for real.

The business is straightforward B2B software: sell an AI QA layer to engineering organizations, meter it against the manual testing it displaces. Pricing is not public yet, which is normal for a company this early. What is clear is the wedge - the pull request - and the promise attached to it: teams that spent weeks on manual testing reaching 90%-plus coverage in days.

The competitive question that follows is whether the general-purpose models eat this category from above. Any capable coding agent can be prompted to write a test; the foundation labs keep getting better. Canary's bet against that is the same bet the benchmark makes - that knowing which flows a change endangers, and having the browser fleets and seeded environments to actually run them, is a different job than raw model intelligence. Infrastructure is unfashionable to build and hard to copy, which is precisely why the founders keep pointing at it.

// Two people, one legal name that gives away the joke

The company is incorporated as Canaries, Inc., which is the kind of name that tells you the founders thought about the metaphor. A canary in a coal mine is an early warning - the small thing that notices danger before anyone gets hurt. That is the job description, compressed into a bird.

Mahalingam is cofounder and CEO; Viswesh is his cofounder, having written systems at Google and Swiggy before this. Their shared background in AI coding tools - at Windsurf, Cognition, and Google - is not incidental. They built the tools that made developers faster, then went to fix the specific problem those tools created. It is a tidy, believable origin: the people who helped speed up shipping now selling the brakes.

Two people is a small team to take on a category this broad, and the honest read is that Canary is very early - a Winter 2026 batch company with a public benchmark, a handful of customers, and web-only support. But the wedge is sharp, the demo is legible, and the problem is one every engineering team can name from memory. Whether Canary becomes the default QA teammate or one of several, it is pointing at something real: the checking did not keep up, and someone was going to try to fix it.