AI Writes Most of the Code: Which Language Wins When the Compiler Becomes the Referee?

Updated: August 2026.

For twenty years, the question “which language should we choose?” has always been answered from the perspective of the programmer: which language is fast to write, easy to read, makes it easy to hire people, and has a rich library of tools. Starting in early 2026, that question was fundamentally redefined. When the majority of the lines of code in a project are no longer written by humans, the criterion of “writing for the sake of writing” loses much of its weight. Replacing it is a much more unusual criterion: to what extent does the language allow machines to automatically verify the correctness of the code, how fast that verification is, and how cost-effective it is.

This isn’t a contest to determine which language is “better.” It’s about how the bottleneck in the software industry has shifted to a new location, and everything around it—compilers, tools, and even the way we measure a language’s popularity—is being realigned to fit that new location.

The bottleneck has shifted: spot prices have fallen, but futures prices have not

The cost of producing syntactically correct code has fallen to nearly the same level as the cost of electricity. The cost of verifying that the code does the right thing, however, has hardly decreased—because it still depends on the time spent by an engineer with sufficient context, which is the most expensive and hardest-to-replicate resource in the industry.

The consequence is very direct. In the past, a “lax” language was an efficient one: you wrote fewer characters, tested faster, and you—the writer—still kept a mental model of what that code assumed. Now the code is generated by a machine, and the machine doesn’t hand over the model in its head. The only thing that’s handed over is the text. If the language doesn’t force those assumptions to manifest as something verifiable, they disappear—and reappear three weeks later as a 2 a.m. incident.

In other words: what’s scarce isn’t the code itself. What’s scarce is the well-founded belief that the code is correct. And whichever language can turn that belief into an executable command in a matter of seconds is winning.

Why a Picky Compiler Suddenly Became an Advantage

The code-writing agent operates in a loop: propose — run tests — read errors — fix — repeat. The quality of the output from this loop depends almost entirely on the quality of what researchers call an oracle: an automated adjudication source that indicates “wrong,” and—even better—“where it’s wrong and why.”

Three characteristics that define a good oracle:

• Early detection. Errors caught at compile time are tens of times cheaper to fix than those caught at runtime, and thousands of times cheaper than those caught in production.
• Structured diagnostics. A message that clearly specifies the file, line, column, error code, and a suggested fix is something an agent can process immediately. A single line of “Segmentation fault” or a “TypeError” at the very bottom of the stack is nearly useless—the agent has no choice but to guess.
• Narrow the valid program space. This is a point few people mention, but it’s the most important. Strict data types, exhaustive pattern matching, explicit error handling, and ownership rules—each constraint eliminates an entire family of incorrect programs. The model generates text probabilistically; the tighter the constraints, the more “plausible but incorrect” options are filtered out before anyone even runs the program.

That is why, in 2026, researchers began to view compilers and language servers not as tools for humans, but as sources of supervisory signals for machines: There were training approaches that directly used feedback from compilers and language servers as rewards, and an entire NeurIPS 2026 workshop dedicated to the topic of verifiable code generation, where agents worked alongside theorem provers, model checkers, and SMT solvers. What was once the “developer experience” is now a machine-to-machine interface.

But the rankings tell a different story

If the above argument is correct, we should see statically typed languages surge in popularity. The reality in 2026 is more complex: Python remains the clear winner. The TIOBE Index for mid-2026 shows Python’s market share hovering around 20%—a level no other language has reached in many years—with a jump of several percentage points in just one year. RedMonk, which uses a different measurement method, still ranked JavaScript first, Python second, and Java third in January 2026, with the top 20 remaining virtually unchanged.

Two forces are pulling in opposite directions, and both are real:

• The driving force behind Python’s rise is AI infrastructure. Everything related to models—training, serving, evaluation, and agent development—takes the shortest path through Python. Furthermore, the best code-generating models are found in the languages with the most publicly available data, and Python and JavaScript top that list. This is a self-reinforcing cycle.
• The pull toward static typing stems from the need for the verification mentioned earlier. It doesn’t manifest as language rankings, but rather in the way people run those languages: TypeScript in strict mode instead of plain JavaScript, and Python with full type annotations and a mandatory type-checking suite in CI instead of “anything that runs is good enough” Python.

