There is a common refrain in circles critical of AI (Large Language Model) technologies that I think creates a blind spot within their critiques. The idea that ‘AI’ systems will inevitably fail to deliver in the workplace allows us to too easily dismiss the broader implications of their current and future impact on our work, and to delay the question of how to respond to the shift in ownership of our labor.

In this post I want to directly address a future in which these technologies do not simply fall over of their own accord and everything goes back to how it was before, but in which they embed themselves in our workplaces, and to reiterate and emphasise what should be an obvious statement; that the topic of LLM adoption in the workplace is fundamentally a labour issue, and it must be approached as such.

In particular, I want to focus in on my own industry, software engineering, where AI assisted technologies are on course to completely change the dynamic of how our work is done, to outline the risks that that introduces, and to discuss what will happen if we don’t rapidly develop a proper conception of what that change means to us, and how we should respond to it.

The nature of automation and is that it shifts the dynamic within a workforce or process, removing bottlenecks from one location and placing them in another, relieving one type of stress while adding new sources, alleviating a given time pressure on one team to now place a metronome on another. Its often insufficient to dub a given piece of automation as simply “good” or “bad”, if it was, identifying and organising against the “bad” would always be easy. Instead we need to be thinking about where and how power shifts and along with change, we do ourselves, future workers, and our critique of the current AI paradigm a disservice by relying on the idea that the problem will just go away.

You May Not be Interested in the Technological Context, but the Technological Context is Interested in You

In October of 2025 I got hit by AI / LLM job security anxiety for the first time. The reason for this is that a potential vision of the future of software engineering crystallised in my head, and I realised that the risk of job loss is relatively minor compared to the risk of loosing agency currently afforded to us as developers.

This post is not intended to scare anyone or be overly pessimistic, nor is it about arguing for/against the merits of using LLM based tools. Instead, I want to connect the current moment with AI coding assistants to past examples of how automation has played out and to emphasise that avoiding discussion of the thorny issue of control over one’s own work is no longer avoidable.

As with any counterfactual what I will lay out in this section will necessarily be flawed and simplistic, please take any specific claim with a large pinch of salt and bear with me because there is a deeper point.

So what changed?

Why am I writing this now, and not in early 2025 or late 2026, or 2022? Well for one thing – and this is just my anecdotal perspective – there seems to have been a vibe shift regarding LLM coding assistants throughout 2025, but especially towards the end of the year. This could be a delayed shock wave from improvements in the models performance, specific feature improvements like whole-project context awareness, or maybe its just that a critical mass of people have now had time to get used to the tools.

So what, did the tools get so good that I finally started believing the technology’s boosters, claiming that fully autonomous agents could replace all need for software engineers, and that we should all retrain as plumbers?

No of course not. As someone who understands the architecture of LLMs (as I think absolutely everybody needs to, lest you inevitably get hoodwinked by them), I understand that they are simply incapable of operating without supervision and a guidance framework at the very least, to say nothing of the inevitability of hallucinations, fixations, and logic loops.

My anxiety was not driven by the thought I might be redundant, but by a realisation that the future of software engineering – on present course – is one in which the agency of the developer themselves could be significantly diminished. Its a future we’ve seen play out countless times in other fields when a new form of automation comes along.

It is a future where we will potentially have to continually justify the fundamentals of our work, to argue for code quality, security and maintainability more so than we have ever had to before. We’ll have the ability to do three times as much, and may be expected to do ten times as much. It will be a future where speed and quantity of work produced may become the main measures of success, even if that means creating low quality or flawed code.

I do think coding assistant tools come with a host of advantages such as freeing headspace to focus on architectural decisions, removing tedium from doing repetitive tasks, and jumping over little hurdles which might otherwise stretch out a sequence of work. (talk about actual examples, testing etc)

But this is rather the point; automation is a multiplicative force which unavoidably increases the amount of work done, along with the speed at which it is done, so is speed the only metric which matters?

