Designing Quality Frameworks for AI-Generated Code [Testμ 2026]

Confidently Wrong Code

She opens with a confession about the session itself. Everything she is about to show was built with an AI coding agent, and about a third of it was wrong on the first pass.

The distinction she draws is the one the whole talk rests on. Not obviously wrong. Confidently wrong. It compiled, and it passed its own tests.

That figure is an anecdote about her own build rather than a study of defect rates, and she offers it as one. What she does with it is the useful part.

She is explicit that this is not a talk about AI writing bad code, and says it often writes better code than a tired engineer at six on a Thursday. The failure she is pointing at is in how we decide what to trust.

The Four-Line Function

The worked example is four lines long, which is what makes it uncomfortable.

The business rule was that the loyalty rate applies to the pre-tax subtotal, never to shipping or tax. What the function does is apply the rate to the order total and return whatever happens to be sitting in that field.

At merge time nothing is visibly wrong. The names are sensible, it returns a number, and the tests written alongside it pass.

Three weeks later a shipping fee is added to the order object and the discount silently starts applying to it. The defect was introduced at merge and surfaced by an unrelated change much later.

Her contrast is what makes the case. A junior engineer writing this by hand would have left a comment, a question or a TODO, and review would have caught it. The AI version reads exactly as confident as the correct version would.

The Unspoken Assumption

For most of her career, she says, quality engineering has run on something nobody had to state: the person writing the code understands what it is supposed to do.

That assumption is what holds up the familiar chain. Code written once, reviewed once, tests passed once, signed off at merge, trusted forever. It is why a single green checkmark has been sufficient evidence for twenty years.

She is not attacking the chain, and says she has built exactly it into governance frameworks for regulated clients. It was designed for a world where a human always sits behind the keyboard.

AI-generated code does not violate the mechanics of that chain. It violates the assumption underneath, which is far harder to notice, because every step still looks like it is working.

Three Ways Trust Breaks

• Fluent without understanding - she reviewed an agent-generated reconciliation script for a banking client that got every arithmetic operation right and used the wrong currency conversion rule. It passed every unit test, because the tests checked the arithmetic rather than the rule. Her summary: it passes every check that was a proxy for understanding, without understanding.
• No fixed author - in a traditional vendor code review you know whose judgement you are trusting, and that judgement is roughly stable week to week. With agents the underlying model gets updated, sometimes without anyone on the team being told which model is now writing the tests.
• Trust decays after the merge - quality engineering already knows environment drift from suites that stayed green for months. AI code has the same problem across a wider surface: a dependency, a schema change or a shift in real traffic changes behaviour without anyone being told the function changed.

The reframe she offers for the second one travels well beyond her own practice. A model swap is closer to a staffing change than a code change, and no team would skip re-onboarding a new vendor engineer just because they use the same laptop.

Her client examples are anonymised and unverifiable from the recording, so they are best read as illustrations of the pattern rather than as case data.

Borrowing Zero Trust

Rather than invent a framework she went to security, on a stated rule worth adopting: import a discipline that has already solved an adjacent problem.

Fifteen years ago network security ran on perimeter trust. Once you were inside the corporate network you were assumed safe. Zero trust replaced that with one sentence: never trust, always verify.

The question she carries across is the one quality engineering now has to answer. How do you keep verifying something whose trustworthiness keeps changing?

A Mirror, Not an Oracle

The first pillar replaces the working definition of verified that most teams use: it compiles, it links, it passes the tests generated alongside it.

She invokes the oracle problem from test design, where the correct answer has to be independent of the thing being checked.

The fix is not more tests but independence: write the assertion from the specification before you look at what the agent produced, exactly as you would write acceptance criteria before a human developer starts a ticket.

Her line for the alternative is the cleanest test of any AI verification setup. If the oracle was generated by the same model in the same breath as the code, you do not have a second opinion, you have another echo.

Blast Radius and Drift

The second pillar replaces giving every AI-authored change the same freedom regardless of what it touches, and its precedent is already familiar. Risk-based testing taught quality engineering that a marketing banner and an interest rate calculation never get the same depth, whatever the ticket said.

Her banking example makes it concrete: a sandbox utility script and a change touching regulated customer data should not carry the same default permissions merely because the same agent wrote both.

Scope the blast radius by risk tier rather than by how confident the output looks. She frames drawing that line as a consulting decision as much as an engineering one, which is a positioning claim for her own service line as well as an observation.

