Why Natural Language Is Now the Most Important Code

I've been covering technology long enough to remember when "user-friendly" meant a computer that didn't require you to toggle binary switches on the front panel. So when IBM's Jeff Crume tells aspiring programmers that the most important language to learn is the one they already speak, I recognize both the audacity of that claim and the decades of incremental progress that make it possible.

Crume's argument is straightforward: In the era of large language models, natural language has become the primary programming interface. You don't need Python or Java. You need English, or Spanish, or Mandarin—whatever you already think in.

That's a remarkable statement from someone representing a company that helped define every previous era of programming languages. It's also incomplete in ways worth examining.

The Arc They're Drawing

Crume walks through programming history as a steady march toward human comprehension. Machine language and assembler sat closest to the hardware—hexadecimal opcodes that made sense to a CPU but looked like gibberish to everyone else. I learned IBM's Basic Assembler Language on a System/370 in 1975, and "learned" is generous. I memorized enough to pass.

Then came higher-level languages: FORTRAN for mathematics, COBOL for business, BASIC for teaching. These looked more like structured English but still required you to think like a compiler. "These looked a little more like the way people talk, but not exactly because people don't talk like that," Crume notes. Anyone who has spent hours debugging a semicolon placement understands.

Each generation brought incremental improvement. Structured programming reduced spaghetti code. Object-oriented languages let you think in terms of things and actions. Web languages added platform independence. Scripting languages raised the abstraction level. Modern safe languages added guardrails.

The through-line: Each step moved the burden of translation from human to machine. We started by learning the computer's language. Now, supposedly, it learns ours.

What's Actually Happening

Large language models do something genuinely new. You can describe what you want in plain English—"write a function that calculates compound interest"—and get working code back. No syntax to memorize. No compiler errors about type mismatches. Just intent translated to implementation.

Crume's framing is elegant: "Instead of having to translate intent into instructions, which then get turned into results, we can go straight from intent to results and let AI do all the rest."

That's true for certain definitions of "results" and certain kinds of problems. It's less true when you dig into what professional software development actually involves.

The Parts They're Not Mentioning

I've talked to enough working programmers to know that writing code is perhaps 20% of the job. The other 80% is understanding the problem, debugging why something doesn't work, optimizing performance, ensuring security, maintaining systems, and reading other people's code.

Natural language gets you the first 20%. It's the other 80% where things get interesting.

When an LLM generates code that compiles but doesn't do what you actually needed, you need to understand programming to diagnose why. When it produces something that works on the happy path but fails on edge cases, you need to think like a programmer to spot the gaps. When it creates security vulnerabilities—and it will—you need expertise to recognize them.

The democratization narrative is appealing. "Not everyone that wants to write code has to be a programmer," Crume says. But there's a difference between writing code and building software. The first is syntax. The second is architecture, testing, maintenance, debugging—all the unglamorous work that happens after the initial prompt.

What History Actually Teaches

I've seen this movie before, though the technology was different. In the 1980s, fourth-generation languages promised to eliminate programmers. Business users would describe what they wanted, and the system would generate the application. It didn't work out that way. Turns out describing what you want precisely enough to be useful requires many of the same skills as programming.

Visual programming languages in the 1990s made similar promises. So did low-code/no-code platforms in the 2010s. Each democratized certain tasks. None eliminated the need for professional developers. They changed what developers did, not whether you needed them.

LLMs are more powerful than any of those predecessors. The jump from writing Python to writing English is larger than previous abstraction increases. But the fundamental dynamic holds: Making it easier to express intent doesn't eliminate the need to understand what you're building.

The Interesting Middle Ground

What's probably happening is more nuanced than either "programming is over" or "nothing has changed."

Natural language interfaces will genuinely expand who can create simple programs. Someone who needs a quick script to rename files or parse data can now get it without learning Python. That's real value. It's also not what professional software developers spend their time on.

For working programmers, LLMs function more like very smart autocomplete than replacement. They handle boilerplate, suggest implementations, explain unfamiliar code. They make the job easier without making the expertise obsolete. "The beauty of programming in natural language is that it's just that it's natural. You don't have to learn it. You already know it," Crume says. But knowing how to ask and knowing whether you got what you asked for remain different skills.

The comparison to previous language evolutions is instructive precisely because it shows limits. Moving from C to Python didn't eliminate the need to understand algorithms, data structures, or system design. It just let you express them more efficiently. Natural language is another step in that direction—a larger step, certainly, but still a step.

What Questions Remain

Crume presents this as a solved problem: computers now understand us, full stop. That's premature. LLMs are probabilistic systems that pattern-match against training data. They don't understand in the way humans do. They generate plausible code, which isn't the same as correct code.

The gaps matter. How do you verify that generated code does what you intended? How do you maintain it six months later? How do you integrate it into larger systems? How do you ensure it doesn't introduce subtle bugs or security holes?

These aren't philosophical questions. They're practical ones that every organization deploying LLM-generated code faces right now.

The optimistic case is that we're in an awkward transition period, and these problems will be solved. The pessimistic case is that we're discovering fundamental limitations in what can be accomplished through natural language alone. The realistic case is probably somewhere between: LLMs as powerful tools that augment human expertise rather than replace it.

After five decades watching technology predictions, I've learned that the thing being hyped is usually real, but not in the way being claimed, and not on the timeline being promised. Computers understanding natural language is real. The idea that this eliminates programming as a discipline is less certain. We've made computers easier to use before. We didn't run out of need for people who understand them deeply.

— Bob Reynolds, Senior Technology Correspondent