In my mind, to try to decide if a given piece of automation is “good” or “bad”, and thus how to respond to it, you must begin with questions such as these: Who owns the benefit from this change? Who’s life does it make easier? And who is now having to do more to keep up with the machine, where before the machine kept pace with them?

Work Capability vs Demand

This is of course already familiar to anyone with a socialist or left-leaning perspective, but I’m realising it needs reiterating now, given the surprise being expressed as the idea that AI workflow tools are creating more work, not less.

In the article AI Isn’t Lightening Workloads. It’s Making Them More Intense by Ray A. Smith in the Wall Street Journal, naive and disingenuous predictions about a reduction in work due to AI automation are contrasted with a study by ActivTrak whos’ initial findings indicated that AI tooling intensified work being performed, expanded the remit of tasks, expanded the boundary of where work was taking place, and lead to an increase in multitasking.

The preliminary findings, detailed further in AI Doesn’t Reduce Work—It Intensifies It by Aruna Ranganathan and Xingqi Maggie Ye (Harvard Business Review), outline how this intensification occurs and what may be done to manage it more sustainably. Staff experimentation with AI tooling can sometimes turn into meaningful work, exhilaration over being to do more leads to a sense of satisfaction which then fades as the novelty wears off and workers realise more is now expected of them.

These actions rarely felt like doing more work, yet over time they produced a workday with fewer natural pauses and a more continuous involvement with work. The conversational style of prompting further softened the experience; typing a line to an AI system felt closer to chatting than to undertaking a formal task, making it easy for work to spill into evenings or early mornings without deliberate intention.

Ranganathan & Maggie Ye in AI Doesn’t Reduce Work—It Intensifies It

This apparently self-directed productivity increase might appeal very strongly to employers but the authors stress the unsustainability of some of the situations created. The increased workload could lead to overwork, judgment impairment, the obscuring of genuine value from ‘busy tasks’, and potentially leading to fatigue and burnout.

The authors suggest building an ‘AI Practice’; a set of activities or behaviours intended to stem the increase of work done, in order to ensure any increase that happens is sustainable.

• Intentional pauses: Breaks strategically placed in workstreams to allow for workers to evaluate their tasks’ alignment with wider goals and regulate pace.
• Sequencing: Providing a structure to which tasks follow which others, preventing notification overload and guiding workers on how to focus on one thing at a time.
• Human grounding: Deliberate social contact interjections within work.

While I find this list to be a good start at tackling the double-edged sword of increased capability from these tools, the problem should be immediately apparent to anyone that has ever interacted with a boss or company; what if they just choose to not care about any of that anyway?

What if bosses are happy to burn people out and simply replace them, knowing that the entire market will do the same? Are lists like the above simply facilitating these extended expectations, rather than tempering them?

I find similarity with a discussion which occurs in urban design circles; that urban design is viewed through the lens of traffic engineering and thus a mindset where the management of cars is often incorrectly thought of like a plumbing problem, a question of managing a set capacity of material through a series of pipes. If you have congestion, well that’s because you need more and bigger pipes.

This logic has been the prevailing mindset in urban design in the UK and elsewhere but is completely flawed due to the effects of induced traffic and the fact that traffic flow is determined by interaction points like junctions, not speed or space. Cars are not a fixed quantity which fills up like a liquid, they are a gas, expanding to fill whatever capacity they are given. The question should not be ‘how do we manage all these cars‘ but ‘how many cars do we want in this space‘?

Are our companies and teams ready to answer the question ‘where do we put limits on our increased work capability’? Are they ready to leave some potential output on the table, recognising that its healthier in the long run?

On ‘Inevitability’ of AI Becoming Standard Practice

Often times I trip over myself trying to speak to multiple audiences at once; at work trying not to look like someone with their head in the sand, deliberately detached from reality, and in more political contexts trying to not appear as though I have “drunk the Cool Aid” and embraced fantastical sales pitches from the tech giants.

What do we mean by Failure?

