Paradigm shifts, bricoleers [sic], and other animals

Posted May 6, 2026, updated onMay 6, 2026 by Jon Dron

Ben Werdmuller is a serial innovator, edtech veteran, and deeply insightful commentator on the tech industry whose skills defy easy categorization. I like him a lot. In One size fits none: let communities build for themselves Ben tells us about how to build digital social systems that fit the needs of their communities, and it is well worth reading if you have any interest in social software.

The post starts with description of the reaction of developers when, in the Summer of 2007, at an Elgg-jam at my then-university in Brighton, Ben first introduced the newly refactored Elgg 1.0 framework. In its several pre-version-1 iterations, Elgg was not a development framework but a full-blown web application. It had blogs, wikis, file sharing, bookmarking, groups, and much more, all wrapped up in a robust social network system with smart discretionary access, extensible very easily through a simple-to-use plugin system. It was easy to use, rich in features, highly adaptable, and it might have been the most popular open source social networking system on the planet at that point. It was a bit hacked-together and not exactly an engineering masterpiece, but it worked really well.

What Ben announced that day stripped away virtually all of its existing functionality, leaving only a tiny core that could do almost nothing user-facing on its own apart from simple user management, the display of activities, and some basic admin tasks. I don’t think it was even possible to create a post and I have a feeling there were floppy disks around at the time onto which the whole thing could fit. The idea was that it was up to developers to provide plugins that end-users could configure to create any kind of social system they wanted, with the core providing the API and data structures to support and greatly simplify their development. A few common tools like blogs, wikis, file sharing, and bookmarks were provided in a package of core plugins to help get things started, but all were (and are) optional. It was extremely elegant.

I believe that I was the person Ben refers to who, many years later (at another Elgg-jam, in San Francisco, as it happens), described his “big reveal” as a mind-blowing moment. Almost every hair on my body stood on end. I got it immediately because I had been thinking along very similar lines – there’s a chapter on such things in my first book, published earlier the same year – and had been, up until that point, intending to spend my newly-acquired national teaching fellowship money on building it. Instead I went with Elgg, which provided the framework on which the Landing and a few other sites (including the one at Brighton to which Ben refers) were built, and the money mostly went towards plugin development for it.

In fact, in the form in which it first launched, Elgg 1.0 wasn’t exactly what I wanted. My vision was more distributed and centred around small services, loosely joined, rather than a single monolithic plugin-based server. The roadmap, though, that Ben described that day made exactly that possible, with plans for a robust and extensible range of services and standards for information interchange that, had they gained any traction, would have made a federated social system of almost any kind simple to create and evolve.

They didn’t gain that traction.

I think a big part of the reason might be that, with no backwards compatibility at all with the older version, and no good migration path for those already running Elgg, it lost almost all of the momentum and good will it had previously gained, and others had moved into the space in the interim that could provide an off-the-shelf experience that was at least as good as the replacement, without the need for further development. In particular, WordPress and Buddypress were already on the rise. Ben eventually moved on to do other things, Elgg gained a loyal and slowly growing following and became a foundation, but its focus shifted to being a development platform for building bespoke servers rather than a distributed social system. The web services and neat ODD protocol never took off enough to be usable beyond some very limited use cases. However, the plugin-based architecture and tiny core was still a cool idea and building using small pieces for almost everything seemed to me to be a really good way to build a social system, so that’s what I and my teams did. It turns out to be much less cool when you want to maintain it, though, a fact that I was quite well aware of but failed to grasp in its full magnitude until it was too late.

Red Queen development

