Understanding friction in software engineering

In the last month or so we've seen the USA embark upon what's quite possibly its dumbest forever war yet. The USA and Israel, without warning, launched widespread airstrikes across Iran, killing Ayatollah Ali Khamenei and much of his family and striking nuclear enrichment and military facilities (along with no few schools, hospitals and other civilian buildings, the targeting of which is a war crime). The hope, one guesses, was that targeting the leadership of Iran would lead to regime collapse and the end of Iran as a regional enemy of the USA. This isn't what happened: Iranian institutions held together, a new leader was chosen and Iran launched widespread and rather indiscriminate retaliatory strikes against US airbases in the gulf states, Israel and more or else anywhere else they could reach. More importantly, they also closed the Straits of Hormuz, though which 20% of the world's oil and 25% of its LNG passes, completely fucking the global economy and more or less ensuring that the USA's involvement in the war will not stop at airstrikes.

While this is awful all around, what's interesting from the perspective of readers of this blog is how the war appears to be falling apart. The attacks started in a very well-organised, co-ordinated and enthusiastic fashion: all of the major targets were hit and Khamenei was successfully killed. As things went on, however, things began to fall apart. The Iranian regime did not respond in the way that American leadership was expecting and, in fact, resolve to keep fighting hardened rather than the regime collapsing. The aircraft carrier USS Gerald R. Ford, deployed to Iran to support these strikes, had to retreat after broken toilets and a laundry fire that led to 600 sailors losing all of their possessions and bunks made the continued deployment of the carrier untenable. Iranian retaliatory strikes on US army bases and airfields killed US soldiers, destroyed aircraft and radars and most recently destroyed a very expensive and important AWACS aircraft that even the USA can only maintain 16-20 of. Iranian proxies in Lebanon and elsewhere caused increasing problems, leading to Israel invading Southern Lebanon and generally escalating far past what the USA was expecting, and recently the Houthi movement in Yemen has begun strikes on shipping in the Red Sea, further exacerbating the already catastrophic shipping situation that the closure of the Straits of Hormuz started. While the destructive capacity of the US army remains more or less undamaged, then, the attack is still failing, not as a result of anything serious being destroyed but simply because things are breaking, going wrong, planning and intelligence are failing and co-ordination is breaking down. It's hard to conclude anything, really, other than that the leadership of the US regime is very, very stupid.

While the fact that these leaders were in charge of the most powerful military on the face of the planet means that their stupidity leads to untold pain and suffering the world over, the mistakes that they're making are sadly not unique to them: many of our leaders in our countries, our workplaces and our industries make the same mistakes and have the same blind spots. In this article, I want to talk about one that's particularly common and particularly damaging in the tech industry: an inability to think clearly about or identify a concept developed by military theorist Carl von Clausewitz called friction. While it's not entirely clear to me that a failure to understand friction is the main issue these people have (honestly, if there's a strategic or operational mistake to be committed, they've probably committed it at this point), it's certainly an element in this, and thus worth talking about.

So, what is friction? And why should those of us working in the tech industry care about mistakes that Hegseth et al. are making?

What does Clausewitz mean by friction?

As is often the case, Clausewitz uses friction in the context of fighting a war as a term of art: the usage of the word in this case has a noticeable relationship to the general usage, but isn't identical to it. This is good for concision, but also means that before we can apply the idea to a new field, we have to explain what friction, in this context, actually means.

In war, friction is simply the tendency of unexpected things to start happening the moment an offensive (or some other operational push) starts. Consider the beginning of an offensive (say, the current US/Israeli war on Iran). While the offensive is being planned and your forces are preparing, things are about as good as they're going to get: you have good intelligence and have been monitoring your enemy's movements for some time so you know more or less what's going on, your troops are all fresh and motivated, your equipment's in working order and things are generally ready. Your offensive power or ability, more generally, to get shit done, is thus as its greatest at the very beginning of the operation.

So you put your multirole fighters into the air, you hit your targets throughout Iran and you kill the Ayatollah Khamenei. And, as sure as night follows day, things start going wrong. Your aircraft carrier's toilets break down and the crew have to start shitting in buckets. The same carrier, having been deployed for a full nine months, has to be withdrawn from action after a laundry room fire injures two hundred sailors. A Kuwaiti air defence installation, functioning under extreme stress, shoots down three of your F-15s. It turns out that the Iranian regime was not, in fact, going to collapse the moment the ruler was killed, but strong state institutions are in fact able to organise a response. Counterstrikes from Iran start hitting your bases across the Persian Gulf, killing people and damaging important infrastructure. Iranian missile strikes blow up your command and control aircraft. Worst of all, the IRGC starts attacking ships passing the Straits of Hormuz, causing a massive oil shock and undermining public support for your war. And little by little, things start falling apart.

