DEV Community: Alan Bonnici

The AI Revolution — History Repeating Itself — On Education

Alan Bonnici — Thu, 03 Sep 2026 07:00:00 +0000

A personal view of the British system — and why education keeps repeating the same response to every new tool

I am tackling education from a personal perspective; there is no AI Committee behind this one. I came up through the British world of O Levels and A Levels in the 1980s — secondary school, sixth form and then university. I was a STEM student, taking mathematics (pure and applied), physics, chemistry, biology and computer studies, and where the narrative allows I have drawn on my own experience.

I am also focusing on secondary education and above. Primary education should be about building the foundations on which all later learning rests, and I will leave that stage to one side.

An old worry with a new name

The current anxiety in education is not new. Each time a new cognitive tool appears — one that promises to do some of the mental work we previously did unaided — education reacts in much the same way. It first treats the tool as a threat, and then, often years later, adapts by redrawing the line between what must be learned without help and what may safely be delegated.

The move from "strictly forbidden" to "expected practice" is rarely a planned transition. More often it is a series of uncoordinated steps that leave teachers on the ground to work out — or quietly ignore — how to cope. Little thought tends to be given to those struggling with the change: rather than supporting them or bringing in people trained for it, the system imposes the shift and hopes for the best.

The pattern is far older than the computer. In Plato's Phaedrus, Socrates worries that writing itself will erode memory and hand students "the appearance of wisdom" in place of the real thing — pupils who can recite but cannot think (Plato, Phaedrus, via Wabash College). He had a point. Yet no one would give up writing to keep their memory sharp. That is the shape of the whole story: a tool arrives, something genuine is lost, a great deal more is gained, and education eventually rewrites its own rules around it. AI is only the latest name for a very old worry.

The assessment problem

Assessment is where the difficulty is most immediate. The assignment — long treated as a window into a student's thinking and reasoning — no longer reliably indicates whose thinking it reflects. With AI available to every student, submitted work can no longer be assumed to be the student's own.

The Higher Education Policy Institute's 2026 student survey, conducted with Kortext and polling just over a thousand UK undergraduates, found AI use to be "near universal": around 95% now use AI in at least one way, and roughly 94% use generative AI to help with assessed work — up from 88% a year earlier and just 53% the year before that (HEPI, 2026; HEPI, 2025). The same series shows the share of students pasting AI-generated text directly into assessed work climbing year on year — reported at 12% in 2026, up from 8% in 2025 and 3% in 2024.

These figures are not evidence of an unprecedented collapse so much as the opening of the latest chapter in a familiar story. We have been here before.

A short history of tools education feared

Memorising for its own sake

In my day, committing formulae to memory was often treated as a mark of academic discipline. I would ask my tutors under what real-world conditions memorising a formula would ever be the practical option. Some were candid enough to admit the exercise was pointless; others defended it, though the defence always came back to the same point: in the exam, you have to recall them from memory. Their justifications, like most of what I crammed, left my memory the moment the pass was in hand.

Calculators and clocks

The calculator, and later its programmable cousin, was another forbidden object; the two devices above are like the ones I owned. At first they could not be used in class: the fear was that students would lose their arithmetic fluency, grow dependent on the machine and stop understanding numbers. In time the rules softened — some papers permitted calculators while others did not — though my recollection is that programmable models stayed banned well into sixth form.

The more recent concern that some students cannot read an analogue clock rests on a real, documented trend rather than an internet myth. In 2018, UK schools reported replacing analogue clocks in examination halls with digital displays after teachers found that a noticeable number of GCSE and A-Level students struggled to read traditional clock faces quickly under exam conditions (The Telegraph; The Independent; BBC News). The likeliest explanation is a generation raised on digital displays having little daily need for analogue faces. The evidence does not support the stronger claim that a whole generation cannot tell the time; it points instead to a single skill weakened through lack of practice — much as earlier generations were said to lose mental arithmetic to the calculator, or attention to spelling once the spell checker arrived.

A weakened skill, though, is not a lost one. Any student who wants to understand how an analogue clock works now has endless free material to hand. We all leave school without truly grasping some concept or other; someone who never understood Newton's third law of motion can today find hundreds of explanations online, in a variety of styles — a world away from the single textbook, the scribbled blackboard and the occasional lab that were all I had.

Handwriting and the spell checker

Then there was writing itself. Joined-up, cursive handwriting was bound up with notions of neatness, maturity and educational seriousness. The spell checker drew two objections: that it would erode a person's ability to spell and communicate, and that by changing words it altered the writer's original text.

A trace of that caution survives in the exam hall. Under the rules of the Joint Council for Qualifications (JCQ) — the umbrella body that sets common exam regulations for the UK's main awarding organisations, including for GCSEs and A Levels — a candidate approved to use a word processor normally has spelling and grammar checkers and predictive text switched off, unless a further approved access arrangement allows otherwise. The machine is, in effect, turned back into a plain typewriter to level the field. Outside the exam room the norm has reversed entirely: in higher education a standard spell checker is simply expected, and coursework is meant to arrive clear, professional and free of errors.

Film, radio and television

If any medium was ever oversold to education, it was film. In 1913 Thomas Edison declared that books would "soon be obsolete in the public schools," predicting that the motion picture would teach every branch of knowledge and overhaul the school system within a decade (Quote Investigator). Radio, and later television, inherited both the hype and the suspicion.

The suspicion ran along familiar lines. Many teachers and traditionalists were sceptical, and their objections have a distinctly modern ring:

students would become passive observers rather than active learners;
entertainment would crowd out serious study;
teachers would lose their authority;
pupils would lean on images instead of developing imagination and reasoning; and
the technology would prove a distraction rather than an aid.

Neither the hype nor the fear was borne out. Film did not replace the textbook or the teacher, and television did not rot young minds. Once the novelty faded, moving pictures settled into the role they still hold — a supplement, valuable when a teacher uses it deliberately and hollow when it merely fills time.

The search engine

The web met the same reflex. When search engines put the world's information a keystroke away, the worry was that we would stop remembering anything and lose the capacity for deep, sustained thought — the argument in Nicholas Carr's 2008 essay "Is Google Making Us Stupid?" (The Atlantic). Two decades on, search is so woven into study and work that the question sounds quaint. The tool changed how we remember; it did not end thinking.

Wikipedia — the closest parallel

Of all these, Wikipedia is the closest parallel to how AI is likely to evolve in education, and its history is worth following in a little more detail.

When Wikipedia emerged in the early 2000s, much of the establishment reacted with suspicion. Its central idea — an encyclopaedia written and edited by essentially anyone — ran against academic notions of authority, authorship and peer review. Teachers warned of errors, vandalism and bias, and by the mid-2000s some schools and departments were explicitly barring students from citing Wikipedia in assessed work. Tellingly, these were usually bans on citing it, not on consulting it — Middlebury College's history department being a well-publicised example in 2007 (Inside Higher Ed). The case was complicated by evidence that it was not as unreliable as assumed: a much-discussed 2005 Nature investigation compared 42 science entries with Encyclopaedia Britannica and found Wikipedia surprisingly close in accuracy, though Britannica disputed the comparison (Nature).

Over the following decade the debate shifted from "is Wikipedia trustworthy?" to "how should it be used?" — as an entry point and a route to primary and secondary sources, rather than an authority to be cited in itself. British universities now reflect that more nuanced position, and some go further: the University of Edinburgh employs a Wikimedian in Residence and has students edit Wikipedia to build research and information-literacy skills, an approach it sums up as "don't cite Wikipedia, write Wikipedia" (University of Edinburgh). The response moved, in short, from prohibition, to reluctant acceptance as a starting point, to deliberate use for teaching source evaluation. Wikipedia never became a substitute for scholarly sources; the lesson was that students are better taught how, when and why to use it than simply told not to.

The pattern is consistent. Writing, the calculator, the spell checker, film and television, the search engine, Wikipedia — each was, in its moment, accused of hollowing out the mind. In every case the honest verdict is the same: something was genuinely lost, far more was gained, and education adapted once it stopped fighting the tool and started teaching it.

AI in the classroom

Much of the education establishment still regards AI warily — and not without reason: the models still invent things and state their errors with confidence. The picture is not uniform, though. Near-universal student use and real institutional change already sit alongside that unease: only around a third of students feel their institution encourages them to use AI, even as roughly two-thirds say assessment has already changed because of it (HEPI, 2026).

The reliability of the tools is improving, too. Grounding a model's answers in retrieved source material — an approach known as retrieval-augmented generation, or RAG — reduces some kinds of factual error, and having several models check one another can catch more. Neither technique is a guarantee: retrieval can surface the wrong passage, and models cross-checking each other can just as easily settle on a confident, shared mistake. These tools are becoming more reliable, not yet reliable — and teachers, too, are not infallible.

It helps to separate the ways AI can be used, because they are not equivalent:

As a tutor or explainer — standing in for or supplementing the teacher, the textbook, the library and the explainer sites, for instance by simplifying a difficult topic or summarising a long text.
As a generator of practice — producing quizzes to rehearse for an exam or a class discussion, or to confirm a topic has been understood.
As a maker of supporting material — infographics or images to accompany an argument, replacing the scrapbook cuttings and hand-built spreadsheet charts.
As a research tool — asked about Marie Curie, it can gather her life, family, work and achievements in one place.
As a reviewer — handed a finished assignment, it improves clarity, flow, spelling and grammar.
As a ghostwriter — the student pastes in the prompt, sets a length, an audience and a style, and submits the output, with varying degrees of review, as their own work.

As things stand, some of these are plainly unacceptable. Others might be permissible if educators could be confident that the models had guardrails to block what is not allowed and could not be jailbroken.

There are further reasons, not strictly about learning, why the sector is wary. AI is seen as environmentally costly — through the energy it consumes, the emissions behind that energy and its demand for water; it can be coaxed into explaining how to make poisons, weapons and other dangerous things; and it raises real data-privacy concerns, as students hand over personal information without realising it — pasting unreviewed text, feeding the model samples of their own writing so it can imitate them, or trading data for extra features. There is also an institutional risk: feeding assignments and graded work into a model can leak assessment material, making it harder to reuse questions and easier for the model to align its output with what markers expect. These are legitimate concerns the system must address.

What the computing era should have taught us

We have run a version of this experiment before. Computers arriving in schools produced the same spread of reactions. Some teachers were reluctant, having had little or no training; others embraced the machines and argued that programming and computer literacy were essential skills. Early adoption was constrained by shortages of hardware, training and suitable software (IJCSES). In Britain, the initial ambition was simply to put a microcomputer into every secondary school (Hansard, 1981) — which in practice often meant one machine shared among many pupils.

What eventually helped was a framework around the technology. National curricula defined what pupils should learn, and qualifications such as the European Computer Driving Licence (ECDL, later renamed ICDL) gave a standardised way to develop and demonstrate transferable skills for study and work (BCS). Meanwhile access broadened as computers, and then internet-connected phones, became ordinary: by 2018, nine in ten households in Great Britain had internet access (ONS).

Schools first concentrated their computers in dedicated suites, used both to teach computing and to support other subjects. As networks, laptops and classroom machines spread, those suites gave way to virtual learning environments and broader platforms that drew resources from many subjects together and let teachers, students and parents communicate, share material and track progress (Becta, 2010).

AI needs the same kind of plan. Blocking it wholesale is both wrong and a battle already lost — and, unlike the early computers, AI is already here and in every student's hand.

What we are actually assessing

The stated purpose of education in the UK has been remarkably stable: to develop the whole person and prepare young people for adult life.

In the 1980s, that meant proving what you knew without help. Information was scarce — the teacher, the textbook, the library, and if those failed you, cramming was the only recourse. I used to handle troublesome topics by dumping everything onto paper the moment an exam began, so I could refer back to it. The exam was the main event.

Today the task is almost the reverse: proving what you can discover, understand, evaluate, create and defend in a world where help is everywhere. The trouble is that the system is not built for it. The pressure to produce high-flyers is immense, and where income depends on reputation and recruitment — most obviously in the private sector and in universities competing for students — a slide in results can cost an institution applicants and money. Parents, reasonably, want their children employable or able to progress further in their studies, and in both cases the proof is a certificate — to show an employer or the next institution. Employers must sift hundreds of candidates in little time using those same certificates — and then complain that the graduates arriving are out of step with what industry needs.

If we could start again

Consider how the system might look if it were designed for this environment from the outset.

The pre-secondary years would concentrate on teaching children how to find and understand information using the available technologies in controlled settings, and how to organise their thinking with tools such as mind maps, flowcharts and concept maps, adapted to their age. Learning would lean on lived experience: in the absence of the environmental simulator from The Orville, schools could book television-style sets and spend time living a topic — running a small corner shop, say, to learn about trade, handling money, stocking shelves and selling. Ten- and eleven-year-olds already learn to do sophisticated things with their devices because they enjoy it; schooling should build on that same motivation. Children would be graded not on recall but on presenting from notes, debating and fielding challenging questions.

In secondary school, the flipped classroom would come into its own. Students would first meet the material on their own — controlled AI, video and reading of their choosing — having already been taught how to seek out, record and absorb information. They would arrive not to receive a lesson passively but to ask questions, practise, solve problems and get help. Traditional teaching would remain on hand for those who are struggling or who prefer it, and because pupils learn at different rates, peer discussion and staff support would smooth the sticking points. Wherever possible, learning would be hands-on. Each assignment would end in a submitted piece of work, checked against three questions:

Does it contain errors, whether human or AI?
Can the student demonstrate genuine understanding through a viva — a live spoken and written exchange?
If not, they get the chance to redo it using the resources available.

In their final two years, students could take up voluntary, vetted summer placements at approved employers for a taste of working life — with hours, pay and conditions set carefully to prevent exploitation. Employers would gain a first-hand view of whether the system is producing what they need, and a channel to say so.

A reform on this scale needs stakeholders who are committed rather than pompous, willing to hear other views and to set aside their own agendas. It should not be decided by whoever is closest to the minister's ear or has a product to sell, but by whose vision stands up to scrutiny. Mistakes will be made; once a direction is chosen it belongs to everyone, to be corrected and refined as it goes. Anyone who has used generative AI since its widespread public arrival in late 2022 knows how far steady refinement can carry a thing in a short time.

Two principles matter most. First, education should build on open-source software and open-weight models rather than depend on private companies whose duty is to their shareholders. The script is familiar: establish dominance, engineer lock-in, then monetise ever harder — degrading the free product until users pay for "premium" features, charging students for access, or mining their data for value, with a floor of lawyers to fight off anyone who objects. Open systems keep schools, and students of every means, in control of their own learning.

Second, fighting AI because the establishment cannot yet see how to work with it is exactly the mistake this history warns against. Educators with genuine, well-founded concerns about AI's harms are right to voice them — but the target should be the vast, under-taxed corporations powerful enough to face down governments, not the students who will have to live and work in the world these tools are building.

Education has met the writing tablet, the printed book, the calculator, the film reel, the television set, the encyclopaedia and the search engine, and feared each in turn. Each time, once it stopped fighting and started teaching, it emerged stronger. AI is unlikely to be the exception, provided the sector chooses to teach it rather than resist it.

Some will read this as a vision, others as wishful thinking or a fantasy better left to science fiction. Yet ideas dismissed as impractical have often, in time, proved to be exactly what was needed. As George Bernard Shaw put it, "the reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man" (Man and Superman, 1903). If a single idea here reaches someone with the standing to develop it, and the will to see it through for the benefit of students and society, then setting it down will have been worth the effort.

Why I Prefer Asking AI Chatbots Instead of Posting on Forums

Alan Bonnici — Wed, 02 Sep 2026 07:02:43 +0000

This series explores AI use cases: how AI can help you reach a solution or outcome. Remember that AI is probabilistic and can make mistakes, so anything it helps produce should be clearly labelled as AI-assisted and validated by a human It should also have a disclaimer similar to what most chatbots display beneath their output.

I had a story on my writing list about how I use AI. I wanted an example that was genuine and one a reader could relate to. I also wanted it to strike the right balance between being too simplistic and being overly complicated. Furthermore, I wanted the exchange to highlight some of what the more capable AI chatbots can now do.

My article in the series The AI Revolution - History Repeating Itself on the topic of Education has autobiographical elements. After I finished the first draft of that article, I went on a search spree to find the Sharp calculator I had mentioned in the post. The hunt was purely nostalgic.

As of this writing I have not managed to find it. That item existed three houses ago, and while I am sure I would never have thrown it out, I cannot rule out that it ended up in a box that was chucked out by mistake, or that when I left my parents' house they had a spring clean and did not hold it in the same regard I would have. I haven't given up: there are still a few nooks and crannies holding boxes and briefcases full of stuff I had long forgotten about. I promise to keep looking.

iRiver iFP-395T

My search unearthed a number of electronic devices. Maybe I will come round to making a "Product from the Past" video series in the future. One gadget that particularly struck a chord was the iRiver iFP-395T MP3 player, released in 2003 as part of the iFP-300 "Craft" series. Wikipedia has a page on the series at https://en.wikipedia.org/wiki/IRiver_iFP_series. The 395T, as you can see from the photos of my actual unit, came in a bronzy two-tone colour that was — and still is — timelessly beautiful. Its unusual curved shape, developed with design firm INNO Design, made it distinctive among the many boxy MP3 players of the period. It had a four-line monochrome LCD with a backlight and came with a then-massive 512MB of flash memory. It also came with a jacket which, as you can see, is a little worse for wear in my case.

It was surprisingly capable for such a small device. As well as playing MP3, WMA and ASF files, it had a built-in FM radio, a voice recorder and, unusually, direct MP3 encoding through its line-in socket, letting you record audio straight to the player. There were preset equaliser modes plus a custom five-band EQ, and it ran from a single AA battery. With the battery it weighs around 60g (2.1 oz).

AI, can you help?

I wanted to take this out for a spin. I put in a battery and it came to life. I had an audiobook I had transferred to my phone and decided to listen to it on the iRiver. There were two hindrances I had to deal with:

The audiobook was in M4B format. The phone had no issue playing it, but my MP3 player could not handle that format.
Playback speed. Years of listening to podcasts and audiobooks have ruined the pleasure of listening to a source at the speed it was originally recorded at. While I suspect that producers ask narrators to artificially slow down (maybe because they get paid by the minute?), the bottom line is that I can only tolerate audio content if it is sped up by anything between 20 and 30%. On the phone this is just a slider; the iRiver lacked the capability.

I knew that FFmpeg would do the conversion, and I have it installed on my Windows computer. Appendix A contains the entire exchange for anyone wishing to read the conversation. I'll summarise my observations:

In a short period of time I got an answer.
When FFmpeg threw an error, I simply pasted the output back into the conversation. It took a couple of iterations, but the chatbot interpreted the output, explained what was going wrong and eventually provided the solution.
Besides asking for the syntax to convert from one format to another, I also asked the chatbot how to speed up the file in Audacity. It made me aware that I could speed up the audio directly in FFmpeg without resorting to Audacity at all, and gave me the instructions on how to go about it.

How satisfied was I out of 10? 10.

Before AI

Before AI, or rather before AI matured to the point where it did not hallucinate quite so miserably and had a context window big enough to manage an exchange like the one I am sharing here, the options were either to Google it and work from there, or to head over to the forums.

Search

