idoco

Great video. I was about to share it here myself.

I love Asianometry! The semiconductor history videos are incredible. The level of quality on that channel just blows my mind. It’s one of the best examples of the revolution happening in high-quality, independently produced content.

I actually first heard about it from the Acquired podcast, which is another great example of that same trend.

I get the frustration, but I think there’s a hidden assumption in this discussion: that everyone can write well in English.

Only about 5% of the world’s population are native English speakers, but more than twice that number use it daily. For many, AI rewriting isn’t about losing personal style—it’s about making sure they can communicate clearly in a language that isn’t their first.

It’s fair to dislike how AI flattens unique voices, but for a huge part of the world, it’s not erasing personality—it’s making participation possible.

Absolutely with you on the need for high-impact tests. I find that humans are still way better at coming up with the tests that actually matter, while AI can handle the implementation faster—especially when there’s a human guiding it.

Keeping a human in the loop is essential, in my experience. The AI does the heavy lifting, but we make sure the tests are genuinely useful. That balance helps avoid the trap of churning out “dumb” tests that might look impressive but don’t add real value.

Totally agree, especially about the need for well-architected, high-impact tests that go beyond just coverage. At Loadmill, we found out pretty early that building AI to generate tests was just the starting point. The real challenge came with making the system flexible enough to handle complex customer architectures. Think of multiple test environments, unique authentication setups, and dynamic data preparation.

There’s a huge difference between using an LLM to crank out test code and having a product that can actually support complex, evolving setups long-term. A lot of tools work great in demos but don’t hold up for these real-world testing needs.

And yeah, this is even trickier for higher-level tests. Without careful design, it’s way too easy to end up with “dumb” tests that add little real value.

It reminds me of a similar cooking technique in Israeli Armored Corps called Transmission Spam.

We used to place a can of spam on the tank's gearbox before a long drive, and by the time we reached our destination, the spam was heated up and ready to eat.

That is why DIY is usually more expensive than managed services. Engineering hours are expensive and best spent on your core competencies.

DIY only make sense at a very small scale or very large scale, everything in between is usually best offloaded to those which do it as their core competency.

I see OpenTelemetry as an application of the same idea pushed by Google via the k8s revolution.

Create a great vendor-agnostic open source tech. Get everyone riled up about the dangers of vendor-locking solutions. Use the new tech to carve yourself a piece of the market from the current incumbent.

It is pretty great and all, but sometimes it is easier to build your app with a simple vendor-locked tech than a super generic agnostic technology.

That is a very good point. Security crawlers should probably use a masked user-agent.