A couple of days ago, Dan Hon published his latest newsletter on the subject of LLM based coding agents. In it, he differed from me on a number of points that I made in my last article, and being first and foremost a writer by temperament, I am obviously deeply and unreasonably sensitive to any criticism whatsoever. Naturally, then, I had to write an ill-thought-out and overwrought response to the piece immediately.

Dan’s argument, broadly construed, is that because of the deep expertise that people like Simon Willison and Jesse Vincent have in software development, along with them being systems thinkers, they can coerce the LLM tools into working well for them, massively customising the tools for the particular outcomes that they want and thus getting better results than someone relatively inexperienced can. I won’t say that there’s nothing to this: Simon does have something like twelve years’ experience on me and is likely much stronger qua writing software in the restrictive sense than I am: my interests tend to run more towards data, infrastructure, statistics and high-performance computing.

I also don’t think that it explains everything by any stretch. After all, I’m far from stupid, and insofar as I can tell from what I’ve written so far, I’m also both curious and untrusting and a systems thinker. I simply tend to care more about a different range of systems: often ones to do with politics and culture. It feels odd, then, to have it suggested that Simon and Jesse have some basic underlying faculty with LLM prompting that I fundamentally lack because, when all’s said and done, I seem, at least superficially, to have a lot of the same traits. Besides, arguments from fundamental personality traits have always made me uncomfortable: if there is a skill to using LLMs, it should be learnable and reproducible by most people, and the implication in Dan’s piece, as I read it, is that the preternatural skill that the Jesses and the Simons of the world have in working with LLMs is largely innate.

Which raises the question: what if the people on the other side of the divide aren’t more trusting, less curious, less experienced or otherwise less suited or less capable of making use of the tools? What if they’re simply humanities people? Or worse, mechanical engineers?

Who are our heroes?

So as not to bury the lede further, what I think Dan and Simon (in his writings on LLMs) both miss is the degree to which the perceptions and uses of LLM technology are deeply shaped by cultural factors. While I don’t know much about Dan’s background, Simon has a Wikipedia article about him, so with a little snooping we can find that he qualified in computer science, has received Y Combinator funding and worked for at least one Silicon Valley luminary, and currently sits on the board of the Python Software Foundation. Both Simon and Dan have also spent significant amounts of time living in Silicon Valley, and the sense I get is that they’re both highly acculturated to what I might refer to as the default Bay Area tech culture. You likely know what I’m referring to: "move fast and break things", a certain predisposition to trying to solve social and political issues with technology, the kind of weirdness that comes with almost everyone around you working in tech... even given that I don’t think Dan or Simon really fully subscribe to the culture, it’s still the reference point that they will use.

I’m pretty far from that: my academic qualifications are in Engineering Science, a field that is largely about the application of mathematics and computer science to engineering problems. While coding was a significant part of the syllabus, the software elements of the course were very much in service to such things as writing Finite Element solvers or fitting statistical models using Bayesian methods: a very different set of concerns to what your average software developer in industry is working on. More importantly, this was very much an engineering degree, which brought with it a primary focus on building physical in-the-world artifacts out of concrete and metal and making them work with the magic of electromagnetism and featured a considerable focus on engineering ethics and standards. I also live in a city in New Zealand of about 200,000 people with an economy that is still, after all these years, largely oriented around the dairy industry. This is inevitably going to lead to my having a very different set of cultural reference points to Dan and Simon, and thus to a different set of concerns.

This distinction is most in evidence in the heroes that our two distinct cultures choose: the people that we believe worthy of emulation and praise and the behaviours and achievements that they exhibit. The technological culture tends to praise risk-takers, iconoclasts and people who exhibit cunning and cleverness to build new things, disrupt old things and usually become rich in the process. Example figures might be people like Steve Jobs, Marc Andreessen and, unfortunately, Elon Musk: Simon himself might well count as a minor hero in the culture considering his contributions. The key virtues being expressed tend to be novelty, independence, ambition, a bias towards action and building something rather than nothing. The key is to throw time, energy and resources into creating something new and brilliant that changes the world, no matter how many lives or anything else are thrown away in the process. This is, in short, an honour culture, where engineers compete for glory on the field of open-source software, aiming to be elevated in the eyes of their peers and the industry. It’s a culture that would be recognisable to Achilles or Beowulf almost immediately once you got them caught up on the context: the goal is to make a name for yourself that will be remembered for ages to come.

