Have them first write a "code spec" in the repo with all the interfaces defined and comments that describe the behaviors.

    """
    This is the new adder feature. Internally it uses chained Adders to multiply:
    Adder(Adder(Adder(x, y), y), ...)
    """
    class Adder:
       # public attributes x and y
       def __init__(self, x: float, y: float) -> None:
          raise NotImplementedError()
 
       def add(self) -> float:
          raise NotImplementedError()
 
    class Muliplier:
       # public attributes x and y
       # should perform multiplication with repeated adders
       def __init__(self, x: float, y: float) -> None:
          raise NotImplementedError()
 
       def multiply(self) -> float:
          raise NotImplementedError()

This is a really dumb example (frankly something Claude would write), but it illustrates that they should do this for external interfaces and implementation details.

For changes, you'd do the same thing. Specify it as comments and "high level" code ("# remove this class and switch to Multiplier") etc.

Then spec -> review -> tests -> review -> code -> review.

Depending on how much you trust a dev, you can kill some review steps.

1. It's harder to vibe good specs like this from the start, and prevents Claude from being magical (e.g. executing code to make sure things work)

2. You're embedding a design process into reviews which is useful even if they're coding by hand.

3. It simplifies reviewing generated code because at least the interfaces should be respected.

This is the pattern I've been using personally to wrangle ChatGPT and Claude's behavior into submission.