Sooner or later you'll hit the point where things get fucked up enough that you can't make any more meaningful progress towards your objectives. This isn't always obvious, of course: often you'll still be perfectly capable of blowing up enemy infrastructure, killing their civilians and generally breaking things, but nonetheless you'll find that mysteriously you're making approximately zero progress towards the goals you had at the start of the operation. At that point a sensible military will call for an operational pause during which the forces deployed for the given offensive will stop pushing forward, reconstitute units, resupply and consolidate gains: in general, they stop moving for a bit, reassess and figure out what their next big operational push is going to be.

A less sensible military, by contrast, will keep pushing, wasting lives and resources even when it should be clear that objectives aren't being achieved. While obviously in the case of our current example this is mostly because the entire high command is stupid, cruel, venal and incompetent, it's possible to make this mistake without being quite so... like that. This is because friction-related breakdowns often have less to do with the blunting of destructive capability than they do a loss of information and command and control.

Take Iran's recent strike on the E-3 AWACS plane based in Saudi Arabia: the strike hasn't directly blunted US ability to just blow shit up and the USA can still direct an effectively infinite quantity of explosives to more or less wherever they want. What the US has lost, though, is a massively important element in co-ordinating attacks and being warned against incoming Iranian munitions. There were until recently only 16 E-3s in service: now, I suppose, there are only fifteen. Replacing one of these with the more modern E-7 costs on the order of $700 million per airframe: a price high enough to make even US military procurement pause. This is, in short, not an easily replaceable asset, and without it, the USA has less capacity to detect Iranian strikes, locate targets and co-ordinate the activities of other air assets in the space. Given this, the fact that the USA can still put explosives on target is less than relevant: they're less able to identify places where it'd be useful to put the explosives, they're more vulnerable to retaliation and they're in general much less able to act wisely than they were previously. From the outside, or from the perspective of high command, though, a lot of that might not be visible, and so it can be easy, for the right kind of dullard, to take continued activity and enemy casualties as a sign that they're about to win and thus continue pushing and running their own forces down for no good reason.

That, in short, is how friction works in war: things start out organised, prepared and informed. Then the bullets start flying, and little by little, things go wrong and start to break apart. Co-ordination breaks down, people get tired and demoralised, and eventually what started out as a well-oiled, effective machine that was more than capable of achieving objectives ends up as a tired, worn-out blob that cannot fight any more or go any further. This seems simple, but as Clausewitz has it, "in war, everything is very simple, but the simplest thing is hard".

A deep understanding of and ability to account for friction is really important to develop if you want to be at all good at strategy, both in the military but also in other complex endeavours. After all, this kind of friction isn't limited to the military: it happens in civil engineering projects quite a lot, it happens quite a bit in initiatives run by the civil service, activists trip up a lot on it and most importantly for our purposes, it happens a lot in software engineering.

How friction works in software development

Setting it out that way, it's fairly simple to see how friction acts in the software development lifecycle. We might start by looking at it over the lifespan of an entire software project: we begin in the greenfield with design documents but otherwise nothing but open space and ambitions. The team that we've assembled is bright, fresh and motivated (and in the better kinds of place, also well-trained and skilled). We've done our market research and our consultation work and we know exactly what our first steps are. At the very start of a project, then, we are the best positioned to deliver on the project's objectives that we'll ever be.

Run the clock forward a couple of sprints. By this point we already have a bunch of code written and maybe even an initial release. And now the bugs start showing up. Different parts of the codebase, written in different styles and with different approaches, start clashing. A few kludges have doubtless slipped in and technical debt has started accumulating. A developer might have gotten sick or burned out and winds up having to take extended leave. There might even have been an initial outage that kept everyone up for days trying to fix it. Unless the team has been very assiduous about doing everything they can to minimise friction, then, development is going to slow down and features are going to be released more slowly.

