I’ll Never Write Code Again — And Neither Will Your Automation Engineers

The Code Epiphany: Why AI Changes Automation by Changing Requirements

In February 2026, after a week watching Claude Code consistently write better code than me, I made a decision I never expected to make: I would stop writing code. Not because I wanted to — but because the evidence said Claude writes code BETTER AND FASTER than I could ever do. If you build, run or manage test automation for a living, I think you’re closer to that week than you’d like to believe.

This isn’t another “AI writes your Playwright scripts for you” talk. Automation being commoditised isn’t the interesting problem — it’s the given. The interesting problem is what happens to the things automation can’t fix: an AI agent doesn’t ask a clarifying question when a requirement is ambiguous, it makes a plausible guess and ships it, confidently, in the wrong direction. And a good share of what your team currently writes off as “flaky tests” or endless maintenance overhead may not be a framework problem at all — it’s an ambiguous requirement wearing a flaky-test costume, a test that encoded a wrong assumption and is only now diverging from reality.

Drawing on nine months building a real production application entirely through AI pair-programming — including the regression pipeline that runs on every release (Playwright for UI, Python/curl for the API, pytest for units, a mandatory security scan across every action) — I’ll show what changed when coding dropped to roughly a tenth of the effort and specification and verification became the other 90%. That includes a live look at systematic requirements analysis running against my own product today, and exactly what it found hiding inside one ordinary-looking sentence.