What Happens When You Go All-In on Agents [Testμ 2026]

The Backlog That Vanished

Rashi Agrawal opens with the concrete problem. Her QA teams could not keep up, there were three sprints of backlog, and every release was waiting on testing. That is why the team decided to go all-in on AI.

The stack they went all-in with is short: Claude Code, Cursor, and custom agents built for healthcare.

Her timing is worth stating carefully. She says the backlog was gone four months later, having opened by dating its disappearance to a few months ago, while the host and the video description both say six months.

The emotional beat she leads with is not triumph. She expected to feel great and instead felt confused, because the problem had not gone away. It had moved.

She promises up front that where it moved changes everything about the job, and then withholds the answer for roughly sixteen minutes. She also frames the audience rather than herself as the beneficiary, calling this the most exciting moment the profession has ever seen, which is a superlative with nothing attached to it.

The 2026 AI SDLC Map

Her zoom-out is what she calls the AI SDLC in 2026: AI embedded in requirements, design, writing code, reviewing code, managing deployments and watching production, every phase at once.

Her argument for why that matters to a QA audience is the strongest line in the section. When the whole system is changing, the people who understand the whole system become the most valuable ones in the room.

She shows an AI developer tools landscape she says was compiled this year: 231 companies across 16 categories, spanning foundation models, inference infrastructure, LLM gateways, vector databases, coding agents, agent frameworks, workflow automation, AI security and observability. She does not name who compiled it, so it cannot be looked up.

Her point about the map is the shape rather than the count. Every category on it eventually produces an output that someone needs to evaluate, trust or verify, which she calls a quality engineering mindset.

The adoption figures on screen come without a named source: 97% of engineering teams already using AI or planning to, and 76% of practitioners saying AI will mean more engineers hired rather than fewer. The one attribution she gives is to Gartner, for a claim that 40% of enterprise apps will contain AI agents by the end of 2026, without citing a report.

Their Production Stack

She describes the stack by role rather than by feature list. Claude Code is the heavy lifter for complex autonomous builds and deep codebase reasoning, and Cursor is the daily driver for her engineers.

On top of those they build custom skills for their own context, because healthcare is uniquely constrained: HIPAA data handling, patient safety considerations, and clinical accessibility requirements for users managing chronic pain.

The design decision she stresses is sequencing. They went agent-first instead of adding AI to existing workflows, redesigning the workflows around what agents do well.

The headline number for that stack is a 60% reduction in feature development time, and she pre-empts the obvious objection: this is not a pilot metric, it is production measured across a full quarter. She gives no baseline, team size or measurement method.

That figure is worth pinning down, because the video description instead claims feature cycle time dropped 99%, and the host repeats that version in the introduction. Rashi Agrawal never says it. Her 99% figure, which arrives later and carries an “about”, is PR cycle time falling from a daylong roundtrip to minutes.

Inner Loop, Outer Loop

She credits the framing to Addy Osmani. The inner loop is what the industry spent years optimising: autocomplete, single edits, one file, generating code, all inside the editor. Useful, and never where the time went.

The outer loop is the whole delivery cycle, from figuring out the plan through building, testing, reviewing and shipping. That is what her team handed to agents, and she calls it the difference between a faster typist and a faster team.

She then opens up what an agent does when it runs unattended, and insists it is not one big leap but a loop: plan, act, observe, verify, repeat, running until it hits a real done condition.

Her explanation for the cycle time drop is deliberately unglamorous. Nobody types faster. The loop never gets tired, never context switches, and never forgets to check its own work, which is why the whole game is making that loop trustworthy.

The Harness Is The Moat

She calls this her most important slide. Everyone obsesses over the model, which model, which version, whose benchmark, and the model is not the hard part anymore. What matters is the harness built around it.

A harness has four parts in her breakdown: context architecture, meaning what the agent knows and how you feed it the right information at the right moment; tools and environments, meaning what it is allowed to touch; guardrails and verification gates, meaning what it can ship without a human; and memory and feedback, meaning how it stops repeating the same mistake.

On memory she gets the biggest recognition line of the talk, asking how many people have told their own coding agent not to do something and watched it repeat the mistake anyway.

She then draws a line she says gets confused constantly and is dangerous in a regulated environment. Vibe coding is fast and exploratory: you prompt your way to something that works and do not really verify it, which is fine for prototypes, quick proofs of concept and weekend experiments.

Agentic engineering runs at the same speed but inside a loop inside a harness, and every output is verified before it counts. One of these ships to patients and one does not. Her answer to people who call going all-in reckless is that they are picturing vibe coding at scale, while what her team runs is agentic engineering inside harnesses at scale.

