Revisit Old Problems with New Eyes! [Testμ 2026]

The Vanished Constraints

He opens by looking back at what he built over the past year: a VAT filing product called Taxly, software engineering solutions he thinks are reusable across teams, and applications built purely to demonstrate ideas.

What makes the claim land is that he applies it to himself rather than to the industry. He is a testing specialist, and two years ago building a product was outside what he could do.

He also declines the obvious format. Rather than touring finished products, he sets out what a good build, test and release process looks like, then points at where each project fits into it, which is why the session works as instruction rather than showcase.

The Continuous Delivery Poll

Before teaching anything he asks the room to rate its own understanding of continuous delivery, and the answer shapes the rest of the session.

43% reported only a basic understanding and 29% said they knew some concepts but not thoroughly. He read those together on air as roughly 71% of the audience still not being clear, which is close enough to the arithmetic to make his point.

That is a self-selected webinar audience with no stated sample size, so it reads as a mood check rather than a survey, and he treats it as one, using it to justify teaching the pipeline before showing anything he built.

He re-ran the same poll near the end and reported the split as improved but not dramatically, which is a more honest reading of a live teaching session than most speakers offer.

The Pipeline Map

The spine of the talk is one diagram of continuous testing and continuous delivery built around feature toggles, which he shares with the audience during the session.

It splits into swim lanes: planning, preparation and build, a commit phase for pre-commit checks, continuous integration where every pull request check runs before anything reaches main, and continuous delivery.

His stated payoff for putting feature toggles at the delivery stage is the one that unlocks everything later: you decouple deployment from release.

His claim for the diagram is modest and useful. Understand this one picture properly and you have a working model of how software gets built, tested and released in companies that actually practise continuous delivery.

Flags at Planning Time

The planning lane is deliberately ordinary: a product owner adds a user story, the team refines it, priority puts it in a sprint.

The single addition is creating the feature flag for that feature during planning, before a branch exists. He shows LaunchDarkly as the example while saying explicitly that it could be anything.

His plain-English definition is the clearest part: feature toggling gives you two configurations under the same keys, so the same flag reads off in production and on in your development environment.

From there a developer cuts a feature or bugfix branch, creates the toggle placeholder and makes the change. His observation is that all of this used to be done by people, and in his experience agents now handle it well.

Commit Phase Guardrails

The commit phase uses git’s own hooks to run checks at different trigger points: formatting or auto-formatting, linting, password and secret scanning, and only the unit or integration tests the change actually touches.

The point he stresses is that not everything belongs on pre-commit. Git offers many triggers, so system tests can move to a pre-push event that fires when the pull request is created.

He opens Taxly to show it running: Husky as the pre-commit hook handling tests, linting and staging, with a pre-push hook that runs the affected Playwright tests immediately before the PR opens.

A failed check sends feedback to the developer instead of landing the commit. Everything passing means the developer keeps committing until the feature is ready to become a pull request.

Agentic Semantic Versioning

This is the most transferable thing he built, and it starts from a problem anyone shipping libraries will recognise.

Semantic versioning decisions are taken by a developer, and the existing tooling is fragile because it depends on commit syntax or branch-name syntax. Both are labels a human typed.

The failure mode is concrete: someone marks a feature branch as a patch, or genuine breaking changes ship under a patch version, and every downstream consumer inherits the mistake.

His solution integrates the Claude Agent SDK into the workflow so the agent reads the nature of the file changes in the pull request and classifies the release as major, minor or patch. He opens the repository and walks through real pull requests where the agent made that call.

His argument for placing the judgement inside the PR rather than after merge is the part worth stealing. The pull request is where all the context sits, and delaying the decision by another two or three PRs means nobody can still say whether the release is a patch, a minor or a major.

The Integration Gate

Once a pull request to main is open, everything bound to that event fires: formatting, linting, security scans and licence checks.

The automated test layers run here too, unit and integration tests plus system tests for both front-end and back-end applications, with code coverage checked against a threshold.

He counts merge policy as part of the same gate rather than as process overhead: a minimum number of approvals, no unresolved review comments, code-owner review, the branch up to date with main, and an agreed merge strategy.

Demonstrating it on Taxly, he shows code coverage above 85% alongside resolved issues, with checks covering formatting, linting, unit tests, system tests, build and deployment status.

Inside the repository he shows the parts that are newer: separate test skills and development skills defined as files, MCP servers wired into VS Code including one he built to pull an agent’s pull request comments from GitHub into his own terminal, and a test pyramid of unit, component and system tests split across front end and back end.

Agents in Exploratory Testing

After a merge under trunk-based development the pipeline builds an image, or a library pushed to an artifact registry, and deploys automatically to the test environment.

He makes a claim here that most teams would resist: with feature flags hiding the new change behind existing production behaviour, you may not need multiple environments at all.

A full or smoke regression runs automatically after deployment, with performance tests triggered on demand for changes that warrant them.

Then he takes on the objection directly. The common community position is that agents can do everything except exploratory testing. He used agents for exploration in his test environment, found the results impressive, and reports the same for pull request reviews.

