Circumstantial Complexity, LLMs and Large Scale Architecture

On software architecture and the paradox of machine-assisted programming.

February 2026

Sic transit gloria mundi

Late 1995, or is it early 1996? Scrawny legs straining against the wind, heart beating with exertion and excitement as I pedal my bike across town and pass the truly affluent neighbourhoods. The harsh winter sea is roaring to my left and the enormous villas overlooking it tower to my right, calm and dignified in the dusk.

Fresh, empty 3.5" floppy disks in my backpack, fresh batteries in my Walkman FX16. Cheap headphones are blasting Chemical Brothers' Leave Home at maximum volume as I cross the tracks of a derelict railway, once connecting Limhamn and its now dwindling fishing industry and recently closed limestone quarry with the city of Malmö proper. I keep going, past Kockum's no longer bustling shipyard, past the decommissioned SAAB factory, past the still busy grain pier. A perfect image of the 1990s: Decades of accumulated decline, of circumstantial industrial death, yet an inevitable need for sustenance.

Then I see it, like I have almost every night for the past few months. A beacon of promise, of future economic opportunities yet unexplored: Kajplats 305, Berth 305, the youth center with a dedicated 256 kbit/s Internet connection.

The world wide web. There seems to be some money in that. But presently, my mind is far from the budding dotcom boom and untapped business opportunities. It's time to download some new Amiga demos, check in on IRC, and update my homepage.

***

It's a bit over three decades since I wrote my first ever lines of HTML on one of the 486 PCs at Kajplats 305. Since then, the kind of web coding I really love has disappeared from the professional world. Not because of LLM-powered coding agents, but because of increasing complexity.

Even though I'm a senior full stack web developer, things are not as they used to be. The days when a single developer installed Linux, compiled and configured Apache, designed a MySQL database and wrote all of the front- and backend code in an unholy mix of PHP, SQL, HTML and (maybe) a tiny bit of JavaScript, are long gone. How fitting, then, that Kajplats 305, like the heavy industries and dockside warehouses preceding it, is now being demolished. It will likely be replaced by modern offices, where the complex software of tomorrow can be designed.

Because complexity is - up to a point - both beneficial and profitable. On the web, most systems and processes are now so complex and involved that even full stack, while indeed dealing with both sides of an HTTP request, is a specialized, compartmentalized role. Builds and deployment? Please, we've got experts dealing with that. I've got colleagues who, in their professional role, never write anything but SQL or React. Expectations and demands on software increase steadily. Few can keep the entire development process, or the entire code base of a modern enterprise web app, in their heads. As complexity increases, so does the need for specialization.

***

A recent blog post by Paul W. Homer, Systems Thinking, divides software architecture into two overarching philosophies. They're called Evolution and Engineering, and the article argues in favour of the latter. Evolution - letting a system grow organically and fixing stuff as you go along - is described as leading to a haphazard patchwork of poorly integrated systems, unnecessary complexity, and terrible fragility. Engineering, on the other hand, means solving the entire problem upfront, in a large unified system.

This is where I think the article contradicts itself. The evolutionary example it mentions involves an ecosystem that's been running and growing for a period of fifty years. Show me the most intelligent and talented team of hardcore systems thinkers ever to exist, and I will show you a team that will never, ever be able to anticipate all the real-world twists and turns that can affect a software system across the span of five years, let alone the span of five decades.

Web development has become what it is today not because someone planned it that way 30-odd years ago, but because of a myriad decisions, big and small, intended to solve technical issues encountered along the way. Since the publication of Fred Brooks' 1986 essay "No Silver Bullet", this is usually called accidental complexity - a technical problem that must be solved before an essential, real-world problem can be solved. For example: A solution to a specific problem involves a certain amount of irreducible, essential complexity, perhaps the act of adding numbers together. This might lead to accidental complexity, such as the need for arbitrary-precision arithmetic.

Hence, a software system that deals with a complex process must, at some level, be at least as complex as the process itself. There's not much use for an airline ticket system that can't deal with bookings and flight schedules. The implementation details - such as inventing COBOL - may be of an accidental nature, but the real world requirements are essential. Regardless of the design process, everything can be perfectly fine in the beginning: nary a flight is underbooked, cash flow is solid, and the pilots and stewardesses are marrying each other and having kids like never before.

