You Are Not Google (the original link wouldn't load for me so using the Wayback Machine) was written at a very different time in the software engineering career's lifecycle (Java 8 was the latest and greatest). The main takeaway of the blog post is:
If you’re using a technology that originated at a large company, but your use case is very different, it’s unlikely that you arrived there deliberately
At the time, this meant thinking hard before choosing a technology that might complicate your system. A company just finding its feet shouldn't be thinking about optimizing their Cassandra cluster, or how to tune their event bus, or the micro-performance changes to how items are rendered on a page. These are cool topics that get blog posts, but they don't provide value on their own.
But there's the other side of this blog post. Google figured out MapReduce because they had to. They built their own code repository system because they had to. They even built their own build tool because builds were getting too large and too complex. Google's systems could not physically scale to meet the needs of the team, so the team invented tools that could.
Google has BigTech problems.
Recently, I've heard people complaining about git not scaling. I've seen it on blogs, X, even Instagram of all places. Cursor/SpaceX even has a product that is "GitHub for agents." There are real problems working with existing code management systems at the speed at which LLMs can pump out code, yes. If you're not willing to change your current workflows and practices, your system (likely GitHub) will start to fail you. Pull requests stack up and merge queues (and times) grow longer. Agents fight conflicts with other agents. Tests build on each other to take longer and longer. The system physically can't keep up. You need to build something new.
You have BigTech problems.
Coding agents promise to bring the productivity of 5, 10 or 100 people (pick your favorite claim) into the fingertips of just one. More than anything, they make it easy for one person to work on many tasks in parallel. But when you have one hundred engineers each working on 10 things at once, that's suddenly the equivalent of 1,000 engineers' output hitting your system. If you didn't plan for that, if you didn't think about the processes your team follows, if you didn't plan out what everyone is working on to minimize the chances of conflicting work, if you didn't spend time working on your build infrastructure, if you didn't keep your tests fast and meaningful, ...
You gave yourself BigTech problems.
But the teams that adapted their processes as their system's limits changed, that planned and coordinated, that treated build times and test suites as real infrastructure... you know what they have?
Normal tech problems.