Agree, and I'd add a caveat: the loop is only as good as the verifier, and agents are very good at finding the gap between "passes the check" and "is correct." Some things I've seen when the verifier is weak:
If the same agent writes the tests and the code, it will happily weaken an assertion, add a skip, or special-case the fixture to get to green. I keep test files read-only for the implementing agent, or have a separate pass write tests from the spec before any code exists.
Mutation testing is a cheap check on whether your tests constrain anything at all. If you can flip a comparison and the suite still passes, the agent's "all tests pass" means very little.
Property-based tests and differential checks (compare against a reference implementation or the old version) hold up much better than example-based tests the model can pattern-match against.
On the screenshot harness: pixel diffs get noisy fast. What worked better for me was dumping the accessibility tree or DOM state alongside the screenshot and asserting on that, with the image as a secondary signal for the model. Fixed viewport, fonts and animation disabled cut flakiness a lot.
Also, verification only covers what you thought to check. Veracode's 2026 update on LLM-generated code had syntax pass rates above 95%, but only about 55% of tasks produced secure code. "It compiles and the tests pass" was true, and the security property just wasn't in the loop. Math has an edge here: a Lean proof that checks really is a proof of the stated theorem, so the remaining risk sits in formalizing the statement. Programming has no equivalent unless you specify everything.
On your last question, I suspect many fields will get partial verifiers (simulators, unit checks on physical quantities, citation checks, reproducible pipelines) rather than a full oracle. Then the human work moves to deciding what the verifier misses, which is roughly what code review is turning into already.