That is experience rather than measurement. He offers no metrics, baseline or sample size for it, which is worth knowing before treating it as evidence rather than as a practitioner’s report.

Dark Launch, Soft Rollback

Production deployment happens with the flag off, enabled only for a set of test users or locations. The code is live and the feature is not, which is what shrinks the blast radius.

Dark launching targets a subset by location, geography, or friends and family, and his suggestion is to sit with that group for a week or two before widening.

When the team is ready, the product owner adds targeting rules for canary releases, beta testing with a small customer group, or A/B experiments shipping the same feature to two groups to see which gains traction.

The payoff arrives when something breaks. A problem behind a toggle is switched off rather than hotfixed, so affected customers are not waiting on a release. His phrase for the speed of that is microseconds, which reads as a figure of speech about flipping a flag rather than a measured figure.

For anything not behind a flag the decision tree is unchanged and worth having written down: can you roll back to the last stable version without losing data? If yes, redeploy the last good artifact. If no, cut a hotfix branch from main and put it through every one of the same checks.

One Commit, Three Behaviours

To move the diagram from theory to something testable he built TaskFlow, an application demonstrating trunk-based development with feature toggles, and shared the repository with the audience.

The pull requests show which commits reached only CI and which went to staging or production, and the docs hold a separate feature-flag source configuration for each environment.

He then opens three genuinely deployed instances, stressing that none of them is localhost, and runs the same commit in each.

In CI the build shows the task dashboard, CSV export, commenting and linking. In staging the dashboard, export and linking are gone. Production runs on defaults. Same commit, different behaviour, controlled entirely by flags.

He offers the material for reuse: one repository demonstrating trunk-based development with feature flags, one for agentic semantic versioning, and Taxly, which he cannot share because it is the commercial product he is still building towards a launch he places at the end of this year or next.

Breaking Roles Vertically

He closes on organisational design, which is where the personal story becomes a claim about teams.

Software engineering has historically been split horizontally: requirements reviewer, front-end engineer, back-end engineer, manual tester, automation engineer, architect, ops. His experience building these products is that one person with agents and a decent grasp of how software is built can now cover all of them.

He is fair to the model he is arguing against. Multiple roles made sense precisely because the knowledge spanned more than one person could hold.

His prediction is that teams start breaking roles vertically instead. With ten features, rather than five people all testing the same one, each person owns a feature end to end.

Q & A Session

Finishing about ten minutes early left room for an unusually substantial Q&A, six questions in all.

• How does AI actually help when you look at old ideas with fresh eyes?

  Pramod Yadav: It bridges the gap between having the right idea and shipping the product. What made both the VAT product and the versioning solution work was that I was very clear about what I wanted and what I did not want. Clear requirements produce better results, and where the requirements are fuzzy to you the agent guesses: uncertainty in, uncertainty out. Once an agent has built something, exploration and acceptance testing become the most valuable work left.

• Why feature flags over short-lived branches?

  Pramod Yadav: I use short-lived branches too, so I reject the framing. In complex applications with several teams you end up compromising: the short-lived branch becomes long-lived because the feature needs too much before it can launch safely, or you risk breaking another team’s work. So it is not either-or. You want short-lived branches behind feature flags, so a feature can be enabled just for you and tested in isolation. Pressed to choose, he calls it a scaling problem rather than a CI speed problem.

• Is there a risk of over-reliance on AI, and how do you keep critical thinking sharp?

  Pramod Yadav: It is a big risk and I have not solved it. When I built things myself, they went wrong and I debugged them, and debugging and failing is how the skill stays alive. Agents have met my expectations well enough this year that I now offload most tasks, which risks losing hard skills over time. Reviewing a project structure while access was down, I was glad to find I had not lost my touch. What you do not use, you lose, like muscles. That reassurance is anecdotal.

• Which old testing problem is AI finally cracking?

  Pramod Yadav: We ran pilots using AI to generate unit, component and system tests, produce exploratory results and write mutation tests, which are otherwise slow to produce, and it did well across all of them. The real answer is that the impact outside testing is larger than the impact inside it: a year ago I was good at testing and could not imagine building an application, and now I can. He widens the question rather than answering it narrowly, and offers no metrics or baseline for the pilots.

• Test data, environments or flakiness, which would you attack first?

  Pramod Yadav: Environments, and they are not an AI problem at all. Teams need environments mainly because they are not doing trunk-based development with feature toggles, so deploying somewhere is the only way to test a change; adopt continuous delivery and the problem largely dissolves. On flakiness, data is one cause but not the main one. Most of it comes from state conflicts, two tests using the same data, account or resource at once, and that is a design problem: find the conflict-prone areas and give those tests their own data so they can still run in parallel.

• Who is accountable when an autonomous agent causes a security incident?

  Pramod Yadav: Treat the agent as a tool. When something goes wrong, ask what can change in the tool so it does not recur, and only escalate to people when it cannot. Organisations should state clearly what accountability means to them, but the emphasis belongs on fixing the problem rather than deciding whose head should roll. He turns the question on humans first, and it produces the sharpest moment of the session.

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.