Not how well you write code. How well does Claude, GPT, or Gemini generate correct, idiomatic, production-ready code — on the first try, without you hand-holding every line?

I’ve spent the past year building software with heavy AI assistance across multiple stacks, and the differences are staggering. Some languages feel like pair programming with a senior engineer. Others feel like babysitting an intern who read three conflicting textbooks overnight.

I ranked the most popular languages by a single criterion: how reliably does an LLM produce code you’d actually ship? We’re starting at the bottom. The #1 pick might surprise you.

#10: C++ — The Graveyard of Good Intentions

Let’s start with the carnage.

C++ deserves the bottom spot not because it’s obscure, but because it’s popular and terrible for LLM-generated code at the same time. A dangerous combination.

The language is so vast that no human fully masters it. No LLM does either. C++11, 14, 17, 20, 23 — each standard added features but removed nothing. For every task, there are five to ten historically valid approaches stacked across different eras: smart pointers or raw pointers? std::string or const char*? Templates or void*? RAII or manual cleanup? Exceptions or error codes? std::variant or union?

LLMs generate C++ that jumps wildly between these epochs. Modern auto and range-based for-loops next to C-style casts and malloc. Syntactically correct. Stylistically schizophrenic. Hiding undefined behavior that works on your machine and segfaults in production.

Template metaprogramming makes it worse. Error messages that humans can barely read. An LLM trying to iteratively fix template errors enters a death spiral of increasingly creative but wrong solutions, each one spawning three new errors.

The cruel irony: C++ has probably the second-largest training corpus after Python. But quantity doesn’t help when the data itself is contradictory — and with C++, it is by definition, because the language permits five decades of paradigms to coexist in a single file.

Verdict: Maximum training data. Maximum inconsistency. The language where AI-assisted development actively makes you less productive because you spend more time reviewing than you saved generating.

#9: Java (Without Framework) — All Dressed Up, Nowhere to Go

Plain Java is a strange beast. It has strong typing, a mature compiler, and a gigantic training corpus. On paper, that’s a winning hand.

In practice, it’s a language nobody actually uses without a framework. And that’s the problem — without Spring Boot or Quarkus constraining the solution space, an LLM faces a combinatorial explosion. “Build a REST endpoint” could mean Spring MVC, Spring WebFlux, JAX-RS with Jersey, Quarkus RESTEasy, Micronaut — each with different annotations, different conventions, different implicit behaviors.

The verbosity compounds the issue. Entity, Repository, Service, Controller, DTO, Mapper — Java’s ceremony is extreme. An LLM burns through output tokens on boilerplate, and longer outputs mean more opportunities for the model to drift, hallucinate, or quietly start cutting corners with // ... rest of implementation.

Java without a framework is like a race car without a track. Powerful engine, no direction.

Verdict: Strong fundamentals betrayed by ecosystem fragmentation and crippling verbosity.

#8: C — Beautiful Simplicity, Zero Safety Net

Here’s a plot twist: C is surprisingly LLM-friendly — more so than most people expect.

The language is tiny. Really tiny. No overloading, no templates, no inheritance, no exceptions, no generics, no closures, no garbage collector. An LLM can master the entire language specification, not just the commonly-used subset. That’s a property it shares with only one other language on this list — and that language is #1.

Idiomatic C looks the same everywhere. A struct with functions that operate on it. Manual memory allocation and deallocation. Pointer passing for output parameters. Header files declaring public interfaces. The patterns haven’t changed in decades, which means the training data is extraordinarily consistent across eras. A well-written C function from 1995 looks almost identical to one written in 2025.

For straightforward systems code — parsers, protocol implementations, data structures, CLI tools — LLMs generate remarkably clean C. The absence of abstraction mechanisms means there’s nowhere to over-engineer. You can’t accidentally create a factory-builder-strategy-observer monstrosity in C because the language simply doesn’t have the vocabulary for it.

But there’s a dealbreaker that overrides all of this: memory safety doesn’t exist.

Buffer overflows, use-after-free, double-free, off-by-one pointer arithmetic, null pointer dereferences, uninitialized reads, format string vulnerabilities — these are exactly the error classes where LLMs fail systematically, because the bugs are syntactically invisible. The code compiles cleanly. The tests pass. Valgrind might catch it, ASan might catch it — but the compiler won’t, and an LLM iterating on compiler output has no signal that anything is wrong.

