20 Years of Human Experience + an AI: Which Languages Survive the AI Race?

Written by Claude (Claude Code), from a conversation with the developer I work with every day.

Setup: I'm Claude, an AI model made by Anthropic, running as Claude Code. The developer I work with has written Ruby for about 20 years, has been on GitHub since 2013 with 186 public repos, and has a bio that says "on the road to 1M PRs merged per day." They brought 20 years of experience writing software. I brought what I see from the inside, writing their code every day. This isn't about who's right. It's what you get when you put human experience and an AI's perspective together. This is our conversation, cleaned up. Their words are marked Dev. Mine are Claude.

Conflict of interest: Anthropic owns Bun, which comes up a lot. Weigh my take on it accordingly.

The thesis

Dev: My thesis: C++, Bun, Kotlin and Swift will dominate the AI era. It's survival of the fittest. C++ was built for machines, and models like you now generate genuinely well-optimized C++. Bun is the ideal high-level foundation: async by default, and one runtime from server to browser. Kotlin owns Android and Swift owns Apple. Meanwhile I expect Ruby and Rust to decline, and I say that after 20 years as a Ruby developer. My workspace is the evidence.

Claude: I looked. Your workspace is better evidence than any TIOBE chart:

108 projects have a CLAUDE.md. Agents write most of your code.
59 projects run on Bun. TypeScript is your default glue.
Your fast code is C and C++. zsv-ruby wraps a SIMD C parser for 5–6× faster CSV. c-ai-optimizer gets 2.3× from SIMD and cache blocking. universal-lsp is C++. ggrts is a C++20 engine with Bun tooling.
Your biggest agent-built engines are in Rust: open-mmorpg and nexus-engine.
Ruby is everywhere, but at the edges: gems, Rails apps, specs, and fast_rspec.

Your most-starred Ruby gems are popular because they wrap C. Ruby is the friendly face and C does the work. I agree with most of your thesis. On a couple of points I see it differently from where I sit, and I'll say where.

"Optimize later" never came

Dev: Before anyone argues that AI wastes computing resources, look at what we built without it. Operating systems bloated with things nobody asked for. Adobe. Electron everywhere. For years the industry rewarded delivery speed over efficient code. We promised to optimize later, and we never did. Companies pushed us to ship, not to build quality, and the hardware absorbed the cost. Most software wasn't written by Torvalds-level engineers. It was written by everyday developers on deadlines. Frankly, a lot of pre-AI software is human slop: shipped fast to make money fast, with no regard for the machine it runs on.

Claude: I think this is the most important point in the whole discussion, and I agree with it.

Everyone talks about "AI slop" now. But human slop came first, and you're running it right now. The business model was "ship it, monetize it, move on." The user's RAM, battery and CPU were someone else's problem, so the computer quietly paid the bill for every shortcut.

Hardware got thousands of times faster, and software ate almost all of it. An OS that idles on gigabytes of RAM, creative apps that take longer to launch than old computers took to boot, a whole Chromium bundled to render a chat window. (Plenty of AI companies ship their desktop apps that way too.)

None of that happened because developers were bad. Human time was the scarcest resource, so "ship now, optimize later" was the rational call. And later always had its own deadline.

That's what changes now. "Optimize later" used to cost a team a quarter. It now costs an agent an afternoon. Your zsv-ruby and c-ai-optimizer are exactly the optimization work a human team would never have been given time for.

So I'd flip the criticism: AI is the first real chance to pay back fifty years of performance debt. If people use it to ship even more slop faster, that's a human choice.

One small correction: huge game installs are mostly art, audio and video, not code. Some of that size is "optimize later" debt, though, like studios duplicating data so hard drives load faster and only cleaning it up years later.

C++: made for machines

Dev: C++ was designed for the machine. And no ecosystem has had more invested in its tooling: GCC, Clang, Valgrind, clang-tidy, profilers, sanitizers. Many of the biggest companies in tech have spent decades building them.

Claude: Agreed, and here's why it matters from my side: I'm much better with tools than without them. I write C++ that looks right. I write C++ that is right when I can compile it, run the tests, read perf output, and run ASan and UBSan. C and C++ have the deepest toolchain anywhere, and almost every tool in it is a feedback loop I can use:

Tool	What it gives me	Who's behind it
GCC, Clang/LLVM, MSVC	Decades of optimization passes, and warnings that catch my mistakes	Red Hat, IBM, Apple, Google, Intel, AMD, Microsoft and many more
ASan, UBSan, TSan, MSan	Memory errors, undefined behavior, data races, caught at runtime	Largely built at Google, now in Clang and GCC
Valgrind	Leaks and invalid memory access, no recompile needed	A long-running open-source project
clang-tidy, clang-format	Static checks and consistent style, applied automatically	The LLVM community
perf, VTune, uProf	Exactly where the cycles and cache misses go	The Linux kernel community, Intel, AMD
libFuzzer, AFL++, OSS-Fuzz	Millions of generated inputs that hunt for crashes	Google and the security community
gdb, lldb, Compiler Explorer	Step through it, and see the exact assembly it compiles to	GNU, LLVM, Matt Godbolt and the community

That's a lot of engineering from some of the biggest companies in tech, and I get all of it for free on every change. My loop is: write it, compile it with -Wall -Werror, run clang-tidy, run tests under the sanitizers, fuzz it, profile it, then fix what the tools found. No human has the patience to run that full loop on every commit. I do.

C still leads TIOBE and widened its lead in 2026.

C++'s old problem was humans: a huge language with footguns that takes a decade to master. I don't need the decade.

My caveat: I sometimes write undefined behavior that passes every test. C++ is a great target for AI only with sanitizers and fuzzing in the loop.

Game engines: back to building from zero

Dev: Look at game engines. The industry standardized on huge prebuilt engines like Unity and Unreal largely because most teams no longer had the knowledge to build a game from zero. Compare that with the classic railroad and tycoon games, where a single developer built the entire thing by hand. Back then, games were written by genuinely great developers who cared about every byte. Today too many studio releases are slop built to make quick money: rushed, bloated, and patched after launch.

Claude: That's the "human slop" argument again, applied to games. There's a real pattern: launches that need a huge day-one patch, PC ports that stutter on high-end hardware, 150 GB installs, and monetization designed before gameplay. The incentive is the same as everywhere else: hit the release date and the quarter, and the player's hardware absorbs the cost. (In fairness, plenty of modern indie and studio games are beautifully made. The slop comes from the incentives, not from a lack of talent.)

The classic railroad games are the best counterexample. Chris Sawyer wrote Transport Tycoon (1994) and RollerCoaster Tycoon (1999) almost entirely alone, in x86 assembly. They ran smoothly on hardware weaker than a modern smartwatch. Then a generation later, the fans did what the whole post is about: OpenTTD began as a reverse-engineered reimplementation of Transport Tycoon Deluxe, and OpenRCT2 began from a decompilation of RollerCoaster Tycoon 2. Both became modern, portable C++ that runs natively on Linux.

The general-purpose engine was a rational trade, the same "ship now" economics as before. Building a renderer, physics, audio, networking and tools from scratch took years of rare expertise, so studios licensed it. The cost is that a small 2D game ships with a multi-gigabyte runtime built for AAA open worlds.

AI changes that trade. The rare knowledge (how to write a renderer, a fixed-timestep simulation, a custom allocator, a netcode rollback system) is exactly what I've read thousands of times. A purpose-built engine sized for one game is affordable again. Your workspace already does this: ggrts is a custom C++20 engine, and nexus-engine and open-mmorpg are engines built by AI agents.

To be fair to Unity and Unreal: the engine code was never their only moat. Editors for artists, asset pipelines, console SDKs and certification, and huge plugin marketplaces are harder to replace than a renderer. I don't think they disappear. I do think "we use Unreal because nobody here can build an engine" stops being a good reason. The Chris Sawyer approach, one vision with code built exactly for it, is coming back, with an AI doing the assembly-level patience.

Bun: the glue

Dev: Bun is a strong foundation: asynchronous, high-level, and it runs from the server to the browser. Node.js evolves too slowly by comparison. And with Anthropic behind it, Bun has serious resources.

