How Many New Programming Languages Will the AI Era Create? A Three-Layer Forecast to 2035

1. Conclusion: More Languages Will Be Born, but the Mainstream Has Very Few Open Seats

New programming languages will not stop appearing. AI is especially likely to increase the number of personal experiments, internal corporate languages, and domain-specific languages. Yet the population of general-purpose languages that people name in everyday conversation, companies adopt in production, and employers place in job requirements will grow much more slowly.

The likely outcome is greater concentration around a few powerful languages, surrounded by an explosion of small ones. Think of a forest: new shoots can cover the ground while the number of trees tall enough to reach the canopy barely changes.

The reason is that the cost of creating a language is different from the cost of establishing one in society. With late-2020s AI, an individual can define a grammar, write a parser, and run a small program in a short time. Building a standard library, package manager, debugger, editor support, security review process, long-term compatibility policy, teaching materials, job market, and community of experienced maintainers still takes years.

Any forecast must therefore separate three quantities: inventions, publicly used and detectable languages, and mainstream languages adopted in production. This article forecasts the three layers through 2035 as follows.

The most important point is not the exact range. The frontier is likely to move from inventing new symbols toward turning human intent into less ambiguous specifications and mechanically verifying AI-produced implementations.

2. Seventy Years of Language History: New Languages Arrive When the Next Problem Becomes Visible

A computer program can be understood as a long staircase of translation. A human-readable string is divided into words and symbols by lexical analysis, transformed into a tree of instructions by parsing, lowered through intermediate representations, and eventually converted into machine operations such as addition, comparison, and memory access. A processor fetches, decodes, and executes those instructions. At the bottom are transistors and logic circuits that treat voltage levels as zeros and ones. Many translation layers separate a line on a screen from electrical change in silicon, but the chain always ends in physics.

Early programmers worked almost directly with numerically encoded machine instructions. Instruction numbers and memory locations differed by machine, so moving a program could require rewriting it. Assembly languages, spreading from the late 1940s into the early 1950s, replaced numeric operations with short mnemonic symbols and gave names to memory locations. Another program—the assembler—performed the translation. That was more than cosmetic notation: it delegated the work of memorizing the machine's numbers to a machine.

Assembly did not disappear. It remains important in CPU boot code, embedded systems, cryptography, and extreme performance tuning. Most developers, however, work above it. The history of high-level languages is also the history of hiding machine detail so that humans can describe more of the problem itself.

FORTRAN, LISP, COBOL, and BASIC expanded who could program

In 1957, the IBM team led by John Backus put FORTRAN into practical use. Backus later recalled that during 1954–1957, many programmers firmly believed an automatic programming system could not produce code comparable in efficiency to hand-written programs. FORTRAN challenged that belief with a working compiler. The deeper breakthrough was structural: improving one translator could improve the output of many users at once.^[1]

John McCarthy proposed LISP at MIT in 1958, foregrounding symbolic processing, recursion, and lists. COBOL, consolidated around 1960, prioritized business data processing and portability across machines. Scientific computing, artificial-intelligence research, and administrative work produced different languages because they posed different problems. New languages are often not collections of every virtue in their predecessors; they are deliberately biased answers to a pressing need. The Computer History Museum's timeline records the period in just this way, with language development expanding computing into science, symbols, education, and business.^[2]

A famous account places the first BASIC programs on Dartmouth's time-sharing system at 4 a.m. on May 1, 1964. Thomas Kurtz later joked that neither principal designer was present and called the precise story a “good myth” worth supporting. What is certain is that Kurtz and John Kemeny wanted computing to be available to all students rather than only specialists. A compact language and an interactive environment that returned results quickly were one combined invention. BASIC's later inclusion with home computers also showed that distribution can determine adoption as powerfully as syntax.^[3]

Languages have added steps to the translation staircase not to eradicate everything below them, but to reach the next users and the next class of problems.

