As coding agents take on more of the implementation work, one thing gets easy to miss: the system that made the change should not be the only system deciding whether the change is correct.
That is partly a trust problem. A coding agent can be very good at producing code and still misunderstand the intent, miss an edge case, or confidently explain why its own work is fine.
The verification layer should be independent. It should start from what the product is supposed to do, exercise the actual application, and compare the result with an observable outcome. That gives the team a separate source of evidence instead of another opinion from the same agent.
What changes in practice
Testing moves closer to the change itself. Instead of waiting for a broad regression suite later, teams can ask what this change might affect, run the relevant checks, identify missing coverage, and explain failures while the context is still fresh.
It also changes where people add the most value. Humans do not need to watch every automated step, but they still matter when intent is unclear, tradeoffs are real, or the system is not making forward progress.
The interesting problem is no longer just whether an agent can build something. It is whether another system can produce enough independent evidence for a person or team to trust what was built.