The hidden costs of AI convenience
LinkRecently I reviewed a pull request for a feature that worked. It looked right on the page and did what had been asked of it. The problem only became visible when I looked at how it had been fitted into the rest of the system. State had been introduced where we had previously kept functions pure. Some data had been placed in the global system even though it belonged inside one module, while other data had been kept local even though the wider system needed to own it. Nothing was obviously broken. From an engineering perspective, however, the responsibilities no longer made sense. Developers made mistakes like this before generative AI. State is difficult to place well, especially when someone hasn’t yet built a mental model of the codebase. What changed was the speed and scale at which a mistaken idea could become a finished-looking implementation. I have come to think of it as giving someone a motorcycle when they previously had a bicycle. They can travel much further before a reviewer catches up, even when they are heading in the wrong direction.
AI also changed what happened after a review. In the past, a structural problem might remain because the work was already late and rewriting it cost too much. Now the author can give my feedback to an AI system and return with another implementation almost immediately. That sounds like an improvement, and sometimes it is. Yet generating another revision is cheap in a way that reviewing them is not. I still have to understand the new patch, determine whether the original problem was solved, and check whether any issues reappeared somewhere else. The harder part is that another revision does not necessarily close the knowledge gap between me and the author. If they did not understand why the first design was wrong, my explanation can become another instruction for the model instead of an opportunity to build that understanding. When the next attempt is still wrong, I have to reject it again. Cheap generation can multiply the artefacts through which the same unresolved disagreement passes.
This has changed my own work. I now write very little code directly. Most of my time is spent planning and reviewing work produced with AI. For example I work out where we need to change our data models, or decide whether functional changes belong in this system or another. Implementation has accelerated while review remains limited by how quickly someone can understand it. If this continues, review becomes the bottleneck. There is also a quieter cost. Repeatedly defending architectural standards takes technical effort and social energy. When nobody else appears to mind the loss in quality, it becomes tempting to let more things through. It would be easy to describe the increased output as productivity. More features are implemented, revisions arrive faster, and work that once required substantial effort can be generated in minutes. From where I sit, part of the cost has moved rather than disappeared. It has moved into review, rework and the growing dependence on the few people who still understand and care how the pieces fit together.
This article is about that movement. Bad code is not the main danger, and neither is some moral failure by workers who use convenient tools. The problem begins when successful output becomes detached from understanding. Two forms of dependence can then grow together. Workers can become faster while losing some of their ability to judge the work or continue without assistance. Their employer can produce more while allowing the knowledge needed to change direction to become scarce inside the organisation. If an outside provider owns the system supplying the missing capability, the organisation has not removed its dependence on skilled people so much as exchanged it for a dependence that its workers have even less power to negotiate. This sequence is a risk created by particular choices about training, work and ownership. It is not the inevitable result of using AI.
Output is not the same as capability
LinkThe pull request exposed a distinction that is easy to miss when work is measured in what gets delivered. Completion means producing an acceptable result while assistance is available. Capability means being able to explain why the result works, test the assumptions behind it, adapt it when the situation changes, and repair it when it fails. AI can improve the first without improving the second. A working feature therefore tells me less about the developer’s understanding than it used to. The code may contain good decisions, but I cannot infer who made them or whether the person submitting it can recognise when those decisions no longer apply.
Research on learning has started to find this gap outside software development. In an experiment with nearly one thousand secondary-school students, Hamsa Bastani and her colleagues found that access to GPT-4 improved performance during mathematics practice. When the assistance was removed, however, those students performed worse than students who had practised without it. A more constrained artificial tutor, designed to guide students without readily supplying answers, largely avoided this harm. The study does not prove that every use of AI weakens learning. It shows that completing assisted exercises successfully does not prove that the knowledge needed for later independent work has been acquired, and that the design of the assistance changes the result. (Bastani et al., Generative AI Can Harm Learning) A small study of software developers found a similar pattern in a setting closer to my own work. Judy Hanwen Shen and Alex Tamkin asked 52 developers to learn an unfamiliar Python library. The developers with AI assistance scored 17 per cent lower on a later assessment of conceptual understanding, code reading and debugging. The average time saving was not statistically significant. How people used the tool mattered: those who delegated most fully sometimes finished sooner while learning less, whereas more engaged ways of asking for explanations were less damaging. This was a one-hour experiment with a small sample, so it cannot tell us what happens across a career. It does demonstrate that producing code with a library and building a mental model of that library are different achievements. (Shen and Tamkin, How AI Impacts Skill Formation) The gap may also affect what people do when assistance disappears. In randomised experiments involving 1222 participants, researchers found that AI improved performance during mathematical reasoning and reading-comprehension tasks, but participants later performed worse without it and abandoned difficult tasks sooner. The exposure lasted only about ten minutes, which makes any claim about lasting workplace behaviour premature. Even so, the result points to a cost that output measures cannot see. Assistance can change not only whether someone knows how to continue, but also whether they persist long enough to find out. (Liu et al., AI Assistance Reduces Persistence and Hurts Independent Performance)
None of this makes AI a poor teacher by definition. A younger colleague of mine wants to learn more about full-stack development and uses AI on personal projects. He describes it as a mentor he can question, not as a machine that does the project for him. That seems like one of the most promising uses of the technology. He can ask questions whenever they arise, request another explanation and explore subjects for which a human mentor may not be available. My hesitation is that a learner can only ask from within what they already understand. A good mentor can notice that the question rests on a faulty assumption, choose a more useful next problem or insist that the learner wrestle with something before receiving an answer. An agreeable system can remain inside the learner’s frame, including the blind spots that the learner cannot yet name.
My point is not to preserve effort for its own sake or insist that competent people work without tools. Experienced developers have always relied on documentation, libraries, search engines, colleagues, and code they did not write. What matters is whether using a tool leaves enough understanding to exercise judgment when its answer is incomplete or wrong. For a developer, that means more than recognising that the programme runs. It means being able to follow the state, see where responsibilities belong, anticipate failure, and explain why the patch fits the wider system. Without that knowledge, assisted output can look like capability right up to the moment somebody has to take responsibility for it.
The new human bottleneck
LinkResponsibility is where the apparent efficiency runs into a limit. Another implementation can be generated in minutes, but deciding whether it belongs in a larger system still requires someone to reconstruct what it does and what assumptions it carries. As the volume of generated work grows, the scarce resource is no longer the ability to produce a plausible patch. It is the attention of people who can tell the difference between a patch that works and one that should be accepted. This resembles a problem Lisanne Bainbridge described in 1983. Automation designers tend to automate the tasks a system can perform and leave people to monitor it and handle the exceptional cases. Yet removing people from routine operation also deprives them of the practice and current understanding they need when something unusual happens. The person remains responsible for the part automation handles least well, at the moment competent intervention matters most. (Lisanne Bainbridge, Ironies of Automation) In software, an AI system can produce routine changes while developers are left to recognise an architectural conflict, investigate an incident, or recover when the generated solution encounters a situation outside its frame. A survey of 319 knowledge workers found that they perceived critical thinking shifting away from gathering information and executing tasks towards verifying information, integrating responses and overseeing the result. That is a real change in work, but the study does not establish that workers became better at those responsibilities. It records their own accounts, and its authors warn that participants sometimes confused reduced effort on the task with reduced critical-thinking effort. The survey also found that confidence in AI was associated with less reported critical thinking, while confidence in one’s own ability to perform and evaluate the task was associated with more. Verification therefore depends on knowledge that exists independently of the tool. (Lee et al., The Impact of Generative AI on Critical Thinking) In software, tests generated from a requirement can challenge an implementation, while tests generated after reading the implementation may reproduce its assumptions. A 2026 preprint found that faults in generated code could propagate into tests produced from that code, creating the appearance of a separate check without establishing one. This does not make AI-generated tests worthless. It means that using another model call, or even another agent, does not by itself answer who established the expected behaviour and whether they understood the consequences beyond the test cases. (Konstantinou, Tambon and Papadakis, On the risk of coding before testing)
Human approval is no stronger merely because a workflow requires it. A reviewer needs the knowledge to find a problem, the time to investigate it and the authority to reject work that appears finished. Even when colleagues accept my judgment if I insist, insisting has a cost. I have to explain why working code is still wrong, request another revision and risk appearing to obstruct delivery. If maintaining a standard repeatedly becomes one person’s private burden, that person will eventually choose which arguments are worth having. I have learned to let some things go when nobody else seems concerned about the resulting loss of quality. The expertise remains, but the organisation receives less of the care that expertise could provide. When review fatigue leads to quiet surrender, the damage does not stop at the repository. The junior developer whose flawed pull request is finally merged receives false confirmation that their design was sound. Sprint metrics register quick delivery, but the chance to build a mental model has been lost. The company slowly produces a cohort of engineers who can prompt an agent through an assignment, but who have never had to defend a data model or debug a subtle corruption of state without a machine generating their responses.
Early research on AI-assisted open-source development suggests that this redistribution may extend beyond my experience. One working paper found that, after the adoption of coding assistance, less-experienced contributors produced more code requiring rework, while experienced core developers reviewed 6.5 per cent more code and produced 19 per cent less original code. The study is recent and limited to the projects it observed, so it does not establish that AI makes every software team less productive. It identifies a cost that measurements of generated code or completed features can miss. Faster production by one group can consume the time of another group through review, integration and maintenance. (Xu et al., AI-assisted Programming May Decrease the Productivity of Experienced Developers by Increasing Maintenance Burden) This is not simply a complaint that senior developers now review more work. Review has always been part of collaborative software development, and more accessible implementation can allow more people to contribute. The problem arises when an organisation counts the additional output without accounting for the judgment required to make it usable. Generation can scale faster than understanding, while the people providing that understanding write less code, carry more responsibility and spend more social effort defending decisions that the rest of the process no longer teaches. What first looks like an individual knowledge gap then becomes an organisational dependency on a shrinking bottleneck.
When a company can outsource its ability to judge
LinkAn organisation does not escape this bottleneck by purchasing more capability from outside. Wesley Cohen and Daniel Levinthal used the term “absorptive capacity” for a firm’s ability to recognise the value of external knowledge, understand it and put it to use. Their argument was that this ability depends on related knowledge already present inside the firm. Internal research therefore does more than produce inventions. It also teaches an organisation enough to evaluate discoveries made elsewhere. Later research on AI implementation reaches a similar conclusion. Combining a model with real work requires technical knowledge, domain knowledge and an understanding of the organisation in which it will operate. Buying access to an AI system does not remove those requirements. It can hide them until the organisation needs to determine whether the system is wrong. (Cohen and Levinthal, Absorptive Capacity: A New Perspective on Learning and Innovation) (Weber et al., Organizational Capabilities for AI Implementation)
Those studies establish that outside knowledge still requires knowledge inside the organisation. They do not establish that generative AI has already caused a long-term decline in organisational capability. The danger I see is a sequence that can follow when a company rewards assisted output but does not protect the work through which people learn to judge it. As an AI system supplies more implementation, fewer workers may take part in the reasoning through which knowledge of the work is acquired. What remains can then become concentrated among reviewers who have less time to produce, teach and document because they are checking a growing stream of output. The organisation may still deliver more in the short term while becoming worse at deciding whether the tool suits the work or what it would have to rebuild if the system disappeared. Replacing the tool then looks increasingly expensive. The people who could lead the replacement are busy sustaining the current arrangement, while everyone else has been organised around using it. The switching cost is no longer confined to a contract or an interface. It includes knowledge the company allowed to become scarce.
This delayed cost is easy to overlook because today’s experienced workers acquired their judgment under an earlier arrangement. They can review generated work even if fewer junior workers now participate in the decisions, mistakes and corrections through which that judgment developed. Routine junior tasks are not valuable merely because they are slow, and automating them does not necessarily prevent learning. The organisation still has to provide another route into the whole work. People need to attempt consequential tasks, see what follows from a decision and receive correction before they gradually take responsibility. Research on workplace apprenticeship describes professional knowledge developing through participation in real situations and communities of experienced workers, including knowledge that cannot be transferred through instructions alone. (Sappa and Aprea, Both novice and expert?) (Aarkrog, Stories of Learning) If generated output replaces that participation while workers must fit training around delivery, a company can consume expertise without reproducing it. That is my interpretation of how the learning research and the organisational evidence meet. No longitudinal study cited here has demonstrated the whole sequence. It is a warning about what a company makes possible when it removes practice without funding another route to independent judgment.
Nor does technical efficiency decide what an organisation does with the capacity it creates. If automated content takes half as long to produce, the saved time might support more contact with clients, paid learning or shorter working hours. It might instead support more content, more clients or fewer employees. The tool cannot choose among those outcomes. Budgets, targets and authority do. The comparison with the rebound effect in energy use is useful as long as it remains an analogy. When efficiency makes a service cheaper, demand for that service can rise and absorb part of the expected saving. The size of that effect varies, and research on energy does not prove that AI will increase every workload. It does show why a technical saving should not be mistaken for a social decision about how the saving will be used. (Gillingham, Rapson and Wagner, The Rebound Effect and Energy Efficiency Policy) This is why telling workers that they are free to experiment is not the same as investing in their ability to use AI well. Learning requires paid time, access to experienced colleagues and room to make decisions slowly enough to understand them. Without those commitments, the worker carries the cost of adaptation while the organisation receives whatever additional output they manage to produce. A company can then mistake access to a tool for possession of a capability, just as it can mistake completed work for a knowledgeable worker. In both cases, the difficult knowledge still exists somewhere. The question is who retains it, who pays to maintain it and who gains power when everybody else depends on access.
Productivity can rise while workers lose leverage
LinkThis question is easy to miss when a study reports a productivity gain. Erik Brynjolfsson, Danielle Li and Lindsey Raymond studied more than 5000 customer-support workers after the introduction of an AI assistant. The number of issues resolved per hour rose by about 15 per cent, with the largest gains among novice and lower-performing workers. Customers also treated workers better. These are meaningful improvements. The system appears to have made practices found in successful support conversations available to people who had not yet acquired them through experience. It raised their performance while they used it. The study did not test whether those workers retained the knowledge without the assistant, whether their wages rose, or whether they gained more say over their work. (Brynjolfsson, Li and Raymond, Generative AI at Work) Raising output among less-experienced workers can narrow the visible difference between them and their more-experienced colleagues. That does not tell us what has been compressed. Workers may have become more capable, or the tool may be supplying the part of the capability that previously distinguished them.
My interpretation is that employers and customers can respond to that visible compression before they know whether understanding has spread with the output. A 2026 study of 49.610 active freelancers on Upwork found that clients in more AI-exposed categories placed less weight on workers’ education, employment history, reputation and profile information after ChatGPT, while price became more important. Demand shifted towards lower-priced workers and the advantage held by workers with stronger records declined. This is one online market, and the paper is still a preprint. It does not show that AI made the workers equally knowledgeable or that every client regarded them as interchangeable. It shows a market behaving as though previous signals of experience mattered less. That is the connection I draw between compressed output and weaker worker leverage. (Siddiq and Zhang, Human Capital, AI, and Labor Commoditization)
Where AI substitutes directly for work sold through a platform, the loss is already easier to observe. Özge Demirci, Jonas Hannane and Xinrong Zhu found a 21 per cent relative decline in postings for automation-prone writing and coding work during the eight months after ChatGPT, compared with work requiring manual skills. Image-generation tools were followed by a 17 per cent decline in image-creation postings. The remaining exposed jobs were more complex and better paid, but competition for them increased. This does not describe the whole labour market. It shows what happens in a market where clients can quickly replace a purchased task or ask fewer people to perform it. Fewer opportunities weaken a worker’s outside options, which matter because the ability to refuse a wage or leave for another job helps determine how much of a productivity gain the worker can claim. (Demirci, Hannane and Zhu, Who Is AI Replacing?) A recent working paper by José Azar, Mireia Giné and Javier Sanz-Espín reports the same connection more directly. Greater exposure to generative AI was associated with lower posted and starting wages, fewer job-to-job moves and a weaker tendency to leave in response to pay. The authors interpret this as evidence of greater employer power in the labour market. The paper was revised in August 2026 and has not yet been peer-reviewed, so it should be read as emerging evidence rather than a settled estimate. (Azar, Giné and Sanz-Espín, The Wage Effects of Generative AI)
Economy-wide evidence is less conclusive. Research linking AI-use surveys to Danish employment records found extensive adoption and reported changes in work, but no average effect larger than 2 per cent on earnings or recorded hours during the first two years after ChatGPT. Finnish population data likewise found no statistically significant difference in wages or employment between occupations with higher and lower exposure over the same early period. These findings do not support a simple story in which AI has already produced large, general reductions in pay or employment. They do not show that productivity gains will be shared. Taken together with the studies of assisted performance, they give us no reason to assume that higher output will automatically become higher pay, shorter hours or greater autonomy. (Humlum and Vestergaard, Still Waters, Rapid Currents) (Kauhanen and Rouvinen, Assessing early labour market effects of generative AI) Worker leverage also concerns control over the job. Employers already use algorithmic systems to allocate tasks and schedules, monitor performance, evaluate workers and decide rewards or sanctions. A worker can keep the same wage while losing discretion over pace, method and the standard by which the work is judged. (OECD, Algorithmic management in the workplace) None of these outcomes follows inevitably from the model. They depend on who owns it, who sets the targets, whether workers retain scarce knowledge, what alternatives they have and whether they can negotiate over adoption. The point is narrower and more uncomfortable than saying that AI takes jobs. A worker can become more productive and easier to replace at the same time. A business can gain more output from its staff while becoming less able to replace the provider supplying that output. Useful output spreads, while control over its terms moves upward.
We have fought over the terms of automation before
LinkThe historical conflict over automation is rarely about rejecting machines. It is about who captures the dividend of greater output and who carries the cost of degraded craft. In 1811 protests began during a period of war, high food prices, unemployment and falling incomes. Families who had made a living from textile work were already under pressure when manufacturers found new ways to reduce labour costs. Machinery did not arrive in a stable trade whose workers could calmly negotiate how it would be used. Calling them opponents of progress removes the material question that confronted them. What did a more productive machine mean for someone who was already losing work, wages and influence over the trade? The Luddites fought over their conditions and their control of the trade. The people who resisted were not strangers to technology. Many were skilled machine operators, and some of the equipment they attacked had existed for generations. Their objection concerned what manufacturers did with it. Wider frames and other production methods allowed owners to divide work differently, employ fewer skilled workers and use cheaper labour, including workers who had not completed an apprenticeship. Some methods also produced goods that trained workers regarded as below the accepted standard. The Luddites described manufacturers who used machinery this way as “fraudulent and deceitful” because they were evading rules that had governed entry into the trade, product quality and pay. Those rules were not merely a romantic defence of craft. Apprenticeship gave workers some control over how knowledge entered the trade. Quality standards connected that knowledge to the value of the finished goods. Wage customs and regulation limited an employer’s ability to turn every increase in efficiency into lower labour costs. The machinery weakened the workers’ position because owners could bypass that arrangement without transferring control to the people operating it.
Supporters of machinery argued that cheaper production would benefit the many even if a smaller group lost employment or wages. The National Archives collection places that argument beside a magistrate’s report that wider frames were reducing wages, accounts of unskilled and child labour, and an appeal published after Parliament rejected a minimum-wage proposal. Workers had therefore sought protection through rules and politics before machine-breaking came to define them in public memory. The two sides were answering different questions. Manufacturers and their supporters pointed to lower prices and greater output. Workers asked who would carry the loss of income, status and control during the transition. Parliament eventually answered through force as well as economics. It made machine-breaking a capital offence in 1812, sent thousands of troops into the affected regions and executed 17 men at York in January 1813. The new organisation of production did not prevail through technical superiority alone. Property law and state violence defended the owners’ authority to decide how machinery would be used. (The National Archives, Why did the Luddites protest?) (Richard Conniff, What the Luddites Really Fought Against)
Generative AI is not a stocking frame, and today’s knowledge workers are not handloom weavers entering the first factories. Many workers can use the same AI systems as their employers, and models can provide access to knowledge and productive abilities that were previously difficult to obtain. The customer-support study demonstrates that benefit. A language model also does not contain a complete and stable version of a craft that can replace everyone who practises it. The comparison concerns a particular transfer of power. In both cases, machinery lets an owner reorganise skilled work before the workers affected have agreed how the benefit and loss will be divided. Acceptable output can spread beyond the workers who developed the underlying skill. Workers may then retain responsibility for the result while losing practice and control over the system that makes the result possible. Owners can change staffing, pay and training before anyone knows what will happen when the remaining expertise is lost. Higher productivity does not settle whether workers gained knowledge, received a share of the benefit or had any say in the transition.
The historical parallel is strongest between workers and the owners reorganising their work. It is weaker on the other side of my argument. A textile manufacturer who owned a frame did not depend on its maker in the same way that a company using a hosted model can depend on the provider’s continuing access, prices and product decisions. That difference does not break the comparison. It shows what generative AI adds to the older struggle. An employer can use the technology to reduce its reliance on workers’ knowledge while becoming more reliant on the firm that supplies the technology. Power does not simply move from workers to their employer. Some of it can pass through the employer and settle with a provider that neither the workers nor the business can readily replace. The Luddites’ question therefore needs a modern addition. Who controls the machine and the work organised around it, and who controls whether the machine remains available at all?
The provider behind the workplace
LinkAn employer that uses AI to reduce its reliance on skilled workers may create a different reliance on the provider. The risks are separate. A knowledgeable team can depend on a closed service while remaining able to do the work more slowly, and a company can run its own model while allowing its employees’ skills to decay. They become most dangerous together, when workers cannot proceed without the system and the organisation cannot control or replace it. Generative AI makes that combination plausible because specialised chips, computing capacity, data, technical expertise and routes to customers are concentrated among a small number of firms. European, British and American competition authorities have warned jointly that control over these inputs can become a bottleneck and that established firms may extend their power through cloud platforms and other routes to market. A company adopting AI may therefore place more of its ability to act behind infrastructure controlled elsewhere. (European Commission, CMA, DOJ and FTC, Joint statement on competition in generative AI foundation models and AI products) Dependence develops through ordinary technical decisions rather than one irreversible contract. A company connects a provider to its documents and databases, rewrites processes around the model’s interface, builds evaluations for its particular behaviour and teaches employees how to compensate for its weaknesses. Each decision may be sensible on its own. Together they make changing providers more expensive because the organisation must move data, replace integrations, retest outputs and retrain staff while continuing to serve customers. The UK’s Competition and Markets Authority found that technical barriers, data-transfer charges and commercial arrangements could make switching and using several cloud providers more difficult, contributing to an adverse effect on competition in cloud services. (Competition and Markets Authority, Cloud services market investigation) Model services add another source of dependence because their capabilities are not fixed products that a customer necessarily gets to keep. Providers retire models and require customers to migrate to replacements. There are legitimate reasons to do this: maintaining every version indefinitely would consume resources and leave old systems unsupported. The problem is not that a provider ever changes its service. A customer may have built a business capability around behaviour, price and availability whose future that customer cannot decide let alone control. A replacement can be better overall and still behave differently enough to require new prompts, tests, safeguards or approval. The migration timetable belongs to the provider even when the cost belongs to the customer. (OpenAI, Deprecations)
Open models offer one route out of this arrangement, but the word open covers materially different things. Publishing model weights can allow another party to run a model without sending every request to its original developer. That creates possibilities a closed service does not: a business can keep sensitive data on infrastructure it chooses, modify the model, retain a working version and move between hosting providers. It does not necessarily reveal what training data shaped the model, provide the code needed to reproduce it or grant a licence permitting every use. The Open Source Initiative therefore requires more than downloadable weights in its definition of open-source AI, including code and sufficiently detailed information about the training data for someone to understand and substantially recreate the system. (Open Source Initiative, The Open Source AI Definition) Even a genuinely open model can carry biases from its training data, and running it independently still requires hardware, energy and people able to maintain it. Nor does openness require publishing every highly capable model without conditions. Releasing weights can enable misuse and cannot be reversed, but restrictions should respond to demonstrated risks rather than quietly turn one provider’s control into the definition of safety. Independent evaluation, controlled research access and delayed release leave more possibilities than a choice between immediate unrestricted publication and permanent private ownership. (OECD, AI openness: A primer for policymakers) Openness does not make a system neutral, cheap, simple or harmless. It provides an exit option against commercial lock-in, but it does not resolve the internal judgment problem. If an organisation hosts an open model locally while its developers have forgotten how the underlying software works, the company has only traded a cloud dependency for a local system it still cannot alter or critically direct.
This is why technological sovereignty cannot be reduced to the nationality of the provider. A closed European service can leave a European customer with less control than an openly licensed Chinese model that the customer can host, retain and modify. Building European models and computing capacity may reduce reliance on foreign firms, especially when laws or geopolitical interests diverge, but replacing one national champion with another does not by itself distribute power. The practical test is whether a worker, business or public institution has a credible way to leave. Can it retrieve its data, preserve the capability it depends on, understand how that capability was produced and move to another provider without rebuilding the organisation around it? Not every company will run its own large model, just as most do not operate their own electricity grid or manufacture their own servers. Independence does not require producing every input alone. It requires alternatives that are technically possible and economically viable. A dependency becomes more dangerous when the supplier cannot be replaced, the customer no longer understands the work, and short-term convenience has been allowed to remove every exit.
Preserve the ability to leave
LinkSimply refusing AI altogether is not a serious answer to this problem. A business may face pressure to use the most effective system available when competitors adopt it, and a worker may reasonably use a tool that helps them perform a task, learn something new or protect their job. Proprietary services can also be cheaper, easier to operate and more capable than systems an organisation could run for itself. Those immediate advantages are important. They are also why voluntary restraint by individual workers or businesses will not prevent dependence. Each adoption can make sense on its own while leaving everybody with fewer choices later. The aim should be to use AI without allowing today’s useful service to become tomorrow’s only possible way of working.
Preserving the ability to judge requires more than placing a human at the end of the workflow. Workers need paid time to practise, access to experienced colleagues and the authority to reject output that fails a standard. They can ask concrete questions when AI enters their work. What knowledge must remain within the team? Who will be given time to develop it? Who reviews the additional output, and does that work count when productivity is measured? What happens to the time saved? These are questions about budgets and power, not personal enthusiasm for technology. An employer cannot tell workers to adapt on their own time, treat the resulting knowledge as an organisational investment and hold them responsible for decisions they were never equipped to assess.
Organisations also need the ability to move. This means keeping data in formats that can be exported, separating business rules from one provider’s interface, recording which processes rely on a particular model and maintaining evaluations that can be run against a replacement. A migration route should be tested before a price rise, product retirement or political dispute makes it urgent. None of this guarantees a painless switch. Another model may behave differently, and independent hosting may cost more. The purpose is to know the cost while the organisation can still decide whether to pay it. Retained expertise is part of that route. Portable files are of little use when nobody understands how they fit together, just as knowledgeable employees cannot move a system whose data and interfaces remain locked to one supplier. The ability to leave has to exist in the technology and in the people who operate it. Organisations can only move if alternatives exist beyond their procurement documents. Maintaining those alternatives requires investment by governments, universities and businesses in interoperable standards, open systems, and computing infrastructure that is not controlled by one supplier. Individual employees cannot build that infrastructure, and choosing a different chatbot will not solve a political problem. They can still make dependence visible at work, support portable systems and reject the idea that adapting to a foreign company’s service is solely their private responsibility. These demands will not decentralise AI by themselves, but they put the right question into workplace and political discussion: whether the people expected to rely on a system retain any credible alternative to it.
I do not see a single bargain or policy that settles who will benefit from AI. Workers will still disagree about its use, businesses will continue to choose short-term survival, and governments will balance access against risks. A useful direction is nevertheless clear. Preserve the knowledge that makes judgment possible, build systems that can be moved and maintain alternatives outside the firms that currently lead the market. Then argue over how the additional output is divided, whether it becomes higher pay, shorter hours, better service or simply more work. The hidden cost of AI convenience is paid when a worker can produce but cannot judge, a company can deliver but cannot change provider, and a society can use a technology but cannot set its terms. The motorcycle is useful. We should still know where we are going, remain able to steer and have somewhere else to go when the owner of the road changes the price.