Short answer: An editor can write a test, but it cannot prove the response conforms to the API. A contract-verified workflow checks each response against the schema and flags the field that is silently wrong, so drift is caught at the moment it happens rather than in a flaky test or a staging incident.

The tests an editor writes well

Cursor is good at generating the happy path: arrange a request, assert a status, check a field. This covers the shape the model expects. The gap is that the test asserts the guess, not the contract, so a response that violates the API can pass if the test never looks at the offending field.

What contract verification adds

CheckEditor-written testContract-verified
Status codeYesYes
Specific asserted fieldsYesYes
Undeclared propertiesMissedFlagged
Missing required fieldsOnly if assertedFlagged
Type drift anywhereMissedFlagged

The failure that matters

The dangerous bug is the one the test does not look for: a new property in the response that was never declared, or a field that quietly changed type. Contract verification examines the whole response against the schema, so it does not depend on a human remembering to assert every field.

How the two fit

Use the editor to write the behavioral tests, and use the studio to verify conformance. They answer different questions: whether the code behaves, and whether the response is valid. Both are needed.

This is part of the Powerduck vs Cursor comparison. Next, read local mocking for agents.