The death of a software craftsman
Well, it happens a lot ‘round here
You think quality is a common goal
That goes to show how little you know

Developers work hard over the years to cultivate tools and techniques to improve the quality of the construction of their software. These tools and techniques are slowly becoming even more useless than they may already be. We must adapt by either going all-in, totally opting-out, or finding a middle ground by tracking the AI code-generation craze to fill the gap as a hand-coding artisan.

Software Quality Problems are People Problems

All techniques for improving the quality of software construction attempt to solve one problem: allow a person to understand the system they are changing so they can safely and correctly make a change to it. Techniques either prevent certain classes of bugs (e.g. static typing, code review, web frameworks), or make it easier to manage complexity (e.g. object-orientation, microservices, function currying)¹.

Although we debate and discuss various techniques amongst ourselves, no non-programmer cares about them. They can’t even conceptualize how software is made, so they have no way to know what quality construction is, how to value it, or even how to identify it. They just care about outcomes.

We tell ourselves that it's these skills that deliver those desired outcomes

Despite all that, we tell ourselves that these skills are critical in delivering those desired outcomes. I myself have a very particular set of skills. Skills I’ve acquired over a very long career. I write about them, I use them, and I am truly convinced that careful construction of software is the best way to reliably create systems that can be easily changed over their lifetimes. Even if no one knows or cares.

However.

Best Block No Be There

I may relish the solutions to building quality software, but the best solution to any problem is to eliminate the problem. Don’t bet against Mr Miyagai’s wisdom.

Let’s imagine a hypothetical tool that could take, as input, any software system and a description of a change. The tool produces, as output, an updated system with that change incorporated. This hypothetical system would not rely on any particular software construction technique—it works with any system you give it.

If software was created this way, would anyone know what, say, dependency injection was? Would anyone go to a conference to learn about the latest features of Ruby on Rails? Would anyone buy a book about carefully designing database schemas?

They would not. There would be no reason to. It literally would not matter what the code was like. Our hypothetical system could handle whatever it’s given and produce the requested changes. Sure, a small few would need to understand how code works, but the group would be quite small.

This hypothetical tool isn’t intended to be magic. Like any tool, there would be a skill to it, perhaps a difficult-to-master skill. And while there might be some overlap with the skills we use today to create quality software, most of those skills would become obsolete.

This system is not so hypothetical.

We know that in at least some cases, they do exactly what I described above.

We’ve seen what AI code generation systems are capable of. We know that in at least some cases, they do exactly what I described above. In some cases, they can take an existing system, a description of a change, and produce a system with that change. And they seem to be improving quickly, handling more and more cases.

And yet.

Soylent Green is People

My visceral reaction to these tools has been a combination of disgust and boredom. Here are the things I have told myself about why this technology can or should be ignored:

• It was created unethically.
• It consumes an unreasonable amount of resources (such as electricity and hard drives).
• It is owned and sold by some of the worst people in the world.
• Its true cost is hidden by investor money. Once its pricing is set in line with its true cost, no one could afford it.
• Being non-deterministic, it can never be as a good as a person.
• There’s no way to hold anyone accountable for its output.
• A real programmer will still need to go into the code. Practices around software construction will always matter.
• It’s shit at anything that’s not a popular technology applied to a common use case.

As of this writing, these are all true. But are they intrinsic problems? Must they be true, always?

AI code generation's problems aren't actually as intrinsic as they may seem

Unlike crypto, which is literally made of intrinsic problems preventing it from widespread adoption (please don’t email me), AI code generation’s problems aren’t actually as intrinsic as they may seem.

• AI models could be created ethically. There could be (and perhaps are?) systems created that comply with the licenses of their training materials.
• Systems that use AI models could be done with less power and resources. DeepSeek demonstrated that even minimal performance tweaking can give real benefits. Not enough to fully ameliorate the issues, but enough that I cannot say with certainty that these resource problems are unsolvable.
• AI code generation tools could be required to operate within a system of accountability. We’ve all seen that CEOs will comply with the government when threatened. And someday, we all might live under a functioning government that works for its people.
• Their price may be bearable when investor money runs out. Uber still exists as a going concern, despite being more expensive than ever.
• People are non-deterministic, too, so it’s not clear me that AI coding agents are necessarily worse than people at producing results. Coding agents are already better at programming than the vast majority of the population. I can’t say with certainty that every living programmer is the embodiment of John Henry.
• While AI coding agents may never be able to handle every imaginable task, it’s not clear to me that there is a limit on what they can do or that any given limit is unreasonable. Most of us are putting spreadsheets in a web browser or wrapping a database in a front-end, so if all that work is automated, that doesn’t seem necessarily bad to me.

In other words, all the problems of this technology could be addressed. I’m not saying they will be, or that it will happen on any particular timeline. But, it seems entirely possible to have a tool that produces software by taking in an existing system and written request as input, all without producing the externalities they currently do.

Not inevitable, but possible.

This means it’s worth considering a world where AI code generation is commonplace. In fact, professional software developers must consider such a world, and think deeply about their place in it.

As a thought experiment, imagine if all the issues above were addressed. We have AI code generation tools are ethical, use appropriate resources, etc. Who wouldn’t use these systems to produce software? At least in the context where the quality of the output was sufficient (a low bar if we are being honest), why would anyone not use these tools?

As much as I love coding, it would be really nice to produce results without fretting over variable names, modularity, OO purity, monads, or any of that stuff. Having a system produce reliable code just seems better. And it’s not like these tools are the first examples of code generation—we use code generation all the time.