As we built the Landing we soon ran into the painful flipsides of plugins, which include the fact that you can’t easily remove them once many people use them, the large number of dependencies they create, and the fact that they have to be maintained, at least every time the core gets updated. It is not helped by the fact that, I think for efficiency, backwards compatibility is still rarely much of a consideration when Elgg gets an upgrade: though they will generally survive (with deprecation notices) for a version or two, many old plugins will simply break if they are not updated, often in subtle, difficult to debug ways. And part of the elegance of the design is also one of its greatest flaws: that, though you can design things in a more robust way, any plugin can fully override almost anything provided by any other simply by including a file of the same name and position in the directory hierarchy. This plays havoc with new versions, and makes plugins far more co-dependent than the very self-contained, well-encapsulated services I had been imagining. To make things worse, it does not scale at all well: Elgg’s object-over-relational data model is very elegant, but it is not very efficient when your site grows large, and every data-storing plugin adds to the problem.

At one point the Landing had 116 plugins (admittedly with a few turned off by default), about a third of which we built, a third of which were distributed with the core, and a third of which were community-developed. As well as our own plugins, we gradually had to take on more and more of the community-plugin development ourselves as original developers abandoned them, or face the wrath of those who needed them. Of the 90 or so that are left today, about half are our/my responsibility. On average, when things were going well and we had the funding for a full-time developer, I reckon most plugins averaged about a person-week of design, development, and testing to upgrade, though the various dependencies and bottlenecks meant that it was rarely less than a month from start to finish before they arrived on the site. Meanwhile, the core was getting updates, sometimes more than once a year. With very little spare cash, especially after losing our full-time developer, there was no way that we could ever hope to keep up with the release cycles of the core and keep the number of plugins we had to maintain. We were stuck in a Red Queen Regime, running harder and harder to stay in the same place. Some call this a technological debt, but it’s just the price of ownership, and we couldn’t pay enough.

It may be a blessing in disguise then, that, some 10 or 11 years ago, the decision over whether to continue development was taken out of our hands by a CIO who refused us any resources to even test let alone to install anything, as a result of a grossly misguided “back to baseline” principle that ravaged many good systems during his tenure, even though we (then) had plenty of money to continue and offered to put it all into his budget. The Landing limped along regardless because it was embedded in many courses, research groups, centres, and so on, so it couldn’t simply be switched off, no off-the-shelf alternative came close to doing anything similar, and we built it to be robust (though never expecting it to still be around, almost unaltered, over a decade later) so it carried on working. With the help of less hostile but never exactly enthusiastic CIOs, we have limped along ever since, very slowly creeping up through the versions on a shoestring budget and odd moments of my own spare time, but we are very far behind the cutting edge.

And then came ChatGPT

LLMs – Claude in particular – can be great at coding, especially for small projects like plugins. I have been vibe coding for a few years now, and it has been incredibly useful in many aspects of my life. However, even the best of them tend to struggle with Elgg plugins. I think it is because there is not enough Elgg code out in the wild, and there have been too many versions and too many approaches to development, so there’s not enough good quality training data. Since the first week of the launch of ChatGPT, I have been trying to get genAIs to help me with Elgg plugin upgrades and bug fixing but, though I have picked up some very helpful ideas in the midst of some very bad attempts at solutions and they have spotted a few bugs for me, not a single line of actual AI-generated code has ever made it onto the Landing. This is going to change.

A few days before Ben wrote his post, on a hunch, after some frustrating attempts at getting Claude, ChatGPT and Gemini to upgrade an existing plugin that was too difficult for me to take on alone, I instead simply asked Claude to make me a new one, with specs I had extracted from the original (using ChatGPT and tweaking the output), but giving it no access to any of the original’s source code or program structure.

Apart from a couple of minor syntax problems that took hardly a minute to fix, it worked first time. It was considerably more polished than the original and, indeed, than almost all the plugins we had written ourselves or commissioned at costs of up to $10,000. It has no deprecated code at all – something that is not even true of plugins in the core for our current Elgg version – and it has all sorts of useful little configuration options that Claude extrapolated from the specs and that I would have been too lazy to bother with, but that make it way more adaptable than its predecessor. It even has a complete set of language files for both French and English – extremely rare in human-made plugins – and it would be trivial to ask it for other languages if we needed them.