Fleets And Earned Autonomy

The unit of work changed. The old unit was one engineer, one task, start to finish. The new unit is one engineer supervising a fleet of agents running in parallel, each on its own branch doing its own work.

The role change follows from the parallelism. The engineer stops being the person typing and starts being the person directing traffic and reviewing outcomes.

She attributes the throughput number directly to that parallelism, saying PR throughput went up four to five times, and stops to correct a likely misread by clarifying that she means four to five times rather than four to five percent. No baseline period, team size or definition of a PR accompanies it.

She uses the number as a hinge into the twist: if one engineer can drive five streams of work at once, can everything upstream of engineering keep those five streams fed?

On autonomy she is explicit that agents were not trusted on day one, because autonomy is earned rather than granted.

Tiering is by risk and by track record. An agent earns its way up the same way a junior engineer does, and a low-risk internal change gets more rope than anything touching patient data. Her point about all three tiers is that every one of them still requires a human to exercise judgment.

The Constraint Moved

Here is the reveal. They fixed the testing and QA bottleneck, then fixed the development bottleneck. The loop was fast, the harness was solid, the fleet was humming. Then they looked up, and the constraint had moved past testing, past development, past design, all the way upstream.

She explicitly refuses the cheap conclusion. The easy read is that product is just slow, and she calls that a sloppy read and wrong.

Her diagnosis instead is that writing the spec was never the hard part. The hard part is deciding what is actually worth building and what it should feel like to use, and that is a judgment call.

The line she builds the rest of the talk on: judgment is the one thing that did not get faster when agents showed up.

She reframes the result economically. They drove the cost of building down to almost nothing, and all that did was expose the real cost sitting underneath it, which was judgment all along.

Three Faces Of Judgment

On the quality side she cites two more figures without attribution: 73% of engineering teams have already hit real problems from AI-generated code accepted without anyone understanding it, and 76% are finding compliance issues after deployment rather than during. Note that this second 76% is a different statistic from the earlier one about hiring, despite the identical number.

She singles out the compliance figure for her own industry, where after deployment is exactly the wrong time to find out.

Her honesty beat lands here. AI made their output dramatically faster and did not make it automatically better, because speed and quality are two different dials and the agent only turns one of them. Faster just means you fail faster.

The third face is definitional. AI can generate thousands of test cases and cannot tell you which edge cases matter, and her example is a 68-year-old patient managing chronic pain on a mobile app.

She lists three things AI cannot do: pick which edge cases matter, determine the risk threshold at which you hold a release, and audit whether an agent’s decision was right given business context it does not have.

Then she pulls the threads together. Running out of requirements was judgment about what to build, unverified code was judgment about what is safe, and defining good was judgment about what done means. The same scarce resource in three disguises. The bottleneck did not move to product or design so much as it moved from doing the work to judging the work.

Context And 47 Edge Cases

Her first superpower is context architecture, and its rule is blunt: an agent produces output exactly as good as the context you give it, no better.

What a human supplies is the personas, the domain constraints, the quality criteria and the risk boundaries. The depth of your domain expertise and how well you understand your users becomes the raw material the whole system runs on.

Her worked example starts with an agent writing test coverage on its own and producing generic, reasonable-looking tests. Then a team member fed it the context that actually mattered.

That context, in her list: elderly patients with chronic pain, mobility limitations, pain medications affecting fine motor control and reading comprehension, screen reader requirements, and users who might be anxious or distressed during intake.

The result she reports is 47 targeted edge cases from the same agent, including what happens when a shaking hand accidentally triggers the wrong input field repeatedly, and when a user abandons mid-flow three times before completing. She gives no before-count and shows no artefact, so this is a recounted internal incident rather than a benchmark.

The Verification Machine

Her second superpower is what you build around the output. The QA engineer of 2026 does not write tests, they design the verification machine.

Her claim for its leverage is that this system now governs the output of every AI agent her teams run, designed once and scaling indefinitely. The scaling claim is rhetorical rather than measured.

The distinction she draws from it is the useful part. You are not manually reviewing each output, you are designing the architecture that determines which outputs need what level of scrutiny, and that is engineering rather than execution. It gets more valuable as you deploy more agents, not less.

Her third superpower is the judgment call itself, and her reason it cannot be automated away is non-determinism: the same prompt in a different context with different surrounding code produces a different result.

She backs it with another unattributed figure, that 71% of developers who actively use and love AI tools still will not merge AI code without a human check, and names the trap: you cannot review everything, or you eliminate the efficiency gain you were after. Her framework is a question. Given this risk level, this evidence and this context, is this output trustworthy enough to ship?

