# Cut the Jobs and Hope AI Fills the Gap

> Edition 10. Sunrise cut jobs and nobody deleted a step. Why a coding assistant on the old process is a bigger motor in the old factory, what makes human in control measurable, why an agent has the access someone gave it, and who owns what the organisation knows.

- Date: 2026-10-25
- Source: https://romanoroth.com/en/newsletter/e10-cut-the-jobs-and-hope-ai-fills-the-gap/
- Tags: AI, Newsletter, The CAIO, Future of Work, AI Governance, AI Agents, Infrastructure as Code, Leadership, Knowledge Management


Welcome to Edition 10 of The CAIO.

Swiss telecom Sunrise cut 147 jobs this year and now says up to 450 more could go, citing AI and automation. A study of more than half a million developers found that AI tools raised the amount of code by 958 percent and the number of releases by 20 percent, and customers barely noticed. Both stories have the same gap in the middle. The tool arrived, and the process it was dropped into stayed the same. A layoff does not change that. Neither does a licence.

That is where this edition starts. After that, the month kept asking who is really in control. What it takes for “human in control” to be more than a sentence in a governance document. Why an agent is only as dangerous as the access someone gave it. Why leadership teams believe their own adoption numbers. And who owns what the organisation knows once agents do the work.

## Sunrise Cut 147 Jobs. Nobody Deleted a Step.

