Rawen's Musings

Rust; the language, not the survival game. The “successor to C” as seen by a lot of its proponents due to it’s strict enforcement of memory safety, data race prevention and many other code ailments which make programmers’ lose hair on many occasions. The very same language which was seen as the a way to safer code found itself in the storm of disdain due to being extensively used by AI tools. But why this one specifically? How did the language of safety become one of the despised tools since it can indicate a heavy-handed use of AI? Well, if you read one of my previous posts on “AI coding” you can probably put the answer together but let’s take this dive once again.

The chapter I’m referencing is specifically the one about genetic programming or as I jokingly call it “the original vibe-coding” in a little bit of a tongue-in-cheek jab. The way I described it in a rather simple manner, was that it’s basically a highly constrained “randomness-driven” process which can deliver a result satisfying these constraints. The constraints are very much the key to why genetic programming works quite well for the tasks you want to use it for. You know what you want in quite a good detail and you have a way to evaluate the outputs of the algorithms properly and you don’t need to know every single detail of the implementation because the robust and clearly defined verification process ensures the solution is correct.

Now let’s take a look at Rust, specifically one of its core features; the compiler and the rules it enforces. If you ever wrote a piece of code in Rust, you can very much relate to the experience of wrestling with the compiler screaming at you about properly passed mutable references, data races you missed etc. Eventually, you either brute-forced your way with unsafe code, basically demoting Rust into C with some extra features (sounds familiar? *cough cough* early C++) or you “took the beating” from the compiler and eventually learnt to write the code satisfying all the constraints it threw at you.

Now what happens if we replace the human coder with AI? We get an autonomous algorithm working in a highly constrained environment to produce a result satisfying the constraints … wait, that sounds like genetic algorithm. Well, you’re not far off. While the resulting code will be hard to read (remember, going through generated code is a really unpleasant task), it’s very likely it’ll be functional and even reasonably safe. All that because the Rust’s compiler will basically drag the unruly AI, kicking and screaming, towards the right path to go through. It won’t necessarily be the ideal solution or even the most optimal (you’d have to actually employ some more principles from the genetic programming field to get that) but the strict rules will keep the AI in check. This is of course limited to the technical or engineering level of the code and not the usability which would require a whole another set of constraints.

“But Rawi, you could do that with any programming language.” Yes, technically you can do it with any structured language, be it a programming or a mark-up one (natural language is far more difficult due to the amount of possible nuances and indirect meanings). But no matter which one you choose, Rust’s compiler is your very likely minimal benchmark. You need to at least match what the compiler does. And you have to do that as a one person for every single problem you want to “solve” with AI. Meanwhile the compiler is being developed by dozens of people who are experts in field of formal languages, grammars and all the compiler theory.

Are you sure you can match that as an individual? Repeatably and reliably?

R.R.A.