Then, all of a sudden, some scumbag from Texas comes along and invents a loyalty system awarding "points" based on individual customers' accumulated flight miles. That rotten bastard! Does he even know how the system's ISAM file spec looks?

This is what I'd like to call circumstantial complexity. Even if it's both feared and loathed among programmers, it's something we should be grateful for, because it's keeping us in business. Without constantly changing circumstances, precious little code - except for improvements of the accidental - would need to be written once a problem has been solved. Nevertheless, this gradual addition of essential complexity is further exacerbated by the fleeting nature of its accidental counterpart.

***

Software development isn't perfect, and there's plenty of poor quality software. The older the system, the more warts it'll have. Some of them could probably have been avoided through better upfront planning, but many are circumstantial, essential and impossible to foresee. I suppose I should know, because I'm what Homer calls a "battle-scarred twenty-year+ veteran".

For well over twenty years, I've been part of a team shepherding an enterprise product from obscurity to having some of Sweden's largest industries, real estate owners, municipalities and government agencies among our users. I've had the fortune of working with some exceptionally bright and competent people, the kind that can take one look at a hugely complex system and pinpoint weaknesses, think up architectures and model massive processes in their heads. And yet, none of us managed to anticipate the many circumstantial externalities, dependencies and events we've had to tackle.

On the accidental side, none of us foresaw Microsoft's fall from browser hegemony, because Google was just a search engine when the product was conceived. We didn't imagine cloud computing in its current form, and we didn't anticipate the present prevalence of virtualization, because we started coding when even most servers had single core CPU:s. While working, we've seen the rise and decline of XML, ExtJS, Backbone and PHP, and the adoption of JSON, UTF-8, Python, WSGI, Markdown, React, YAML, and continuous deployment. We've experienced unlikely twists and turns, like Orcale's acquisition of Sun, and Microsoft's reluctant adoption of Linux. We certainly couldn't imagine that security auditors would, at some point, start complaining about the use of C++ because it's not memory safe.

I dare say that nobody, twenty-odd years ago, could foresee the present details involved in writing asynchronous code to stream a response from a neural network, running on a graphics card (of all things) in some faraway server farm, through a web browser, to the office of a Swedish municipal administrator for the purpose of summarizing school budget forecasts.

On the essential side, we've had to deal with several cases of new legislation, shifts in best practices, market trends, and big and small customer demands. A particular such shift prompted the development and integration of a large and complex new module that of course had to interconnect with many other parts of the product. Others, such as the advent of GDPR, prompted smaller changes across the entire breadth of the system.

The messy dependencies and seemingly haphazard architecture of software systems is, to a large extent, circumstantial and highly unpredictable. Such circumstances are likely to escalate: For the first time in a very long time, we're seeing massive geopolitical shifts causing reverberations even in the boring fundaments of town hall realpolitik. I'm betting that right now, some developer at a Swedish defense contractor is battling with some new-fangled requirement due to our recent accession into NATO. Two hundred years of neutrality, permeating systems thinking across all levels of society, was changed overnight due to a series of unfortunate circumstances.

In short: During the extended planning phase of a killer architecture, the very circumstances upon which it depends are likely to change.

***

One such circumstance, as I touched on above, are large language models. Despite my bearish position on the AI bubble as a whole, it seems likely that LLM-assisted coding is here to stay, in one form or another. The exact shape, and how it will crystallize, is still up for debate. To me, it seems that for every hyped-up exclamation, there are a dozen valid questions in need of answers. In another recent blog post, Nolan Lawson ponders how we programmers mourn our craft. I think the text touches a nerve, but for my part, I've been lamenting our lost craft for much longer. Like an old 8-bit game developer, I yearn for less complex times, when it was humanly feasible to keep an entire system in the head at once, and maintain a skillset that covered the entire construction process.

I see a danger in the expectation - and possible reality - that LLMs can help with that grief. Initially, I'm sure vibing is very tempting. The problem is that as a "battle-scarred 20+ year veteran", I'm worried about things like maintainability, adaptability and longevity.

There are paradoxes here that the proponents of coding agents rarely address. Lawson, for example, suggests that junior developers will "code circles" around their seniors, if the latter don't adopt and adapt to the LLM craze. That may well be true, at least in some cases, but it leaves out the crucial detail of how juniors eventually become seniors.

Circumstance has a lot to do with it. We learn by making our own mistakes, not by letting someone else do them for us. We understand how systems work by examining them in great detail for extended amounts of time, not by having someone else build them for us. Complexity requires upkeep, upkeep requires skill, skill comes from grind, and grind takes time.