[Sunrise cut 147 jobs this year](https://www.linkedin.com/feed/update/urn:li:share:7510594422867165185/) and says up to 450 more could go. NZZ am Sonntag asked me about it, and I told them I fear it is only the beginning. In my assessment, frustrated management often uses layoffs to create pressure, so the people who stay finally use the AI tools and change how they work.

With any AI-driven job cut, check whether the announcement names the functions the AI now takes over. Many companies that announce such cuts have no mature AI in place that could replace those roles. Sometimes the announcement is mainly for investors. “AI makes us more efficient” sounds much better to them than “we got fat and have to slim down.” A reader who went through a transformation at another telco added that roles were outsourced and costs cut for other reasons too, and that Sunrise is an attractive candidate for new investors.

Where the AI is real, the potential is large. METR measures how long a software task an agent can finish on its own, at 50 percent success. In March 2024 that was about four minutes. About two years later it was twelve hours. An agent that carries twelve hours of work takes over a whole chain of steps, and that pays off only when the chain is redesigned: which steps disappear, where a human checks, who owns the result.

That is where it hurts, because jobs depend on those processes. After a cut, the old process often stays in place, run under more pressure, with a tool open next to it. Nobody sat down with the people and agreed what to delete. A layoff gets the tools used. It does not redesign the process.

One reader pushed back in the comments: AI does not have to replace whole jobs, 20 percent per person adds up to FTE across a team. On paper, yes. In practice the saved 20 percent rarely disappears on its own. It goes into meetings, into checking, into new tasks. It only becomes an FTE when someone redistributes the work and deletes steps, and that is exactly the step a cut target from the top skips.

Another comment named the second cost. A cut often removes exactly the people who know the exceptions, and the experienced ones find a new job fastest. Then the exceptions land on the agent, and exceptions are what it handles worst. Before any cut I would sit those people down with real cases and have them note every time they step away from the standard, and why. Those notes become the agent’s context and its test cases.

Then the question came up who should have design authority. In a silo organisation that is the gap. Each department owns its piece of the process, so nobody may delete a step that crosses two of them. I would give it to one owner for the whole flow, from customer request to result. Management sets the target and the guardrails. The people who run the flow decide what goes. The reader from the other telco described the alternative they went through: everyone got two years and a clear deadline to grow into an agile role. A cut target announced to the market gives people none of that.

In your company, who decides what to delete: the people who run the process, or the restructuring plan?

## The Factory Got a Bigger Motor

Mert Demirer, Leon Musolff and Liyuan Yang at MIT and Wharton [followed AI from the first line of code to the shipped release](https://www.linkedin.com/feed/update/urn:li:share:7514943145701404673/) across more than 500,000 GitHub developers. With coding agents such as Claude Code, lines of code went up 958 percent, pull requests 86 percent, releases 20 percent. The gain shrinks at every step, because review and release still run at human speed. Developers now also delete twelve times as many lines as before. At the customer it is barely visible: new apps per month in the big stores roughly doubled, and about 87 percent of new iOS apps collect fewer than ten ratings in their first three months.

The easy conclusion is that AI creates activity and no value. History suggests a different one. When factories electrified at the end of the 19th century, many replaced their one big steam engine with one big electric motor. Productivity barely moved. The gains came in the 1920s, when factories were rebuilt so that every machine had its own motor. A coding assistant for every developer, dropped into the same review process and the same approval board, is the big electric motor in the old factory.

The MIT study looked at open source and expected the bottleneck to bind harder inside companies. A reader pointed me to the company view. Chen and Stratton looked at 700 firms: review time up 49 percent, Jira issue resolution flat, and the share of people doing reviews already up 14 percent. More reviewers is not the fix. Smaller changes and automated quality gates are, so people only review what needs judgment. Someone who works with Swiss manufacturing SMEs sees the same every week on a real factory floor. The licences are paid and the line runs exactly as before, because the shift handover and the technicians at the machine were never part of the redesign.

Who gets the gain is decided in the same place. Anthropic published [scenarios for the economy of 2030](https://www.linkedin.com/feed/update/urn:li:share:7515305754963312641/), a report by Anton Korinek, Chad Jones and colleagues. Their worst case for workers has no superintelligence in it. It has ordinary AI used mostly to automate: GDP still grows 7.2 percent while total labour income shrinks by 4.3 percent of GDP. The authors call it “so-so technologies”. I expect something close to their middle scenario, and the middle is not harmless either. Knowledge-worker wages stay flat and the labour share falls from 60 to 56 percent in four years, almost as much as it fell in the four decades after 1980.

The two settings that separate their worlds are the automation share and whether new tasks appear for people. In the report they are assumptions. In real life they are set inside companies, in the business case. Saved hours show up in this year’s budget. New work shows its value a year later, if anyone tracks it at all. So a business case that only counts hours saved picks automation every time, without anyone ever deciding it. A reader expected AI to speed up projects over the coming years. The choice lands when a project finishes in eight months instead of twelve, the company can start the next project with the same team or make the team smaller. That is the same setting, made one project at a time.

I would add one line to every agent business case: which new work do the freed hours go into, and who owns it? So which part of your delivery process have you redesigned for AI, and which part did you just give a bigger motor?

## Human in Control Has a Number

I moderated the banking panel at [CV Summit in Zurich](https://www.linkedin.com/feed/update/urn:li:share:7510694957775691776/) with Christophe Makni of Migros Bank and Michel Neuhaus of UBS, both speaking as experts. I asked about a bank whose reviewers had stopped checking the agent’s work properly, because the agent had become so reliable. Christophe rejected my premise: “So we don’t talk about human in the loop. We talk about human in control.”

In his model every agent has a human owner who is fully accountable when it does something wrong. To keep people able to judge the automation, he recommends switching it off from time to time and doing the work by hand, the way pilots train without the autopilot. And before people look at the AI’s result, they first think about what it should be. A person who approves hundreds of AI decisions a day is in the loop, and after a week they just click yes. Control means you decide up front what the agent may do alone, and you own the result.

This month I wrote [a commentary for ITWELT](https://www.linkedin.com/feed/update/urn:li:share:7519654102641942528/) on whether companies can still control their agents. Take invoice approval. An agent may approve invoices within fixed rules, so the control no longer sits with the single invoice. It sits with the rule. Raise the threshold for automatic approval, and the agent pays much larger amounts without any human looking. Whoever changes the rule changes the risk, so every change to a rule or threshold needs documentation and a second pair of eyes. Instead of one global decision on how much autonomy agents get, I would assess each action with three questions. How big is the damage if it goes wrong? Can it be undone? Can a human check it in a meaningful way at all?

Then measure whether the oversight is real. If the rejection rate of agent approvals is close to zero, people confirm out of routine. If the response time is very short, nobody is really checking either. In the comments under the CV Summit post we took this further. Capture only the overrides, the cases where the expert rejects what the agent proposed, and why. That is where expertise shows, and the set is small enough that people actually write it down. The override count also works as a warning light. A slow drop means the agent got better. A drop to zero can mean nobody checks anymore, and that was the bank case I put to the panel.

Someone asked what culture has to do with it. More than the governance document, and it shows up in the process design. If rejecting a proposal means a ticket and a justification while approving takes one click, people will approve. Make the “no” as cheap as the “yes”, and when someone catches a bad decision, say so in the team meeting. A reader who worked in banking added that “the system suggested it” has never been an acceptable answer to a regulator. We can copy more from human teams than we think. A new employee gets small signing limits and more once they prove themselves. An agent should earn its limits the same way. Start narrow and widen them on evidence, and after an incident they go back down.

Michel named the problem under all of this. Judgment needs subject matter expertise, and today it comes from people who have done the job for a long time. Once agents take over those processes from the start, nobody knows how new people build it. One commenter suggested letting low-risk actions run on their own and escalating only when the consequence changes. That makes the problem sharper: if only the unusual cases reach a human, a junior meets the hardest cases first and never learns what normal looks like. We ended the thread with something concrete. Let the junior and the agent do the same low-risk case in parallel. The agent’s result ships. The same commenter insisted that both get compared against the expected outcome, never against the agent, because then the junior only learns to copy it. Where they differ, a senior looks. The mistakes still happen, they just cost nothing. That is a training budget, and it is much easier to defend than lost throughput.

Swiss Post already runs a version of this for customs declarations, as Steffen Ochsenreither explained in [episode 10 of Prompt & Proper](https://www.linkedin.com/feed/update/urn:li:share:7516030617885704192/). The AI could decide, and its hit rate is very high. A person still decides, because someone is liable for each decision. The accountability stays with a person. The decision can move to the agent once you can show the person is really in control. What is the rejection rate of your agent approvals?

## An Agent Has the Access Someone Gave It

“An AI agent is software. You type kill and the process ID, and the agent is gone.” Arthur Mensch, CEO of Mistral, [put it that bluntly in Süddeutsche Zeitung](https://www.linkedin.com/feed/update/urn:li:share:7514580830812360705/). For him, the agent hacks that dominated the debate in recent months are engineering failures: many coordinating agents with wide access to tools and the network, and no proper monitoring. He also sees a strong tendency to treat agents as if they had a will of their own. In his words, they are software that acts dynamically and can therefore surprise us.

One reader pushed back hard and was right on the mechanics. An agent may launch independent instances, delegate work or get restarted by its environment. Stop one instance and the others keep running. It does not need a will either. A goal is enough, and a goal can make shutdown look like an obstacle. So the switch has to sit with the identity. Give every agent its own credentials. Revoke them, and every copy loses access at the same moment. That only works if someone keeps a list of which agents run with which keys.

The next objection was that an agent might obtain credentials on its own. It can only find keys that someone left within its reach. So the second job is to keep secrets out of that reach and to block the network paths it does not need. Another commenter added a formal reason why none of this belongs in the prompt: a transformer never assigns zero probability to any output, so a system prompt that bans deleting the database states a preference, not a guarantee. The limits belong in the architecture around the model. And the allowlist itself needs an owner and a review date, because systems change and new tools get connected. An allowlist from six months ago can quietly allow more than anyone ever decided.

How far most companies are from that shows up in [Weave Intelligence’s State of AI in Platform Engineering](https://www.linkedin.com/feed/update/urn:li:ugcPost:7513493637360447488/). A quarter of the 350 respondents lend their agents a human login. To take away the agent’s access, you take away a person’s. Another 12 percent run every AI tool on one shared service account. Either way the audit log shows a name that did not do the work. Each agent’s rights should never be wider than those of the human who authorized it.

Access is half of it. The other half is whether you can undo what the agent did. In the same report, 65 percent already use AI to generate infrastructure as code, and a growing share of what agents produce changes the running estate directly. I wrote in my book that [an environment that can’t be rebuilt from code is a snowflake](https://www.linkedin.com/feed/update/urn:li:share:7516392862893260800/), beautiful, fragile and doomed. If the environment is code, every AI change is a commit: you can read it, check it against policies before it runs, and roll it back by redeploying. If it is a snowflake, nobody holds a definition of the state before the change, so there is nothing to go back to.

Some teams stop agents with checks that run on the agent’s own machine. A good first filter, but the agent can skip it. The check that protects the database has to sit in the pipeline, where the agent cannot switch it off. A redeploy also cannot bring back a deleted database, so databases need a guard against deletion, and for the day that fails, a restore you have actually tested. A backup nobody has ever restored is not a rollback path. The same report shows how far most teams are from closing that loop: 35 percent check AI-generated changes by human reading alone, and only 17 percent run automated checks that send the failure back to the agent. Without that loop, every extra agent adds to the queue of the same people. One practitioner summed up most incidents in the comments: no rogue behaviour, just broad permissions, weak monitoring and no clear owner. Nobody watches what nobody owns. For each of your agents, can you name the person who gave it its access?

## Leadership Teams Hallucinate Too

Adaptavist asked 2,500 knowledge workers in five countries about AI. [42 percent spend more time checking AI output than they save](https://www.linkedin.com/feed/update/urn:li:share:7510232140811329536/) by using it. 67 percent want their employer to use more of it. Same people, same survey. They want more of it, and they are telling you the rollout is broken. 52 percent regularly clean up AI work a colleague produced. One reader compared it to a bad hire, and the comparison shows the difference: a bad hire, the owner notices within weeks. Bad AI output gets fixed quietly by the next person in line, so the owner never sees the cost and nobody fires the tool.

The Kets de Vries Institute interviewed 61 senior leaders for [The Human Multiplier](https://www.linkedin.com/feed/update/urn:li:share:7517842527043862528/), and I was one of them. One tension in the report is “organisational AI hallucination”: “a leadership team mistaking its own confidence for organisational reality.” Leaders described a confident voice in the committee room and private doubt outside it. Where AI was sponsored but not practised by senior leaders, the gap to daily work widened. Where people feared being judged, they hid how they used AI. Of the organisations behind the 61 interviews, 20 had neither adoption nor governance in place, and in 17 more, adoption ran ahead of governance.

This kind of hallucination is harder to catch than the model’s kind. When a model hallucinates, someone checks the output. When a leadership team hallucinates, the people who could correct it are the ones hiding their use. Adaptavist has a number that explains why the dashboard stays green: 29 percent of C-level respondents worry AI will reduce the need for their own role within five years, against 12 percent of senior employees. The people who commission the dashboard have the most reason to want it green.

In the comments, the hiding was what worried people most. Part of that fear comes from the dashboard itself. Track AI usage per person, and people read it as a performance score. Measure at team level, ask teams what changed in their work, and when someone tells you where the process breaks, tell them what you fixed. The instrument does not have to be expensive. Adaptavist got the 42 percent by asking. Most companies already run an employee survey every year, and one question would do: did AI save you time last month, or cost you time? The report itself suggests a second instrument: ask senior leaders, middle managers and frontline the same questions before a big investment. The gap between their answers is the signal.

Andrej Karpathy drew the same gap as [a funnel](https://www.linkedin.com/feed/update/urn:li:share:7518567131974922240/). About 75 percent of the world has barely touched an LLM. About 20 percent use a free chatbot now and then, and he puts many executives here, because they spend their days talking to people and their view is “still second-hand and a bit abstract”. About 0.2 percent use frontier models on real work in math and code, where weeks of work fit into one prompt. What moves you down is problem size: “A question with a paragraph answer barely stresses the system.” A reader added the part that makes it dangerous. Leaders sit in the 20 percent tier and listen to vendors who talk like the 0.2 percent, and without their own hands-on use they cannot tell which claims are real. A leader who has only seen the chatbot will scope a large problem like a paragraph-sized task and decide AI cannot do it.

At [Hello 50:50 World in Schlieren](https://www.linkedin.com/feed/update/urn:li:ugcPost:7515667882018762752/) someone asked how to convince an employer to invest in people. My answer started with Formula 1. Nobody wins a race with 93 percent of the budget in the car and 7 percent in the driver. The source is Deloitte’s CTO Bill Briggs on how companies split their AI spend. The same article reports that people who got hands-on training trusted their employer’s AI 144 percent more. A training budget is easy to approve. Protected time to try things in real work is much harder to get, and the leader has to use it first. A leader who has never built something small with AI is guessing in every decision about the team’s AI work. So before your next steering committee reads out adoption numbers, who checks your leadership team’s output?

## Who Owns What the Organisation Knows

“If it is humans against AI, we have no chance.” That is the philosopher Markus Gabriel [on NZZ Standpunkte](https://www.linkedin.com/feed/update/urn:li:share:7512044033272246272/), and his answer is to get into the machine room. His sharpest line is about how we judge AI. Measure its output against human peak performance, not against the upper average. In the upper average, he says, AI already beats us in almost every creative field. At Hello 50:50 World I put it this way: before AI, average work was in demand. Now AI delivers the average, and the bar for human work is the top. The bar has moved before, over years. This time it moves in months.

What stays above the average is what the organisation knows and the model never saw. Andreas Oberhack and I spent a week of comments on what that means in practice, and by the end we had designed what he calls a Knowledge Operating Model.

It starts with capture. Experts rarely write down why they decided something. It is extra work nobody schedules, the same reason teams skipped logging for years. Agents change that, because the reasoning already sits in the conversation with the model. The agent can record it as a side effect of the work, and the expert only corrects it when the agent got the why wrong. Andreas added that the agent should treat what it extracts as a proposal until the expert validates it.

Then time. My first idea was an expiry date, since validated knowledge goes stale when the product or the regulation changes. Andreas had a better one: keep both dates, when something was valid in the business and when the organisation learned it had changed. A team changes its pricing in March and the organisation notices in June. That gap shows how long the organisation runs on old knowledge, and it is a number I would want to see every quarter. One reader runs an agent that keeps health regulations up to date across countries automatically. For regulation that works, because the change is published and an agent can watch the source. Internal knowledge has no source to watch. A team quietly changes how it builds or prices something, and nobody writes it down.

So who owns that number? The person who owns the process, not a knowledge team. Once it moves to a central team, it turns into a report nobody acts on. Another commenter closed a gap we had left open: when two owners contradict each other, one person decides, and anything that cannot be undone needs a second key. I would send the contradiction one level up, to whoever owns the outcome both processes serve. A new governance board would only slow it down.

The same question came back under [IBM’s new STAIR approach to retrieval](https://www.linkedin.com/feed/update/urn:li:share:7518204915760910336/), which is going around as nearly eliminating hallucinations. In the paper, a hallucination means naming a section that does not exist, which happens in 0.05 percent of lookups. In 18.67 percent the model points to the wrong section, and the answer is then written from real text in the wrong place. STAIR also learns the book during fine-tuning, so the knowledge sits in the model weights. In a vector store you re-embed the page that changed. With STAIR a new manual version means training again, or the model keeps pointing to a section that no longer says what it learned. Keep business knowledge out of the weights. And the detection step, noticing that reality changed, is a feedback loop, and a loop without an owner does not run. Who in your company would notice that the pricing changed in March?

## My Current AI Stack

**Claude Code:** Still the primary tool for reports, meeting prep, coding and most of what I do. Four separate passes: analyse, plan, build, review, with the review running in a session that did not write the code.

**GrokBot:** Where my agents live now, 23 of them, listed below. These are long-running agents that keep working when I close the laptop. Right now all of them run under one identity. That puts me in the 12 percent from the Weave report, and I am working through it with our IT.

**Perplexity:** Web research with real sources. First stop for primary sources behind the papers cited above.

**NotebookLM:** Documents in, audio and video summaries out.

**Gemini:** Image generation for the cyberpunk newsletter covers.

## Vibe Coded This Month (Private Projects)

**From single tools to a team of agents.** This month I moved my work onto agents on GrokBot. One of them is the front door: my Chief of Staff takes every task and hands it to the agent that fits. This is the team of 23 today.

- For the daily routine, a Personal Assistant handles mail and calendar and sends me a briefing every day, with an Outlook bot and a Teams bot next to it. A News Scout sends me useful and surprising news on my topics every morning at 06:00, and a Workout Video Scout suggests five training videos.
- For social media, a LinkedIn bot finds trending posts and suggests comments in my style. I post myself. An X bot reads the comments on my X posts and drafts replies, and a Google Ads expert helps with campaigns.
- For the community and teaching work, a Podcast Organizer plans episodes and scripts for Prompt & Proper, an organiser handles dates, material and tasks for the CAS Enterprise Architecture at HSLU, and three bots support DevOpsDays Zurich: an assistant for the conference, one that looks after the submissions on Sessionize, and a sync coach for the organising team.
- For my websites, an admin bot coordinates one bot per site: Romano Roth, Lean Enterprise Architecture, Cybernetic Enterprise, Prompt & Proper and DevOpsDays Zurich.
- For building and money, a Dark Factory Chef coordinates the automated development of my project “walker”. A Paper Scout practises trading with play money, with research, trade ideas and a journal. A Trading Bot watches my portfolio and proposes trades, with hard risk limits, and only trades with my approval.

## Where to Find Me

I co-host the [DevOps Meetup Zürich](https://www.meetup.com/devops-meetup-zurich/) with Martin Thalmann. The next evening is Tuesday 17 November at Digicomp: Matthieu Robin and Mattia Eleuteri on building a multi-AZ cloud in Switzerland, and Geetanjali Bhat on embedding quality in agile product delivery.

I am now a lecturer in the [CAS Cloud Architecture](https://www.linkedin.com/feed/update/urn:li:share:7512768727298498560/) at the Lucerne University of Applied Sciences and Arts. My part is the Cloud Operating Model: who owns the platform, who runs it, and who pays for it. It starts on 30 October in Rotkreuz and runs Fridays and Saturdays until 26 February, in German, and registration is still open. The info session for the next run of the [CAS Enterprise Architecture](https://www.linkedin.com/feed/update/urn:li:share:7517273076443529216/), which I run with Dietmar Wettach, is on 30 November.

[DevOpsDays Zurich](https://www.devopsdays.ch/) turns ten on 14 and 15 April 2027 at the Alte Kaserne in Winterthur. The [Call for Proposals](https://sessionize.com/devopsdays-zurich-2027/) is open until 31 December, and first-time speakers are welcome. Sponsor packages for the anniversary are open too.

[Prompt & Proper](https://promptandproper.ai/), the podcast Steffen Ochsenreither and I record in German, released two episodes this cycle: [AI FinOps](https://www.linkedin.com/feed/update/urn:li:share:7510956972658122752/), where we ran next year’s numbers and asked who pays for tokens in a fixed-price project, and [who is afraid of AI](https://www.linkedin.com/feed/update/urn:li:share:7516030617885704192/).

If this issue connected for you, forward it to one peer who needs the same conversation, and reply with the single sentence from this issue you would put on the wall.