If Coding Is Solved, How Do We Fix Specification and Testing?

A year ago I had an epiphany: AI could write better code, faster, than I could. Since then, I’ve come to trust what the frontier model makers say: “coding is a solved problem”. It may not be fully true yet. But it will be soon.

If that holds, the bottleneck doesn’t disappear — it moves, to specification. Humans have a poor track record there, and the methods we have to improve it — inspection and review — are too slow and expensive to survive AI-speed delivery. We’ll be forced to bring AI into territory we’ve resisted: requirements capture and analysis, test analysis, risk profiling, usability and security judgement.

This focuses attention on trust. If software is built by AI agents, or a hybrid human-AI collaboration, how does anyone — regulator, customer, employee — trust what they deliver? This is the AI Assurance Problem, and most enterprises struggle with it.

This talk suggests a possible answer: a handover model between client and builder — Specification, Developer Tests, and an Assurance Framework — and what it implies for today’s testers.

Fewer testers, and two new roles emerging at the centre of it: Requirements QA and AI Assurance Engineers.

It’s the old verification/validation split, re-emerging as the fault line for what’s left of testing once build-level work is automated. Verification (did we build the system right?) becomes the Assurance Engineer’s job. Validation (did we build the right system) stays stubbornly human, and that’s exactly the ground the best testers should be claiming.

Part case study, part provocation — drawing on practical experience since February 2026 building and running an AI-assisted requirements and testing process in production — this talk asks not what AI can do for testing today, but what’s left for testers to do once it has.