The Extreme Industrialization of Programming

There’s always this tension between craft and industry, and that very tension seems to be frightening my peers in software engineering.

A “Hello, World!” greetings program in C

It’s 2026, and we’ve now been coding with large language models for some time. Some of us have been doing it at home, some of us have been forced to do it at work. Some of us are enjoying it. Some of us hate artificial intelligence. What I want to talk about is how we’re going to address whether this is the end of software engineering as a profession, and how it’s really an old question that we might be able to answer. I find that these discussions about AI can be rather boring, so I might sound dismissive, but I want to point out that I’m not anti-AI, I just think that we’ve seen this story before. For me personally, I understand it from the lens of visual art, and I want to talk a little bit about how technology has affected the visual arts and what we can learn from that. So firstly, what is this old question I’m referring to? It’s an inquiry about the tension between craft and industrial methods.

I should probably first explain what I mean by “craft” and what I mean by “industrial methods”. When I’m talking about craft, I’m just talking about labor in the economy that’s done very skillfully by hand. It doesn’t scale very well. It’s using less machinery and assembly lines. At its most extreme, it’s one person doing one thing end-to-end. What I mean by industrial methods is when we do take labor into a factory, we break it down and scale up production while increasingly using a whole lot of machinery.

We often feel this tension because as human beings, we seem to really appreciate and love craft, but frankly, in the modern world, much of the stuff that we enjoy or take for granted is actually mass-produced, and it’s so much more reliable and consistent, that it has made our lives so much better. This tension between these two things is bearing down on software engineering to an unprecedented extreme. Maybe that sounds odd because software engineering seems highly industrial to begin with. What do you mean it’s being industrialized now, it wasn’t before? You weren’t making things by hand. Of course, I’m talking about coding in particular. That was done by hand. We were typing things painstakingly into a computer for thousands of hours of our lives. Now we’re saying there’s a new method where we don’t have to do that anymore: use LLMs, and you can do this at scale.

But without going too far into software engineering, I want to point out that we’ve seen this with visual art. I went to school for digital art, and it was interesting because I went in for commercial art, not fine art. It was awkward though because I had to take foundational courses in fine art, but I did music and computer science in grade school, not visual art. I wasn’t very good at those foundational courses in college, but I wasn’t bad either. Then, as I was doing my work for the digital art courses, I felt like I just didn’t understand something that the fine artists understood. There was just something they understood that I didn’t. I took drawing foundations a couple of times and then, you know, I had to take it in private lessons only much later in the past few years. I took private lessons and really started to understand how to draw traditionally, but what I learned is difficult to explain… it’s some embodied knowledge, and I don’t think you can quite put it into words, but, I assure you that there is a difference between digital artists who know traditional and those who only know digital. There’s a difference between when a fine artist comes into a tool like Photoshop or ZBrush versus people who have only ever dealt with digital. You see, in Scott Robertson’s How to Draw, the book starts with mark-making as foundational, and practicing traditional art is extremely effective at sharpening that skill. So it’s still the recommended course, in my opinion, to learn traditional drawing before you hop into Photoshop and try to do any kind of digital painting, and that’s been the curriculum at many art schools for over a decade too. So my point is, there’s still something essential in the manual skill that you just can’t replace, and I think that’s going to carry over for coding as well. Writing code by hand teaches you to follow the logic function-by-function, as functions are described as a fundamental in The Structure and Interpretation of Computer Programs, and if you don’t know it, I’m doubtful that you’re going to get masterful results out of any digital tools that you try to use to get around that.

