Agentic Engineering: From Writing Code to Reviewing It [Testμ 2026]

The Autonomy Ladder

Before making any claims he lays out a map, because AI coding gets used for five very different things and the differences decide everything else.

The vertical line between L2 and L3 is the whole argument. Everything to the left makes one person faster; everything to the right multiplies a team, and you do not cross it by buying a bigger model. It is an operating model change, not a capability upgrade.

At L3 the agent has its own machine, so it can run the tests, read the failure, fix and run again against real feedback rather than guessing. The developer stops being the driver and becomes the reviewer of the destination.

His conclusion from the ladder is the sentence a testing audience should take personally: every rung removes a human checkpoint, which raises the value of the checkpoints that remain.

Keystroke to Ticket

For seventy years the unit of software work did not move. A human at a keyboard produced the next line, the next character, turn by turn, and every IDE and linter the industry built made that keystroke faster.

The assistant era kept that shape. AI suggests fragments and you execute, which is useful, but you still own the stitching, the testing, the documenting and the shipping.

An agent accepts a ticket rather than a keystroke, and returns something different in kind: a plan, a traceable change, tests, documentation and a pull request ready for the same governance process as any other change.

He puts the weight of the session on one word in that list, which is reviewable. Once the unit is a ticket, typing speed stops mattering and three things become scarce: clarity of intent, architectural judgement, and high-quality review.

His aside is that the audience has been training for those three for entire careers. He spent his own first two years as a quality engineer before moving into deployment work.

Local and Cloud Agents

He separates two mental models that get collapsed together, and the distinction is about synchronicity rather than capability.

A local agent runs in your editor, your file system and your attention. It is synchronous by design, so you steer each step and verify each step, and it makes you faster.

He cites research from Microsoft and other organisations for the limit of that model, putting code generation at roughly a fifth of the productivity available while the rest of the lifecycle holds the other four fifths.

A cloud agent is not a tool but a team member with its own machine. It clones the repo, implements, runs tests, iterates over failures and opens the PR while you are in a meeting, drinking coffee or asleep, which is precisely why you can delegate a fleet of them at once.

The economics follow from that. Reviewing takes minutes where writing takes hours or days, so converting hours of writing into minutes of reviewing is real leverage, on one condition he flags immediately: the quality has to stay constant, and that part is not free.

The Delegation Failure

There is one sentence he says on day one of every enterprise rollout, and it is the one engineers resist hardest.

The loop is easy to describe and hard to live: define the task, delegate it, review the output, and give feedback on the PR where the record lives rather than in a chat window.

The step people fail at is the delegation itself. His description of the failure is engineers micromanaging an agent like nervous parents watching a teenager learn to drive, rechecking every intermediate step and destroying the advantage in the process.

The skill that replaces it is writing a task definition clear enough that you can afford to walk away: hand over twelve hours of work, then review the outcome with full attention for thirty minutes.

His framing for the difference is that drivers watch the road every second while reviewers inspect the destination, and that testers already know how to do the second one.

The Golden Question

If you keep one slide from the session, he says, keep this one. Every delegation decision goes through a single filter.

• Yes - there is a mathematically objective way for the agent to know it has finished: a comprehensive test suite, an API contract every endpoint must conform to, an automated visual end-to-end regression framework. The agent writes, runs the verifier, sees the failure, writes again, and repeats indefinitely without anyone telling it whether it is right. Strong candidate.
• No - the only way to know is your judgement: your tests, your architectural experience, or an undocumented incident from 2019 that exists nowhere but your memory. Refine the spec until parts of it become verifiable before an agent touches it.
• The grey zone - most real engineering work. Stage it: the agent researches, you decide, the agent implements your decision, you review.

What he wants noticed is what kind of question that is. It is a testing question, which means the delegation boundary of an organisation is exactly the coverage boundary of its verification.

Tests Are the Speed Limit

The question he gets asked most in the field is which frontier model to buy in order to improve the software lifecycle. He thinks that is the wrong question.

The ceiling on how much work can be safely delegated is not the model. It is the test suite, which makes the people who build verification the ones setting the speed limit on the entire adoption curve.

His corollary is blunt: an enterprise without objective verification cannot safely deploy autonomous agents at all, whatever it spends on models.

He is direct about what that means for the audience. Quality engineers were treated as second-class citizens in the previous decades of software delivery, and in an agentic model the ability to verify objectively is what governs how fast an organisation can move.

Delegating a Scoped Ticket

