How AI Is Reshaping Developer Choice (Octoverse 2025 Data)

TL;DR

• TypeScript overtook Python and JavaScript as the most-used language on GitHub in August 2025
• 80% of new GitHub developers use Copilot within their first week, resetting expectations for what "easy" means
• AI performs better with strongly typed languages, creating a convenience loop that's reshaping technology choices
• This matters if you're choosing a tech stack, building frameworks, or managing engineering teams at scale

The Big Picture

Developer preferences don't shift overnight. They accumulate through thousands of small decisions: which language feels easier, which framework has less friction, which tool makes the annoying parts disappear. AI coding assistants are now part of that friction calculation, and the data shows it's changing what developers reach for.

GitHub's Octoverse 2025 report dropped a headline that should make you rethink your tech stack: TypeScript surpassed both Python and JavaScript to become the most-used language on GitHub for the first time ever. TypeScript grew 66% year-over-year while JavaScript grew 24%. That's not a gradual trend line. That's a behavioral shift.

The deeper story isn't about TypeScript winning. It's about what's driving the win. AI coding tools work better with strongly typed languages. Developers notice. They choose accordingly. Those choices compound. The convenience loop becomes self-reinforcing, and suddenly the ecosystem tilts in a new direction.

This isn't speculation. Over 1.1 million public repositories now use LLM SDKs. Eighty percent of new developers on GitHub use Copilot within their first week. When AI absorbs the friction that made certain languages painful, developers stop avoiding those languages. They start picking based on utility instead of overhead.

How It Works

The technical reason behind this shift is straightforward: type systems give AI better constraints. In JavaScript, a variable could be anything. In TypeScript, declaring x: string immediately eliminates all non-string operations. That constraint matters because AI models generate more reliable code when they have clear boundaries.

When you're working in a dynamically typed language, AI has to infer context from usage patterns, comments, and surrounding code. It's guessing. In a strongly typed language, the type annotations are explicit contracts. The AI doesn't have to guess what getUserById returns—the signature tells it. That reduces hallucinations and increases the likelihood that generated code actually works.

This effect compounds across the development workflow. AI-assisted autocomplete works better. Refactoring suggestions are more accurate. Error detection happens earlier. The cumulative result is that developers working in TypeScript with AI tools experience less friction than developers working in JavaScript with the same tools.

The Octoverse data shows this playing out at scale. Shell scripting usage in AI-generated projects jumped 206% year-over-year. We didn't suddenly fall in love with Bash. AI absorbed the friction that made shell scripting painful—the syntax gotchas, the quoting rules, the error handling patterns. Now developers use shell scripts for the tasks where they're actually the right tool, without the usual cognitive overhead.

This is the convenience loop in action. When a task goes smoothly, your brain remembers. Reduced friction becomes a preference. Preferences at scale shift ecosystems. The languages and frameworks that work best with AI tools are gaining momentum not because they're objectively better, but because they're subjectively easier when paired with the tools developers are already using.

The architectural implications are significant. Teams that adopted TypeScript early are now seeing productivity gains from AI tools that teams still on JavaScript aren't experiencing. That gap creates pressure. Engineering leaders notice that their TypeScript teams ship faster. New projects default to TypeScript. The flywheel spins faster.

But there's a cost. Higher velocity means architectural drift accumulates faster. When developers can generate code at 20-30% higher throughput, the volume of code that needs review increases proportionally. If your review processes and architectural guardrails weren't designed for that volume, quality degrades. The code passes type checks and looks correct, but the system becomes harder to reason about over time.

What This Changes For Developers

If you're choosing technologies without considering AI compatibility, you're setting yourself up for future friction. That doesn't mean you should rewrite everything in TypeScript tomorrow. It means you need to be conscious about the tradeoffs.

For individual developers, the shift changes how you should think about learning. If you're early in your career, investing time in strongly typed languages now pays compound returns because AI tools will amplify your productivity in those languages more than in dynamically typed ones. If you're experienced, the calculus is different—you already have deep expertise in your current stack, and switching costs are real.

For teams, the implications are more complex. AI tools are fantastic at following established patterns but struggle to invent them cleanly. If you define your first few endpoints or components with strong structure, Copilot will follow those patterns. Good foundations scale. Weak ones get amplified. This means the quality of your initial architectural decisions matters more than it used to, not less.

The recent updates to GitHub Copilot's coding agent make this even more pronounced. The agent can now handle multi-file edits and complex refactoring tasks. That's powerful when your codebase has clear patterns. It's dangerous when it doesn't.

Testing becomes more critical, not less. There's a temptation to trust AI output because it "looks right" and passes initial checks. Resist that. AI-generated code needs harder scrutiny, not softer. The code might be syntactically correct and type-safe while still expressing incorrect business logic. Your tests need to catch that.

The velocity jump also changes team dynamics. When junior developers can generate code at near-senior velocity, the bottleneck shifts from writing code to reviewing it. Senior engineering time becomes more valuable, not less. Someone must ensure the system remains coherent as more code lands faster. If your team doesn't have that review capacity, the productivity gains from AI tools will be offset by technical debt accumulation.

Try It Yourself

GitHub now offers a Copilot usage metrics dashboard in public preview for Enterprise customers. It tracks daily and weekly active users, agent adoption percentages, lines of code added and deleted, and language and model usage patterns across your organization.

The dashboard answers a critical question: how well are teams using AI? If you're seeing high agent adoption but code quality issues in certain teams, that's a signal those teams need better prompt engineering training or stricter review standards. If specific languages or models correlate with higher defect rates, that's data you can act on.

Here's a practical exercise: look at the last three technology decisions you made. Language for a new project, framework for a feature, tool for your workflow. How much did AI tooling support factor into those choices? If the answer is "not much," I'd bet it factored in more than you realized. Those moments of friction and flow are encoding your future preferences right now.

Next time you start a project, notice which technologies feel "natural" to reach for. Notice when AI suggestions feel effortless and when they don't. Are you choosing your tools consciously, or are your tools choosing themselves through the path of least resistance?

The Bottom Line

Use TypeScript if you're starting a new project and AI coding tools are part of your workflow. The productivity gains are real and measurable. Skip it if you have a mature codebase in another language and your team isn't experiencing friction—switching costs will outweigh the benefits in the short term.

The real risk isn't picking the wrong language. It's failing to recognize that AI compatibility is now a first-class concern in technology selection. If you're building frameworks or languages, AI support can't be an afterthought. If you're managing engineering teams, you need metrics and review processes designed for higher code velocity. If you're an individual developer, you need to be conscious about which skills will compound with AI tools and which won't.

The convenience loop is already running. The question is whether you're steering it or being steered by it.

Source: GitHub Blog