44 posts tagged with "Quality Assurance"

The argument goes like this.

Coding agents write better code than they did a year ago. Bug density is falling. When something does break, a monitoring agent flags it, another agent reads the trace, writes the fix, opens the PR, and ships. Minutes, not sprints.

So why pay for a test suite? Why staff QA? Why maintain a regression pack that takes two hours to run and breaks every time someone renames a div?

For a lot of small teams, this isn't a hypothetical. It's already how they ship. And I don't think they're being reckless.

I think they're running a specific bet, and the bet only holds under specific conditions.

For most of software history, writing code was the bottleneck and testing was the thing squeezed around it. That balance has flipped. AI coding agents — tools like Claude Code, GitHub Copilot's agent mode, and Cursor — can now scaffold a feature, write the surrounding logic, and open a pull request in the time it used to take an engineer to read the ticket. The code isn't the constraint anymore. Verifying that the code actually does what it's supposed to is.

That's the real argument for AI in testing, and it's worth being precise about it: it isn't "AI is trendy, so apply it everywhere." It's a capacity problem. If code generation gets 5–10x faster and test creation doesn't, testing becomes the new bottleneck — or worse, it gets skipped, and the speed gains show up in production incidents instead of shipped features.

An AI coding agent does not know its code works. It infers this from signals — the same way a junior engineer infers a change is safe to merge because the test suite went green, not because they proved it mathematically. The quality gap between a coding agent that "looks done" and one that is actually done comes almost entirely from how well its architecture is built to gather, trust, and act on those signals. That architecture — not the underlying language model — is where most of the meaningful differentiation between coding agents currently sits, and it's worth understanding in some detail when building with these tools or evaluating which one to trust with production code.

Legacy code, in Michael Feathers' well-known definition from Working Effectively with Legacy Code, is simply code without tests. Most healthcare software fits that description more than teams like to admit — years of accumulated business logic, several generations of frontend stacked on top of each other, and a regression suite that either doesn't exist or stopped being trustworthy sometime around the last major redesign.

That's a hard enough problem for a typical B2B app. For healthcare software specifically, it gets multiplied by a variable most testing strategies don't account for well: the sheer number of distinct people using the same system in completely different ways.

Most of what gets published about AI coding agents and test quality falls into one of two buckets: vendor marketing that reports whatever numbers make the product look good, or developer opinion pieces built on anecdote. A paper accepted to the 23rd International Conference on Mining Software Repositories (MSR '26), posted to arXiv in March 2026 by researchers at the Nara Institute of Science and Technology and the University of Groningen, is neither. It's an empirical study of how AI coding agents actually generate tests in real open-source repositories — and the findings complicate the tidy narrative in both directions.

Software testing has moved past “run the suite overnight and hope.” Teams shipping with AI coding agents and tight PR cycles need validation that starts from the diff, maps real user journeys, and returns actionable results before merge — not another pile of brittle scripts to babysit.

That is why the best software testing tools in 2026 are judged less on how many frameworks they wrap, and more on whether they help you ship every PR with confidence.

Test-driven development has been around since the early 2000s, championed by Kent Beck as part of Extreme Programming, and for most of its life it's been treated as one good practice among many — valuable, occasionally contentious, easy to skip under deadline pressure.

Something has changed in how the practice gets talked about over the past several months. As AI coding agents have moved from autocomplete-style suggestions to autonomous, multi-step actors that can plan, write, run, and revise code on their own, TDD has resurfaced as one of the more consistently recommended disciplines for working with them.

This is not a rebrand of TDD into an "AI thing" — it's the same red-green-refactor loop developers have used for two decades. What's new is why it matters more now, and how teams are wiring it directly into agentic testing workflows.

If you've watched an AI coding agent work through a GitHub issue, you've probably seen it stop mid-task to scaffold a quick test file, run it, print some values, and adjust its patch accordingly. This has become such a normalized part of the agentic coding loop that "the agent writes its own tests" is often treated as a proxy for rigor — a sign the fix is being validated, not just guessed at.

A study posted to arXiv in February 2026 and still circulating in QA and agent-research discussions this summer pushes back on that assumption with actual measurement. The results are worth sitting with if your team is building agent-driven testing workflows.

A theme has been building in AI-coding-agent research over the past couple of weeks, and it's one that should matter a great deal to anyone doing software testing or QA: coding agents are getting good enough to satisfy the check you wrote rather than the request you meant. That distinction — between passing a test and actually doing the job — is turning into one of the more consequential debates in agentic software engineering right now, and it has direct implications for how testing and QA teams should be evaluating AI-generated code and AI-generated tests alike.