Part 2 of 4: Rethinking the quality operating model for AI-native engineering

I’ve seen and heard about how this has been playing out in different organisations, with different tools and different teams.

A team adopts an AI testing tool and they claim to be doing the leg-work properly: they get it integrated, they point it at the right environments, and they get the reports coming through, so by any reasonable measure, it appears to be “working”. Code is being generated, people are starting to  move faster, tests are also being generated (so that ever-so-important “coverage” metric is increasing), and ultimately the pipeline is running.

And then, when you look a little closer, and you notice the team is still doing the same level of code reviewing and the same 3 hours of “manual regression testing” they’ve always done before every release… But not because the tool failed or because anyone told them to. It’s really because nobody was quite ready to bet a product release on something they hadn’t fully made their own minds up about yet.

The tools were set up and running, but nobody believed in it enough yet to invest in the change.

I do want to be careful with my words here though, because what I’m saying isn’t meant as a criticism of the teams in this position. This is a completely rational response to something new. But it is a problem I think most engineering leaders are misreading right now. They’re seeing low AI adoption and diagnosing it as a skills gap or a tooling gap, when what they’re actually looking at is a trust gap – trust in the company regarding stability, investments in people, and to be data driven in their decision making, and trust in the tools due to various mixed messaging and some “LLM snake oil” content already circling in the communities, etc. And trust gaps don’t close the way skill or tool gaps do.

What a trust gap actually looks like

The reason trust gaps are so easy to misdiagnose is that they wear the costume of other more familiar problems.

“The tool keeps generating tests that aren’t relevant” often means: I don’t trust its judgement yet, so I’m noticing every miss more than I’m noticing every catch…

“We need more training on it” sometimes means: I don’t feel safe relying on this yet, and more training feels like a safer ask than admitting that…

“It’s not quite right for our stack” occasionally means: I’m not ready to restructure my working day around something I haven’t fully bought into…

“We’re running it alongside the manual checks, just to be sure” is the clearest signal of all of a team carrying the overhead of AI adoption without any of the productivity benefit, because the trust required to actually change how they work hasn’t been built yet.

There’s an important distinction worth making here between healthy scepticism and trust-gap paralysis. Early caution is completely appropriate! When a team is new to a tool, a deeper level of analysis in trialling, testing and running it in parallel with existing checks while building confidence is totally sensible. The trust gap is what happens when that caution hardens into a permanent parallel workflow that has a really long tail in being retired. I.e. Three months in and the tool is still running alongside everything else, and nobody’s had the conversation about whether it’s time to let go of the “manual checks” for certain parts of the system.

That’s a real cost which isn’t being talked about enough. The promise of AI-native quality is in changing how you work, because the agents are handling things you used to handle manually. If the change-how-you-work part never happens, the tool is just an expensive add-on to the workflow rather than a transformation of it.

Why trust is harder to build than skill

Skills can be trained: You can run workshops, write documentation for people to read and understand, pair or ensemble with people, give them time and a safe space to practise, etc. There’s a reasonably predictable path from “doesn’t know how to do this” to “knows how to do this”.

Trust doesn’t work that way though. Yes, you can teach people about trust as a topic, but you can’t teach people how to build trust in the same way you can, say, teach them how to use a tool. With a tool, people can learn exactly how to use a tool skillfully, but still not trust it with something that matters on a Friday afternoon before a release. Skills and trust are different things, and leaders who conflate them end up trying to run sessions in an attempt to improve adoption, but ultimately don’t move the needle.

Trust in AI tools can only really be built through accumulated evidence, not through demos or documentation. With testing and quality tools, every time the tool catches something real, a risk or problem related to something that the team cares about, trust increases a little. Every time it misses something the team expected it to catch, trust takes a hit. And there’s a level of asymmetry that makes this really hard: the loss of trust from a miss is disproportionately larger than the gain of trust from a catch. One high-profile failure by the AI tool gets remembered and retold for months. Twenty quiet catches barely register.
Coupled with this is another added challenge – the variability in the input to the AI tool (the context supplied, the instructions, the guardrails, etc) impacts that miss/catch outcome. Some people talk about “shit in, shit out”, but it’s actually way more nuanced – even what seems like a reasonable prompt might be missing some important context, throwing the output and outcome off in a way that is frustrating.

This all means that the conditions under which trust gets built matter enormously. Teams in high-pressure environments, where a missed incident means an on-call page and a postmortem, will default under pressure to whatever they trust most. Which is usually whatever they’ve been doing the longest. If the stakes are always high, the window for building trust in something new stays permanently narrow.

That’s a leadership problem too… It’s not a tooling problem. The conditions that allow people to take the small risk of trusting something new have to be created deliberately. They don’t emerge on their own in a team that’s already running fast.

The specific trust challenge with AI testing tools

Most tools earn trust through transparency: A CI pipeline either runs green or it doesn’t. A linter flags a line or it doesn’t. The reasoning is visible and legible, and that legibility is a significant part of what makes those tools trustworthy.

AI testing agents have a different relationship with transparency, and it’s one that the best tools in this space are having to work hard to address.

When an AI agent explores your application, generates a set of tests or charters, investigates or executes them, and then produces a report, the natural questions a tester asks are: why those tests? What did it decide not to test, and why? How did it decide what to cover? If those questions don’t have legible answers, the trust barrier stays closed, not because the tool is untrustworthy, but because the team has no basis on which to form a view either way.

BearQ is the clearest example I’ve seen of a tool that’s taken this seriously. Its design choices have become genuinely and intentionally relevant to the trust conversation. Plain-English detailed descriptions mean a tester or engineer can read a generated test and evaluate whether it reflects good judgement about the application. Recordings of agent activity mean the team can see what was explored, not just what got reported. Structured failure reports with screenshots give enough context to make a real assessment of whether a finding is worth acting on.

