Nobody Reads the Code Anymore
How to run verification for engineering teams that ship with AI agents
Nobody is reading all that code, and pretending otherwise is how agent-written bugs reach production.
Vilhelm von Ehrenheim shows what checks the code instead – invariants, judges and dynamic testing on the PR's preview environment – then opens a real pull request and lets an agent find the bug, live.
- Thursday, October 22, 2026
- 16:00 CEST / 10:00 ET · 60 min
- Online
Demo runs on Vercel preview deployments
About this webinar
Why we're running this session.
Most teams now let agents write a large share of the code, and the only check between the spec and the merge is a set of unit tests the same agent can rewrite. That is an open loop, and open loops only hold for systems that are deterministic and well understood. Agents are neither.
Vilhelm shows what closes the loop: four kinds of invariant you can write down this week, judges that score the blast radius of a change and review it against the ticket, and dynamic testing on the PR's preview environment. The longest block is in the product – a pull request, the test cases the agent generates for that change, the regression it catches, the evidence it leaves for the reviewer, the fix handed back to the coding agent. API test cases run in the same PR.
You leave with a verification stack you can start building with. And if you deploy on Vercel (or a similar solution), you get a shorter path to verification: every PR already has a preview deployment, which is the one thing dynamic testing needs to run.
What you'll learn
Six things
you can use the next sprint.
- Why agent-written PRs sit five times longer waiting for a human reviewer – and why reading harder is not the fix.
- The four kinds of invariant worth writing down now – decisions a senior already made, written so a machine can enforce them.
- How to turn the review agent you already run into a judge: give it the ticket and the codebase's rules as a rubric.
- What dynamic testing does that a regression suite can't: score the change, generate the test cases it needs, run them on the PR's preview.
- How to evaluate the evaluator – benchmarks of bugs you already found, and the four failure modes that look like progress.
- Where this stops today: what you need in place (a preview per PR – Vercel gives you this for free), what it doesn't replace, and the real ramp-up curve.
Agenda
Sixty minutes, including a live verification run on a pull request.
- 00:00 – 00:05
Welcome & intros
Who's on, what to expect.
- 00:05 – 00:15
The problem
Agents optimise the reward, not the intent. Why spec-driven development is open loop.
- 00:15 – 00:25
The checks
Invariants, judges, risk scoring – and one human approval at the end.
- 00:25 – 00:45
Live demo
A real PR on a Vercel preview deployment. No pre-written tests – the agent explores what changed and reports the regression in GitHub.
- 00:45 – 00:50
Evaluate the evaluator
Why two 100%-green harnesses can both be lying.
- 00:50 – 01:00
Q&A
Bring the hard ones.
Host & speakers
People you'll hear from.
Speaker
Vilhelm von Ehrenheim
Co-founder & Chief AI Officer at QA.tech
Vilhelm builds the agents that test software at QA.tech, and worked on ML systems at Klarna before that. He gives the talk, runs the demo live in the product, and takes the technical questions.
Host
Rebekah Black
Tech Advisor at QA.tech
Rebekah talks to engineering teams about their verification setups every day. She keeps the session on time and makes sure your questions reach Vilhelm.
Set-up for the session
Stack for the demo
Vercel
GitHub
QA.tech
Vercel preview deployments per PR · GitHub for the review · QA.tech for the verification run
FAQ
Questions before you register.
- Is this webinar free?
- Yes. Register once and you get the live link, the recording and the slides.
- Will there be a recording?
- Yes. Every registrant gets it in the next few days after the webinar, whether or not you make it live.
- What is dynamic testing?
- Instead of re-running a fixed suite on every change, an agent reads the pull request, scores what it touches, generates the test cases that change needs and runs them on the PR's preview environment. The suite is built per change, not maintained forever. Read how it works →
- Who is this for?
- CTOs, VPs and Heads of Engineering, platform and QA leads at teams already shipping agent-written code. The more PRs your agents open, the more of this applies to you.
- Is this a product pitch?
- The first 25 minutes are Vilhelm's conference talk and vendor-neutral – invariants, judges and closed loops apply whatever you use. The demo is on QA.tech, because that's what he builds. You'll see exactly what it does and what it doesn't.
- Do I need preview environments for any of this?
- For PR-level verification, yes – an environment per PR is what lets an agent use the product before you merge. We'll show what you can still do against staging if you don't have them yet. If you deploy on Vercel you already have one per PR – that's what the demo uses.
- I already have a big Playwright suite. Is this for me?
- If you have 4,000 Playwright tests and they work, keep them. This session is about what they don't cover: the new change, the long tail, and the question of whether the code matches the intent.
Nobody is going to read all that code. Verify it instead.
QA.tech scores every pull request, generates the test cases the change needs, runs them on the preview environment and posts the evidence back to GitHub. See it on your own repo in a 30-minute demo.