It’s also worth stating plainly something that RedMonk itself has warned about: the old metrics are becoming obsolete. The number of questions on Stack Overflow no longer reflects usage levels when developers ask directly about a language; the number of pull requests on GitHub fluctuates strangely as code production speeds up but the way changes are aggregated differs from before. In other words: all language ranking figures at this stage should be interpreted as trend indicators, not precise measurements.

The field of reconciliation: applying verification mechanisms to dynamic language

The most interesting thing about 2026 isn’t that Python lost or Rust won, but that the industry chose a third path: keeping dynamic languages, but wrapping them in a verification layer fast enough to fit within the agent’s loop. Here are a few specific milestones:

• TypeScript 7 will be officially released in mid-2026 with a compiler rewritten from scratch in Go (codenamed “Corsa”), which is about an order of magnitude faster than the previous version for project-wide type checks. This isn’t just a matter of convenience: when type checking an entire monorepo takes ten minutes, an agent can’t use it as an oracle after every edit; when it takes a few dozen seconds, it can. To be fair, it’s worth noting that the initial 7.0 release did not yet have a stable programming API, so a number of related tools (such as typescript-eslint and the type checkers for Vue, Svelte, and Astro) couldn’t run immediately, and the migration had to be done gradually.
• Python has a new generation of type checkers written in Rust: Astral’s `ty` and Meta’s `pyrefly`, both of which aim for low enough latency to run continuously rather than just overnight. Combined with uv and ruff, by 2026 the Python toolchain will have largely replaced its core components with Rust—and in March 2026, OpenAI acquired Astral, a clear signal that Python’s tooling infrastructure is viewed as a strategic asset for the age of agents rather than a mere utility.
• Python itself also changed its runtime: starting with version 3.14, the GIL-free version moved from experimental to officially supported, accompanied by a JIT that was still in experimental status. The single-threaded cost of the free-threaded version has dropped significantly compared to the previous generation, though C libraries that haven’t declared compatibility still cause the GIL to re-engage—so this is a multi-year transition, not a simple flip of a switch.

What all three have in common is that the speed of the type-checking tool is a feature of the language, on par with syntax. A type checker that is correct but slow is virtually nonexistent in the world of agents, because it cannot keep up with the loop.

The Ladder of Verification: Where Do We Stand?

If you put everything on a scale, it becomes clearer. Each step adds another layer of complexity and costs a little more—in terms of both the effort required to write the specifications and the machine’s runtime.

The highest level—program generation accompanied by formal proofs, tentatively called “vericoding” to distinguish it from “vibe coding”—is the most vibrant area of research in 2026. The idea: the author specifies the requirements, the machine generates both the implementation and the proof, and then an independent verifier confirms that the program satisfies the specifications. Benchmarks are already available for Dafny, Verus (Rust), and Lean; there are also closed-loop processes in which the model iteratively refines the setup to make it easier to prove. The results are good enough to be interesting, and in some cases, they’ve even detected errors in human-written code.

But we must be honest about the limitations: this approach is still narrow. It requires a formal specification—and writing a correct specification is often just as difficult as writing correct code. It takes a significant amount of machine time. And it has an inherent pitfall: software that is proven correct according to a flawed specification is still flawed software—it’s just flawed in a very formal way. As of August 2026, the majority of the development team is at levels 2 through 4—static, rigorous, and, for platform systems, with Rust’s ownership model.

Rust: A victory few saw coming

By 2026, Rust will have moved beyond the “favorite language” phase and entered the “required language” phase. The pressure isn’t coming from the community but from regulations: cybersecurity agencies have set a deadline requiring infrastructure software providers to have a roadmap for transitioning to a memory-safe language, with the deadline falling in early 2026. In addition, the Rust driver in the Linux kernel has moved past the pilot phase, and the percentage of enterprises using Rust in production continues to rise.

But the more interesting argument lies elsewhere. Rust’s biggest hurdle has always been the cost of learning and the cost of battling the borrow checker—a cost paid in human frustration. That cost has just been drastically reduced, because machines don’t get frustrated. An agent rejected by the borrow checker for the twentieth time will still read the error message and try again with just as much enthusiasm as the first time. What used to be Rust’s biggest drawback for humans is precisely what agents need most: an uncompromising arbiter that clearly explains its reasoning and always gives the same answer.

In other words, the same linguistic feature can result in different accents depending on the user: difficult for people, easy for machines.