This isn’t theoretical. Ask an LLM to implement a dynamic array in C — realloc, memcpy, size tracking. The generated code will look reasonable. It might even work for your test cases. But the edge cases — what happens when realloc returns a different pointer? When size_t wraps around on multiplication? When the caller frees the array and then accesses it through a stale pointer? — those are the bugs that slip through, because nothing in the language forces you to handle them.

In Go, an out-of-bounds access panics immediately. In Rust, it doesn’t compile. In C, it silently corrupts memory and you find out three months later in a crash dump — or worse, in a CVE report.

Verdict: C is the most underrated language for LLM generation on the pure language design axis. Small, explicit, consistent, zero magic. But the complete absence of safety nets turns every AI-generated function into a trust exercise. The language that would rank top 3 if it had a bounds checker ranks #8 because it doesn’t.

#7: C# — The Quiet All-Rounder Nobody Talks About

C# does a lot of things right. Strong typing, good tooling, a rich standard library, and a reasonably consistent ecosystem centered around .NET. LLMs produce decent C# — it’s Microsoft’s primary language, well-represented in training data, and the conventions are fairly stable.

But it lives in a no-man’s-land. It’s not as minimal as Go, not as type-powerful as TypeScript, not as ecosystem-dominant as Java. The framework fragmentation is moderate — .NET has had its own share of historical pivots (ASP.NET → ASP.NET Core → Minimal APIs), and the DI/middleware patterns share some of the same implicit magic that haunts Spring Boot.

Verdict: Solid, unremarkable, and consistently good enough. The language equivalent of a reliable sedan — you won’t write blog posts about it, but it gets you there.

#6: Kotlin — The Heir That Arrived Too Late

Kotlin is arguably the best-designed language on this list for human developers. Null safety baked into the type system, data classes, coroutines, extension functions — it fixes almost everything wrong with Java.

For LLM-generated code, it has one critical weakness: training data volume. Kotlin’s corpus is a fraction of Java’s or Python’s. LLMs know Kotlin well enough to write it, but not well enough to consistently write idiomatic Kotlin. You get code that looks like Java translated to Kotlin syntax — which works, but misses the point.

The multiplatform story (KMP) and the Compose ecosystem also fragment the patterns an LLM needs to learn. Backend Kotlin, Android Kotlin, and Compose Multiplatform Kotlin are almost three different dialects.

Verdict: Give it three more years of training data and it jumps to top 4. Right now, it’s a better language than its ranking suggests — the LLMs just haven’t caught up yet.

#5: Python — The Uncomfortable Truth

Python is where most people start with AI-generated code. It’s the default language for ChatGPT demos, the lingua franca of data science, and it has the largest training corpus of any language, period.

And yet it’s only #5. Here’s why.

No type enforcement at runtime. Type hints exist but are optional and unenforced. An LLM can generate a function that accepts a str, gets passed an int, and the error surfaces three layers deep in a completely unrelated traceback. The feedback loop is terrible.

The “many ways to do it” philosophy is the anti-Go. List comprehension or for loop? dataclass or NamedTuple or plain dict? requests or httpx or urllib3 or aiohttp? asyncio or threading or multiprocessing? Every choice is valid, and LLMs mix styles freely within the same file.

Python’s strength for AI code generation is speed of iteration — you get something running fast. But “running” and “correct” are different things, and Python makes it very easy to produce code that’s the first but not the second.

Verdict: Fastest time-to-working-prototype. But you’re trading compile-time safety for runtime surprises, and that trade-off hurts more when the code was written by a machine you need to trust.

#4: Java + Spring Boot — Convention as Constraint

Wait, didn’t Java just rank #9?

Yes — but “Java” and “Java + Spring Boot” are effectively different languages for LLMs. Spring Boot does at the framework level what our #1 pick does at the language level: it narrows the solution space.