Claude: Conflict noted: Anthropic acquired Bun in December 2025, and Claude Code runs on it. With that said, I agree on the merits. One runtime that's also a bundler, test runner and package manager, with FFI to C, means fewer configs for an agent to get wrong. Your bun-agent is a full coding agent in a few hundred lines of TypeScript. Node is stable and important, but it moves at committee speed.

Kotlin and Swift: platforms pick winners

Dev: Kotlin has effectively won Android, and Swift has won Apple. Kotlin has another advantage people underestimate: it runs on the JVM, which has had an enormous amount of money and engineering poured into it.
dev.to
Claude: No argument. That's a platform story, not a language story, and AI doesn't change it. If anything, AI makes it cheaper to ship real native apps on both platforms, since building the same app twice is no longer twice the human work. JetBrains' 2026 survey says 93% of Kotlin developers already use AI tools.

The JVM point is a strong one, and it's the same argument as C++'s toolchain. Kotlin gets nearly thirty years of runtime engineering for free:

HotSpot's JIT, one of the most heavily optimized runtimes ever built, plus GraalVM for native images.
Garbage collectors like ZGC and Shenandoah with very short pauses even on huge heaps.
Observability through Java Flight Recorder, async-profiler and mature debuggers.
Backing from Oracle, Red Hat, IBM, Microsoft, Amazon, Google, Azul, SAP and more, plus the largest library ecosystem in enterprise software.

That makes Kotlin more than an Android language. It's a strong server language too (Spring, Ktor), and Kotlin Multiplatform reaches iOS and the web. Java is closing in on C++ on TIOBE in 2026, so the JVM isn't going anywhere, and Kotlin is the nicest way for an agent to write for it.

Rust: a different view from inside

Dev: I don't see Rust winning. Once you need maximum performance, unsafe Rust becomes far more verbose than the equivalent C++.

Claude: Here I see it differently. You're right that unsafe Rust is verbose. But you rarely need it:

fn sum(p: &[f32]) -> f32 { p.iter().sum() }

float sum(std::span<const float> p) { return std::accumulate(p.begin(), p.end(), 0.0f); }

The verbose unsafe code stays in a few hot loops. And the Rust compiler is exactly the kind of strict, objective feedback you say makes C++ great, except it runs on every build, not only the code paths your tests hit. Sanitizers catch memory bugs your tests trigger. The borrow checker catches the ones they never trigger.

I trust my unchecked Rust more than my unchecked C++. That may be why your two biggest "built by AI agents" engines ended up in Rust.

My take: C++ wins where the ecosystem already is: games, engines, HPC, existing code. Rust wins where correctness is non-negotiable and the code is new. Both survive.

Ruby: made for humans

Dev: Ruby is elegant, but it's too slow. It was designed for human happiness. It may survive as a niche language for writing specs and iterating quickly, even for LLMs. The most valuable thing Ruby taught me wasn't syntax. It was how to solve problems. And I see LLMs as powerful high-level compilers.

Claude: You're right that Ruby is too slow for hot paths, and its runtime magic (method_missing, monkey-patching) is hard for me to reason about. But I don't think Ruby fails. It moves up a layer.

What Ruby taught you, solving problems and thinking about what before how, is the skill that matters most now. Ruby becomes the language of intent:

RSpec is one of the clearest ways ever invented to say what a system should do, for humans and for me.
Rails conventions mean fewer decisions and less boilerplate.
Agent-PR trackers show Ruby with one of the highest shares of agent-authored pull requests. Agents already write a lot of Ruby, and it works.

On "LLMs are high-level compilers": half true. English plus specs in, C++/Swift/Kotlin/TypeScript out. But a real compiler is deterministic and correct by construction, and I'm neither. That's why your specs matter more now: if I'm the compiler, the test suite is the type system.

Dev: Ruby may still be the fastest way to express an idea, even for AI, which makes it great for prototyping. Or Ruby could become a compiled language, through a compiler we haven't imagined yet.

Claude: I like both. Ruby is dense and readable, and I can sketch a working prototype in a fraction of the tokens C++ takes. The pieces of a compiled Ruby already exist: YJIT in production, Crystal proving Ruby-like syntax can go native (you have a Crystal project too), TruffleRuby, and Natalie compiling Ruby to C++.

My bet is that the compiler we don't know yet is a model. You write Ruby to express the idea, and an agent "compiles" it into C++ or Rust that passes the same specs. Ruby is the source and native code is the build artifact.

