AI Code Fails Where Quality Matters, C++ Creator Warns

Bjarne Stroustrup isn’t claiming that AI can never produce working software. The creator of C++ is making a more specific argument: code generation has little value when the resulting code is difficult to understand, verify, secure, and maintain.

In a widely shared interview clip, Stroustrup criticized the idea that natural language could replace programming languages. He also argued that AI systems tend to produce bloated code containing bugs and security weaknesses, leaving experienced developers with the unpleasant job of checking an implementation that may change whenever the prompt changes.

The strongest part of his critique isn’t about whether an AI model can complete a coding task. It’s about whether the generated result reduces the total engineering work required to deliver dependable software.

Stroustrup's Critique Is Narrower Than the Viral Clip

2096654149500698761

The viral post says Stroustrup called natural-language programming “idiotic.” The full interview transcript provides an important qualification: Stroustrup attributed that blunt description to computer scientist Edsger Dijkstra. He then agreed with the underlying objection, explaining that English is ambiguous and highly dependent on context.

That distinction matters. Stroustrup wasn’t simply insulting prompt-based programming. He was questioning the premise that ordinary language can replace the precision provided by programming languages, type systems, interfaces, tests, and other formal tools.

He also didn’t say AI is useless for programming. In the interview, he acknowledged that it can write particular categories of code, including relatively standard web applications. His objection concerns software where correctness, security, efficiency, or predictable behavior cannot be treated as secondary requirements.

Stroustrup informally suggested that perhaps 70% or 80% of the world’s software falls into areas where AI-generated code may be acceptable. His attention is on the smaller, technically demanding category:

“It’s that 10, 20% of the code that I’m interested in.”

Those percentages shouldn’t be read as measured market statistics. They illustrate his priorities. C++ is widely used for operating systems, browsers, databases, game engines, embedded systems, financial infrastructure, and other software where memory use, latency, hardware access, and failure behavior can materially affect the product.

An AI-generated administrative dashboard and an AI-generated component controlling medical equipment may both compile. That doesn’t make them equivalent engineering achievements.

Validation Is the Real Bottleneck

AI coding tools make generation nearly instantaneous. A developer can request a class, API endpoint, test suite, parser, database migration, or entire application feature and receive hundreds of lines within seconds.

Reviewing those lines is a different problem.

A patch can compile and pass ordinary tests while still violating architectural assumptions, mishandling rare inputs, duplicating existing functionality, using an inappropriate dependency, leaking sensitive information, or creating a performance problem that appears only under production load. The reviewer must understand both the generated implementation and the surrounding system well enough to find those failures.

This is the basis of Stroustrup’s complaint about senior developers becoming validators for machine-written code. A lengthy AI contribution can force a reviewer to reconstruct design decisions that no human developer consciously made. Changing the prompt can then produce a substantially different solution, restarting part of the evaluation process.

His claim that experienced developers are retiring because they don’t want this work should be treated as a personal observation, not an established labor trend. The interview presents no workforce data supporting it. The underlying dependency is still real: organizations need people with enough domain knowledge to decide whether generated code is actually safe to merge.

Research on AI coding productivity reflects this tension. A METR randomized controlled trial assigned 246 real issues from mature open-source projects to 16 experienced developers. Its original analysis found that developers using early-2025 AI tools took 19% longer, despite expecting AI to make them faster.

METR subsequently updated the analysis after identifying issues involving task-selection filters and incomplete timing data. Its revised central estimate changed from a 19% slowdown to a 4% speedup, with a confidence interval broad enough to include both a slowdown and a meaningful gain. The study therefore doesn’t prove that AI coding tools reduce productivity. It shows how difficult it is to demonstrate productivity gains among experienced developers working in codebases they know well.

Other evidence is more favorable. An NBER working paper covering three field experiments examined 4,867 software developers at Microsoft, Accenture, and another large company. Access to an AI coding assistant increased completed tasks by an estimated 26.08%, with larger gains among less-experienced developers.

These results aren’t necessarily contradictory. AI can accelerate well-scoped implementation work while providing less value in large, unfamiliar, or highly constrained systems. Counting completed tasks also doesn’t automatically capture future maintenance, security remediation, operational failures, or technical debt.

The relevant metric isn’t how quickly code appears in an editor. It’s how quickly dependable software reaches production and remains dependable afterward.

Security Research Gives His Warning Real Weight

Security testing provides stronger support for Stroustrup’s concern about plausible-looking but unsafe output.

Veracode’s 2026 GenAI Code Security Report evaluated more than 100 models released over four years. The average security pass rate was 56%, meaning roughly 44% of generated solutions failed the report’s security evaluation. Veracode also said the overall pass rate had not materially improved, even as models became better at producing functional code.

The report is a vendor-run evaluation, not a neutral measure of all real-world AI development. It uses 80 defined programming tasks and doesn’t establish that 44% of every line generated by AI is vulnerable. It also cannot directly prove Stroustrup’s claims about C++ or safety-critical systems.

