I think coherency of implementation is a lot more important than YAGNI. For example:

class Car:

def honk(self):
print('Honk!')

Cool, now we have a car, but it only honks. But we only needed it to honk, so that's fine.

class RoadTrip:

def __init__(self, car, destination):
self.car = car

def go(self):
self.car.start()
self.car.drive_to(destination)

Oh no, we built a car but it does nothing that a car does. Let's add this functionality.

class Car:

def __init__(self):
self.started = False
self.gps = []
self.location = cool_app.get_current_location()

def honk(self):
print('Honk!')

def start(self):
self.started = True

@property
def location(self):
return self.gps[-1]

@location.setter
def location(self, new_location):
self.gps.append(location)

def drive_to(self, location):
self.location = location

Super easy. Except a different user of our library implemented this functionality already for a different reason, but in a different way.

class CarEngine:

def __init__(self, car):
self.car = car
self.started = False

def start(self):
if self.started:
raise Exception('Already started!')
self.started = True

def turn_off(self):
if not self.started:
raise Exception('Not started!')
self.started = False

class CarGasTank(self, car):

def __init__(self, gallons):
self.car = car
self.capacity = gallons
self.level = gallons

@property
def empty(self):
return self.level == 0

class MotorCar:

def __init__(self, engine, gas_tank, mpg, location):
self.engine = engine
self.gas_tank = gas_tank
self.location = location
self.mpg = mpg

@property
def started(self):
return self.engine.started

def start(self):
return self.engine.start()

def drive_to(self, location):
distance = location - self.location
fuel_required = distance / self.mpg
if fuel_required > self.gas_tank.gallons:
raise Exception('Not enough gas!')
self.gas_tank.gallons -= fuel_required
self.location = location

I've lost count of the number of times I've seen stuff like this. Sometimes the original implementation is in a different library that's hard to change. Sometimes other code rely on specific details of the original implementation so changing it requires changing that code too. Sometimes additions seem "out of scope" so they are actively pushed to dependencies.

It might feel like this is a process problem -- like there should have been better upfront design or communication -- but these "failure cases" are actually the success cases for code. You want code to rely on your libraries. You want to consider all users of your libraries when making changes.

The problem is actually YAGNI, because that mentality encourages us to churn out big, incoherent bags of functions when we should be thinking about code responsibilities and designing whole systems.

You can see this in action with JavaScript most infamously. Its standard library is extremely YAGNI, and it led to whole new programming languages being built on top of it because it was so anemic. The complexity has to live somewhere, and if you don't deal with it in a coherent and orthogonal way, someone else will have to deal with it and their options will be a lot more limited than yours.

Following simple mantras like DRY, YAGNI, and whatever else fits on a poster is the surest way to mess up your design. It requires thoughtfulness and experience, and there are no shortcuts.