As coding agents take on more implementation work, it gets easier for the system that made the change to also be the system explaining why the change is correct. That context is useful, but I would not want it to be the only evidence.
A coding agent can misunderstand intent, miss an edge case, or carry the same blind spot into its review of the work.
I want the checking step to start from expected behavior, run against the real application, and produce something observable: the test passed, the page behaved a certain way, or the API returned the expected result.
Where testing fits
Testing also needs to move closer to the change. Instead of waiting for a broad regression suite later, a team can look at what changed, run the checks that matter, spot gaps in coverage, and explain failures while everyone still remembers what they were doing.
People still matter when intent is unclear, tradeoffs need judgment, or the automated loop is stuck. The routine checking can happen in software as long as the evidence stays understandable enough for a person to trust.
That is the part I keep coming back to as coding agents get better: the faster they can make changes, the more useful it is to have an independent way to verify the result.