My Concerns of TRACTOR for unemployed developers

Oct 7, 2024

TLDR: TRACTOR is bad for jobs, good for lazy developers.

The content of this post is without a doubt, going to be a controversial take, but it needs to be addressed. It is imperative that we acknowledge the fact that TRACTOR is something that is still being developed, and all the concepts addressed here are all highly theoretical, and the project should be met with a degree of skepticism. The project is only in its infancy stages, and is to change over time; This post is based on theory from factual analysis, it is primarily opinionated on the possible implications for both the job security and labor market for Rust developers, but serves as a critique of the project presented by DARPA that could simply cause the same issues that the project deems to address.

As a reference, I will be sourcing my information from:

  1. Official documentation and qualification details provided DARPA through their listing on sam.gov

  2. Official Rust Documentation, and other studies (linked throughout this post)

  3. Previous implementations of similar desired technologies as a reference to usage of AI and LLM's.

But first, we need to clarify:

What the hell is TRACTOR?

TRACTOR (TRanslating-All-C-TO-Rust) is a project proposed by DARPA (Defense Advanced Research Projects Agency) to translate legacy C code, to Rust. DARPA is the largest technology agencies in the U.S. that works with both the public and privatized sectors of the U.S. to improve national security, and remains as the leading group towards both technological security, and weapons innovations for the United States. (read their about page here.)

At it's core in layman's terms, they are what pivot the tech industries towards new proposed standards, and are comprised of fielded experts working towards the goal of building technology for use within military applications, but also with commercial applications.

DARPA is the group behind ARPAnet— the predecessor to the modern internet, and the TCP/IP protocol that made computer networks possible. In short, they employ the best of the best to develop and deploy technologies that pivot society into new territories.

TRACTOR is a project that was proposed some time in July of 2024 and it's goal is to utilize accurate code generation by Large-Language Models (LLM's) to procedurely generate safe Rust code to replace legacy C code in critical programs.

Why Rust?

Rust is a typesafe language that exhibits similar performance and speed to C that reduces critical bugs with memory management through its borrow-checker. This borrow-checker prevents items (or variables) outside the 'scope' of the stack from being called, or being written to, if the items are not referenced or explicitly mutable (for more reading, see here).

This allows Rust developers to easily write memory-safe programs a majority of the time, as breaking the rules of the borrow checker prevents the code from being compiled. In addition to this, the typesafe features allow for input sanitization at compile time, requiring the developer to check for correct types between function parameters, and failing to compile if any discrepencies occur, however user input will need to be sanitized, but this is easily addressable through match statements, and/or other control flow methods.

This has been a large selling point by both Rust, and Rust developers as it makes the process of generating safe-code much easier than having to worry about both manual and dynamic memory allocation to their software to prevent critical bugs such as buffer overflows. However, as seen in this post, this attack is still possible to perform in Rust, however it takes much more intent to perform a segmentation fault— unlike its C counterpart which provides zero guardrails.

This is because Rust requires the developer to explicitly state the unsafe keyword to designate code that the compiler will explicitly ignore. This implementation of the unsafe keyword not only decreases the possibility of writing code that could lead to very dangerous attack surfaces— but it also serves the point that a developer must explicitly declare the compilation and usage of unsafe code that only as of now, only a human can verify the validity of it's safety.

It's no secret that Rust is a very safe language. Google recently switched to using Rust as part of the Android's development cycle, and saw a 68% drop in memory vulnerabilities from 2019 to 2024 (The Hacker News, Lakshmanan Sept. 2024). However, it is also become a recent topic of debate between C developers and Rust developers over where the line between safety and control should exist.

Are LLMs and AI the solution?


In regards to AI, according to a study conducted by the AI index report, there have been over a 149 total foundation models produced by 2024 alone, (data was gathered from this article produced from Shana Lynch from Stanford University). It's no secret that AI has changed the game for many fields, and it's gone public to the masses. To quote TIME magazine:

Think of it like this. Previous era’s most powerful technologies were generally reserved to a small capital rich elite or national governments. Building a steam powered factory, an aircraft carrier or a nuclear power plant were costly, difficult and immense endeavors.

- Time Magazine (Suleyman, Sept. 2023)

So here's the real question: is AI going to try and replace skilled developers? There are issues with AI that stem outside of the scope of this blog post, but I wish to keep it contained to address issues pertaining to TRACTOR's AI. There was a study conducted by Uplevel that found that software that used AI to assist building it contained 41% more bugs in comparison to code developed without AI. In light of this study, the model will more than likely promote the difficulty in the process of translating C code to Rust.