I think this works because of the different way Claude approaches the problem compared with how it handles an existing plugin. When trying to fix a broken or obsolete plugin, the plugin itself plays a large influencing role, then Claude pulls on a ragtag bunch of existing plugins as examples, but the paucity and mixed quality of the training data means they are less than wonderful role models. Almost all of its prior attempts included code from a future version of Elgg, or an older one, or one that has never existed, and it quite often did things in a very non-Elgg way. In contrast, when building a new plugin from scratch, its strategy appears to be to read the entire core codebase and all of the official documentation, then to build the plugin to fit, with little or no reference to any existing plugins beyond those that come with the core distribution. When things go wrong, it goes straight to the definitive source of a function in the core, not to a muddle of existing solutions, and its context window (at least in the paid versions) is now large enough for it to contain much if not all of the whole thing, or at least for retrieval-augmented generation to deal with the correct pieces. The small core that was so useful to human developers turns out to be ideal for LLMs.

The key lesson to be drawn from this is that, if the architecture is sufficiently and cleanly modular (as Elgg’s is), then it may now be more effective to recreate components from scratch than to maintain the ones you have already written. If it continues to pan out as it has so far done, I’d say this is a potential game changer. As well as making development extremely agile, it even improves the security of the system because, though any one plugin may yet have flaws despite the apparently high quality of coding, it is not going to stick around for long enough for them to be exploited, and anyone who follows this approach is not going to have the same plugins as anyone else so it’s not worth anyone’s while to develop a specific hack for it. The next upgrade is almost ready so I am only going to use this approach sparingly for now but, when the time comes for the next major upgrade, this is how I intend to do most of it. I won’t let it near core plugins or still-maintained community plugins but, for all those we inherited or created, ChatGPT or Gemini will provide me with the spec. I’ll then run each spec through Claude, getting it to produce the complete plugin including unit tests. It will still take time, and I don’t expect it to work as well all the time, but much of that time will be spent by Claude, not me. At one fell swoop, this almost eliminates the technological debt.

This principle is not necessarily limited to elegantly engineered systems like Elgg. A night or two ago I went through my regular quandary about how to schedule ad hoc meetings for one of my courses. In the past I’ve used wikis, discussion forums, various free (but not quite right) poll-based schedulers like Doodle, and more. None were great, and the ones that worked best raised potential privacy concerns that I was not willing to grapple with. The length of time it takes to get a plugin to production made a Landing plugin a non-starter. Then it struck me that my own personal website would be more private and controllable than any of those, and hosted on Canadian soil (unlike any of the rest) so I went in search of a plugin. WordPress is very inelegant, sprawling software, and plugin development is positively painful compared with Elgg, but the vast numbers of WP developers mean that, among the many tens of thousands of plugins, no matter what the task, at least one will do the job I want, or close enough for me to tweak so that it does. At least that had always been the case until now. To my great surprise, this time, there were none. Something like the functionality does exist in a few polling and scheduling plugins, but with very complex configurations and a lot of unwanted fluff around them, not to mention the need to get premium non-open versions to do what I want. I just wanted a small subset of Doodle’s functionality, that would not store any private data, nor cater for needs I don’t have. So I asked Claude to make it, knowing that it would already be quite skilled in WP development because of the vast number of examples to learn from. It took about 4 attempts to get exactly what I wanted. Overall the whole process took about an hour, including writing the spec, Claude’s thinking time, and the time it took to upload, configure and test it. It works really nicely. I actually spent more time earlier looking for the right software than it took to make it from scratch. I have some experience writing specs, but even a beginner could do this with a bit of help from the AI.

Ochlotecture management

I might ask an LLM to build the Spec Manager – essentially a means of managing the application architecture, not unlike a traditional source code management system – that Ben writes about, to simplify and automate some of the workflow, not that it is particularly onerous. However, the time it would save would allow me more time to work on another idea sparked by Ben’s post.

