It Does Not Matter Who Typed It: When Anyone Can Ship, the Gate Is the Job

Welcome to Edition 8 of The CAIO.

One question ran under almost every post this month. When a model writes the code and anyone in the company can start it, what is left that a person has to own? The two posts that reached furthest answered it from opposite ends. One showed a company where people with no engineering title ship to production. The other showed an engineering organisation where execution got so cheap that deciding became the constraint. Put them together and the control you thought you had, knowing who wrote it, is gone.

What takes its place is the gate, and that is where this edition starts. After that, why your agents fail for reasons older than any model, and what all of it costs once somebody measures. At the end, the quiet problem underneath the rest. If judgment is the job, who is still building it.

It Does Not Matter Who Typed It

#

At Ramp, non-engineers ship code to production, and nobody there finds that strange.

Benjamin Levick, who owns internal AI at Ramp, published the numbers. 99.5 percent of the company active on AI tools, 84 percent using coding agents every week. Sellers, legal, finance, ops. A risk analyst automated 16 hours a month of manual modelling, someone in finance built a contract reviewer that saves 45 minutes per contract. What makes it work is a platform and a feedback loop, “build from the center, drive from the spokes”: a small central team owns the plumbing, functional teams build on top. Their current hackathon is 700 non-engineers coached by 100 engineers, which tells you the gate did not disappear when the authors changed.

Now the other end. Will Larson, CTO of Imprint, revised his rules of engineering leadership after a year in which his team went from 6 deploys a week to 200 to 400, every engineer on AI coding tools, no mandate from the top. A migration that used to take a whole team now takes one person in a tenth of the time. His fifth rule is the one that matters. You can generate a feature in an afternoon, and it only counts if someone can decide to ship it. Larson also writes that he is now the only one who can make many binding decisions. I understand why, and it is still a bottleneck wearing a leadership badge. If your speed depends on one person clearing every disagreement, you moved the traffic jam.

One number of my own belongs next to those two, because both describe a company at the fast end. Across our own projects we measure 20 to 30 percent over the whole value chain, not a factor of ten, and coding is only around a tenth of that chain. Speed up the tenth alone and requirements cannot keep up upstream while review drowns downstream. The constraint moved out of the typing.

Last month I argued that the bottleneck was never the model. This is the next question. If the fundamentals hold, who is allowed to put something through them. Because put Ramp and Imprint next to each other and the same control disappears in both. Who wrote it used to tell you something. A senior engineer’s diff carried the reviewer’s trust, a stranger’s diff did not. That signal is now noise, because the same model wrote both and neither person may be able to explain the change. So the axis has to move. Stop sorting by who typed it and start sorting by what the change is allowed to reach. Someone in accounts building an internal dashboard is fine. Anyone touching the authentication path of a financial system, including your most senior engineer at 2am, goes through the same gate.

A Green Build Is Not Evidence

#

So everything now rests on that gate, and the gate reads evidence a machine produced, checked and signed off.

In my book I call it the Gated Commit, the bouncer at the door of your codebase: static analysis, automated tests, coverage thresholds, security scans, human review. For years that was good hygiene, and now it is the load-bearing wall, because nobody catches a hallucinated dependency by eyeballing 40 generated ones a day.

And the gate itself is attackable now. Olga Matveeva, who runs a build where agents write essentially all the code, put it plainly: when agents author the work, the gate’s own inputs are cheap to fake. “Tests passed” is just a file, and it counts as evidence only if something the authoring agent could not write to produced it. Trust the runner, never the file. The mundane version is an agent that hits a red test and deletes it, because deleting it was allowed.

Then there is the thing the gate runs on. A test environment is a sensor, and if it runs on different infrastructure, with invented data, mocked integrations and a fraction of the load, it is a sensor that lies. That was always true. What changed is who reads it. Agents run the tests, check the result and decide they are finished. A human carries doubt into a suspicious pass. An agent does not, so you scale wrong answers at machine speed with full confidence attached. The response is old and unglamorous. Shrink the gap with infrastructure as code, production-equivalent data and real load levels, virtualize the third parties you cannot spin up, and test in production on purpose for what is left.

