TypeScript beat Python because coding agents need a compiler to argue with

In August 2025 TypeScript overtook Python as the language with the most contributors on GitHub. According to GitHub’s Octoverse 2025 report, it led by about 42,000. Python had held the top spot for the previous 16 months. TypeScript added more than a million contributors over the year, up 66%, and coverage of the report ties the jump to AI-assisted development. I read that as the first measurable case of a language winning because of who actually writes the code now.

I expected the agent era to flatten language choice, on the theory that a model has no reason to prefer one language over another. The Dashbit post on evolving languages makes the best version of that case. Its author has had agents produce everything from web markup and stylesheets to Elixir, Rust and the Lean theorem prover, and says the syntactic gaps that loom large for him hardly matter to the models. I agree with him about syntax. What surprised me is that his observation strengthens the argument for designing languages around agents, because once syntax stops mattering, the remaining competition is over what the toolchain can tell the machine.

Consider how an agent works. It writes code, runs the compiler, reads the errors and tries again. Every property the type checker can establish is a round of review that costs nothing and happens before a human looks. A dynamically typed codebase gives the agent far fewer chances to discover it is wrong until the code runs, or until a person reads it. TypeScript’s pitch was always that it gives JavaScript a checker, and for an agent that checker turns guesses into feedback.

The Dashbit post pushes this further in a direction I think language designers should take literally. Type inference exists because humans find writing signatures tedious, and agents do not experience tedium. The author also points out that the languages whose types can be fully inferred are a subset of those whose types can be checked, so designing for inference caps both expressiveness and guarantees. I would go further than he does: new languages, and new editions of old ones, should make explicit signatures on public functions mandatory, since the keystrokes people complain about are increasingly typed by software.

Tooling needs the same rethink. The Language Server Protocol speaks in files, lines and columns, which agents track badly. In building Tidewave, Dashbit found agents do better asking where foo_bar is documented or where BarBaz is defined. The post proposes exposing what language servers already know, such as symbols, references, call graphs and types, as a program database with a query language, whether SQLite, Datalog or a custom DSL. No human will write a query to find references to a function. An agent will happily write one that finds every public function that eventually calls it. The same goes for runtimes. The Erlang VM already lets you inspect processes, message queues, supervisors and ETS tables; the post argues the unfinished work is exposing that safely to agents.

The obvious pushback is that developers choose languages for jobs and libraries, and no Python shop is going to rewrite its data stack because a compiler gives better error messages. That is true of existing codebases. But the Dashbit post itself supplies the answer. It argues agents shrink the gap between ecosystems, because porting known algorithms, translating papers and reimplementing libraries is exactly the work they do cheaply. If a smaller language can catch up on libraries in months, the moat that protected the big languages erodes, and so does the cost of switching. Languages gain and lose developers at the margin anyway, on new projects and among new contributors, and I doubt many of TypeScript’s million new contributors arrived through rewrites.

Documentation follows the same logic. A docs site built for a human scrolling a sidebar is a poor fit for an agent that wants the documentation for one symbol from the command line. I think any language team that cannot answer a symbol lookup with a single tool call is writing docs for a shrinking audience.

Point your coding agent at your largest repository and ask it to list every path through the program where a particular value can become nil. Count the files it opens and the minutes it takes. Then ask whether your language’s toolchain could have answered with one query. By the end of 2026, I think at least one widely used language will ship a first-party queryable program database aimed at agents, and I expect its contributor growth in the following Octoverse report to beat its nearest rivals.

Prompted by Evolving programming languages in the AI era - Dashbit Blog, dashbit.co.