The Death of Code as Craft

Are developers artists, or are they cogs? If they are artists, individual care and craft—the hallmarks of great work—are prized, and handcrafting code would be highly profitable. If coding is just a cog in the industrial machine, then the job of the software engineer is diminished. For many years, Jon Christensen—a software engineer himself—argued the former, but with the rise of AI, he worries that the latter is becoming true. It signals a profound shift in the economics of the tech industry and our relationship to the labor of technology company building. I found his perspective honest and refreshing. —Evan Armstrong

For the better part of two decades, I've been a card-carrying member of the code-as-craft cult, which espouses the belief that deeply considered, finely honed code can create better products. I used to evangelize the ideology to anyone who would listen. I’ve waxed poetic about the sanctity of clean code. The nobility of well-architected systems. The pride of a perfect pull request.

As the founder of Kelsus, a software development services company that has built products for more than 40 startups and large companies, including Chewy, Intel, Equifax, and Splunk, I've browbeaten teammates to adopt rigorous coding standards and argued myself hoarse in conference rooms fighting for more time to hone our digital craftsmanship. I've even rage-quit projects where management failed to recognize the value of well-honed code.

Code as craft was my religion, my identity. And among developers, I was not alone.

But a blinding light on the horizon of technology has made me question everything I once believed. The meteoric rise of Large Language Models (LLMs) has cast a shadow over the concept of code as craft, threatening to eclipse it entirely.

In this piece, we'll embark on a journey beyond the horizon and into the land of AI-driven development. We'll explore the far-reaching implications of LLMs on the way we write, design, and think about code.

And I'll make the case for why—as painful as it is to admit—code as craft might just be a relic of a bygone era. 

Crafting a talent magnet

To truly grasp the rise of code as craft, we’ll need to understand its role in the fierce battle for programming talent.

In the early days of software, coding was considered a niche, almost clerical skill. When the first electronic computers were developed in the 1940s, the people responsible for "programming" these machines were often women, many of whom had previously worked as clerks or secretaries. Due to ingrained biases, people still believed women were better suited for repetitive tasks, despite the complex skills required for programming. These women, known as "computers" or "coders," were tasked with translating mathematical equations into machine language, a tedious and error-prone process.  

Even as coding became more sophisticated in the 1950s and ’60s, with the advent of higher-level programming languages like FORTRAN and COBOL, most organizations still treated it as a secondary, support role. Programmers were there to serve the "real" stars—the hardware engineers and business analysts who were responsible for designing the physical systems and making high-level business decisions.

In 1975, in an article titled "The Humble Programmer," computer scientist Edsger Dijkstra lamented this perception of early programming as a second-class intellectual activity:

But most important of all, the programmer himself had a very modest view of his own work: his work derived all its significance from the existence of that wonderful machine. Because that was a unique machine, he knew only too well that his programs had only local significance, and also because it was patently obvious that this machine would have a limited lifetime, he knew that very little of his work would have a lasting value.

But things were changing. Software was finding a foothold in every industry, and programmers like Donald Knuth and Dijkstra started to push back against this "second-class" ethos. They believed that it was as much a craft as anything else, and that a disciplined, aesthetic-minded approach would lead to programs that were more efficient, reliable, and easier to maintain. Knuth famously declared that programming was an art form, stating in a 1974 article: “The chief goal of my work as educator and author is to help people learn how to write beautiful programs.”

His words were deeply influential. As the personal computer revolution unfolded into the internet boom, demand for software developers exploded. Suddenly, programmers were the rock stars of the business world, and companies were locked in an all-out war to attract and retain the best coding talent. For employers, craft became a subtle form of marketing to signal to developer talent that their company cared about code and was a good place to work. 

However, the language people used to describe craft was foreign to standard boardroom dwellers. Developers mostly talked about mantras and idioms they had invented, like “continuous integration” (which is about reducing the amount of repeated effort required to release a new version of an application) and “DRY code” (short for “don’t repeat yourself,” referring to code that has very little repetition despite an application’s functionality being repeated in different places). None of this meant anything to the vast majority of CEOs.

Sometimes, the easiest way to convince the CEOs of the value of craft was just to say: The engineers say it’s good, and we need the engineers. Keep that in mind. Code as craft doesn’t always have to do with the bottom line. Sometimes, it has more to do with winning developer talent.

The great AI divide

LLMs have sparked a fierce battle, pitting the old guard of code as craft against a new wave of AI enthusiasts.

On one side of the divide are the stalwarts of craftsmanship, like Dave,* a veteran software architect with 20 years of work experience. When he first experimented with ChatGPT, he was alarmed by what he describes as middling code quality and unvetted code finding its way into his codebase. 

“I want an engineer who has carefully considered every line and how it fits into the larger system," he explained to an online group of senior tech leaders. For Dave and others like him, LLMs are a potential threat to the stability and reliability of their software because they sacrifice the careful planning of well-crafted code. This ideology runs deep. Before LLMs, they had been training staff to avoid Stack Overflow, which, as an aggregator of crowd-sourced answers for programming questions, was the former best friend of junior developers worldwide. Now, LLMs are seen as just another way of developing bad habits.

On the other side are young, ambitious programmers like Abby.* Abby sees LLMs as a liberating force. Where Dave sees risk, Abby sees opportunity. It may be that Abby is less encumbered by the past—as a newer developer, she is more open to the solutions provided by LLMs. She doesn’t mind that the code isn’t beautiful because she believes perfection is the enemy of excellence, and AI-produced code helps her learn. "It was like having a highly knowledgeable coding partner," she explains about her first time using an LLM. "It could handle a lot of the repetitive tasks, and even suggest improvements and optimizations I hadn't considered."

Abby and her compatriots believe that the automation of low-level tasks will free up developers to be more creative and focus on the big picture rather than getting bogged down in the details—or worrying about code beauty. She also points out the potential for LLMs to aid in code comprehension and maintenance—the very thing that Dave’s side worries about: "With an LLM, I can understand someone else's complex code without having to spend hours reading through it and adding breakpoints to see what it's doing…" In Abby’s world, there’s no need to care about the beauty of code. The LLMs will sort out our mess.