In August 2025, TypeScript became the most used language on GitHub. This was the largest shift in GitHub’s language rankings in the last ten years and it occurred during the period of most accelerated adoption of coding AI agents.
Coding AI agents had previously been predicted to lower the importance of language selection. It was assumed that organizations would become stack agnostic and select tech stacks based solely on the needs of the business problem, leaving behind the considerations of the available developer hiring pool. Instead, a mere two years after the widespread adoption of AI coding tools, the market appears more restricted, with a rapid narrowing of available coding languages, and most of the focus is on a single family of languages.
Analysis of the change
GitHub’s October 2025 Octoverse report counted TypeScript contributors. Its 2.64 million monthly contributors marked a 66% increase year-over-year. During 2025, TypeScript saw over a million developers write their first TypeScript code in GitHub.
This growth is in addition to an already highly dominant position. In 2025 Stack Overflow sent a developer survey that collected more than 49,000 responses. Of these responses, 66% self-reported using JavaScript. For nearly every year since 2011 JavaScript has dominated this position. In conclusion the JavaScript family is both the most used and the fastest growing on GitHub.
It is worth briefly addressing an issue with GitHub’s counting method; counting activity on GitHub is counting activity on their own site which presents a conflict of interest as they may want it to look good. Also, fashion trends impact the kind of information that is included in public repositories. However, the indicators still align with survey data, which is reasonable considering the scope of this particular trend.
Models write best in the code they have seen most
How it works is quite simple. Models learn from the code that is published, and most of the code that is published is written in JavaScript and TypeScript. In fact, much of the code is centered around React.
This creates a substantial gap in the output that developers can see in their agents within a day of changing their stack. Request a coding agent to generate a typed React component and the output will usually compile, conform to the standards of the codebase, and require minimal edits. In contrast, when you ask the same agent to generate code for a Svelte, Solid, or a less popular backend framework, the output tends to be much thinner. Also, you will see more invented APIs, and the scaffolding will need more corrections before it is executable.
As a result, this is now changing the way that teams are selecting their stacks. It is no longer simply a matter of deciding which framework is the most efficient or easiest to work with, but rather which framework is most compatible with the team’s tools because the productivity gap in usable agent output during an extended build cycle is compounded. When that team produces output, it gets published, scraped, and included in the subsequent training runs, widening the productivity gap.
None of this points to a technical verdict. Solid and Svelte are good frameworks, and several more modern frameworks outperform React on raw speed. The market rewarded the choice the models already knew.
The models are built in Python, but the products are shipped in JavaScript
A valid counter to the above points is that AI development happens in Python. Model training, evaluation, and most research tooling run in Python, and that hasn’t changed.
However, very little of what the customer interacts with is written in Python. In fact, the front end of an AI product is essentially a window that streams tokens. It also requires buttons to execute tools, an approval step for anything that could lead to a negative outcome, and an explanation of what the system did and why. This is all done in JavaScript and TypeScript, regardless of whether the model has been sourced from OpenAI, Anthropic, or an open-weight model that the company hosts on their own hardware.
By the end of 2025, GitHub had reported over 1.1 million public repositories using an LLM SDK, a 178% increase from the previous year. This increase was primarily due to application development, rather than model development. Every enterprise pilot that makes it past the demo stage requires someone to build the user-facing component, and the industry-standard tools for that work are JavaScript frameworks.
Type systems became the guardrail for generated code
The opinion from GitHub is that the shift has meant developers are moving towards typed languages because type systems make agent-assisted development safer. Generated code has a specific type of failure. It reads and is structured well. It even runs perfectly fine in dynamic languages, only to crash due to shape mismatches three calls down. Type checkers will identify a large portion of this before the code even gets run.
This theory has proven correct in practice. In 2026, the use of TypeScript by professional developers reached 78 percent, an increase from 69 percent two years prior. Approximately 40 percent of developers write exclusively in TypeScript, and only 6 percent of developers write exclusively in plain JavaScript.
The types of errors that a compiler will find tend to be the types of errors that a human reviewer will overlook when faced with 400 lines of reasonable code.
● A function is called with an object that is missing one of the required fields.
● Code contains an assumption that a value exists, and this results in a null or undefined value being passed.
● The shape of an API response has changed, and the generated handler still uses the old one.
The bottleneck has changed from writing code to verifying code
The field report from OpenAI regarding the use of coding agents in scientific computing from July 2026 stated the limitation most plainly: verification has become the limiting factor, as opposed to code generation. While it is a vendor examining their own product and should be taken with a grain of salt, the result coincides with what many engineering teams, particularly those outside of research, have been noting for the past year.
When a capable front end is finished in one afternoon instead of three weeks, the slowest part of the process becomes determining if everything that appeared on the screen is correct, secure, and maintainable. This changes what is expected from a JavaScript developer. Speed in typing code has never been the real value of the job, but it was used as a rough measure of competence during the hiring process. Generated code has taken away the measure and left the judgment.
It is expected that a React effect will fire twice during development, and a developer who is unaware of this may spend an entire day investigating what they think is a bug due to a duplicate API call. A generated query will seem fine in the development environment with sample data, but it can end up scanning an entire table when used in the production environment. An auth check can be placed anywhere in a component and be ineffective, which may give the illusion of security, but that illusion disappears when someone actually tests it.
There is a misalignment that teams tend to overlook. Generation capacity is nearly infinite and increases with each additional agent or a new subscription. In contrast, review capacity is limited by the number of engineers who are sufficiently versed in the system to identify a plausible error. That number is not likely to increase at the same rate. Adding more code generation capacity to a team that is already at their review capacity limit does not increase the rate of delivery. It simply moves the bottleneck from writing to reviewing. A team could double their code generation capacity in a week, but that won’t change the number of people available to review. This is why the constraint has shifted and why additional tooling does not provide the solution.
The same has not been true for hiring practices. Most screening still assesses whether a candidate can arrive at a working solution, which is the part the tools already assist with. Some companies have begun evaluating the opposite skill. They present candidates with blocks of AI-generated code which contain a fault and observe how long the fault remains unaddressed.
Staffing firms have also moved in that direction. For instance, Full Scale now describes the JavaScript engineers it places as having fluency in AI tools and product sense, rather than lines of code written. A company that sets out to hire a dedicated JavaScript developer is now acquiring as much review capability as building capacity. That seems a minor shift until an AI-generated login flow moves into production without human intervention.
The concentration carries a cost
A market that values what the models already know makes it difficult to introduce anything new. A new framework published this year has no pre-existing corpus of training data, making it difficult for agents to work with it, causing teams to avoid it, leading to a scenario where no corpus is generated. The typical time-to-funding is insufficient for merit-based solutions to break this cycle. Frameworks that achieved their milestones prior to 2023 now have an advantage that has nothing to do with quality of design.
The risk is narrower for a single company. A business whose product, tools, and hiring pipeline all revolve around a single language family has made the same bet three times. That is comfortable while the language family maintains its dominance, and costly should it falter.
The first prediction was half correct. AI has indeed eliminated much of the cost of writing code in a language that no one on the team understood. The cost of comprehension and ownership still persists, and for most teams, this is the primary cost that determines the technology stack.