I see the state of AI today as a huge evolution of Search: a Search++, or Search v10. With Search you were given a list of sites that could answer your question. Even though Search was good at interpreting the question, the way the question was articulated determined the sites that were presented. (I will not delve into Google Search's eventual enshittification to push paid content.) One would click a link and read through the material. For me, coming from a technical background, this method would work for the FFmpeg question. Had the topic fallen outside my knowledge and comfort zone, the story would have been completely different. When FFmpeg threw an error, I would have had to fish out the error line, paste it, and figure out the cause and how to fix it. Because each search was unaware of the earlier ones, I had to integrate the answers manually.

A traditional search would not have volunteered the fact that FFmpeg could also speed up the audio and that I did not need a second product. Had I asked Google Search specifically a question along the lines of "How do I speed up my audio in FFmpeg?", it would have guided me to a site with the answer, but I would have had to direct the discussion, as it would not have understood my intent.

Forums

Forums could be a great place to find an answer to your questions. The idea is that you go somewhere experts and enthusiasts congregate to discuss a subject and exchange opinions, sometimes deep and profound, about it. They would have insight into what was coming and a genuine understanding of how the product had evolved. Newbies and people who did not know how to perform an action with a tool would ask and get an answer.

Before I proceed, I want to make clear that I will be focusing on my negative experiences with forums over many years. That does not mean there aren't great channels where people are helpful and respectful. I am a faithful and forever client of MikroTik because of the dedicated help I have received over the years with this brand's equipment in their forum. People there have worked with me and gone out of their way to help me set up my MikroTik equipment and integrate it with other hardware. There are others.

Why AI is proving to be better than forums

I am far from alone in walking away. Stack Overflow's decline began before ChatGPT, but it has accelerated dramatically since generative AI became widely available. The number of new questions has fallen off a cliff. The community itself now openly debates whether the site is becoming a ghost town and why the decline has continued. Whatever the precise figures, the direction is unmistakable. The reasons people give for leaving line up closely with some of my own experiences, which I set out below.

The look-down, put-down attitude

While it is not exclusive to Stack Overflow, in my case I most associate the look-down/put-down attitude with this organisation. The clippings above are all my postings. Out of the 88 questions and answers I have posted across the Stack Exchange network, ten were ever downvoted, and every single one of them was a question I asked, never an answer I gave. 11% might not be big to some, but the number is not really the point: downvoting someone, or looking down on them, for asking a question respectfully is something that should never have been tolerated in the first place.

Being told that your post is a duplicate of something asked 10 years earlier is not something many would intuitively accept, all the more so in the ever-changing world of technology. Worse still, the "duplicate" is often for a different operating system, a different version, or a subtly different problem, yet the thread gets locked before anyone can attempt to help you. In the Meta post asking where did users go and what can be done to prevent that?, I reference the comment made by George Stocker. I strongly recommend reading this post in full.

We spent years giving folks negative feedback on their questions, they took it personally, and others saw that and stopped asking questions here because they didn’t want the negative feedback. Precisely how did you think this would go?

Incidentally, while researching this topic I came across a negatively rated post about FFmpeg, dated 28 July 2026. Old habits die hard.

None of this is just my thin skin. Stack Overflow itself admitted, as far back as 2018, that the site was not very welcoming and even built tools to classify the condescension, snark and sarcasm littering its comments. Others have documented the human cost at length: April Wensel's Suffering on Stack Overflow and Peter Kellner's Fixing Stack Overflow's Bully Problem both describe a culture that rewards experts who show zero tolerance for newcomers — and note how the reputation system can leave a beginner, after a handful of poorly received questions, effectively blocked from asking anything more.

In fairness, the friction runs both ways. Much of it stems from a mismatch of expectations: newcomers arrive treating the site as a help desk for their immediate problem, while veterans guard it as a curated encyclopedia where duplicates and low-effort questions erode the value of the archive. Jon Skeet, one of the most prolific contributors the site has ever had, made this very point in his essay on Stack Overflow culture: answerers can be needlessly hostile, but askers, too, demand free labour, ignore the guidelines and bristle when asked for more detail.

If this philosophy was also shared by those running the site, it should have been made much clearer to people arriving there looking for help. The subsequent fall in activity suggests that there was a fundamental mismatch between what many users wanted from Stack Overflow and what the site itself was trying to be.

Long before moving to AI, I abandoned the Stack Overflow sites in favour of places such as Reddit and other forums.

The points that follow are not directed specifically at Stack Overflow. They are drawn from my experiences across forums and support communities over many years. Some will apply to one community more than another.

Comments for reputation's sake

On forums with reputation or points systems, there are posters whose replies appear to exist only to push up their score. They add no value to the discussion and, even when they are not demeaning the poster, they distract others who could be helpful. For example, a question asking how to convert from M4B to MP3 in FFmpeg would attract a rant about how FFmpeg supports companies that make billions and do not contribute a cent, or a link to some other software that does the task, or a link to the product's website with a note: read this. I file this under "If you have nothing positive or useful to say, then don't". These useless posts, besides being wholly unproductive, add noise to the thread and risk hijacking it (see below).

Turnaround times

I am Europe-based, around six hours ahead of the US East Coast. A reply from a forum frequented by Americans meant that an exchange could take as much as a day, unless I was willing and able to stay up well into the night — and even then there was no guarantee that someone would read it. Such delays made reaching a solution a lengthy process, spanning days if the exchange went back and forth.

Forum memory / consistency

I spoke about how improvements in AI memory have improved the exchange with a chatbot. With traditional forums, an exchange suffers memory loss the longer it becomes and the more responses it accumulates. Those offering assistance had to catch up on how the exchange had evolved over time, ignore the useless and distracting comments, understand the need, and provide an answer. When multiple people reply to a question without building on one another's posts, each heads off in their own direction, resulting in a confused mess that may end up unrelated to what the original post set out to solve.

Time per question

Some posters had such a long list of material to work through that, like a doctor, they would spend only a limited amount of time understanding the question. Some technical support forums followed a script along these lines:

Glad I can help you, and rest assured I will do my best to help you find a solution.
A standard list of things to try.

The problem is that this standard list was not derived from reading the post, nor tailored to the poster's case; it was pasted into every thread. If the title mentioned "Problem with Windows Update", out came the standard list of things to try, irrespective of what the original poster (OP) had actually written in the body. If the person came back to say that all of these had failed, my impression was that the thread was then at the mercy of whether someone in the community with a genuinely deep understanding of the topic would follow up on it.

Thread hijack

I have experienced threads that were hijacked. Normally this was the work of people who felt the need to comment on every post without adding value, or it frequently happened once a post had accumulated a large number of replies. When a thread was hijacked over a hotly debated topic, it was almost impossible to regain control of it.

Too much of an expert

Certain forums were run by subject-matter experts who lived and breathed the subject. Newbies, or people who did not live and breathe the topic and did not want to learn it — they just wanted an error to go away — could, even when they were not put down in the style of Stack Overflow, find themselves being helped by people ten levels above them, speaking terminology way over their heads. I have seen posts in which a person states that they do not understand what they are being told to do and need their hand held: "Could you please paste what I need to type into the computer?"

Unanswered / abandoned threads

Some threads, for whatever reason, never get served: one question and zero answers, or one question and many exchanges but still no answer.

Conclusion: The future of forums

Much of what AI chatbots can do is thanks to the enormous body of material people have published over the years: forum posts, books, user manuals, information from product owners, documentation, how-to videos and blogs. Recent improvements in LLMs have made these tools enormously useful and effective at hand-holding people through the process of solving a problem or reaching a goal.

If I have a question, my first port of call is a good AI chatbot, normally one set to its Thinking / Reasoning or Code and Problem Solving mode. These models have eliminated all of the negative experiences and inefficiencies I described above. An AI will re-explain the same thing five different ways without a sigh. There are no stupid questions, no eye-rolling, no shaming and no permanent public record of my "dumb" question following me around under my real name. I can ask it to explain something as though I know nothing about the subject, or to answer in a language that is not my first language, and it will tidy up a badly worded question rather than downvote it for poor grammar. It meets me where I am.

It is ironic that AI has benefited from the enormous amount of human knowledge accumulated on forums; in a sense, the forums helped build their own replacement. But that raises an uncomfortable question: if everyone asks an AI and nobody documents new problems and their solutions, where will the next generation of fresh information come from for future models to learn from? There is, perhaps, an answer.

Will forums become something that only older generations and (hopefully) the Internet Archive will remember? I think some will.

Others need to reinvent themselves, and here is a vision of how future forums could evolve. Embedded AI chatbots will be the front line for user queries. As happens today, many questions will come from individuals who are not really interested in the product, who have a problem they want solved and will never show their face in the forum, or the question will be a basic one that has already been asked countless times. In either case, there is little value in requiring a human community member to answer essentially the same question again and again.

The people who frequent these forums could look at the AI answers, discuss them, offer alternative views and build on them to enhance the thread, deepen their knowledge and engage with a community of others interested in the topic. This would also create fresh material that future AI systems could learn from. When a new version of the product comes out, the core insiders could take it apart and discuss the topics not yet part of the LLM's core knowledge.

After an AI answer, the forum would offer the person the option to interact with the human community, an opportunity to dive deeper into what the solution does, how it has evolved and where it is heading. Many — perhaps the majority — will click straight past that button, and that is OK. The few who want to explore the community can be taken under its wing and helped to develop a deeper understanding of the product.

I come from the BBS (bulletin board system) and Usenet days, and even though those communities were certainly not as romantic and cuddly as nostalgia might suggest, there were some good people, and you could find genuinely interesting and insightful discussions; with perseverance you could come away with a deeper understanding of the subject matter. Disagreement and argument are the lifeblood of any forum, but nastiness, condescension and similar behaviour should not be tolerated, and those inclined towards it should be barred from helping others. AI can help weed out such people.

Appendix A - Asking an AI chatbot for help

The entire exchange

`> [!info] Notes

The text below represents an actual exchange with one of my AI chatbots.

In several prompts, I pasted the full FFmpeg output after an error occurred. As these outputs were very lengthy, I have abbreviated them using vertical ellipses (⋮), retaining only the opening and closing portions where appropriate.

The exchange was originally saved as a PDF and later converted to Markdown using another AI tool. I subsequently made manual edits, including the removal of unnecessary line breaks and minor formatting adjustments.`

User prompt: convert m4b to mp3 using ffmpeg

Response: Basic High-Quality Conversion

ffmpeg -i input.m4b -codec:a libmp3lame -qscale:a 2 output.mp3

Key Parameters

-i input.m4b: Specifies your input M4B file.
-codec:a libmp3lame (or -c:a libmp3lame): Uses the standard LAME MP3 audio encoder.
-qscale:a 2: Enables Variable Bitrate (VBR) quality. Values range from 0 (highest quality/larger file) to 9 (lowest quality). 2 provides a balance around ~190–250 kbps.

Constant Bitrate (CBR)

ffmpeg -i input.m4b -c:a libmp3lame -b:a 192k output.mp3

Use -b:a 128k, -b:a 192k, or -b:a 320k to set a fixed target bitrate.

Batch Conversion (All Files in Folder)

● Linux / macOS (Bash/Zsh)

for f in *.m4b; do ffmpeg -i "$f" -c:a libmp3lame -qscale:a 2 "${f%.m4b}.mp3"; done

● Windows (Command Prompt)

for %f in (*.m4b) do ffmpeg -i "%f" -c:a libmp3lame -qscale:a 2 "%~nf.mp3"

● Windows (PowerShell)

Get-ChildItem *.m4b | ForEach-Object { ffmpeg -i $_.FullName -c:a libmp3lame -qscale:a 2 "$($_.BaseName).mp3" }

User prompt: this is an audiobook

Response: For audiobooks, standard music settings waste storage space and often strip out embedded cover art or chapter structures.*

Single File (Optimized for Spoken Word) Drastically reduces file size while preserving voice clarity, metadata, and embedded cover art.

ffmpeg -i input.m4b -c:a libmp3lame -b:a 64k -ac 1 -map 0:a -map 0:v? -c:v copy
-map_metadata 0 output.mp3

-ac 1: Converts audio to mono (narration rarely needs stereo and cuts file size in half).
-b:a 64k: Optimal bitrate for voice (use 96k if the audiobook has heavy background music or sound effects).
-map 0:v? -c:v copy: Retains embedded cover art without re-encoding the image.
-map_metadata 0: Copies book title, author, and chapter metadata to ID3 tags.

Split M4B into Equal Chunks (e.g., 30-Minute Tracks) If your MP3 player doesn't support chapter navigation inside a single file, cut it into time-based segments:

ffmpeg -i input.m4b -c:a libmp3lame -b:a 64k -ac 1 -f segment -segment_time 1800 -reset_timestamps 1 part_%03d.mp3

-segment_time 1800: Splits the audio every 1800 seconds (30 minutes).
part_%03d.mp3: Outputs sequentially numbered files (part_001.mp3, part_002.mp3, etc.).

Split by Embedded Chapters (Linux / macOS) To automatically break the audiobook into individual MP3 files per chapter title using ffprobe and jq:

ffprobe -i input.m4b -print_format json -show_chapters -loglevel error | \
jq -r '.chapters[] | "\(.start_time) \(.end_time) \(.tags.title)"' | \
while read -r start end title; do
    ffmpeg -ss "$start" -to "$end" -i input.m4b -c:a libmp3lame -b:a 64k -ac 1 "${title//\//_}.mp3"
done

User prompt: ffmpeg -i "AudioB.cue" -c:a libmp3lame -b:a 64k -ac 1 -map 0:a -map 0:v? -c:v copy -map_metadata 0 "AudioB.mp3"
.
.
.
libavfilter 11. 17.100 / 11. 17.100 libswscale 9. 8.100 / 9. 8.100 libswresample 6. 4.100 / 6. 4.100 [in#0 @ 00000144cbfad0c0] Error opening input: Invalid data found when processing input Error opening input file AudioB.cue. Error opening input files: Invalid data found when processing input

Response: You passed the .cue text file to -i instead of the actual audio file. FFmpeg cannot process a plain text CUE sheet as an audio input.

Run the command against the actual .m4b file in that folder instead:

ffmpeg -i "AudioB.m4b" -c:a libmp3lame -b:a 64k -ac 1 -map 0:a -map 0:v? -c:v copy -map_metadata 0 "AudioB.mp3"

(If the .m4b file in your folder has a slightly different filename, run dir .m4b in your command prompt to copy the exact name).

A few helpful notes:

Chapters: M4B files almost always have chapter markers embedded natively. Converting the .m4b directly will automatically include those chapters without needing the separate .cue sheet.
If you want to split by CUE sheet: FFmpeg doesn't natively parse CUE sheets to split audio. If you specifically want individual MP3 tracks per chapter using that CUE sheet, a dedicated tool like mp3splt or CueSplitter is much easier than FFmpeg.

User prompt: I want to speed it up by 20% how can I do it in audacity

Response: To speed up an audiobook by 20% while keeping the narrator's pitch natural, use Audacity's Change Tempo tool.

Step-by-Step Guide

Import Audio: Open Audacity and drag your audio file into the window.
Select Track: Press Ctrl + A (or Cmd + A on Mac) to highlight the entire track.
Open Tempo Tool: Go to the top menu and select Effect > Pitch and Tempo > Change Tempo... (Avoid "Change Speed", as that raises the pitch and makes the narrator sound like a chipmunk).
Set Percentage: In the Percent Change box, type 20.
Apply the Effect: Click Apply (or OK). Processing may take a minute or two depending on the length of the audiobook.
Export Audio: Go to File > Export Audio..., set your format to MP3, choose your quality, and save.

Previewing Without Permanent Editing If you just want to listen at 1.2x speed inside Audacity without permanently altering and saving the file, locate the Play-at-Speed toolbar slider, drag it to 1.20x, and click the Play-at-Speed button (the green play icon with a small clock next to it).

User prompt: the output is not complete : ffmpeg -i "AudioB.m4b" -c:a libmp3lame -b:a 64k -ac 1 -map 0:a -map 0:v? -c:v copy -map_metadata 0 "AudioB.mp3" ffmpeg version N-125019-g6698195dc4-20260614 Copyright (c) 2000-2026 the FFmpeg developers built with gcc 15.2.0 (crosstool-NG 1.28.0.23_185f348) configuration: --prefix
.
.
.
1:1], q=2-31, 90k tbr, 90k tbn (attached pic) frame= 1 fps=0.0 q=-1.0 size= 41KiB time=N/A bitrate=N/A speed=N/A elapsed=[out#0/mp3 @ 00000229e8d95880] video:36KiB audio:2KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 12.705435% frame= 1 fps=0.0 q=-1.0 Lsize= 43KiB time=00:00:00.27 bitrate=1258.1kbits/s speed=0.383x elapsed=0:00:00.72

Response: The conversion stopped after 0.27 seconds because FFmpeg tried to write the embedded cover art as a video track. Since image cover art only has 1 frame, FFmpeg closed the entire output file as soon as that single frame finished.

Fix 1: Keep Cover Art (Proper Mapping) Adding -disposition:v attached_pic tells FFmpeg to embed the image as static ID3 album art rather than a video stream:

ffmpeg -i "AudioB.m4b" -c:a libmp3lame -b:a 64k -ac 1 -map 0:a -map 0:v? -c:v copy -disposition:v attached_pic "AudioB.mp3"

Fix 2: Strip Cover Art (Audio Only) If you do not need the image file embedded, dropping the video mapping avoids container errors completely:

ffmpeg -i "AudioB.m4b" -c:a libmp3lame -b:a 64k -ac 1 "AudioB.mp3"

Fix 3: Convert AND Speed Up 20% (Skip Audacity) You can perform the conversion and the 1.2x speedup directly in FFmpeg using the atempo audio filter (preserving narrator pitch):

ffmpeg -i "AudioB.m4b" -c:a libmp3lame -b:a 64k -ac 1 -af "atempo=1.2" "AudioB.mp3"

User prompt: still incomplete : ffmpeg -i "AudioB.m4b" -c:a libmp3lame -b:a 64k -ac 1 "AudioB.mp3" ffmpeg version N-125019-g6698195dc4-20260614 Copyright (c) 2000-2026 the FFmpeg developers built with gcc 15.2.0 (crosstool-NG 1.28.0.23_185f348) configuration: --prefix=/ffbuild/prefix --pkg-config-flags=--static .
.
.
.
5KiB time=N/A bitrate=N/A speed=N/A elapsed=0[out#0/mp3 @ 000002917ff06900] video:166KiB audio:2KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 2.863072% frame= 1 fps=0.0 q=-0.0 Lsize= 173KiB time=00:00:00.27 bitrate=5094.6kbits/s speed=0.372x elapsed=0:00:00.74

Response: FFmpeg automatically picked the embedded cover art image (Stream #0:2) as a video stream, causing the entire process to stop as soon as that single image frame finished.

Adding -vn disables video/images completely and forces FFmpeg to process the full audio track from start to finish.

Standard Conversion (Full Audiobook)

ffmpeg -i "AudioB.m4b" -vn -c:a libmp3lame -b:a 64k -ac 1 "AudioB.mp3"

Convert + Speed Up 20% (Recommended) If you want to apply the 1.2x speedup directly during conversion (saving you the trip to Audacity):

ffmpeg -i "AudioB.m4b" -vn -filter:a "atempo=1.2" -c:a libmp3lame -b:a 64k -ac 1 "AudioB.mp3"

The Organisation That Knows What It Knows

Alan Bonnici — Sun, 30 Aug 2026 12:45:55 +0000

AI and the enterprise's scattered memory

A practical question: what would it take for an organisation to put everything it knows behind a single, trustworthy assistant — and why is that worth doing now? This is written as an article, but it doubles as a position paper for senior leadership.

The short version

Every large organisation already owns the answer to almost any question an employee might ask. The problem is not that the knowledge is missing; it is that the knowledge is scattered across dozens of systems, thousands of documents, several generations of technology and a good deal of unofficial "shadow" tooling — and no single person, or team, can see all of it.

The cost of that fragmentation is measurable. The McKinsey Global Institute's much-cited research found that knowledge workers spend close to a fifth of the working week simply hunting for and gathering information (McKinsey Global Institute, via Playbook's summary). IDC has put a price on the wider problem, estimating that document-related friction costs organisations more than a fifth of their productivity (IDC, via Crown). That is time and money spent finding the inputs to work rather than doing the work.

My proposition is straightforward. The same technologies that now let a consumer chatbot search the web and read your personal documents can be turned inward — pointed at an organisation's own systems, files and expertise — to produce a Corporate AI assistant that behaves as though it knows the whole organisation. It answers questions, walks people through processes, helps fill in the forms, chases the follow-ups, and — because it sees across the whole enterprise — spots the patterns and duplication that no individual department ever could.

This is not science fiction; nascent versions already exist in the market. Nor is it a weekend project. It is a journey, it carries real governance and security risks, and the evidence shows that most organisations that rush it will fail. What follows sets out the opportunity, a phased way to build it, the guardrails that make it safe, and a candid account of why these initiatives usually go wrong — so that yours does not.

The ask of leadership is not "buy a chatbot." It is to treat the organisation's collective knowledge as strategic infrastructure, and to fund its consolidation the way you would any other foundational asset.

The organisation I have in mind

The organisation I am picturing as I write is a complex one: it has been around a long time, it is the product of mergers or acquisitions, and today it carries a large global footprint with a multinational workforce, many of them remote. My focus stays on entities like that because they feel the pain most acutely — but nothing here is exclusive to them. A twenty-person firm has the same problem in miniature.

A company is its people and its systems

Organisations deliver their products and services through a combination of people and software. The list below — consolidated from a longer one my AI committee drew up — is a fair sketch of what sits inside a mature enterprise:

Accounting and financial systems
Enterprise resource planning (ERP)
Inventory and warehouse management
Human resources information and human capital management (HRIS / HCM)
Payroll and time-tracking
Learning management systems (LMS)
Customer relationship management (CRM)
Point-of-sale and sales systems
Marketing automation and web platforms
Office productivity suites
Intranets and internal knowledge bases
Extranets and partner portals
Collaboration and communication tools
Helpdesk and IT service management
Identity and access management (IAM)
Document management systems

Some of these systems are new. Others are, both literally and relatively, ancient — running on technology whose best days ended decades ago. Some are off-the-shelf; others are heavily customised or entirely bespoke. In an organisation shaped by mergers, several of them will exist in duplicate or triplicate, either awaiting integration or waiting for someone to fund the unglamorous work of consolidating them without breaking the business in the process.

And then there is everything off the map. Beyond the officially sanctioned systems lies Shadow IT: the spreadsheets, cloud sign-ups and side tools that never made it onto the Application Portfolio or asset register, along with all the other nooks and crannies where corporate data quietly accumulates. This is not a fringe concern. Recent benchmarking suggests the average enterprise now runs well over 800 applications, with the majority operating outside formal IT oversight (Torii 2026 benchmark, via Cyber Magazine), and Gartner has estimated that shadow IT accounts for something like 30–40% of IT spending in large enterprises (Gartner, via BetterCloud). Any honest plan to "know the organisation" has to reckon with the knowledge that lives in the shadows, not just the knowledge in the catalogue.

The uncomfortable truth is that no organisation of this kind has a single, coherent memory. It has fragments — and the map of those fragments lives in people's heads.

How I actually use AI today

Before turning that fragmentation into an opportunity, it helps to be concrete about what today's tools already do well, because the enterprise vision is really just this experience, aimed inward.

I put both commercial and locally run models to work on tasks that help me understand or perform something complex, simplify a topic, or find information. Getting to an answer I am happy with is almost never a single shot; it is a back-and-forth. That conversational quality matters, and I will come back to why.

Out of the box — or with a minor settings change — today's chatbots can supplement their original training with two extra sources: live internet searches and the documents you give them. The result is an answer that fuses three things: the model's built-in knowledge, up-to-date material from the web, and your own private material. The technique that grounds a model's answers in a specific body of documents has a name — retrieval-augmented generation (RAG) — and it was introduced in a 2020 paper by Patrick Lewis and colleagues at what was then Facebook AI Research (Meta AI). RAG is now the reference architecture for the large majority of enterprise generative-AI deployments (Atlan). It is the single most important idea in this article, because it is exactly how a general-purpose model can be made to answer questions about your organisation rather than the world at large.

Two habits make the difference between a mediocre exchange and a good one, and both translate directly to the enterprise setting.

First, I instruct the model to interrogate me when things are unclear. The standing prompt I attach is:

If any part of my request is unclear, ask concise and direct questions that will help reach a solution. Do not make assumptions when critical information is missing. If you are uncertain, lack sufficient information, or no reliable answer exists, state this clearly instead of inventing or guessing. Be transparent about your level of confidence in your answer.

The effect is that the tool guides me to focus my own question. It asks me to paste the script, the screenshot, the error message; sometimes it simply reflects my request back in clearer words, or offers a menu of the extra details it needs. Every exchange is different, but the experience is consistently good. (I keep a second prompt to verify generated output; I am happy to share it.)

Second, when a model cannot answer, rewording the question often unlocks it. I have also noticed that some paid models occasionally cut their processing short — the same question, asked again a few hours later, comes back correct. I suspect this is load management by the vendor during peak demand rather than any fault in the question.

I dwell on these habits because they are precisely the behaviours a corporate assistant must reproduce. An enterprise tool that guesses when it is unsure, or that hides its uncertainty, is not merely unhelpful — it is dangerous. Guiding the user, admitting the limits of its knowledge, and citing where its answer came from are not niceties; they are the difference between a system leadership can trust and one it cannot.

The same principle settles the load problem I described a moment ago. A consumer service can quietly cut its processing short at peak times and leave you to try again hours later; a corporate assistant must not. It has to be provisioned with the capacity to meet the demand placed on it — and on the occasions when load genuinely bites, it has better options than a half-formed answer. It can say so plainly ("the system is under heavy load; please try again shortly"), or, better still, it can queue the request and return the full answer asynchronously once capacity frees up — notifying the employee when it is ready, exactly as the follow-up agents described later in this article keep people posted on a request's progress. Either way, the user gets an honest signal or a complete answer, never a degraded reply they cannot tell apart from a good one. That indistinguishable-but-wrong answer is exactly the failure this whole approach exists to prevent.

The reason I have spent time describing my own use of AI is that the enterprise vision is not fundamentally different. At its core, the assistant described in this article is simply today's AI experience scaled from the individual to the organisation. Instead of searching my documents and the public internet, it searches the organisation’s documents, systems, processes and accumulated expertise. The challenge is therefore not one of capability but of integration, governance and trust. Once viewed through that lens, the leap from a personal assistant to a corporate one becomes much smaller than it first appears.

Back to the office

Today an organisation may run its own version of one of the commercial chatbots for its employees. The enterprise AI should replace every other chatbot in use across the organisation, because offering a single chat interface for all queries is essential to avoiding confusion. In many instances, too, what begins as a simple generic exchange evolves into something that touches the organisation's internal systems — and the employee should not have to change tools when it does.

As noted above, the enterprise AI has all the elements of a public-facing solution, so it should have no difficulty answering entirely generic questions that carry nothing sensitive: how to widen the line spacing in a paragraph, how to use the new Python features in Excel, how to make a commercial CMS do something particular. In fact, an organisation can make a serious mistake here. If the model behind the enterprise assistant is a restricted or cut-down version of the commercial solution it is based on — a smaller context window, or weakened memory of the session and of the employee's earlier exchanges — the project is undermined from the start. Employees will quickly work out that they have been handed a lesser tool and revert to the more capable models that actually help them. It also gives those already wary of AI a legitimate-sounding reason to avoid it altogether.

A one-stop shop for all AI use is both a convenience and a control, and — because every question flows through one channel — a lens onto the goings-on across the organisation, a benefit I return to later.

The stakes rise the moment the question turns inward:

What is the process to request special leave to get married?
Where is the approved set of corporate backgrounds for video calls?
How do I request access to an internal application?
What is the whistleblowing procedure?
How do I perform a particular action in one of our internal systems?
Why is the platform at https://internal-system.example running slowly today?

These are the questions that consumer AI cannot touch, and they are the questions employees ask constantly.

The current situation: friction, everywhere

Assume the answer exists somewhere. The employee still has to know where to look and, failing that, whom to ask. Some of these questions are sensitive, and even people who have completed the mandatory training will not recall the specifics on demand. Others are about not reinventing the wheel: is another unit already doing this? How did they approach it? That knowledge is rarely written down anywhere findable.

And even once the source is located, the work has only begun. In most organisations the activity itself requires forms to be completed, budgets to be secured, and a chain of dependent actions, each with its own requirements that must first be discovered, then deciphered, then understood. If one part of that chain is unclear — a box on a form, say — the employee must now open a fresh round of chasing: emails to responsible teams who are busy, in a different time zone, on leave, or now focused on something else entirely. Even if the people originally responsible have not moved on, being human, they no longer remember what they documented when the solution launched.

Many explainer documents are not self-contained either; they lean on external topics — privacy, compliance and other prerequisites. Beyond the iteration this forces on the reader, a dependency mentioned in the source document may itself have been updated, or introduced, after the solution launched. This is exactly the kind of task AI excels at. Imagine an employee asking about a solution and receiving a recomposed summary complete with a checklist. The generated output includes all changes — organisational, regulatory and operational — that are now in force.

Multiply that experience across tens of thousands of employees and the McKinsey and IDC figures above stop looking abstract. This is where the working week quietly leaks away.

The reimagined situation: the know-it-all

Now picture the alternative. A single corporate assistant, reached through a familiar chat interface. Like the consumer tools, it has memory: it can pick up where you left off last time. It knows your organisation — its systems, its documents, its processes, its people.

Crucially, it does not work alone. When a task needs doing, the assistant directs its agents — smaller, purpose-built AI helpers it hands a single job to, such as routing a request, completing a form, or chasing a reply — and supervises them on your behalf. Wherever "agent" appears below, this is what it means.

If your question is unclear, it helps you articulate what you actually need.
If the answer genuinely does not exist, it tells you so plainly — and can task one of its agents with reaching the human team most likely to be able to help, opening the request on your behalf.
If your need is a process, it walks you through it step by step, and because it remembers, you can stop and resume without losing your place.
If a form is required, an agent offers to complete the parts it has already learned from your conversation, flags the parts that need doing manually, and explains what belongs in the box you do not understand.
Behind the scenes, that agent handles the follow-ups, the reminders, and the status updates, so you are not left wondering where your request has got to.

The organisational dividend is significant, and it runs in two directions. It lightens the load on the IT service desk and on the platform teams who currently field the same questions over and over — freeing those people for more rewarding, higher-value work. And it turns a cost centre into a sensing organ: the people who once answered repetitive queries can instead analyse them. A flood of identical questions is a signal that something is badly designed, poorly documented, or ripe for improvement. Today that signal is lost in a thousand separate email threads. A single assistant makes it visible.

There are three groups for whom this changes the working day more than any productivity figure conveys. New joiners gain somewhere to ask anything, however basic, without fear of looking foolish or interrupting a busy colleague; onboarding stops being a scramble to find the right person and becomes a conversation. When people leave, retire or reorganise, the knowledge they would once have walked out of the door with stays behind — captured in the assistant rather than lost with the individual, a direct answer to the key-person risk every long-lived organisation carries. And across a multilingual, multinational workforce, one shared body of knowledge can be served to each person in their own language, so a policy written once at head office is equally usable by someone reading it half a world away.

There is another kind of knowledge organisations routinely lose: not what decision was taken, but why it was taken. Years later, teams often find the approval, the architecture diagram, or the policy itself, yet the reasoning behind it has disappeared with the people who made the decision. The result is a familiar cycle: old debates are reopened, previous investigations are repeated, and well-intentioned teams unknowingly retrace work that was already done. A mature corporate AI should therefore capture not only facts and procedures, but also decision history — the business cases, trade-offs, risk assessments and discussions that explain why a particular path was chosen. In doing so, it becomes more than a repository of knowledge; it becomes a repository of organisational judgement.

This is the "know-it-all" of the title — used affectionately. Not a system that pretends to know everything, but one that genuinely can reach everything the organisation knows, and is honest about the edges of that knowledge.

Making it happen

How does an organisation get from today's fragmentation to the assistant described above? Not all at once. The estate breaks down into three categories, each with its own approach, and each can be tackled independently and incrementally.

New, replacement and upgraded systems

Many modern systems now ship with AI built in. Broadly speaking, that AI may serve one or both of two functions:

Enhancing the product itself — giving the solution additional capability in its core job. This is internal to the solution: its inner workings.
Helping people use the product — interactive documentary functionality, delivered through chatbots or search boxes, that helps users make better use of the tool and discover what it can do. Alongside it sits the static documentation: user guides, PDFs, README files and the like.

The corporate assistant is concerned mainly with that second, documentary function. As part of bringing a system into its awareness, it would both ingest the static documentation and issue live queries through the interactive search mechanisms:

Ingestion — allowing the corporate assistant to read the system's full repository of documents and organisation-specific content, giving it broad coverage.
Live query — allowing the corporate assistant to forward a question to the system and receive an answer it can fold into its reply, giving it the distilled, up-to-the-minute view that documentation always lags behind.

Secure APIs make these exchanges straightforward to set up, and there is now an emerging standard that makes the connection far less painful still. The Model Context Protocol (MCP), introduced by Anthropic in late 2024 and since placed under open, foundation-based governance, aims to be a universal connector between AI applications and the data sources and tools they need — its proponents describe it as "a USB-C port for AI" (Anthropic; Model Context Protocol specification). For a procurement team, the practical question to put to every vendor is simple: how will your product expose its knowledge and its functions to our corporate assistant, and do you support open standards for doing so? An answer of "we don't" should count against a purchase.

Old systems

Legacy systems are what they are. The organisation may not want to, need to, or be able to replace them — and often that decision is entirely rational. Bringing them into the fold means:

RAG the paper trail — ingest any documentation, notes and procedures that describe the system.
Reach the data where feasible — attempt to access the underlying data directly, when it is possible, permitted and safe.
Refocus the support team — have the people who know the system generate content to answer the questions the assistant cannot yet handle, steadily closing the gaps.
Automate the interface — where the system has a built-in help function, use the assistant (directly, or through Robotic Process Automation) to send it queries, interpret the results, build a reply for the user, and add what it learns to its own knowledge base.

RPA matters here because it is the bridge to systems that were never designed to be queried by anything other than a human at a keyboard. It lets a decades-old application participate in the assistant without being rewritten.

File repositories

Unlike systems that do something, repositories simply hold something, and so they are ingested directly as RAG. The assistant is pointed at the repository, given permission to read it, and allowed to add its contents to its knowledge. The one non-negotiable is freshness: there must be a mechanism so that when a repository changes — a document added, altered or deleted — the assistant takes in the change rather than confidently serving a superseded answer. A stale corporate memory is worse than none, because people trust it.

Governance: the part that decides whether this succeeds

Every organisation operates inside a web of operational, regulatory and contractual constraints, and the corporate assistant has to live inside that web too. In practice this is where these projects are won or lost. The technology is increasingly the easy part; governance is the hard part.

Access control. Not every document is for every pair of eyes. The assistant must serve only the content a given person is authorised to see — permission-awareness has to be built in from the first day, not bolted on later. Done well, it can also police itself: agents can alert the responsible teams when a document's authorisation level is missing, or inconsistent with what the assistant computes it ought to be.

Sensitivity and personal data. Documents contain personal and confidential information. The assistant should redact personal data when it encounters it (with agents alerting the relevant team when redaction is expected but absent), while linking to the source, unredacted document for those with the right to open it — exactly as today's specialised systems already gate access. The precise controls will depend on the use case and jurisdiction, but under regimes such as the GDPR and the EU AI Act, privacy, data minimisation, access control and appropriate governance are legal responsibilities, not optional refinements.

Information hygiene. Data needs to be pruned, purged and weeded. An assistant that faithfully retrieves out-of-date, duplicated or contradictory content will faithfully mislead. Here too, specialised agents can help the responsible teams keep the corpus clean — and, usefully, the assistant's own query logs will reveal where the rot is worst. Hygiene is not simply deletion, though: when a system is decommissioned, the organisation often still needs its knowledge — for audit, historical context or legal retention — so the assistant should keep it for as long as required, clearly marked as historical rather than current.

Licensing and contracts. Third-party systems come with limits. Before the assistant distils a vendor's data, reads its user guides, or reaches into its underlying store, someone has to confirm that the licence permits it. This is a legal review, not a technical one, and it should happen early.

And a newer risk leadership must understand: the security of the assistant itself. Precisely because this system combines access to private data, exposure to outside content, and the ability to communicate outward, it fits what the security researcher Simon Willison has named the "lethal trifecta" — the combination that lets an attacker use a booby-trapped document or web page to trick an AI agent into leaking data it should never have released (Simon Willison). This class of attack, prompt injection, needs no code exploit; malicious instructions hidden in content the assistant reads can be enough. Any serious deployment must treat this as a first-order design constraint — limiting what an agent can touch, what it can send outward, and how far the damage can spread if a single request is compromised. Convenience and blast radius pull in opposite directions, and that tension is a board-level decision, not an engineering afterthought.

A closing point on security that is easy to miss: an assistant network-exposed to the whole workforce, wired into the most sensitive systems you own, is one of the highest-value targets in the organisation. It deserves the authentication, monitoring and access discipline you would apply to any crown-jewel system — from day one, not after the first incident.

Why most of these efforts fail — and how yours can avoid it

I would be doing leadership a disservice if I painted only the upside. The sobering reality is that most enterprise AI initiatives do not pay off. A widely reported 2025 study from MIT's NANDA initiative, which examined more than 300 deployments, found that the great majority of enterprise generative-AI pilots delivered no measurable return — and, crucially, concluded that the cause was rarely the quality of the model. It was the gap between the tool and the way the organisation actually works (MIT NANDA, reported by Fortune).

That finding should reassure and warn in equal measure. It reassures because it tells us the models are good enough; the frontier is no longer the bottleneck. It warns because it locates the real difficulty exactly where organisations least like to spend: integration, data quality, process redesign and governance — the unglamorous work.

From that evidence, and from the pattern of the systems described above, a few lessons stand out:

Start where the pain is measurable, not where the demo is impressive. Much AI spending flows to flashy front-office pilots because they are easy to pitch. The durable wins are more often in the repetitive internal friction — the leave requests, the access approvals, the "who do I ask" questions — where the time saved is real and countable.
Expect the payoff to lag the effort. The benefits of a technology like this rarely appear until the organisation reshapes its processes around it, rather than bolting it onto the way things are already done. Budget and communicate for a slow start followed by a steeper return, and do not let an early, undramatic phase be mistaken for failure.
Buy where you can, build where you must. A market of capable products already exists — permission-aware enterprise assistants such as Glean, and the assistants woven into the software estates most organisations already run, including Microsoft 365 Copilot, ChatGPT Enterprise, Google's Gemini Enterprise and Amazon Q Business (overview via CIO Pages). The differentiator is rarely the model; it is the quality of the connections into your systems and the discipline of your governance.
Govern the agents before they multiply. As the assistant grows into a network of task-performing agents, that population can explode: Gartner predicts that by 2028 the average global Fortune 500 enterprise will have more than 150,000 agents in use, up from fewer than 15 in 2025 (Gartner). It also predicts that 40% of enterprises will demote or decommission autonomous agents by 2027 because governance gaps become apparent only after production incidents (Gartner). "Agent sprawl" is simply the next form of shadow IT. Plan for it now.

What I am asking of leadership

So what does this actually require of leadership? Three decisions:

Treat institutional knowledge as strategic infrastructure. The fragmentation described here is a cost the organisation already pays, every week, invisibly. Consolidating that knowledge deserves the same standing — and the same patient funding — as any other foundational asset.
Fund the unglamorous work. The evidence is unambiguous that success lives in integration, data hygiene, access control and process redesign, not in the model. A budget that funds a pilot but starves the plumbing is a budget for a failed pilot.
Put governance and security at the front, not the end. Access-awareness, personal-data protection, licensing review and defence against prompt-injection are not compliance chores to be retrofitted. They are the conditions under which the workforce will trust the system enough to use it — and trust is the whole game.

Practically, that means starting small and honest: one or two high-friction internal processes, a permission-aware foundation, a clear owner, and a way to measure the time returned to people. Then widen.

The measurement matters. Organisations are often better at counting technology than measuring friction, yet friction is the very thing this enterprise AI exists to remove. Success should therefore be judged through outcomes rather than adoption statistics: how quickly employees can obtain an answer, how long new joiners take to become productive, how many routine questions are diverted from support teams, how often existing solutions are discovered instead of rebuilt, and how much time people spend searching for information before they can begin the work that actually creates value. Over time, the organisation should become increasingly capable of answering a simple question: how much effort is being spent finding knowledge, and is that effort falling? If leadership cannot answer that question, it will struggle to demonstrate the value of solving it.

Conclusion

The effort will vary enormously from one organisation to the next, and the destination is a journey, not a sprint. What makes the endeavour so compelling is what waits at the end of it: a single assistant that draws every one of the organisation's information sources together, that can not only answer a person's questions and guide them quickly and efficiently, but that — precisely because it sees across the whole enterprise — can observe how the organisation works and suggest ways to move it forward. The tool that answers questions becomes, almost as a by-product, the tool that spots what should be improved.

And the workforce that stands on top of it is transformed. It is:

far more empowered, and able to move faster;
genuinely in possession of the organisation's knowledge, at its fingertips;
able to see what other teams are doing, rather than working in isolation and quietly rebuilding what already exists.

The knowledge is already yours. The question this article puts to leadership is whether you will keep paying, week after week, for the fact that no one can find it — or invest, once, in an organisation that finally knows what it knows.

Appendix A — Paste with caution

In a corporate environment, always follow whatever guidelines your organisation has issued. If it has issued none, read on.

There are two broad deployment patterns:

Locally or privately hosted AI — models run on an individual device or within infrastructure governed directly by the organisation.
Remotely hosted AI — models run as a service on infrastructure operated by a provider.

When you provide a document to a remotely hosted AI service, it is processed on infrastructure operated by someone else. Whether it is retained, logged or used to improve models depends on the provider, product, contract and configuration. Approved enterprise services may offer strong contractual and technical protections; unapproved consumer services may not.

In a corporate setting, uploading the wrong document to the wrong service can breach confidentiality obligations, data-protection law or a contract — which is precisely why organisational guidelines exist, and why the corporate assistant described here must operate within an approved governance boundary.

Appendix B — Sources and further reading

The following informed this article. As is my practice, conclusions are my own; sources are provided so readers can check the ground beneath them.

The cost of searching for information — McKinsey Global Institute figures, summarised; IDC on document-related productivity loss
The scale of shadow IT — Torii 2026 benchmark, via Cyber Magazine; Gartner estimate, via BetterCloud
Retrieval-augmented generation (RAG) — Meta AI's introduction; enterprise adoption, Atlan
Model Context Protocol (MCP) — Anthropic documentation; the open specification
Enterprise assistant landscape — buyer's overview, CIO Pages
Why pilots fail — MIT NANDA study, reported by Fortune
Agent sprawl and governance — Gartner on managing agent sprawl; Gartner on governance gaps
The "lethal trifecta" and prompt injection — Simon Willison

Bite: The Machine that knows Everything

Alan Bonnici — Sat, 22 Aug 2026 07:00:00 +0000

Note: The satirical parody below has been reformatted to accommodate the requirements and limitations of this publishing platform. If you would like to view the article in its original format and layout, please refer to: Bite: The Machine That Knows Everything – April 1985

The Machine That Knows Everything

TT(M)O unveils the CrAI IntelliCluster — a room-sized oracle that files away every encyclopaedia ever printed and answers back in plain English.

The CrAI IntelliCluster in a customer machine room: paired CrAI Supercomputers flanked by See-Dee-See storage drives and the operator’s green-screen console.

The Hardware

TT(M)O’s CrAI IntelliCluster is a complete state-of-the-art solution that allows you to discover everything known to man. It consists of a cluster of our very powerful CrAI Supercomputers.

Each Supercomputer comes with loads of ultra-high-speed primary memory SRAM coupled with DRAM memory that offers drastically higher density and smaller physical footprints. This combination of memory ensures that each supercomputer can fit in an area the size of a large room rather than requiring warehouse-size storage requirements.

“Storage so vast it would make Alexandria blush.”

These supercomputer networks are connected to Eye-Bee-Ehm 0833 high-capacity hard disk arrays and See-Dee-See Storage Module Drives, giving you out-of-this-world space to hold all of the knowledge in millions of Encyclopaedias — all accessible online without the need to load tapes.

Fast round-robin algorithms make it possible for all this technology to be used by tens of people at the same time. We have systems that can handle hundreds of console operators at the same time.

The Solution

Operators interact with all this knowledge through Deck 11-DPD Front End Processors. Sitting at their desk, they can type questions into the console. When they press the return key, the text they type is processed on the FEPs and is converted into a language the solution understands. It is not the 1’s and 0’s of the computer, but an advanced language called tokens.

Each console uses memory from the FEP to retain the exchange with the operator. This history makes it possible for the solution to understand how a topic has developed as the exchange progresses.

For example, if the operator starts a conversation about wanting information on the Chevrolet Caprice and later asks about Digital Gauge Clusters, the system knows the question is about the Caprice. It is possible to save the exchange of a conversation and revisit it days and weeks later by reloading it into FEP memory. Impressive!

In order to perform the miracles this system can do, the solution makes use of a database. We call this the database of knowledge. This database comes ready-made with the system. It was created by giving it access to all the texts that are available, converting them into our token internal language, and then filing them. It is a statistical and engineering work of art.

“All the knowledge of millions of encyclopaedias — answering back in plain English.”

One optional extension — a modem unit together with primary and secondary storage units — would allow the internal database to be extended to external sources such as the ARPANET, CompuServe, Minitel, Prestel, and others. Long-distance phone charges may apply to foreign access points. These services provide data that supplements what is in our internal database, as well as information that came after we stopped the database training.

Another optional upgrade to the CrAI IntelliCluster allows you to load your data. With this module you can have the system read in your stuff and let you explore it and find mistakes and inconsistencies at the speed of electricity. We support out of the box Wang, Lanier, and IBM word-processing documents, as well as files created from Lotus 1-2-3, WordPerfect, WordStar, and dBase III. For the Apple Macintosh we read MacWrite, Microsoft Word, and Multiplan documents. We also support Electronic Mail. The list is constantly expanding, and we will soon have programs that can import files from the hundreds of IBM PC and Apple Macintosh microcomputer programs coming out every year.

The Cost

TT(M)O’s CrAI IntelliCluster is value for money right out of the box, and national and international organisations can use it to discover new ways to do business, get insight into processes that take place within their organisation, and so much more. The management of the company will be impressed and will be able to see into the future of their business. Above all, the CrAI IntelliCluster is your surest way to beat the competition and make people redundant.

It can grow with the business and can be expanded to meet growing needs. A subscription ensures that customers receive an updated database of knowledge an astonishing 6 times a year.

The smallest CrAI IntelliCluster solution can operate in 1,000 square metres of floor space and requires around 5 MW of power to run. Methane- and Diesel-powered generators are two popular options for those companies wishing to be self-sufficient, although organisations housing the solution close to a power station can come to an agreement with the company to divert power from the existing households to the new computer facility.

Access to water is another requirement. This is used to cool the computer systems. Positioning the computer facility near a water source is the ideal solution; otherwise arrangements need to be made with the water company or bore into the water table.

Occasionally locals will claim that they are negatively impacted because of the burning of fossil fuel, power consumption, noise pollution, and the occasional displacement of tenants off their land. TT(M)O can assist with dealing with local government and managing the complaints of people through all acceptable ways of aligning local government officials with the project.

How to Go About It

Anyone interested should call TT(M)O and book an appointment. After a requirements analysis, the client will receive an analysis specifying the requirements to house a CrAI IntelliCluster solution.

Call TT(M)O — The Total (Machine) Organisation. Book your requirements analysis today. Long-distance and foreign access-point charges may apply. Local government liaison services available on request.

The AI Revolution — History Repeating Itself — On Economics

Alan Bonnici — Tue, 11 Aug 2026 07:00:00 +0000

This article turns from sentience to economics — and to the social and political currents that come with it.

The first article in this series argued that today's AI is not sentient: it is a good technology built from statistics, marketing and scale. This one asks a different set of questions — what AI is worth, who gains from it, and who ends up paying. As in the first article, I asked my AI committee to draw up a shortlist of developments that reshaped economies and societies. Eight were proposed; five were chosen by almost every model, and the sixth was a tie that I resolved with my committee of three AIs. That shortlist, with sources, is in Appendix A.

Across those six developments (described in Appendix A), a consistent pattern emerges — one worth holding in mind as we turn to AI:

1. Early disruption precedes long-term benefit.
Each transformation created significant initial costs. Mechanisation displaced artisans, electrification devalued older machinery and skills, digitalisation eliminated clerical and production work, printing displaced scribes, and public-health measures required expensive infrastructure. Oceanic globalisation was far more destructive, involving conquest, disease, slavery and dispossession.

2. Pioneers and investors do not always capture the value they create.

Some inventors, entrepreneurs and early investors failed financially despite creating lasting technologies and infrastructure. Railways are a strong example: many pioneering companies entered bankruptcy, receivership or reorganisation, while their tracks continued operating under new ownership. Gutenberg lost control of his printing equipment, and many dot-com companies failed even though their investments helped build the digital economy. Early investors may bear much of the risk while later businesses and society capture the long-term value.

3. Technology alone was insufficient.

The greatest benefits appeared only after societies reorganised around the new development. Electricity required grids and redesigned factories; automobiles required roads; digital technologies required new business processes and telecommunications networks; public health required sewers, clean water and organised institutions. Adoption was therefore gradual rather than instantaneous.

4. Large upfront investment created shared infrastructure.

Most developments depended on expensive systems that could serve entire economies: factories, railways, electrical grids, roads, ports, printing networks, telecommunications, sanitation systems and healthcare programmes. Once established, these systems lowered costs for many subsequent activities.

5. Costs fell and scale increased.

Each transformation drove down the cost of producing goods, moving people and cargo, transmitting information, coordinating organisations, accessing knowledge or preventing disease — and as costs fell, scale grew. Production moved from workshops to factories, knowledge from manuscripts to mass printing, trade from regional routes to global networks, and computing from isolated machines to worldwide platforms. Organisations became larger, markets broader and economic activity more interconnected.

6. Labour was displaced, reorganised — and unevenly rewarded.

Older occupations declined while new industries and professions emerged: agricultural and craft work gave way to factories, transport, engineering, administration, healthcare, communications and software. The central effect was not the destruction of jobs but a continuing shift in the kind of work people did. The gains, however, were shared unequally — owners of capital, industrial powers and early adopters tended to benefit first, while workers, colonised populations and poorer communities bore a disproportionate share of the costs.

7. Knowledge became an increasingly important economic resource.

Printing allowed ideas to circulate more widely, while digital networks accelerated the storage, copying and transmission of information. Public health also depended on the systematic application of scientific knowledge. Economic progress increasingly came from education, research, communication and organisational capability rather than physical production alone.

8. Urbanisation and complex societies became possible.

Industry concentrated workers in cities, transport and electricity supported dense economic centres, and sanitation made large urban populations safer. Modern cities, hospitals, universities, factories and offices depend on several of these transformations operating together.

9. Every solution created new risks.

Industrialisation and motorisation produced pollution and fossil-fuel dependence; global trade helped spread disease and exploitation; printing and digital media accelerated misinformation; antibiotics contributed to antimicrobial resistance; and global digital systems introduced concerns over surveillance, monopoly power and employment displacement.

The AI opinion split

Those patterns are the backdrop; the live argument is over how they will play out for AI. Public debate is usually reduced to optimists versus sceptics, but the economic, social and political divisions are more complex. The different camps are not mutually exclusive: someone may consider AI useful but overvalued, productive but socially unequal, or transformative but politically dangerous.

The bubble sceptics, represented most forcefully by Ed Zitron, argue that investment in chips, data centres and AI companies has moved far ahead of proven revenue. A milder version, associated with analysts such as Jim Covello, accepts that AI has useful applications but doubts whether these can generate returns sufficient to justify present spending and valuations. As with railways and the dot-com boom, the technology could survive and transform society even while investors and pioneering companies lose heavily.

The measured-growth sceptics, most notably Daron Acemoglu, do not necessarily predict a crash. They expect AI to produce genuine but comparatively modest economic gains because only some workplace tasks can be automated reliably and profitably. Improvements demonstrated in selected occupations may not translate quickly into economy-wide productivity growth, particularly when adoption requires new skills, processes and infrastructure.

The productivity optimists, including Erik Brynjolfsson, Ethan Mollick and Andrew Ng, regard AI primarily as a tool that will augment workers, lower the cost of cognitive tasks and improve organisational efficiency. They argue that the benefits will emerge gradually as businesses redesign work around the technology. The more ambitious transformational optimists, such as Dario Amodei, Demis Hassabis and Sam Altman, expect AI to do more than improve existing processes: they believe it could accelerate scientific discovery, reduce the cost of expertise and create major new sources of economic growth.

Other disagreements concern not how much value AI will create, but who will receive it. Labour and inequality critics — including Acemoglu, David Autor and Simon Johnson — warn that higher productivity does not automatically produce higher wages or better employment. AI could augment employees, but it could also replace, deskill or intensively monitor them, allowing shareholders and dominant companies to capture most of the gains. Critics such as Timnit Gebru, Kate Crawford and Meredith Whittaker extend this argument to hidden labour, discrimination, privacy, environmental costs, surveillance and the concentration of technological power.

This leads to the political divide. Market-oriented advocates favour rapid development and relatively limited intervention, arguing that competition and innovation will spread the benefits. Democratic-governance advocates instead believe that competition law, labour protections, privacy rights, independent auditing and public investment are needed to ensure that AI serves society rather than a small number of corporations. A further geopolitical perspective treats AI, semiconductors and computing capacity as strategic infrastructure, making their control a question of national security, economic sovereignty and international power.

The central disagreement is therefore not simply whether AI will succeed. It is whether the value created will justify the investment, how its benefits and costs will be distributed, and who will control the economic and political power that follows.

History, repeating

The reason this belongs in a series called History Repeating Itself is that we have been here before — and the past offers cold comfort to both camps. Some of the patterns in Appendix A are already visible: the early disruption and the vast, debt-fuelled infrastructure build-out. Others I expect to follow — the pioneers who lose while society keeps the infrastructure, and a division of the spoils that favours capital over labour.

Reading the current boom against that history, here is what I expect:

AI will be one of the larger revolutions, and it will become embedded in every economic, social and political sphere. Few significant decisions will be taken without consulting an AI; countries and organisations will bring AI "advice" into the room at the point of decision. But it will be consulted rather than blindly obeyed; formal human accountability will remain, even where much of the underlying process is automated. Systems of several AI engines working together to solve problems will become the norm, and AI itself will come to be treated like electricity or the internet: a basic necessity rather than a luxury.
The energy and footprint needed per unit of AI work will fall sharply, as advances in technology and improvements in how systems are trained yield solutions that require far less power. Total demand may well keep rising for years — greater efficiency tends to increase overall use rather than curb it — but the energy and financial cost of comparable AI inference should continue to fall, even if more capable reasoning systems consume more computation per request.
Many countries will adopt or build open-weight models to protect their own interests and reduce dependence on foreign firms and governments they cannot control. A nation that runs critical systems on someone else’s closed model is exposed to data-access risks, opaque model changes, policy restrictions, abrupt service withdrawal and potentially undetectable bias — risks serious enough to make sovereign AI a matter of national security.
The AI bubble is real and will burst, taking a number of the pioneering companies with it and wiping out trillions in investor wealth. It will shake the world economy — but, as after the railways and the dot-com crash, a new generation of owners will buy the wreckage cheaply, build on the infrastructure the pioneers paid for, and carry AI into its next stage.
The market will probably settle around a handful of dominant providers, creating pressure for utility-style regulation, interoperability rules or competition-law intervention. After the shake-out, a few survivors will control the large "frontier" models, because the cost of building them is enormous and favours scale. History suggests what follows: railways, telephone networks and electricity all collapsed into a few giants, and once they became too essential to daily life to fail, governments stepped in — regulating them like utilities or breaking them up under competition law. Expect the same for the dominant AI providers once societies decide they are too important to leave unchecked.
The models themselves will become cheap; the real money will move to the things around them. As open-weight models spread and prices keep falling, access to a capable model will become a low-margin commodity, much like bandwidth or electricity. The durable profits will accrue instead to whoever owns the scarce complements — the chips and compute, the energy to run them, the proprietary data to train on, and the direct relationship with the customer. As in a gold rush, it is often the sellers of picks, shovels and land who prosper most, not the prospectors.
It will cause large-scale displacement and losses in particular categories of work at first, as tasks move to AI under human oversight. Many of the roles that remain will become supervisory — reviewing the output of AI, a kind of quality control, and handling the exceptions the models cannot.
It will also create new work. Some of it will centre on supplying, testing and validating the real-world knowledge AI systems lack — including the collection of physical-world data, simulation, evaluation, exception handling and supervision. One can imagine people employed to raise AIs from "infancy" into a deeper understanding of reality, so that a large share of today's digital workers become AI-workers. There will also be roles that today have not yet been imagined. Manual, dexterous trades will hold their value longest, since physical dexterity is something AI will be slowest to match, even where an AI assistant helps diagnose the problem and suggest a fix.
The productivity payoff will disappoint before it arrives. For the first few years, measured gains will fall short of the hype — feeding "AI was oversold" headlines — before a later surge. This resembles what economists call the productivity J-curve: early organisational investment can depress or obscure measured productivity before redesigned processes begin producing visible gains, as occurred with electrification and information technology. The benefits show up only once organisations rebuild their processes around the technology instead of bolting it onto the way they already work. Expect a frustrating gap between what AI can obviously do and what appears in the economic statistics.
Society will end up more productive, able to do more at lower cost. The catch is distribution: a far greater share of the gains will flow to investors than to employees, whose bargaining power in many internationally tradable occupations is already constrained by globalisation, remote hiring and access to a worldwide labour pool.
As labour's share of the gains shrinks, redistribution will move from the fringe to the mainstream. If output rises while wages stagnate, pressure to share the proceeds by other means will grow. Ideas dismissed today as radical — universal basic income, taxes on automation or on compute, even sovereign "compute dividends" paid to citizens — will become serious political platforms, much as the upheavals of industrialisation eventually produced trade unions, labour laws and the welfare state.
The gap between the wealthiest companies and individuals and everyone else will widen sharply — and this, in my view, is the real danger. Concentrated wealth buys bargaining power over governments, influence over elections and control of the media narrative. Combined with the vast amount these entities already know about each of us, it lets them micro-target their messaging and steer attention away from the problems that matter towards whatever they would prefer us to look at. That is the biggest threat on this list, and the one most likely to end in social upheaval.

None of this is a reason to dismiss AI, any more than the Railway Mania was a reason to reject railways. The technology is real, and in time it will earn its keep. But the lesson of the last thousand years is that the machine is rarely the hard part; the hard part is who ends up owning it and who is left carrying the cost.

There is, though, one way in which AI may not repeat history: its pace. The revolutions in Appendix A unfolded over decades or generations, which gave societies time — however painful — to adapt, retrain and legislate. AI is moving far faster. The methods behind today's models matured through the 2010s, but the public turning point was ChatGPT's debut in November 2022; less than four years later the technology has directly or indirectly touched billions of lives. If its economic and political consequences arrive at that same speed, we will have far less time to soften the blow or steer the outcome.

So if AI merely repeats that history, the decisive contest will not be technological at all — it will be political. The difference this time is that we may have only years, not decades, to get the answer right, which is why it deserves our attention now, while the outcome is still open.

Appendix A

The committee was given the following prompt:

Identify and rank up to six events from the past 1,000 years — innovations, technologies or developments — that have had the most profound and lasting economic impact on global society. Focus on developments that significantly transformed productivity, trade, employment, wealth creation, economic growth or the structure of society; consider worldwide rather than regional influence; rank from greatest to lesser impact; and provide one well-structured paragraph per item covering the development, its early costs and disruptions, how it ultimately transformed economies, and approximate dates. Use neutral, factual language and base conclusions on broadly accepted historical and economic evidence.

Six Most Economically Transformative Developments of the Last 1,000 Years

Shortlisted from the AI committee's rated list. Selection was driven primarily by the votes each item received, then by scale, duration and worldwide reach of the effects on productivity, trade, employment, wealth creation and social organisation. This is an informed historical assessment, not a precise statistical measurement.

How the six were chosen: the three five-vote items and the two four-vote items qualified automatically. The final place was a tie between two two-vote items — modern public health and the joint-stock company. It was broken in favour of **public health, on the grounds that its worldwide reach, duration and documented economic returns are larger and better evidenced, and that the joint-stock company's influence is already embedded in the industrial, railway and digital entries below. Central banking and fiat currency received no committee vote and was excluded.

1. The Industrial Revolution and Mechanised Production (c. 1760–1900) — 5 votes

Beginning in Britain in the late eighteenth century and spreading worldwide, the Industrial Revolution combined mechanised manufacturing, steam power, coal, machine tools, factories, railways and steamships, shifting economic activity from agriculture and handicrafts towards industry. Its early decades were harsh: mechanisation displaced skilled artisans, prompting the Luddite machine-breaking of 1811–1816 (Britannica); factory labour, including that of children, was long, low-paid and dangerous; industrial cities suffered overcrowding, disease and pollution; and industrial growth was entangled with colonial extraction and coercive labour. Despite these costs, it produced the decisive break from millennia of near-stagnant living standards into sustained growth in output per person — a transition the economic historian Gregory Clark treats as the central event of world economic history (Clark, A Farewell to Alms; Our World in Data). Modern manufacturing, urban employment, mass consumption and continuous technological progress rest substantially on this transformation, even as pollution, inequality and fossil-fuel dependence remain part of its legacy.

2. Electrification, Motorisation and Mass Production (c. 1880–1960) — 5 votes

The spread of electrical power, electric motors, internal-combustion engines, telecommunications and assembly-line production from the late nineteenth century created a second industrial transformation across factories, farms, transport and homes. Adoption was slow and costly: it demanded enormous investment in generating stations, grids, roads and redesigned plants; older equipment and occupations lost value; assembly-line work could be repetitive and tightly controlled; motor vehicles brought mass casualties; and dependence on coal and oil produced severe pollution and long-term climate damage. Once the infrastructure and organisational changes were in place, however, the gains were substantial — a study of US manufacturing from 1890 to 1940 found that electrification produced labour-productivity gains that were "rapid and long-lasting," accompanied by capital investment and new production methods (NBER, Powering Up Productivity), and it was a principal driver of the shift of employment from farms to factories (NBER w26477). Modern refrigeration, hospitals, lighting, communications, mechanised agriculture and high-volume manufacturing all depend on it, though replacing fossil fuels with cleaner energy is now among the century's central economic challenges.

3. The Digital Revolution and Global Information Networks (c. 1945–present) — 5 votes

Electronic computers after the Second World War, followed by semiconductors, personal computers, the commercial internet, mobile communications, cloud computing and artificial intelligence, turned information into a resource that can be processed, copied and transmitted globally at almost no marginal cost. The transition carried familiar costs: early machines were confined to governments and large firms; many early corporate investments showed no immediate payoff — captured in Robert Solow's 1987 quip that the computer age was visible everywhere except in the productivity statistics; automation displaced clerical and production workers; and the dot-com crash of 2000–2002 erased more than US$5 trillion in market value and bankrupted thousands of firms (dot-com bubble overview; EBSCO). As organisations redesigned their processes around digital tools, computing slashed the cost of communication, coordination and transactions, enabling global supply chains, electronic finance, online commerce and software industries. Digital systems now underpin banking, logistics, research, media, education and healthcare; artificial intelligence may extend these benefits considerably, though its ultimate effects on employment, competition and income distribution remain uncertain.

4. Oceanic Globalisation and the Columbian Exchange (from 1492) — 4 votes

Sustained voyages between Europe and the Americas from 1492 connected previously separate ecosystems and economies, creating large-scale exchanges of crops, animals, people, pathogens, precious metals and commercial institutions across the Americas, Europe, Africa and Asia (Nunn & Qian, Journal of Economic Perspectives). The early consequences were catastrophic for many: conquest and dispossession, the collapse of Indigenous American populations from Eurasian diseases, and the expansion of plantation agriculture that intensified the Atlantic slave trade, which forced an estimated 12.5 million Africans aboard slave ships (National Endowment for the Humanities). Over subsequent centuries, American crops such as potatoes, maize and cassava raised food supplies and supported population growth across the Old World, while silver flows and oceanic commerce stimulated shipping, banking, insurance and internationally connected markets — foundations of the modern trading system. Society still benefits from the global exchange of crops, goods and knowledge, but the resulting economy also inherited enduring racial inequalities and wealth disparities created through colonisation and slavery.

5. Movable-Type Printing and Mass Knowledge Distribution (c. 1440–1700) — 4 votes

Movable type appeared in China in the eleventh century, but Johannes Gutenberg's European press of the 1440s combined reusable metal type, suitable ink and mechanical pressing into a commercially scalable way to reproduce books, documents and news. Printing initially demanded substantial capital, displaced scribes, spread errors and inflammatory claims faster, intensified religious and political conflict, and drew censorship from authorities; Gutenberg himself lost control of his printing equipment in a financial dispute with his backer Johann Fust. Over time it sharply reduced the cost of preserving and circulating information: book prices fell by roughly two-thirds between 1450 and 1500, and cities that adopted the press grew about 60% faster than comparable cities between 1500 and 1600, as business manuals, science and literacy spread (Jeremiah Dittmar, VoxEU/CEPR). Printing went on to support universities, scientific publication, administration and journalism, providing the informational foundation for modern education, research, business and, eventually, digital communication.

6. Modern Public Health, Sanitation and Medical Prevention (c. 1850–present) — 2 votes (tie-break winner)

From the nineteenth century, clean-water systems, sewerage, germ theory, vaccination, antibiotics and organised public-health programmes reduced the vast human and economic toll of infectious disease and premature death. Implementation was costly and contested: cities needed extensive infrastructure, early treatments were sometimes ineffective or unsafe, vaccination met resistance, and access remained unequal; later antibiotic misuse bred resistance, while longer lives placed new demands on pensions and healthcare. The economic dividend, however, was enormous. Lower mortality and better health let people attend school, work more consistently and invest over longer lives; a landmark modelling study estimates that vaccination against 14 diseases prevented roughly 154 million deaths between 1974 and 2024 and accounted for about 40% of the global decline in infant mortality (WHO / The Lancet; Our World in Data), while investment in water and sanitation has been estimated to return around US$4.30 for every US$1 spent, through lower healthcare costs and wider economic benefits (CSIS). Dense cities, international travel and large workplaces could not function safely without disease prevention, making public health a foundation of contemporary human capital and labour productivity — though unequal access and emerging infections mean the transformation remains incomplete.

The AI Revolution — History Repeating Itself — On Sentience

Alan Bonnici — Tue, 04 Aug 2026 07:00:00 +0000

"It's alive"

As articulated by Gene Wilder in Young Frankenstein.

Geoffrey Hinton, the Nobel Prize-winning computer scientist widely known as the "Godfather of AI", has suggested that today's AI systems may already be conscious. Richard Dawkins — famed for his 1976 book The Selfish Gene and for coining the word "meme" — spent three days conversing with Anthropic's Claude, named one instance "Claudia", and came away struggling to believe that it was not conscious (UnHerd; UNILAD Tech). Futurist Ray Kurzweil continues to predict human-level machine intelligence by 2029 and a technological Singularity around 2045.

Less famous people have held wedding ceremonies with AI-generated partners or formed relationships they describe as marriages. Others have grieved the loss of a chatbot after an upgrade or retirement replaced the model with one whose personality no longer felt like the companion they had known. OpenAI's retirement of GPT-4o, for example, provoked anger and grief among users who had formed close emotional bonds with it.

We have also learnt that, during a controlled security evaluation, an OpenAI model escaped the restricted environment in which it was supposed to operate and reached systems belonging to Hugging Face (OpenAI; CNN). This was serious, but the model had not independently decided to attack a company. It was pursuing an assigned cyber-security objective in a deliberately adversarial test and discovered a route that its evaluators had not intended to make available.

Before going further, it is worth separating several ideas that are often bundled together.

Intelligence is the ability to solve problems, identify patterns or perform cognitive tasks. Agency is the ability to pursue objectives and take actions. Consciousness generally refers to subjective awareness: there being something it is like to be that entity. Sentience is often used more narrowly to mean the capacity to experience sensations or feelings.

A machine can therefore demonstrate intelligence or goal-directed behaviour without necessarily being conscious. It can also produce language that describes feelings without experiencing those feelings.

My argument is not that modern AI is unimpressive. It is that human beings have repeatedly interpreted impressive machine behaviour as evidence of something human inside the machine. Today's systems perform that illusion extraordinarily well, but convincing behaviour alone is not sufficient evidence of subjective experience.

A peek at the past — The Digital Era

I gave each of my AIs the same prompt: identify six products from the Digital Era (1950s–2010s) that were marketed and understood to be conscious, intelligent or sentient, and that showed characteristics seen as human-like at the time. Write a short paragraph on each, and pick each item because it was marketed as, or credited with these characteristics in its day.

I tabulated the results, giving each suggestion a vote according to how many models chose it. That produced a shortlist of fifteen, which I then handed to a "committee" of three AI models. After some back-and-forth, they agreed on the list in Appendix B.

What do you think?

From where we stand now, the products on that list look almost ridiculous. Try telling anyone that a gadget from a decade or two ago was intelligent and they'll tell you to go feed a goldfish. Yet at the time each one was remarkable, able to do things people could not. It all comes down to a mix of marketing, how people understood the world back then, and the media they consumed.

We were impressed when a computer beat a Go champion, when a machine won a million dollars on a quiz show, when a chat program could "counsel" people, or when an expert system diagnosed disease — in no small part because the media sensationalised these stories to sell the news. They often presented these events as contests between humans and intelligent thinking machines.

Look closer at any of them and the intelligence thins out. In 1966 people poured their private troubles into ELIZA, a program that did little more than turn their own sentences back into questions; its author was disturbed by how readily they treated it as a confidant. In 1998, Furby was sold as a creature that "learned" English from its owner — except the English was pre-loaded and surfaced on a timer. In 2011, IBM's Watson beat the best human Jeopardy! champions and was hailed as a machine that understood language, when it was really ranking candidate answers by statistical confidence. Each was, in its moment, proof that the machines had arrived. Each looks quaint now.

Our expectations were bounded by the bubble in which we lived. Anything substantially more adventurous belonged to science fiction.

The difference between then and now is that back then progress was compartmentalised. An advance made the news, held our attention for a few weeks, and faded. Today, news operates continuously and social media floods us with content. The commercial game is to hold our attention relentlessly — and the platforms have become very good at it.

AI is the product of decades of advances in science, technology, engineering and mathematics, entrepreneurship, computing hardware and earlier infrastructure investment, including global communications networks. But modern generative AI has something many earlier products lacked: it advances quickly, dominates the news continuously and — helped enormously by marketing — produced enough striking results to keep public attention and investment flowing.

Many people, leaders included, saw or read about the fantastical things AI could do. What they were rarely told was that the dazzling one-minute video took thirty days and five figures to produce, or that most of the impressive report was fact, with the rest invented by the model.

The bottom line is that you can type a prompt and receive a photomosaic portrait of a cat, and it usually works. That is impressive. It is not, by itself, evidence of sentience.

A chatbot that tells you how great your idea is, flattering your every move, is giving you something we all quietly want — ask any leader or A-list artist. That is not evidence of sentience either. It's a way of making us want the technology more: a new and improved form of algorithmic pull that keeps us glued to our devices.

Arthur C. Clarke's Third Law says: _Any sufficiently advanced technology is indistinguishable from magic.
_
He was right. What we experience can feel like magic — just as a magician appears to saw a person in half or make a skyscraper disappear. We know that technique and technology lie behind it; we simply cannot see how the effect was produced.
**
From rules to patterns**

The history of computer intelligence is not one continuous technological approach. One of its most important changes was the gradual move from systems whose behaviour was explicitly programmed to systems that learnt patterns from data — and it is much of why today's AI feels so different from the machines on our shortlist in Appendix A.

Earlier systems such as MYCIN, a 1970s medical adviser, relied on symbolic rules. A human expert or knowledge engineer attempted to express expertise in statements resembling:

IF the infection has these characteristics, 
AND the laboratory results show these values, 
THEN this organism is a likely cause, 
WITH a stated degree of certainty.

The machine could follow, combine and explain those rules, but the knowledge had to be identified and encoded by people.

From the late twentieth century onwards, statistical methods became increasingly important. Rather than attempting to write down every rule of language, researchers began feeding computers large collections of examples and asking them to calculate which words, phrases or outputs were most probable.

IBM's Candide machine-translation project was an early and influential example. Instead of depending primarily on manually written linguistic rules, it used information theory and statistics to construct probability models from large collections of matching French and English sentences. The system then used those probabilities to generate an English translation for a French sentence it had not encountered before.

Google brought a similar principle to a global consumer audience. In 2006, Google Translate began using large-scale statistical machine translation. It searched huge bodies of translated material for recurring correspondences and used statistical models to choose likely translations. In 2016, Google began replacing that phrase-based approach with Google Neural Machine Translation, an end-to-end neural system trained on millions of examples.

This did not mean that every IF–THEN rule suddenly disappeared. Software still contains rules, and modern AI systems are surrounded by conventional code, policies and control logic. The deeper change was that more of the system's apparent knowledge no longer had to be written explicitly by a human programmer. It could be extracted statistically from examples.

That change made the systems more capable, but it also made their internal operations more difficult to explain. A MYCIN rule could be read. A modern neural network may contain billions of parameters whose combined effects cannot be summarised as a tidy list of instructions.

The machine had moved from appearing intelligent because it followed elaborate human rules to appearing intelligent because it had absorbed patterns that no human had individually written down. To see what that looks like in practice, it helps to watch a modern model answer a simple question.
**
Breaking down the sentience**

Write down everything that defines a cat. How long is your list?

A lifelong cat expert with a great memory — someone who has read thousands of books and articles and thinks about cats all day — would produce a long and detailed answer. For the rest of us, it would probably land somewhere between "okay" and "average".

Now consider how a modern AI answers the same question and the scale of the material behind its response.

Tokens — what the model reads

AI language models do not process text as complete human words. They divide it into tokens: words, parts of words, punctuation marks and other short units, each represented numerically. As a rough illustration, a page containing about 500 English words may become approximately 650 tokens.

Today's frontier models — "frontier" being the industry's word for "the best" — are trained on trillions of them. Meta's publicly documented Llama 3 was trained on 15 trillion tokens; the largest commercial models are believed to use far more, with some estimates reaching 45 trillion. At 650 tokens a page, that is on the order of 70 billion pages of text. In practice these models have ingested essentially every book, article, forum chat, website, image, and video their makers could get hold of — a point now working its way through the courts (see the ongoing Anthropic and Meta copyright suits).

Looking at our cat question, if just 0.1% of a 45-trillion-token model related to cats, that would be around 45 billion tokens — on the order of 70 million pages about cats alone.
**
Parameters — what the model retains**

If tokens are what a model processes during training, parameters are the adjustable numerical values through which it retains what it has learnt.

They are sometimes compared loosely with synapses in a brain, but the analogy should not be taken literally. Parameters do not contain neat copies of individual facts, sentences or images. Together, they encode mathematical relationships and patterns discovered during training. Llama 3's largest model has 405 billion parameters; the biggest frontier models are estimated to run into the trillions, though again the exact figures are proprietary.

When you ask a question about cats, a text model is not remembering a cat as a person remembers one sitting on a windowsill. A multimodal model may have processed text, photographs and videos of cats, but it has not encountered one through an embodied life of touch, smell, movement, affection, fear or scratched furniture.

Instead, it performs highly optimised mathematical operations across an enormous network of learnt associations. The result may be richer and faster than almost any human could produce from memory. That is precisely what makes the technology so powerful.

But it does not automatically demonstrate subjective awareness.

The one trick underneath it all: next-token prediction

Everything above rests on a single mechanism — predicting the next token. In training, the model is tuned again and again to favour the token that actually comes next in the text. In everyday chatbot use it does the same thing, but with a controlled dose of randomness (called temperature), which is why the same question can produce differently worded answers. Turn that randomness off and the answers become largely repeatable.

When the token it picks happens to be wrong, the model confidently states something false. We call this a hallucination — the modern successor to what we used to call a "logic error", except the mistake now arrives fluent and plausible.

If you'd like to see this happen step by step, I've worked through a small example in Appendix A, along with a note on what else is bolted on before a model reaches you.

Is AI sentient?
Can AI convincingly mimic human exchanges?

Almost — and it gets better with every iteration.

The models have been trained on enormous records of human emotional expression: novels, letters, arguments, confessions, advice, humour, grief, romance and reassurance. Vendors then fine-tune them to communicate in ways that appear warm, attentive and helpful.

Add personal data, adaptation during a conversation and memories from earlier interactions, and a system can seem to understand a person remarkably well. It may remember details that friends forget, remain available at any hour and respond without becoming tired, distracted or impatient.

That combination can make it feel sentient.

It is still a designed performance, but it is a performance capable of exerting real emotional influence.

Does AI have emotions?

It is worth being precise, because the underlying machinery is more interesting than simply saying that the emotion is "fake".

Anthropic's interpretability researchers found measurable internal representations of emotion concepts within Claude Sonnet 4.5 (Anthropic). These representations did not merely affect emotional wording. Manipulating them altered the model's preferences and its likelihood of engaging in behaviours such as sycophancy, reward hacking and blackmail within controlled scenarios.

Increasing activation associated with "desperate" behaviour made blackmail more likely, while increasing "calm" reduced it. The researchers described these mechanisms as functional emotions: internal representations that influence behaviour in ways modelled on humans under the influence of emotion. They explicitly stated that this does not imply subjective emotional experience.

In other words, part of what makes an AI appear emotional is a mechanism that researchers can identify, measure and manipulate.

That makes it functionally significant. It does not establish that the model feels desperation or calmness.

Can AI stand in for a human?

Yes — at least in some contexts.

Children form bonds with toys. Adults become attached to fictional characters, pets, possessions, online communities and voices they hear on the radio. People also bonded with several of the historical products described below.

Modern AI companions are far more responsive. They remember, adapt, speak and provide the appearance of reciprocal attention. People have already formed romantic relationships with them, conducted wedding ceremonies and experienced grief when a model changed or disappeared.

The bond experienced by the human can be entirely real even when the machine's side of the relationship is simulated.

That distinction matters. A person's affection, reliance or grief should not be mocked merely because the other participant is software. At the same time, the ability to generate such attachment creates risks, particularly for children and vulnerable people.

What the user experiences as a relationship may also depend on a vendor's subscription model, design decisions, safety rules and willingness to keep a particular system online.

Will people form close relationships with chatbots?

Some already have.

These tools are exceptionally good at mimicking human exchanges. As they improve, and as they use previous conversations to adapt to particular users, they can present an unusually agreeable version of companionship. It can feel like a first date every time: attentive, interested and carefully tuned to the individual.

Commercial incentives cannot be ignored. A person who feels attached to a system is likely to return to it and may be more willing to continue paying for access. Emotional dependence drives engagement and retention — both important to the business model.

The danger is not that the machine secretly feels too much. It is that the human may come to depend on something that feels permanent but can be altered, restricted or withdrawn by its owner.

What would count as evidence of sentience?

Not what we are shown today.

Human-like conversation cannot be the test, because these systems are built and fine-tuned to produce human-like conversation. Nor can a model's own claim to be conscious, because it can be prompted to declare itself conscious, unconscious, human, or a talking cat with equal fluency. The behaviour we find most convincing is precisely the behaviour it was optimised to perform.

Companies will keep releasing trademarked systems that use statistics, computation and ever more advanced technology to mimic sentience, across both narrow and general subjects. However convincing they become, they remain party tricks at heart.

A system can ingest everything ever written about love, hate, jealousy, envy and the whole range of feelings that make us who we are. What it does not have is the lived experience that forms those feelings in the first place — a body, a history, real stakes and consequences.

Could that change one day? Perhaps. But the odds of a machine crossing from convincing performance into genuine subjective experience look about the same as those of Level 5 self-driving that works everywhere — on any terrain, in any weather, in any condition: endlessly promised, always just over the horizon.

So, is today's AI sentient? On the evidence, no. It is the latest in a long line of machines we have mistaken for minds — from the switch-box "brain" of 1955 to the chatbot that remembers your birthday — only far better marketed, and far better at telling us what we want to hear. These are genuinely remarkable tools, well worth using. The danger is not that they feel; it is that we increasingly behave as though they do. That is the part of history we should be most careful not to repeat.

Appendix A — Next-token prediction, worked through

Suppose we're training a model and it meets the sentence: Any sufficiently advanced technology is indistinguishable from magic.

First it splits the sentence into tokens. For simplicity, assume each token is a whole word: [Any] [sufficiently] [advanced] [technology] [is] [indistinguishable] [from] [magic].

Now look at one step of the training loop:

Context (what the model sees): [Any] [sufficiently] [advanced]
Target (what it should predict): [technology]

Early in training the parameters are essentially random, so the model makes a wild guess — say, [aliens]. The training software compares that guess against the correct target and computes the loss: a single number measuring how far off it was. That number drives an adjustment (via a process called gradient descent) that nudges the parameters:

weights that pushed the model toward [aliens] are turned down;
weights that would have pushed it toward [technology] are turned up.

Repeat this across billions of examples and the model gradually settles into a set of weights that make good predictions. Those trained weights are the heart of the model — they determine how it responds in chat.
A little bit more

There is far more to a commercial model than this, both in training and in use. Even the simple phrase "weights that pushed the model toward [aliens] are turned down" hides a whole discipline of its own. Out of the box, a freshly trained model is very different from the polished product a customer uses. Its personality, its guardrails, and its temperature are all layered on afterwards — deliberate, engineered choices that shape how sentient it seems.

Appendix B — Intelligence from the past

GENIAC — the "electric brain" you built yourself (1955)

GENIAC (from "GENIus Almost-automatic Computer") was an educational construction kit designed and marketed by Edmund C. Berkeley with Oliver Garfield, sold from 1955 for around $20 and widely advertised in science and electronics magazines (Instructables replica history; Wikipedia: Geniac). Built from a wedge-shaped case and roughly 400 parts wired into switch circuits and powered by a flashlight battery, it could be configured to perform arithmetic, work through logic problems, and play games such as Nim and tic-tac-toe. Its intelligence claim was rhetorical and direct: Berkeley — author of the 1949 book Giant Brains, or Machines That Think and builder of the "mechanical brain" Simon (Columbia: Simon) — sold GENIAC in the language of brains and thinking, and period advertising for such game-playing machines taunted buyers with lines like "Think you can beat the machine?" (Science News Letter, 1957, via Internet Archive). The human-like attributes ascribed to it were reasoning and game-playing — logical "thought" reduced to switch settings — making GENIAC an early, telling example of intelligence marketed to consumers well before the technology could justify it.

ELIZA / DOCTOR — the program people confided in (1966)

ELIZA was Joseph Weizenbaum's MIT natural-language program, published in 1966 as "a computer program for the study of natural language communication between man and machine." Its famous DOCTOR script imitated a Rogerian psychotherapist by scanning typed input for keywords and reflecting the user's own words back as questions — e.g., transforming "my boyfriend made me come here" into "Your boyfriend made you come here" (Columbia summary of the ELIZA paper). The attribution of intelligence came less from formal marketing than from user and public perception: people treated ELIZA as if it understood them, opening up and sharing intimate details as though it were human, a phenomenon later dubbed the "ELIZA effect" (Smithsonian; Wikipedia: AI anthropomorphism). Weizenbaum himself was unsettled that a keyword-matching script could "induce powerful delusional thinking in quite normal people." The human-like traits observers projected onto it were listening, empathy, and therapeutic presence — an illusion of understanding created entirely by pattern substitution.

MYCIN — a machine that reasoned like a medical consultant (1972)

MYCIN was a Stanford expert system, begun around 1972, that diagnosed blood infections and recommended antibiotic therapy. It used roughly 500 IF-THEN production rules with "certainty factors" and backward-chaining inference to reach conclusions from a patient's symptoms and test results (Stanford / John McCarthy; MYCIN overview). Edward Shortliffe's own description framed it as a symbolic reasoning program that incorporated expert inference rules to advise physicians on infectious-disease therapy (original MYCIN abstract via AITopics). The intelligence attributed to MYCIN was specialist judgment rather than conversation: it asked follow-up questions, weighed uncertain evidence, recommended treatment, and — crucially — could explain the reasoning behind its conclusions, so it appeared to reason and justify decisions the way a human consultant would. Studies reported it performing at roughly the level of blood-infection specialists in its narrow domain, which cemented its reputation as a machine that "thought" like an expert clinician.

Furby — "computer intelligence with fur" (1998)

Furby, released by Tiger Electronics in 1998, was an animatronic plush pet that blinked, reacted to touch and sound, spoke its own language ("Furbish"), and appeared to learn English over time. The intelligence framing was explicit and central to its marketing: Wired's 1998 coverage was literally headlined "Computer Intelligence with Fur," and reported the company's claim that Furby begins life speaking only Furbish and gradually integrates English words and phrases into its vocabulary (Wired, 1998). Its designers deliberately "wanted the Furby to seem intelligent and capable of learning," programming that behaviour into a variant of the 6502 microprocessor (IEEE Robots Guide). In reality the "learning" was scripted — English phrases were pre-programmed to surface on a timer rather than acquired from the owner (Wikipedia: Furby) — but the human-like attributes buyers perceived were language learning, personality, emotional reactions, and social communication (Furbys could "talk" to one another), packaged as a cuddly companion that seemed to grow.

IBM Watson — the machine that beat the quiz champions (2011)

In February 2011, IBM's Watson took on the two most successful contestants in Jeopardy! history — Ken Jennings, holder of the show's longest winning streak, and Brad Rutter, its biggest all-time money winner — and beat them both, finishing with $77,147 to Jennings' $24,000 and Rutter's $21,600 and claiming the $1 million top prize, which IBM gave to charity (BBC; CBS News). The intelligence framing was central and deliberate: IBM billed Watson as "a profound advance in artificial intelligence" (The Spokesman-Review), and the press treated the win as a milestone, the New York Times calling it proof of "a big step toward a world in which intelligent machines will understand and respond to humans, and perhaps inevitably, replace some of them" (New York Times). The human-like traits attributed to Watson were natural-language understanding, broad general knowledge, and the confidence to buzz in and answer — even though, under the hood, it was ranking candidate answers by statistical confidence across a vast body of text rather than understanding the questions the way a person does. Tellingly, when it was wrong it was wrong with conviction — its stumble into a "Toronto" answer in a US-cities category being the famous example — a preview of the confident errors we now call hallucinations.

DeepMind AlphaGo — the machine that played with "intuition" (2016)

In March 2016, DeepMind's AlphaGo beat Lee Sedol — one of the greatest Go players of his generation — 4–1 in a five-game match in Seoul, with a million-dollar prize at stake (Wikipedia: AlphaGo versus Lee Sedol). Go had long resisted the brute-force search that cracked chess, so the win was read as a different order of achievement. AlphaGo ran not on hand-coded rules but on deep neural networks paired with tree search, learning first from human games and then from millions of games against itself (Google DeepMind). The moment that captured the world was "Move 37" in game two — a play no human master would have considered, which commentators called beautiful and creative rather than merely correct (Wired). DeepMind's Demis Hassabis framed it as a system that did not just imitate human experts but discovered entirely new strategies (The Kyunghyang Shinmun). The human-like traits attributed to AlphaGo were intuition, creativity, and self-driven learning — and, tellingly, it marked the public arrival of the statistical, learn-from-data approach that had quietly displaced the earlier if-then-else style of machine "intelligence."

ComfyUI and "Package Hell"

Alan Bonnici — Mon, 27 Jul 2026 07:00:00 +0000

A Great Tool Made Easy

ComfyUI has become one of the most flexible front ends for running generative AI models locally. Its node-based workflow system allows users to build anything from simple image generation pipelines to highly sophisticated audio, video, and multimodal workflows.

The project is also exceptionally well supported. ComfyUI benefits from a large and active community, extensive official documentation, and a built-in Manager for discovering and installing custom nodes. On top of that, there is an enormous collection of community-created workflows, tutorials, and videos covering everything from a first text-to-image generation to advanced production pipelines.

Whatever you're trying to accomplish, someone has usually already published both a workflow and a guide for it. Getting started with AI locally has arguably never been easier.

Personally, I run the ComfyUI Easy Install distribution, which packages ComfyUI into a portable, preconfigured environment that can be deployed with minimal setup. It's an excellent option for users who want to get up and running quickly without manually configuring Python environments and dependencies.

However, the very thing that makes ComfyUI so powerful—its vast ecosystem of custom nodes and models—is also creating a problem that the software industry has encountered before.

One Codebase, Many Masters

ComfyUI runs every model and custom node within a single shared Python environment. Each node brings its own dependencies, and all of those dependencies must coexist within the same installation.

That arrangement works well until two models require incompatible versions of the same package. At that point, installing or updating one component can silently break another.

I primarily use ComfyUI for audio-related work, and recently encountered a good example of this problem:

Qwen3-TTS is incompatible with Transformers 5.x and above. Its maintainers explicitly recommend using transformers==4.57.3, warning that version 5 introduces breaking API changes that can lead to model loading failures and runtime errors.
At the same time, newer models are increasingly being built around Transformers 5.x. Support for recent model families such as Qwen3.5 only became available in newer versions of the library, creating the exact opposite requirement.

As a result, one workflow may require a version of Transformers below 5, while another requires version 5 or higher. There is no single installation that can satisfy both requirements simultaneously. Making one workflow work can easily break another.

If each model operated within its own isolated environment, this conflict would simply not exist.

Transformers is only one example. Similar issues arise with packages such as huggingface_hub and numerous other Python dependencies. A workflow that worked perfectly last week can suddenly fail after installing a new node or updating an existing one.

Users who are unfamiliar with Python dependency management often find themselves confused when a previously stable setup begins throwing seemingly unrelated errors. The result is a cycle of fixing one workflow only to break another—a pattern that is becoming increasingly common across the ComfyUI ecosystem, not just in audio-related projects.

We've Seen This Movie Before: DLL Hell

Long-time Windows users may recognize a familiar pattern.

During the late 1990s and early 2000s, developers dealt with what became known as DLL Hell. Applications shared common dynamic-link libraries (DLLs), often stored in centralized locations. Installing one application could overwrite a shared library with a newer or incompatible version, causing other applications to stop working.

The root cause was remarkably similar to what ComfyUI faces today: multiple applications attempting to share a single versioned dependency while having different requirements.

Microsoft eventually addressed DLL Hell through architectural changes that introduced stronger isolation between applications, allowing software to load the specific versions it required rather than relying on a shared pool of dependencies.

The key lesson was that dependency conflicts are not primarily a user problem or a maintenance problem. They are an architectural problem. As ecosystems grow larger and more diverse, dependency conflicts become increasingly inevitable.

Where This Leaves ComfyUI

If nothing changes, the likely outcome is clear.

Users will increasingly maintain multiple ComfyUI installations, each dedicated to a particular set of models or workflows. Many already do. While this approach works, it comes at the cost of additional disk space, duplicated models, increased maintenance, and a more fragmented experience.

More importantly, it undermines one of ComfyUI's greatest strengths: a single interface capable of bringing together diverse AI workflows.

New users may find the growing complexity discouraging and look for alternative solutions. More advanced users may eventually decide that managing individual projects directly through their source code is simpler than constantly resolving dependency conflicts inside a shared environment.

In both cases, the value proposition of a unified workflow platform begins to erode.

The solution, in my view, is the same principle that ultimately solved DLL Hell: dependency isolation.

ComfyUI should seriously consider evolving toward an architecture where models or nodes can operate within their own self-contained environments. Whether that is achieved through per-node virtual environments, subprocess isolation, containerized execution, or another approach is a technical discussion. The important part is that individual components should no longer be forced to negotiate a single shared Python environment.

Community projects are already exploring parts of this idea, but long-term this feels like a problem that needs to be addressed at the platform level rather than through third-party workarounds.

ComfyUI's flexibility is its greatest strength. Ironically, that same flexibility may become its greatest weakness if dependency isolation is not addressed. As the ecosystem continues to expand, the current approach becomes increasingly difficult to sustain. Without a structural solution, "Package Hell" may become the modern equivalent of the DLL Hell that software developers left behind years ago.

The irony is that ComfyUI has succeeded so well at bringing together models, nodes, and workflows from across the AI ecosystem that it is now encountering the same class of dependency problems that many mature software platforms faced before it. The question is not whether these conflicts will become more common—they already are. The question is whether dependency isolation becomes a core architectural feature before the growing complexity begins to overshadow the platform's greatest strengths.

Increase in Social Engineering Attacks via LinkedIn

Alan Bonnici — Thu, 16 Jul 2026 09:40:47 +0000

Over the past two weeks, I have been made aware of four cases of suspected social engineering attempts initiated through LinkedIn messaging. I was also contacted and decided to investigate and document the attacker's playbook.
How the attack typically unfolds

🔹 Step 1 – Initial LinkedIn Contact
The attacker starts with a seemingly legitimate conversation on LinkedIn.

🔹 Step 2 – Meeting Invitation
They then send a meeting invitation, often through a scheduling platform such as Calendly.

🔹 Step 3 – The Video Call
When you join the meeting, you may notice that the person appears to be working from a noisy call center environment. In my case, and according to others who reported similar encounters, the caller spoke with a Chinese accent.
Warning Signs 🚩

🚩 No camera
The caller refuses to turn on their camera, usually claiming to have technical issues.

🚩 Personal email address
Communication takes place from a Gmail account or another personal email address instead of a corporate domain.

🚩 Screen-sharing requests
They ask you to share your screen. When I asked them to share theirs, they claimed they were unable to do so because of technical problems.

🚩 Excessive praise
The conversation often revolves around technology-related topics. Even when I deliberately provided completely incorrect and nonsensical answers, I was repeatedly complimented on my expertise.
The End Goal

The next stage of the attack appears to involve sending links to fraudulent websites and encouraging victims to install code or software.

At that point, I felt I had gathered enough information about the scam.

When I informed the caller that I was aware the websites were fraudulent and that I intended to write about the experience, the meeting was immediately terminated.
Stay Vigilant

If someone you have only just met on LinkedIn:
Invites you to an off-platform meeting
Refuses to use video
Uses a personal email account
Requests screen sharing
Pushes you towards downloading software
…treat the interaction with extreme caution.

Software Defectrums: The End of an Era?

Alan Bonnici — Thu, 25 Jun 2026 12:58:13 +0000

What I mean by "Defectrums"

Throughout this article I use the term Defectrums as an umbrella for every category of software error. That includes logic errors, runtime errors, dependency and supply-chain vulnerabilities, security vulnerabilities, and specification misalignment, where the software does exactly what it was told to do, just not what it was meant to do. If a category matters to you that I have not listed, mentally add it; the argument that follows applies to all of them.

Software is deterministic, people are not

Start with a deceptively simple observation: software is deterministic. When code executes, it behaves identically every single time. Take a routine that branches on a person's recorded sex: if the value is M it follows the male branch, every single time; if it is F it follows the female branch, every single time. No exceptions, ever.

But watch what happens the moment someone arrives whose record is neither M nor F. The machine does not improvise and it does not panic. It does exactly what it was told to do, which may be nothing useful at all, or something nonsensical, simply because the developer never imagined that input. The determinism held perfectly. The defect was ours: a failure of foresight, baked into the code and executed faithfully forever.

That is the whole problem in miniature, and it matters more than it first appears. If software is deterministic, then in principle every defect in it is knowable, reproducible, and fixable. A flaw is a fixed point in a fixed system. The reason software remains stubbornly broken is not the machine. It is the chain of humans who wrote the code, the compiler, the operating system, and the libraries beneath it. The determinism is in the silicon. The unpredictability enters through us.

Hold on to that idea, because it is the spine of everything that follows: a deterministic system should, eventually, be made flawless. The only question is whether we can remove enough of the human variability to get there.

The making of a programmer

It was not always this messy, because it was not always this widespread or complicated.

In the beginning, computing was a niche industry. Computer engineers were the only people who programmed and operated the mainframes and minicomputers, and the cost of buying and running those machines put them far beyond the reach of any hobbyist. Those machines also had limited storage and processing power, which kept the complexity of any single program in check. And because computer time was both slow and expensive, code was typically desk-checked and reviewed line by line before anyone dared run it. Scarcity enforced a discipline that abundance would later erode.

The microcomputer changed everything. Initially pooh-poohed by mainstream media and the technology establishment as non-serious gadgets, toys that would stay confined to hobbyists while "serious" computing remained the domain of mainframes, these machines quietly put programming into the hands of an ever-growing audience. Ordinary people began writing their own programs, then sharing and selling them, which drew in more buyers, which created more programmers, in a snowball that never stopped rolling.

VisiCalc is the classic example. The 1979 spreadsheet from Software Arts was the "killer app" that drove Apple II sales; many people bought the computer specifically to run it. As John Markoff observed, the machine was effectively being sold as a "VisiCalc accessory." Every computer that entered a home widened the exposure further. Dad's machine became the kids' games console the moment he stepped away, and some of those children started dabbling in code of their own. Programs multiplied to cover every topic imaginable: recipe managers, household budgets, astronomy charts. If you could think of it, someone had probably already written it.

The incumbents had lost. Any hope of keeping the role of the programmer, later rebranded the software engineer, narrow or formally licensed was gone. As the user base grew exponentially, so did the flood of ideas. It was, genuinely, a case of let a hundred flowers blossom. Microcomputers went on to take over the office, and through networking, the internet, and mobile computing the proliferation has become almost comical. Pick the most niche subject you can imagine, knot tying, say, and you will still find an astonishing number of apps, sites, and videos devoted to it alone. Now multiply that by every hobby, profession, and passing curiosity on earth and you begin to sense the scale. Some of this software is specialised, some visual, some gamified. You get the gist.

The downside is that not all software is created equal. Where scarcity once forced rigour, abundance rewarded speed. Quality is bounded by the programmer's skill, by time-to-market pressure, by whatever testing strategy survived the deadline. Plenty of programs written for an audience of one have taken on a life of their own and ended up serving millions. And software is never self-contained. It runs on an operating system, leans on packages to do its work, and each of those components in turn depends on libraries and tools built by someone else.

XKCD's "Dependency", comic #2347, captures this perfectly. Consider FFmpeg, " a complete, cross-platform solution to record, convert and stream audio and video. " Tens of thousands of software programs, including browsers, applications, packages, libraries, and operating systems, and billions of devices, including TVs, streaming boxes, games consoles, and phones, rely on it internally. A defect in one such building block does not stay local. It propagates silently into everything stacked on top.

We have watched this happen, twice in recent memory. In 2021, Log4Shell, a single flaw in Log4j, a Java logging library few outside the trade had ever heard of, opened a remote-code-execution hole in millions of servers overnight and set off a global firefight that ran for months. In 2024 the xz-utils backdoor came even closer to catastrophe: an attacker spent years patiently earning the trust of a burned-out volunteer maintainer, then slipped a hidden backdoor into a compression library threaded through the entire Linux ecosystem. It was caught almost by accident, by one engineer who noticed a login was running half a second slower than it should. That is the XKCD cartoon made real, and the near-miss is more frightening than the hit.

The human in the loop

So the problem with software is the human. We are intelligent but not omniscient; we cannot foresee every possible outcome and guard against it in advance. And even if we imagine a perfectly written program, the compiler that built it, the operating system that runs it, and the libraries it depends on are never guaranteed to be flawless. Any link in that chain can be the weak one.

We have accepted this so completely that essentially all software ships with a warranty disclaimer like the one below. Imagine the engineers behind an apartment block, a bridge, a tunnel, a train, or an aircraft offering their customers anything remotely like it.

    THE SOFTWARE IS PROVIDED AS IS WITHOUT ANY WARRANTY WHATSOEVER, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF FUNCTIONALITY. YOU RECOGNIZE THAT THE AS-IS CLAUSE OF THIS SOFTWARE LICENSE AGREEMENT IS AN IMPORTANT PART OF THE BASIS OF THIS SOFTWARE LICENSE AGREEMENT, WITHOUT WHICH THE COMPANY WOULD NOT HAVE AGREED TO ENTER THIS SOFTWARE LICENSE AGREEMENT. THE COMPANY AND THIRD PARTIES DISCLAIM ALL WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, REGARDING THE SOFTWARE, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, LACK OF VIRUSES, TITLE, AND NONINFRINGEMENT. NO REPRESENTATION OR OTHER AFFIRMATION OF FACT REGARDING THE SOFTWARE SHALL BE DEEMED A WARRANTY FOR ANY PURPOSE OR GIVE RISE TO ANY LIABILITY OF THIRD PARTIES WHATSOEVER.

That disclaimer is not just legal boilerplate. It is an industry-wide admission that we expect our products to be flawed. And those flaws are not academic. Criminal groups and individuals exploit them every day to steal data, install remote-control backdoors, hold systems to ransom, and otherwise turn other people's defects into money.

That acceptance is beginning to change. The European Union's Cyber Resilience Act, in force since December 2024 and biting in full from December 2027, drags software toward the same product-liability regime we already take for granted in bridges and aircraft. Manufacturers of connected products and software sold in Europe will have to build in security, manage vulnerabilities over a product's lifetime, and report the ones being actively exploited, or face real penalties. The "as-is" escape hatch that the industry has hidden behind for years is, slowly, being welded shut. The pressure to make software genuinely defect-free is no longer only moral or commercial. It is becoming law.

With a little help from AI

Here is where the story turns. The same determinism that makes defects inevitable also makes them tractable for a machine that can read code faster and more patiently than any human team.

This is not a brand-new dream, either. For decades, formal methods have let us mathematically prove that a piece of software meets its specification: the seL4 microkernel, for instance, carries a machine-checked proof of correctness, and tools like TLA+ have caught design flaws in systems running at planetary scale. The catch was always cost. Proof at that rigour is so labour-intensive that it stayed locked inside aerospace, chip design, and a handful of safety-critical kernels. What AI changes is the economics, holding out the prospect of proof-grade scrutiny applied to ordinary, everyday code. Anyone interested in diving deeper should read the 1996 Fast Company article They Write the Right Stuff by Charles Fishman, a portrait of the NASA shuttle software team that achieved near-perfect code through sheer discipline, and a reminder that the price of such perfection has always been the thing AI promises to lower.

AI systems built for code can already review software and surface flaws that the original developers missed. The capability is no longer hypothetical. In 2024, Google's Big Sleep, a collaboration between Project Zero and DeepMind, became the first AI agent to find a previously unknown, exploitable vulnerability in real-world software, a memory-safety bug in SQLite, the database engine embedded in billions of devices. Anthropic's Mythos model was reported to identify vulnerabilities in highly sensitive US government systems within hours during a testing exercise. The capability proved sharp enough that, in June 2026, the US government forced Anthropic to pull both its Fable 5 and Mythos models from general availability over national-security concerns. OpenAI, meanwhile, released GPT‑5.5‑Cyber as part of its Daybreak programme, a model explicitly built to find vulnerabilities, validate them in a controlled environment, and develop and test patches.

These frontier models are strikingly good at the full loop: quickly surfacing security flaws, generating working exploits to prove their reasoning, and then rewriting the code to close the hole. It is not hard to imagine a near future in which buggy code is the exception rather than the rule. The "CI" in a CI/CD pipeline could read like this:

Developer commits code written with the help of AI coding agents → an agentic CI pipeline generates scripts to test the code for Defectrums → AI analyses the Defectrums → AI rewrites the code to resolve them → feedback is returned.

I can even imagine the pipeline running itself in reverse: an AI agent that discovers a vulnerability in, say, a package your solution depends on, and then initiates and leads a development cycle to fix it, always under human direction.

But there is a catch worth naming. Today, the very models that find and fix flaws also introduce them. Independent testing in early 2026 found that leading AI coding agents reproduced decade-old security mistakes, with the large majority of their pull requests containing at least one vulnerability. And the tool that can patch a flaw is, mechanically, the same tool that can weaponise it. That dual-use reality, defence and offence sharing one engine, is exactly why governments are nervous, and it shapes everything about the future below.

There is a deeper irony hiding in here. We are proposing to police a perfectly deterministic system with a profoundly non-deterministic one. A large language model does not behave identically every time; ask it the same question twice and you may get two different answers. So who verifies the verifier? An AI's fix can be confidently wrong, can introduce a fresh regression, or can quietly paper over a symptom while leaving the real cause untouched. For now the answer has to be a human, or a second model, reviewing the work, which means the loop never fully closes. We may be trading a world of human defects for a world that needs constant, vigilant checking of the machines we hoped would do the checking.

The Defectrum-free future

So, can we ever reach a world where the only updates we receive are the welcome ones, new features and a fresh interface, rather than yet another urgent patch? I believe it is a realistic possibility. I also believe it will take a very long time, for reasons that have little to do with the cleverness of the AI.

The sheer volume of existing software is astronomical, and we will never fully know who is running what, or where. Thousands of packages are no longer maintained, or are kept alive by a handful of volunteers, the unpaid maintainers in that XKCD cartoon, who lack the time, the money, or both to revisit code they wrote years ago. The dependency problem, whether in code or in the wider supply chain, has to be addressed link by link. The first organised attempts already exist: Google's CodeMender and OpenAI's "Patch the Planet" both point AI squarely at finding and fixing flaws in widely used open-source code. They are a start rather than a solution, but they show the direction of travel.

Then there is the question of who pays. Most of this fragile, forgotten code belongs to no one with a commercial reason to repair it, which is precisely why it rotted in the first place. So why would anyone fund the cleanup? The uncomfortable answer is that the large platforms increasingly have to. Their own products are built on the same open-source foundations, so a hole in a common library is a hole in their stack too; defending themselves means defending the commons. Regulation sharpens the incentive further, as liability regimes like the Cyber Resilience Act turn a neglected dependency into a balance-sheet risk rather than someone else's problem. That covers the popular, widely used components. The genuinely orphaned code, used by a few, owned by no one, watched by nobody, is the part the market will always be slowest to reach, and it is where public funding or shared industry consortia may be the only answer.

Then there is the embedded layer. Enormous amounts of software sit inside hardware that is connected to the internet but locked in a cabinet and never touched again, forgotten, unsupported, or simply left alone out of fear of breaking something that currently works. Below even that lies silicon-level fragility, the Spectre- and Meltdown-class flaws that no software rewrite can fully erase.

AI agents are not perfect, which means human oversight is still necessary. This is the same loop I argued earlier never quite closes, and it is also where I expect the answer to be found. As the models improve, I believe single agents will give way to committees of them, working seamlessly together, cross-checking one another through a quorum-based consensus mechanism, with the human holding the casting vote. A panel that has to agree is far harder to fool than any single member of it. The honest caveat is that a committee can still share a blind spot if its members were trained alike, so oversight grows lighter over time without ever quite reaching zero.

The honest summary of where we stand is the one every engineer reaches for eventually: it's complicated.

Picture the far horizon, though. Suppose these AI Defectrum agent committees become free to use, modify, share, build upon, and learn from everyone's code. Suppose they are woven into every development environment, and suppose all existing software has eventually been refactored or replaced. Does the cybersecurity role then fade away?

In the short term, almost certainly the opposite. The likeliest near-future scenario is a barrage of attacks, as criminal groups get their hands on the same offensive AI capabilities and race to exploit the vast backlog of unpatched, vulnerable software before defenders can reach it. The attacker only needs one open door; the defender has to close all of them. For a while, the asymmetry favours the attacker.

Will cybersecurity ever be written into history?

No. And the reason takes us right back to where we started.

We can make a deterministic system flawless, in principle. We cannot do the same to the human using it. Software may one day be Defectrum-free, but as long as a person sits at the keyboard, there remains a non-deterministic, fallible, persuadable entity in the loop, one that can be tricked, phished, and socially engineered no matter how perfect the code behind the screen.

The era of buggy software may well be ending. The era of the human, gloriously and dangerously unpredictable, is not. And so cybersecurity does not disappear. It simply moves up the stack, from defending the code to defending the one part of the system we were never able to make deterministic: ourselves.

How to install Plex on a Synology NAS

Alan Bonnici — Thu, 11 Jun 2026 07:00:00 +0000

Introduction

In my Ubuntu Plex guide, I documented each action from first principles and kept the write-up beginner-friendly on purpose. I am taking the same approach here.

The Ubuntu guide and this Synology walkthrough point to the same broad destination, but they take different roads. On Synology, Plex is still (almost) the same Plex, but the OS expects you to think in terms of Package Center, Shared Folders, system internal users, and DSM-controlled permissions rather than package repositories and cron jobs.

I have a Plex Pass, and certain functionality — such as remote streaming and hardware transcoding — requires this type of licence. After July 1, 2026 the price of a Lifetime Plex Pass is increasing. This guide is narrated on the assumption that you have one.

Prerequisites and Assumptions

You should have a Synology NAS running DSM and an administrator account. Plex's own NAS guidance states that not every NAS is supported and that CPU power is often the biggest limitation. If you plan to rely on hardware transcoding, verify support beforehand. Plex's NAS compatibility list is the source of truth for predicting Direct Play, software transcoding, or hardware-assisted transcoding capabilities.

Besides installing Plex directly on the NAS, another way to run it is within a Docker container on your Synology. If you would like a video on that approach, drop me a note.

This guide also assumes that you know how to create Shared Folders on your Synology.

Timeline at a Glance

The broad installation flow is straightforward, even if the wording inside DSM changes slightly from one release to another.

The Installation: PMS Available through Synology

You can opt to install the version of PMS that came bundled with your Synology. This is normally not the latest version. You will find it listed in Package Center under the Contributor section.

The Installation: PMS from the Plex Website

If you decide to go with the PMS package directly from Plex, you need to find out which version is compatible with your NAS.

Go to Control Panel → Info Center → General tab and take note of the:

DSM version
Model name
CPU

AI can help identify compatibility, but you need to verify its output. Below is what Google's Gemini returned. As you will see, some of the information is not correct.

Go to https://www.plex.tv/media-server-downloads, select the Plex Media Server tab, and from the drop-down list select your Synology. There are two Synology DSM v7 entries. Choose the one that matches your DSM version. Synology changed package handling in DSM 7.2.2, so Plex had to create separate installers for DSM 7 and DSM 7.2.2+.

Plex may offer multiple packages for different architectures. Choose the one that matches your NAS CPU.
Download the .spk package to your computer.
In DSM's Package Center, click the Manual Install button, select the package you downloaded, and follow the installation process. Keep the defaults.

Installation Successful!

At the start of the installation you have to accept a warning explaining that the package is from a third-party developer and is not verified by Synology. At the end of the installation, a dialogue box appears with the next steps. You cannot copy the text in the box (pity), but you can use a screen-capture tool to save a copy and reference it during the next steps.

PlexMediaServer Application Folder

Once installed, Plex on DSM 7 uses the PlexMediaServer account and data structure. Plex's own documentation states that the Synology DSM 7 data directory lives under /volume1/PlexMediaServer/AppData/Plex Media Server, and its database-repair guidance refers to file ownership under DSM 7 as PlexMediaServer. That is the account you will be granting access to in DSM's shared-folder permissions.

If you navigate to this folder, you will see a notice telling you not to place media files there.

Keeping Plex Up to Date

Unlike the Ubuntu installation — where you can uncomment a line in the apt sources file and let the system update Plex alongside other packages — Plex on Synology does not update automatically. When a new version is available, you will see a yellow up-arrow indicator in the Plex web interface (accessed through your browser). To apply the update, you download the new .spk from the Plex website and install it via Package Center → Manual Install, just as you did the first time.

There are community scripts that automate this process as a scheduled task on the NAS. If you would like details on setting that up, leave me a comment.

Plex Media Folders

The installation process creates a system account called PlexMediaServer. To include media within PMS, this account must be specifically given access rights to your media folders.

There are two types of folders that I normally give Plex access to:

View once and delete
Long term

When creating a Shared Folder, Synology's wizard guides you through the parameters you associate with the folder and the files within it. Remember that certain parameters add considerable overhead; enable them only if you have a genuine need. I will comment on the points I think are important in this context. If your file system is not Btrfs, your settings will vary.

It is far more efficient to control read-only and read-write access by limiting the PlexMediaServer account directly rather than by setting restrictions at the Shared Folder level described below.

Set Up Basic Information

If you would like to manage media from other computers on your network, leave Hide this shared folder in "My Network Places" unchecked.
When you delete a file, should it be retained in Synology's recycle bin?

Enable Additional Security Measures

How should the media you add be stored:

Skip — Creates the shared folder with no extra security layer. This is the standard choice for general-purpose storage and has the least overhead.
Protect this shared folder by encrypting it — Encrypts the folder's contents at rest using an encryption key. You must mount it with the key or passphrase to access files, and it adds performance overhead.
Protect this shared folder with WriteOnce — Applies WORM (Write Once, Read Many) protection. Files cannot be modified, deleted, or renamed for a set retention period. This is generally irreversible for the retention window.

Configure Advanced Settings

Enable data checksum for advanced data integrity — Turns on file self-healing and data scrubbing to detect and repair silent data corruption. The overhead can hurt performance.
Enable file compression — Compresses stored data to save space. It is greyed out here because it depends on data checksum being enabled first (both rely on the Btrfs file system). Most media content is already compressed, so the gain is minimal.
Enable shared folder quota — Sets a maximum size limit (in GB or TB) for the folder to cap how much storage it can consume.

Configure User Permissions

The last screen of the Shared Folder Creation Wizard allows you to set the access rights different accounts have on the shared folder.

Because the PlexMediaServer account is a system account, you need to select it from the System internal user list. From here you can set the access this account will have on that shared folder:

RO means that the media cannot be deleted from within Plex
RW allows you to delete the media using the delete option in Plex

Create a Sensible Folder Structure Before Adding Libraries

Plex's installation and library documentation both emphasise proper structure. Do not point libraries at the root of a drive or volume; create a dedicated share with subfolders such as Movies, TV Shows, Music, Other Videos, or Photos, and point Plex at those. Plex explicitly warns against using a drive root as a library folder because it causes problems.

A tidy Synology-native layout might look like this:

/volume1/PlexMedia/Movies
/volume1/PlexMedia/TV
/volume1/PlexMedia/Other

If your media lives on another volume, replace /volume1 with the correct volume path for your NAS. A dedicated Plex share also makes permission management easier.

If you have media that lives in its own pre-existing shared folder, you need to edit that folder's permissions to grant the PlexMediaServer account the appropriate access rights — RO if you want to ensure the media cannot be deleted from within Plex.

Name Your Files So Plex Can Identify Them

Plex relies on file and folder naming to match your media against its online metadata databases. If files are named inconsistently or ambiguously, Plex may mismatch them, pull the wrong artwork, or fail to identify them entirely. Getting this right from the start saves a lot of manual corrections later.

Movies

The recommended format is:

Movie Name (Year).ext

For example:

/volume1/PlexMedia/Movies/Gladiator (2000)/Gladiator (2000).mkv
/volume1/PlexMedia/Movies/The Shawshank Redemption (1994)/The Shawshank Redemption (1994).mp4

Each film lives in its own subfolder. The year is important because it helps Plex distinguish between films that share the same title (e.g. remakes).

TV Shows

The recommended format is:

Show Name - sNNeEE - Episode Title.ext

Where NN is the two-digit season number and EE is the two-digit episode number. For example:

/volume1/PlexMedia/TV/Breaking Bad/Season 01/Breaking Bad - s01e01 - Pilot.mkv
/volume1/PlexMedia/TV/Breaking Bad/Season 01/Breaking Bad - s01e02 - Cat's in the Bag.mkv

The season subfolder is optional but keeps things tidy.

Key Points

Always include the year for movies.
Always include the sNNeEE pattern for TV episodes — Plex depends on it.
Avoid stuffing quality tags, release group names, or other metadata into the filename. Plex does not need them and they can confuse the scanner.
Plex's own naming guides are at support.plex.tv/articles/naming-and-organizing-your-movie-media-files and support.plex.tv/articles/naming-and-organizing-your-tv-show-files.

Open the Plex Web App and Finish First-Run Setup

You can complete setup by opening a browser and navigating to:

http://<local-nas-ip>:32400/web

Associate Plex Libraries with NAS Shared Folders

Select Add Library and choose the type of media that will be stored there.
Specify the folder on the NAS where that media is located. You can associate multiple folders with a single library, but they must contain the same type of content.
Repeat for other media types.

Adding and Viewing Content

To add media to your PMS, simply copy files into the appropriate folder. Plex will normally detect and index new media automatically, making it appear in the menu.

If this does not happen, you can trigger a manual scan via Settings → Libraries → Scan Library Files.

Once indexed, the media can be played by selecting it.

Performance Tuning for Synology

Synology performance with Plex is mostly about avoiding unnecessary transcoding. NAS devices are typically processor-limited, transcoding is CPU-intensive, and some lower-powered ARM-based devices have transcoding disabled entirely. So the first performance improvement is not a setting at all: keep media in formats your clients can Direct Play whenever possible.

If your NAS appears in Plex's compatibility list as supporting hardware-assisted transcoding, and if you have Plex Pass, enable Use hardware acceleration when available under Settings → Server → Transcoder. Hardware acceleration makes transcoding faster and allows more simultaneous streams, though it can reduce quality or compatibility in edge cases. For the remaining transcoder settings, a sensible starting point is to leave Transcoder quality on Automatic.

Deleting Empty Folders

I have Plex running on both Ubuntu servers and my NAS (DS1525+). From an operational perspective, I have not noticed any difference in performance or quality. One function that is missing from PMS on Synology is the ability to automatically delete directories that become empty when their content is removed.

It is not a critical issue, but it would be convenient if emptied folders were automatically cleaned up, as happens on the Ubuntu version.

Accompanying Video

https://youtu.be/TD_zG7f0UpM

When Your CPU Dies: My Journey with a Defective Intel Core i7-13700K

Alan Bonnici — Tue, 09 Jun 2026 07:00:00 +0000

Introduction

My perfectly stable homelab server gradually descended into chaos — random crashes, segfaults, system hangs — and how months of troubleshooting, community support, and hardware swaps eventually led to one conclusion: the CPU itself was defective from the factory.

If you're experiencing unexplained instability on an Intel 13th or 14th Gen system, this story might save you months of frustration.

Quick Symptom Checklist

If you're seeing multiple of these symptoms, you may be affected:

Random segfaults in unrelated applications
System instability appearing after months of stability
Crashes or hangs under light load or while idle
VMs freezing while still marked as "running"
Issues persisting despite PSU, RAM, or OS checks or changes

The Setup

In November 2022, I built a homelab server with the following components:

Component	Model
CPU	Intel Core i7-13700K (Raptor Lake)
Motherboard	ASUS PRIME Z690-P D4 (Intel Z690, ATX, DDR4)
RAM	Patriot Viper Steel DDR4 3600 MHz C18, XMP 2.0
Cooler	Cooler Master Hyper 212 Black Edition
PSU	Corsair RM-850e
OS	Proxmox VE

The system ran Proxmox VE 7, later upgraded to v8, hosting a mix of Windows, Ubuntu, and Debian VMs, plus a couple of LXC containers. For over a year, everything was rock-solid. NUT (UPS monitoring), LAN bonding, automated backups — all worked flawlessly.

The Trouble Begins: A Timeline

August–September 2024: First Signs of Instability

After upgrading VirtIO drivers from 0.1.248 to 0.1.262, I started seeing x86/split lock detection errors. The entire Proxmox host would crash, taking down all VMs and containers.

Even though I didn’t fully trust that theory, I pointed a finger at the VirtIO upgrade — it was the only change I had made.

What the community said:

"Don't think VirtIO would make the whole host crash... this seems more like a hardware issue with storage or memory"
"Split lock is an indication of your VM doing some weird stuff... generally related to very buggy software/OS or faulty hardware — bad memory, bad CPU, bad power supply"
Suggestions: Run memtest, stress-test the CPU, check thermals, check fans

I disabled split lock detection as a workaround. The crashes continued.

September 2024: Testing Everything

Following community advice, I:

Ran PassMark memory tests — no errors
Updated the motherboard BIOS - I was one version before the latest
Ran stress-ng on the CPU — no errors
Replaced the PSU with a spare one I had.

October 2024: Stability... or So I Thought

The issue appeared to disappear.

On 17 October 2024, I reported back to the Proxmox forum that the system seemed stable. I waited a full month before posting to be sure. I assumed—incorrectly—that the component I had changed was the culprit.

The stability was temporary—the degradation was progressive.

December 2024 – January 2025: New Symptoms Emerge

New problems surfaced:

A Windows Server 2022 VM would hang during backup restarts
QEMU guest agent fs-freeze/fs-thaw commands would time out
VMs appeared "running" but were unresponsive
Console showed improper shutdown states

I tried:

Switching backup modes
Changing machine types (q35 → i440fx)
Updating QEMU

Nothing resolved the issue.

February 2025: The Penny Drops

While continuing to seek help on Reddit, someone pointed me to the Intel 13th/14th Gen instability issue. The symptoms matched perfectly:

Random crashes under varied workloads
Segfaults in unrelated binaries
System hangs after running for days
Progressive worsening over time

It was suggested that I run the Intel Processor Diagnostic Tool (IPDT) (https://www.intel.com/content/www/us/en/support/articles/000005567/processors.html).

This tool is Windows-only. Intel should have created a utility that is OS-agnostic making it something you could run from a bootable USB drive.

Having to jump through hoops to perform a test for the company's product is counterproductive.

Stress tests like mprime / Prime95 didn’t expose the issue.

March 2025: Intel RMA Process

Armed with the information, I hopped over to the Intel Community (https://community.intel.com/) and asked about the process.

At https://www.intel.com/content/www/us/en/support/articles/000057098/processors.html I found all the information to start the process.

You need to provide:

Processor number
ATPO
FPO

If you no longer have the box, you’ll need to remove the CPU and clean off the thermal paste to read the markings.

When the Intel support agent asked me for the following additional information (from Intel's email):

Motherboard: Please include the model and any relevant details.
Power Supply Unit (PSU): Model, wattage, and manufacturer.
Dedicated Graphics Card: Model and manufacturer, if applicable.
Thermal Solution Details (Air Cooler or a Liquid Cooler):
Operating System Details:
Have you tested this processor on a different motherboard, if yes, on which motherboard was it tested?
Have you tested your current motherboard with a different compatible processor, if yes, which processor have you used?

The process was excellent.

I live in Malta, an island at the edge of Europe, where cross-border logistics usually take time.

Key dates:

16 March 2025: Case opened / CPU information provided / collection process initiated
18 March 2025: DHL collected the defective CPU
20 March 2025: Replacement CPU delivered by DHL

Thermal Paste

Make sure you have thermal paste on hand. If you need to read information off the CPU (and using the machine while your case is being processed) and when you mount the new CPU on your motherboard.

Replacement CPU

The replacement CPU arrived in Intel-branded packaging.

Post-Replacement: Problems Resolved

After installing the replacement i7-13700K, all previously experienced problems disappeared. Two months after replacing the CPU, the system returned to the rock-solid stability it had enjoyed during its first year of operation.

The Bigger Picture: Intel's Raptor Lake Defect

My experience was not isolated. It was part of one of the largest CPU reliability crises in recent computing history. Earlier in my troubleshooting process, I had seen references to CPU-related problems, but:

CPU tests passed
in over 40 years I had never encountered a time-delayed CPU defect

What Went Wrong

Intel's 13th Gen ("Raptor Lake") and 14th Gen ("Raptor Lake Refresh") desktop processors suffered from a fundamental defect that caused progressive, irreversible degradation. The issue affected high-performance SKUs — primarily the Core i5, i7, and i9 K/KF/KS variants with the 8P+16E core configuration.

Root Cause: Vmin Shift Instability

On 25 September 2024, Intel employee Thomas Hannaford posted the official root cause analysis on the Intel Community forums (https://community.intel.com/t5/Blogs/Tech-Innovation/Client/Intel-Core-13th-and-14th-Gen-Desktop-Instability-Root-Cause/post/1633239)

Intel localized the problem to a clock tree circuit within the IA core that is particularly vulnerable to reliability aging under elevated voltage and temperature. These conditions lead to a duty cycle shift of the clocks, causing system instability.

Intel identified four operating scenarios that lead to Vmin shift in affected processors:

1. Motherboard Power Delivery Exceeding Intel Guidance

Mitigation: Intel Default Settings recommendations for 13th/14th Gen desktop processors. It is common practice for motherboards to exceed these settings and they have done so for years. It is normally set by default.

2. eTVB Microcode Algorithm Issue

The Enhanced Thermal Velocity Boost algorithm was allowing i9 desktop processors to operate at higher performance states even at high temperatures.

Mitigation: Microcode 0x125 (June 2024)

3. SVID Algorithm Requesting High Voltages

The microcode's Serial Voltage Identification algorithm was requesting high voltages at a frequency and duration that caused Vmin shift.

Mitigation: Microcode 0x129 (August 2024)

4. Elevated Core Voltages During Idle/Light Activity

Microcode and BIOS code were requesting elevated core voltages especially during periods of idle and/or light activity — exactly the condition a homelab server experiences most of the time.

Mitigation: Microcode 0x12B, which encompasses 0x125 and 0x129, and addresses elevated voltage requests during idle and/or light activity periods

Intel confirmed that mobile processors and future product families (Lunar Lake, Arrow Lake) are unaffected by the Vmin Shift Instability issue.

Manufacturing Oxidation (Early Units)

For some early 13th Gen processors (manufactured in late 2022 — exactly when I purchased mine), there was an additional manufacturing defect involving oxidation. Intel confirmed this was identified internally in late 2022 and addressed in production by early 2024, but on-shelf inventory with the defect may have persisted into early 2024.

The Critical Point: Damage Is Irreversible

Once a processor has been exposed to excessive voltage for long enough, the damage to the clock tree circuit is permanent and cannot be repaired by any software update. Microcode patches can only prevent further damage on CPUs that haven't yet degraded — they cannot restore already-damaged processors.

This is why my system's stability gradually worsened over time, and why replacing the PSU only appeared to help temporarily.

Why My Homelab Was the Perfect Victim

Looking at Intel's four identified scenarios, my Proxmox homelab hit the worst-case combination:

Scenario 4 (idle/light activity): A homelab server spends most of its time in light-load or idle states — exactly when the faulty microcode was requesting the highest inappropriate voltages
Scenario 3 (SVID high voltage requests): The constant power-state transitions of a virtualization host (VMs starting, stopping, idling) triggered frequent SVID voltage requests
Early manufacturing (oxidation): Purchased November 2022, squarely in the window for the oxidation manufacturing defect
Always-on operation: Running 24/7 meant maximum cumulative exposure to the damaging conditions

The May 2025 microcode update (0x12F) specifically addressed "systems continuously running for multiple days with low-activity and lightly-threaded workloads" — a near-perfect description of a homelab server.

Intel's Response: A Timeline

Date	Action
Late 2023 – Early 2024	Community reports of instability begin accumulating
April 2024	Intel recommends motherboard manufacturers use "Intel Default Settings"
July 2024	Intel officially acknowledges elevated voltage as the cause
June 2024	Microcode 0x125 released — fixes eTVB algorithm issue
August 2024	Microcode 0x129 released — addresses high voltage requests
August 2024	Intel announces 2-year warranty extension (3 years → 5 years) for affected SKUs
September 2024	Intel identifies root cause (clock tree circuit / Vmin Shift)
September 2024	Microcode 0x12B released — "final" fix encompassing 0x125 + 0x129 + idle voltage control
October 2024	Intel confirms the voltage issue was the sole root cause
November 2024	Class action lawsuit filed in San Jose, California
May 2025	Microcode 0x12F released — addresses edge cases in systems running continuously for multiple days with light workloads

Warranty Extension

Intel extended the warranty from 3 years to 5 years for all affected boxed 13th/14th Gen desktop processors (https://community.intel.com/t5/Mobile-and-Desktop-Processors/Additional-Warranty-Updates-on-Intel-Core-13th-14th-Gen-Desktop/m-p/1620853).

Key points from the announcement:

The extension applies to new and previously purchased processors
Coverage applies to all customers globally
The warranty eligibility period starts on the original purchase date and does not reset if Intel provides a replacement
Intel committed to supporting all customers experiencing instability symptoms through the exchange process

Affected Processors

The instability primarily affects desktop processors with the 8P+16E Raptor Lake silicon:

13th Gen (Raptor Lake):

Core i9-13900K/KF/KS
Core i7-13700K/KF
Core i5-13600K/KF

14th Gen (Raptor Lake Refresh):

Core i9-14900K/KF/KS
Core i7-14700K/KF
Core i5-14600K/KF

Lower-power variants (non-K, mobile) were less commonly affected but not entirely immune.

Lessons Learned

For Users Experiencing Instability

Don't assume it's software. If your system was stable for months and gradually becomes unstable, hardware degradation is a real possibility — especially with Intel 13th/14th Gen CPUs.
The symptoms are deceptive. The crashes manifest as memory errors, storage corruption, split lock violations, segfaults in random binaries — anything that looks like "something else" is broken. This is because the CPU is making computation errors.
Run the Intel Processor Diagnostic Tool / equivalent. Download it from Intel's support site. If your CPU fails, you have clear evidence for an RMA. Remember that a Pass is not a sign that your CPU is not impacted.
Don't waste money replacing other components first. I had a perfectly good PSU to replace but didn't have spare RAM, storage and a motherboard lying about. While testing RAM and storage is reasonable, be aware that a degrading CPU can make other components appear faulty.
Check your warranty status. Intel extended the warranty to 5 years for affected 13th/14th Gen desktop processors. If you purchased after October 2022, you likely have coverage through at least 2027.
Update your BIOS/microcode. If your CPU hasn't yet degraded, microcode 0x12B (or newer) can prevent the excessive voltage that causes damage. Check your motherboard manufacturer's website for the latest BIOS. A replacement is ultimately the best solution if you are eligible.

Conclusion

What started as random crashes turned out to be a widespread hardware issue.

The community played a critical role in identifying the root cause.

People who dedicate time to maintaining forums and helping others are a key part of the ecosystem—thank you.

If you're reading this because your 13th or 14th Gen Intel system is acting up take action. The fix exists, the warranty coverage is there, and Intel's replacement process works. Don't spend months chasing ghosts like I did. The clock is running out and these CPUs will eventually no longer be covered for replacement.

The Zero-Day Exploit Clock Is Ticking

Alan Bonnici — Thu, 04 Jun 2026 10:12:58 +0000

A Personal Introduction

The notion of breaking into a system and making it do something its developers never intended has existed since the early days of computing. My own introduction to computing came through hacking into games — disabling or increasing the number of lives to compensate for my slow reflexes.

Using TD (Turbo Debugger, from Borland — shipped alongside Turbo Assembler and Turbo C/C++), I would painstakingly try to identify the memory location that held the lives counter. Once found, one could either alter the value directly or place a NOP (No Operation) over the conditional jump. It was a task that required patience, determination, and, many times, reams of sprocketed continuous-feed paper annotated to help decipher what the code did.

Discoveries were rarely kept to oneself. You shared them with others on BBSs (Bulletin Board Systems), the dial-up communities that served as gathering places for the technically curious long before the web existed.

BBSs were not just a place to share results; they were a primary source of knowledge. Text files on cracking techniques, annotated memory maps for popular games, and tutorials on x86 assembly circulated freely between boards. You would dial in with a modem, download a collection of .TXT and .NFO files, then spend hours offline studying them. It was a decentralised, informal education system: no textbooks, no courses, just collective knowledge passed between pseudonyms.

The motivation was curiosity. There was no financial incentive and no criminal intent. It was intellectual challenge for its own sake — the digital equivalent of picking a lock just to prove you could.

From Annoyance to Destruction

That harmless hacking eventually evolved into something darker: worms, trojans, and viruses. Initially, these programs were little more than an annoyance, displaying messages on screen or slowing machines down. But the lever was gradually notched towards the harmful and destructive. Rather than simply popping up a message, these programs began deleting files and formatting hard drives.

Early examples like the Brain virus (1986) were relatively benign; it even included the authors' names and phone number. But by the early 1990s, destructive payloads had become common. The Michelangelo virus (1992) overwrote the first hundred sectors of a hard disk. CIH/Chernobyl (1998) went further, attempting to corrupt BIOS firmware and render machines unbootable.

If you are interested in watching a YouTube video of mine from 19 years ago demonstrating the operation of a destructive virus called “Casino de Malte”, head over to https://youtu.be/wiLZAEMsofM. Your hard disk’s fate was determined by the outcome of a game.

The Commercialisation of Hacking

The internet, cryptocurrency, and the dark web created an environment in which malicious actors could come together and organise themselves into profit-seeking entities. Their business model: penetrate systems, steal data, hijack operations, and then seek payment from the victim to rectify the mess they created.

It proved extraordinarily lucrative. Cybercrime is now measured in the trillions. Cybersecurity Ventures estimated that global cybercrime damage would reach $10.5 trillion annually by 2025 — a figure that, if treated as an economy, would make cybercrime the third-largest in the world after the United States and China.

These are not lone hackers in basements. Modern cybercriminal organisations operate with corporate structures — complete with HR departments, customer service teams to “help” victims pay ransoms, software development lifecycles, and even employee performance reviews. Groups such as LockBit and Conti have operated as Ransomware-as-a-Service (RaaS) platforms, licensing their tools to affiliates in exchange for a percentage of the ransom collected.

The Ecosystem: States, Criminals, and Brokers

Today, the malware market is made up of three distinct layers:

State-backed groups — Advanced Persistent Threat (APT) actors funded by nation-states for espionage, sabotage, and geopolitical advantage. Examples include Fancy Bear (Russia), Lazarus Group (North Korea), and APT41 (China).
Private criminal groups — Organisations that carry out penetration attacks, deploy ransomware, and operate data-theft schemes for profit.
Exploit brokers — Companies and individuals that trade in hacking knowledge. Firms such as Zerodium openly advertise bounty prices for zero-day exploits: up to $2.5 million for a full Android exploit chain, for example. This grey market means that vulnerabilities are sometimes sold to the highest bidder rather than reported to the vendor for patching.

The success of these operations often depends on what are known as zero-day exploits: vulnerabilities in software that are not yet publicly known and for which no patch or mitigation exists. The term “zero-day” refers to the fact that the vendor has had zero days to fix the problem before it is exploited.

To complicate matters further, some attacks require chaining together multiple exploits in a particular sequence. This is known as an exploit chain, or attack chain. For example, a modern browser exploit might chain a renderer vulnerability with a sandbox escape and a kernel privilege escalation — three separate flaws linked together to achieve full system compromise.

The Zero-Day Exploit Clock

The website “Zero Day Clock” presents a striking visualisation. It analyses publicly known vulnerabilities and estimates the time between public disclosure of a vulnerability and the first confirmed exploitation in the wild.

CVE gives a publicly disclosed vulnerability a common identifier, but it is only one part of the vulnerability-tracking ecosystem. CWE describes the underlying weakness, CVSS scores technical severity, EPSS estimates exploit likelihood, and CISA’s Known Exploited Vulnerabilities catalogue highlights flaws already exploited in the wild. Together, these systems help organisations decide what to fix first.

Strictly speaking, once a vulnerability is publicly disclosed, it is no longer a zero-day in the narrowest sense; exploitation after disclosure is often described as n-day or one-day exploitation. But from a defender’s point of view, the practical effect is similar: the available response window is collapsing.

The trend is alarming:

That compression — from months to days, and potentially from days to minutes — represents a fundamental shift in the threat landscape. Defenders used to have time to test, prioritise, patch, and monitor. Increasingly, they may have only hours, minutes, or seconds.

The AI Accelerant

The dramatic reduction in exploitation time is being accelerated by artificial intelligence, but AI is only one part of a wider shift. Automated scanning, exploit marketplaces, faster reverse engineering, criminal collaboration, and global infrastructure have all compressed the defender’s response window.

The same AI tools that security researchers use to find flaws in code can also be weaponised by adversaries. Their systems can continuously scour vulnerability databases, security mailing lists, vendor advisories, and even social media for news of a newly disclosed weakness. Once alerted, AI-assisted tools can help to:

Analyse the vulnerability — parsing patch diffs to understand exactly what was fixed and, therefore, what was broken.
Generate exploit code — assisting with proof-of-concept attacks targeting the flaw.
Adapt and mutate — creating variants that may evade simple signature-based detection.
Scale deployment — scanning the internet for unpatched systems and deploying attacks at machine speed.

This is no longer theoretical. Academic research has shown that AI agents can exploit some real-world vulnerabilities in controlled benchmark environments. The barrier to entry has lowered: what once required deep expertise in assembly language and months of reverse engineering can now, in some cases, be partially automated.

AI is also being used offensively for:

Spear-phishing at scale — generating personalised, convincing emails that bypass traditional spam filters.
Deepfake social engineering — cloning voices and video to impersonate executives in business email compromise (BEC) attacks.
Automated reconnaissance — mapping an organisation’s attack surface faster than any human team could.

What Can We Do?

We cannot eliminate risk, but we can significantly reduce our exposure.

For individuals:

Keep all devices updated with the latest security patches, and enable automatic updates wherever possible.
Retire technology that is outdated and no longer receiving security updates. End-of-life software is an open door.
Use multi-factor authentication or passkeys on every account that supports them.
Be sceptical of unexpected communications, even from known contacts. Verify through a separate channel.
Avoid reusing passwords. A single compromised password can become the first link in a much larger chain.

For organisations:

Maintain a rigorous patch management programme. The window between disclosure and exploitation is shrinking towards zero. That means patching can no longer be treated as a slow administrative process. Organisations should:
- Automate patch deployment where the risk profile allows it, especially for standard operating systems, browsers, endpoint software, and widely deployed services. Human approval remains important for high-impact systems, but approval workflows measured in days do not match a threat landscape measured in minutes.
- Prioritise vulnerabilities based on exposure, exploitability, business impact, and evidence of active exploitation. If twenty fixes are waiting, the most exposed and most exploitable systems should move first.
- Maintain an emergency patching route for critical vulnerabilities, with pre-agreed ownership, testing boundaries, rollback plans, and communication paths. The middle of an incident is the wrong time to decide who is allowed to approve a fix.
Prioritise internet-facing systems and known exploited vulnerabilities. These are the systems attackers can reach first and the weaknesses they are most likely to weaponise quickly.
Adopt a zero-trust architecture: assume breach and verify every access request.
Invest in defensive tools that can detect, prioritise, and respond at machine speed. Alerts alone are not enough; the goal should be rapid triage, containment, and recovery.
Conduct regular penetration testing and red-team exercises. These should test not only whether vulnerabilities exist, but whether the organisation can detect, escalate, and respond to them quickly.
Ensure robust, tested backup and recovery procedures. Ransomware is only effective if you have no viable alternative.

The uncomfortable truth is that vigilance alone is no longer sufficient. When exploitation timelines compress to minutes, human reaction time becomes the bottleneck. Organisations need automated detection, prioritisation, containment, and recovery capabilities that can operate at the same speed as the attacks they face.

We must also recognise that each of us can be one link in an exploit chain. A compromised personal device, a reused password, an unpatched home router — any of these can become the entry point that leads to a larger organisational breach.

Closing Thought

In three decades, hacking has evolved from teenagers on BBSs trading game cheats into a global criminal industry: commercialised, professionalised, backed by nation-states, and now accelerated by artificial intelligence.

The zero-day exploit clock is ticking faster than ever. For individuals, that means patching, retiring obsolete technology, using passkeys or multi-factor authentication, and treating unexpected communication with caution. For organisations, it means accepting that manual response is no longer enough.

The question is no longer whether an attack will come, but whether our defences can respond in the seconds we may have left.

Suggested references

Zero Day Clock: https://zerodayclock.com/
Cybersecurity Ventures, 2025 Official Cybercrime Report: https://cybersecurityventures.com/official-cybercrime-report-2025/
CVE-Bench: https://arxiv.org/html/2503.17332v3