Structure, objects, and portability absorbed growing complexity

As programs became larger, the next challenge was no longer expressing an instruction but controlling complexity. In the mid-1960s, Ole-Johan Dahl and Kristen Nygaard at the Norwegian Computing Center used Simula to unite data and procedures as objects. In 1972, Alan Kay, Dan Ingalls, Adele Goldberg, and colleagues developed Smalltalk at Xerox PARC. Object orientation was not a sudden philosophical invention. It grew out of simulation, interactive displays, and the difficulty of handling large software systems.^[2]

In the same decade, Dennis Ritchie's C combined machine-level control with portability. Ritchie's history says that the essentials of modern C were complete by early 1973 and that the Unix kernel was rewritten in C that summer. A useful operating system proved the language; porting the operating system then spread the language.^[4] The relationship would recur between browsers and JavaScript, smartphones and Swift or Kotlin, and cloud infrastructure and Go.

C++, Python, Java, JavaScript, PHP, and Ruby appeared from the 1980s through the 1990s. The clustering of Java, JavaScript, PHP, and Ruby around 1995 was not merely coincidence. Personal computers, the commercial internet, graphical interfaces, and the need to connect servers and browsers sharply increased demand for portability and development speed. Java used a virtual machine to absorb hardware differences. JavaScript obtained an already distributed runtime in the browser. PHP lowered the entry cost of dynamic web pages, while Ruby and Python emphasized reducing human effort.

Since 2000, safety, concurrency, and heterogeneous hardware have taken center stage

Robert Griesemer, Rob Pike, and Ken Thompson began outlining Go at Google on September 21, 2007. The official FAQ traces it to frustration with the complexity of large C++ and Java projects, the spread of multicore processors, and weak language support for concurrency. An early compiler begun in January 2008 emitted C instead of machine code. Even a new language did not have to build every layer immediately. Go became public in 2009 and reached its stable Go 1 milestone in 2012.^[5]

Rust pursued the performance of C and C++ while using its type system to prevent use-after-free errors and data races. When Rust 1.0 shipped in May 2015, the team explicitly described a goal of combining low-level control and safety without requiring a garbage collector or dedicated runtime.^[6] In Stack Overflow's 2025 survey, 72% of developers who had used Rust wanted to continue—the highest “admired” rate among the surveyed languages. A research idea about safety became durable because it was joined by package management, error messages, and documentation.^[7]

Language creation continues. Gleam, a statically typed language targeting the Erlang virtual machine and JavaScript, reached 1.0 in March 2024 and recorded a 70% admired rate in the same 2025 survey.^[8][7] MoonBit, first released in 2023, targets WebAssembly, JavaScript, and native execution and entered beta in June 2025. It initially aimed for 1.0 in the first half of 2026, but as of August 19, 2026, it remained on v0.10.9. Choosing stabilization over a calendar promise is itself a healthy choice for a new language.^[9][10]

MLIR in the LLVM ecosystem lowers another barrier by making intermediate representations at different abstraction levels reusable. Its stated goals include reducing the cost of domain-specific compilers and connecting existing compiler systems. A modern language can stand on LLVM, MLIR, WebAssembly, or an existing virtual machine instead of creating a machine-code generator from zero.^[11]

3. Raw Data Shows Expansion and Concentration Happening at Once

There is no complete census of programming languages. No registry captures every university experiment, internal DSL, or one-person creation. GitHub Linguist—the system GitHub uses to recognize file languages—offers one observational window.

Counting entries marked type: programming in Linguist's languages.yml at the last commit before each observation date gives 298 at the end of 2015, 395 at the end of 2020, 455 at the end of 2022, 530 at the end of 2025, and 560 on August 28, 2026. The net increase from the end of 2015 through the end of 2025 was 232, or a simple annual average of 23.2 entries. The count rose by 42 during 2022 and by 32 during 2025. At minimum, the observable diversity did not stall.^[12]