I want to identify two broad type of failure scenarios for LLM based technologies in order to stress that I am aiming this post directly at one and not at all at the other. When I talk about the ‘technology failing’, I am speaking directly to the claim that AI tools somehow don’t (or wont) work in workplace contexts, and that this will somehow lead to some kind of collective awakening where we just come to our senses and abandon them.

Do AI Tools Work?

Perhaps a topic to revisit in its own post, I think that talking about whether a given AI tool “works” or not is the wrong way to go about critiquing them. It asserts and imposes an intentionality that the tooling and the vendors just don’t share.

Whether or not the tool can perform to the current expected quality of work often does not matter when the true purpose of the tool is to shift the balance of what is expected, what is valued, and who owns the product of that new value.

AI translation is dreadful, but it ‘works’ well enough to have completely decimated the translation industry, relegating translation workers to the task of cleaning up AI outputs for less pay than before. To simply blithely say “well look how bad it is at translating!” is a deliberately naive statement and, frankly, insulting to said translators.

The purpose of a translation tool is not to ‘do the job as well as a translator’; its purpose is to be an excuse to remove agency from translators and take them down a pay scale. The purpose of a document summary tool is not to ‘accurately summarise documents’ – the possibility of hallucinations prevents that from ever happening reliably- it is to let you blunder your way through meetings you didn’t bother preparing for, the TV adverts showing people doing this explicitly saying as much.

In this sense, whether AI coding assistants actually do speed up developers or increase other productivity metrics may not ultimately matter versus the possibility that the value perceived by business is that of looking as though you are producing more work, of generating more commits, more lines, more complex logic.

I don’t think there’s anything wrong with pointing out how poorly AI tools perform, or how negatively they affect X or Y industry, but I just get frustrated that we continue to ignore the reality of the impact of these tools in the workplace with a pithy statement of “well it’s shit so it can’t possibly work”, thinking that stating so will somehow make them shrivel up like the Wicked Witch of the West.

Real Failure

On the other side of the coin, there is the financial failure scenario, the one in which the entire industry falls over and ceases to function, this one is far more inevitable and tangible.

Let me make absolutely clear that I am not aiming critique at or disputing the claims of LLMs’ unsustainability, or any of the brilliant work being done by people like Ed Zitron. These journalists and researchers do a fantastic service to us all of interrogating the AI industry, calling out its claims, and highlighting its nonsensical financing. The current AI industry is deeply unsustainable, the AI bubble remains a bubble and the current industry can therefore not continue to exist on its current terms.

It is undeniable that the current situation of cyclical funding, service denigration, and speculation must end in – most likely – a market crash. Even the most popular coding assistants are no where near profitability, ditto for the root vendors themselves, there is ever increasing consciousness within the working population of some of the downsides of AI tools propagating.

“But Robyn, how can you talk about a technology that seems doomed and also talk about a future in which it propagates everywhere?”

In the context of this post I am effectively ignoring the inevitable end of the current AI bubble, imagining that in some way some form of LLMs continue to exist and with them coding assistants and the expectation of increased output that comes with them.

Perhaps the market does crash but some plucky upstarts remember back to when the unveiling of Deep Seeks R1 in early 2025 caused a brief disruption in the AI world with the novel idea that you could use a more specialised architecture for specific tasks, rather than use One Big Model trained on the entire internet, and it might be more efficient for those tasks. Such upstarts might see the upcoming bubble-burst and set to work on a Cursor-like system which is currently uncompetitive but will look better and better as the offering from existing vendors continues to degrade with more rate limiting and token reductions.

In any case, and because I don’t want to speculate fiction, I just want to illustrate that predicting the future with too much confidence often ends with something newer (and stupider) happening instead. Yes I’m talking about that example. Yes and that one. And especially that one.

On that note, let me just set out a stall to explain my position on the current AI moment more generally, just because I have not done so yet on my blog, and because I want to head off any claim of being too confident in the potential dominance of AI coding assistants in the future.

What do I think of ‘AI’?

I am very critical of LLM based technologies, in fact I think they probably shouldn’t exist.

