AI Systems That Generate Execute Heal Learn and Govern Quality [Testμ 2026]

The Five Verbs At A Glance

Generate, execute, heal, learn and govern are the spine of the deck. Each is presented as an agent and as an orchestration, and his claim is that any one of them improves a daily task while the five wired together turn autonomous quality engineering into a loop that improves over time.

His payoff line for the whole arrangement is that making it one autonomous unit can create miracles for your workflow. No case study, metric or before-and-after accompanies it.

The Confidence Gap

He lists what the industry already spent its effort on, smaller changes, more automation, more parallel execution, and then rejects the question those efforts answer. Asking whether we can run more tests is not going to solve the problem of delivering faster.

His reframing is that shipping speed is no longer the constraint. Teams can ship code faster; building the confidence is the problem being faced right now.

The supporting observation, that delivery speed rose several-fold after AI arrived, is an impression with no figure, source or baseline behind it.

He qualifies the ambition immediately. Wanting an intelligent system does not mean everything gets built with AI, and he positions the talk as carrying pre-AI quality engineering thinking forward rather than replacing it.

He returns to the point at the close: autonomy comes from the loop, not from one chatbot you built.

Three Inputs To The Coordinator

One input is the smallest artifact in the workflow, a commit or pull request a developer pushes, against which someone writes a functional or integration test.

Another is the release delta, and he flags that the vocabulary itself has shifted. Teams used to talk about a release regression against a build; now the conversation is about the commit and the delta between the last release and this one.

Production pain plus telemetry supplies the last one, meaning defects and incidents including P0 and P1 severities, alongside the observability signal. He calls it an extreme of shift-right testing, where a lot of metrics arrive daily as signal.

The coordinator consuming all three is a slide he narrates as a list: understand the change, plan the tests, coordinate execution, verify outcomes, triage failures, self-heal, then feed quality memory and produce a decision with an explanation.

His caveat on the very first stage is the honest one. Asked whether AI can understand what changed, he answers yes absolutely, then asks whether it can do so with the accuracy and precision of a human and answers not really.

Generate As A Pipeline

Two years ago, in his account, everybody started at prompt in, test out, with no prompt engineering and no governance in place. What changed since is tooling, and specifically Model Context Protocol servers and the coordination they allow, so the same end-user workflow can be handed to an agent with more capability behind it.

The slide headline is that good test generation is a pipeline rather than a prompt. He stumbles reading it aloud, so it is reported here as a slide line.

The draft stage takes everything available: designs and schematics, Figma, Confluence or Jira, requirements and user stories, and the code changes themselves, on the reasoning that code and tests now get written in parallel.

The grounding stage brings project context through a retrieval pipeline over a vector store, which he says increases accuracy a lot. No accuracy figure is given for either side of that comparison.

The iterate stage assumes the first generation is not the artifact you wanted, and his standard for what survives is the phrase he returns to all session: keep only the tests that earn that place.

Trust But Verify

His analogy is a junior engineer joining the team. Quality engineering already knows how to handle that, by trusting and verifying, and he wants the same hat worn for AI-generated scripts.

The prohibition attached to it is explicit. You cannot blindly trust the output, you have to validate and verify, and that is where the human in the loop comes in. He repeats the junior-engineer frame later in the governance section and says so as he does it.

Hallucination is treated as a live constraint rather than a footnote. A model can hallucinate, and the response you get is only as good as the prompt you give it.

Passing a coding-standards review is not sufficient in his framing. Generated code can follow repository conventions and reuse existing functions and still not be the artifact you actually wanted.

Then comes the gate a generated test has to clear before joining the suite. Run it in a lower environment and confirm it passes consistently over a period rather than once. Check that it matches the intent and is genuinely asserting something. Use mutation testing to prove it catches an introduced bug rather than staying green regardless. Stabilise it, and give it a human owner.

What the gate lacks is any number. There is no pass rate, no flake threshold, no definition of consistently and no mutation score. It is qualitative end to end.

The Suite As A Portfolio

His volume trap is a hypothetical he builds on the spot. AI generates 100 tests in a day, a 500-test suite becomes 600, and regression coverage improves by some percentage he guesses at aloud. Those figures are invented for illustration and are not measurements of anything.