More kinds and greater concentration are compatible. A region may have extraordinary biodiversity even while its city streets use only a few tree species.

This is not a statistic of invention dates. Old languages may be added later, and the file includes dialects, template languages, and hardware-description languages. Linguist also requires evidence of broad public use for new extensions: ordinarily at least 2,000 indexed files over the previous year, distributed across users and repositories. Tiny hobby languages are unlikely to qualify. The increase therefore measures the widening fringe of languages that have become sufficiently used and observable, not births.^[13]

GitHub's 2025 Octoverse showed strong concentration at the same time. Nearly 80% of repositories created between September 2024 and August 2025 used six languages: Python, JavaScript, TypeScript, Java, C++, and C#. TypeScript exceeded 2.6 million monthly contributors in August 2025, grew by roughly 67% year over year, and became the most-used language by GitHub's contributor-based measure. More choices exist, but production activity keeps pooling in enormous ecosystems.^[14]

The same report counted more than 180 million developers on GitHub, with over 36 million added in a year. Users created more than 230 repositories per minute and pushed about 986 million commits, up 25.1% year over year. More than 1.1 million public repositories used an LLM SDK, up 178%. GitHub cautions that these are correlated activity indicators, not a proof that AI caused every increase. We cannot assign all growth to AI, but software activity is plainly not stagnating in the AI era.^[14]

4. AI Accelerates Language Prototypes—and Strengthens Existing Languages

Stack Overflow's 2025 Developer Survey analyzed 49,009 responses from 177 countries. Eighty-four percent of respondents were using or planning to use AI in development, and 51% of professional developers used it daily. Yet only 33% trusted the accuracy of AI output, while 46% distrusted it. “Almost right, but not quite” answers were the largest frustration, selected by 66%. Rapid use and weak trust coexist.^[15][16]

AI lowers the cost of the first implementation and its tests. It does not automatically erase the cost of maintaining compatibility and trust for a decade.

Capability indicators have moved quickly. Stanford's 2026 AI Index summarized top performance on SWE-bench Verified as rising in one year from about 60% to nearly 100% of the human baseline.^[17] That figure cannot simply be translated into workplace productivity. In February 2026, OpenAI reported an audit of 138 Verified failures in which 59.4% contained test or specification problems capable of rejecting functionally correct submissions, and stopped using Verified for frontier evaluation. In July, it reported that roughly 30% of the successor SWE-Bench Pro tasks were also broken. Benchmark saturation reflects limits of the ruler as well as improvement in the thing being measured.^[18][19]

The workplace effect is similarly non-linear. In METR's randomized controlled trial from early 2025, 16 experienced open-source developers completed 246 tasks in projects to which they had contributed for an average of about five years. When AI was allowed, completion time increased by 19%. Before the work, participants expected AI to make them 24% faster; afterward, they still estimated a 20% speedup.^[20]

METR's February 2026 update estimated an 18% speedup for a subset of returning developers, but the confidence interval stretched from a 38% improvement to a 9% slowdown. Developers unwilling to work without AI increasingly avoided the experiment, AI-friendly tasks were withheld, and parallel-agent workflows made time accounting unreliable. METR explicitly said the data was not a reliable signal of the current effect. The lesson is not that acceleration is imaginary. It is that AI is now embedded deeply enough to break older measurement designs.^[21]

AI still pushes down the prototyping cost of a language. It can draft grammars, parsers, type checkers, tests, standard-library code, and editor extensions in parallel, while retrieving lessons from earlier language designs. But it also favors languages with abundant examples, clear compiler errors, and deep libraries. AI systems have far more experience with Python, TypeScript, Java, or Go than with an unknown new syntax, so they can produce more reliable code in the established languages.

AI is therefore an engine of diversification and an engine of concentration at the same time.

5. Even If AI Writes the Code, Human-Readable Languages Will Not Disappear

