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 and that the programming language is human. Everybody in the world is now a programmer.

Language models now write working code from a paragraph of English, so it’s tempting to hear that as the end of programmers.

I see it differently. Typing the code was never the job. The job is the meaning of what we’ve been asked to build, its semantics.

Software is translation

That meaning usually starts as words, in a ticket, a spec or a meeting, in a human language like English. English is fuzzy, so a requirement can be read more than one way. Our work is to take those meanings and represent them formally. Code is that formal representation, precise enough for a computer to run.

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

1
qualifies = subtotal > 100        # before tax
2
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 often meaning lost in translation

When the code doesn’t do what the business meant, the business calls it a bug. Some bugs are plain slips, like an off-by-one. The ones the business feels most are meaning lost on the way from English into code. The customer with the $102.60 order expected the discount and didn’t get it. Maybe the business meant after tax and the code picked the other reading. Maybe nobody had decided, and the code settled the question by accident. Either way the business notices, because it is the expert on its domain’s semantics, even when it never wrote the answer down.

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 even more questions: 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.

Finding those gaps is hard for anyone, so we need better tools too. Formal methods mean writing the requirements in a language precise enough for a tool to check. Writing that specification forces the questions nobody asked, and a model checker can then search it for conflicts and edge cases. That’s a topic for another day.

Humans own the translation

Most of all, I think humans are still accountable for this work. When something is wrong, the model doesn’t answer for it. A human engineer does. Humans own the translation of domain semantics from English into code, whatever the language, and they should keep owning it.