Code is cheap(er)

https://htmx.org/essays/code-is-cheap/ Tildes: https://tildes.net/~comp/1ujh/code_is_cheap_er

# [</> htmx ~ Code is Cheap(er)](https://htmx.org/essays/code-is-cheap/)

There is no getting around the fact that, in the last year, code has gotten much cheaper to create. AI is able to generate reams and reams of code, often of reasonably decent quality, incredibly quickly. There is no point in pretending that this isn’t the case.

At times, when confronted with this admittedly uncomfortable fact, I have seen people I respect say something like “coding was never the problem.”

While I appreciate the sentiment, I don’t completely agree with that: certainly coding was at least part of the problem.

And that part of the problem has shrunk significantly with the advent of effective AI coding tools.

So what does raw coding becoming less important mean for software developers, people who, in the past, prided themselves (and often compared themselves) on their ability to code?

## Understanding is Expensive(er)

One thing I see is that it means that understanding code has become more expensive. This is because when reams and reams of code are generated, rather than emerging painfully from a particular programmer’s fingers, there is no understanding of that code.

In as much as understanding that code needs to exist, it has to be done after the code is written, by reading the code.

Note that conventional wisdom is that reading someone else’s code is harder than writing your own code.

Some AI enthusiasts say “Who cares, you don’t understand the output of compilers.”

I think that is a category error for multiple reasons:

• - Compilers are deterministic; LLMs are, by design, not

• - Compiler workflows retain their original source code; LLM workflows typically do not

• - Compiler output is to a narrowly constrained domain (machine code); LLM output is not (generalized software)

I maintain that, in most cases and certainly for mission-critical software, developers still need to understand the underlying code even if it is generated by an LLM.

And if code is generated by an LLM there is a stark danger: the LLM can produce code far faster than you, or anyone else, can understand it. This is why I recommend incremental use of LLMs rather than allowing them to generate massive changelists that neither you, nor anyone else, can understand.

(There are times when this can be appropriate, such as in a mechanical refactor, but it is extremely dangerous when new semantics are being introduced into a code base.)

## The Sorcerer’s Apprentice Trap

One movie scene that has been consistently coming back to me as I have watched AI garner more and more attention is The Sorcerer’s Apprentice from Disney’s movie Fantasia.

In this scene the apprentice decides to use magic to assist in the drudgery of cleaning. He enchants a broom which then proceeds to start cleaning things up. Things appear to be going swimmingly for a while, until the broom starts cleaning more and more vigorously, reaching a point where things start going swimmingly literally.

The chaos is resolved when the Sorcerer reappears and asserts control over the situation, glaring at the apprentice for his foolishness.

This seems like an apt metaphor for the AI era: you want to be a sorcerer and not an apprentice.

And a sorcerer has to understand the code.

## Complexity: Still Bad

Humans, generally, have a poor grasp of geometric and exponential curves.

(This is why they believe in fairy tales such as compound interest.)

…