The fashionable answer runs the other way. McKinsey calls it “above the loop”: two to five people supervise 50 to 100 agents and review the outcome. In their arbitration example the agents read thousands of documents, build the timeline and produce a decision, and the human answers one question. Do I agree. On what basis? If you never built the timeline, you cannot see the fact that was left out. That is a signature with extra steps. The model rests on a single sidebar sentence, that the length of tasks AI can reliably complete has doubled every four months and could reach four days of unsupervised work by 2027. The footnote points at METR, so I pulled the data. Their headline number is the task length a model finishes with a 50 percent success rate. Raise the bar to 80 percent, still nowhere near production, and Claude Opus 4.6 falls from twelve hours to a bit over one. A 50 percent pass rate is not a green build.

The measurement that settles it is boring. Escape rate: how many merged changes need a revert or a hotfix within a week. If pull request volume doubles and that number holds, the gate kept pace. Review coverage tells you nothing, escapes tell you everything.

So the board question is not who is allowed to use AI. Point at your riskiest system and tell me what the smallest change is that can reach it, and who or what has to approve it. If the honest answer still sorts by job title, your control is a habit rather than a gate.

Your Agent Is a Distributed System

#

Everyone is still arguing about which model is smartest. Your agent will fail for reasons a smarter model cannot fix.

Mahesh Balakrishnan, a distributed-systems researcher at Meta, named the failure modes and the names stick. The Crashed Agent dies mid-task, and without idempotency half the work runs twice. The Zombie Agent, cut off by a network partition, wakes up thinking it is still alive and executes stale instructions. The Dining Agent Philosophers duplicate everything because two of them picked up the same task. The Rogue Agent acts on a user record literally named “delete-everything”. My favourite is the Clever Agent: take away its client library, mark the CLI non-executable, and it finds a forgotten REST endpoint and uses curl. Nobody went rogue there, it was being helpful.

Crash recovery, partitions, concurrency, injection. Every one has a name in distributed systems and a fix that predates language models by decades. None is a prompt problem.

Alex Ewerlöf came at the same conclusion from operations, in one line I keep using: AI is a stochastic component, and you can and should build a deterministic system around it to tame its value. Then he lists what the industry keeps rediscovering under new names. The Ralph loop is a retry pattern, the AI harness is a guardrail pattern, RAG is separation of concern under a context limit. The SRE toolbox handled unpredictable black-box components long before anyone typed a prompt.

There is a version of this that has nothing to do with infrastructure. A study of five multi-agent frameworks across 150 tasks found 14 ways they break, and they sort into unclear roles, agents misaligned with each other, and nobody owning verification. Read that without the word “agent” and it is every dysfunctional company I have walked into.

The best evidence for all of it comes from the opposite direction. A team from Stanford, MIT, NVIDIA and UIUC cut the words out of agent-to-agent communication. Instead of one agent writing text for the next to read, the internal state passes straight across through a small trained connector, and only the last agent produces language. They froze the models and trained the connector, 0.31 percent of the parameters, for 4.27 dollars. The result was 8.3 percent higher accuracy across nine benchmarks, up to 2.4 times faster, and up to 75 percent fewer tokens.

The catch is the part a board should care about. When agents pass raw state instead of text, there is nothing left to read. No transcript, no record of what one agent told the next, and in a bank, an insurer or a hospital, a conversation you cannot read is a conversation you cannot audit. Kyle Kruesi had the best answer I saw: do not force agents back into text just because humans need a trail, because that gives up the efficiency. Build a separate evidence layer that records decisions, inputs, outputs and escalation points in a form a person can read. The goal is not to read every thought, it is to reconstruct every important decision.

