Who Hates AI and Why?

A brief note: I'm pleased to report that matters have improved for me: it turns out that selling professional DevOps mentoring and coaching is a lot more popular with my audience than the somewhat undifferentiated consulting I was selling earlier. I still have some space for mentoring and coaching clients, so if you're an early-career engineer or someone who writes code professionally but feels like they have some gaps in the spaces I publish on, please drop me an email!

As the relentless flow of LLM slop and propaganda continues to soil the world, I find myself increasingly trying to interpret and understand why and how opinions about LLM technology form. I've had a lot of thoughts about this, most of them unprintable, but one thing that's been interesting is that some people whom I like and respect as engineers are willing to mount defences of limited LLM use, whereas some of the others are, by contrast, comparatively hardline (I'm definitely more one of the hardliners).

An observation that I had when trying to explain this is that a remarkable number of LLM sceptics prefer technical fields that aren't application development. David Gerard is a sysadmin. I have a strong preference for DevOps and infrastructure over application development these days, and Pavel Samsonov works primarily in UX/UI design. Even the engineers I know that use LLMs over multiple fields (the Pivots come to mind) tend to be much more enthusiastic about LLM use in application development than they are about the same technology in DevOps and infra spaces. On the face of it, this is difficult to understand: after all, it's all technical work and none of the spaces we're looking at have any particular relation to each other beyond being "tech" jobs. So why do we see this alignment?

Transformative and compositional work

While work is obviously a very, very complicated thing, a useful lens for the purpose of this essay is to draw a distinction between work which reshapes a raw material into a finished object and work that puts together multiple objects in a way that creates a certain effect in the world. For the sake of having a shorthand, I've chosen to call them transformative and compositional work, respectively.

Transformative work is, in general, the act of taking a raw material and turning it into an object of use to someone in the world without an undue amount of consideration for how that object fits with other objects in the world or in the hands of the person using it¹. While obviously interaction with other things is important, it is also in some sense a secondary consideration. For a prototypical example of transformative work, one might take blacksmithing: when one makes a sword or a knife, one is concerned with the use of the blade, but during the act of production, the focus is squarely on the blade and its properties. One has to consider how the knife might be stored or handled in a kitchen environment, or that the sword works with a soldier's armour and the scabbard suspension, but these are secondary to the ability of the blade to cut well and effectively and can be sacrificed to an extent if the primary function of the object requires it. In my experience, application development tends to follow a similar pattern: the job of an application developer is to build an app that will naturally do something, using the programming language as the raw material being used. How that app works with other pieces of software (or even the deployment infrastructure) is a secondary consideration to the internal function of the application and the question of whether it does what we want it to do.

Compositional work is quite different. In compositional work, we're not working with a raw material: rather, we have a lot of already existing objects that are in some sense already finished and our task is to make them work together in a way that makes sense. In composition, the nature and internals of the individual parts isn't important in the way that it might be in transformative work: the parts have to fit certain parameters and be able to do certain things, but in the context of compositional work their individual purposes are secondary to how they fit into the greater whole: the internals of PostgreSQL vs Redis or Mongo are secondary, in the compositional view, to what these databases bring to the larger system. A prototypical compositional job might be that of an interior designer: the goal is not to fuss deeply about the purposes and internals of each individual piece of furniture, but rather to ensure that the different elements in a room or a home work together harmoniously to create a given effect.

These are, I think, stances or standpoints more than they are hard categories, and I believe that it's possible to approach most types of work from either a transformative or a compositional point of view: to give an example of this, metalsmiths working on precision machinery or lathe operators are doing work which one might naively consider transformative, but in a highly compositional context. Nonetheless, people do usually have a preference for one stance over another. To give myself as an example, I tend to lean heavily towards compositional work: I struggle with writing fiction, and my non-fiction writing tends to be less about exploring new ideas than about composing existing ideas in new ways that serve a purpose. I enjoy choral music a lot, which is a very compositional artform, and I spend a lot of time cooking and baking, both of which are also compositional much more than they are transformative.

And it's this observation, I think, that goes some way to explaining the observed trend in LLM scepticism. All of the fields I've mentioned above tend to take a compositional stance, whereas boosters tend to work in fields (like the aforementioned app development) where the common stance is far more transformative.

Take UX design as one example. This is very much not a field where things are created out of raw materials. Rather, one has a lot of pre-existing elements where the exact internals of the elements don't much matter so much as the fact that the elements fit the spec and do what they need to in the wider scheme of things: it doesn't matter what framework a form component is built in or the internals of the API it talks to so long as it does what it needs to do in the UI. The goal of the designer is thus, in one reading, to assemble and arrange these components, requesting that new ones be manufactured if need be, in order to get a certain effect. To give an example, my website is composed of a few different elements: content in markdown files managed by Nuxt-Content, a few display components written in Vue, a couple of functional components (subscription boxes and the like) and an API to a backend database. The internals of all these things, from a design perspective, don't really matter: what matters is that they work broadly as specified and thus that, when designing, I can get a desired effect: a user can read my blog posts and feel edified, and if they so incline, they can sign up to my email list, contribute to my Patreon or avail themselves of my consulting or mentoring services.

Systems administration is similar: the goal isn't usually to create new packages or develop new functionality for an operating system, but rather to choose an operating system and appropriate tools that work harmoniously to achieve a given goal: for example, to allow people on the internet to see a website hosted on a server robustly and with minimal downtime. Similarly, DevOps and infrastructure are, on the whole, highly compositional fields: the goal isn't usually to create de novo entities unless you really need them to fit into an existing process or system, and instead you're usually using black box components (CI/CD tools, Docker containers, OpenTofu resources) together in order to achieve some kind of effect. Containerisation technologies really bring this into sharp relief: it's no surprise that one of the more popular simple orchestration tools out there is called Compose, and the entire ethos of containerisation + immutable infrastructure is very much a compositional one.

Choice and precision in composition

So why might a compositional stance lead to LLM scepticism? What about that mindset leads to having difficulty dealing with what LLMs do? Compositionality relies (among other things) on two core values or functions: choice and precision, both of which are antithetical to LLM functioning.

Choice is the first core function. Much of the time, when doing something compositional, your initial bias is not to build a new component but to choose an existing component that does what you need from among a range of alternatives. Databases are once more an excellent example of this: there are a whole family of them, each doing very different things and meeting different needs. For example, PostgreSQL is a very robust, easily extensible relational database, Redis is in-memory, fast and excellent for use as a cache or message queue where speed and ease of use are considerations ahead of robustness and atomicity, and MongoDB is Web Scale. Choosing one of these over the others thus involves understanding at quite a deep level the system you're trying to build, the performance qualities and uses of the databases and the context that all of this work exists in: there's really not one singular pointer that you can use to make the choice.

Choice is also heavily intuitive and relies a lot on taste: in compositional fields, pressure towards precision in execution coexists heavily with taste, judgement and subjective calls in the planning stage. Specifically, it's important in compositional fields that the choices you make are internally coherent: you can't make half of your decisions in one framework and the other in a completely different one and expect anything remotely adequate to come of it. Consistency, therefore, is of primary importance. This shows up a lot in DevOps spaces: if you're choosing a primarily immutable infrastructure, for example, it's important that you don't carve out exceptions to allow for mutability in certain spaces, as it compromises the whole enterprise.

The second core function is precision. In compositional work, it is important that the different components that you're working with do exactly what they do and that they're fitted together precisely. The prototypical example here is precision machining: to build advanced machinery, you need things machined to sub-millimetre tolerances very frequently. A gun barrel has to be machined with precise rifling and with the hole of the barrel precisely in the centre of the matrix: if it's even a little off, the gun will prove inaccurate and the barrel will wear out after only a few hundred rounds. Similar principles apply to artillery shells: they have to be of just the right radius, the drive band has to be exactly right otherwise the thing won't work at all. Welds have to be even and bind tightly, and God help you if there's any corrosion on the pieces of metal you're joining that you haven't scrupulously removed. The weld can't have bubbles in it either, for that matter. And don't even get me started on the precision required to put an airframe together.

Modern robots and computers simply don't have the capacity to manage this level of precision unaided, which is why a startling amount of manufacturing work is still done by humans. Engines, trailers, F-35s, basically anything welded... they're not assembled by humans because humans are cheaper, but because machines simply don't have the precision or context awareness to do those jobs. While machines have done a lot to reduce the labour required for things where precision isn't key, in the precision manufacturing field it's less a question of labour reduction and more "technology lets us do things that would otherwise simply be impossible". An electric lathe or a five-axis mill exemplifies this: you simply can't get anything remotely as precise as what you can do on a lathe as a human with hand tools, but operating a lathe still requires an immense amount of human intervention.

Compositional fields in the technology world are similar: there's not really such a thing as "good enough" when scheduling database backups or setting up a firewall. While one might choose (going back to the choice point above) to make tradeoffs (for example, one might elect to only take logical backups as opposed to physical ones for an unimportant database), once one's chosen the tradeoffs, things have to be precise in respect to those tradeoffs. You can't, for example, determine that you'll host a website using TLS and then just... give up when it proves hard. The sense I get is that application developers are often not as careful about that kind of stuff as we'd like².

Choice and precision are core values for people who tend to take a compositional stance to their work, but it's as yet unclear why this would translate to LLM scepticism. To do that, we need to have a look at how good LLMs are at these two core functions.

LLMs and composition

As it happens, LLMs are awful at them. Let's tackle precision first: while an LLM can convincingly create code that does something, getting an LLM to do exactly what you want it to do and nothing else is impossible, likely intractably so. Most obviously, the fact that LLMs often spit out random stuff that doesn't exist is a massive issue: inventing packages and libraries that don't exist, trying to impose patterns from one language onto a completely different one and other failures in this vein make it basically impossible to trust anything an LLM produces for you. Digging a little deeper, the only constraint you can apply to LLM output is, fundamentally, the prompt. This might be OK for creating a standalone artifact, but when doing compositional work, satisfying competing constraints while achieving a goal is the core of the task. You need to be able to make tools interact with previously specified interfaces, meet robustness and security guarantees and half a hundred other things that you simply can't get from other prompts. For that matter, an LLM can't even maintain meaningful consistency from prompt to prompt, so even if you manage to produce (somehow) one useful object using an LLM, there's approximately zero hope that any other objects you generate with an LLM being consistent with the first one. All of this, for someone working in a compositional field, is quickly going to drive them up the wall and make them give up.

Choice is no better. An LLM is ignorant of the context and implicit knowledge that a practitioner has and knows nothing of the goals or design of the system you're trying to build. While it might have a slight advantage over a practitioner in terms of discovery (LLMs can throw up tools that you might not otherwise have known existed), it can of course also hallucinate stuff about the things you're trying to make a choice about that just aren't true, and simply has no grounds on which to inform a decision as to which tool to use. Furthermore, LLMs are a statistical average of human language, and are thus highly likely to give you an average solution. Given how bad the average solution is, average is not good enough: it leads to things like suggesting the use of React for a basic static site or Kubernetes for one dockerised application. A compositional practitioner of any real quality is quickly going to find this annoying.

Interestingly, neither of these things is as important for someone taking the transformative stance (though there are still many transformative practitioners who'd probably find it annoying as hell). Transformative practitioners tend to focus on one object at a time, with how it interacts with other things being a secondary consideration to what new function the thing created can serve or what a user can do with the one object. Being more focused on creating a new thing rather than choosing between existing ones and combining them, moreover, choices tend to not be front-and-centre in a transformative framing so much as trying to discover what a piece of code does or should do. These are all things that an LLM can conceivably do, if not well. And for one single artifact, an LLM can generate something that looks right, does something close enough to what the user thinks it should do that a transformative practitioner might think it acceptable, or at least a good starting point.

This, to my mind, underlies a lot of the core conflict between (sensible) sceptics and (sensible) advocates: we're trying to do very different things in a field where the differences have been obscured by the halo of "tech". A transformative practitioner sees the technology as something good for proofs-of-concept, exploring vague thoughts and trying to build towards something new (many of them will eventually get frustrated with it, of course). Even with its flaws and the things it does badly, it can still feel like one's making progress. A compositional practitioner, by contrast, finds the thing immensely irritating almost immediately. The LLM comes across primarily as an electronic dumbass that's constantly wrong about everything, the mistakes it makes are unforgivable in a field where slight mistakes can mean frequent outages, security breaches and massive cloud bills, and it is worse than useless in the core skill of making the choices of which parts to include in your project. The LLM therefore becomes immensely more of a nuisance to a compositional practitioner than to a transformative one.

Looking at the failings of (usually not very good) transformative practitioners using LLMs, they also fit the pattern described here. A common failing I see on LinkedIn in particular is people claiming that programmers are dead because LLMs can generate a full website and then the website falling down on basic usability criteria. In extreme cases, people post links to localhost:8080, failing to understand everything that goes into deploying a web app and exposing it to the internet, and when they do manage to expose it, the websites are often missing TLS, break when faced with minor changes to screen resolution, have messed-up layouts, are full of placeholder text and have forms that simply don't work. For a particularly ignorant person, these are all things that can be handwaved in a proof of concept, but for someone more compositionally oriented, it's rather like jamming nails into your eye sockets.

This leaves us with one more question: if this is the case, why is the LLM clamour this loud? One could, after all, feasibly just market LLMs to the section of the population that might find them somewhat useful: people doing transformative work who need to be able to explore a wide range of options when creating their thing. Why do the rest of us have to deal with all this shit?

Innovation and the cult of transformation

It might seem so far that I've been fairly hard on the people doing transformative work: this really isn't my intention. We would make no progress at all without people willing to reshape the raw matter of the world into new and interesting shapes and figuring out what parts need to be made in order to make systems that someone like me can't even think of (in fact, that's a lot of why I struggle with transformative work: visualising a whole lot of parts all at once is a lot of work, especially if they only do anything useful when all of them are together. In fact that's why I like containerisation so much: it gives parts a shape and makes it easier for me to make the ones I need, essentially shifting the type of work being done from blacksmithing to precision machining). Without transformative work we'd have no PostgreSQL, no HTML, no email, no internet and probably even no computers at all. So it's important and the people who do it are important: the good ones are also very good at what they do.

Unfortunately, the business people at some point got wind of this idea and started getting very excited about innovation. They lionised it, talked about it everywhere and did everything they could to encourage it in their businesses and in wider society. And while doing so, they focused in almost entirely on transformative work.

This is particularly glaring in the case of Silicon Valley and the Venture Capital industry more generally. What's lauded as innovation is almost exclusively the new thing rather than old things put together in new ways: the sword rather than the machined rifle. Mark Zuckerberg created a website that let Harvard students rate each other on fuckability (to use Cory Doctorow's excellent phrase): the many, many engineers that built and developed the infrastructure to let that website scale and work reliably is never mentioned. Elizabeth Holmes was funded so heavily in large part because she proposed a radically new creation: the fact that it was a fraud wasn't really a problem until it got too bad to ignore, and the same people who funded that have done their best to gut all semblance of public health initiatives in the USA (a compositional field if ever there was one). And who can forget the radically new and exciting Juicero? By contrast, initiatives involving the recombination of old tools have trouble getting headway: nobody wants to care about high-speed rail when the Hyperloop exists, or support vaccinations when new drugs are an option. And of course, in the end, LLMs are themselves an example of this: something new, shiny and capable, but nonetheless something that doesn't fit into systems or meet real needs. They're a beautifully forged sword that was presented to a society that didn't need swords, and is now being jammed into random pieces of machinery because after all "it's an important part and if we don't use them in our machines, we'll be left behind". Of course, all that happens is that the machinery breaks.

This attitude has unfortunately filtered down into wider society and tech workplaces in a way that might be at best be described as "reactionary misogynistic hagiography". The people building new applications are lauded: app developers, founders and tech leaders, skewing heavily male and heavily white, are spoken about in glowing terms, called geniuses and made out to be something to aspire to. Innovation and good tech work is, in the end, made out to be entirely transformative. Meanwhile the people doing the compositional work are more diverse, more female and pushed to the margins, with the work consequently being treated as feminine and thus lesser. We've seen this happen with design and front-end development, and we're increasingly seeing it happen with infrastructure and DevOps. More concerningly, outside of tech many of our militaries seem to be treating logistics and combined arms as somehow feminine and lesser (both of these are compositional tasks, the latter almost by definition). We can count the cost of the last thing, at least, in lost Super Hornets.

When we have this attitude to innovation in our society, the current LLM hype wave is pretty unavoidable. After all, it is a new and interesting thing, it creates new and interesting things and it was made by Sam Altman, one of the geniuses of our time and a man whom we should all defer to and almost hold sacred. It enables so many more men to try their hands at entrepreneurship and making new shit, and well, when all's said and done, all the "boring", steady and careful work of composition that it takes to actually make something like that work isn't important. Nobody cares about slowly, steadily and carefully putting precisely crafted things together to make something new.

Unfortunately, compositional innovation, however much people might like to ignore it, happens quite a lot. Public transport is innovation. Municipal sewage is innovation. Hell, even the invention of the steam engine was as much compositional as a de novo thing: the cylinder technology that steam engines relied on was originally developed for machining cannon barrels, much of the demand for the thing was spurred by the Spinning Jenny's need for significant rotational power that couldn't be provided by watermills (by-the-by, a lot of the external couplings in steam engine machinery were directly lifted from this kind of mill) and even the fuel was what it was because Newcomen developed his initial steam engine for draining coal mines. When the time came for Newcomen and Watt to build their engines, they only had to design one part in a system that was otherwise mostly in place.

Compositional innovation, for all that it's not as exciting as the transformative kind, also seems to do better for most people on the whole. I care a whole lot more about sewage systems and electricity than I do about Facebook, and even in the space of computers, I'm much more of a believer in boring things that let people be interesting than new, exciting and interesting technologies that make people boring and shallow. LLMs, serving only the transformative kind of innovation, and that mostly badly and wastefully, are thus something that I'm naturally going to despise.

When the LLM hype inevitably ends, and perhaps even a little before then, we need to remember that, unfashionable though it might be, compositional work is just as important as the transformative kind and it needs to be respected and valued. This means respecting and valuing the attitudes and ways of being of the people who do it, and rather than constantly trying to force a very limited version of innovation on us, let us do things the way we like to achieve the ends we want.

Oh, and if you try to tell me that LLMs are the future of everything again, I will deliberately poison your favourite one so that it makes you run up a $ 3 million AWS bill.