8 posts tagged with "QA Strategy"

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.

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.

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.