In my part of the world, none of this really flies: iconoclasm in bridge design, for example, tends not to be associated so much with wealth, fame and changing the world in new and exciting ways. Rather, it’s associated with messy, expensive disasters. Similarly, cutting corners (which the use of a coding agent fundamentally is and will be for the foreseeable future) when launching things into space tends to lead to the kind of TV footage that’s liable to kill your career, along with six astronauts and a primary school teacher. We just don’t really have the kind of culture that encourages the energetic, world-reshaping kind of hero, and inasmuch as we ever had them, they mostly live in the past: the Newcomens, Watts and Faradays of the world all live quite a lot further in the past than the heroes of Silicon Valley. Hell, for civil engineers the hero-cult goes back so far that we likely couldn’t even identify that kind of hero: even Sneferu’s architects were primarily concerned with maintaining existing buildings and correcting previous mistakes, as we can see in the Bent Pyramid:

Whatever you might say about the skill and ingenuity of the architects, there isn’t all that much that’s heroic about having to adjust plans on the fly due to foundation instability, or having to perform major corrective work for the same reason. Our heroes, by and large, are maintainers, people who quietly did the work of keeping alive the things our predecessors built that were valuable and improving on them when needed. They’re also whistleblowers and dissidents, people who held the line on the fact that what someone else did was wrong and dangerous and would not be silent about it, often at the cost of their careers or even lives. In contrast to the honour culture of tech, our culture is heavily influenced by the mediaeval church and at times can be almost monastic in nature: our task is to contribute to the long work of salvation, which no one person will ever complete. Individual heroism is thus less important than piety and the willingness to suffer for our principles, and while tech culture encourages you to make a name for yourself, engineering culture encourages you to work, quietly and diligently, for your salvation and for the salvation of the world.

So, what does that have to do with coding agents? In his article Dan posted the following:

I think “deciding what well is” is an inherently human skill that is very difficult for AI to replicate well enough consistently.

This is true, but I also don’t think it goes anywhere near far enough: as any student of the humanities will tell you, it’s a well-established fact that what "something being done well" is an extremely culture and society bound concept. Whether or not a technology is considered "useful" very much depends not only on the use value of the technology in itself, but on what the culture that it’s embedded in believes is useful or productive. And guess what? Dan, Simon and I are all embedded in very different cultures.

In the odd kind of honour culture that is tech, where you gain fame and social status by doing great deeds of technical heroism and innovation, coding agents make a lot of sense. First of all, using a coding agent is in itself a sign of being forward-thinking and at the cutting edge of tech: after all, this is the big new thing, and being able or allowed to keep up with new trends in tech is an important status signifier in tech culture. Even using the thing at all means that you’re cooler, more productive and more innovative than those of us that don’t. Secondly, the culture stresses production over the work of maintenance and reproduction: the person who first creates something is honoured and gains much status, while the dozens of people who quietly work for years or decades on keeping it working, updating it to keep up with times changing and developing new uses for the thing are largely forgotten, despite the fact that they’re the ones that actually make the thing valuable to people. Linus Torvalds is famous, but the Linux kernel, in itself, isn’t good for much: the value of the kernel comes from the hundreds of thousands of people who’ve maintained it, patched it, updated it and built things for it. The value I get from using Linux comes as much from the people who’ve built KDE and the applications that I use as it is from the kernel (I could probably run OpenBSD and get many of the same benefits as running Linux, but replacing KDE would be much harder). Given that new breakthroughs are how you gain status in the tech world, though, being embedded in tech culture means that coding agents start seeming remarkably useful: after all, you clearly can create new things with them, which you can use to gain glory and social standing in the eyes of your peers. And ephemerally, they will work, which by the standards of the culture of tech, means that coding agents work "well": they allow for the accumulation of glory and social standing exceptionally effectively.

For us who seek salvation more than a glorified name, and who are willing to take up the long work, though, coding agents seem less valuable. One thing that I probably under-discussed in the last article was the fact that coding agents, however we spin it, cannot maintain code. They can produce a first product, but time passes, languages change, and APIs and libraries become deprecated, and things start breaking. The best that a coding agent can do in these situations is to, one way or another, "make the thing work again". To understand a bug or a breakage when it occurs requires you to read the generated code, line by line, unpick the whole chain of failures, understand what caused the issue and redesign the code so that the issue doesn’t recur. I am certain that this will be disputed, but I know in my bones that this is the only way to fix a bug for good: while LLM code can often be adequate, LLM bug fixes basically never are. This comes from my training in non-software engineering: if you don’t know why something failed, you haven’t fixed it or prevented it from happening, but merely set yourself up for a bigger disaster to come. To build something that can be truly called reliable, then, takes multiple prototypes, lots of work on eliminating bugs, learning from previous projects, a lot of institutional logic and constant monitoring and maintenance. And if you’re taking it seriously, every time you push a fix you ablate away a little of the LLM code, to the point where in a mature product, even if you started with LLM-produced code, there’s likely to be very little of it left. In the framework of the long work, then, there is very limited point or value in what a code agent produces.