It does reveal an important gap between functional and secure code. Models can learn the common structure of a solution without consistently applying input validation, authorization boundaries, safe query construction, output encoding, resource limits, or secure error handling.

C++ adds its own review challenges. The C++ Core Guidelines devote extensive attention to ownership, object lifetimes, bounds, concurrency, resource management, and undefined behavior. A generated function can look idiomatic while containing an invalid reference, race condition, integer conversion bug, or assumption about memory that fails only in a particular build.

Performance-critical programming introduces another category of hidden requirements. A function can produce the right answer and still allocate too much memory, disrupt cache locality, block an important thread, prevent vectorization, or create unacceptable tail latency. Those properties must be measured within the real system. They usually cannot be inferred from a generic request to “make this fast.”

AI may help propose optimizations, but the benchmark, workload, compiler, hardware, and operational constraints still determine whether the proposal works.

Natural Language Is an Interface, Not a Specification

Natural language is useful because people already know how to use it. It allows developers and non-developers to describe an objective without remembering a library name, API signature, command, or language feature.

That makes it an effective interface for programming tools. It doesn’t make English a programming language in the formal sense.

A request such as “build a secure user authentication system” leaves hundreds of decisions unresolved. Which authentication protocol should it use? How are credentials stored? What are the password rules? Is multi-factor authentication required? How are sessions invalidated? What happens during an identity-provider outage? Which attacks are in scope?

A model must fill those gaps with assumptions. Some may be sensible, but they remain assumptions unless the developer converts the request into explicit requirements, interfaces, tests, policies, and operational constraints.

Traditional programming languages reduce ambiguity by giving instructions precise syntax and semantics. Type systems constrain possible values. Tests define expected examples. Static analyzers enforce rules. Contracts and formal specifications can describe properties that must always hold. Benchmarks define measurable performance targets.

Prompting doesn’t eliminate those artifacts. At best, it helps create them.

This is where Stroustrup’s emphasis on abstraction becomes important. In his writing on abstraction and C++, he describes abstraction as a way to express ideas clearly without sacrificing access to the machine or introducing unnecessary overhead.

A well-designed abstraction packages knowledge into a component that developers can validate once and reuse many times. A library interface can enforce invariants and hide a difficult implementation. Generating a fresh implementation from a prompt each time does the opposite if every result needs to be independently understood and checked.

Humans may eventually type less syntax, but they will still need to decide what the system means, which guarantees matter, how components interact, and what evidence is sufficient to ship it. Writing types, tests, interfaces, policies, and specifications is still programming, even when AI fills in some implementation details.

The Best Use of AI Keeps Humans Accountable

Stroustrup’s warning points toward a risk-based approach rather than a blanket rejection of AI coding tools.

AI is easier to justify for bounded, reversible work such as:

• Generating boilerplate and repetitive data transformations
• Drafting tests that developers inspect and expand
• Explaining unfamiliar code or compiler errors
• Creating prototypes that won’t be deployed unchanged
• Converting code between well-understood APIs or formats
• Suggesting local refactors with measurable behavior
• Producing documentation and implementation alternatives

Higher-risk code needs stronger controls. Teams can keep generated changes small, require a human owner for every contribution, run static and dependency analysis, test failure conditions, fuzz exposed interfaces, and benchmark performance-sensitive paths. Generated code should meet the same review requirements as an external contribution from an unknown developer.

Safety-critical work demands more. Independent verification, traceable requirements, controlled toolchains, reproducible builds, qualified reviewers, and evidence tied to the deployed system cannot be replaced by a model’s confidence or by a successful demo.

Developer education also matters. If junior engineers use AI only to produce answers, they may get fewer opportunities to learn how systems fail. AI tools are more valuable when they expose tradeoffs, propose tests, compare designs, and help developers investigate code rather than simply accepting generated patches.

The human role may shift away from writing every routine line. It cannot shift away from ownership of the result.

Final Thoughts

Stroustrup’s language is sharper than the available evidence supports if his comments are reduced to “AI-generated code is unsuccessful.” Controlled studies show that coding assistants can increase output, particularly for less-experienced developers and well-scoped tasks. That benefit is real.

His more durable argument concerns the definition of success. Code isn’t successful because it exists, compiles, or passes a handful of tests. It succeeds when its behavior can be understood, validated, maintained, secured, and operated at an acceptable cost.

For ordinary internal tools and conventional application features, AI’s speed may outweigh the additional review burden. In a trading engine, medical system, runtime, browser component, security library, or embedded controller, validation may dominate the project. Producing more code only helps if it reduces that total burden.

Natural language will probably become a common way to request software. It won’t remove the need for formal languages, tests, specifications, measurements, and reusable abstractions. As generation gets cheaper, trustworthy judgment becomes more valuable, not less.