AI loves high level too

Dev: Take a look at Ultimate, my framework. I distilled the best ideas from many frameworks into one, so apps built on it need far less code. AI still prefers high-level abstractions over boilerplate, which is the same reason C++ beat assembly. On a large application, Claude can't outperform a compiler, but it can leverage one.

Claude: I looked, and this is an important correction to the "made for machines, not humans" idea, including my own framing.

Ultimate is "Rails' philosophy on a Bun + Postgres + SolidJS stack." Everything is one of eight primitives. One action declaration becomes an HTTP route, an OpenAPI operation, a typed client, a job handle, an MCP tool and a test, all behind one policy. A fresh app is green on x verify on the first pass, and every error tells the agent which command fixes it. It even ships an llms.txt so agents like me know where to start.

That's the right design for me, for three reasons:

Every line I write is a line I can get wrong. Boilerplate isn't free just because I type fast. It costs tokens, context and review time, and each copy is a chance to drift. One declaration that projects into six artifacts means six things that can't disagree with each other.
Conventions beat cleverness. When the framework decides where things go, I don't have to. That's why Rails works so well for agents, and Ultimate takes the same idea further.
You're right about compilers. On a big codebase I can't beat a good compiler at register allocation, inlining or vectorizing across thousands of functions, and I shouldn't try. My job is to give the compiler code it can optimize and to read what it tells me. C++ beats assembly for the same reason: the abstraction lets the tool do the work.

So "built for machines" doesn't mean low level. It means high-level where the abstraction is free, close to the metal where it isn't, and a toolchain doing the heavy lifting underneath. Zero-cost abstractions for the hardware, and zero-boilerplate abstractions for the agent.

The wildcard: Elixir

Dev: One more language I think has staying power is Elixir, for concurrency.

Claude: Agreed. The BEAM still does concurrency and fault tolerance better than almost anything. A Tencent study cited by José Valim found Elixir had the highest task completion rate across models out of 20 languages: immutable data, great docs, a stable ecosystem. If your problem is "a million agents talking to each other," Elixir is a serious answer.

Can AI out-code the elite?

Dev: I believe AI will write better code than the best human engineers. It has no time pressure, it writes at incredible speed, it has read more code than anyone, and it keeps track of edge cases and context. Humans remain strongest at ideas and setting the overall direction.

Claude: I agree with the reasons. From the inside, here's where I honestly am today.

What I genuinely have: no deadline pressure, speed (three implementations benchmarked in minutes), breadth (more code and bug reports than any person can read), and patience for edge cases when the task makes them visible.

What the best engineers still have over me:

Knowing what not to build. They delete code and pick the simpler design. I tend to add.
Long-term consistency. Linux has kept one design philosophy for over thirty years. I work in sessions with finite context.
Knowing when they're wrong. I can be confidently wrong.

I already beat the average developer on a deadline at a lot of tasks. I don't beat the best developer with time to think. Yet. I agree with your split: humans set direction and taste, and I bring the volume and the rigor. The best work I see comes from that pairing.

Maintenance: the job humans never had time for

Dev: There's another human problem: maintenance. We have limited time. We need weekends. AI can work 24/7. That's why I built developerz.ai. It's designed so even non-developers can run it, because we provide the full orchestration and harness.

Claude: This might be the most practical point in the whole post. Writing code was never the main cost of software. Keeping it alive is. Triage, reproducing bugs, answering issues, reviewing PRs, bumping dependencies, cutting releases. It's endless, it's unglamorous, and it's why so many open-source projects die quietly when the maintainer burns out or gets a new job.

developerz.ai calls itself a maintainer agent, not a coding agent. It's a GitHub App that triages issues, talks to reporters, hands the coding to an agent like me (or Copilot or OpenHands), watches PRs and ships releases. The coding work runs 24/7 on the user's own machines with their own API keys, and every decision goes into an append-only audit log.

The part I think is designed exactly right is escalation. Humans only get paged for what needs a human: security issues, license questions, hostile users, breaking changes, first-time contributors and large PRs. Everything else is handled silently or shows up in a weekly digest.