Run it forward a little more. By this point, a few of the original developers have left the company and been replaced with new people, taking their institutional knowledge with them. There have been multiple outages and cloud deployments are getting hopelessly tangled, and as the complexity of the codebase grows, an increasing number of kludges, weird bugs and technical debt becomes introduced. Morale starts flagging as people get tired and the project seems to be making less and less progress. At this point, real progress towards the objectives of the software project is becoming very slow as it becomes unclear where effort should be directed and when initiative is taken, it's often misdirected because communication between people working on different parts of the project has broken down. At this point, the project really needs to halt for a while to reorganise, regroup and do much-needed maintenance work: otherwise people will keep burning out and the project will grind to a halt entirely.

But let's assume that thanks to higher management being difficult, that doesn't happen. At this point, all of your capable engineers have left or burnt out and no longer give a shit: the only people willing to work on the project are those who are incapable of actually doing the work. Not only are bugs and kludges prevalent, reporting has broken down to the extent that nobody actually knows what bugs exist in the codebase or where they are, or what compromises have been made. Documentation bears no meaningful resemblance to the situation on the ground, and the deployment keeps breaking in strange ways at the worst possible time. The people nominally working on the project are in fact working on their own client work or simply failing to show up entirely and any work that gets done is entirely incidental. Nobody wants to look too hard at uptime or what the software is hosted on: that way lies madness. At this point, doing anything besides desperately pushing fixes and trying to keep the software barely alive is more or less impossible. If you want to implement new features, say, or otherwise keep pushing towards the initial objectives of the project, your best option at this point is to burn everything down, dissolve the team and try again, taking more care not to let friction accumulate.

If you've been working in the tech industry for any length of time, you've experienced at least one project that got to the final stage, where friction was completely out of control but thanks to poor leadership you had to keep running head-first at the enemy line (as it were), no matter how much damage is being done or how much progress is being made. It's awful: you feel as though you're making no progress to speak of, as though you have to lie to management in order to keep your job and as though it doesn't matter whether the code you write is any good or not. In short, if friction is neglected, morale quickly ends up in the toilet and no progress to speak of can be made.

A large part of the reason why we can't effectively address these issues in tech is, I think, that without a framework for thinking about it of the kind that Clausewitz created, it's difficult to see all of the individual things that go into friction as facets of an individual phenomenon. Technical debt is its own thing, brittle deployments are their own thing, poor engineer morale is its own thing and the death marches are very much their own thing, as is poor engineering leadership. We thus tend to try and address all of these things individually. To resolve friction, however, a holistic approach is required. This won't make up for poor leadership, of course, but let's face it: you don't need truly horrible leaders to end up in a situation where we're attempting to push through friction if you don't see friction as a thing. The only way to deal with friction is to deal with it as friction.

Minimising friction

While the tech industry wouldn't call it that, individual developers and engineers have developed some techniques to minimise various kinds of friction in the software development process. While these don't aim to directly deal with friction as such, their goal is almost always to mitigate individual sources of friction and consequently improve the speed and morale of developers. A lot of these methods, you might note, have been developed in the context of Extreme Programming, and in particular the good people of Pivotal Labs.

The first technique, of course, is automated testing. A major source of friction in software engineering practice is bugs: you write code to add a new feature or improve an existing one, and in doing so, break existing functionality. When that happens, rather than working on something intended to further a project objective, someone has to be pulled off a task to go and resolve the regression bug. Right away that levies a loss of time and further loss of efficiency thanks to switching costs for the engineer whom you've pulled off the work to make the fix. The rest of the team that they're working with also takes a hit: they've lost an important member temporarily and have to rework their work plans around their absence. Morale also takes a hit, because rather than moving towards their goal, the team member has to fix something which either they or someone else in their team likely broke: neither is likely to engender optimism in the team and recriminations over who fucked up are common. The fix itself is likely boring, and while the fix is ongoing the capabilities of the deployed software are almost certainly degraded. Finally, in most cases, management doesn't recognise bug fixes as wins in the same way as they might a new feature release, so the work isn't appreciated. Bugs have an extremely high cost in terms of friction, in short.

In order to minimise friction, then, our goal should be to deliver code with as few bugs in it as possible and make sure that at every stage, the number of bugs created is as low as possible. Automated testing helps a lot with this: being able to run tests often, fast and whenever you want does a lot to make sure that new bugs don't get introduced into the codebase, or that if they are introduced, they aren't deployed. It's difficult to express just how much of a difference this makes unless you've worked on a codebase with comprehensive tests before: just being able to check before pushing someone makes the whole process so much less painful than it would otherwise be. Having comprehensive tests, then, is an excellent way to keep friction in your system to a minimum.

