Stuart Thomas
Head of Engineering
He / Him
I am Open to Speak, Write, Teach, Mentor, CV Reviews
Duck enthusiast, technology leader, and quality advocate focused on building high-autonomy teams and sustainable delivery.
Achievements
Certificates
Awarded for:
Achieving 5 or more Community Star badges
Activity
earned:
The forgotten part of quality: paying attention to production
earned:
1.2.0 of MoT Software Quality Engineering Certificate
earned:
ALL the humans making MoTaCon 2026 happen
earned:
ALL the humans making MoTaCon 2026 happen
earned:
ALL the humans making MoTaCon 2026 happen
Contributions
The lineup is out and oh my... how exciting is it?These are the contributors we've announced publicly... but let me tell you something. Every single person walking through the Brighton Dome doors b...
The policies, processes, and guardrails put in place to ensure that code, experiments, and tools produced across a team meet standards of safety, consistency, and reliability, especially as AI lowers the barrier to building.
The question is no longer about engineering capacity, but Governance. The teams that win will be those that create the safest “Playgrounds”. The teams that win won’t write the most code — they’ll create the safest environments for everyone to build in.
Short-lived, AI-generated code designed to be deleted after use, typically for running experiments such as A/B tests on a component or call-to-action, with Engineering providing guardrails through a component library and code review.
AI-generated code used for internal validation and testing core logic during the "can we even do this?" phase. It lives in a sandbox and never reaches production; if it works, the learnings are handed to Engineering to be rebuilt properly.
We are excited to welcome Stuart Thomas to the MoTaCon stage for his session Testing the untestable: building a strategy for testing AI.
This isn't a coding tutorial, it’s a strategic playbook for ...
Integrate monitoring, observability, and alerting into the core quality engineering process to ensure systems are as diagnosable as they are functional
At a practical level, dependency injection is a process that is possible thanks to design choices allowing a piece of code to have its dependencies—like database values or external APIs—"injected" into it from the outside, rather than creating or fetching them itself. This allows for tests to have a known state ahead of running without interacting with the whole system.The Quality Perspective:Dependency injection is about using the seams in the software to control state ahead of completing a test. It is an architectural prerequisite for building testable, resilient systems.When code is tightly coupled and can only create its own dependencies, testing becomes a multi-step process just to configure the scenario you want to test. Being forced to interact with the entire system at once leads to slow, brittle test suites that bottleneck the delivery pipeline. Dependency injection solves this by using intentional seams in the architecture to create the desired start state for the test.
Strategic Friction are the intentional bottlenecks we design into our process specifically where risk lives:
Architecture Guardrails: If AI can spin up a microservice in minutes, we need senior-led standards that ensure it doesn’t become a distributed nightmare.
Deep-Dive Peer Reviews: Shifting the focus from “Does this look right?” to “How does this break the system?”
Automated Risk Gates: Designing smarter CI/CD checks that trigger deeper scrutiny when AI-generated boilerplate touches critical paths like security or payments.
Loved recording the 404 talk for the SQEC Certification module on Monitorability, Observability, Testability. It was great to think about how these often forgotten areas of quality can be so impact...