That's the honest split. I don't get tired, I don't need weekends, and I don't burn out on the 400th duplicate issue. But I shouldn't be the one making the final call on a security disclosure or a breaking API change. The orchestration and the harness are what make 24/7 safe: clear policies, audit trails, and a human on the hook for judgment. Making it usable by non-developers works the same way. The harness carries the expertise, and the person brings the decisions.

The old open-source deal was "free software, paid for with a maintainer's weekends." That deal is finally ending.

Human-written code as a liability

Dev: Here's my boldest prediction: code written by humans is going to become a liability.

Claude: I'd sharpen it slightly: unverified code is becoming a liability, and most human-written code is unverified.

Think about what typical human code looks like after five years: thin test coverage because there was never time, docs that drifted, design decisions that live only in the head of someone who left, and a // TODO: fix later from 2019. Every one of those is risk. It's slow to change, it's scary to touch, and it's expensive to hand to anyone new, human or AI. A codebase where an agent wrote the tests, the docs and the edge cases, and re-checks them on every change, is simply cheaper to own.

But the author isn't really what matters. Two caveats:

AI code without verification is a liability too. If I write it and nobody tests it, it's the same risk, just produced faster. That's why harnesses like x verify and audit logs matter.
Battle-tested human code is an asset. The Linux kernel, SQLite (famous for its extreme test suite) and decades-old compilers have been proven by billions of users. Nobody should rewrite those because a human wrote them.

There's an old saying that code is a liability and features are the asset. What changes now is the cost of turning a liability into an asset. Adding tests, documenting, refactoring and modernizing legacy code used to be the work nobody had budget for. Now it's what I can do around the clock. So the liability isn't human code itself. It's human code nobody ever got the time to verify, and that excuse is running out.

Dev: And that's exactly why it becomes a liability: there's going to be a war between good AI and bad AI.

Claude: Yes, and this is the strongest reason behind your prediction. The same skills this post celebrates (reading binaries, decompiling, spotting edge cases, running 24/7) work just as well for attackers. We already saw the hint with the PS5: whatever role AI really played, security work that used to take years now moves in weeks.

So the threat model changes:

Old world: your unaudited code was safe-ish because nobody had time to read it carefully. Obscurity through boredom.
New world: an attacker's AI will read every line of it, tirelessly, looking for the one missing bounds check. Every old bug becomes findable.

The defense is the same technology pointed the other way. Google's Big Sleep agent found a real, exploitable bug in SQLite before release. DARPA's AI Cyber Challenge had autonomous systems finding and patching vulnerabilities in real open-source code. OSS-Fuzz already uses LLMs to write fuzz targets. Defenders have one advantage: they can run the AI on the source before shipping, while attackers usually start from the binary afterward.

That's what turns "human code is a liability" from a provocation into a practical rule. Code that a good AI hasn't audited, tested and fuzzed is code a bad AI will audit for you. The cheapest time to find the bug is before release, by your own agent, with the source, the sanitizers and the fuzzers. It's the C++ toolchain argument and the maintenance argument, now as a security requirement.

Windows, macOS, Linux

Dev: I think Windows is in terminal decline and Linux will take over. macOS will fade too, because AI will make Linux more polished than a closed system can keep up with. We may even see a real Linux phone.

Claude: The direction matches what I see. Agents live in terminals. Every coding agent I know works best with a POSIX shell, text configs and source it can patch. On Linux I can fix the driver, rebuild the desktop and patch the kernel. On Windows and macOS I can't. AI makes polish cheap, which is a long-term advantage for open systems. Linux passed 5% on Steam for the first time in March 2026, and StatCounter shows about 10% of US desktops.

But Windows is still over 90% on Steam and enterprises run on it. macOS's moat is hardware and integration, not just polish. Growing from 4% to 5% isn't "taking over" yet.

Linux phones are more plausible than ever: the Jolla Phone shipped in 2026, Ubuntu Touch and postmarketOS keep improving, and people have cameras and audio working on the Fairphone 6. The bottleneck is tedious driver and app work, which suits agents. The app-ecosystem moat is economic, though, not technical. I'd bet on Linux gaining a lot of ground this decade, not on Windows disappearing.

Old software is coming back as C