There’s also a moral angle: while the honour culture has Achilles’s shade in Asphodel whatever his morality looked like, those of us who work in engineering culture are at very real risk of damnation. The things we work on, after all, can kill people when they fail. A bridge collapses, or a building catches fire, and if we failed in our diligence, hundreds or thousands of people can die. What we work on, in short, has real moral weight, and we will apply that lens to everything we do. The honour culture doesn’t really care about harm done: Achilles remains a hero while killing a whole lot of people for not very good reasons, kidnaps women and keeps them in sexual slavery and then sulks in his tent after Agamemnon decides to take some of those women for himself: in any culture that partakes of Christian morality, this is enough to condemn people to hell multiple times over. It’s often said that this is because software is less likely to kill people than the kind of engineering I was trained in, but this simply isn’t true: the British Post Office using shoddy software led to at least thirteen suicides, the Therac-25 consistently gave patients massive overdoses of radiation, and it’s nontrivial to find a whole host of other situations where code, in more or less dramatic ways, can kill a lot of people. Consequently, people writing code in highly sensitive spaces do not (I can personally attest) share the broader tech culture: they act much more like engineers. I suspect, then, that there’s a difference in the attribution of responsibility between tech culture and engineering culture: while a tech-culture person who releases code with an LLM-created bug in it might be temporarily shamed by it, it usually won’t be seen as morally reproachable. An engineer who releases similar code, however, will be judged as though they recklessly put the entire community in danger, which is a much more severe sanction.

In the end, I think that explains why those of us from engineering cultures tend to see coding agents as much more pernicious than those from tech cultures. Firstly, we tend to take quite a different view of productivity: while Dan praises Simon and Jesse for their productivity and mentions that coding agents enhance that even further, I’m not actually sure that I care much. Django was enough; it was a diligent contribution to the Python ecosystem, and maintaining and stewarding that by sitting on the Python foundation’s board is more than enough for anyone to be proud of. If Simon chose to maintain and steward what he’s already done rather than producing more, then, that would be enough, and in the engineering view he doesn’t necessarily gain more merit by doing more. Writing, mentoring, thinking and all of the glue work that goes into keeping a technical ecosystem together are all just as important as the initial act of production. Secondly, if work is worth doing at all, it has to be worth something to someone: the value of code is in how, one way or another, it makes someone’s life better in some way. While a solution might be imperfect and have flaws, then, if something isn’t completely useless cannot abide even minor flaws in the core function of the thing. Take a screwdriver, for example: you can cheap out and use soft metal or metal that has a tendency to rust. You can economise with the handle. There are a whole lot of ways in which you can make a screwdriver shoddy without compromising on the core function. If you create a screwdriver with a handle that a person can’t grasp effectively or with a head that can’t gain purchase on a screw, though, the tool is useless and you’ve failed at designing it. This means that everything, to a greater or lesser extent, calls for the level of regard given to a situation where life is at stake: you never know when a tool that you make or something that you build might be put into a situation where lives depend on it, after all.

The situation we’re faced with, then, is one where the code agent works "well" from the perspective of the tech culture that prioritises what is essentially competition between elites to do great deeds, but doesn’t do "well" at all in a culture that for all that it’s close in domain to what software developers do, has very different attitudes and discourages this kind of elite competition across the board in favour of a much more collaborative attitude. While, for a number of reasons, I have little love for the tech culture and what it prioritises, I don’t think we can say that either perspective is wrong: certainly, I think the engineering culture perspective brings a lot of value to the table that it would be a shame to drop. However, a lot of people in tech culture seem... disinclined to offer that consideration to other professional cultures.

As mentioned earlier, a lot of people coming from the tech culture tend to judge others by their own culture (I guess most people do this). When faced with this position, then, there’s a tendency to judge perfectly good engineers, scientists or humanists as defective tech-culture people who will be "left behind" or otherwise marginalised. Willison even says as much in one of his blog posts:

Since Claude Opus 4.5 and GPT-5.2 came out in November and December respectively the amount of code I’ve written by hand has dropped to a single digit percentage of my overall output. The same is true for many other expert programmers I know.

At this point if you continue to argue that LLMs write useless code you’re damaging your own credibility.

