Hey Reader,,

Theo asked a question this week that’s been sitting in the back of every developer’s head: how much better do the models have to get before you stop reading the code? It’s been going on for days, but I honeslty love it. We are talking about verification and quality! Although the initial question might not be the right one. Reading was never the goal, it’s one tactic for earning the right to ship something. If reading is the sharpest tool you’ve got, read. If you have something better, a good AI code review, a test that actually pins down intent, use that instead. The question isn’t whether you read the code. It’s whether you verified it.

Kilo seems to be building toward that second option. They proposed REVIEWS.md, a repo-level standard that hands a review agent your project’s actual coding conventions, architecture decisions, and team norms before it opens a single diff. That’s a more honest bet than piling on extra reviewers, which I pushed back on a few weeks ago. Better context beats more opinions, whether the reviewer is human or not.

I’ve been circling the same question from a completely different angle. At a QA meetup recently I asked the room to imagine a world with no test automation, nothing to point a browser script at, no pipeline handing you a green checkmark. Where does quality actually get decided in that world? It turns out almost never in the test run. It’s in a PR comment asking “wait, what happens if this is empty,” in someone remembering the incident from eight months ago, in a hundred small judgment calls that never touch a dashboard. The checkmark was always a proxy. A convenient one, but still a proxy.

Kent Beck wrote an amazing piece: We’re accumulating code faster than we’re accumulating trust. Trust builds slowly and evaporates instantly, and once it’s gone there’s no negotiating your way back. Kent is the author of Extreme Programming, which he reframes in his post as trust factory, because pairing, continuous integration, weekly planning, and refactoring do double duty: they build trust with the people around your work, and doing them honestly is what makes you trustworthy in the first place. Vibe coding skips exactly that part. You keep the code and lose everything that would have made anyone believe it.

My friend Andy Knight, who’s been solving test automation problems under the AutomationPanda name for longer than I can remember, just put out a LinkedIn Learning course on Playwright with AI agents. He walks through Playwright’s planner, generator, and healer agents, and how to keep what they produce something you’d want to maintain rather than something you dread opening.

If you’d rather do something like this live, Packt is running Orchestrating AI-Native Testing with Playwright this Wednesday with Ivan Davidov and Debbie O’Brien, on the architecture that keeps AI-assisted tests production grade instead of just fast to write. Code fill50 gets you half off.

None of this settles Theo’s question, and I don’t think it’s supposed to. What Kent Beck’s piece makes clear is that trust was never going to come from one lever, reading code included. It comes from stacking the boring practices, pairing, review, the test that actually pins down intent, until they add up to something you can rely on without checking twice. Andy’s course and the Packt session are exactly that kind of practice, a way to get better at earning trust rather than a shortcut around needing it. So my answer to Theo isn’t a model version or a year. It’s that I’ll keep reading exactly as much as it takes to trust the change, and stop the moment something else does that job better.