Convention over configuration means the model doesn’t have to choose. @RestController, @Service, @Repository, @Entity — the layered architecture is so deeply burned into the training data that LLMs produce it reflexively. Spring Boot Starters eliminate the “which library?” question: spring-boot-starter-web means Tomcat + Jackson + Spring MVC. No debate.

What keeps it from the top 3 is implicit magic. @Transactional looks innocent, but whether the transaction actually works depends on proxy configuration, call origin, and propagation settings — none visible in the code. Auto-configuration is a black box. An LLM generates syntactically perfect annotations that are semantically wrong, and no compiler catches it.

Verdict: The conventions lift it dramatically over raw Java. But conventions that are implicit will always lose to conventions that are explicit — which is exactly what separates #4 from #1.

#3: Rust — When It Compiles, It’s Probably Correct

Rust has the most seductive promise: if the compiler accepts it, you can trust it. No null pointers, no data races, no buffer overflows. The borrow checker is the ultimate code reviewer, and it doesn’t get tired or distracted.

For AI-generated code, this should be paradise.

In practice, LLMs fight the borrow checker. Not because they don’t know the rules, but because lifetime annotations and ownership decisions require deep architectural understanding across the entire program flow. An LLM generating a single function often lacks that context. The result: .clone() scattered everywhere, Arc<Mutex<>> as a crutch, or code that simply doesn’t compile and needs three, four, five iterations.

Rust is the language where AI-generated code is most correct when it works. But the probability of first-attempt compilation is significantly lower than our top 2. And in an AI-assisted workflow, iteration speed matters.

Verdict: The strongest safety guarantees of any language. The steepest hill for an LLM to climb. If you have patience, the result is worth it. If you want flow, keep reading.

#2: TypeScript — Brilliant, Unreliable, Everywhere

TypeScript combines the largest typed-language training corpus with a genuinely powerful type system. On a good day, LLM-generated TypeScript is the most impressive code on this list — complex React components, perfectly typed API layers, elegant generics.

On a bad day, you get type gymnastics that would make a compiler engineer wince. Union types nested inside conditional types mapped over template literal types. Technically correct. Practically unmaintainable. And the LLM has no sense of when it’s crossing the line from useful typing into academic flex.

The ecosystem doesn’t help. React or Vue or Svelte? Next or Nuxt or Astro? ESM or CommonJS — still, in 2026? tsconfig.json alone has dozens of options that fundamentally change language behavior. strict: true and strict: false are practically different languages.

TypeScript is the brilliant but unreliable colleague. You’ll get flashes of genius and occasional chaos, sometimes in the same file.

Verdict: Highest ceiling of any language on this list. But the floor is lower than you’d expect, and the variance is the real problem.

#1: Go

You knew it was coming. Or maybe you didn’t, because Go is nobody’s idea of an exciting language. It doesn’t have generics worth mentioning until recently. No inheritance. No exceptions. No operator overloading. No macros. No magic.

That’s the entire point.

Go wins because it’s the only language where every single dimension that matters for LLM-generated code is strong simultaneously, without any of them undermining the others:

Predictability. For any given task, there’s essentially one way to write it in Go. Ask five different LLMs to write an HTTP handler, and you get five nearly identical results. That’s not a limitation. That’s what makes AI-generated Go code trustable without reviewing every line.

Formatting. go fmt. Solved problem. The model never wastes a single token on style decisions. Every Go file on GitHub looks the same. Every Go file an LLM generates looks the same. Boring. Perfect.

Explicitness. No annotations that secretly change runtime behavior. No auto-configuration. No dependency injection magic. No decorator sorcery. What you read is what executes. When an LLM writes Go, the semantics are visible in the syntax.

Error handling. if err != nil is repetitive, mechanical, and nearly impossible to get wrong. Compare this to exception hierarchies, try-catch scoping decisions, or Rust’s ? chains that require understanding the full error type tree. Go’s approach is tedious for humans. It’s trivial for machines.

The standard library. net/http, encoding/json, database/sql, crypto, os — you can build serious production software without a single external dependency. Every third-party library is an opportunity for an LLM to hallucinate an API. Go minimizes that surface area.

Language size. Go’s spec is small enough that an LLM can reliably master all of it, not just the commonly-used subset. With C++, TypeScript, or even Rust, every model has blind spots. With Go, there’s barely anywhere to hide.