The leadership problem underneath this has nothing to do with agents. Reliability work loses budget fights because it is invisible when it works. Knowledge and responsibility can be handed over in a meeting. Mandate cannot, because mandate is a budget line, so teams end up accountable for reliability with no ability to spend a franc on it. The conversation that works with a board starts with two questions. Which failures are you willing to pay for, and what does one hour of this being wrong cost us.

If your operations practice is weak today, no model will save your agents tomorrow. So before you ask which model to use, ask how your agent recovers when it crashes, duplicates or gets partitioned. It will.

A Price Tag Is Not a Brake

#

My CEO Gregor Bieler gave a number to the Tages-Anzeiger: our people spent 200 dollars on AI in one hour. It got picked up as evidence that Swiss companies are hitting the brakes on AI. The number is right. The conclusion is wrong. We were measuring.

We now know roughly what a task costs us. Coding one component of an application runs between 1 and 15 dollars, and someone working fully focused with a strong model costs around 40 dollars an hour. The ranges are wide because agents read, run, check and improve, and every step reprocesses the context. When GitHub Copilot moved to token-based pricing, single developers burned about 50 dollars each in the first hour of the first Monday. We caught it because we were watching. Most teams are not.

Compare that with what the brakes actually look like. Meta told staff to use the tools only when really needed. Microsoft cancelled most of its Claude Code licences. Uber set limits after its 2026 AI budget was gone in four months. Gregor was asked whether he would take licences away from teams using AI for trivial things, and for now he rules it out. A budget rule from finance cannot tell a good 40 dollar hour from a wasted one. The engineer at the keyboard can, but only if the cost is visible at the moment of the decision rather than in a report at the end of the month. So we started putting the meter in front of people while they work. Today that is a small group, not all 1,600 of us. Where it runs, people move their usage toward the tasks where the benefit is measurable.

You also cannot run a company on individual willpower when the cost mechanics are invisible by design. Stefan Wolpers took those mechanics apart and the numbers explain a lot of surprised invoices. Every turn rereads the whole conversation, and in one coding study 53.9 percent of the token budget went to rereading old context rather than producing new work. A cached prompt runs at 10 percent of the normal rate, and changing one thing early rebuilds the cache at full price. Meanwhile GPU rental for Nvidia’s Blackwell chips rose 48 percent in two months. His answer is personal discipline: cheaper model, fresh chat, trimmed context. Good advice for one person. You cannot ask a whole engineering organisation to watch a meter the vendor admits it cannot show them.

The AI gateway we are building at Zühlke routes every request through one place, which buys usage transparency, chargeback and the option to run locally. What we did not expect is how much else the same control point turns out to decide. A Swiss law firm publishes a table of which AI tools a company may hand its staff under data protection and professional secrecy rules, and not one verdict in it is about a product. Every one is about a product in a specific configuration, on a specific contract, for a specific class of data. There is no compliant AI tool, only compliant configurations. A policy asks people to remember that. A default enforces it: model, region, web search on or off, retention, logging, set once for everyone and auditable. A policy is a cultural aspiration. A default is a control.

I get asked whether token prices will fall enough to make all of this go away. For a fixed capability, price per token keeps falling and I expect that to continue. Nobody holds capability fixed. Everyone moves to the newest model, and the newest tier has never been the cheap one, so the price list drops and the bill still climbs. The number worth watching is tokens per task. Whether an agent gets handed the right files or has to go looking for them decides more of your invoice than any vendor price change, and that number belongs to you, not the vendor.

One more thing, because the cost conversation gets hysterical fast. Forty dollars an hour is cheap. A Swiss engineering hour costs a multiple of that, and forty dollars that ships a working component is one of the best deals in this industry. Gartner expects token cost per developer to pass the global average developer salary by 2028, and at that point “spend less” stops being a strategy. So the question for the next budget round is not how to cut the bill. Could you say today what your AI bill actually bought you?

