We make mission-critical software for unmanned systems, used in maritime search and rescue and in defence. Operators depend on it under pressure, often at the edge of a link. When it is wrong, it is wrong in front of someone who needed it to be right.

We also move quickly, and AI tooling is deeply embedded in how our engineers work. That combination is the problem this role exists to solve: verification has to scale at the same rate as delivery, and it cannot scale by adding reviewers. It has to be engineered, and most of that engineering has not been done yet, here or anywhere else.

So this is not a role with a playbook. We are less interested in how many years of a particular tool you have than in how you think about problems like this one and how you go about solving them.

• Test the critical things by hand. Decide what must have human eyes on it (safety, mission-critical paths, first-of-a-kind flows) and test it well, including exploratory testing nobody scripted.

• Write scenario packs a persona-focused QA agent can run. Anchor each scenario in a real operator persona, make it specific enough for an agent to execute and recognisable enough for an operator to sign, and state what counts as evidence.

• Build and evolve QA agents. Design, instruct, give tools to, evaluate and retire the agents that do QA legwork: scenario runners, regression checkers, feedback triage. Keep them auditable.

• Build test generation pipelines, and make them check themselves. The core of the job. Pipelines that produce tests are easy; pipelines whose output you can trust are not. That means mutation testing that proves a suite detects real regressions, assertion analysis that fails a suite for looking green without proving anything, and tests derived from specification rather than from implementation.

• Engineer against correlated blind spots. AI-generated code and AI-generated tests can share the same blind spot and agree with each other about the wrong thing. Structure things so verification is genuinely independent, and prove the independence holds.

• Make the product mechanically verifiable. Build the testability, test environments, test data and harnesses that let a pipeline or an agent drive and assert against the application reliably, and hold a defensible line between what is worth driving through the UI and what belongs a layer below.

• Solve the oracle problem. Much of what we ship is not a return value. It is a rendered map, a decoded video frame, a telemetry overlay with a hard freshness budget, a screen coordinate converted to a position on the ground. Turning "an operator can see that it is right" into an assertion a machine can make is one of the more interesting problems here.

• Own the gates, and keep them honest. Decide what mechanically blocks a merge or a release, and revisit it as volume rises, because a gate that is easy to satisfy has stopped being a gate.

• Verify more than correctness. A series of individually correct changes can still walk a design somewhere expensive, and a review that only asks "is this change correct" will wave every one of them through. Noticing that class of problem is explicitly part of this job.

• Measure the process, not just the product. Rework rate, escaped defects, gate effectiveness, acceptance rate, how long the tenth similar feature takes compared with the first. Then change something because of what the numbers say.

• Evolve the quality process. Treat quality as a system the team runs, change it on evidence, and teach it, because in this new way of working quality is what keeps speed safe.

• Work with the people who use it. Run acceptance with operators and the people who own the outcome, and turn their feedback into scenarios and checks.

• Produce evidence an auditor accepts, where a programme or customer requires it.

• Enough C# to read, review and debug it confidently. You will not be writing production code from scratch, but you cannot design checks for code you cannot read.

• Having automated a real desktop UI, and dealt with what makes it hard: synchronisation, flakiness, automation trees, rendering, application state.

• Having built automated workflows or CI/CD, rather than only consuming someone else's.

• Day-to-day use of AI coding and agentic tools in real work, and some opinion about what they get wrong.

• Having built or configured an AI agent or LLM-driven workflow, and evaluated its output.

• Broadly 3+ years somewhere in QA, test engineering or software engineering.