I was an AI sceptic (and I’ve got the old blog posts to prove it)

There’s a certain type of blog post going around at the moment, the one where a tester explains how AI won them over. I’m about to write one, too (so do bear with me) but I think I’ve got something most of them don’t have; I wrote my scepticism down at the time.

Back in 2023 I ran a set of experiments with generative AI and testing, published the fairly lukewarm results and moved on… which means I can go back now and answer the version of me who came away unconvinced. This post pulls those early pieces together and replaces them and really it’s a letter to any tester still standing where I was.

Here’s what I got wrong, back then I kept bumping into garbage in, garbage out where I asked the AI a lazy question and got a bad (AI slop) answer back which gave me reasons to be sceptical. It’s taken me a long time to see it the other way round, that garbage in, garbage out is actually a good outcome for testers; that if the quality of what comes out depends on the quality of what you put in and if putting good thinking into messy problems is literally the job of a tester… then these tools don’t threaten us, they help us to use our innate skills and show our value.

What sceptical Callum actually found

Since I’m retiring my original posts I want to keep their findings rather than lose them, so here’s what 2023 me concluded about using AI & LLMs.

I asked whether AI could write a good test approach. I gave it a proper brief, integration between a web front end and a database over REST APIs, an agile team with an embedded tester, Jest for unit tests and Cypress for the API layer. What came back was tidy and decent on the basics, the roles and responsibilities, a “test champion” to advocate for exploratory testing and it sensibly wove automation in to support exploration. But it gave me an average of everything ever written about test strategy online, defaulting almost entirely to end to end automation (saying nothing about unit or integration testing closer to the code) and gave me no real view of shift right or exploration. To get anything more complex and detailed I had to write the approach myself and let it tidy up the words I’d given it.

I asked could AI write good exploratory tests. As a starting point it was okay, a bit like testing flashcards or the basics from a risk storming session; the format of “give me some exploratory test ideas for the risk that…” was a handy thing to put in front of people during a bug bash for them to use. The test ideas were shallow though, focusing on breadth rather than depth, giving risks like data integrity, authorisation, performance and localisation but with no depth. It could tell me to look at things but not give any rationale as to why it mattered or any specificity, for example it’d say localisation but nothing about character sets or regional data standards.

Next was whether it could teach me technical concepts and this was the one that was the best, where even sceptical me came away impressed. I used it to teach me about APIs and it walked me from “what is an API” through the request types and through to how you’d send data with a POST, in clear human understandable language. The bit that I should have paid attention to was what happened when I sharpened how I asked questions; a vague ask gave me a generic answer but naming Postman got me tool specific steps and then asking for an example payload on top got me steps and a worked JSON body. Now we’re cooking with gas, I wrote at the time, completely missing that I’d just discovered the entire trick to AI prompting (that you have to use bigger prompts and be really specific on what you want). I did at least note the danger, when a tool hands you one confident answer and you can’t see the sources behind it so you have to treat what it says with healthy scepticism.

I also wrote a follow up on the risks I’d found about garbage in, garbage out prompting, half braced for the AI to go full HAL 9000 on me, calmly assuring me everything was fine while quietly doing its own wrong thing. Those risks were real and I’ll come back to them properly, but in short they were about maintainability, consistency and a worry that we’d start prizing people who could write a prompt over people who understood engineering.

My verdict at the time was that using AI was handy for a first draft, it’s shallow without a lot of steering, good for teaching basic well known concepts and a bit risky. Every one of those observations was true, but my mistake was the conclusion I came to from that.

Responding to my old scepticism

I’ve done a lot of learning since I wrote those old posts in 2024 so I want to use this as a way to respond to the objections that I’d raised about AI in the past, because each one has an answer now. This is important because I hope it’ll help other AI sceptics in the testing and software delivery space to go on their journey too.