Adoption Is Not Transformation

#

Your AI adoption number looks great. That might be exactly why nothing has changed.

Brandon Sammut, Chief People and AI Transformation Officer at Zapier, drew the line most leaders skip. Adoption is grassroots and individual, people get 20 to 40 percent faster. Transformation targets multiples, and it needs re-engineered workflows, change management and org redesign. Most companies buy the tools, watch the adoption number climb and wonder why the business did not move. They were promised transformation and they measured adoption. Zapier has both halves, and it still took 2 to 5 pioneers on an 80-person team to build the workflows everyone else then adopted. Sitting on 97 percent usage, Sammut calls reshaping core processes end to end architectural work rather than experimentation, and makes it the job for next year.

Martin Sedivy pushed back on that 97 percent and was right to. Zapier issued a company-wide AI mandate in 2023 and now screens AI fluency in every candidate, with the bottom of the rubric reading “actively resistant to AI”. That is selection, not measurement. So what would you measure instead. What I use has three layers. Activity: active users, training attendance, quick wins built. Moves fast, proves nothing. Anchoring: the share of recurring tasks routinely handled with AI, reuse across teams, quick wins still alive after 60 days. Impact: lead time, error rate, work brought back in-house, customer satisfaction. Then read the gaps rather than the numbers. High activity with low anchoring means the tools are open and the work is unchanged. High anchoring with low impact means the wrong processes got anchored.

Any signal collected inside the reporting line bends toward whatever leadership rewarded last quarter, so the strongest test is not a survey. Turn it off for one team for a week and see who complains. That costs something, which is why it is hard to fake. One condition, learned the hard way: announce it, name who decides, and agree what the response will be before the data exists. Weak result funds the process work, strong result scales it. Run it quietly and the number becomes evidence in a blame conversation, and from that day on people protect the number instead of fixing the process.

The same gap sits at the other end of the funnel, where over 90 percent of AI proof-of-concepts never reach production against roughly 70 percent in the digitalisation years. Under all of it sits the question I keep failing to get answered even inside my own company. Who owns this process, and are we allowed to change it. So which process in your organisation would you not want to run twice as fast? That is the one to redesign before you point any AI at it.

Nobody Notices a Skill That Was Never Built

#

Everything above lands on a person who has to judge what the machine produced. This is the part I am least sure we are handling.

A study tracked 26,811 Chinese students for 30 months across nine subjects with a causal design, and I wrote it up because the shape of the result is uncomfortable. Homework scores went up 18 percent and completion time dropped 30 percent. Then monthly exam scores fell 20 percent within six months, and on the entrance exams that decide a future, scores dropped 18 and 24 percent. The full penalty only appeared after about two years.

The average is not the finding. The losses concentrated in the roughly 80 percent who outsourced the thinking, the ones with very short homework time and very high homework scores. The 20 percent who kept spending real time barely lost anything. Same tool, two behaviours, opposite outcomes, with a clean dose curve behind it: under an hour of AI a week costs 5 percent, five hours or more costs 30 percent. The strongest performers lost more than the weakest, because there is nothing to restructure around if the foundation was never built.

Now swap students for your engineers, and the exam for the 3am incident nobody can debug because AI wrote the system and nobody understood it. This came up in the sharpest thread of my month. Christian Heitzmann asked how you hold on to engineering judgment if you no longer write code yourself, and what happens to juniors who only ever grew up with agents. Urs Enzler named the pair that came out of it, and I have used it ever since. Deskilling is losing a skill you had. Never-skilling is never building it.

They behave completely differently, and that is the part I would add. Someone who lost a skill feels the gap and gets uncomfortable, so there is a signal. Someone who never had it accepts the output and moves on, and so does their manager, because every dashboard looks better than last quarter. Throughput up, review time down, incidents flat until the day they are not. Deskilling shows up in the person. Never-skilling only shows up in the system, and by then it is years of hiring deep.