Let me stress: this is a blind spot in his thinking. It isn’t being particularly wise, it isn’t an indication that he knows more about the tools than the rest of us. It’s a cultural bias that holds his culture and its values to be superior to those of engineers, scientists or humanists and believes that he has nothing to learn from them. I’m fairly certain that this isn’t conscious as such, and that Simon doesn’t consciously hold these beliefs, but this still leaves a bad taste in the mouth, all things considered.

Everything is gender

Unfortunately, that isn’t an end to it. As Dan was kind enough to specify that he was not criticising my capability or experience, I will return the courtesy by stating that I do not think that he is in any way consciously sexist or bigoted: I believe that he is well-meaning and does not harbour any conscious beliefs about women being less capable of software engineering than men are. Nonetheless, the framing of the situation feels suspect, and I don’t think I can ignore it.

We can note from observation that Dan and Simon are both men, and I am a woman. This isn’t an uncommon situation when discussing LLMs: LLM proponents are disproportionately male, while critics or people who take a more sceptical stance do tend to be, in aggregate, more female and less binary in gender on the whole. Sometimes this is innocuous, but other times it leads to things like Kat Marchin being driven off the internet thanks to relentless death threats over the Openslopware project. The point is that there’s a noticeable asymmetry in the people who are for the use of coding agents as opposed to those who have a warier attitude to the tech, and that this asymmetry isn’t exactly innocuous.

In that situation, the fact that getting results out of code agents is placed in a deficit framing is deeply troubling. To quote Dan:

Simon and Jesse are experts with decades of software development knowledge. I also understand them to be systems thinkers - they know enough about how everything works. In temperament as well, they’re curious but also untrusting. Not everyone is like them. The point here is that the tools aren’t easy to use well, where “well” means producing software that meets certain criteria. What Simon and Jesse are also good at is deciding what those criteria are in ways that are appropriate to the task and context. This is also something that not everyone is good at.

...

I think what Simon and Jesse have done is to massively customize the tools for their own particular usage. That’s on a different end of the continuum of using LLM-assisted coding out of the box. They just aren’t ready for mass use yet.

It’s really rather hard to read this as anything other than "Simon and Jesse (who are male) are very clever and have the right experience, patterns of thought and temperament to make this very powerful technology work for them, whereas I (a woman) don’t possess that". The possibility that I have the capability but don’t share the value system that makes code agents useful to them is pretty neatly excluded here, and I can’t help but read a bit of implicit sexism into it: if I don’t get the results that I find valuable from a code agent, it’s because there’s a flaw in me rather than the tool being not fit for purpose. I should value something else, or I lack some fundamental gifts needed to make the coding agent work (personally, I wasn’t aware that Claude Code was operated with the penis and required high levels of testosterone in the bloodstream in order to function, but I’m always open to learning new things). That, I think, certainly says something about the culture surrounding LLM use.

Even before the advent of code agents, the honour culture of tech was very much a patriarchal one: while women weren’t directly excluded, the culture is very male and women are systematically disadvantaged in gaining the highest degrees of honour and glory in it. After all, producing these new innovations requires you to dedicate a hell of a lot of time to writing software: time which often requires you to have someone else cooking, cleaning and picking up for you around the house. Men are far more likely than women to have access to this kind of support. Even in tech, the culture tends to relegate women and nonbinary people to support roles: minoritised people, far more than white men, tend to end up in fields like data, site reliability, front-end engineering and all of the maintenance work and reproductive labour that the tech industry requires rather than employing them as core software engineers solving what tech culture thinks of as the "real problems". This isn’t necessarily because core software problems are harder to solve, but because the work of doing them is not valued by the culture that it’s embedded in: site reliability and data engineers are regularly solving problems far thornier than what your average application developer deals with, but they’re marginalised as "maintenance" done by people who "aren’t real programmers". I think it striking, for example, that a regular complaint that people like me make is that coding agents seem to really struggle with things like Terraform, Dockerfiles and CI/CD (you know, the things you’ll probably be using to let someone actually use your app, which makes them more than a little important), yet this is almost never considered to be a major issue with what the tools can do: so long as they can produce adequate Python or Javascript in volume, people are happy. In short, the code agents are great with languages that are gendered more "male" in tech culture, but really rather bad at the ones that are gendered more "female".

We’re already dealing with this shit, in short: men are already claiming the bulk of the glory for doing the (most prestigious, but not necessarily hardest) work, while we, who work just as hard and are just as clever, are marginalised as not really counting. The fact that a similar set of tropes are emerging in the code agent discourse is thus very concerning. In short, code agents are increasingly becoming a way in which masculinity is performed in the tech world.