Setting aside the ever expanding list of criticisms that may be levied at them, I think that on a basic level a technology that is capable of such psychological harm, with such an obvious privatisation of stolen intellectual property, and such enormous energy requirements during a time when we should be in a constant state of panic about the climate crisis, simply cannot be justified, even if it does have benefits.

The Omni Product

Challenges are often raised to the question of scale and energy requirements such as ‘well what if it became portable / could run on conventional hardware / reduced its energy intake / was sovereign to each country it was used in etc.’ but these ignore the fundamental role that scale plays in the political utility of the current AI industry. LLMs are built on such massive scales of data, hardware, and energy precisely because it suits the political economy of the US.

LLMs are a technical-political engine to provide justification for the continued relevance of the US tech sector, a justification for for their continued monopolisations of aspects of public life, and ultimately as a battering ram for US technological imperialism.

A sort of ‘Omni-Product’, the spectre of AI can be used to mean anything, to justify almost anything, and to be a sort of sock puppet which can be used to obscure any number of dubious pieces of functionality and data accumulation under the auspices of a technology that is sold as magic. LLM based technologies under the AI ‘Omni-Product’ banner are the natural conclusion of a tech industry which has ran out of ways of dazzling the public, and can no longer sell its data harvesting architecture under the vision of a better and more democratic future. An endlessly repackageable generic product which requires little justification (being magic) while at the same time acting as the perfect shield to the industry from any criticisms of its intrusion into so much of our modern lives. LLMs are intrinsically deeply political entities and any analysis of their function that does not take that context into account is virtually useless.

Given the precarity of the political, financial, and infrastructural arrangements which underpin access to LLMs (at least outside of the US), the criticism’s of its stated productivity gains, and the coming energy crisis, it remains ever possible that one day access to LLM based technology will simply cease. Either through the bursting of the financial bubble, or a temper tantrum from the US government, we could wake up one day to find that none of these tools can connect to their servers anymore. If that happens this entire post will be pointless and you will have wasted 5 minutes reading this far. Apologies. If it makes you feel any better I bet the rest of this post looks very funny in retrospect.

Nevertheless, for as long as LLM vendors are available, the software engineering / software development industry is one place where LLM’s work really well. As such, the pragmatic thing to do is to plan for a future in which they stick around, and in which we have to deal with a context in which their use spreads and embeds further.

I’m not interested in trying to convince you of the inevitability of such a future, there are still so many different ways things could play out, but to discuss its implications assuming it hypothetically does.

What will Software Engineering Look Like?

Please forgive me if you’ve seen 300 articles with this exact title in the last week alone.

Let me be clear about what this section is not. It is not a laundry list of hypotheticals drawn from fairy land about how any day now your own personal little R2-D2 is going to do your dishes and design you a PaaS which will make you a millionaire overnight, better suited to the subreddit r/worldbuilding than any sort of critical analysis. Nor is it a story of an apocalypse, of “AGI” of or a mass jobs crisis which places us all in the world of Children of Men. And most importantly, it is not a barely disguised sales pitch for the Agentic Workflow Tool Of The Month.

Instead, I find it instructive to look at what technologies already exist and trends / workflows already emerging in order to extrapolate reasonable assumptions about the future of software development by imagining them being more prevalent, more embedded, and more standard practice than they currently are at time of writing. For some reading this, the workflows described here will sound exactly like what you’re already doing, I’m inviting you to imagine a context in which this is just the baseline everywhere.

Developers as Conductors

Through use of “Agent” frameworks and wrapper tools such as Claude Code, Cursor, Windsurf etc., the role of the software engineer will shift from implementing changes, to acting as an orchestrator, coordinating agent sub-processes and reviewing changes in batches. Barriers to adoption such as model drift and misinterpretation of requests will be significantly reduced through techniques such as specification-driven development, in which developers iterate over a given change to be made by writing and refining a mini brief or specification, breaking down the required implementation steps, then guiding the agent one step at a time through implementing them.