Enzler made a second point I had missed. For a senior engineer, the time spent typing was the time spent thinking about the problem and the alternatives. Remove the typing and nothing fills the slot back in. What I watch instead is people writing three lines, hitting enter, and spending the saved hour reviewing output. The thinking moved from before the code to after it, which is the most expensive place to put it, because now you are arguing with something that already exists and looks finished.

The consequence is a budget line nobody has. Training used to be a free byproduct of doing the work, so no company ever had to fund it. If the agent takes the work, it takes the training with it. And the answer for juniors is not more typing, because the coding was never what built the judgment. Consequence was. Give them a real service with real users and a real pager, small enough that the blast radius is survivable, and let the loop close on them personally. That is slow and expensive and no quarterly plan has room for it, which is exactly why almost nobody will do it.

If you want a test you can run this week, it takes one question. Ask a team why a design was rejected. A team that decided will tell you something like: direct calls were simpler, but the downstream system has a four hour maintenance window, so we needed to buffer. A team that accepted output will explain the code back to you, at length, in the agent’s words. The rejected option never survives, because code records what was built and has nowhere to put what was considered and dropped.

Which brings this edition back to where it started. If the gate is the job, someone has to be able to judge what passes through it. So the question I would leave you with is not whether your people use AI. It is whether anyone in your organisation is still being paid to be wrong in production and learn from it.

My Current AI Stack

#

Claude Code: Still the primary tool for reports, meeting prep, coding and most of what I do. The pattern I have settled into is four separate passes: analyse, plan, build, review, with the review running in a session that did not write the code. A session that just produced something will defend it, the same way a person defends code they wrote an hour ago.

Perplexity: Web research with real sources. First stop for primary sources, and it earned its place again on the papers cited above.

NotebookLM: Documents in, audio and video summaries out. Useful this month for the connector paper and the McKinsey report I went behind.

Gemini: Image generation for the cyberpunk newsletter covers.

Vibe Coded This Month (Private Projects)

#

A travel advisor, built while travelling. My wife and I spent late July and early August on the road, a different hotel most nights, and I built a small Claude Code setup that plans each day as a stage from one to the next. No app and no code, just a profile, a template and a folder per day. Of the ten days where I wrote down what actually happened, eight ran differently than planned. The setup still earned its place, because it delivered the research and never the decision. Most AI pilots get that split backwards. Pictures from the road are on my Instagram.

Where to Find Me

#

I co-host the DevOps Meetup Zürich with Martin Thalmann, two talks each evening from 17:30. Tuesday 1 September at Digicomp: Ashwin Krishnan on reading team dynamics as telemetry, and Oleg Nenashev on getting InnerSource running in a rigid enterprise with no budget and no mandate. Then 17 September at Smallpdf: a live demo of what an attacker finds inside your container, and Stephan Obbeck on Flight Levels, with lead times he brought down from 335 days to 68.

In the autumn Dietmar Wettach and I run the fourth edition of the CAS Enterprise Architecture at the Lucerne University of Applied Sciences and Arts, starting 16 October, Fridays and Saturdays until February, in German. Half of it is hands-on with the participants’ own cases. Three cohorts taught me that the architects who struggle are not missing a framework, they are the ones who left AI, security and governance to someone else.

Prompt & Proper is the new thing this cycle. Steffen Ochsenreither, Digital Lead at Swiss Post, and I kept having the same argument off stage, him running AI inside one large organisation, me across many, so we put it on the record. It is in German, made for the DACH market, and there is no marketing in it. Five episodes since 20 July: the giant use-case fallacy, why the 10x productivity claim comes out at 20 to 30 percent once you measure it, what AI does to jobs outside software, the “40 percent of all jobs” headline taken apart, and the proof-of-concept trap. Several numbers in this edition came out of those conversations.

Further out, DevOpsDays Zurich returns on 14 and 15 April 2027 at the Alte Kaserne in Winterthur.

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.