The more I have my code reviewed (and self-reviewed) by AI, the more confused I get: how did we not think of some very basic sanity rules before?

Okay, memory safety is a difficult one. Heck, null safety alone is difficult. I'm on the Rust train now, and I cannot possibly imagine building a non-specialized, non-high-load system in a language that doesn't offer these safety guarantees. But I won't judge here.

What I 𝘢𝘮 tempted to judge is data structures and data storage patterns. A 𝙷𝚊𝚜𝚑𝙼𝚊𝚙 storing in-flight requests is clearly an attack surface, duh. So, very often, what we truly need is a version of a 𝙷𝚊𝚜𝚑𝙼𝚊𝚙 that will quietly throw an exception of a known type once it holds more than 𝙽 elements. Or once its total footprint in memory exceeds approximately 𝙼 megabytes.

In fact, this 𝙷𝚊𝚜𝚑𝙼𝚊𝚙 is best coupled with a queue. An actor, if you wish. So that the default behavior is: proceed if an empty slot opened up within 𝚃 = 𝟻𝟶𝟶𝚖𝚜, otherwise fail with what silently becomes a 𝟺𝟸𝟿 𝚃𝚘𝚘 𝙼𝚊𝚗𝚢 𝚁𝚎𝚚𝚞𝚎𝚜𝚝𝚜 behind the scenes.

Then, the queue is best made a priority queue. So that some QoS is built in right away. If user traffic is throttled, admin traffic should still go through. For instance, traffic coming from 𝚕𝚘𝚌𝚊𝚕𝚑𝚘𝚜𝚝, or traffic signed with an admin key. Makes perfect sense, right?

Furthermore, I've seen plenty of client-side JavaScript that uses cookies and 𝚕𝚘𝚌𝚊𝚕𝚂𝚝𝚘𝚛𝚊𝚐𝚎 wrong. Sometimes the user's machine is out of disk space, you know? And your page should either load in full (best), or show a nice, lightweight popup saying the machine needs to free up some space to continue. I've seen all sorts of disk-full failures these days — most of them should simply never exist in the first place.

Point is, we're about to be writing more code, and this code will be safer — but it's a long way to get there. Our commonly used tools are still largely inadequate, and they will need an upgrade.