Economic Corner: Every Failed Loop Costs Real Money

This issue comes down to money in three ways, and all three are measurable.

First, the cost of a single iteration. Every time an agent makes a wrong guess and has to correct it, that counts as one inference cycle: input token, output token, and CI runtime. Any language that catches errors at the compilation stage—without needing to run the code, set up the environment, or use real data—will eliminate nearly all of the costly loops that follow. For a team running thousands of agent tasks each week, a difference of just a few loops per task makes a noticeable difference on the bill.

Second, and far more significant: the cost of human review. A single style check costs a few cents in machine time; an hour of a senior engineer reading code costs tens of dollars and represents an inelastic resource. When the volume of code requiring review increases manyfold while the number of reviewers remains constant, humans become the new bottleneck. Therefore, the criterion for choosing a language—in financial terms—is the ratio of errors caught by the machine to the total number of errors. Every percentage point shifted to the machine’s side frees up one percentage point of human time for the task that only humans can do: deciding whether what we’re building is actually worth building.

Third, the cost of incidents. Bugs that make it to production are orders of magnitude more expensive than those caught in CI—including service outages, data corruption, and security vulnerabilities. This is also where insurers and regulators are starting to take notice: as the proportion of machine-generated code increases, the question “What can you prove about your code?” shifts from a technical issue to a matter of legal liability. Languages and tools that provide machine-verifiable evidence are less risky, and that ultimately shows up on the bottom line.

Common Points of Confusion

• Static typing doesn’t catch incorrect intent. A program can be well-typed, compile without errors, run smoothly, and still completely fail to do what the customer needs. The compiler checks code for consistency with itself, not for correctly solving the problem. This is why the most valuable work of an engineer is shifting toward expressing requirements and designing system boundaries.
• Languages with limited data suffer a double disadvantage. A young language, no matter how beautifully designed, is at a disadvantage because models rarely encounter it and thus generate inferior code. The paradox: the AI era has made learning a new language easier for people, yet has made popularizing a new language more difficult.
• The reverse is surprising: legacy languages are being saved. Precisely because agents can read and fix COBOL or Fortran reasonably well, the cost of maintaining and modernizing old systems has dropped significantly—undermining the very reason people once rewrote them. Not every language needs to win to survive.
• Don’t confuse “typed” with “strictly typed.” A TypeScript project littered with `any` types has an oracle nearly as weak as JavaScript’s. The value lies in strict mode and in having tools block issues during CI, not in the language’s name.

Prediction

• The divergence is taking place within a language, not between languages. Python and JavaScript lead in terms of numbers, but variants used in serious development will, by default, have mandatory type checking in CI. “Untyped Python” is gradually becoming something used only for throwaway scripts.
• Toolchain speed has become a key factor in language selection. Following the rewriting of TypeScript in Go and the Python toolchain in Rust, more ecosystems will follow suit—with the implicit goal of bringing all project-wide checks down to under a few dozen seconds.
• Rust continues to gain ground in infrastructure, partly for non-technical reasons. The regulatory pressure for memory safety, combined with its advantages in agent loops, makes Rust the default choice for new infrastructure layers, even though C and C++ will still account for a massive volume of code for decades to come.
• Vericoding is leaving the lab but is targeting only the most high-stakes areas. Cryptography, operating system kernels, payment systems, medical software, and aviation—where the cost of a single error is high enough to justify writing formal specifications. The rest of the industry remains at the level of static typing combined with testing.
• High-value skills are shifting. It’s no longer about “knowing the syntax of language X,” but rather about building a verification system: writing formal specifications, designing data types so that incorrect states cannot be represented, defining invariants, creating property tests, and knowing where to stop the agent loop.
• Popularity metrics will have to be redefined. As programming questions shift to private conversations with models and most code is generated by machines, metrics based on public forums and commit counts will lose their meaning; it’s likely there will be new ways to measure based on actual running code.

In short, the 2026 programming language race won’t be decided by elegant syntax or extensive libraries, but by a simple question: in one second, how much can this language prove about the code it just generated? A language that can answer more questions allows agents to converge faster, lightens the burden on reviewers, and saves real money. A language that can answer fewer questions will still survive—but it will have to borrow armor from elsewhere, and in reality, the entire industry is busy borrowing armor.