AI Will Multiply Your Code Output. It Will Also Multiply Your Liability

Your embedded engineering teams are about to ship more code, faster, than at any point in your company’s history. AI assistants already write a meaningful share of new software in the enterprise world, and that trend will shift to the embedded and high-integrity world as well, without question. This may read like pure upside: more output, lower unit costs, faster time-to-market; however, it is critical to keep safety and security in mind as well.

If your teams write in memory-unsafe languages such as C and C++, AI will not only accelerate the good code. It may also increase your attack surface, at machine speed, in systems where a single defect can mean a recall, a grounded fleet, or a fatality.

The risk you are scaling is well documented

Memory-safety errors are not an edge case. Microsoft and Google have each reported that roughly 70% of their serious security vulnerabilities stem from memory-safety problems, a figure consistent enough that the U.S. and allied cybersecurity agencies built formal guidance around it. In June 2025, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA) jointly urged manufacturers to adopt memory-safe languages and eliminate these defects at the source.

In automotive, aerospace, and defense, this is not only a security story. The same class of error drives functional-safety failures, certification delays, and warranty exposure. AI that writes more C writes more of exactly the problem regulators are now telling you to remove.

And yes, modern C++ has more memory safety features built in; however, there is no enforcement, and a small mistake can still have a big impact.

Memory-safe languages change the economics, not just the code

The strategic response is to move high-integrity work onto languages where whole categories of defects cannot occur. The evidence is concrete. When Google's Android team shifted new code to a memory-safe language, the share of memory-safety vulnerabilities fell from 76% to roughly a quarter over five years.

A language such as SPARK, a verifiable subset of Ada used in flight control and rail systems, goes further. It does not ask engineers to avoid dangerous constructs by discipline. It removes them and lets tools mathematically prove that errors such as buffer overflows and uninitialized data cannot happen. The business translation: defects that would otherwise surface in test, in the field, or in an attacker's hands are prevented before code review.

This is not an all-or-nothing decision

You already have code, probably lots of it. You do not want to spend time converting it all, and you do not have to. You can start by writing new code in SPARK to make your new features stronger. And then, you can review your existing code and convert high-risk components to SPARK. Interesting side point: AI is actually very good at taking existing code, converting it to SPARK, and proving the absence of runtime errors.

SPARK integrates very well with C and C++, making calls across the SPARK to C interface is easy, and there are well-known patterns for handling C++ to SPARK, for example, GNATpolyglot by AdaCore.

Your developers will appreciate it

Current approaches to memory safety in C and C++ typically revolve around MISRA. Nobody likes writing MISRA-compliant code; it is additional work and very tedious. Many of the rules in MISRA are not needed in SPARK; they are moot, have a look at the developer-focused article that explains this in further detail.

The competitive question

The agencies have signaled the direction. Your competitors are reading the same guidance. The differentiator will not be whether you adopt memory-safe languages, but whether you do it as a coherent platform that compounds across programs, or as scattered projects that never repay the learning curve.

This is also where a vendor relationship earns its keep. A partner such as AdaCore covers a broad range of the targets these divisions ship on, which simplifies procurement, and its thought-leadership team can sit with yours on strategy before a technology shift becomes a technology problem. As your tools change and AI reshapes how code is produced, that forward visibility is itself a form of risk reduction.

The decision in front of you

The question to bring to your next staff meeting is not whether AI will increase your output. It will. The question is whether your current language and tooling base lets you scale that output without scaling your liability in lockstep. If it does not, the follow-on question is sharper still: would you rather fix that once, as a platform, or repeatedly, one program at a time?