60–70% of YC X25 Agent Startups Are Using TypeScript
3 Arindam1729 7 6/7/2025, 8:50:04 PM
I recently saw a tweet from Sam Bhagwat (Mastra AI's Founder) which mentions that around 60–70% of YC X25 agent companies are building their AI agents in TypeScript.
This stat surprised me because early frameworks like LangChain were originally Python-first. So, why the shift toward TypeScript for building AI agents?
Here are a few possible reasons I’ve understood:
- Many early projects focused on stitching together tools and APIs. That pulled in a lot of frontend/full-stack devs who were already in the TypeScript ecosystem.
- TypeScript’s static types and IDE integration are a huge productivity boost when rapidly iterating on complex logic, chaining tools, or calling LLMs.
- Also, as Sam points out, full-stack devs can ship quickly using TS for both backend and frontend.
- Vercel's AI SDK also played a big role here.
I would love to know your take on this!
I think ppl underestimate the cost of context switch between languages, even if you're really proficient in more than one.
If you're a team with 1-2 eng and have to build a frontend, you are forced to use js/ts. Now, if you can keep everything in a monorepo in the same language, you're simply moving faster. And I'm sure people will criticize and bring counter examples... but statistically 60-70% of the teams will just be faster working this way.
My first startup was frontend php, backend python, 2 eng; soon we specialized one working on frontend, the other on backend, it's tedious to context switch. My last startup was typescript for everything, again 2 eng, same code base, same coding style, both iterating on all code. (And daily I work in rust & C, I'm definitely not a frontend eng nor a js/ts enthusiast, I'm just reflecting on efficiency.)
Typescript (which is still "Javascript") is extremely immature for a "backend" language.
I can't take anyone seriously if they believe or use such a pseudo-typed language like typescript and especially a weakly typed language with dynamic types on a costly runtime such as Javascript on the backend.
Both of them should stay far away from anything backend.
Now we can argue how good or bad the nodejs (or any alternative JS implementation) is. At the end of the day the objective is most likely to rock the boat enough to be acquired and have a payday. With enough discipline you can get far before the footguns show up.