The thing to know, though, is that the modern world seems to always need more outputs. It’s a world where we are increasingly productive, and we’re increasingly producing more things that we encapsulate into other more useful things, and we just keep scaling up. We’re more and more productive, and we have more and more things that we can rely on that are beneficial to a greater variety of us from all different walks of life. What I’m trying to say is that we really owe it to our audience to be more productive, and at the same time, I don’t think industrialization of art destroyed the pursuit of excellence in visual art. I want to point out, Game of Thrones is still a beautiful work, and it was largely created with digital art. Sure, I mean, you have a lot of, you know, actors and stage props and things like that, but you still see plenty of special effects in there, and the special effects are really stunning. The actresses and actors and horses are beautiful too, of course, but the special effects are also essential to telling that story, and it wasn’t the end of great art for them to start using tools like Houdini, Nuke or whatever they used in their studios. It gave us something new that we couldn’t have had before. So you can see that, despite there being this tension, digital art still emerged as a kind of discipline of its own, and there’s a huge variance in skill among digital artists. There’s still this notion of “I wasn’t very good at digital art, and then I got better”. There’s still training involved, and we still want to have results that we like. We just need to be doing it in a little bit more of an industrial way, and I think that’s an important lesson in general.

So appreciating this leap in industriousness is something that we have to think about and embrace as software engineers. We need to think about what our fundamentals are, and make sure we’re focused on that and look at these industrial methods as accelerating us, and being useful for retrieving something that we already embody, something that we painstakingly gained. I mean, you’re still going to have to study and learn, I think, quite a bit about what makes software good. You might call it moving up the ladder of abstraction. I don’t know if everything on that ladder is an abstraction, but I deem it an industrialization of our methods. We went from needing syntax highlighting, to needing automatically inserted matching braces, to needing auto-complete… then it was even better auto-complete, and now it’s the scale of entire programs if you wish. My emphasis isn’t only on the ladder though, it’s also that I believe we’re going to really still need our basics to use these new tools effectively, the same way I believe digital artists today are better off still carrying a sketchbook.

Now, you might say “That’s not a fair comparison, you’re comparing engineers using AI to artists using digital content creation apps. You need to be comparing artists using generative AI to engineers using LLMs to generate apps.” I think that’s fair, and the reason is that these AI tools do something quite remarkable: it allows us to completely divorce ourselves from the discipline. If I want to work in Photoshop, as I mentioned before, I was saying you need to know your way around the canvas. With generative AI though, you don’t need to know because I can just say “draw me a cat”, right? That’s true, but that’s not quite the whole story. You see, craft reemerges. If I sit down in front of generative AI, I’m probably not going to ask it to simply “draw me a cat”, as I’ve drawn a cat by hand before. I’m going to be more inclined to actually talk through building up the image the way I want the image to be, telling it what kind of dimensions I want the canvas to be in, or what the perspective needs to be. I wonder, do I want a portrait, or do I want a picture of a cat from far off? There’s also a lot to talk about, like the color palette, et cetera. There are so many aspects to visual art. Similarly, there’s domain knowledge for engineers as well. So on any level, it’s still the recurring notion of grappling with increasingly industrial methods.

As we’re experiencing extremely rapid industrialization of our methods, we have to consider what our fundamentals really are. As engineers, we create something, and given some condition, we expect some behavior; the way we evaluate whether we’ve done a good job or have made progress or not, is we run tests. Of course, we’re seeing a lot of spec-driven development, a sort of renaissance of the waterfall methodology, where we focus on specification before checking the LLM output to see that it matches the specification. I hope you would agree that that’s an exercise of domain knowledge. Writing a specification still requires a depth of understanding, the same way the introduction of C++ still demanded a depth of understanding. I mean, you go from error handling in C, where you have to catch the possibility of errors on seemingly every call site as a return, versus what you read in Bjarne Stroustrup’s books on C++ where he talks about the use of C++ exceptions to decouple and consolidate error handling from each call site. We could go into all of what Stroustrup talks about in the transition from C to C++, but the idea is that this domain knowledge was still important for programmers using increasingly advanced compilers. You understand error handling, you understand memory-handling, and you’re familiar with the challenges of software composition in a growing codebase, right? So, I think the focus should be on what our fundamentals really are in software engineering, and to not lose sight of that. I don’t think this is something that dies out, but I rather think more is being demanded of us. At best, perhaps it’s actually something that can grow in new and interesting ways if we allow it to.