Four Agent Blind Spots

Her fourth superpower is lived human experience, and she makes it concrete with four misses she attributes to their own systems rather than to a study.

The agents never tested device switching mid-session, because it never occurred to them that a person would start an exercise on their phone and finish it on a tablet in the same flow.

The agents missed time zone edge cases, because they only tested from the developer’s local time zone.

The agents generated visually attractive UI that was completely inaccessible to screen readers.

And the agents had no concept of a patient who has just received a difficult diagnosis, whose emotional state means their reading comprehension has dropped and who needs simpler language and more forgiving input validation.

Her conclusion turns the audience’s own life into the qualification. You have switched devices. You have struggled with broken software in a stressful moment. No AI model has lived that. She reframes the four superpowers as skills AI has freed people for rather than skills that are dying, and calls it a promotion if you take it.

The Six-Month Path

Her on-ramp needs no budget and no permission. Months one and two: pick one tool and use it every single day rather than occasionally, see where it is great and where it falls apart, and write it down, because that is what builds the intuition you need before leading others.

Months three and four: bring the team in, starting with one thing, and she suggests test data generation as a good first candidate. Hold it to a single metric. Did you save more time than you spent reviewing the output? If not, find out why before going bigger.

Months five and six are the hard part. Start showing up to product meetings and ask how we will know this works, before anyone writes a line of code. That question from someone with a QA background, she argues, is worth more than anything done at the end of the cycle.

Her picture of the QA engineer of 2027 carries a different title, perhaps quality architect or AI systems engineer, whose day starts by reviewing the evaluation criteria they set for an agent pipeline that ran overnight. The numbers she uses to illustrate that day are invented for the purpose rather than measured.

The closing figures are again unattributed apart from a second Gartner reference: 87% of engineers who actively adopt AI tools saying it future-proofs their career, an AI-in-testing market reaching 4.8 billion this year with no currency or source stated, and Gartner’s projection that 55% of software engineering teams will be actively building LLM-based features by 2027.

What she says she wants the audience to leave with is not a framework or a checklist but a feeling: that the instinct to learn, experiment and stay ahead is what the moment requires, and that the strategic seat AI has opened is there to be claimed.

Q & A Session

Four audience questions closed the session. The askers’ names are inconsistently rendered in the captions, so they are not reproduced here.

• What environment makes a sandbox for exploring agentic AI safe, while discouraging shadow AI use?

  Rashi Agrawal: On sandboxes she is encouraging. You do not need much permission: with a proposal, an idea and allies in infrastructure or service enablement, go build it. Her one hard constraint is data, since no HIPAA-regulated data, PHI, PII or sensitive data should ever reach the sandbox, and she suggests using other agents that do have access to higher-fidelity data to generate mock data instead. She twice asked the questioner to clarify what they meant by shadow AI use, received no answer, and said outright that she was not sure what was meant before offering a guess, so that half of the question went unanswered.

• Where is the greatest growth in quality engineering as agentic AI shifts toward autonomous operations?

  Rashi Agrawal: In becoming more strategic about which problems you approach. Quality has long sat at the tail end of the lifecycle, picking up work after a handoff, present when features are outlined but doing its real work later. The shift is the chance to be the voice in the room when the feature is being discussed, because a QA engineer already has the domain expertise and systems knowledge to say whether something will break and how it would be verified. Her closing instruction was behavioural: do not be a passive receiver of what is handed to you, claim that seat and challenge assumptions.

• In regulated industries, how do you maintain compliance and safety guards when static spec sheets are replaced by dynamic agent behaviour?

  Rashi Agrawal: I am taking static spec sheets to mean deterministic binary expected outputs, and this is not just healthcare. Start by defining what quality means, what the bar is, and how you will measure it. Say you have an AI health assistant helping someone triage pain and deciding whether they should go to the ER, call emergency services, or follow a recommendation. Rather than specifying each step, evaluate the whole conversation against the member’s outcome. Building measurement around complex conversational data is hard. She restates the question under that explicit assumption, her illustration is hypothetical, and the confidence claim she describes about escalation rates is an aspiration rather than a measured result.

• Do you need to progress through every autonomy tier, or can you skip ahead?

  Rashi Agrawal: Conditional. If you want to reach full autonomy you have to walk the tiers, because the earlier ones are how you discover your evaluation threshold: each tier teaches you where your agent is failing and where things break, and only that observation lets you set a number. She marked her own number as an example rather than a recommendation, using a hypothetical threshold to make the point that you cannot know the right value in advance. The release valve is that if you do not need full autonomy, you do not need to walk all the tiers at all, and some systems may perpetually require a human in the loop.

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.