Robin Miklinski Independent AI & software engineer · London

I ensure AI products are ready to release.

At Reward Gateway, I led release assurance for the company’s first customer-facing AI product — evaluation, adversarial testing and the evidence a go/no-go panel could act on.

Output is abundant. Confidence is not.

Models can produce code, analysis and plausible answers. The difficult work is deciding whether an output is correct, whether the system has enough context, what it is permitted to do and who remains accountable when it fails. That is the layer I engineer.

01 / About

Robin Miklinski

I took responsibility for quality and release assurance on the first customer-facing AI product at Reward Gateway, the employee-benefits platform Edenred acquired for £1.15bn. The application had already been built. The evaluation infrastructure had not. It was a retrieval-based assistant built on AWS Bedrock with OpenSearch, serving many enterprise customers from one system. It shipped natively on iOS and Android as well as the web, and I owned release assurance across all three surfaces. A failure of isolation was not a bug in one account but a disclosure across several. There was no defensible basis for deciding whether it was ready to launch.

Because the model’s wording varied between runs, conventional exact-output checks were insufficient. The same prompt can return three different answers and all of them be acceptable. I replaced pass/fail equality with semantic assertions, classifier-based validation and sampling across repeated runs, so the suite could judge whether a response completed the task and stayed inside the system’s rules. The adversarial half covered direct and indirect prompt injection, jailbreaks, tenant data isolation, personal data leakage, authentication flows and retrieval scope.

The suite ran to 180 tests across unit, integration, API and functional layers: forty-four on security, thirteen on tenant isolation alone, and a set of benchmark answers reviewed by subject-matter experts to judge whether the assistant was actually right.

The suite made the limits of the launch evidence visible. Without a labelled dataset, answer accuracy could not be measured at scale. Response times had no agreed service level, and the pipeline handling updated and deleted content remained untested. I turned each gap into an explicit residual risk for the go/no-go panel to assess. The product launched with a clear account of what was known, what remained uncertain and where further investment would produce better evidence.

The same approach applied to continuous evaluation. Every run queried the model and carried a usage cost, so test frequency was a commercial decision as well as an engineering one. I quantified the cost and made the trade-off visible to the people responsible for it. That is part of release assurance too: not pretending a control exists when the organisation has not yet chosen to fund it.

The suite became the release gate for later AI work and set the platform’s wider AI testing approach: AI-assisted test generation, and risk-based test selection driven by what a code change touched.

Background

Before the AI work I built Reward Gateway’s quality function from nothing: fifteen engineers across London and Sofia, supporting more than two hundred people in product and engineering. I designed its quality career framework so senior engineers could progress, and built the automation and measurement platform underneath it. That platform held a 0.02% flake rate across roughly a thousand end-to-end tests, against an industry norm of five to fifteen per cent. The infrastructure helped support the platform’s scale and release cadence in the years before Edenred acquired the company for £1.15bn.

I began in defence and intelligence data systems at BAE Systems Detica, Steria Defence UK and Fujitsu Services, where a change had to be traced to its reason and a boundary had to hold against an assumed attacker. Since then: peak trading performance testing at 15,000 concurrent users at ASOS, security scanning moved into the delivery pipeline at Huddle in 2015, and the test framework behind a billing system launch and a first international customer at Perkbox.

My work spans Python, JavaScript, TypeScript and C#, from product implementation to the evidence needed for sound release decisions. That range matters when a system can fail in ways that are fluent, plausible and wrong.

BSc (Hons) Internet Engineering, University of Exeter. ISTQB Foundation Certificate in Software Testing. I spoke at BrowserStack World Tour 2024 on observable test automation at scale.

Outside work

I DJ and produce electronic music as Eidetic. Self-taught since 2007, resident at EGG London in 2017 and 2018, and a radio show, Late Night Relics on AAJA Radio.

02 / Highlights

Selected highlights.

Three records, each labelled by what backs it. The complete register lists the rest under the same labels.

YR2L, We Can Help You Limited 2025–2026

24,000 applications rescored in production

I took over a Dart, Flutter and Firebase product from its original solo developer, working from a codebase with almost no documentation. Across two paid engagements I integrated a third-party planning-data API, restored a failed council dataset, rebuilt the scoring system and re-scored more than 24,000 planning applications in production. I then stabilised the handover and onboarded the external development team that took the product forward.

Reward Gateway 2025

The £227,000 hidden in 451 incidents

I analysed 451 production incidents across ninety days and classified each by cause and by whether testing could have prevented it. Sixty-one per cent could have been caught. Only one had test evidence attached, and root cause was recorded on fewer than one in twenty. The analysis turned a vague concern about quality into a measurable business case and put a £227,000 annual figure on preventable failure.

Agent infrastructure 2026

Agents work. Authority stays human.

I run my own working environment on agents under one rule: they can research, draft and build freely, but sending, spending, shipping and publishing require my approval. Reads are autonomous. Writes are confirmed. State lives in plain files, so decisions remain inspectable without the tool that made them. It is a working implementation of the boundaries I design for other AI systems.

Open the complete evidence register →

03 / What I do

My work centres on AI release assurance: evaluation, safety testing and the evidence needed to decide whether an AI system is ready to ship. AI products rarely fail at the model boundary alone. They fail because context is incomplete, permissions are too broad, outputs cannot be explained or a release decision rests on a convincing demonstration rather than repeatable evidence. The same discipline applies when a business adopts AI rather than building the underlying product.

  1. 01 Build dependable AI systems

    • evaluation
    • permissions
    • tenant isolation
    • failure behaviour
    • human control
    • escalation
    • agents
    • retrieval
    I design and build AI-enabled software with the controls in place from the start. The model is one component in a complete product. You get a system whose limits are written down before anyone has to discover them.
  2. 02 Evaluate and harden existing products

    • acceptance criteria
    • repeatable evaluations
    • adversarial tests
    • model and prompt change management
    • release evidence
    I turn broad expectations into measurable criteria. The result shows what the system can do, where it breaks and what remains uncertain, in a form a board or a customer’s risk team can act on.
  3. 03 Find where confidence breaks down

    • observability
    • security
    • cost
    • latency
    • accuracy against autonomy
    I investigate failures across models, prompts, tools, data and the software around them. That includes the commercial questions: what it costs to run at the cadence you need, and how much autonomy its accuracy supports. You get a named cause, not a list of suspects.
  4. 04 Make AI earn its place

    • workflow mapping
    • tool selection
    • fixed-fee discovery
    • safety checks
    • handover
    Not every business needs to build an AI product. Most need to know where AI will save meaningful time, where it will create new risk and which work should remain human. I map how the work gets done, identify the uses with genuine value, and choose or build workflows with controls proportionate to what they can affect. Fifteen years of finding out how software fails goes into deciding what to automate and what to leave alone. Discovery is fixed fee, so the cost and the plan are known before anything gets built.
04 / Contact

Tell me what the system must do, and what must never happen.