Doing what we already do, better, cheaper, and faster, is quite cool, but the most significant benefits of any new technology come from being able to do things that were previously impossible: it is the adjacent possibles they create and we exploit that drive progress. As Ben says, some of the biggest things that matter in a social system are the what, why, and for whom, and that’s very true, but there’s more. I’ve written previously of the ochlotecture of a social system, by which I mean all the human as well as non-human elements of it that make it do what it does, including the whats, whys, and for-whoms: the written and unwritten rules, the structural topography (networks, group hierarchies, set clusters, etc) , the norms around posting, the pace, the interests of the community, the cross-cutting networks, the ethical principles, the aesthetic preferences, the physical spaces they inhabit, and so on, that combine to give shape to a community. In essence it is much like a user model, only for crowds.

It strikes me that it should be possible to build an Ochlotecture Manager in much the same way as we might build the Spec Manager. Exactly how this would work is to be determined but I envisage it including an assortment of personas and scenarios as well as rules, demographics, contextual information, and network/group/set structures. The idea is to try to get away from the traditional functional definitions and instead describe relationships, policies, norms, and so on in a way that, with a bit of work, LLMs will be able to interpret and thus to better fit the site to its community. This would be particularly useful in a learning context, where a lot of software is built or chosen to perform a function, with far too little regard to how it achieves it. It almost never fits exactly what a teacher would like to do, because it ain’t what you do, it’s the way that you do it, that’s what gets results, and you can’t do the same thing the same way for everyone and expect it to be a perfect fit for all of them. The app will most like generate some YAML or JSON and instructions about how to deal with it. But this doesn’t end with the design.

A much under-utilized adjacent possible of LLMs lies in their potential to connect people and sustain communities. From summarizing conversations or connecting individuals with complementary needs, to nudging conversations or analyzing sentiment, there are many ways LLMs can catalyze interaction, not as a participant but an enabler. Having a clearly specified ochlotecture would make this much easier to achieve. It might not be a bad ochlotectural analyst, too, suggesting and implementing improvements in the design based on not user models but crowd models.

Having done that, it opens up the potential to make this a truly adaptive system, not just changing data and parameters but also the underlying code itself as a community evolves. Imagine, to give a simple example, a discussion forum in which the system observes people regularly responding with “this is great” or similar replies. The system could identify a need for some kind of rating system and, rather than simply implementing a “like” button (which is far from ideal in all situations) it could consult its ochlotectural model to identify what would work best. This could range from a simple change of wording – “recommend”, perhaps, or “rate”, depending on the community – to a multi-dimensional ranking system, that might work better if more precise feedback is needed (e.g. in peer review). More complex changes are possible: it might build a system to (say) manage events, or create photo albums, or implement breakout spaces, or shift between threaded and non-threaded discussions. Perhaps it could shuffle menus to better fit community needs, or fix accessibility issues, or identify more relevant posts. I’d be extremely nervous of taking humans out of that loop – that way disaster lies – but perhaps the humans would not need to be developers as long as a developer had crafted the spec and the ochlotecture carefully enough in the first place. Community members themselves could suggest things, the LLM could present them to the group (perhaps creating a poll system for voting, or some other dispute-settling mechanism to do so), and it could use the ochlotectural and architectural models to help guide the actual development. It might even do a bit of proactive A/B testing, making an evolutionary (survival of the fittest) approach possible. Ultimately, it might even evolve how it evolves, developing its own strategies for engaging the community and responding to changing needs. It would be no more annoying that it constantly changes than it is for existing cloud services, with the added benefit that, if the community doesn’t like it, they can fix it.

In my perfect world all of this would rely on a local, open LLM but, though some are now extremely good for coding assistance, none currently have the large context windows and sophisticated tuning of the bigger commercial models. This will probably change. A hybrid approach might work in the interim, where the local model deals with everything apart from the coding itself, and the commercial model does the rest, but I’ve not thought through the economics of that.

Bricoleering: a new paradigm?