Where before we might have viewed development as a linear list of tasks to burrow through as quickly as we are capable of, the challenge here will be ensuring adequate mental space and patience, to write robust instructions and specifications, resisting the urge to ‘just crack on’ and begin pumping out features. We will all be project managers and product designers, stopping continually to take in a wider project perspective. The risk here is that doing so may not feel like “real work”, it will be labeled “planning” either by developers performing the activity, or by project managers and bosses who may also want to progress past this stage as quickly as possible.

The alternative to taking adequate time to do this is perhaps obvious but worth restating; an endless stream of slop, insecure, buggy, unmaintainable code where speed and quantity have been prioritised above all else.

Static analysis and code review also falls under this working method, potentially leading the developer coming to expect Merge Request review functionality within each step of the development process. Done well, this could bolster SAST and DAST integrations and lead to higher quality code. But again, the opposite could equally be possible, the burden for reviewing quality being reduced on the developer presents the risk of carelessness.

In the piece by Ranganathan, Maggie Ye, the term “boundless work” is used to describe the increase in potential workloads, I cannot think of a phrase which describes software engineering better. There is always more we want to build, more things to learn, more demand for our services, more requirement to respond to a changing context, new vulnerabilities, update and maintenance.

How we pace ourselves in with the flood gates open to working as fast as we can prompt, is entirely undecided. Who decides what a reasonable pace is? Who decides how much time is adequate to scope and plan a feature? Who gets to decide that, in fact, your team is rushing too fast and must slow down in order to increase quality? Answers on a postcard.

Human Sink

Increased pressure to get more done can lead to increased mistakes getting through for obvious reasons, but carelessness will also come at a cost. Performing Merge Request reviews well is difficult in my experience, and often poorly performed by teams even when workloads are small.

An emphasis on responsibility and guardrails will become stronger as organisations attempt to respond to any slide in quality control, but turning a problem of overproduction into a question of personal responsibility won’t work any better than responding to a dangerous street design with posters at the carriageway warning people to ‘watch out’, it will not resolve the issue but it might give you someone you can blame.

On a recent episode of This Machine Kills (the episode that inspired this post) the hosts touch on the idea that AI requires a Human Sink; a way to ground responsibility in a person or group which functions as a heat sink does on hardware devices. We see this play out in discussions of autonomous weapons where the hypothetical final sign-off on a machine-driven decision is used to respond to criticisms of autonomous killing.

The flow of responsibility can also act in revere; we are surely all familiar with how the spectre of the computer can be used as a form of excuse making for to remove the burden of blame for those involved in making unethical decisions, such as systems which try to target benefits frauds.

What to do When Your Boss Starts Vibe Coding

Has this happened to you (yet)? I’ve already had one instance of a non-technical client team vibe code their own rebuild of the tooling we provide to them and present it back to us to have to deal with.

The system is very complex, critical to an annual reporting cycle with a small open window, and has strong regulatory implications. When we received the repository for the supposed rebuild, my colleagues and I had a good laugh about it, at least at first. The build was riddled with glaring flaws and bad practices; database calls from the front end, no separation of concerns, no authentication, bloated state management that couldn’t be verified, to name a few. However, taking a broader view it wasn’t dreadful, there was the outline of a good project, there were sensible variable names, and it did at least appear to somewhat work. I compared it to a ‘big clumsy Figma file’.

I was shown an email thread stretching back months in which my boss, the head of SE, first had to explain in detail what was wrong with it. It was not simply enough to say “its vibe-coded garbage by a non-technical user”, he had to painstakingly detail exactly what was wrong, what the better practice would be, and why that matters. Effectively, he had to justify what we do what we do, and why we do it that way.

What followed was a back and forth on these points, each time my boss responding with a description of how we work, and each response being more “but what if” questions. The discussion subtly shifted from questions about why the rebuild didn’t work, to ‘when can you build a real version’, a scope of work which hadn’t existed before. The team had built themselves a vision of the thing they wanted, and had decided that they wanted it.