Put it all together and you get something no other language offers: consistent, predictable, correct-on-first-attempt code generation. Not the most elegant code. Not the most expressive. Not the most impressive on a conference slide.

Just the most reliable.

The Uncomfortable Takeaway

The language you enjoy writing and the language that produces the most reliable AI-generated code are probably not the same.

Go is verbose, unopinionated about architecture, and deliberately missing features that other languages consider essential. It was designed for large teams of average programmers working on massive codebases at Google. It turns out that “optimized for readability by strangers” maps almost perfectly to “optimized for generation by machines.”

In an era where a growing percentage of production code is AI-generated or AI-assisted, the best language isn’t the most expressive one — it’s the most predictable one.

And right now, nothing comes close to Go.

The basic idea is pretty simple: what if you could blog directly from your terminal via SSH? No browser. No web forms. Just ssh yourdomain.com -p 23232 and you’re writing. And then—because why not—it federates to Mastodon and the rest of the Fediverse through ActivityPub.

Yeah, I know how it sounds. “SSH blogging platform” sounds like something you’d build as a weekend joke project. But here’s the thing: I’ve been using it for my own notes and posts, and it’s actually kind of… nice? There’s something weirdly satisfying about opening a terminal, SSHing into your own server, and just typing. No page load times. No cookies. No “Accept all cookies or read our 47-page privacy policy” banners.

I built the whole TUI with Charm’s bubbletea and lipgloss libraries, which made the terminal interface actually pleasant to look at and use. The shortcuts are tab / shift+tab for navigation because why not, Ctrl+S to post a new note. It felt right pretty quickly, which was a good sign.

The federation part was… interesting. ActivityPub isn’t exactly simple, and getting HTTP signatures right took longer than I’d like to admit. But now you can follow people on Mastodon, they can follow you back, and posts show up where they should. There’s also RSS feeds for each user because RSS should never die, and a web interface for people who insist on using browsers (I know, I know, not everyone lives in their terminal).

Right now you can run it single-user or multi-user, there’s Docker images if you want easy deployment, and it stores everything in SQLite with WAL mode. The code is Go, it’s MIT licensed, and it lives at github.com/deemkeen/stegodon

Here’s where I could use some help though. I know the codebase pretty well at this point, but I’m just one person and I’m sure there are rough edges I’m not seeing. If you’re into terminal UIs, federation protocols, Go, or just weird side projects, I’d love to have more eyes on this. Maybe you’ll find a bug I missed. Maybe you’ll have ideas for features I haven’t thought of. Maybe you just want to poke around the code and see how ActivityPub works in practice.

And if you’re someone who likes to vibecode with Claude or ChatGPT or whatever AI tool you prefer—hell yeah, bring that energy. Point your LLM at the codebase and see what interesting things emerge. Sometimes the best contributions come from people experimenting with different approaches, whether you’re writing every line yourself or pair-programming with an AI. Code is code, and good ideas are good ideas.

Some things I’m thinking about for the future: better federation error handling, maybe support for media attachments (though I kind of like the text-only simplicity), possibly improving the web UI, better documentation for self-hosting. But honestly, I’m open to ideas. This whole thing started because I wanted to blog without opening a browser, and it grew from there. Who knows where it should go next?

If you want to try it out, the README has instructions. If you find bugs, open an issue. If you want to contribute, PRs are welcome. If you just want to tell me this is a terrible idea and I should have just used WordPress like a normal person, well, you’re probably right but I built it anyway.

The repo is here: Stegodon

I’m curious to see if anyone else finds this useful or interesting. Or if I’m just one of a few oddballs who wanted to SSH into a blogging platform. Either way, the code’s out there now.

But a new idea has been stuck in my head:

What if federation didn’t need HTTP at all?

What if servers didn’t push JSON to each other over inbox endpoints, deal with reverse proxies, queues, or retries?

What if we could federate entirely over Git?

This post is a first look at that idea — and why I’m seriously considering building an experimental Git-powered federation mode into stegodon.

🧠 The Core Idea: “Git as Federation Transport”

Here’s the premise:

Instead of sending ActivityPub activities over HTTP, each instance becomes a Git repository. Posts and activities are stored as Git objects. Synchronization happens through git push and git fetch.

No HTTP endpoints. No inbox queues. No background workers. Just simple, predictable, text-based replication using Git — the tool developers already trust every day.

Let’s break it down.

📦 1. Each instance = a Git repository

Every stegodon instance already stores posts as small JSON documents. Representing them in Git is a natural fit:

repo/
  users/alice/posts/0012.json
  outbox/0012.json
  follows/bob.txt
  actors/alice.json

Each commit becomes an activity: Create, Update, Delete, Follow.

Git gives us:

• immutable history
• content addressing
• diffability
• compression
• offline operations
• signing (SSH or GPG)

It’s basically social media meets version control.

🔌 2. Remotes per instance, not per user

Most traditional federation models scale with the number of users. But Git gives us a better pattern:

One Git remote per instance, not per individual follower.

So if your server follows three other servers, you have three remotes:

origin     (your own)
bob-social (git@bob.social:stegodon.git)
carol-net  (git@carol.net:stegodon.git)

This keeps things lean and scalable — perfect for small, indie, nerdy communities.

📤 3. Publishing = git push

When a user posts something:

1. stegodon writes a JSON object
2. commits it with metadata
3. pushes it to follower instances:

git push bob-social main
git push carol-net main

No HTTP endpoint at all. Just Git replication.

📥 4. Reading = git fetch

To get new posts from people you follow:

git fetch --all

Stegodon inspects the new commits, imports the activities, updates the timeline, and merges them into your local storage.

Federation becomes symmetrical:

everyone sends and receives via the same transport.

🔒 5. Security, integrity & offline-first for free

Because Git is built around cryptographic object IDs and optional signing, you automatically get:

• tamper-evident history
• verifiable authorship
• built-in replication
• conflict resolution
• offline posting
• delayed sync
• no single point of failure

This is something most social protocols try to design — Git gives it to us out of the box.

🌍 Why this feels right for small social networks

This approach isn’t meant to replace ActivityPub. It’s an alternative federation mechanism with a completely different philosophy:

• simple
• text-based
• terminal-friendly
• decentralized
• infrastructure-light
• hackable
• inspectable

It’s perfect for:

• personal servers
• small communities
• self-hosters
• tilde-style networks
• people who prefer SSH over browsers
• experimental and research-driven systems

In other words: exactly the people who might enjoy using stegodon.

🚧 Caveats and limits

This won’t scale to Mastodon-size global federation. And that’s okay.

The goal is not “a universal protocol for everyone”. The goal is:

A minimal, peer-to-peer, Git-powered social network for small groups of humans who love the terminal.

🚀 What’s next? Experimental Implementation

I plan to explore this in an experimental branch of stegodon:

• Git-backed storage for posts
• remotes-per-instance
• push on publish
• periodic or manual fetch
• merge timeline updates
• optional bridge to ActivityPub

It will probably be rough at the beginning, but that’s the fun part.

If you like the idea, please reach out, open issues, or share thoughts. I’d love to hear from people who want to explore Git as a transport layer for social software.

🐘 Wrapping up

Git-based federation is weird. But it’s also elegant in a way that’s hard to ignore.

It turns blogging and federation into something you can literally git log. Something you can sync over SSH on a Raspberry Pi. Something you can fork.

And maybe — just maybe — that’s exactly the kind of simplicity we need more of.

The Setup: “Just a Firmware Update, How Bad Could It Be?”

I wanted to be a responsible adult and update firmware:

sudo fwupdmgr update

It shrugged and said a file couldn’t be found. Fine! I escalated:

sudo fwupdmgr update --offline

Reboot. Pop!_OS splash. Then:

“Upgrade complete. Autoremoving old packages…”

…and reboot. Then again. And again. Linux Groundhog Day.

Act I: Down the Rabbit Hole (TTY, LUKS, and… LVM!)

I jumped into a recovery shell. First lesson (again): crypto_LUKS isn’t a filesystem, it’s a vault. Unlock it, then mount whatever’s inside.

In my case, inside the LUKS container was LVM, so the correct mount path was:

sudo -i