We are at the bottom of a learning curve with genAI right now. Most of us are simply replacing things we already do with LLMs, and that is highly problematic for reasons I and many others have written about extensively (see at least half my posts at https://jondron.ca/ai). In a world with machines that can creatively replicate almost any human cognitive skill, often at an expert level, there are high risks that our descendants are going to lose at least a portion of their own capacity to do so unaided. That’s not necessarily a bad thing, in itself. Few of us can still recite every word of a novel from memory, or create a bow and arrow, or perform complex mental arithmetic, because we don’t need to. Coarse grained cognition – thinking in bigger chunks, using the products of our own and other humans’ thought – is what has let us build pyramids, spaceships, welfare systems and virtually every invention ever, including this sentence. It’s our collective, extended cognition that makes it possible to constantly create more. That’s more of a problem when creativity itself is at stake, however, because we risk delegating too much of it to the machine, and allowing our own capabilities to atrophy. Already, I quite often tell the machine what I’m trying to do then ask it for a list of ideas and select one, rather than trying to think of one myself: that’s how the picture at the top of this post was conceived. At scale, this is not a great idea. If the world is going to be a better and not a worse place, we need to learn to be creative with the creative outputs of the cognitive Santa Claus machines, not simply to specify and use them. I think that the idea I suggest above is one of the ways this can happen. A plugin-based (or other component-oriented) approach enables us to do bricolage with the pieces, assembling, disassembling, and reassembling them in new and creative ways that neither we nor genAIs could do alone. It is not Levi Strauss’s bricolage of the “savage mind”, however, nor is it engineering. I think it is a new paradigm in which we do not simply assemble pieces we happen to have lying around but actively help to shape them so that they will fit. Our roles are closer to those of architects like Frank Gehry, who famously couldn’t use the machines that were essential to creating his iconic machine-made designs, instead relying on hand-drawn sketches to communicate his idea to those who could. I don’t know what to call this: “bricoleering” perhaps, or “adaptafacture”?

The collective ochlotecture of large language models: slides from my talk at CI.edu, 2024

Posted December 10, 2024 by Jon Dron

Here are my slides from the 1st International Symposium on Educating for Collective Intelligence, last week, here is my paper on which it was based, and here is the video of the talk itself:

You can find this and videos of the rest of the stunning line-up of speakers at https://www.youtube.com/playlist?list=PLcS9QDvS_uS6kGxefLFr3kFToVIvIpisn It was an incredibly engaging and energizing event: the chat alone was a masterclass in collective intelligence that was difficult to follow at times but that was filled with rich insights and enlightening debates. The symposium site, that has all this and more, is at https://cic.uts.edu.au/events/collective-intelligence-edu-2024/

With just 10 minutes to make the case and 10 minutes for discussion, none of us were able to go into much depth in our talks. In mine I introduced the term “ochlotecture”, from the Classical Greek ὄχλος (ochlos), meaning “multitude” and τέκτων (tektōn) meaning “builder” to describe the structures and processes that define the stuff that gives shape and form to collections of people and their interactions. I think we need such a term because there are virtually infinite ways that such things can be configured, and the configuration makes all the difference. We blithely talk of things like groups, teams, clubs, companies, squads, and, of course, collectives, assuming that others will share an understanding of what we mean when, of course, they don’t. There were at least half a dozen quite distinct uses of the term “collective intelligence” in this symposium alone. I’m still working on a big paper on this subject that goes into some depth on the various dimensions of interest as they pertain to a wide range of social organizations but, for this talk, I was only concerned with the ochlotecture of collectives (a term I much prefer to “collective intelligence” because intelligence is such a slippery word, and collective stupidity is at least as common). From an ochlotectural perspective, these consist of a means of collecting crowd-generated information, processing it, and presenting the processed results back to the crowd. Human collective ochlotectures often contain other elements – group norms, structural hierarchies, schedules, digital media, etc – but I think those are the defining features. If I am right then large language models (LLMs) are collectives, too, because that is exactly what they do. Unlike most other collectives, though (a collectively driven search engine like Google Search being one of a few partial exceptions) the processing is unique to each run of the cycle, generated via a prompt or similar input. This is what makes them so powerful, and it is what makes their mimicry of human soft technique so compelling.

I did eventually get around to the theme of the conference. I spent a while discussing why LLMs are troubling – the fact that we learn values, attitudes, ways of being, etc from interacting with them; the risks to our collective intelligence caused by them being part of the crowd, not just aggregators and processors of its outputs; and the potential loss of the soft, creative skills they can replace – and ended with what that implies for how we should act as educators: essentially, to focus on the tacit curriculum that has, till now, always come from free; to focus on community because learning to be human from and with other humans is what it is all about; and to decouple credentials so as to reduce the focus on measurable outcomes that AIs can both teach and achieve better than an average human. I also suggested a couple of principles for dealing with generative AIs: to treat them as partners rather than tools, and to use them to support and nurture human connections, as ochlotects as much as parts of the ochlotecture.

I had a point to make in a short time, so the way I presented it was a bit of a caricature of my more considered views on the matter. If you want a more balanced view, and to get a bit more of the theoretical backdrop to all this, Tim Fawns’s talk (that follows mine and that will probably play automatically after it if you play the video above) says it all, with far greater erudition and lucidity, and adds a few very valuable layers of its own. Though he uses different words and explains it far better than I, his notion of entanglement closely echoes my own ideas about the nature of technology and the roles it plays in our cognition. I like the word “intertwingled” more than “entangled” because of its more positive associations and the sense of emergent order it conveys, but we mean substantially the same thing: in fact, the example he gave of a car is one that I have frequently used myself, in exactly the same way.

Announcing the First International Symposium on Educating for Collective Intelligence (and some thoughts on collective intelligence)

Posted November 17, 2024 by Jon Dron

First International Symposium on Educating for Collective Intelligence | UTS:CIC

Free-to-register International online symposium, December 5th, 2024, 12-3pm PST

Start time:

Change timezone:

This is going to be an important symposium, I think.

I will be taking 3 very precious hours out of my wedding anniversary to attend, in fairness unintentionally: I did not do the timezone conversion when I submitted my paper so I thought it was the next day. However, I have not cancelled despite the potentially dire consequences, partly because the line-up of speakers is wonderful, partly because we all use the words “collective intelligence” (CI) but we come from diverse disciplinary areas and we mean sometimes very different things by them (so there will be some potentially inspiring conversations) and partly for a bigger reason that I will get to at the end of this post. You can read abstracts and most of the position papers on the symposium website,

In my own position paper I have invented the term ochlotecture (from the Classical Greek ὄχλος (ochlos), meaning something like “multitude” and τέκτων (tektōn) meaning “builder”) to describe the structures and processes of a collection of people, whether it be a small seminar group, a network of researchers, or a set of adherents to a world religion. An ochlotecture includes elements like names, physical/virtual spaces, structural hierarchies, rules, norms, mythologies, vocabularies, and purposes, as well as emergent phenomena occurring through individual and subgroup interactions, most notably the recursive cycle of information capture, processing, and (re)presentation that I think characterizes any CI. Through this lens, I can see both what is common and what distinguishes the different kinds of CI described in these position papers a bit more clearly. In fact, my own use of the term has changed a few times over the years so it helps me make sense of my own thoughts on the matter too.

Where I’ve come from that leads me here

I have been researching CI and education for a long time. Initially, I used the term very literally to describe something very distinct from individual intelligence, and largely independent of it. My PhD, started in 1997, was inspired by the observation that (even then) there were at least tens of thousands of very good resources (people, discussions, tutorials, references, videos, courseware etc) openly available on the Web to support learners in most subject areas, that could meet almost any conceivable learning need. The problem was and remains how to find the right ones. These were pre-Google times but even the good-Google of olden days (a classic application of collective intelligence as I was using the term) only showed the most implicitly popular, not those that would best meet a particular learner’s needs. As a novice teacher, I also observed that, in a typical classroom, the students’ combined knowledge and ability to seek more of it far exceeded my own. I therefore hit upon the idea of using a nature-inspired evolutionary approach to collectively discover and recommend resources, that led me very quickly into the realm of evolutionary theory and thence to the dynamics of self-organizing systems, complex adaptive systems, stigmergy, flocking, city planning, markets, and collective intelligence.

And so I became an ochlotect. I built a series of self-organizing social software systems that used stuff like social navigation (stigmergy), evolutionary, and flocking algorithms to create environments that both shaped and were shaped by the crowd. Acknowledging that “intelligence” is a problematic word, I simply called these collectives, a name inspired by Star Trek TNG’s Borg (the pre-Borg-Queen Borg, before the writers got bored or lazy). The intelligence of a “pure” collective as I conceived it back then was largely to be found in the algorithm, not the individual agents. Human stock markets are no smarter than termite mounds by this way of thinking (and they are not). I was trying to amplify the intelligence of crowds while avoiding the stupidity of mobs by creating interfaces and algorithms that made value to learners a survival characteristic. I was building systems that played some of the roles of a teacher but that were powered by collectives consisting of learners. Some years later, Mark Zuckerberg hit on the idea of doing the exact opposite, with considerably greater success, making a virtue out of systems that amplified collective stupidity, but the general principles behind both EdgeRank and my algorithms were similar.

When I say that I “built” systems, though, I mean that I built the software part. I came to increasingly realize that the largest part of all of them was always the human part: what the individuals did, and the surrounding context in which they did it, including the norms, the processes, the rules, the structures, the hierarchies, and everything else that formed the ochlotecture, was intrinsic to their success or failure. Some of those human-enacted parts were as algorithmic as the software environments I provided and were no smarter than those used by termites (e.g. “click on the results from the top of the list or in bigger fonts”), but many others were designed, and played critical roles. This slightly more complex concept of CI played a major supporting role in my first book providing a grounded basis for the design of social software systems that could support maximal learner control. In it I wound up offering a set of 10 design principles that addressed human, organizational, pedagogical and tech factors as well as emergent collective characteristics that were prerequisites if social software systems were to evolve to become educationally useful.

Collectives also formed a cornerstone of my work with Terry Anderson over the next decade or so, and our use of the term evolved further. In our first few papers, starting in 2007, we conflated the dynamic process with the individual agents who made it happen: for us back then, a collective was the people and processes (a sort of cross between my original definition and a social configuration the Soviets were once fond of) and so we treated a collective as somewhat akin to a group or a network. Before too long we realized that was dumb and separated these elements out, categorizing three primary social forms (the set, the net, and the group) that could blend, and from which collectives could emerge and interact, as a different kind of ochlotectural entity altogether. This led us to a formal abstract definition of collectives that continues to get the odd citation to this day. We wrote a book about social media and learning in which this abstract definition of collectives figured largely, and designed The Landing to take advantage of it (not well – it was a learning experience). It appears in my position paper, too.

Collectives have come back with a vengeance but wearing different clothes in my work of the last decade, including my most recent book. I am a little less inclined to use the word “collective” now because I have come to understand all intelligence as collective, almost all of it mediated and often enacted through technologies. Technologies are the assemblies we construct from stuff to do stuff, and the stuff that they do then forms some of the stuff from which we construct more stuff to do stuff. A single PC alone, for instance, might contain hundreds of billions of instances of technologies in its assembly. A shelf of books might contain almost as many, not just in words and letters but in the concepts, theories, and models they make. As for the processes of making them, editing them, manufacturing the paper and the ink, printing them, distributing them, reading them, and so on… it’s a massive, constantly evolving, ever-adapting, partly biological system, not far off from natural ecosystems in its complexity, and equally diverse. Every use of a technology is also a technology, from words in your head to flying a space ship, and it becomes part of the stuff that can be organized by yourself or others. Through technique (technologies enacted intracranially), technologies are parts of us and we are parts of them, and that is what makes us smart. Collective behaviour in humans can occur without technologies but what makes it collective intelligence is a technological connectome that grows, adapts, evolves, replicates, and connects every one of us to every other one of us: most of what we think is the direct result of assembling what we and others, stretching back in time and outward in space, have created. The technological connectome continuously evolves as we connect and orchestrate the vast web of technologies in which we participate, creating assemblies that have never occurred the same way twice, maybe thousands of times every day: have you ever even brushed your teeth or eaten a mouthful of cereal exactly the same way twice, in your whole life? Every single one of us is doing this, and quite a few of those technologies magnify the effects, from words to drawing to numbers to writing to wheels to screws to ships to postal services to pedagogical methods to printing to newspapers to libraries to broadcast networks to the Internet to the World Wide Web to generative AI. It is not just how we are able to be individually smart: it is an indivisible part of that smartness. Or stupidity. Whatever. The jury is out. Global warming, widening inequality, war, epidemics of obesity, lies, religious bigotry, famine and many other dire phenomena are a direct result of this collective “intelligence”, as much as Vancouver, the Mona Lisa, and space telescopes. Let’s just stick with “collective”.

The obligatory LLM connection and the big reason I’m attending the symposium

My position paper for this symposium wanders a bit circuitously towards a discussion of the collective nature of large language models (LLMs) and their consequent global impact on our education systems. LLMs are collectives in their own right, with algorithms that are not only orders of magnitude more complex than any of their predecessors, but that are unique to every instantiation of them, operating from and on vast datasets, presenting results to users who also feed those datasets. This is what makes them capable of very convincingly simulating both the hard (inflexible, correct) and the soft (flexible, creative) technique of humans, which is both their super-power and the cause of the biggest threat they pose. The danger is that a) they replace the need to learn the soft technique ourselves (not necessarily a disaster if we use them creatively in further assemblies) and, more worryingly, b) that we learn ways of being human from collectives that, though made of human stuff, are not human. They will in turn become parts of all the rest of the collectives in which we participate. This can and will change us. It is happening now, frighteningly fast, even faster and at a greater scale than similar changes that the Zuckerbergian style of social media have also brought about.

