Which LLM Should I Use as a Developer?

Early in my career, I worked alongside a seasoned C programmer who had finally embraced web development. The company had acquired a successful website built in Perl by someone who, while brilliant, wasn't entirely technical. The codebase was a fascinating mess. print commands interwoven with HTML, complex business logic, database calls, and conditional statements all tangled together in ways that would make you want to restart from scratch!

Then came the JavaScript requirements. Whenever frontend interactions needed to be added, animations, form validations, dynamic content, I became the go-to person. Despite his deep understanding of programming fundamentals, JavaScript simply didn't click for this experienced developer. The event-driven nature, the prototype-based inheritance, the asynchronous callbacks? They made no sense to him.

I was young when I picked up JavaScript, still malleable enough to wrap my head around its quirks. Looking back, I sometimes wonder: if my introduction to programming had been through React or Vue rather than simple loops and conditionals, I would have chosen a different career path entirely.

Fast-forward to today, and that same experienced programmer would likely sail through JavaScript challenges without breaking a sweat. Large Language Models have fundamentally changed the game for developers working with unfamiliar languages and frameworks.

LLMs can scaffold entire functions, components, or even small applications in languages you've never touched. More importantly, if you're not lazy about it, you can read through the generated code and understand the patterns and idioms of that language. When you inevitably write buggy code in an unfamiliar syntax, LLMs excel at debugging and explaining what went wrong. They're like having a patient mentor who never gets tired of explaining the same concept in different ways.

For example, I'm not very good with the awk command line tool, but I can write what I want in JavaScript. So I would often write how I want to parse content in JavaScript and ask an LLM to convert it to awk.

Let's say I want to extract just the user agent from Apache log files. In JavaScript, I might think about it like this:

// Extract user agent (typically the last quoted string in Apache logs)
const line = '127.0.0.1 - - [10/Oct/2023:13:55:36 +0000] "GET /index.html HTTP/1.1" 200 2326 "http://www.example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"';
const userAgent = line.match(/"([^"]*)"$/)[1];

The LLM converts this to:

cat access.log | awk -F'"' '{print $(NF-1)}'

It uses the quote character as a field separator and prints the second-to-last field (since the last field after the final quote is empty). This kind of translation between mental models is where LLMs truly shine.

Until recently, new developers would approach me with the question: "What's the best programming language to learn?" My response was always pragmatic: "It depends on what you're trying to build. It doesn't really matter."

But they'd follow up with their real opinion: "I think Python is the best."

The concept of a "best programming language" never entirely made sense to me. I might love Python's elegance, but I still need JavaScript for frontend work, SQL for databases, and bash for deployment scripts. The job dictates the tool, not the other way around.

Today, something fascinating is happening. Developers aren't asking about the best programming language anymore. Instead, I hear: "Which is the best LLM for coding?"

My answer remains the same: It doesn't really matter.

The internet is awash with benchmarks, coding challenges, and elaborate metrics attempting to crown the ultimate coding LLM. These tests typically focus on "vibe coding". They try to generate complete solutions to isolated problems from scratch.

If that's your primary use case, fine. But in my experience building real applications that serve actual users, I've rarely found opportunities to generate entire projects.

Instead, I see myself asking questions to old pieces of code to figure out why the original developer made a decision to implement a function one way. I generate util functions with an LLM, I ask to generate those extremely annoying TypeScript interfaces (Life is too short to manually write that out). To my knowledge, all LLMs can perform these tasks at an acceptable level that I can immediately test and validate. You don't need AGI for this.

---

After programming for over three decades, I've learned that picking up new languages isn't particularly challenging anymore. The fundamental goal of making computers do useful things, remains constant. What changes is syntax, idioms, and the philosophical approaches different language communities embrace.

But when you're starting out, it genuinely feels like there must be one "optimal" language to learn. This illusion persists because beginners conflate syntax familiarity with programming competence. The truth is more nuanced. Even expert C programmers can struggle with JavaScript, not because they lack skill, but because each language embodies different mental models.

The barriers between languages are dissolving, and the cost of experimenting with new technologies is approaching zero. The LLM you choose matters far less than developing the judgment to evaluate the code it produces.

Pick any reputable LLM, learn to prompt it effectively, and focus on building things that matter. The rest is just syntax.

Don't start with a language; start with a problem to be solved. — Matt Mullenweg

---