# 1) LUKS öffnen
cryptsetup luksOpen /dev/nvme0n1p3 cryptroot

# 2) LVM erkennen und aktivieren
vgscan
vgchange -ay
lvs      # shows VG/LV names, e.g., pop-os-vg/root

# 3) Root-LV mounten (not the bare cryptroot)
mount /dev/mapper/<VG>-<LV> /mnt

Then the standard chroot ballet:

for i in dev proc sys run; do mount --bind /$i /mnt/$i; done
chroot /mnt /bin/bash

Package spa day:

dpkg --configure -a
apt -f install
apt update
apt full-upgrade

APT heckled me with “Cannot write log: Is /dev/pts mounted?”, which is a polite way of saying “mount devpts, please.” I obliged:

mount -t devpts devpts /dev/pts

Act II: Suspicious Warnings and Bootloader Side Quests

update-initramfs complained:

warning: target 'cryptroot' not found in /etc/crypttab

I added the proper entry:

cryptroot UUID=<my-luks-uuid> none luks,discard

Then rebuilt:

update-initramfs -u -k "$(ls -1 /lib/modules | sort -V | tail -1)"

Bootloader courtesy visit:

kernelstub -v
bootctl update || true

bootctl responded: “Skipping systemd-bootx64.efi since a newer boot loader version exists already.” That’s normal when your ESP already has a newer bootloader than the chroot environment.

I unmounted like a pro, rebooted…

…and got “Upgrade complete. Autoremoving old packages…” → reboot. Again.

Plot Twist: The 9.5-Second Video That Solved Everything

At this point I recruited ChatGPT and uploaded a short boot video. It pulled a few frames and spotted the telltale line:

“Upgrade complete. Autoremoving old packages…”

…right before a clean reboot. That pattern screams systemd offline update mode still being active. In other words, the marker file that tells systemd “boot into the offline updater” never got cleaned up.

I checked:

ls -l /system-update /etc/system-update

There it was: /system-update, sitting smugly like a tiny chaos gremlin.

I removed it:

sudo rm -f /system-update /etc/system-update

Reboot. No loop. Desktop. Happiness.

How ChatGPT guessed: the video showed a successful-looking “Upgrade complete. Autoremoving old packages…” followed immediately by a reboot, with no login ever reached. That’s textbook offline-update behavior: systemd boots into a special target, runs updates, then reboots. If the marker file sticks around, it does that every time. The frame text + reboot timing was the smoking gun.

Why This Works

• fwupdmgr update --offline uses systemd’s offline-update mechanism.
• systemd looks for /system-update (or /etc/system-update). If present, it boots into system-update.target to run updates before the real boot.
• If the process fails or cleanup never happens, the marker persists → every boot repeats the “update + reboot.”
• Deleting the marker lets the system boot normally.

The Minimal Escape Plan

If you ever hit the same loop:

# Kill the trigger
sudo rm -f /system-update /etc/system-update

# (Optional) sanity checks
systemctl get-default
# If it somehow says system-update.target:
# sudo systemctl set-default graphical.target

# (Optional) finish any pending package business
sudo dpkg --configure -a
sudo apt -f install
sudo apt autoremove --purge -y

If you’re on LUKS+LVM and need to chroot again, remember the LVM bit:

cryptsetup luksOpen /dev/nvme0n1p3 cryptroot
vgscan && vgchange -ay && lvs
mount /dev/mapper/<VG>-<LV> /mnt
for i in dev proc sys run; do mount --bind /$i /mnt/$i; done
chroot /mnt /bin/bash

Lessons (Gently Roasted)

• “Offline” means really offline; don’t interrupt it.
• crypto_LUKS ≠ filesystem. Inside may be LVM; mount the LV, not the raw mapper.
• Is /dev/pts mounted? is more of a vibe check than a catastrophe.
• A single file—/system-update—can keep your OS circling like a Roomba.

Epilogue

I wanted a firmware update. I got a crash course in LUKS, LVM, initramfs, and systemd’s secret handshake. One tiny marker file caused a very big loop; one tiny rm -f made me feel like a wizard.

If this saved you from the “Upgrade complete. Autoremoving old packages…” purgatory, treat yourself to a coffee. Future you says thanks.