Almost everyone in the orbit of software development only cares about outcomes

Remember, almost everyone in the orbit of software development only cares about outcomes and results, not the process by which they were achieved. It doesn’t mean you are wrong to care, but most people don’t.

So what’s a lonely programmer to do?

Ce n’est Pas un Griefpost

I’ve been a professional software developer for 30 years, and these AI code generation tools basically obviates a big chunk the skills I’ve developed. But I like using those skills. I like writing code. I like the process of building software. How do I navigate a world that no longer values that?

I’m results-oriented and am good at communicating with non-programmers. I can manage teams and projects, and keep people focused on business outcomes. These are all skills you need no matter how code is written. But my least happy professional eras were when I wasn’t involved with code.

Up until now, the never-ending need for programmers has given me a nice career where I can balance all of this stuff. Thankfully, I’m on the tail end of that career. But I’m not retired yet.

I see three paths in front of me: Hard Pass, All In, and Embrace Tradition.

Hard Pass

The problems I listed above are real. And while they could be solved, there’s no guarantee they will be solved in any given timeframe, or even at all. The problems compound and create what many believe to be an easy choice: don’t support unethical systems created by terrible people that quickly exhaust our resources.

This is how I felt initially. It’s just easy to write this entire thing off as awful, useless, evil, of poor quality, and not something I want to be involved with (like crypto!). Unlike ignoring crypto, the Hard Pass has consequences to the career of a software professional.

In the short term, it’s still possible to be gainfully employed in software while abstaining from AI. There’ll be fewer and fewer such jobs as time goes by, but there should be at least a few years of generally available jobs writing code by hand.

But these positions will become fewer and far between. Choosing AI abstinence means ultimately exiting professional software development, at least at some point.

Choosing AI abstinence means exiting professional software development

This might seem extreme, but be honest: these tools will become far more prolific over the short term. Not enough people are going to come around on the ethical issues to slow or stop their adoption. The country I live in is 350+ million people who tolerate the sexual exploitation and murder of children (as just one example). I say this not to encourage you to give in or sell out, but just to understand that the world of software development as you know it is going to become very small very fast.

This is the consequence of the moral dilemma. You can opt-out. Almost every job that ever was or ever will be is something other than writing software. Most people make a living without writing software. But if you want to give AI a Hard Pass, you will eventually be giving your career as a programmer a hard pass, too (though please stick around for option three, below).

If this is you, start figuring out how you’re going to make a living otherwise.

Or, you could go all-in.

All In

Going all-in is to accept that the profession is changing so radically that you’ll need to retrain yourself. You’ll leverage your experience and incorporate these new tools in the same way as you would any other advance in the field. Except you may leave a lot of your existing skills behind.

It's hard to live a life free of compromise

It’s hard to live a life free of compromise. Going All In is to compromise. It means you must tolerate the downsides of this technology (assuming you believe there are at least some downsides). Of course, tolerance is not the same thing as support. Every one, every where, every day must weigh their needs against what their conscience can bear.

If your priority is to stay working in software development, especially if you have a long career ahead of you, going All In is the safest, simplest, most practical option. You just have to be able to live with yourself.

There are two reasons I find this option depressing, beyond having to tolerate the ethical problems.

One is as I mentioned above: I like coding. I like writing code and everything about it. I like the control it gives me, and I do not enjoy “coding” by writing Markdown and feeding it to a compiler that sometimes works and sometimes doesn’t until I ask it nicely to do what I need.

Two is related to the “common technology” problem. These tools produce code using the popular frameworks, techniques, and libraries. While it’s possible I won’t have to review or modify the code these tools produce some day, today is not that day. And I just really, really don’t want to write React or Tailwind. I don’t really want to learn Python. And the creator of Rails can go fuck himself.

But that’s me. If I were younger, smarter, and less concerned with the ethical issues, I’d embrace this new world, and not worry so much about what code was being produced. The whole point is that it won’t matter in the end.

All this being said, flat-pack furniture made of fiberboard did not eliminate the skill of putting a chisel to hard wood. The time of the software craftsman could be coming.

Reject Modernity, Embrace Tradition

I always though the “software craftsman” movement was dumb. Uncle Bob is a terrible person with bad ideas, and Agile Thought Leaders seem more focused on their billable rate than improving outcomes for users. Their collective disrepsect for anyone not a programmer is galling. But most of all, it just seemed like navel-gazing. Results and outcomes really do matter!

But what is a craftsman, really? Someone with deep skills honed over many years, who can produce amazing results using a process that’s almost as engaging to observe as the results themselves. There are certain outcomes that only a highly trained human hand can deliver.

There are still craftsmen being trained and employed to this day, across a wide variety of industries. Although few people have hand-made furniture, you can still commission it. And don’t forget that even uninspiring chain restaurants like The Cheesecake Factory still make almost all their food from scratch.

Thus, it’s not unreasonable to think that such an industry will exist for writing software. In the short term, there’s still a ton that AI coding agents simply can’t do very well. And in the long term, there will be at least some demand for software written to a higher standard than what AI is producing. Of course, there will always be the need to pay a high price to have real programmer pop the hood on your vibe-coded mess to figure out what’s actually wrong.

However, to live in this world as a Software Crafter² is to understand AI code generation…at least until it plateaus in capabilities. To be marketable and make a living, you have to know what gap you are filling. And that gap is changing often. Thus, you cannot abstain entirely from AI if this is the way you go. You may not use it to produce your results, but you will need to use it—not just read about it—to understand it.

We don’t get to live our lives free of compromise.

Maybe in the next world.