His response to the trap is that the added tests mean nothing until somebody goes through and executes them. The sentence comes out as a double negative in the recording; the sense is unambiguous.

The model he is rejecting is the one most teams still run. Take a suite of 500 or 600 tests, run all of it, publish the list of failures, tell people to validate manually, call it done.

His team does targeted or risk-based regression instead, which is the only first-person practice claim in the main talk. The stated motivation is resources, compute and token economics.

The mechanism he describes for a weekly release cycle is to hand all the commits to a model along with the existing test cases, and have it produce a regression plan naming which subset the changed files warrant. He illustrates with 200 out of 500, another figure invented for the example.

The safety valve carries a negation worth preserving. He is not saying the other 500 tests are useless. He wants a golden set that runs regardless of whatever the targeted or risk-based selection produces.

Stop Retrying Until Green

The habit he names is treating a flaky test as something to retry until it goes green, driven by wanting regression results by the morning.

His objection is economic as much as epistemic, framed around the compute power being wasted on reruns.

The replacement is to let a failure fail, then use a model to classify what kind of failure it is and how to make it better.

He defers the mechanism to the self-healing section, and the classification method is never specified anywhere in the session. No classifier, taxonomy, accuracy figure or tool is named, and no sample classification output appeared on screen.

The part a team can act on immediately is separable from any of that. Switching off automatic reruns is a policy change that costs nothing to try and needs no AI capability at all.

Heal: Four Levels

The repair he wants is the smallest thing that restores the intended signal, rather than whatever turns the pipeline green.

His account of why trust fell is specific about direction. Trust used to come from what quality engineering certified; the signal has moved to AI, quality engineers and AI now overlap, and trust has come down as a result.

He backs that with an unspecified escape claim: P0 and P1 incidents that more diligent testing without AI could have caught. No company, product, date or count is attached, so it is reported here as an unspecified claim.

The healing tiers come off a slide. Locators and waits are the safe self-heal tier. Test data and environment, including generated synthetic data, is the tier he labels L2 out loud. Test code itself sits above that, and product code, which he labels L4, requires a human review. The level-one and level-three numbering in the published chapters is the metadata’s, not his.

The prohibition at the test-code tier is the one to keep intact. Do not self-heal a test for the sake of self-healing; make sure it is not a real failure first.

And when business intent itself changes, his line is that you cannot rely on models to make the decision for you.

Runbooks And SKILL.md

His requirement for anyone running self-healing is that every decision the AI makes gets authored into runbooks.

The workflow he describes is a morning read of that runbook, showing which test changed, what failed, why it failed, and why the fix was made or the heal was needed.

He frames each self-healing change as an experiment. A model can detect, diagnose and propose; the quality engineer’s job is having a system, whether runbooks or SKILL.md files, that records every decision it makes.

The loop closes on the agent rather than the test. If the logged decisions do not match your expectations, that is the signal to modify or fine-tune the agent.

He checks the clock aloud partway through this section, which is where the self-healing detail visibly compresses. That is the likely reason the level model stays thinner than the rest of the deck.

Quality Memory

The definition is the most original idea in the talk, and he claims the coinage. Quality memory is not a model checkpoint; it is the memory an organisation creates.

The inputs come off a slide: requirements, intent, tests, changes, commits, test results, service changes, defects, incidents and observability telemetry.

The obligation he attaches is that each result, repair, incident or bug should make the next decision better, so the next regression cycle beats the previous one.

His argument for why the concept is needed at all is the clearest version of it. When a person joins a team, they consume the requirements, the bugs and the history and it becomes their memory. Quality memory is his answer to how an agent does the same.

Directionally he wants production feeding back into pre-release, so production improves the next round of testing every time. The slide chain that follows this point is heavily garbled in the captions and is paraphrased rather than quoted.

No storage design, schema, retention policy, retrieval method or tool is given for quality memory anywhere in the session.

Govern

He pre-empts the obvious objection, saying governance is not a set of rules placed there to make your life more difficult.

The scope he asks for is total: identity, policy, evaluation, audit and rollback around every action the system takes on your behalf.