I’m not telling this story to have a go at the team in question, in fact I applaud their tenacity, and I appreciate their curiosity about what goes into our work, it was all very civil and a nice chance to share perspectives, no harm was done.

However, in my mind, this is a very lightweight taster of what’s to come, both as ‘citizen developers‘ continue to vibe code their own solutions to things and gain confidence in doing so, but also as executives and higher-ups learn that they can do the same thing.

How exactly would we respond if the head of Finance vibe-coded a version of our exec dashboard BI tool, showed it to the board, and then brought it to us saying “the board love this, how fast can we productionise it?”. And if that hypothetical is too obtuse, how long until a mid-level manager decides to cut headcount, or to massively reduce deadlines because “I’ve seen how fast things can go now, you don’t need all that resource”?

A common refrain to this type of hypothetical is to say something along the lines of ‘it will still need to be properly engineered / will still need expert intervention / still not be possible’, and while I agree I want to stress that the point is that the excuse of increased speed will potentially be used as a cudgel to:

• Reduce deadlines,
• reduce tollerances,
• ask for far more work and,
• pass the whip further down the orginisation hierarchy, each layer demanding more of the next.

Once again, we may gain the ability to do five times as much, what happens if we are then expected to do ten times as much?

An Example of Automation From My Own Life

I have experienced a type of ‘automation’ similar to the examples described here before, when I worked in Waitrose and Partners, Kings Cross Station. I like to return to this anecdote because it embodies the duality of automation; the change in capability making one aspect of life easier while increasing pressure elsewhere.

The branch I worked at is a very small unit off the main concourse of Kings Cross station in London, which features in the top-10 busiest national rail stations in the entire country. The layout is a C shape, with the main entrance at one end, the intended exit at the other, amongst a bank of checkouts.

2020 Redesign for Increased Throughput

Pre-2020 we had 5 staffed checkouts and 6 old self-checkouts (SCOs); large, clunky machines which were always breaking down, getting coins and notes stuck, occasionally shredding notes and so on. Even with 5 staff on the staffed checkouts, it was very common for us to have large trailing queues through the shop floor, with spontaneous queues forming when a large departure was about to leave. As you can imagine, this lead to a lot of abandoned items, customer frustration, stress for all involved.

In early 2020 the partnership finished a project to redesign the space, there would now be only three staffed checkouts tucked away in the corner, the rest of the space converted to host about 12 new “skinny” self checkouts, all mounted above a sort of continuous bench. To facilitate this, a magazine rack was removed to open up the approach even more and turn the space into a receiver area for people to spill into. The new ‘skinny SCOs’ were much smaller, did not accept cash, had no security scale, and packed in tightly.

More throughput means more work, is that bad?

One day in 2021, once traffic had just about returned to pre-pandemic levels, I was helping a customer when they turned and said “I bet you hate those sodding things”. I was perplexed. “I’m sorry what things?”. The customer half-turned and gestured towards the SCOs with a ‘get a load of this guy’ expression on their face, “These things! They’re putting you lot out of a job!”. The irony apparently lost that I was in fact still in the job and serving him at the time so clearly not redundant.

When the installation was first happening I was worried, not about loosing work but more about the mechanics of how this new system would work. With no security scales, the risk of theft was surely going to rise? Only three staffed checkouts? But at the moment we need all five, how are we supposed to manage with only three? And, most crucially of all, how is the one self-checkout attendant supposed to manage 20 SCO’s all on their own (removing duplicate scans, helping unsure customers, re-printing receipts, validating age-restricted products etc.)?

Material changes noted before and after

The reality was that, during peak times we barely had any queues forming. As the shop had increased capacity, and as customers gained confidence in using the shop without fear of delay (with wait times of about 2 minutes max), foot traffic increased steeply.

Each of the new SCOs required far less intervention then the old ones, and so each staff member could manage more, but there were also a lot more SCOs to manage. In quitter times in the past we might have been able to get away with two members of staff (one on tills, one on SCOs), now we’d require at least three, even during evenings. Now, during peak times, we’d get away with only two staff members on the staffed checkouts, while the majority of the effort was spent managing SCOs.

