Testing is a place where dedicated AI tools make an insane difference
Most of the conversation around software engineering with AI is focused on writing code faster.
This is the most obvious win. You open a coding agent, describe the thing you want, watch it edit files, run tests, fix errors, and maybe open a PR. If you are a software engineer, this still feels a little ridiculous even after you have seen it a hundred times.
A ton of the newsletter focuses on this workflow. Using AI to write code faster. It’s probably why you subscribed!
But I think we are already moving into the next set of problems. Coding isn’t the bottleneck for high-performing teams anymore.
Once your team can generate more code, the question changes from “can we build this?” to “can we safely ship this?”
That is a much less fun question. It is also the question that decides whether AI actually makes engineering teams more effective or just gives them a faster way to create messes.
I have been using AI tools heavily in my own development work. I am very bullish on them. But the longer I use them, the more convinced I am that testing and quality engineering are going to become more important, not less.
We already compromise on testing #
The perfect story of writing software is something like this:
You write the feature. You write or update the tests. Maybe you do this in reverse! CI runs. The team reviews the PR. Everything ships with confidence.
But what usually happens isn’t as clean. Sometimes you write solid coverage. But sometimes you test the happy path because the release is already late. Sometimes the flaky test just gets rerun until it passes. Sometimes the code is technically covered, but the test is mostly checking implementation details. Sometimes the actual risky behavior is buried in a background job, a permission check, a billing edge case, or some third-party integration nobody wants to touch.
Testing is hard to dedicate time to because it is often too tempting to stop at good enough. Product pressure or even implicit pressure from leadership is enough to put testing on the backburner.
Tricentis’ 2026 Quality Transformation Report puts numbers behind this. According to the report, 60% of organizations say they regularly ship untested code into production. The top reasons are leadership pressure to move faster and having too much code to test.
AI-generated code is still code #
There is a weird temptation to treat AI-generated code as a separate category.
Sometimes AI gives you a perfect one-shot. Sometimes it is horrifyingly off the mark. Even worse, sometimes it’s believable but subtly incorrect.
This is my whole thesis behind AI-augmented engineering being better than vibe coding.
A coding agent can implement a billing change without knowing the weird enterprise customer that has a custom contract. It can modify an authorization policy without understanding why a previous bug caused a support incident. It can update a controller, service object, API endpoint, or queue worker and miss the downstream behavior that is obvious only to someone who has lived in the codebase.
AI is often good at producing a reasonable first pass. It is useful for generating tests you were too lazy to write. It is useful for summarizing a diff. It is useful for brainstorming edge cases. It is useful for asking, “What did I forget?”
But AI does not automatically know what your business considers risky.
That context has to live somewhere. In a small team, it might live in the heads of a few senior engineers. In a large company, it is usually scattered across ticket history, test management tools, QA processes, tribal knowledge, production incidents, compliance requirements, and whatever comments happen to be on the PR.
That is not a great foundation for AI-augmented delivery. Once you accelerate software production by even a conservative multiple, you’ll inevitably begin breaking things at an unacceptable pace.
The useful version of AI testing starts before implementation #
The most obvious version of AI for testing is “write unit tests for this function.”
I still do that. It is very useful, but it is not where the real leverage is.
The more useful workflow starts before the code exists.
Take a normal ticket:
“Add support for prorated refunds when a customer downgrades mid-cycle.”
A mediocre AI workflow says, “Implement this.”
A better workflow asks AI to help turn the request into a quality plan before anyone touches the code.
What are the business rules?
What should happen when the customer has a coupon?
What if the downgrade happens one minute before renewal?
What if the payment provider fails?
What if the account has multiple seats?
What data needs to remain auditable?
What existing tests probably need to change?
What flows should QA validate manually?
You’ve probably heard me refer to these as living specs.
That is where AI starts feeling more like an engineering assistant. It can help expand a vague ticket into the set of behaviors the team actually needs to protect.
As a developer, I care about this because most bugs are not caused by forgetting syntax. They come from incomplete understanding. The code does exactly what someone told it to do, but the ticket did not describe the weird case, or the developer did not know about an old workflow, or the reviewer missed the hidden coupling.
AI can help with that, but only when it is part of the actual delivery workflow instead of a side chat window where context goes to die.
AI Workspace offers a useful platform for this #
Tricentis, the company behind Tosca, has introduced “AI Workspace”.
AI Workspace is a purpose-built tool built around the practical idea that if AI agents are going to participate in quality engineering, companies need a controlled place to run them.
This article is sponsored by Tricentis, the company behind AI Workspace. I’m happy to be covering this topic because testing is one of the places where AI-augmented development gets very tricky, very quickly.
If you want to try out AI Workspace, you can book a demo today :) The product is positioned as a control plane for agentic quality engineering. In plain English, that means it gives teams a place to design, deploy, govern, and monitor AI agents that work across testing and quality workflows.
That phrasing sounds enterprise-y, but the underlying problem is real.
Once AI enters the SDLC, you do not want ten disconnected agents all doing their own thing. One agent generating tests. Another choosing what to run. Another summarizing failures. Another commenting on PRs. Another making release recommendations. Nobody knows what ran, why it ran, who approved it, or whether it followed the process the team agreed on.
AI Workspace tries to make this manageable by centralizing agent management, workflow orchestration, human review gates, visibility into AI decisions, and auditability. The goal is not “let the robot ship to production.” The goal is to let AI do useful quality work inside boundaries the team can see and control.
That is the part I find compelling.
I have no interest in an AI tool that silently decides a release is safe. I do want AI to help me analyze the change, find the risky areas, recommend the right validation steps, generate missing coverage, run the relevant workflows, and bring a human in when the decision actually requires judgment.
Solving AI-augmented testing at enterprise scale is a challenge #
For an individual engineer, AI-assisted testing can be pretty lightweight. Ask your coding tool for edge cases. Generate a few tests. Have it explain a failure. Ask it to review your diff for missing coverage. That is useful, and many developers should be doing more of it.
The enterprise version is different.
Large teams have multiple tools, release processes, compliance rules, test environments, packaged applications, custom applications, and different groups with different definitions of quality. Developers might care about maintainability and correctness. QA might care about coverage and release readiness. Security cares about risk. Product cares about customer behavior. Leadership cares about speed and predictability.
A product like AI Workspace makes the most sense in that environment. It gives the organization one place to coordinate AI assistance for quality work, enforce approval gates, monitor what agents are doing, and preserve an audit trail. That is less exciting than a coding demo, but it is the kind of thing enterprises need before AI becomes part of normal delivery.
How I would actually use AI for testing #
If I were rolling this out on a team, I would start with a few specific workflows rather than trying to “AI-enable QA” as a broad initiative. First, I would use AI to turn tickets into test plans. Every meaningful ticket should produce a short list of expected behaviors, edge cases, affected areas, and open
questions. Many teams do this already as part of a work refinement process.
Second, I would use AI during PR review to summarize risk.
Third, I would use AI during code review to catch mistakes.
Fourth, I would use AI to triage failures. When CI fails, I want help separating likely flakes from real regressions, grouping related failures, and pointing to the probable root cause.
You could do all of this in isolation, but these workflows need governance. The team should know which agent did what, what information it used, what it decided, and when a human approved or overrode it.
AI Workspace can help with that!