Carl from The Internet of Bugs made a great video about The Biggest Lie in A.I.

A.I. companies repeat the claim that “this is the worst A.I. will ever be” and that’s simply not true. As Carl notes in the video, with the release of ChatGPT-5, it’s clear that it’s not an across the board improvement over ChatGPT-4.5.

Hardware tends to improve over time: gets faster, does more in parallel.

But LLMs are software, and software doesn’t have that track record.

As the old saying goes: “Grove giveth and Gates taketh away.”

Spiro Sideris writes:

To write understandable code, always ask the question of who your audience is. What level of experience do they have? What are the prerequisites they should know before reading this function? There are even differences in the semantics between programming languages, so knowing the best practices, and the language coding style, will ensure you are writing readable code for developers in that language.

Rule 1. You can’t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don’t try to second guess and put in a speed hack until you’ve proven that’s where the bottleneck is.

Rule 2. Measure. Don’t tune for speed until you’ve measured, and even then don’t unless one part of the code overwhelms the rest.

Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don’t get fancy. (Even if n does get big, use Rule 2 first.)

Rule 4. Fancy algorithms are buggier than simple ones, and they’re much harder to implement. Use simple algorithms as well as simple data structures.

Rule 5. Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

Sam Schillace writes:

I was talking with the engineering team at Box about what I’ve learned along this journey, and what came out of that conversation were my personal engineering principals. These aren’t rules or engineering guidelines. They’re simply the principles that I pay attention to when I write and operate code.

These include:

• Be paranoid.
• Don’t lie to the computer.
• Keep it simple.
• First rule of optimizing: don’t.
• Don’t just fix the bug; fix all possibility of it ever happening again.
• Question assumptions constantly.
• Think long term. Slow down, it goes faster.
• Care about your code.
• Cheap, fast, right — pick two.
• Conclusion: Be curious. Learn as much as you can, all the time.

Jim Bird writes:

Using run-time flags like this isn’t a new idea, certainly not invented at Flickr or Facebook. Using flags and conditional statements to offer different experiences to different users or to turn on code incrementally is something that many people have been practicing for a long time. And doing this in mainline code to avoid branching is in many ways a step back to the way that people built software 20+ years ago when we didn’t have reliable and easy to use code management systems.