AI changed how developers choose programming languages
AI can lower the cost of entering an unfamiliar programming language, but it does not replace ecosystem knowledge, review skill, or engineering judgment.
"People who are deeply tied to a single tech stack are so f*cked right now"
The tweet went viral this week, but it's not what he said that surprised me, it was the replies. Scroll through them and you find something rare on tech Twitter: consensus. He's right, and everyone seems to already know it.
Picking a language used to be a marriage
For decades, picking a language was a long-term commitment. You would spend months, sometimes years, reaching real fluency. Your projects, your job prospects, often your professional identity would attach to the choice. "I'm a JavaScript dev." "I'm a Python person." We didn't just use languages. We joined them.
And when a choice costs that much, everyone optimizes for the same things: how gentle is the learning curve, how big is the ecosystem, how fast can I ship something. That preference explains most of modern web history. Rails exploded off a 15-minute blog demo, and PHP put a generation of developers on the internet. Node's whole pitch was carrying one language everywhere. Next.js won by making the hard parts disappear.
The switching cost collapsed
The real price of a new language was the unproductive stretch, not the studying: the months where you're slow and dangerous, where every task takes four times longer and you can't yet tell good code from bad. That stretch is what kept developers married to their stacks. Nobody can justify a quarter of shipping nothing.
AI collapsed that stretch. The model is already fluent in the language you aren't, so you produce working code from day one, and fluency rubs off. You ask why the compiler is complaining, why the code is structured this way, what the idiom is, and the language soaks in while the product gets built.
The old sequence was learn first, produce later. The new sequence is produce and learn at the same time.
Carl Lerche, who created Tokio and supports Rust adoption inside Amazon, watches this at scale: engineers join Rust projects without knowing Rust, lean on AI as a learning copilot, and ship real features while they learn.
The extreme case is Bun. The runtime is 535,000 lines of Zig with 22 million monthly downloads, and its creator, Jarred Sumner, ported the entire thing to a new language in 11 days: dozens of AI agents working in parallel, with a test suite of over a million assertions passing 100% before merge. His own estimate for doing it by hand: three engineers, a full year. In his words: "Until very recently, programming language choice was a one-way decision."
I point to these two cases because of the pattern they share: people are now willing to reach for the languages we know to be more difficult. Amazon engineers walked into the language famous for its unforgiving compiler. Jarred left a language he loved for one that rejects, at compile time, the exact class of crashes that plagued his project. The payoff of the harder language was always there. The climb just stopped being a veto.
The case for staying married
Deep experience in one ecosystem is still one of the most valuable things a developer can own. That was true before AI, and nothing above changes it.
Ecosystem knowledge doesn't transfer on demand.
Knowing a language's syntax is the smallest part of competence in it. Knowing which library is abandoned, which pattern bites you at scale, what production failure looks like at 3 a.m. That's years of accumulated context, and an AI assistant doesn't hand it to you. A developer with ten years in one ecosystem will out-ship a tourist in it for a long time.
There's a catch in the fluency-rubs-off story, too. If the model writes the unfamiliar language for you, you can ship for weeks without genuinely reading it, and reviewing code in a language you half-know is exactly where subtle bugs live. That's why the Amazon story works: those engineers bring deep general fundamentals and treat the AI as a tutor rather than a ghostwriter. This is not vibe coding. AI fills the syntax gap, not the competence gap. Jarred didn't merge a million AI-written lines on faith either. He spent those 11 days directing and reviewing, and it worked because he understands that codebase better than anyone alive.
So the objection is real. It just argues for a different conclusion than "stay married." It argues that the depth matters and the exclusivity doesn't.
What to do about it
For anyone deciding what to learn (or worrying about what they've already learned), the playbook is short:
- Learn one language deeply. Depth is still where fundamentals come from. TypeScript and Python are popular on-ramps for good reason (huge ecosystems, instant feedback), but the best first language is the one attached to something you actually want to build.
- Treat it as a first language, not a life sentence. The fundamentals (data structures, systems thinking, what good code looks like) are the part that transfers. AI is the part that does the transferring.
- Pick per problem, not per identity. When the job rewards a stricter compiler or a different runtime, the unfamiliarity tax is now low enough to pay. Refusing on tribal grounds is the expensive choice.
- Never ship what you can't explain. The tools multiply what you walk in with.
These courses provide practical starting points and next steps for building that transferable foundation.
Check out our related courses
The developers in trouble right now are the ones who made a language their whole identity and stopped learning underneath it, not the ones who picked the "wrong" one.
Date the languages, but marry the fundamentals.