As educators, we should pay attention to this. Unfortunately, with their emphasis on explicit measurable outcomes, combined with the extrinsic lure of credentials, the ochlotecture of our chronically underfunded educational systems is not geared towards compensating for these tendencies. In fact, exactly the reverse. LLMs can already both teach and meet those explicit outcomes far more effectively than most humans, at a very compelling price so, more and more, they will. Both students and teachers are replaceable components in such a system. The saving grace and/or problem is that, though they matter, and they are how we measure educational success, those explicit outcomes are not in fact the most important ends of education, albeit that they are means to those ends.

The things that matter more are the human ways of thinking, of learning, and of seeing, that we learn while achieving such outcomes; the attitudes, values, connections, and relationships; our identities and the ways we learn to exist in our societies and cultures. It’s not just about doing and knowing: it’s about being, it’s about love, fear, wonder, and hunger. We don’t have to (and can’t) measure those because they all come for free when humans and the stuff they create are the means through which explicit outcomes are achieved. It’s an unavoidable tacit curriculum that underpins every kind of intentional and most unintentional learning we undertake, for better or (too often) for worse. It’s the (largely) non-technological consequence of the technologies in which we participate, and how we participate in them. Technologies don’t make us less human, on the whole: they are exactly what make us human.

We will learn such things from generative AIs, too, thanks to the soft technique they mimic so well, but what we will learn to be as a result will not be quite human. Worse, the outputs of the machines will begin to dominate their own inputs, and the rest will come from humans who have been changed by their interactions with them, like photocopies of photocopies, constantly and recursively degrading. In my position paper I argue for the need to therefore cherish the human parts of these new collectives in our education systems far more than we have before, and I suggest some ways of doing that. It matters not just to avoid model collapse in LLMs, but to prevent model collapse in the collective intelligence of the whole human race. I think that is quite important, and that’s the real reason I will spend some of my wedding anniversary talking with some very intelligent and influential people about it.