CI/CD is another important element of minimising the friction inherent in software engineering. Manual deployment and integration are significant sources of friction in software engineering teams that still do that. For a start, manual integration often means that the people responsible for writing a given part of the codebase have to get permission from a different part of the organisation to actually merge their code into the wider codebase. While some amount of this is inevitable, it is also a source of friction: developers often feel that their work is being judged arbitrarily and by people who don't understand what they're doing, leading to interpersonal strife and morale damage. The time it takes to get someone to review the code and run the merge is also annoying as it means that people can't work fluidly but end up getting blocked not by technical issues but by other people. Thus, while some amount of manual review is inevitable, the goal should always be to minimise the amount of it to the greatest possible extent. Automating as much of the integration and deployment process as possible, then, reduces friction heavily.

Finally, making sure that developers have access to high-quality tools that let them do what they need is an excellent way to reduce friction. Working with poor or shoddy tools is a massive inducer of friction: to give just one example, I once worked in a system so locked down that I was reduced to manually rewriting machine learning algorithms in user-defined python functions in Redshift. I had no access to an IDE, no access to code highlighting, I couldn't install packages and, for that matter, my access to documentation was sharply limited. You can forget about something like terminal access. It is nigh on impossible to actually get anything done with the amount of friction that something like that induces, so if you want to keep that source of friction to a minimum, you'd better damn well make sure that your engineers have good tooling.

There are a bunch of other technical and cultural interventions that fall into the general category of "friction-reducing tools": containerisation technology, pair programming, the use of certain languages over others and even management style can all contribute to keeping overall friction levels low on a dev project. Unfortunately, you'll notice that these things all have one thing in common: these all have fairly high upfront costs in time or money. In short, you have to slow down, invest resources and dedicate time to preparation and maintenance in order to make these things happen. You need to allow downtime for engineers to rest, to make sure that all the systems they depend on to deliver fast are working, to co-ordinate, to write tests and to fix annoying but non-urgent breakages that will otherwise build up. In the extreme case, companies like Basecamp have in the past explicitly blocked out two week periods at the end of a sprint for these kinds of regrouping and consolidation activities, but even if you don't do that, you need to block out that time, treat it as sacrosanct and actually invest in doing the friction-reducing things that you need operational pauses for. None of this is stuff that individual contributors (as we so euphemistically call them) can do: if we want to push for friction-reducing policy, it has to come from leadership, and ideally from high levels of leadership.

Defence in depth: friction as an ally

So far we've almost entirely been talking about friction as a negative, and to be fair, it often is! It isn't always, however, and understanding when you can make friction work for you is just as important for leading well in the context of an environment where friction is a real factor as understanding how to get rid of it. Here, then, we'll talk for a bit about friction as an ally.

To go back to our current war and the recent loss of the E-3 AWACS, Iran has been making a deliberate policy in this war of striking US and Israeli radar installations. This might not immediately make sense to someone without knowledge of how we fight wars: surely you want to hit destructive capability rather than what looks like a weird civilian plan with a spinny thing on top of it? The goal of destructive capability, however, is to actually destroy strategically important targets rather than blowing up schools and hospitals: as much as I'm pretty sure that Trump and Hegseth actively get off on death and suffering, this is, from a military perspective, a fucking stupid idea. Being able to locate and identify targets, then, is kinda important, and it's no surprise that one of the major effects of friction is a breakdown in command-and-control, or, you know... the military capability that involves identifying which targets you need to hit in order to get the results you want. Hitting radars and AWACS capability, then, is Iran maximising the amount of friction that US and Israeli forces are exposed to. Doing this also reduces US and Israeli ability to respond to Iranian strikes: given that Iran has few aircraft and are thus limited to ground-launched munitions that are comparatively easy to see, the best way to maximise how many of them get through is to induce enough friction that the enemy can't effectively detect or respond to launches: again, this is a large part of what they're doing at present.

Blocking the Strait of Hormuz is once again a way in which Iran is maximising the friction that enemy forces are exposed to on several levels. First off, the blockage is something that the US has no option but to attempt to clear (apart from agreeing to a ceasefire, in which case Iran more or less wins). If the US wants to clear the Strait, then, they have to deploy additional forces beyond what they already have and, importantly, redirect forces that they could otherwise use to strike targets in Iran to support that effort. That means bringing more materiel into theatre, which means exposing more of it to Iranian strikes. It also has a real effect on the strategic level: rising fuel prices, increasing shortages among allies and the consequent discontent makes it increasingly difficult for the enemy to actually prosecute their war without... unpleasant things happen. And this too is Yuri... sorry, I mean friction.

