Maybe.

I have a small ritual I perform every time a new programming language starts trending on Hacker News. I open the tab, skim the benchmarks, read the "why we built this" section, and then — this is the important part — I close it and go back to whatever I was actually doing. Over the years, I have performed this ritual for Kotlin, Elixir, Crystal, Nim, Zig, and at least a dozen others whose names I've already half-forgotten.

I did eventually stop closing one of those tabs. Go earned a permanent seat at my table — its type system is clean, its simplicity is genuine, and the learning curve is something a team can actually absorb without losing six months of productivity. When people ask me what language they should build in, Go is usually where I start the conversation.

I'm telling you that because I want you to understand that I'm not a language skeptic. I'm someone who made a considered, deliberate bet on a language precisely because it won the human-mastery argument. Which makes what I'm about to argue more uncomfortable, not less.

Every developer reading this still knows the feeling I'm describing. The never-ending arrival of Yet Another Programming Language — YAPL, let's call it — used to feel like progress. Now it mostly feels like homework.

I want to make the case that the YAPL era is ending. Not because the languages have stopped arriving — they haven't — but because AI has quietly changed the calculus underneath the whole question. The human-mastery argument that made Go the right call for so many teams is shifting. And the implications land differently depending on whether you're the developer sitting in front of the keyboard, or the CTO deciding what that keyboard is supposed to produce.

Both of you need to read this, because what each of you decides in the next few years will directly shape the other's reality.

The Tax We Stopped Talking About

What nobody puts in the conference talk is the following; the decision about what language to learn or use was only partly technical. It was also political, economic, partly religious and frankly exhausting.

There was always a language that was theoretically better for the job — safer, faster, more expressive — and there was always a reason you weren't using it. Sometimes it was tooling. Sometimes it was hiring. Sometimes it was that your team had spent three years building expertise in something else, and asking them to context-switch was going to cost you six months of lost productivity and two engineers who quietly updated their LinkedIn profiles.

This is the tax I'm talking about. Not just the learning curve — that's the visible part — but the whole organizational drag of language proliferation. The cognitive overhead of maintaining polyglot codebases. The tribal knowledge that lives in one engineer's head and walks out the door when they leave. The junior hire who learned Python in college and stares blankly when you mention the Rust ownership model.

It was a real tax. And for most organizations, it was rational to pay it in the form of staying with the language you knew, even when a better one existed.

Rust is the case study I keep coming back to, because for a long time it was the sharpest possible example of this tradeoff.

Rust and the ROI Problem That Isn't Anymore

Rust has been offering a genuinely compelling value proposition for years: memory safety without garbage collection, C-level performance, and a type system that catches entire classes of bugs at compile time rather than 3 AM in production. For systems programming, embedded development, and anything where security and performance are in the same sentence, the technical argument for Rust was never really in dispute.

The dispute was always about the cost.

Rust's ownership and borrowing model is, to put it charitably, an acquired taste. The learning curve isn't just steep — it's conceptually foreign to most developers who came up on Python, JavaScript, or Java. The compiler is an opinionated sparring partner who will absolutely tell you when you're wrong, in detail, repeatedly, until you stop being wrong. Some engineers find this liberating. Most find it, at least initially, like being lectured by a particularly well-read bouncer at a club they can't quite get into.

The math was simple: the productivity penalty in developer time during ramp-up outweighed the production-time gains in performance and safety for most teams at most organizations. Not for everyone — there were always teams building things where the tradeoff was obviously worth it. But for the median engineering organization? Stick with what you know.

Here's what's changed.

According to a February 2026 analysis on Medium, AI-generated Rust code is noticeably better than AI-generated code in Python or TypeScript. One-shot implementations that actually work. And the reason isn't coincidence — it's structural. Rust's strict type system and obsessively detailed compiler errors give AI coding agents precise, unambiguous feedback loops. Cargo, Rust's toolchain, gives agents a clean project structure with no guessing about setup, dependencies, or testing conventions. When an AI agent writes Rust and gets it wrong, the compiler tells it exactly why, in terms that a language model can parse and act on.

The AI isn't intimidated by the ownership model. It doesn't get frustrated. It doesn't update its LinkedIn profile.

The productivity penalty that made Rust's ROI calculation unfavorable was always a human productivity penalty. AI doesn't pay it.

The Data Is Already Moving

This isn't speculative. The consolidation is happening.

JetBrains' State of the Rust Ecosystem 2025 report shows 48.8% of companies making non-trivial use of Rust in production — up from 38.7% in 2023. That's a ten-point jump in two years. The developer community doubled from two million to four million users between Q1 2022 and Q1 2024. And 84.8% of organizations running Rust in production say it helped them achieve their goals, with 78.5% saying adoption was worth the cost.