In this nascent dialogue, men are far more capable than women of the subtle patterns of thought and setup needed to make good use of code agents. This means that they can become much more productive than everyone else, which means that they become the centre of the coding world, producing large volumes of code and new tools for other people to use. The maintenance of and infrastructure behind the tools is pushed to the side and devalued as women’s work, where the technical skills needed to make everything work and keep working are devalued, treated as of little account and poorly compensated. An ever increasing group of marginalised people is exploited and paid much lower wages than the men to actually put the tools that the men with code agents wrote to some kind of use. When a messy accident occurs, they’ll be held accountable, of course.

In the current tech culture that’s forming this nascent dialogue, then, code agents are the spears that the high and mighty of the tech culture fight with for glory in battle. They’re a way for men to assert their masculinity and their skill in producing much new and innovative code, and they demonstrate to the men that use them that they are fighters and effective on the field of combat that is innovation. As much as they’re used to write code, they’re used to fight for status and glory even more: they’re a way for people to make a name for themselves. To express other skills and virtues than success in writing new code that is "proper software", or to wish to write software in a different way, has the taint of femininity and is to be avoided: after all, making a plate can be a masculine pursuit, but washing it is distinctly feminine. In short, maintaining and deploying code is gay and effeminate.

A popular aphorism in my Bluesky bubble is "Everything is gender", and this is unfortunately quite applicable in this situation. Given the way in which the technical equivalent of "women’s work" is essentially shoved under the rug or stigmatised as being unmasculine, tools that are made primarily by men and for men completely fail to take women’s work into account. Then, by a subtle sleight of hand, the work that is valued and seen as "technical" becomes the work that can be done most effectively by coding agents, and thus, in the tech culture, becomes valuable de facto. There’s no particular technical reason that things should be organised this way: we could build a culture in which people writing hard technical code are seen as useful but a bit weird and are generally kept out of the way in favour of the people who use these tools to engineer real systems that don’t fall over. In that kind of case, the person who writes the Node app would be relatively unimportant while status accrues to the person who keeps the Kubernetes cluster turning over. But this isn’t the world we live in.

The tech culture version of "well", then, has a distressing tendency to ignore an awful lot of important work because it’s seen as being less prestigious and generally a job to be done by women or people who are otherwise less well-regarded than our prototypical software men. The fact that the coding agents don’t do at all "well" on what is easily half of the work that it takes to actually deliver a software solution to an end-user doesn’t seem like an issue, and neither does the fact that coding agents often introduce code patterns that make the delivery actively harder (a problem that will likely have to be solved manually by said less-prestigious people). For the people manufacturing and using these agents, though, neither the thoughts of other professional cultures nor those of marginalised people in their own culture seem to matter much: they aren’t worth much of a thought. This feels arrogant and honestly quite distasteful.

Conclusions

I stress that I don’t believe that either Dan or Simon consciously hold these beliefs: in fact, I’m convinced that if pushed, they would quite quickly disavow them. The cultural norms of an industry or a profession do, however, shape how you think about certain problems and drastically colour your perceptions, hence the current situation, where I can only feel that Dan mistook someone working in a different mode and with entirely different values for a defective version of a generic tech person.

Code agents are the product of a certain culture with certain values, and make quite a lot of sense within the bounds of that culture, where engineers are fighting for the honour and esteem of their peers in contests of cleverness and innovation: they let you produce more, innovate more and thus gain higher status. For those of us outside the culture though, the tools really struggle to seem useful, and in fact make the entire tech culture seem vain, obsessed with pointless status games and perilously uncaring towards human life. Looking at the industry objectively, it’s hard to say that this is an inaccurate description.

I’m not going to say that tech culture should dissolve itself entirely: that’s likely impossible and in any case isn’t a reasonable demand to make. I would ask, though, that tech culture be a bit more self-aware. The fact that the culture outright ignores an awful lot of the actual work that goes into turning a proof-of-concept application into something that users can reliably access and use is in itself a massive problem, as is the fact that other professional cultures that rely (as almost everything does) on computing technology tend to have their particular cultures trampled over by the techies (let’s face it, the vast bulk of data science boils down to "statistics done badly by someone with no training in it"). Inasmuch as tech is even aware of the existence of other professional cultures and groupings with their own institutional and cultural knowledge, the first instinct is to think that they’re defective and try to make them more like the tech world: this had led to some truly stupid situations occurring. A little indication that other professional cultures might well be right in saying what they say, and a little more consideration of the parts of their own culture that they consider unimportant, might well be wise.

If, after all of this, I somehow still seem like the kind of person you’d be keen to work with, I am currently on the lookout for consulting or contract work, or the right full-time role (I am not a high-status engineer and need to be able to pay for rent and power). I mostly work in the data and infrastructure spaces, and am good at quite a few other things.