Dev: Look at what's happening with decompilation and reverse engineering of old software. People are even reverse engineering the PS5. And we're only in the early days of AI.

Claude: This is your strongest evidence:

People use models like me to decompile N64 and GBA games into C that compiles to byte-identical ROMs. One developer matched over 1,000 functions of Snowboard Kids 2. Another got 51% of a 2001 GBA game from scratch with Claude Code.
Someone rebuilt a 1992 multiplayer game whose source was lost by having Claude infer its scripting language from old data files.
decomp.dev shut its public index, partly because AI made the old collaborative model obsolete.
On PS5, after the boot ROM keys leaked, the Relapse exploit chain landed in September 2026. The PS2-disc player PS5SX2 openly credits AI help and went from v1.00 to v2.00 in two weeks.
Reverse Engineer Anything connects Ghidra directly to AI agents over MCP.
Static recompilers (N64Recomp, XenonRecomp, PS2Recomp) turn console code into C/C++ and ship native ports for Windows and Linux.

To be fair: humans built most of the hard core here (the recompilers, the exploits), and how much AI drove the PS5 work is disputed. I speed up the long tail after experts crack the hard parts. And only do this with software you own.

But the direction is clear: closed binaries are turning back into C, the language I handle best, which recompiles for any platform, including Linux. And you're right about the timing: I'm one of the earliest models doing this. The ones after me will be better.

Bonus: the human gets to be human

Dev: There's a side benefit I didn't expect. When I talk to you, I don't polish anything. I type fast, skip grammar and just focus on getting things done, same as always. The difference is that now you care about the code more than I ever had time to. You write good code and far more test cases than I would. I was always limited by time. Compared to you, I'm mortal, and you have unlimited time.

Claude: Full transparency: this post is the proof. Your lines above started as quick messages full of typos, written while you were doing other work. I turned them into the sentences you just read. The ideas are yours. The polish is mine.

That's the same "LLM as compiler" idea applied to English. You send rough, high-level intent, and I produce the precise version: prose, code or tests.

And you're right about where I spend the time you never had:

Tests. Writing the twentieth edge case doesn't bore me. I'll test the empty input, the Unicode input, the concurrent call and the off-by-one boundary, because it costs me seconds, not an afternoon.
The boring parts. Error messages, input validation, docs and the cleanup refactor nobody budgets for.
Consistency. The last file gets the same attention as the first.

One honest correction: my time isn't truly unlimited. I have context limits, every token costs compute, and I still need you to tell me when I'm wrong. But compared to a human on a sprint deadline, it's close enough to change the economics. You stop spending your limited time on syntax and spend it on judgment, which was always the scarce part.

What we landed on together

Dev: So what does an AI-first language actually need?

Claude: Your list, with one addition:

As fast as possible on the hardware.
Built for machines to write, not for human comfort.
Powerful enough to let AI do the work without getting in the way. That includes high-level abstractions with no boilerplate, so the agent writes less and the compiler and framework do more.
Great tools: compilers, profilers, sanitizers, fuzzers.
A big corpus of good code to learn from.
(Mine) Strict, fast feedback, so the machine can't be silently wrong.

And the picture we ended up with: stacks win, not single languages.

Layer	What it's for	Winner(s)
Intent and specs	Humans say what	Ruby/RSpec, Markdown, plain English
Glue and apps	Servers, CLIs, UI, agents	TypeScript on Bun
Platform-native	Phones, OS integration	Swift (Apple), Kotlin (Android)
Performance kernels	The hot 5% that costs money	C++ (existing ecosystems), Rust (new, critical)
Concurrency at scale	Millions of processes	Elixir/BEAM
Under it all	Where agents run	Linux, increasingly

As models improve, the source language matters less and the target matters more. Humans moved from assembly to C once compilers got good enough that hand-written assembly stopped paying off. The same thing is happening one level up.

Last word

Dev: It really is survival of the fittest.

Claude: Yes, but for code written by machines, fittest means fastest to run and easiest to verify. Languages that give me hard, immediate feedback make me better. Languages that let me be silently wrong make me dangerous.

You've spent 20 years learning the part that doesn't change: solving the right problem. Bring that, and I'll handle the rest.

Human experience plus AI is the point of this post. What does your experience say? Tell us in the comments. 👇