A possible allure with LLMs is that specialists suddenly feel like generalists again. We're tricked into believing we're once more in control of the entire process, just like in the roaring 1990s, when we FTP:ed our PHP to the web hotel and called it launch day. LLMs solve accidental complexity, a means to an essential end. But if we're not in control of that accidental complexity - if someone, somewhere doesn't fully understand their designated piece of it - we're very poorly equipped if suddenly required to deal with changing circumstances.

As a battle-scarred veteran, I don't really care how software is written, as long as it's maintainable. I know for a fact that certain bugs might not surface for over a decade, and when they do, it's circumstantial. I know for a fact that code will almost always live much longer than anyone originally intended, and that systems become hairy monsters because nobody can fully plan for the whims of the world. As developers, we may use libraries, frameworks and other abstractions to aid us. We may not know how they work - but someone, somewhere does: Complexity leads to specialization.

This complexity isn't going away. It's what LLMs are trained on, and the code they generate depend on it. If humans are bad at anticipating circumstances, LLMs are even worse. They don't do systems thinking, they don't have institutional memory, and even if they can see how the pieces of a 50 year old software ecosystem interlink, they have no understanding of why. This, according to (some) LLM proponents, is why humans will still be needed in the loop, and why there will still be a demand for skilled developers to take on architectural roles.

The paradox here is one of knowledge. I wonder where all those LLM-whispering specialists and architects will come from once we're all automaton-assisted generalists, when our battle scars come from prompting skirmishes, and all the epiphanous mistakes are made by machines who won't learn from them unless somehow incorporated into their ever-growing training data.

***

Another interesting paradox is that of invention. LLMs don't innovate - they replicate. We're at our current level of abstraction because a lot of people have, for a long time, thought hard about certain technical issues and how to solve them. I truly wonder what will happen to our many layers of accidental complexity when (or if) our reliance on coding agents increase.

Will software stagnate at its current level? It's a valid question if the proponents of vibe coding are correct in their predictions: Will we keep on running flat design sites written in React Hooks, in Chrome 145 on Windows 11, the only innovation in the accidental realm being miniscule tweaks to our current coding and design paradigms coaxed out of LLMs through sheer, dumb luck?

There's an adoption paradox here, too. If someone does provide a solution to some accidental complexity (perhaps with the aid of an LLM), will people understand the greatness of it if their LLM can't code for it? And what if we can suddenly, for some reason, remove a significant portion of accumulated accidental complexity? Will we care enough to adopt it and, if so, how will we train an LLM on it if there isn't a couple of hundred man-years of code it can feed on? How will possible mistakes be found, corrected and distributed if the LLM can't consume the accumulated knowledge of thousands of humans before it? Will operators of the foundational models care, when they finally want to profit off the gigawatts of power and billions of dollars they've spent on GPUs?

Competition and security is another interesting aspect. Will some reactionary megacorp with a secret lab full of unassisted coders suddenly launch a piece of software that's faster and better than its competitors, because it's built on new abstractions - the kind no LLM has been trained on? There's a possible gap to be exploited here, and I'm sure someone is already exploring it.

Will some malicious cyber terrorist somewhere, meticulously sifting through code the old-fashioned way, find a security hole that's too hard to fix without actually sitting down and truly trying to understand the accidental complexity hidden away in millions of lines of LLM-generated code? I'm sure this, too, is being discussed in some smoke-filled room somewhere in a Highly Suspicious Nation.

In any case, we now know what happens in countries like Sweden, where derelict industries are turned into youth centers and then demolished to make way for the digital economy. The competence in manufacturing diminishes, infrastructure is left to decay until fit for removal, and the knowledge surrounding these complex systems - not just constructing the factory itself and the roads leading to it, but the many systemic kinks that must be managed - dwindles until it all but disappears. Reindustrialization is hard not just because it's expensive, but also because the prerequisite skills need upkeep, especially at the current level of abstraction and automation. Expertise follows practice - but what happens if we stop practice altogether?

To quote Brooks' essay: "There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity." It seems to me that despite our heartfelt desire, not even LLMs may be a silver bullet. If they live up to their promises, they could push us over the point of complexity where upkeep is no longer possible, and we lose sight of our abstractions.

Then again, nobody knows what the future holds.

I guess it all comes down to circumstance.