“It only gives me the average of what’s on the internet, not a considered response“. It did that because I didn’t give it anything else to work from, AI needs to be given more context in order to give a better answer that isn’t just thin and generic. Once you feed it your acceptance criteria, your risks, your guidelines / standards and an example of what good looks like then it stops giving you the average and starts giving you something useful. The thing that I’d missed is: AI wants to please you (it’s a people pleaser) so it won’t push back, critique or point out problems on its own… you have to explicitly tell it to do that.

So my AI prompts now include something like:

I pair the prompt for critique with an instruction to own up when it doesn’t know what to do by asking it to flag when it hasn’t got enough context to act, give a confidence rating from 1 to 10 with a rule that if it drops below 6 it stops and asks me. That stops it quietly making things up and hallucinating when it doesn’t actually know.

On anything big I also get AI to prove it’s actually understood me before it builds anything by having independent agents each summarise the spec and what they think it’s asking for. Then getting a fresh agent to compare those summaries and score how aligned they are, flagging any drift it spots, so I catch problems in uncertainty before anything gets built.

“Its exploratory ideas are shallow and it never says why something’s risky“. That was because I’d given it lazy one line prompts asking for tests. If you give the AI a proper structure for forming exploratory test charters and some trusted heuristics for risk identification then it can go a lot deeper. If you want to read more about how I do this then read my post on exploratory testing with AI.

“It ignores the code and focuses on end to end testing.” Again, this was because I’d never pointed the AI at the code or the testing and engineering standards for types of test I wanted. If you define what good testing looks like and point the AI to that alongside the code repo, then a prompt as simple as “review this code against our unit and integration testing standards and tell me where coverage is missing with fixes” gets it writing the cheaper tests closer to the code (instead of building another costly end to end suite).

“It’ll make us value prompt writers over people with real skills“. This was my biggest worry and it’s the one I’d most want to reassure myself about. Writing a genuinely good AI prompt (or building things with AI) uses so many good testing skills like knowing what to ask, what could go wrong, what to assert on, what heuristics matter and how to define if something is good enough. You won’t be outsourcing or losing your testing skills, even if you end up baking some of them into automated prompts, AI enabled engineering organisations need the exact skills a good tester already has.

“It’ll cause problems, refactoring code a lot will cause regressions“. This risk still stands but it’s not specifically an AI issue, it’s a foundational issue with engineering and a potentially optimistic view of developing at pace. Any refactors teams make can potentially break things, that’s not new to AI, we also know that teams are bad at thinking about testing for looking for regressions so tend to miss this. What’s new is the speed and how customer testing / manual testing at the new pace of change won’t keep up with the new potential rate of failure with faster drift leading to faster AI slop. But we can use AI to retrofit E2E tests to make sure behaviour stays static or add AI skills to report on maintainability and other core code quality areas to give ourselves a safety net that works at pace.

The risks I raised and where they actually stand now

The biggest risk I’d raised was that generative AI builds from everyone else’s code and habits scraped off the internet. The thin answers you see from a basic prompt come from that, a model reaching for the average of everything online in order to people please and give you some kind of a response (rather than a nuanced one based on your actual context). On top of that you then inherit styles and quirks you didn’t choose yourself, which is how you end up with bad results and AI slop.

That risk gets bigger when we want to go faster, or when we fall prey to the idea that AI is a genius that always gives you the right answer (a lot of AI psychosis comes from it people pleasing and confirming your own biases). When we forget to check what it’s given us that’s when we get inconsistent coding patterns, behaviour refactored out from under us, tests rewritten to do the wrong thing and all the anti patterns of code on the internet. I see this constantly with my AI usage… the number of times I’ve had to ask “what does this test actually assert on” and fix for it is wildly high, I’ve also had to keep reprompting to say ASSERT THAT SAVED DATA PERSISTS ACROSS A SAVE VIA THE UI AND API!

None of that is really the AI’s fault specifically, it’s the tool exposing engineering that was already foundationally weak (something that DORA’s research keeps finding), AI is an amplifier that magnifies the strengths and weaknesses a team already has. We need to help teams to fix their quality foundations to get them to a better result consistently.

