I've been an advocate for Rust for years, both as a hobbyist and as a professional, to the degree that I regularly link US federal memos on memory safety into the work Slack. My workplace involves systems that have lots of lithium batteries, dangerous actuators, high speeds, etc. so these risks really aren't hypothetical!
At this point I'm the sole maintainer for several Rust codebases of reasonable size and complexity: a Bevy roguelike targeted to in-browser WASM, an in-memory database for game unit data queries, a machine learning bot for playing Battletech matches, and most recently a PDS implementation for agents.
I've also hand-written less than 5,000 lines of Rust in my entire career.
Software is an ecosystem
I've used Python for well over a decade and could rattle off all kinds of trivia about .pth files, wheels, metaclasses, you name it.
But for most of my career, I've been on DevOps/platform/SRE teams. This means that I read vastly more code than I write, especially in the context of incident response. It's common to be asked to provide support for software I've never even heard of, and to be expected to debug it better than the current owner can.
This puts me in an interesting position relative to Python engineers I work with. I often have more experience with the language and the ecosystem, so in some sense I'm an "expert". Yet I almost never write interesting large-scale programs in Python, because my job is to support other people doing that.
Context windows
What I find is that I often have something to contribute, but that it's rarely fruitful to tell anyone the nuts and bolts of how to do their job. That's because the act of doing something matters: the way in which regular Python authors interact with Python is simply different from my interactions with it at a remove. I may have more factual knowledge about elements of Python, but even with fewer years of experience, they have vastly more experiential knowledge. They live in our specific codebase and problem domain, while I am just a guest.
Increasing availability of agents means that a lot more people are now inheriting these working conditions of having to figure out what's up with an unfamiliar codebase. Yes, there are managerial and product management elements to agents too: but if you have a "software factory" you're also the technical point of contact if the machines ever jam.
That doesn't necessarily mean you jump in to write the "hardest parts of the code" for the agents. In fact, I'm not at all qualified to do that in Rust! The role is to manage the overall process of fixing the technical problem, and that's where deep knowledge matters.
Invasive species
But what happens if you don't have deep knowledge?
I have heard horror stories about agentic participation in software ecosystems, notably Rust. Essentially: it's now so easy to make something that works that you can simply ignore intended patterns for working with systems. And then when something does break down the line, you file a bunch of issues blaming or completely refactoring the upstream systems. And then fork the entire project or even rewrite it in a new language.
This is all very antisocial and entitled, and right now it harms the ecosystem. But also? I think the current transition period will settle into a new equilibrium, like how invasive species may naturalize, or gain predators that check their growth. As the meta settles, this kind of behavior will increasingly be outcompeted by people who know what they're doing.
Learning how to learn
Deep knowledge of a software ecosystem might benefit from programming talent, or writing lines of code, but it doesn't strictly require it. What it really needs is a lot of actual experience iterating on and shipping things, intentional effort, and above all social relationships. You can't fit even a moderately sized software ecosystem all in your head! Your interactions with others are how you develop instincts for what to prioritize, prune, defer, or delegate during your education.
No, I haven't written many Rust programs: but I've followed the language's developments for years. I engage with active users, read a ton of blog posts, follow CVEs, and dive into project source. I have prior experience with similar languages and systems and concepts. It's all a natural extension of two decades of prior education where I've always leaned towards systems and safety.
So am I a Rust developer? I don't know, maybe: but if I am it has nothing to do with owning agentic codebases, and if I'm not, writing more Rust wouldn't necessarily be the thing to do it! After all, some of the worst Rust code I've ever seen was proudly hand-authored by humans.