From the screencast: > implement also for Days This fails to recognize that this is a bad feature that the Abseil library would explicitly reject (hence the e

From the screencast: > implement also for Days This fails to recognize that this is a bad feature that the Abseil library would explicitly reject (hence the existence of absl::CivilDay) [0], and instead perpetuates the oversimplification that 1 day is exactly 24 hours (which breaks at least twice every year due to DST). Which is to say: it'll tell you how to do the thing you ask it to do, but will not tell you that it's a bad idea. And, of course, that assumes that it even makes the change correctly in the first place (which is nowhere near guaranteed, in my experience). I have seen (and bug-reported!) cases where it incorrectly inverts conditionals, introduces inefficient or outright unsafe code, causes unintended side effects, perpetuates legacy (discouraged) patterns, and more. It turns out that ML-generated code is only as good as its training data, and a lot of google3 does not adhere to current best practices (in part due to new library developments and adoption of new language versions, but there are also many corners of the codebase with, um, looser standards for code quality). [0] https://github.com/abseil/abseil-cpp/blob/bde089f/absl/time/time.h#L502-L506 https://github.com/abseil/abseil-cpp/blob/bde089f/absl/time/...