So yes, the risk is real but it’s not a reason to avoid using AI… it’s a reason to bring quality thinking into how we use and prompt it. Just like when we build features we need to build our prompts using quality engineering thinking to steer AI into the right thing:

• Build certainty by asking for everything up front, the more complete the prompt the less AI has to guess at and get wrong.
• Don’t assume the output is good, prompt for quality signals and review what comes back.
• Be critical of what it’s built, get it to test the risks so you learn about the quality rather than trusting it.
• Give it your heuristics and best practices to check its own work against, so “good” means your good and not its people pleasing average.
• Prompt in small steps so the feedback loop stays short, rather than one big ask you can’t unpick or understand.

So if you don’t want thin answers, want to meet better standards or are worried about the risk that AI will create slop, derisk it by prompting in a way that tells AI exactly what you want. Don’t do what I’ve seen a lot from people when I’m teaching them to use AI and ASSUME AI KNOWS WHAT YOU WANT, AI isn’t some kind of genius that’ll fill in the gaps and build what was intended from a light one line ask. It’s a dumb number generator that needs telling and properly redirecting to the right answer.

The real risk is in how people think about and talk to AI rather than the tool itself… it’s classic garbage in, garbage out!

We’ve been here before

I’m going to be honest, originally I’d come in to looking at AI with a really thin assumption, a confirmation bias that I wanted to prove out: that AI was bad at testing and that it wouldn’t replace me.

I don’t think I’m alone with this, you’ll have seen so many posts and messages saying “AI will never replace manual testing” or “you can’t automate a human tester’s intuition”. Many people are defaulting to “AI can’t fully replicate my judgement so I won’t engage with it at all” rather than looking at what rules we can teach AI to get it part of the way there. It’s a similar pushback we saw from the testing community to dismiss automation testing, something that partially came from a place of imposter syndrome and worrying about not being technical enough or being replaced. The real blocker here isn’t the ability to teach AI to test and use human intuition, it’s far more likely to be (something I felt too, so I know it) feeling like we’re handing our skills away and making ourselves replaceable.

But as I spoke about in You’re Not Ready for QE, our teams want to work with people who adopt new tooling, build things and help them to ship faster. That includes AI too, they’re going to want quality professionals (just like they wanted automation engineers and SDETS) who can help bake their knowledge and intuition into their delivery pipelines. The intuition and testing skills you’re trying to protect is the exact thing that makes you good at steering AI into doing the right things for teams, so it makes sense to apply it where it’s wanted!

If you’re still the sceptic

So if you’re stood where I was after a quick go with AI (thoroughly underwhelmed and thinking about the risks) here’s what I’d say to you; your instincts aren’t wrong, the shallow output is real and so are the risks of AI slop. But maybe you’ve drawn the same conclusions that I did, that this is a tools problem and not worth engaging. Why not push further by trying to give AI the context that you’d give a new starter, tell it what good looks like, let it know that it’s okay to disagree with you and to own up and say when it isn’t sure about something. Then review what comes back the way you’d review a junior’s work, giving guidance where needed for what would be better and keeping the good bits so that you can run them again. You’ll find that AI tends to meet you at whatever level of thinking you bring to it.

And if you’re worried that using AI will rust your skills out or replace you, remember that context changes all the time and you’ll be using your skills to improve the guardrails and test the difficult things. Just like how automated testing didn’t kill the need for manual and exploratory testing… it (supposedly) just freed up our time to do more of it. That’s how I’m seeing using AI, as a tool that I can use to enhance the testing I do and get it into a pipeline where it matters (for speed) but still has to rely on my knowledge for what matters.

Thanks for reading. If this resonated (or if you think that I’ve got it wrong) there’s more to read on the blog… or get in touch via LinkedIn. I’ll talk quality to anyone who wants to listen!