If only AI wrote code, it might seem efficient to discard human-readable syntax and use a compact representation optimized for machines. Production code, however, is not merely a command. It is also a record of responsibility. Someone must investigate failures, compare behavior with requirements, audit for malicious operations, and understand a change years later. Even when AI generates the implementation, the organization that bears the loss needs a form humans can verify.

Readability is not irrelevant to an LLM either. Clear names, types, function boundaries, tests, and documentation provide predictive structure and make errors visible. GitHub cited this feedback effect when explaining TypeScript's 2025 growth: types can expose broken contracts in AI-produced code earlier. A type is documentation for a human and a contract a compiler can check.^[14]

An AI-oriented language is therefore more likely to make types, preconditions, postconditions, permissions, and failure behavior explicit than to become an unreadable cipher. Natural language remains useful at the entrance, but executing it directly leaves dangerous ambiguity. AI can transform a Japanese or English request into a formal specification, tests, and typed intermediate representation; compilers and verifiers can then lower it into existing languages or machine code. Humans write fewer individual operations and more intent, constraints, and evaluation criteria.

Natural language becomes the entrance, formal specifications and tests become checkpoints, and established runtimes become the road. The connective layer may be the next kind of “language.”

The boundary between compilation and interpretation will keep thinning

One source program already can move between interpretation and compilation. A language defines meaning; compilation versus interpretation is largely a property of its implementation. Java virtual machines and JavaScript engines start execution quickly, then compile frequently used sections at runtime. They may even undo optimizations when observed types or behavior change. Interpretation and compilation are being selected in stages inside one process.

That adaptation can move upward. A system may interpret for responsiveness during development, compile ahead of time for production, emit an energy-saving build on a device, a parallel build on a server, and a matrix-oriented build for a GPU from the same intermediate representation. MoonBit's multiple backends and MLIR's multi-level design point in this direction.^[9][11]

Unrestricted automatic switching would make performance reproducibility, debugging, and cost prediction difficult. A realistic “strongest language” will not mix every technique without limits. It will hold semantics fixed while changing execution strategy only within observable, measurable boundaries.

6. How Many by 2035? Read the Forecast in Three Layers

The first layer contains personal experiments, internal languages, and DSLs. Because AI sharply lowers the minimum effort needed to complete a prototype, hundreds or thousands could be created each year. Many will remain private, resemble configurations or APIs more than standalone languages, or disappear in days. Assigning a fixed birth count would be false precision.

The second layer contains languages used enough on public GitHub to enter a classifier such as Linguist. Starting with the 2015–2025 average net increase of 23.2 entries per year, a central range of 20–35 annual additions suggests roughly 200–350 entries from 2026 through 2035. For 2026 through the end of 2030 alone, that would be about 100–175. The range reflects upward pressure from cheaper experimentation and the delay imposed by a requirement for real public usage. It must not be relabeled as a count of inventions.

The third layer is new general-purpose languages that repeatedly appear in major surveys and enter production hiring. This article forecasts roughly 3–8 between 2026 and 2035, with perhaps 1–3 joining the global top tier. When nearly 80% of new repositories use six languages, and organizations face compatibility, hiring, and training costs, dozens of new general-purpose languages are unlikely to become mainstream simultaneously.^[14]

The ranges of 3–8 and 1–3 are conditional scenarios, not outputs from a statistical model. Economic conditions, regulation, education, or adoption by a giant platform could move them. A successful newcomer will probably connect to an existing ecosystem—just as TypeScript extended rather than discarded JavaScript—or target Python, JavaScript, WebAssembly, the JVM, or another established base.

The biggest change may not be counted under “programming languages” at all. We may see specification languages that combine instructions to agents, data types, permissions, business workflows, tests, and evaluation criteria while AI generates established implementation languages underneath. A human may appear to issue a request in natural language, while the system internally relies on a structured, ambiguity-reduced representation that functions as a new language. The paradigm shift is less likely to be one syntax replacing all old syntax than a layer for intent and verification being added above code.

