On 22 September 2026, Computer Weekly turns 60. To mark the milestone, we asked some of our friends – experts, parliamentarians, IT leaders and suppliers – for their perspectives on how tech has changed their lives over six decades. What’s changed the most for you since then?
I was born two years before Computer Weekly and for the first couple of decades of my life, our worlds did not intersect at all. I didn’t see a computer until I was 19 and working in a tool distribution company in Birmingham where we checked stock in and out on a green-screen mainframe.
I was a user, except occasionally I was roped into the daily routine of taking out the disks. The machines were the size of a washing machine, the disks a foot across, with a big clamp-and-close handle you swung shut.
That was the extent of my IT life for another decade, during which I was a toolmaker in Birmingham, and my world was strictly Industry 1.0. There were CNC (computer numerical control) machines in the shop, but I had nothing to do with them beyond asking someone to make me a part now and then.
An access course carried me into university in my mid-twenties, and then I got my first computer: an Olivetti green screen with 5.25” disks. I used it to write essays. There was nothing else you could do with it.
After university – BSc history, MSc third-world politics – I worked in journalism almost from the start, on various publications. I laid out pages and wrote articles on PCs and Macs. I was still very much a user.
Three or four years later, I got my first PC. I went on the internet via a noisy modem, and got into downloading music through Napster and Limewire. It opened a world of exploration I could not afford before, when a record meant money I did not really have.
Still a user
In 1997 my journey brought me to Computer Weekly. I worked there as a sub-editor, production editor, then reporter. My background dictated I would report on IT in manufacturing, so I covered ERP and MRP, visited oil refineries, the Longbridge car plant in Birmingham, an iron ore mine in Sweden. I was still a user of technology but becoming a professional observer too.
That phase lasted for seven years, before I went freelance and moved to the north of England.
Now I was responsible for my own PC, and I quickly learned to fix what went wrong. Two HDD failures in the space of months forced me to delve deeper into the guts of the PC and its components, and I soon became comfortable Googling my way through problems.
By the late-2000s I had become storage editor for what would become soon Computer Weekly’s parent company. It was a space I’d largely adopted because everyone else considered it too boring.
I got to dive deeper into the tech, and was even given the chance to do a week’s course in storage technology certified by the industry body.
But in my relationship to IT, I was largely a user or an observer, and that held until the late 2010s.
The practitioner
Somewhere along the way, an interest in football – I was coaching our boy’s football team by this time – coincided with the rise of “citizen analysts” of football data. I was amazed at what people could do – turning raw football statistics into charts and graphics. And it resonated with me, because I never quite trusted my impressions when watching football and craved the grounding that numbers and patterns and arrows on a pitch graphic gave me.
“ Instead of being in the tactical weeds of coding or writing, I oversee an LLM-powered worker that can assess and summarise vast volumes of source material, locally and on the internet”
Antony Adshead
To do any of it, I needed software, so I taught myself R, the open source data science software. It was a long process – several months of pain simply learning it, and more when building things. When something did not work, my only recourse was Stack Overflow, and hoping someone’s problem somewhere in the world had intersected with mine.
Sometimes a whole afternoon or a day slipped by before I found the fix for a single line holding everything up. But it was a great introduction to programming, because everything had to happen by hand. I also learned some Python.
That ability to fix computers and work with data soon collided with a newer part of my life: I had become a trustee for Mums In Need, the domestic abuse charity my wife started in 2014. It is a small organisation – fewer than 10 employees – but still has real IT requirements, and I became board member with special responsibility for IT, which gives some flavour of the concerns of a real CIO. I was the person with the hands-on knowledge of software and the strategic IT overview my work at Computer Weekly gave me.
One milestone, still ongoing, was the case management system I built for the caseworkers who support our service users. It runs on Google AppSheet, a low-code platform, and replaced a clunky, bought-in casework system that was far too widely scoped and never really suited the work Mums In Need actually did. Inevitably, shadow IT in the form of Google Sheets had grown up around it. What we wanted was to bring all that data together – to gather it, to build reports and, crucially, to build good evidence for the funding applications on which charities are utterly dependent.
So I moved from user and observer to practitioner – first tactically, learning R and doing data analysis as a football hobby – then doing data science for the charity and building software around data, and with the leadership remit an IT board member might hold in any organisation. Mums In Need is small and my work very part time, but the overhead is real and covers the gamut from data protection and data backup to developing systems to handle the organisation’s information.
The agent overseer
The latest phase of my evolution has been as an everyday user of large language models (LLMs) in my role as acting datacentre and cloud editor with Computer Weekly, in particular when I have my data journalism hat on.
I hesitate to call it AI. It’s a glorified autocomplete, even if the frontier models are very, very powerful. Really what we’re doing is leveraging LLMs, and at best and in the most critical environments, learning how to work with their limitations.
I’d been using “one-shot” browser-chat AI for some time, but had long thought there must be a better way. You can set up persistent chats to guide Gemini or ChatGPT with a “master prompt” but it soon forgets what you tell it. You can get them to help writing R scripts for example, but they never truly know what you’re doing because they live in one window while Rstudio is in another.
I knew “agentic” was the next big thing and that I needed AI to work more as a copilot – that is, literally having vision and the means to execute actions in the folders / environment I’m working in – but had struggled to gain any traction.
Two encounters really gave me a kick up the backside. I met a developer friend in the pub one night, where he told me of the work he had been doing with agentic AI. He had a job scraping some specific data from every council in the country. The scraper worked autonomously; if it encountered a failure, it rebuilt itself to work around the issue. It all worked with “skills” he said, and markdown files. I hadn’t got a clue what he was talking about and felt like I’d arrived in a time machine from 1956.
A couple of weeks later I was at a Google event. A Google employee was sat next to me, laptop open on his knees during a keynote. I tried desperately to look as if I wasn’t looking and caught glimpses of a fleet of agents at work in different panes – researching, checking, working. I thought – I need to know how to do that.
A few months later – and taking inspiration from the likes of Jake Van Clief and Matt Pocock – a lot of my work revolves around an LLM inside a code editor, and using markdown-based workflow and skills files, that help me research, conduct data analysis, write drafts, and where needed, verify quotes and check facts.
It seems obvious to me that such setups are a good fit for many types of relatively unstructured work because the LLM provides the intelligence to bring structure. IDE-integrated, agentic workflows are commonplace in software engineering. If the enterprise can use such code editors to generate and maintain vast codebases, it is a dead-cert candidate for spheres such as research and article or report drafting, where the concept of “diffing” is easily transferable and possible at high speed and reliably with a capable LLM.
The challenge is to keep the LLM on track through the ability to guide the workflow and to compensate for the context window and memory limitations that even frontier models carry.
The end result is a setup that allows me to handle vast amounts of information – multiple datasets of multiple types, PDFs, CSVs, markdown, whatever it can read. Meanwhile, its agentic capabilities can spin up R and Python scripts for intermediate checks or as part of persistent data pipelines for perpetual use. Via MCP servers it can carry out research on the internet and add to the dataset. Its outputs can be checked against source material and finished articles can be compared to its drafts so it can build your requirements into the markdown-based documents that guide its workflow.
Not yet the culmination
So, what’s my role as I do this? I feel sometimes I’ve become more like the editor now. I’m taking strategic decisions all day long. Instead of being in the tactical weeds of coding or writing, I oversee an LLM-powered worker that can assess and summarise vast volumes of source material, locally and on the internet. Its brain can work with far more sources than I can, so I guide it to investigate angles and report back, tweak lines of research on my instruction, edit its written and graphical outputs.
But I am glad I learned to code before all this arrived, because to use an LLM for this kind of work it is essential to have some idea of what it is doing – to see where it might have gone wrong, and to troubleshoot when things do not come out as you expected. That depends on knowing what happens at the code window level. It’s the equivalent of knowing your subject matter when it comes to editorial decisions.
And so that’s where I’m at now in my journey in IT. It’d be foolish to call it a culmination. Things move so fast and who knows where we’ll be in a year’s time. I’m sure there’s a lot more I could explore.