Microsoft Distinguished Engineer Galen Hunt has publicly stated his goal of eliminating every line of C and C++ from Microsoft by 2030 — roughly a billion lines of code — and is building a team around AI-assisted tooling to make it feasible. To be precise: this is a research initiative, not a company-wide edict from Satya Nadella's desk. But a senior technical figure at Microsoft assembling a team around this specific goal, at this specific moment, is not nothing. Microsoft has more legacy C/C++ than almost any organization on earth, and the fact that someone with Hunt's standing is pointing in this direction — and doing it publicly — reflects exactly how the combination of AI-assisted development and Rust's safety guarantees is changing the calculus at the highest levels.

Worth pausing on what this means for C#. I say this with genuine respect for the language — C# has powered an enormous amount of serious production software for over two decades, and the .NET ecosystem remains one of the most complete and productive in enterprise development. Plenty of teams are running significant, well-maintained systems in C# and should keep doing so. But Microsoft's own strategic direction sends a signal. The company that built C# is now directing its systems and infrastructure investment toward Rust. That's not a verdict on C# for application-layer work — it's a clear statement about where Microsoft sees the performance and safety frontier moving. If you're a CTO with a large C# footprint thinking in five-year increments, that signal is worth sitting with.

Meanwhile, at the IEEE Spectrum's top programming languages ranking for 2025, the picture is consistent: the top 20 languages now account for 83.56% of the market — historically high, suggesting a consolidation phase already underway. Kotlin, Swift, and Ruby are measurably declining. The TIOBE Index tells the same story. The middle of the language market — the languages that weren't dominant enough to be ubiquitous or specialized enough to be indispensable — is being eaten.

What This Means If You're the Developer

I want to share that I believe there is goodness to be had out here for the developer. I think a lot of the conversation about AI and developer careers is either unrealistically optimistic or quietly terrifying, and neither framing is actually useful.

The "gotta learn YAPL" anxiety? That part is genuinely getting better. If AI is doing the implementation, the language you're operating in matters less in terms of your daily cognitive load. The orchestration layer — prompting, reviewing, testing, steering — is increasingly language-agnostic. You don't need to have internalized the Rust borrow checker to direct an AI agent that has. You need to understand what you're asking it to build, why, and how to tell if it got there.

This is, on balance, good news for developers with a few years of experience. The architects and system designers — people who have built up strong mental models of how systems fit together, what the failure modes look like, what the security surface area is — those people become more valuable, not less, as implementation gets delegated. The judgment that comes from having shipped things and watched them break in production is exactly the kind of thing AI can't replicate from a prompt.

The trickier picture is for developers who are mid-career but whose primary value has been execution competence rather than architectural judgment. The research from O'Reilly and CIO Dive puts it plainly: AI is compressing the middle of the career ladder most aggressively. The path from junior to senior is getting shorter for those who adapt. The plateau where you could coast on solid implementation skills is shrinking.

The practical implication: if you're a developer thinking about where to invest your growth energy right now, I'd argue you want to be building toward one of two positions. Either deep architectural and system design judgment — the skills that make you a better orchestrator of AI agents — or genuine specialization in the domains where human expertise still matters: security reasoning, performance profiling, domain-specific logic that requires understanding context AI doesn't have. The YAPL treadmill is slowing down. The judgment treadmill is not.

Rust specifically is worth understanding even if you're not writing it yourself. Not because you'll be writing it, but because you'll be reviewing it, directing agents to write it, and making architectural decisions about when it's the right tool. Understanding what Rust's ownership model is protecting you from is a different skill than knowing how to write it. The former is the kind of thing a good orchestrator needs. You don't have to learn it to master it. You do have to learn it to supervise it.

What This Means If You're the CTO

The language decision has always been a human resources decision masquerading as a technical one. When you chose Go over Rust three years ago, you weren't just choosing a technical tradeoff — you were choosing the shape of the hiring pool, the ramp-up time for new engineers, the cognitive load you were willing to impose on your team, and the tribal knowledge dependencies you were comfortable with.

Most of those factors are changing.

If you can generate production-quality Rust with AI tooling, the hiring argument for staying with a less optimal language weakens considerably. You're no longer primarily hiring for people who will write Rust from scratch — you're hiring for people who can direct, review, and reason about Rust. That's a different, and ultimately less constrained, talent market.

The security argument for Rust, meanwhile, has only gotten stronger. Memory safety vulnerabilities — use-after-free, buffer overflows, data races — account for approximately 70% of the CVEs Microsoft patches each year. These aren't edge cases. They're structural. And they're the exact class of bugs that Rust's type system prevents by design, not by convention or practice. At a moment when AI is writing nearly a third of new production code and that number is rising fast, the question of what language those AI-generated systems are written in is a security question as much as a performance question.

