When people talk about AI and software development, the focus usually lands on productivity: faster pull requests, fewer boilerplate chores, auto-generated tests, autocomplete that feels psychic. But according to Idan Gazit, who leads GitHub Next—the team behind Copilot and GitHub’s long-range R&D—that’s the shallow end of the change curve.

The deeper shift is happening before a single line of code is written.

“AI isn’t just changing how we write code,” Gazit says. “It’s starting to change what we choose to build with in the first place.”

That shift is already visible in this year’s Octoverse report. In 2025, TypeScript overtook both JavaScript and Python as the most-used language on GitHub—a 66% year-over-year surge and the biggest language movement in more than a decade. 

But the story isn’t “TypeScript beats Python.” It’s that AI is beginning to shape language trends from the inside out.

The last generation of change was about where code runs: cloud, containers, CI/CD, open source ecosystems.The next one is about what code is made of, and why those choices suddenly have different stakes.

TypeScript passed Python. But the real story is why.

Developers don’t usually switch languages just for philosophical reasons—they switch when something makes their work meaningfully faster, simpler, or less risky. And increasingly, what feels “easier” is tied to how well AI tools will support their work with that language.

“Statically typed languages give you guardrails,” Gazit says. “If an AI tool is going to generate code for me, I want a fast way to know whether that code is correct. Explicit types give me that safety net.”

Typed languages reduce hallucination surface area. They also give models more structure to reason about during generation. That’s not a theoretical benefit. It’s now a behavioral signal in the data:

• AI models tend to perform better on languages which expose information about correctness, like a type system
• Developers using AI tools are more likely to adopt typed languages for new projects
• The more teams rely on AI assistance, the more language choice becomes an AI-compatibility decision, not merely a personal preference

That shift sets up a feedback loop.

AI assistance is a new consideration when developers are selecting languages and frameworks

AI models are strongest at authoring code in popular languages: TypeScript, Python, Java, and Go, just to name a few.

“If the model has seen a trillion examples of TypeScript and only thousands of Haskell, it’s just going to be better at TypeScript,” Gazit says. “That changes the incentive before you even start coding.”

If an AI tool is going to generate code for me, I want a fast way to know whether that code is correct. Explicit types give me that safety net.

Idan Gazit, head of GitHub Next

Before AI, picking a language was a tradeoff between runtime, library ecosystem, and personal fluency. After AI, a new constraint appears: How much lift will the model give me if I choose this language?

“Python is the dominant language for machine learning, data science, and model training,” Gazit says. “Why would I not choose the one that already has the most robust frameworks and libraries? Those are wheels I don’t need to reinvent.” So TypeScript isn’t winning against Python; each is winning in the situations where it is the right tool for the job, and where AI makes it more valuable.

The surprise winners of the AI era: the “duct tape” languages

One of the most unexpected signals in the Octoverse data wasn’t about TypeScript or Python—it was about Bash.

Shell scripting saw +206% year-over-year growth in AI-generated projects. So what gives?

Because AI makes painful languages tolerable.

“Very few developers love writing Bash,” Gazit says. “But everybody needs it. It’s the duct tape of software. And now that I can ask an agent to write the unpleasant parts for me, I can use the right tool for the job without weighing that tradeoff.” If AI automates the drudgery layer of programming, the question stops being “Is this language enjoyable?” and becomes “should I consider using it when I don’t have to write the code myself?”

Very few developers love writing Bash. But everybody needs it. It’s the duct tape of software. And now that I can ask an agent to write the unpleasant parts for me, I can use the right tool for the job without weighing that tradeoff.

Enterprises aren’t asking “Should we adopt AI?” anymore. They’re asking “What happens after we do?”

“A lot of enterprises have been sitting on the sidelines, waiting to see when the water is warm enough to jump in,” Gazit says. “Now they’re seeing the value: junior developers ramp faster, and senior developers spend less time on toil and more on architecture.”

That creates second-order effects:

Typed languages accelerate this shift—the stronger the safety rails, the more work can be handed to automation.

The next horizon: when language stops being a constraint

Today, language choice matters because runtimes are still fragmented. Browsers require JavaScript. Models need Python. Firmware expects C.

But that’s already eroding.

“WebAssembly is starting to change the rules,” Gazit says. “If any language can target Wasm and run everywhere, that removes one key consideration when picking your stack.”

Combine that with AI-generated code, and you get a plausible future:

• Developer writes in Rust (or Go, or Python)
• AI generates code in that language
• Compiler targets Wasm
• The same code runs on web, edge, cloud, local sandbox

That’s not a TypeScript-wins future. It’s a portability-wins future, and a natural extension to the rise of containerization over the last decade as a means of packaging and running software.

Languages may end up competing less on syntax, and more on ecosystem leverage: package depth, tooling maturity, model familiarity, debugging ergonomics. We’re not fully in that world yet, but the early signals from AI-driven tooling to Wasm-powered portability suggest it’s coming faster than most teams expect.

What developers should actually take from this

This isn’t a “learn TypeScript now” blog (there are enough of those out there, to be sure). 

Here are the signals that matter:

The takeaway isn’t about switching stacks. It’s about optimizing for leverage, not loyalty.

The languages and tools that survive the next decade won’t be the ones developers love most—they’ll be the ones that give developers and machines the most shared advantage.

More resources:

• Watch Idan’s interview
• Learn more about GitHub Next and the future of developer tools

Written by

Content Writer