Much of the feedback on my recent article on Reasons to Dislike AI Coding featured a dismissal of a collection of common themes in arguments against AI coding, without any thesis. That post was indeed my way of collecting thoughts, and connecting them to existing articles where I’d already addressed some of the concerns: I don’t think I dismissed the thematic arguments so much as referred to my own, or other, arguments. Here we are, a month later, and I’m ready for the synthesis.
For a lot of software engineers—myself included—the arrival of AI coding assistants represented an existential threat of sorts. Here’s a thing that I’m good at, have made a reputation for being good at and had what I hoped was the first half of a career out of being good at. Now here’s a tool that does it not as well as I do it, that everyone’s going nuts over as the future of the craft of doing the thing. It’s easy to take that personally and to get angry and upset about the change in technology. I know that, because I’ve done it before.
Instance One: Unix
The thing that tipped me from programming as a hobby to programming as a potential career path was using NeXTSTEP at university. I’d already encountered FreeBSD and Linux, and “knew” that Unix-like systems were the technologically superior choice for workstation operating environments. However, even I had to accept that they weren’t exactly pleasant to configure. While the hacking community recommended tinkering with Linux to learn more about how computers and networking work, I was ready to acknowledge that 80% of what you learned through tinkering with Linux was how to tinker with Linux (if you’ve edited sendmail.cf or XF86Config, or gone through the kernel’s make config without access to menuconfig, you know what I mean).
NeXTSTEP demonstrated that you could have the power of UNIX with the elegance of a consistent, well-designed user interface. Admittedly that assessment ignored a lot of rough edges, but it felt clear that NeXTSTEP was the best of the best. Mac OS X was evidence that this technology was ready for primetime, even if (to me) it had various borderline-acceptable compromises to make it work with the legacy Apple landscape.
So imagine my surprise, nay consternation, at going to work in my early 20s as a NeXT/general-Unix-like sysadmin, then programmer, to find out that the people I worked with were far from jealous that I was the person working on the best computers. Some of them not only voluntarily worked on Windows NT, but even claimed to like it!? Imagine my upset to hear that a NeXT-based solution wasn’t automatically chosen just for the pedestrian reason that other people had accidentally bought suboptimal workstations!
Much of this came from my initial cultural introduction to the sysadmin world, which was through a collection of university Unix admins who very much subscribed to the BOFH mindset and communicated in phrases from the ESR jargon file. Indeed, their secret, back-channel mailing list was even called CBOFH…compleat bastard operators from hell.
I never consciously trained myself out of this one; the whole non-Microsoft world and bits of Microsoft vindicated the Unix choice at about the same rate that my opinions mellowed, so I became able to avoid having that argument around the time that it went away.
Instance Two: Smalltalk and Objective-C
Having been a NeXT person, I naturally fell into the classical object-oriented, message-passing, extreme late binding world of software design. And got, if I may say so, rather good at it (my M.Sc. dissertation was an interactive live coding environment that used LLVM as a JIT to dynamically execute ObjC code). I did quite well out of understanding problems from the perspective of networks of interacting agents that send each other messages; making expressive, concise, efficient designs using advanced runtime techniques; and helping others to do the same. Mostly in Objective-C, the language of the NeXT, and of the iPhone and iPad Gold Rushes; also Smalltalk, Python, Java, and Ruby.
Imagine then, my confusion, and the threat to my sense of psychological safety, when the entire field started moving in the opposite direction; towards compiler appeasement and specifying all the bindings in advance. TypeScript was OK because it cleaned up some of JavaScript’s gnarly edges, but Go and Rust seemed like unnecessary distractions when investing in analysis tooling for existing languages gave the benefits of continuing to use legacy code and high-fidelity design techniques while also gaining the benefits of fixing common bugs in memory management and variable misuse.
But eventually, the type supremacists came for ObjC, and we got Swift, a programming language that promised to deliver efficient and correct code across a range of application domains and that eventually got there. This one felt like a shot that landed too close to home, and along with a period of career burnout and break, personal life upheaval and depression, I did what the no-AI people are doing today: I opted out. I spent a year not working at all, then did what someone described as “entering witness protection” and went off to have a career outside my comfort zone: in local companies that had no technology relationship with the field I’d left or the field that had left me. I tried to prove that my software engineering knowledge was domain-agnostic and translational, and in doing so left behind my communities, relationships, and other support structures.
It took me four years to even engage with the Apple-developer world at all, and eight years to get comfortable with the idea of doing my stuff in Swift, the tool that I felt had pulled the rug out from under my career back in 2014. This was a long, and unhealthy, reaction to a technical change.
Instance Three: AI-Augmented Coding Assistants
Like many other people, I initially reacted negatively to the rise of LLMs. Firstly, because of the cavalier approach some of the frontier companies took to copyright; as a Free Software person, I’m already part of a plot to nullify proprietorial stances in software, thank you very much. Then, because the early models made bad software. And then, because an LLM can’t understand software engineering, it can only generate code.
But this time, I reacted differently. Instead of withdrawing from software engineering, I asked how I use my knowledge and skills in this world. What’s the way I contribute, and feel empowered and safe, with this new development? Further, how many other people are going through this difficult shift, and how can I contribute to their empowerment and safety? Chiron Codex continues to be an attempt to answer that question, nearly a year later.
I’ve also lived through tool wars, like AD vs LDAP, Windows/Eclipse vs Linux/Vim, Java vs Python, VMs vs containers etc. Cohabitation was possible most of the time, and in the worst case you could find another shop down the road that had the “right” tooling. Working with the enemy’s tool has never made me feel as bad as I do now.
There is a push across the industry to replace human design and thinking with machines. Another level of abstraction that replaces design-as-code with natural language and weird techniques to ensure that the machine does what you want, which feels entirely backward. According to the marketing materials, the next step is to automate this part as well, removing the human from the loop altogether.
Code is not the product but an expression of the design and, to some extent, the specification. Build and deploy were automated a long time ago, and nobody really complained. The people pushing for AI now are effectively asking you to change your thought process from a precise design to an approximate one. In the same way that you don’t call the services of a graphics designer anymore, but ask the machine to produce the result from a hand-drawn doodle and a few text prompts. Going faster and cheaper (supposedly) while the world burns around us.
My fundamental issue is that AI kills design creativity (the kind you only get when working closely with the details), and will kill other domains as well. We were not “hand-crafting wood furniture” as some keep suggesting; we were hand-crafting the design of it, and now the machine is stealing that.
I’m glad that, with your past experience, you have managed (or are in the process of managing) this transition positively.