7. Five Stages for Building a Language Yourself: You Do Not Need to Target a CPU First

Building a language is not the same as building a widely adopted language. Start with a tiny implementation that solves one problem.

Stage 1: Choose one frustration

Limit the target: commands in Japanese, safe data transformation, a language children can understand, or a simpler way to use a GPU. Trying to combine every advantage of PHP, Java, Ruby, JavaScript, Go, and Python causes virtues to conflict. Runtime speed trades against implementation simplicity, freedom against safety, and implicit convenience against predictability.

Stage 2: Fix a small semantic core

Numbers, strings, variables, addition, conditionals, loops, and functions are enough to build programs. The surface may use Japanese, English, Arabic, or another writing system; Unicode makes the characters manageable. The hard requirement is a grammar that gives the same sentence the same meaning and a defined rule for errors.

Even a first language that accepts only this expression has crossed a meaningful boundary once input, meaning, and output are fixed:

足す 2 3

Stage 3: Transform input into a syntax tree

Split “add 2 3” into an operation and two values, then create a tree with addition at the root. A hand-written parser is fine, and existing tools such as ANTLR or Tree-sitter are available. AI can draft the grammar, tests, valid examples, and error cases in parallel. Freeze expectations with tests so that the generated grammar and generated implementation cannot silently disagree.

Stage 4: Borrow an existing runtime

Evaluate the syntax tree directly, or translate it into JavaScript, Python, C, or WebAssembly. There is no need to emit machine instructions for every CPU. Go's early implementation generated C; borrowing an existing base proved the concept faster. LLVM or MLIR can come later if performance demands it.^[5][11]

Stage 5: Build the environment, not only the language

A usable language needs a standard library, package management, formatter, diagnostics, debugger, completion, documentation, compatibility policy, and security checks. Build a small useful program in the language and see whether someone else can install it without an oral explanation. Only after crossing this stage does an interesting interpreter become a language capable of accepting responsibility for another person's time.

Judge success with five questions rather than “does the compiler run?”

1. Can a first-time user execute something within 30 minutes?
2. Does an error identify its cause and the place to fix it?
3. Does code from a year ago still run on the new implementation?
4. Can users trace package provenance and permissions?
5. If the creator disappears for a week, can someone else isolate a problem?

AI accelerates the first implementation. These questions remain work in design, operations, and community.

8. What Survives Will Be Verifiability, Not Flashy Syntax

Across more than 70 years, languages were not created merely to hide machine inconvenience. They appeared when scientists, administrators, students, large-system developers, web creators, and distributed-system operators encountered problems their existing tools handled poorly. That structure remains in the age of AI agents. What changes is prototype speed, and the fact that the first user may be an AI as well as a human.

Pocho Laboratory's one-sentence forecast is this:

The number of languages will become more dynamic. Visible use will concentrate in existing languages. Between them, a new layer of AI-readable specifications and human-and-machine verification will emerge.

Even if people stop writing code character by character, they still must describe what is permitted, what is forbidden, and how correctness is judged. That description system is itself a programming language in the broad sense.

Understanding how electricity becomes light is different from building a power station. In the same way, you do not need to finish a production compiler to benefit from understanding how text becomes a syntax tree, intermediate representation, machine instruction, and electrical signal. As AI handles more implementation, the human role moves toward decomposing the problem, fixing meaning, and verifying output.

The strongest future language may not be one grammar containing every feature. It may be the shortest auditable path connecting human intent, AI generation, mechanical verification, and an enormous existing execution ecosystem.

Method note: The 2035 ranges in this article are scenarios derived from public data and historical patterns, not deterministic predictions. Linguist entry counts are not direct counts of inventions or users, and GitHub, Stack Overflow, and benchmark numbers each depend on their own population and measurement method.