The practical read for a CTO thinking about stack strategy over a five-year horizon: consolidation is not just possible, it's probably prudent. Not "all Rust everywhere" — that's not how this works — but a deliberate move toward a smaller number of well-chosen languages with a clear rationale for each one. Python for AI/ML and data work, where its ecosystem is irreplaceable and it's only gaining dominance. Rust for systems, infrastructure, and anything where security and performance are first-class requirements. Go where simplicity, readability, and team-wide mastery are the primary constraints — it still wins that argument convincingly for a large class of backend and services work, and the fact that AI changes the ROI calculus elsewhere doesn't change Go's genuine strengths. TypeScript for web surfaces where JavaScript is essentially a runtime constraint. And then a serious, honest look at everything else in your stack and a conversation about whether it's still earning its seat at the table.

The org chart implication is real too. If AI is handling the language-specific implementation details, the value of hiring around language specialization drops. The value of hiring around judgment, domain expertise, and architectural thinking rises. That's a reshaping of how you evaluate candidates and how you structure teams — not a staffing reduction, but a different kind of staffing.

The Part That's Actually Still a Question

I've been arguing so far that AI is driving consolidation toward existing high-quality languages — Rust, Python, TypeScript — by lowering the human cost of using the ones that were previously too difficult. I believe that's true and the data supports it.

But there's a second-order question that I keep turning over, and I don't have a clean answer to it: as AI becomes both the primary author and the primary executor of code, does the human-readability constraint that has shaped every programming language since FORTRAN start to erode?

Every language we've ever built has been designed, at some level, for humans to write and read. The syntax, the abstractions, the error messages — all of it is tuned for the human in the loop. Even when we've optimized ruthlessly for machine performance (assembly, C), we've still left handholds for human comprehension.

What happens when the human is primarily in the review and direction seat, not the authorship seat?

Mojo is the earliest serious answer to this question. Built by the team at Modular, it's a Python-compatible language designed specifically for AI workloads — GPU kernels, inference pipelines, systems where performance is measured in fractions of a millisecond and the bottleneck is hardware utilization, not human readability. Early benchmarks show 10,000× to 35,000× improvements in certain workloads. It's reached 1.0 imminently, its core components have been open-sourced, and AI startups are already using it in production inference pipelines.

Mojo wasn't designed by AI. But it was designed for AI workloads, with the understanding that the bottleneck in those workloads isn't developer ergonomics — it's raw execution efficiency. That's a different design philosophy than anything that came before it.

The more radical possibility — languages whose syntax and structure are optimized for machine authorship rather than human readability — doesn't have a mainstream example yet. But the conditions that would produce such a thing are coming into view. If you are building systems where AI writes 80% of the code and humans review output rather than craft input, then "is this readable?" becomes a less central design constraint than "does the AI generate correct, safe, efficient implementations?" Those aren't always the same optimization target.

I'm not predicting that Python gets replaced by something humans can't read. The constraint of human oversight isn't going away, and there will always be a need for at least one layer of the stack to be legible to the people responsible for it. But I do think the design philosophy of future languages will be shaped by this question in ways we haven't fully grappled with yet. The history of programming languages is the history of managing the distance between human thought and machine execution. AI shifts where that distance actually lives.

Where I Land

I've spent a fair amount of this series arguing that AI changes the constraint, not the job. The sprint piece was about measurement — we built instruments calibrated for human coding speed, and now the constraint has moved. The amplifier piece was about execution — if shipping isn't the bottleneck anymore, knowing what to build is.

This one is about the scaffolding underneath both of those. The language question has always been a proxy for deeper questions: who's doing the work, what are their actual costs, and what are we optimizing for?

AI doesn't eliminate those questions. It changes the answers.

For developers: the relief from YAPL treadmill anxiety is real, but the replacement obligation is architectural judgment and domain expertise — and that's actually a better trade, if you're willing to make it.

For CTOs: consolidation toward fewer, better languages is now practically achievable for the first time. The blocker was always human productivity cost. That cost is changing. The security and performance arguments for better language choices — Rust, specifically — were always sound. Now the organizational arguments are catching up.

And for the rest of us watching what AI does to the craft of building software: the most interesting question isn't which language wins. It's what the concept of a "programming language" looks like when the primary author isn't human.

I'm making these observations in real time, from inside a landscape that is shifting faster than any analysis of it can fully capture. In a sense, I've taken the red pill — and the rabbit hole turns out to have a lot more floors than the lobby suggested. What I can tell you is what I see on the way down. The rest, we figure out together.

This is part of an ongoing series on how AI is reshaping software development — not just what we build, but how we think about building it.