Amidst the recent move towards more and more LLM coding, the word “craftsmanship” has been missing from the discussion. All the LLM companies and loud voices online are raving about higher productivity, faster coding, lower costs and generally less human input and more LLM output. Many are calling this the “industrial revolution” of software engineering (including Nvidia CEO Jensen Huang) and I agree with that description.

The “craft” of programming is the one aspect that is left behind in this discussion. Programming is as much of an art as it is a science. There’s often 10 different ways to solve a problem and usually 1 is the most appropriate choice in a given situation. It is the programmer’s taste and discretion which drives this choice. Solution A might be more memory efficient while solution B might be more performant. But the programmer might choose solution C because it fits the API design the best. The subtleties and nuances behind these decisions come from countless hours of practice and effort. It’s what separates average or good programmers from great programmers. It’s the difference between a codebase which lasts 5 years and a codebase which lasts 50 years.

LLMs by their very design are incapable of automatically making these kinds of decisions. The whole point of prompting an LLM instead of writing the code yourself is to reduce the amount of human input for maximized code output. If you had to give the LLM every single detail, you would just be programming everything yourself, except through natural language, which is often not precise enough. (Dijkstra, of Dijkstra’s algorithm fame, among many other things, summarized this eloquently many decades ago.) You want to tell the LLM “write me a binary tree in C” instead of having to describe what a binary tree is and how to write one and what C is. The higher productivity and faster coding comes exactly from this “arbitrage” of input to output.

The tradeoff you make in this arbitrage is nuance. And that’s where the craftsmanship lives. The subtle decisions, the tradeoffs we often make between memory, speed and flexibility. There’s an argument to be made that some products or modules don’t need this nuance, and any working code is enough to get the job done. But the software industry as a whole is racing towards a paradigm where most or all of the code is going to be without nuance, without context-appropriate tradeoffs, without a craftsman’s touch and intuition.