{ "archive_path": "archive/1791972334.988906", "base_url": "smallcultfollowing.com/babysteps/blog/2026/10/14/agentic-dev-and-rust", "basename": "", "bookmarked_date": "2026-10-14 10:05", "canonical": { "archive_org_path": "https://web.archive.org/web/smallcultfollowing.com/babysteps/blog/2026/10/14/agentic-dev-and-rust", "dom_path": "output.html", "favicon_path": "favicon.ico", "git_path": "git/", "google_favicon_path": "https://www.google.com/s2/favicons?domain=smallcultfollowing.com", "headers_path": "headers.json", "htmltotext_path": "htmltotext.txt", "index_path": "index.html", "media_path": "media/", "mercury_path": "mercury/content.html", "pdf_path": "output.pdf", "readability_path": "readability/content.html", "screenshot_path": "screenshot.png", "singlefile_path": "singlefile.html", "warc_path": "warc/", "wget_path": "smallcultfollowing.com/babysteps/blog/2026/10/14/agentic-dev-and-rust/index.html" }, "domain": "smallcultfollowing.com", "extension": "", "hash": "16EFZDRT0X0G9E22MT3Q", "history": { "archive_org": [], "dom": [], "favicon": [ { "cmd": [ "curl", "--silent", "--location", "--compressed", "--max-time", "120", "--output", "favicon.ico", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://www.google.com/s2/favicons?domain=smallcultfollowing.com" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-10-14T10:06:17.048334+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1791972334.988906", "schema": "ArchiveResult", "start_ts": "2026-10-14T10:06:16.413600+00:00", "status": "succeeded" } ], "git": [], "headers": [ { "cmd": [ "curl", "--silent", "--location", "--compressed", "--head", "--max-time", "120", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://smallcultfollowing.com/babysteps/blog/2026/10/14/agentic-dev-and-rust/" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-10-14T10:06:17.414213+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1791972334.988906", "schema": "ArchiveResult", "start_ts": "2026-10-14T10:06:17.057144+00:00", "status": "succeeded" } ], "htmltotext": [], "media": [], "mercury": [ { "cmd": [ "/app/node_modules/@postlight/parser/cli.js", "https://smallcultfollowing.com/babysteps/blog/2026/10/14/agentic-dev-and-rust/" ], "cmd_version": "1.0.0", "end_ts": "2026-10-14T10:06:24.053094+00:00", "index_texts": null, "output": "mercury", "pwd": "/data/archive/1791972334.988906", "schema": "ArchiveResult", "start_ts": "2026-10-14T10:06:20.555392+00:00", "status": "succeeded" } ], "pdf": [], "readability": [ { "cmd": [ "/app/node_modules/readability-extractor/readability-extractor", "/tmp/tmpawx4y8nv", "https://smallcultfollowing.com/babysteps/blog/2026/10/14/agentic-dev-and-rust/" ], "cmd_version": "0.0.11", "end_ts": "2026-10-14T10:06:20.545030+00:00", "index_texts": [ "Me, calmly assessing the implications of LLMs for programming language design(ers).As someone who has made a career of programming language design, I definitely have moments of existential dread about the rise of LLMs. I started coding in 5th grade on an x861 that ran at 5MHz, had something like a 5MB hard-disk and 512K of RAM2. Computers were really, really different back then. But honestly, programming wasn\u2019t. For all the advances in IDEs and programming languages and so forth, the basic act of entering code into a file has remained surprisingly constant3 \u2013 right up until a few years ago, when everything kinda turned on its head. That\u2019s been exciting and empowering at times4 but also scary and disorienting. Will my skills in programming matter? What about my skills in programming language design (such as they are)? This blog post is my attempt to answer those questions.So as not to keep you in suspense, let me just give you the conclusion. In short, yes, I believe there will still be a role for humans in programming. And yes, I think that programming language design is still relevant. And, naturally, I also happen to think Rust is a really good fit for agentic development \u2013 but that\u2019s not to say we can\u2019t make it a better fit. And that\u2019s what this post is ultimately about: what makes Rust and agentic development work well, and where we could double down on those strengths.This is a kind of \u201cblog post companion version\u201d of a talk I gave this week at REBASE, part of SPLASH. You might also enjoy the slides from the talk I gave at IWACO, IWACO and Rust: hidden links revealed, which was a bit more of a retrospective (no soundtrack for those, though). In any case, this turned out to be a great conference! Jack Huey presented on the Rust Vision Doc and, quite to my surprise, Steve Klabnik and Dorian Scheidt presented \u201cLLMs as Collaborators in Language Specification and Design\u201d, talking about their process in building out Rue. It was fun to see Steve again. On top of that, there was a ton of great research presented at IWACO in particular. I was particularly taken by the work on Reachability Types and Information Borrowing. I also really liked learning about Hylo Lang, particularly their approach to projections. Clever and cool.Rust is popular in the agentic eraFrom the most important Slack channel at Amazon, #aws-memes.Rust is popular right now. Very popular:Stratospheric among the breakout languages is TypeScript, cropped from the chart and sitting currently at +1200% growth from the prior year. [..]The second most rapid recent growth is in Rust. Meta engineers have written twice as much first-party Rust code so far this year than in the previous 9 years combined.\u2014 David Tolnay (emphasis mine)Some of that is because agents make it very easy to try out new things. And some of that is because Rust has a reputation for being performant and, if it\u2019s just as easy to pick any language, why not pick one that will yield faster execution times?But I think Rust is popular for another reason: because Rust happens to be a really good fit for agentic coding6. Of course, I would, wouldn\u2019t I? The point of this post is (1) to argue for why that is and then (2) to discuss what we might change about Rust to make it work even better.Foundational Software construction with agentsIt seems to me that an effective \u201csoftware factory\u201d will have three pillars:Design: figure out and specify clearly what the code is supposed to do.Construction: author code that does what it is supposed to do.Optimization: optimize the code so that it runs efficiently.None of these pillars are solved, but some have made more progress than others.Rust and optimization: fast by default, knobs when you need \u2019emRust is designed to give \u201cgood performance by default\u201d, making the idiomatic thing typically also be the fastest thing. But another key part of Rust is that you have the knobs to eke out better performance when you need it. You control when something is stack- or heap-allocated and where pointer indirection occurs. If you want to, you can force the layout of your structs to be done in a particular way, or decide where to introduce boxing into your async stack frames. In the limit, you can put in inline assembly.In the past, learning how to \u201ctune the performance knobs\u201d could be a bit of a black art: but agents are making that much easier.7 It turns out that agents are really good at fine-tuning the performance of existing code. For example, people who work on super high-performance cryptographic algorithms used to do so by hand-tuning assembly code. But those people tell me that they are now turning to agents for that same job. More prosaicly, a lot of people building network services are finding that, using a profiler like dial9, agents can quite effectively diagnose async performance pitfalls, like long polls or blocking.Therefore, I think the task for Rust is clear. We keep on with our goal of \u201clow-level enough for a kernel, high level enough for a GUI\u201d. If anything, I think the shift around agents means we can tolerate a bit more \u201cnoise\u201d in the form of explicit calls to clone() or share() \u2013 but not too much, since we still want the \u201chappy path\u201d of the code to be clear and evident8, even as we surface details that are important in specific scenarios (like tracking precisely how many clones you have of a channel endpoint). Combined with a profiler, you get an effective feedback loop to get your code running fast:flowchart LR\n Code -- Benchmark --> Profile\n Profile -- Analyzed by --> Agent\n Agent -- Propose --> PR\n PR -- Improve --> Code\n Reliability is king, as alwaysAs usual though, while a reputation for good performance is what brings people to Rust, what makes them want to stay is a sense that using Rust \u201cjust seems to work better\u201d. The basic theory is that Rust\u2019s type system and guardrails help keep agents on track:rust is a perfect language for agents, given that if it compiles it's ~correct\u2014 Greg Brockman (@gdb) January 2, 2026I think there\u2019s truth in that: languages like Rust, Ocaml, or Haskell all share this \u201cif it compiles, it works\u201d feeling, and I think that agents will benefit from that.Testing is not enough, type systems helpTesting can show the presence of bugs, but not their absence.\u2014 Edsger W. Dijkstra, 1970Agents presenting their work.Writing tests has never been enough to show that your program is correct \u2013 but, with agents, it\u2019s not even close. It happens so often that my first few tests seem great and then the next one goes completely bonkers. Usually bonkers in a way where I cannot even imagine how that bug could have come about. Then I dig in and I realize the agent completely missed the boat on the logic I was trying to express.9This is where a type systems really shines \u2013 particularly an advanced one like Rust. Type systems give you some guardrails that keep the agent on track. In Rust, those guardrails extend beyond simple stuff like \u201cdo all fields have the correct names\u201d and to stuff like never having to close a socket.Type systems are not enough eitherType systems can show the absence of bugs, but not the presence of correctness.\u2014 Me, failing to coin a phrase of equal eloquence10, 2026So yeah, type systems are helpful! But they have inherent limits. A type system is a simple set of rules that, if you follow them, make sure that you avoid (certain kinds of) mistakes. But they don\u2019t tell you that you do the right thing \u2013 only that you don\u2019t do (certain kinds of) wrong things. If you want to go further, you need a proof system \u2013 something that will let you show that richer properties are actively true, not just that you\u2019re avoiding bugs.As it happens, there are a lot of interesting proof tools for Rust, like Verus, Creusot, Aeneas, and Kani. As a starting point, you can prove that your code is panic-free, which will eliminate a lot of bugs, though it is still fundamentally a \u201ctype-checker-like\u201d property (i.e., you avoid doing things wrong). But you can also go further and add assertions that show your code is computing the results you expect.Strong guardrails give better performanceDeplying proofs is not just good for getting code right \u2013 it\u2019s good for getting code fast. This is somewhat counterintuitive, but it\u2019s true. Earlier I mentioned how optimized cryptographic algorithms were now being written by agents. Part of what makes that possible is that cryptographic algorithms have a very clear mathematical definition. This means that you can basically tell the agent \u201cdo whatever you want, as long as you can prove that the code still computes the correct result\u201d. These proofs can be done with theorem provers like Lean or Rocq. The blog post \u201cWhy Lean is faster than Rust\u201d makes the point quite well.For Rust, a good example of this would be around unsafe code. Right now, people are sometimes reluctant to deploy unsafe code even if it might make their code faster because it\u2019s not worth the risk of getting it wrong. And I applaud that effort. But what if you could use a prover to show that your unsafe code is, in fact, safe (i.e., incapable of causing undefined behavior)? Then you\u2019d be free to optimize to your heart\u2019s content.If we are going to prove things, do we need type systems?You might wonder: if we\u2019re deploying a proof system on our code, do we still need type systems? I think the answer is definitely yes. Type systems are infinitely simpler to work with, which is why they are much more popular. Using a type system lets you rule out all kinds of annoying bugs so that you can focus your \u201cproof energy\u201d only on the important stuff.As a simple example of this, consider the following Java code:void setFoo(Bar bar) {\n this.foo = bar;\n assert this.foo == bar;\n}\nWithout seeing more code, it is impossible to prove whether this assertion is true or not! This is because there could be any number of other threads running around mutating this. In contrast, the following Rust code must be true (at least, so long as the Eq operator is reflexive for Bar):fn set_foo(&mut self, bar: Bar) {\n self.foo = bar;\n assert_eq!(self.foo, bar);\n}\nWe know this because the type system of Rust guarantees that &mut self implies a unique reference.This is in fact exactly how Verus works. By trusting the Rust borrow checker to track uniqueness etc, it simplifies the job of the SMT solver, making proof checking must faster and more reliable than it would be otherwise.Where I think Rust should go on reliabilitySo my take is that Rust should double down on if it compiles, it works. As expressive as Rust\u2019s type system is, there are plenty of things that it cannot capture. This includes fairly common things, like this method only reads one particular field or internal references, but also fancy things like \u201cno logging of personally identifiable information\u201d. We should work to lift those limits, giving agents room to prove more complex properties.We also need to improve the experience of integrating a proof tool by working towards an extensible compiler. As cool as the existing Rust-based proof tools are, using them is a janky experience involing annoying macros and pinned compiler versions. We can do better.A north star: No more unsafe codeI\u2019d like to propose a north star for Rust: no more unsafe code. By that, I don\u2019t mean that we never use the unsafe keyword. Rather, I mean that we have the power to prove that all the unsafe code we write is correct and cannot cause undefined behavior. Don\u2019t get me wrong: knowing exactly what code needs to be vetted is a huge step forward, as is normalizing the idea that libraries need to be responsible for protecting their users from undefined behavior via safe API boundaries11. But given agents\u2019 ability to find vulnerabilities, I think we need to up-our-game if we want to stop the steady stream of CVEs.12Design is an open problemBut before you go about proving things or optimizing them, you need to have a clear idea of what you are building. As far as I can tell the state of the art here is basically variations on \u201cmarkdown-driven-development\u201d, developing docs and hoping that agents pay attention.I don\u2019t know how much of a role for Rust there is in this space. I think there are some steps we might wind up taking that could be helpful here \u2013 for example, having ways to separate out interface from implementation so that it\u2019s easier to review the interface in isolation or to see when the agent made changes there.13 Or perhaps just providing betters tools to review that.I also think there\u2019s space for dedicated \u201cmodeling languages\u201d, something that let you iterate quickly with agents on the high-level designs and invariants without having to get into the weeds and read the code. I have more thoughts on this but it merits many blog posts all of its own. For the moment, I\u2019ll settle for pointing you all at this post by Kari Wilhelm, \u201cPrinciples of Anchor Engineering\u201d, which I think does a nice job of describing what it means to pull out the key elements of a design and drive the coding from there.ConclusionWe covered a lot of ground here, so let me put this all together. What makes Rust a good choice for developing with agents?It offers good default perf (why pay more?) and, in conjunction with a profiler, can be tuned as much as you want.The type system gives stronger guardrails, and if you setup your agents right, you can strengthen those guardrails through techniques like new types.And what could make it better, from a language design perspective? Overall, I think it\u2019s very similar to what we were doing, except that the way we weight the tradeoffs is tweaked to account for agents doing the code authoring, and humans focused more on code comprehension:If it compiles, it works \u2013 our type system is our big advantage, we need to make it more expressive and more functional so that agents don\u2019t get stuck trying to work around it!And as an adjunct, establish a North Star: Enable Unsafe code without unsafety by supporting proof, and see the most widely used Rust libraries proven sound.Low-level enough for a kernel, high-level enough for a GUI \u2013 make sure we expose the knobs needed to tune for performance, while also making the code\u2019s intent clear (but don\u2019t worry about golfing the code down to an absolute minimum number of characters).Extensible and versatile \u2013 one of Rust\u2019s great strengths is that, with macros + our type system, we support DSLs and a wide variety of targets. We need to bring that spirit of extensibility into the compiler so we can target more styles of development (e.g., GPU, deep language interop, etc) and also integrate theorem provers and other tools that require more than just tokens.As a final close, let me point you at this interesting article by Marc Brooker, \u201cWhat\u2019s easy now? What\u2019s hard now?\u201d. He posits that the more it is possible to clearly specify success criteria for a task, the easier it is, and that we may find that tasks we traditionally think of as \u2018hard\u2019 (e.g., building out an efficient implementation of a cryptographic algorithm) may soon become automated, whereas tasks that we have thoght of as \u2019easy\u2019 (e.g., making a unique, compelling website) may become more valued.Looking at it from a PL point-of-view, I think Marc\u2019s point reinforces my sense that the biggest action is going to come from design languages, things that let you capture the architecture and intended behavior at a very high-level. The goal would be to let humans intuitively specify a design that gets translated into effective guardrails, whether that\u2019s type system checks, lints, or theorems to be proven. Agents would then take on the task of translating the design into code written in a traditional PL like Rust, with humans looking at it only rarely. This doesn\u2019t make the design of traditional PLs less interesting, but it definitely makes the tradeoffs very different than they were before." ], "output": "readability", "pwd": "/data/archive/1791972334.988906", "schema": "ArchiveResult", "start_ts": "2026-10-14T10:06:18.723491+00:00", "status": "succeeded" } ], "screenshot": [], "singlefile": [], "title": [ { "cmd": [ "curl", "--silent", "--location", "--compressed", "--max-time", "120", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://smallcultfollowing.com/babysteps/blog/2026/10/14/agentic-dev-and-rust/" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-10-14T10:06:18.716290+00:00", "index_texts": null, "output": "What agents mean for Rust (and vice versa) \u00b7 baby steps", "pwd": "/data/archive/1791972334.988906", "schema": "ArchiveResult", "start_ts": "2026-10-14T10:06:18.701331+00:00", "status": "succeeded" } ], "wget": [ { "cmd": [ "wget", "--no-verbose", "--adjust-extension", "--convert-links", "--force-directories", "--span-hosts", "--no-parent", "-e", "robots=off", "--reject=js,mjs,woff,woff2,ttf,otf,eot,mp4,m4v,mov,webm,ogv,mkv,avi,flv", "--timeout=120", "--restrict-file-names=windows", "--page-requisites", "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) wget/GNU Wget 1.21.3", "--compression=auto", "--timestamping", "https://smallcultfollowing.com/babysteps/blog/2026/10/14/agentic-dev-and-rust/" ], "cmd_version": "GNU Wget 1.21.3", "end_ts": "2026-10-14T10:06:18.687955+00:00", "index_texts": null, "output": "smallcultfollowing.com/babysteps/blog/2026/10/14/agentic-dev-and-rust/index.html", "pwd": "/data/archive/1791972334.988906", "schema": "ArchiveResult", "start_ts": "2026-10-14T10:06:17.423826+00:00", "status": "succeeded" } ] }, "icons": null, "is_archived": true, "is_static": false, "latest": { "archive_org": null, "dom": null, "favicon": "favicon.ico", "git": null, "media": null, "pdf": null, "screenshot": null, "singlefile": null, "title": "What agents mean for Rust (and vice versa) \u00b7 baby steps", "warc": null, "wget": "smallcultfollowing.com/babysteps/blog/2026/10/14/agentic-dev-and-rust/index.html" }, "link_dir": "/data/archive/1791972334.988906", "newest_archive_date": "2026-10-14T10:06:20.555392+00:00", "num_failures": 0, "num_outputs": 6, "oldest_archive_date": "2026-10-14T10:06:16.413600+00:00", "path": "/babysteps/blog/2026/10/14/agentic-dev-and-rust/", "schema": "Link", "scheme": "https", "snapshot_id": "5d2add3f-c924-4c38-8c29-b9694d0b822c", "sources": [ "/data/sources/1791972334-import.txt" ], "tags": null, "tags_str": "", "timestamp": "1791972334.988906", "title": "What agents mean for Rust (and vice versa) \u00b7 baby steps", "updated": "2026-10-14T10:06:16.413117+00:00", "updated_date": "2026-10-14 10:06", "url": "https://smallcultfollowing.com/babysteps/blog/2026/10/14/agentic-dev-and-rust/" }