If you ask a model for code and for tests in the same breath, you often get tests that repeat the implementation. They pass because both sides share the same mistake. Write the tests, or at least the list of cases, before the implementation exists.
Four cases are enough for most functions. The ordinary input you actually expect. The empty or zero input. The boundary just inside the limit and the boundary just outside it. One failure: missing data, a refused permission, a timeout. If the function talks to anything else, add one case where that dependency fails and the caller must hear about it.
Phrase each case as an observable result, not as a line of code. “A blank name is rejected and nothing is saved.” The model can then write the test, but it cannot quietly change the result to match a convenient implementation. When a test fails, decide whether the case was wrong. Do not let the model delete the case to make the suite green.
A test you did not read is not a test. Open the assertion. If it only checks that a function was called, it is a sketch. Push it until it checks the value a user or a caller would notice.