The rapid adoption of AI-assisted coding is reshaping how software is produced and deployed. In 2026, AI-assisted coding is no longer confined to startups and hobbyists. It is embedded across the software industry, from companies like Google and NVIDIA to financial institutions, cloud providers, and increasingly, government agencies. AI systems are used to generate boilerplate, refactor legacy code, write tests, and generally accelerate development. AI assistance is simply part of the standard development environment now, and no longer a separate workflow or experiment.
As security expert David Mytton (founder and CEO of security provider Arcjet) and many others have argued, this shift introduces a new category of risk. That risk is not primarily driven by obviously bad code, but rather by insufficient human oversight and a lessening of understanding what is actually being shipped. The danger is not that things fail loudly, but that they fail quietly while appearing to work.
So, the problem isn't that AI-generated code typically fails outright. That might actually be preferable. Instead, the code often appears correct enough to deploy while quietly embedding assumptions, edge cases, or security weaknesses that have not been examined. Its “correctness” is inferred from surface behavior rather than established through strong constraints, formal guarantees, or deep review. When this pattern is applied to security-sensitive or foundational systems, the consequences can be serious as well as difficult to trace.
Even Linus Torvalds has said that AI-assisted coding can be appropriate for prototypes, experiments, and for helping beginning programmers get started. I agree completely. Risk escalates when this relaxed posture is applied indiscriminately to production systems. In those environments, failures are not only more damaging, they are often silent and cumulative. Bugs do not announce themselves immediately; they accumulate, interact, and surface later under conditions no one explicitly tested for.
These risks are well-known and widely discussed. But AI-assisted coding makes invention cheap, fast, and persuasive. The economic incentives are obvious: fewer developers, shorter timelines, and code that looks complete and confident at a glance. There are no signs that this approach will be abandoned. As a result, it seems increasingly likely that unverifiable or under-verified designs will make their way into production as a matter of course, not because teams are careless, but because the surrounding systems have come to reward speed and plausibility over deep certainty.
I believe that programming language choice can meaningfully mitigate this risk by acting as a form of constraint. Dynamic, permissive languages such as Python, JavaScript, Ruby, and PHP sit at the higher-risk end of this spectrum. They allow code to run with minimal upfront validation, pushing most errors to runtime. With AI in the loop, this makes it easy to deploy code that appears correct but fails under specific conditions. JavaScript adds further risk through implicit type coercion, complex asynchronous behavior, and a vast dependency ecosystem.
C and C++ present a different, but equally serious, risk profile. Although compiled and statically typed, they do not enforce memory safety or prevent undefined behavior. This is widely acknowledged, but they're embedded everywhere in our modern infrastructure and working with them is inescapable. Historically, their risks have been mitigated by highly skilled developers who know where to look and what to distrust. The concern with AI-assisted coding is that without such oversight, compilation success becomes an even weaker signal than it already was. Code may build cleanly while containing latent vulnerabilities such as buffer overflows or use-after-free bugs that remain dormant until exploited or triggered in production.
Languages like Java, C#, and Go occupy a middle ground. They enforce stronger structure and surface more errors early, but they still allow logic errors, insecure defaults, and subtle misuse of APIs to pass through compilation. They reduce certain classes of failure, but they do not eliminate the need for careful review and domain expertise.
At the lower-risk end are languages such as Swift and Kotlin, which enforce stronger type systems, null safety, and safer defaults than many of the older languages. These features act as friction, forcing developers and tools alike to be more explicit about intent.
Many argue that Rust currently represents the most risk-averse option available. Its strict compiler enforces invariants around memory safety, lifetimes, and concurrency that cannot be bypassed accidentally. Entire classes of errors are made impossible, or at least extremely difficult, to express. While this does not prevent logic or design mistakes, it dramatically reduces the space for silent failure.
I have some experience with Rust and its compiler’s strength in providing robust code and useful, actionable error messages. It is genuinely difficult to get bad code through that compiler. But it's not impossible. As part of my recent work testing the limits of large language models, I deliberately asked KIMI to generate flawed Rust code that would still compile. It succeeded. Whether a skilled and diligent Rust developer would have caught the issues is an open question, but I'd say yes, he or she would. That distinction matters.
The broader lesson is that AI-assisted coding is not inherently reckless nor incapable. It becomes dangerous when it is treated as a substitute for constraint rather than being forced to operate within it. AI-assisted coding is viable only where constraints are strong: compilers that fail loudly, test suites that are meaningful rather than ceremonial, limited permissions, and review by skilled developers who understand both the domain and the failure modes of the tools they're using.
In that environment, AI-assisted coding can be both productive and relatively safe. Outside of it, the risk is not dramatic collapse, but gradual erosion of confidence in the systems we rely on.
I spend a lot of time challenging and testing AI models, and my personal conclusion is that this new technology is very powerful and capable of producing solid code. But that doesn't remove responsibility. It changes where that responsibility must be applied. Keeping humans in the loop is simply not optional; it is the only thing that makes systems coherent and the only thing that can keep them that way.
Ben Santora - January 2026
Top comments (0)