I could, before LLM-authored PRs. They broke all my heuristics for what to check. LLMs can write code that looks incredibly professional and well thought out, and nowadays they almost never make the usual human mistakes (like off-by-one errors). But at the same time, they can make incredibly silly mistakes of the kind people would never make (like inventing brand-new parameters for some remote API call).

It feels like everything I’ve learned over the years about reviewing code no longer applies.

[Disclaimer: I do work on AI at Google, but nothing related to Search, so this is my subjective personal opinion, not based on any first-hand knowledge of this specific case.]

I think these are simply people who cannot believe that someone might give out an email address they do not actually own, either because they are confused or because they make one up on the spot just to fill in a required form field. So when they receive messages intended for someone else but addressed to another variant of their own address, they treat that as proof that the intended recipient owns that variant. In reality, people giving out email addresses they do not own is extremely common.

I see a lot of people swearing up and down that they have seen proof that such a Gmail bug exists. But whenever you dig into the details, it turns out that all they have actually seen is emails intended for someone else arriving in their inbox. There is never any direct evidence that two people were able to register two Gmail addresses that normalize to the same canonical address.

I registered my Gmail account very shortly after the invite-only public beta began, so my Gmail username is simply my first name (in this example, it would be john@gmail.com). Believe me, I know a thing or two about confused people giving out email addresses that don't belong to them.

Importantly, the dot-normalization rule was there from the very beginning. You learned about it alongside all the other kooky ways Google had decided to reimagine email, including 1 GB of storage, conversation threading, and an interface with a prominent "Archive" button but no visible "Delete" button.

And the choice of whether to use tabs or spaces does not affect semantics. It is purely a matter of style. Indentation using tabs and indentation using spaces work in exactly the same way.

Worse, sometimes you would start working on a project without having that discussion first, only to discover a few days later that the code was failing because different people had different indentation settings in their IDEs, both regarding tabs versus spaces and the number of spaces. You would then have to pause the work, go back, have the discussion, and decide who was going to fix all the code committed so far.

This only stopped when linters became popular. They may be a little like vaccines: when they work, you do not see them working, so it is easy to forget what things were like before. But believe me, when they appeared, they were a breath of fresh air. We could finally focus on discussing the work rather than the conventions.

And tabs versus spaces is only one example. There used to be PR discussions about countless style issues throughout the entire lifetime of a project. That was not entirely unreasonable, because a consistent style genuinely makes a project easier to work on. But when every individual convention has to be negotiated by humans, it takes enormous amounts of energy and becomes tedious very quickly.

That’s 100% on the authors for failing to make the default main “hidden” text and the decoy easily distinguishable. The way this is set up is incredibly confusing.