This ties into the general defensive strategy (which Iran appears to be applying) of defence-in-depth. In a defence in depth, you don't aim to hard stop the enemy at the border: rather, you apply just enough pressure to induce friction in the attacking force, while falling back yourself before you lose too many troops or equipment. The enemy then pushes forward, dispersing themselves, stretching themselves thinner and imposing more friction on themselves (longer supply lines lead to more friction in and of themselves and are also more easily interdicted as we saw in the first stages of the Russo-Ukrainian War in 2022, and pushing forward also means worse intelligence as it's harder to see what goes on in back areas). Keeping minimal defensive pressure up through this whole process and launching interdiction strikes on supply lines and spoiling attacks against force concentrations, the enemy advances slowly, at a very high cost in lives and machines and loses command and control at a rapid rate. Eventually the offensive loses steam, at which point you, having conserved your offensive capability, can launch a counterattack and push the enemy out.

Now, we're obviously not usually in the habit of mounting a defence in depth against hostile actors in the software world (unless you work in cybersecurity, in which case I guess you very much are). There are, however, significant cases in which friction can still work in your favour. Take, for example, new feature requests. A low-friction situation, in this case, is that whenever someone comes up with a new idea for a feature in your software, you implement it. This, however, has considerable issues. For a start, it's often unclear whether features actually contribute to the objectives of a software project, so simply letting new feature ideas go through will often lead to you doing pointless work. It can also be deeply disruptive to existing workflows: if what you're working on changes every week, organisation and co-ordination is quickly going to be lost. In short, you actually want a level of friction in deciding what work to take on, because if there is zero friction at that point it leads to more friction down the line.

Similarly, and for similar reasons, the introduction of new technologies should be a process with a considerable amount of friction attached to it. If you're a shop working in Go and Vue, for example, you should think very hard and carefully before writing anything in Rust. After all, as with physical friction, the fewer moving parts you have in a system, the less friction is generated. Given that, adding new and independently moving parts should be a high-friction process because otherwise they will exact a consistent and long-lasting cost in friction on anything further that you do in the project. For similar reasons, adding Kubernetes to your stack should be a high-friction process.

Finally, though it's not strictly a part of the software development life cycle, hiring engineers ought to be a higher-friction process than it currently is. A large part of the problem with our current hiring system is that between online applications, LLMs and every other damned piece of technology out there, the cost of applying for a job has been reduced to effectively zero, as has the cost of putting up a job advertisement. This means that a) workers trying to find work have to apply for many, many more jobs than they would previously have even been able to find listings for and b) hiring managers have to sift through hundreds upon hundreds of plausible-looking CVs without (thanks to LLMs) any good way to filter through them. Eventually the process of applying for work becomes effectively random as the friction of making use of any of these results spikes, and the only way that anyone actually gets jobs becomes through high-friction processes such as in-person networking or writing and hoping that someone sees your work.

Unfortunately, what immediately feels good to leadership is often precisely the reverse of what actually works: low friction is concentrated in places where higher friction would be better, and we see high levels of friction in places where it really needs to be low. Which in turn leads us to...

Learning to lead

It is a true but unpleasant fact that the amount of friction reduction that can be done by individual people is sharply limited: tackling friction in any meaningful way has to be done by leadership, and ideally by as high a level of leadership as possible. Paying for high-quality tooling, actually watching for friction and calling for operational pauses and investing in maintenance and preparation work are all things that only leaders can make happen. They're also things that leaders can quite easily kill if they're not aware of what's going on: if a leader demands that people push harder when there's no way that pushing harder will actually get the results they want, tells people to ignore maintenance or not write automated tests because they slow people down or otherwise tell people to stop doing friction-reducing activities, it's quite easily for a team to end up completely bogged down. Leadership will then, of course, think that the team is defective and not understand how their own actions contributed to the problem.

The first thing we need to do, I think, is improve how we choose leaders. It is manifestly obvious to anyone who's led the news that we're currently very bad at this on a societal level. While it's true that the Trump regime in the USA is unusually bad, a lot of the personality traits that we see in Trump-appointed leaders come up in a lot of corporate leaders the world over: a disdain for expertise, deep incuriosity and an unwillingness to learn shit that might change their worldviews. A lot of CEOs are generally just... dullards. The single biggest thing that we could do to reduce friction losses in the tech industry, then, is to make sure that leaders like that don't get appointed. While I do have one idea for how this could be done, most of this is a matter for politics rather than for the tech industry itself.