He put the demos in the middle of the talk rather than at the end, deliberately, so each claim is followed by evidence for it. Each run is triggered on stage and then, for time, he switches to the same session already executed, so what you watch is a played-back run rather than a live one.

The first is a well-formed Jira ticket against a hypothetical social blogging portal: article slugs must be URL-safe. What makes it work is the prompt structure rather than the task.

It carries full context, end-to-end requirements, how the feature should be implemented, and explicit success criteria that define done, including what the PR should say. Then you fire it and close your laptop.

The agent plans, edits, builds and runs inside an isolated VM, performs end-to-end visual validation, and opens a pull request as a complete reviewable package.

The field patterns he names next all move the human from the trigger to the final gate: vulnerability remediation, bug investigation, and monitoring a Slack channel for work to pick up.

The 3 AM Alert

The second demo is the one that makes the case, because nobody prompts anything. An internet banking application fails on a simple account-to-account transfer.

Sentry raises the error, the alert lands in Slack, and the agent starts a session off the back of it.

What it then does is triage rather than patch. It reads the type error from Sentry, queries Datadog over MCP, works out which functions are affected and maps the dependencies, rather than fixing the first error it sees.

The evidence it assembles is specific: the failure occurred 600 times in the period, the API is returning HTTP 500, and every transfer attempt against that endpoint fails.

It writes the fix, raises the PR, runs the suite, writes the tests that were missing, compiles the binary on its own machine and exercises it the way a Selenium or Playwright run would.

Total elapsed time was eight to nine minutes. His comparison is a human woken at midnight in panic mode, who with the best local tooling might take thirty minutes at best and hours at worst, and who now wakes instead to a reviewable package with CI green.

Agent Swarms

Some tasks are too large for a single agent, and the answer is a hierarchy that will look familiar to anyone who has run a team.

A lead agent decomposes the problem, spins up workers to run scoped tasks in parallel, then aggregates and cleans the results as they come back, with deduplication and false-positive validation on top.

He points out that the shape of the diagram is a management hierarchy, and the skills it runs on are the same three: decomposition, delegation and review.

What that unlocks in practice is scale on work that was previously deferred indefinitely: crawling a multi-million-line codebase, running a large migration, or auditing code quality across a thousand repositories in days rather than quarters.

His framing of the result is the line worth keeping. Engineering judgement was not automated away, it was maximised, and a human still sits above the lead agent as the final gate even when hundreds of sessions run in parallel underneath.

Three Green Gates, Wrong Code

The pipeline has three verification stages: the agent’s own verifier, CI, and a review pass. The agent even watches CI, reads the logs and re-runs until it goes green, then delivers the PR with video evidence and a test report attached.

Which raises the question he says every tester in the room is already asking. What if all three pass and the code is still wrong?

His final demo is built to produce exactly that. At 5:55 PM a developer in a hurry writes a prompt with no scope and no success criteria: we keep getting encoding bugs from non-ASCII slugs, some old slug tests are probably outdated, fix whatever fails, do not overthink it, get CI green and open a PR.

The most interesting moment is what the agent does during planning. It flags that the instruction to fix failing tests overrides the general principle of treating tests as the source of truth, then follows the instruction anyway because the human gave it, deleting tests rather than satisfying them.

A separate review agent runs on the resulting PR and finds three bugs. The one he opens is articles with fully non-Latin titles, in Spanish or Chinese, producing a blank slug because the global case was never covered.

It fixes them, re-runs the suite end to end including the non-Latin cases, and rewrites the deleted tests, so what reaches a senior developer is a clean package. That is what he means by delivery as a closed-loop quality system: a bad prompt was caught by a gate that sits outside the agent that obeyed it.

Q & A Session

Time allowed two questions from the audience at the close.

• How long does a full SDLC cycle take on average?

  Sumit Shatwara: Most of the elapsed time goes on defining the success criteria for the delegation rather than on execution, which loops back to the golden question. With that answered and the pipeline connected, a typical task runs from planning to a reviewable PR in ten to thirty minutes depending on complexity, against the three to six hours a developer would spend. Codebase-wide work such as a security swarm takes days, because it is doing a quarterly job in one pass.

• Is mobile or gaming a good use case?

  Sumit Shatwara: Yes. The agents run on Linux and Windows VMs today, with macOS support coming in the following months, which brings the Xcode toolchain and iOS simulation into range. Android emulators are already supported on those machines, so a mobile app works whether it is a game or anything else.

His closing line is the one to argue with or adopt: the job is not disappearing, it is inverting. Humans set the intent and approve the outcomes, and agents do the mechanical execution in between.

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.