His cost argument is deferred rather than immediate. Skipping governance is survivable now, but as the AI systems grow over months and years it gets messier, and doing it badly costs a lot more than doing it right.

The consequence he names is a job nobody asked for. Quality engineers now do their own testing and test the AI at the same time, and whether you like it or not you are indirectly testing an AI agent even though it is not in your job description.

The AI quality dimensions he reads off the slide are groundedness, robustness, non-determinism, security and safety, and privacy, plus latency, cost and operational drift.

On token economics he separates spend from value: everybody has been talking about it recently, and it does not mean you are producing enough quality. The timing of that trend is his impression, undated and unsourced.

Maturity And Measurement

The honesty line arrives before the measurement advice. Even his own team is not 100% at the point where he can arrive in the morning, read the runbooks and SKILL.md file, and declare everything went perfectly. They are not there yet.

The stages he names are assisted, orchestrated, guarded autonomy and autonomy. His numbering contradicts itself inside thirty seconds, placing his team at level three and also describing level three as the point where you are really talking about autonomy, so no numbered ladder is reproduced here.

His read of the audience is hedged and offered as impression rather than survey: most people have probably crossed the assisted stage and many have crossed orchestrated too.

His reassurance on jobs is unambiguous even where the recording is not. Human in the loop is not going away and quality engineering jobs are not being taken, though the way the work gets done has to change.

He contrasts that with a culture he says has already passed, where using a lot of tokens made you a star in the team a year ago and no longer does.

The measurement areas as spoken are flow, quality effectiveness, trust and control, and economics. He announces four and names five or six terms; the published chapter list picks a tidy four, which is the metadata’s selection rather than his.

Q & A Session

Roughly ten minutes went to audience questions relayed by the host. Two questioners were named on air; both names are garbled in the captions and are withheld here.

• What practical AI security checks should exist in every CI/CD pipeline?

  Jyotheeswara Reddy Gottam: Retail, healthcare and insurance each face different problem sets. In my own domain that means PCI masking, so no raw payment data reaches a model, alongside compliance-sensitive health data and heavy use of synthetic data. We do not put these checks in the CI/CD pipeline; we address them in the agents themselves, because the risk sits at the point of generating artifacts rather than at the point of running tests. He narrows the scope before answering, then rejects the question’s framing. The published chapter title frames the opposite of what he concluded. He names no specific check, tool or gate.

• How should agents learn from historical production incidents?

  Jyotheeswara Reddy Gottam: The observability data has existed for years in search indexes and caches, and the new capability is that a model can pull the signal out and take the noise away. Hand it two years of history and it will identify which functional areas produce the most bugs. My team applied predictive analytics over three years of production bug data broken down by functional area and team, out of an end-to-end testing role touching around 120 teams, and the output is not about pinpointing anyone. That team figure is self-stated with no source. No model, method, sample or accuracy figure is given.

• Which architectural safeguards stop a testing agent from hallucinating steps that contradict the product data you feed it?

  Jyotheeswara Reddy Gottam: I could talk for 45 minutes on this one. A model cannot grade its own output: ask it why a script is good and it will tell you why, ask why it is bad and it will tell you that too. The remedy is cross-model validation, generating with one model and handing the same requirements, schematics and designs plus the generated artifact to a different model to judge whether it is on par or hallucinated. Add structured memory through MCP servers, playbooks and SKILL.md logging of every fix, because a silently repaired test can leave a real bug undiscovered. He flags that upfront and then answers roughly half of the question. Temperature constraints and strict retrieval pipelines, both named in the question, go unaddressed.

• How do reinforcement learning loops distinguish genuine software regressions from environment-induced noise?

  Jyotheeswara Reddy Gottam: Teams are already doing reinforcement learning by getting data daily and training their own agents rather than the model. Reinforcement learning makes the work easier, but it does not deliver trust or confidence, which has to come from the systems you build in your own environment. He describes no mechanism, so this is a non-answer to the question asked, and the reframing argues against the question’s premise instead. The passage is negation-heavy and breaks off mid-sentence. The published chapter title presents it as an answer.

This session was part of Testμ Conf 2026, which ran across three days of sessions on agentic engineering and quality. Registrations for the next edition are already open on the Testμ Conference 2027 page.