The code was never the job

In February 2024, Nvidia’s CEO Jensen Huang said: “It is our job to create computing technology such that nobody has to program”. Language models now write working code from a paragraph of English, and to some people that sounds like the end of programmers.

I see it differently. The purpose of software isn’t to code. It’s to build things. And building things with software is about semantics, the meaning of what we’ve been asked to build.

Software is translation

That meaning starts in a specification written in a human language like English. English is fuzzy. A requirement can be ambiguous or imprecise, open to more than one reading or interpretation. Our work is to take those meanings, those semantics, and represent them in a formal way. That formal way is code, and code is precise enough for a computer to run.

Take “Orders over $100 get 10% off”. Both of these lines of Python match it:

qualifies = subtotal > 100        # before tax
qualifies = subtotal + tax > 100  # after tax

An order of $95 with $7.60 of tax comes to $102.60. It gets the discount under the second line and not the first. The English allows both readings but the code has to pick one.

A bug is meaning lost in translation

When some of the semantics get lost on the way from English into code, the business calls it a bug. We didn’t faithfully translate what they meant. They feel the consequences, because their expectations aren’t met. The customer with the $102.60 order expected the discount and didn’t get it. The business people are the experts on their domain’s semantics, so they know when something is missing. The old expression for this is “lost in translation”.

AI doesn’t replace the translation

So AI can’t, and doesn’t, replace the translation of semantics. A model can produce the code for either case in seconds. It can’t know which one the business meant, though, because the English doesn’t say. We still need humans, engineers in particular, to do that translation.

Someone has to think through the fuzzy specification. Real requirements run for pages. They can conflict or overlap, and they have edge cases. Add a second rule to our example, “Members get 15% off”, and a member’s $110 order raises questions nobody answered: do the two discounts stack, and does the 15% come off before or after the $100 check? The business isn’t always explicit about things like that. Sometimes it doesn’t know, or never thought about it, because it’s hard for any brain to hold pages of English in mind and find every edge case and conflict in them.

That’s why we need humans, and we need better tools too. Model checkers, and formal methods in general, could help us find those edge cases and conflicts, and turn unclear requirements into precise specifications. And yes, that’s a topic for another day.

Humans own the translation

Most of all, I think humans are still accountable and responsible for this work. When something is wrong, the model doesn’t answer for it. A human engineer does. Humans still own the translation of domain semantics from English into whatever programming language they use, whether that’s Python, C#, C++, Rust or Elixir, and they should keep owning it.