The third pillar replaces one-time sign-off treated as permanent. For AI code the drift can be a dependency version, a schema field, or a shift in the data distribution the function runs against.

Her reframe is the sentence to take into a governance meeting: trust has an expiry date, and it expires on a schedule or on a drift signal. It behaves like a credential rather than a certificate bolted to a wall.

Review Depth and Ledger

The fourth pillar replaces identical review depth everywhere, which she describes as a tax on your best reviewers’ time.

Her precedent is exploratory testing charters, which exist precisely because you cannot give every corner of a large system the same depth and still ship. Senior judgement is the rare resource and belongs where the blast radius is largest.

The fifth replaces a static test report signed once with continuous attestation, and she argues it matters most in regulated industries where audit trails and traceability matrices are already the instinct.

To an auditor, a document saying tested once on this date is worth far less than a living record. She calls it an evidence ledger rather than a certificate.

What the ledger records is specific: which agent version generated the change, which rule it was verified against, and when re-attestation happened. That turns why do we trust this six months later into a traceable answer rather than a shrug at an old merge date.

The Trust Score Demo

She runs the framework against the same loyalty discount function from the opening, in a console she appears to have built for the talk. The numbers below are illustrative values inside that demo, not benchmarks or product metrics.

On day zero the assertion on the left is written straight from a policy document, that the discount applies to the pre-tax subtotal and excludes shipping and tax, so it would hold even if the code underneath were entirely different. The right panel shows a trust score of 96, logged and attested, alongside which agent generated it, which policy version it was checked against, who reviewed it and when it is next due.

• Day 12 - a routine auto-merge dependency change drops the score with no edit to the function itself. She calls it the first real hit, and the kind of change that would never appear in a pull request for that function.
• Day 28 - a new field enters the order object upstream. Because the original assertion was written against the order total, the assertion did not get weaker; the world underneath it got wider, and the same formula now computes incorrectly.
• Day 45 - a production data dump puts real traffic through edge cases the original test set never exercised. The badge flips from verified to drifting and the score crosses the line where re-attestation becomes mandatory rather than optional.

Crossing the threshold fires the automation without anyone spotting a dashboard or filing a ticket. The function’s blast radius auto-restricts to internal traffic, and a re-verification job runs against the current state of the world rather than the state it was verified against before.

She runs re-attestation live and the score comes back 89, not the original 96, and stresses this is deliberate rather than a bug in the demo.

The two prior drift events stay in the ledger, so the function carries history and gets watched more closely next cycle than one with a clean record. Trust accumulates memory the way a credit history does, and the next loop starts from 89.

Metrics, Roles, Tooling

On metrics, she moves specification coverage and attestation freshness ahead of line coverage and pass rate as the numbers leadership tracks.

On roles, somebody has to own risk-tier assignment and the re-attestation trigger, calibrated to the organisation’s own risk appetite. Her observation is that most organisations she works with have not named that role, and naming it is usually her first recommendation.

On tooling, a drift monitor and an attestation ledger become as core to the pipeline as the test runner is today.

She is emphatic that none of it is a testing tool purchase. It is an operating model decision, and any tool can be brought in to fill the framework, which is an unusually vendor-neutral position for a session of this kind.

Q & A Session

Three audience questions closed the session.

• Should AI-generated code face a higher quality bar than human code, or the same one?

  Neelmani Verma: Not necessarily a higher bar, but different metrics and parameters, and that difference is where assurance comes in. In my own practice I use one model evaluating another, with the important condition that it is not the same model that produced the code. It is that independence, rather than a uniformly raised threshold, that matters most right now. She offers no evaluation data or tooling for the approach, so treat it as her practice rather than a measured method.

• How often should a framework re-evaluate AI-generated code for silent functional drift?

  Neelmani Verma: Observability has to be built in, and re-evaluation has to be dynamic and auto-triggered, because you cannot wait even a day. The thresholds for when different alerts fire are set by the organisation’s risk appetite and the systems involved. The checks are integrated so nobody is manually monitoring anything; the system alerts the relevant teams itself. That is the point she stresses.

• Do you track which code was AI-generated, and does that label matter downstream?

  Neelmani Verma: My engagements are currently a mix, and the human-written share is dwindling. The human versus AI distinction is not the useful one anyway, because the framework I described works for human-written code too. What has to change is the assurance thinking and how code is validated, not the perspective on who authored it. That share is an impression from her own client work rather than a measurement.

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.