But how exactly? Consider the unsafe keyword in Rust. There is a ton of legacy C projects that use manual memory mapping in order to efficiently, and replicate very specific functionality. For example, some projects will use very low-level byte manipulation in order to produce an extremely fast operation. Consider a case where this low-level functionality contained a critical vulnerability— if an AI were to try and recreate that functionality in Rust, it will likely need to call the unsafe keyword, and introduce the exact same bug that existed in the original C program.

Although those bugs can be fixed/mitigated, it will still require an on-site developer to identify those bugs, and fix them manually. The biggest issue however, is that it might as well have been written from scratch into Rust as the debugging process still requires an on-site developer. Sure— using AI will cut down the cost of assembling a team of developers to recreate these projects; but then this process then creates a Catch-22:

More people use this tool to push their legacy C code into Rust -> less people become experienced in understanding the intricate details of Rust -> more bugs that could have been caught slip past them.

Additionally, the usage of AI in development spaces creates less jobs of specialization, where in the jobs are critical for maintaining the security, and development of these advanced projects. Not to mention the fact that Rust is a relatively recent and upcoming language, meaning that it and the projects that it produces are updated VERY frequently in comparison to C, which has been around since the 70's.

So as to simplify the situation, we need to ask:

  1. What sources are being used to help generate the training data that these AI are going to be trained on for generating safe and valid code?

  2. Will TRACTOR really be good for security in the long run? What if the model just recreates the exact same bugs from C into Rust?

  3. How will the model handle future additions to Rust? Both Rust, and Rust crates are growing exponentially. The data that the model is currently being trained on might not be applicable in the near future.

Not to mention that the project predicates itself on an ideal scenario, where the following parameters are true:

  • The model is trained on perfect C code, and the code itself is non-malicious, and can be easily translated into Rust with the unsafe functionality that uses both secure-by-design principles and remains optimized for minimal time complexity.

  • LLMs are able to get to a point where all of these issues concerning misinformation, biases, and faulty logic produced from the tokenization process no longer exist.

Genuine concerns for me as a Rust developer.

I have been programming and studying the arcane crafts of computers for 10 years almost. I remember how difficult it was to even find a job related to developing with an embedded language, more or less with an up and coming language like Rust. However, the 2024 BSOD Crowdstrike incident signalled that Rust will be the language of the future; and I hopped onto that train as soon as I could. My biggest concern is that companies will abuse this tool for generating Rust code to take jobs that both me, and many other Rust developers have spent our entire careers towards in order to save on costs; costs that may just intoduce the same bugs that existed prior that still requires a team to manually review in order to fix.

I am against the use of AI in development spaces in general. I think that it's a very expensive gimmick that is great when it comes to learning the basics of a language: the syntax, semantics, and generating simple code, but is lacking in generating large-scale projects. It kills me to imagine that AI is trying to replace so many jobs and there aren't securities in place to protect the livelihoods of those affected by this massive technological advancement. It's tried to take the jobs of warehouse workers, it's tried to take the jobs of screenwriters and actors, and now it's trying to take the jobs of developers. AI should be a tool to assist in the learning process, not as a tool to replace those who require food, living spaces, and money to survive. We cannot let companies use AI as an excuse to decrease wages, decrease employment opportunities, and decrease the ability of well-equipped developers to do our damn job. AI is simply not at the stage that it needs to be to do a very detail-oriented and demanding job. Hell, even if you did implement AI into your workflow, you're not going to change much as we don't live in the perfect world that this project requires us to live in for it to be feasible to completely do the job that it is intended to do.

Me being against it however doesn't negate the idea that this will not be useful. TRACTOR's AI will definitely be helpful for those C developers who abstain themselves from Rust to help secure their projects. There's also the fact that this will definitely decrease the amount of critical vulnerabilities that are caused by the extremely loose type system of C. In embedded spaces— and in military application (which is, let's face it, where DARPA primarily seeks to address) all of this functionality will boost the productivity and security of vital projects.

So what is the solution? What should be the real purpose in the use of TRACTOR's AI? Simply put, it needs to be utilized by C developers who haven't learned Rust. Like how I mentioned earlier: AI is wonderful for learning new concepts fast and quick— getting a foothold with extremely generative AI is something that it does great. But for someone who understands the intricate details of the Rust language; Someone who understands how to translate C into Rust; TRACTOR's AI will be completely useless and cause more issues than it solves.