Why AI Didn't Actually Make You Ship Faster — Gabriel Spencer-Harper, Meticulous
Gabriel Spencer-Harper, co-founder and CEO of Meticulous, explains why assertion-based tests cannot keep pace with AI-generated code and how near-exhaustive frontend verification with zero developer effort works. The talk covers record-and-replay visual diffing on every pull request, network mocking, a deterministic browser, and coverage-guided flow selection that makes code coverage meaningful.
Verification is the new bottleneck
AI now writes code faster than people can review it, so verification has become the constraint. Teams without exhaustive verification end up trading velocity against bugs and user experience, because someone has to manually check the impact of every change. Gabriel Spencer-Harper, CEO of Meticulous, argues that the answer is near-exhaustive verification of the frontend with zero developer effort.
Why assertion-based tests fall short
No matter how carefully a human or an agent defines correct behavior up front, the space of possible regressions is too large to cover with hand-written assertions. A useful test is to ask whether you would merge a given pull request if an engineer in your organization, or an AI, had written it. In most organizations the honest answer is no, because real confidence requires manually checking feature flags, roles, permissions, configurations, and edge cases.
The cost shows up in three ways. Bugs and regressions carry business impact. Engineering organizations spend double-digit percentages of their time maintaining end-to-end suites across manual validation, review, debugging flakes, and updating tests. Weak verification also makes teams avoid the changes that matter most, such as bumping dependencies, sweeping refactors, or accepting AI-generated changes with confidence. Exhaustive verification would let teams program in a different way.
Record and replay on every pull request
Meticulous is installed with one line of JavaScript on non-production environments such as localhost, QA, dev, and staging. The script instruments the browser and records thousands or tens of thousands of user flows, such as clicking login, opening settings, or opening analytics.
When a pull request opens, CI spins up the application locally and Meticulous replays a subset of those flows, dispatching each event in sequence. At every atomic moment it takes a screenshot, producing a sequence per flow for the code before the change and a sequence for the code after it. The two sequences are diffed, and a comment typically appears on the PR within minutes.
Meticulous does not decide whether something is a bug. It shows what would be different if the code were merged, and the reviewer or an agent judges whether each before and after diff is expected. In the demo, one change renamed a label in both light and dark mode, and another introduced an error in a dropdown. Assertion tests encode expected behavior up front; here the judgment happens at review time.
Three technologies behind the approach
Network traffic is fully mocked. Requests and responses are recorded and stubbed at replay time. This makes tests idempotent, so the same flow can run a thousand times with identical results. Each test is also isolated from the others, which removes race conditions and allows horizontal parallelization, so results come back in a few minutes.
The browser itself is made deterministic. Browsers were never designed for determinism, and randomness leaks in from many places, from animation timing that depends on CPU clock speed to the interleaving of setTimeout and setInterval. Meticulous augments the browser from the scheduling layer up so that it behaves fully or nearly deterministically. The claimed result is orders of magnitude fewer flaky tests than tools such as Cypress or Playwright.
Flow selection is coverage-guided. Each recorded flow is replayed once against the main branch while monitoring which lines of code execute. This builds an index mapping each workflow to the lines it executes, and then a subset of workflows is chosen to maximize code coverage across the application.
Why code coverage finally means something
Code coverage is usually a weak metric. A Cypress or Playwright test can cover 100 percent of a codebase while making a single assertion, so covered code is not the same as tested code. Because Meticulous takes a screenshot at every possible moment of a flow, coverage approximates tested code: a single pixel difference anywhere along a covered path gets flagged.
That level of detail produces a lot of data. Screenshotting every step yields on the order of tens or hundreds of millions of images, and without a fix that volume would drown teams in noise. This is why flakiness has to be solved at the root by making the browser deterministic, rather than tolerated after the fact.