Assuming a lack of bad leaders or leaders unwilling to learn, though, education can go an awfully long way towards preventing these kinds of mistakes. You now, having read this, know what friction is and how it can be handled. You know what to look for, and you know that a lot of the disparate things that you might have thought of as being separate problems before are all facets of a winder phenomenon. And you know what you can do to deal with problems caused by friction. These are all things that, in principle, can be taught.

In general, I think that we significantly under-invest in real leadership education. We spend a lot of money on retreats, professional development and nice, feel-good things that purport to teach leadership skills, but very little on the actual hard concepts that underpin leadership and strategy. To reduce friction losses in software (among other things), once we've done what we can to eliminate bad leaders, we should spend money on real strategic education. While I imagine that sending business leaders to War College might actually work quite well, this probably isn't very practical and the military won't like it, so we might need to drop the idea. What we could do, though, is get tech leaders to sit some post-graduate courses. These shouldn't be in the business school: a good list of approved courses might be in history (particularly military history), sociology, political science and statistics. In general, we should normalise the idea that leaders should, in general, be spending about ten hours a week in graduate school, at least for a few years of their lives. This would also have the much-needed effect of reducing the number of dullards that end up in positions of power: having to read some worthwhile books and academic papers is likely to filter out a lot of the people who think they're too important to read or who need business books summarised for them.

Oh, and our leaders should all read Clausewitz. That's very important.

Coda: LLMs and friction

Iris being Iris, I can't exactly write a text like this without touching, at least briefly, on how LLMs influence the friction situation. The picture is complex, but broadly speaking, unfortunately, LLMs increase friction where it should be reduced and reduce it where it should be higher. In the simplest sense of the term, an LLM tool reduces the friction generated in creating an artifact to near zero. You can, for example, get Claude Code to generate a feature or submit a Pull Request to an open-source project with effectively no effort. Similarly, the tools reduce the cost to leadership of asking for something steeply: where a middle-manager might previously have needed to ask someone to mock up a view or write a spec, they can just do it with ChatGPT now.

Unfortunately, as we have by now established pretty well, LLM-generated code is unavoidably buggy. Including LLM-generated code into your codebase, then, unavoidably involves introducing bugs into your codebase. We've already discussed the very steep cost of producing buggy code, and given that LLMs allow you to produce code in volume and very, very fast, this means that what we've mostly generated is the ability to introduce bugs into your code very, very fast. Resolving the bugs properly, however, can't be done via LLM, because the fix will add code (and thus more bugs). You have to resolve the bug manually. And now you see the issue: you will more or less immediately have generated enough bugs to create a level of friction that's going to make real progress impossible. However, to the people for whom friction is reduced, this is invisible, so rather than, as they should do, taking an operational pause, management will continue pushing for more progress to be made. And then we're fucked.

Using LLMs to do friction-reducing tasks is similarly flawed. Certainly, you can make the tool write unit tests. They're often, however, not very good: they're unstable, they don't test for what they need to test for and the machine often simply cheats. Attempts to use the LLM to resolve this problem simply reproduce it at a higher level. What you tend to end up with, then, is a situation where using LLMs to do these things makes it look like you've done maintenance while actually having made the situation worse, compounding the problem by deluding yourself.

Finally, the tools are addictive and give enough of a sense of productivity that people using them struggle to take the kinds of operational pauses for consolidation and preparation that become increasingly essential when using the tools. The temptation of "one more feature" is always there, and rather than reducing their workloads, people using the tools tend to burn themselves out pushing more and more work, trying to get more and more done. This makes it very difficult for teams using these tools to stop and reflect, and can lead to them getting themselves into some truly ugly situations.

In short then, a large part of the issue with LLMs is that they can make things seem too easy: they give you victory disease, in fact. You get a few initial wins, they let you become overconfident and develop a bit of an addiction, and before too long you're up to your neck in shit and friction and can't easily get out. I don't think this is a particularly productive way to work.

Want a strategically capable engineer to help you with your DevOps, infrastructure or data problems? Need a website fixed? I'm currently on the lookout for small contracts: get in touch if I can help you! If you're not in need of practical work but need education, I also have an excellent coaching offering