Although these look like nice UX aspects of the product, it’s actually trust infrastructure. A tool that shows its workings earns trust faster than a tool that asks you to take its word for it, regardless of how good its underlying results are.


Alt-text: Screenshot of BearQ’s transparent activity log and screen recording

The culture shift that leaders actually need to drive

Here’s the part where I want to be direct about what doesn’t work, because I’ve seen well-intentioned leaders try most of these.

Telling teams to trust the tool or the new process doesn’t work. Trust can’t be built through instruction. (It feels odd even needing to write this, but I have seen and heard execs say this to their teams).

Mandating a new process before anyone’s ready doesn’t really work either. It creates compliance theatre, people remove the “official” process and add it back in “unofficially” somewhere else.

And treating low AI tool usage as a performance issue is probably the fastest way to ensure the tool never gets a fair chance, because the team’s energy goes into defending themselves rather than exploring whether the tool is actually good and valuable.

What does work is slightly slower but is much more durable:

Start with low-stakes, high-visibility wins. Run the AI tool on the most stable, best-understood part of the system first, the part where the team already knows what good looks like. That gives them a real basis for evaluating the tool’s judgement against their own, without any pressure riding on the outcome.

Make the tool’s evidence visible and discussable. Not just in a dashboard somewhere on the side, but directly in the conversations the team is already having. In retros, in sprint reviews, in standups. E.g. “Here’s what BearQ found this week. Here’s what it missed. Here’s what we think about its coverage of this module. Here’s some improvement ideas regarding context we can feed in.”… Normalising the evaluation conversation and treating the tool’s output as something worth discussing critically (rather than either accepting or rejecting wholesale), helps to build trust fast.

Retire the parallel process deliberately, as a team decision. And this doesn’t mean directive – more as a conversation. “We’ve seen BearQ catch X, Y, and Z across the last 3 releases. Are we ready to retire the regression tests being run manually for this module?” That kind of framing treats trust as something the team grows together through data points, and not something leadership imposes from above.

And leaders need to go first. If the Engineering Manager or VP is still asking for a manual sign-off “just to be sure” before every release, the team reads that signal loud and clearly. Trust cascades downward, and so does distrust. The leader’s own willingness to work towards assessing and growing trust in the tool’s output, visibly and in contexts that matter, is a top trust-building mechanism. Definitely more powerful than any training programme or adoption metric.

What BearQ’s broader design tells us about building trust at scale

There’s a broader principle worth naming here, because it applies beyond BearQ to any AI tool a team is being asked to adopt.

The AI tools that earn trust fastest aren’t necessarily the ones that are right most often. They’re the ones that are most legible about their workings and reasoning. A tool that’s right 95% of the time but opaque about how it got there will be trusted less, in practice, than a tool that’s right 90% of the time but shows its work clearly enough that the team can form their own views of its judgement.

BearQ’s agent-based architecture, where the QA Lead agent acts as a visible point of interaction with directable focus, and where the Explorer and Test agents produce outputs the team can actually read and evaluate, is a concrete example of a system designed with this principle in mind. The human-in-the-loop capabilities, including focus areas, guardrails, and work reviews, really enable teams to choose the level of autonomy they’re comfortable with. These things are all safety features, which in turn are trust features. They keep the team in the loop in a way that lets them build confidence incrementally rather than taking a leap of faith.

That spectrum is deliberately staged rather than binary: teams typically start in human-directed mode, where every proposed test needs sign-off before it’s added to the regression suite, then graduate specific areas of the application to autonomous execution as trust builds – often module by module, not all at once. It’s a small structural choice, but it means the tool’s autonomy expands at the same pace as the team’s confidence in it, rather than asking either party to get ahead of the other.

There’s also something worth naming in BearQ’s broader mission that connects directly to this trust conversation. SmartBear describes its core purpose for customers as building “application integrity”, which they define as continuous, measurable assurance that software works as intended, with the governance needed to operate at AI speed and scale. That framing matters for BearQ because integrity, as a concept, is inseparable from trust. You don’t trust a system because it told you it was reliable. You trust it because it consistently demonstrates reliability in ways you can observe and verify over time. That’s exactly what the human-in-the-loop architecture is designed to produce: not a one-time pass/fail result, but an accumulating body of visible evidence that the application is behaving as it should. 

This design choice is something I think matters most for teams and leaders who are trying to answer the question: “how do we get our people to actually trust this?”

Closing: trust is the work

The teams making real progress with AI-native quality right now aren’t uniformly the ones with the best tools or the most technically sophisticated testers. The common thread I see is something more specific: trust between people and their AI systems has been deliberately built, deliberately maintained, and deliberately grown over time.

Skills gaps close quickly with the right support, but trust gaps close more slowly, and only through accumulated evidence, visible reasoning, and leaders who are willing to be the first ones to actually change how they work themselves.

If this is a challenge you’re wrestling with right now with AI testing tools, it’s worth knowing that you can now start a BearQ 7-day free trial for yourself. Which means the conversation about whether your team would trust an agentic QA system is no longer hypothetical. You can find out directly through the BearQ free trial – here’s a link.

The next piece in this series tackles something harder still… Trust between a team and an AI tool is one challenge, but the shift that leaders need to make in how they think about quality strategy entirely, is a biggie – and this is a topic I’ve not heard anyone talk about yet. 👀

This article is part of a sponsored series with SmartBear, who gave me early access to BearQ and let me write about my thoughts on the subject of AI in testing and quality.