There was a noted increase in the amount of theft, but the financial loss was compensated by there being far more transactions overall. The increased incentive to pay with cash was not received well by many customers, but it sped up transactions overall and reduced the burden of the cash office, therefore the number of times we needed to interrupt service to refill the tills. The increased incentive to use a SCO reduced the line for the main tills, freeing them up for those that needed them (for cash payments and restricted products).

The burden of security was heavily shifted away from slower older systems like basket scales to the staff, including the blame when a large value theft occurred. What was once a job of standing, listening for errors and directing queues, became a job of watching customers like a hawk; we would stand in the centre of the new floor space, back to back, observing a section of SCOs each, ready to leap into action when required before returning quickly so as to regain view of the other customers. What was once a relatively low-attention task had become a reaction-test game, with potential thief’s understanding that momentary lapses in attention could be exploited to slip something into a bag without scanning it.

Because of the increased staff in that area, when there were dips in traffic we could more frequently perform routine tasks like tidying leaflet stands, refilling bags, and wiping down equipment with disinfectant. The result of this expanded work remit meant that the area looked much tidier than it ever did before.

Increased energy in the system means a new type of customer stress

My colleagues and I got really quick at spotting issues and darting in to fix them. The opened floor space meant we could move more dynamically, often sneaking up on customers, diving in and out with our little identity key fobs from the side to action things like age-verification by muscle memory. Sometimes we could do this whithout even looking at the screen, I got so used to the muscle memory I could do it behind my back on one screen while talking to a customer on the next. We’d dance and dart about the floor, fuelled by coffee and energy drinks, appearing to pop up from nowhere with a little “hi there! :)” to announce our presence and do something before disappearing just as fast.

Some customers thought this was hilarious. Others would laud our speed and attentiveness, especially those in a rush. It was common to see a customer encounter an age verification or accidental product double-scan, frustratedly slump and sigh, preparing to have to wait for an attendant, only to find I was already beside them dismissing the problem to their equal-parts surprise and delight.

Others would get quite upset, stressed out by the pace, the energy that was now enveloping them on the floor, arms and bags and baskets all flashing around them in a blur to a backdrop of chatter, audio instructions, flashing scanners and Network Rail platform announcements. In some cases they’d still be trying to explain an issue encountered to us, not realising that we had already dismissed it and had moved onto the next customer. I occasionally got accused of ignoring customers before pointing out that I had resolved the issue having seen it coming a mile off.

In quieter times I’d get to talk to some of these people, they acknowledged that it was a busy area, but were overwhelmed by the activity, the closeness of the others around them, the lack of time to adjust to each beep and flash of a scanner around them. All I could do was empathise with them and say that speed was the main priority, our main metric of good customer service, after all if you’re setting up for an intercity trip laden with bags and children and timetables, surely the last thing you need is to get stuck waiting for us.

Did the machines take my job?

Returning to 2021, I look back at the customer claiming that the machines were “putting [me] out of a job” and almost laugh. There was more work than ever! Had they known the reality of the situation they might have asked a more accurate question such as “How does the type of stress now compare to before?”. And I might have answered “Well, I don’t much like the increase in the amount of work, but I am really glad to no longer have to deal with as many angry customers any more.”.

Before the renovation, the throughput of customers was mostly determined by the speed of the machines, and partly by our role facilitating and unblocking the machines. Now, capacity was often not an issue at all. The new role for staff was to try to keep pace performing supervision for machines that themselves had specialised; sacrificing functionality to facilitate increased speed. A speed that eliminated customer tantrums and accusations that we made them late for their train.

We eventually opened new slots on our rota in the evening to bring in a couple of extra members of staff, boosting the overall numbers for the evening shift and allowing us to hire new people to increase overall headcount. I look back up at the customer, readying their bags to leave, and then again over at the marshaled line of SCOs, standing like a line of toy soldiers ready for their next engagement, and simply replied “yeah they’re alright I guess.”