Welcome to Edition 7 of The CAIO.
I have argued for years that the model is the small part and the discipline around it is the work. It is a claim that is easy to nod along to and easy to dismiss as a consultant’s line. In July it stopped being a line. A research group tested it on 5,000 codebases and put a number on it. A systems engineer took apart a viral “37,000 lines a day” boast and showed what that volume actually costs. Both posts reached far beyond my usual audience, one of them among the highest reach I have had all year. The audience is not tired of the argument. It wants the evidence.
That evidence is the spine of this edition. The bill from June has not gone away, it has a new headline number for 2029 that belongs in a board pack. The management layer companies keep cutting has started to reach the people doing the cutting. And underneath all of it runs the same thesis, now stated by other people in their own words: AI does not fix your organisation, it amplifies whatever is already there.
This edition follows what the audience actually opened. The proof that discipline, not the model, decides whether AI helps. The flattening that is climbing past the middle. The AI bill nobody can yet explain to a board. Why “AI amplifies what is already there” is now the most repeated sentence in my comment threads. And a quiet philosophical paper that says why the human never leaves the loop.
The Bottleneck Was Never the Model#
For two years the promise was that a better model would close the gap. July produced the cleanest evidence yet that it will not.
Start with the data, because this is the part that is new. Markus Borg, Adam Tornhill and colleagues from CodeScene and Lund University published the first hard test of a question I have been working on with clients for two years: is human-readable code also AI-friendly code? They took 5,000 Python files, had six different models refactor each one, and ran the original tests against the output. The result was consistent across every medium-sized model. On healthy code, the models broke 15 to 30 percent fewer tests. Same model, same prompt. The only thing that changed was the code they started from. Their maintainability score predicted refactoring success 3 to 10 times better than the model’s own confidence in its answer. Code that confuses humans confuses machines in the same way, and now there is a number attached to it.
Read that as a leader, not an engineer. Most AI conversations in the boardroom are about which model, which copilot, which budget. Those are the easy questions. The hard one is whether your codebase can absorb AI at all. On a weak foundation, more AI just produces more bugs, faster. Technical debt used to be a cost-of-delivery problem you could defer. In a codebase shared with agents, it is a risk multiplier you cannot.
Bryan Cantrill made the same point from the other end, and it is why his essay travelled so far when I wrote about it. Larry Wall, who created Perl, once named laziness as a programmer’s cardinal virtue. He did not mean doing less. He meant doing the hard abstraction work up front so everyone downstream does less: the libraries, the compilers, the schedulers that came out of someone refusing to solve the same problem twice. A model has no downstream to protect. It will, in Cantrill’s words, happily dump more and more onto a layercake of garbage. His exhibit was a viral boast about shipping 37,000 lines of code a day. An engineer took one such project apart and found it pulled in multiple test harnesses, a Hello World sample app, a stray text editor, and eight copies of the same logo, one of them zero bytes. For comparison, all of DTrace, the observability tool inside macOS and Solaris, is about 60,000 lines. Volume is not progress. The constraint is the part the model cannot supply for you, and it has to come from a human who is protecting a future the model cannot see.
This is where I want to be precise, because I made a version of this argument last month about cost, and it would be easy to hear the same note twice. Last month the point was economic: generation got cheap, so the bill exploded and verification stayed expensive. This month the point is structural and measured: the quality of what you already own decides how much the model can safely do. Those are two different bottlenecks. One is about how much you spend. This one is about whether your foundation can hold weight at all.
The good news is that the fixes are old and unglamorous, which is exactly why they work. I audited my own CLAUDE.md files this month after Andreas Horn’s prompt to do so, and cut rules that were scar tissue from a single bad output rather than real principles. I keep making the case that test-first is no longer a preference: when a model writes the code, a test written afterward only confirms the model did what the model did, while a test written first is the one place your intent gets fixed before the machine guesses at it. Test automation is the tightest feedback loop a team owns, and skipping it at machine speed just ships risk faster. And the least glamorous input of all, test data, quietly decides whether every test above it is telling the truth or testing a story about your software. None of this is exotic. It is discipline applied to the boring parts, and the CodeScene numbers say the boring parts are where the real gains sit.
So the uncomfortable board question has nothing to do with which model to buy. Point at the codebase you own today and tell me where you would not let an agent near it. That gap is your real AI strategy, and no model upgrade closes it for you.
The Layer Dissolves#
For three years the story about flattening was that it hit the middle. The 2026 data says the wave is climbing.
The LeadDev Engineering Leadership Report surveyed 600 leaders on where manager roles were cut, and the movement year over year is the whole story. Line management: 42 percent, then 67, now 59. Middle management: 43, then 56, now 65. Upper management, the CTOs and VPs: 13, then 18, now 23. The thinning started at the line, moved to the middle, and is now reaching senior leadership. The report reads this as the cuts becoming less selective. I read it differently. This is not about who is safe. It is about what the layer was for.
For most of its history a management layer solved two human limits: how many people one person can oversee, and how information moves up and down. When AI and modern tooling handle the routing, the layer whose main job was routing loses its reason to exist. That is true at the line, and it is just as true at the top. A wave moving up the chart level by level is a function dissolving.
Here is the part the flattening enthusiasts keep missing. Flat organisations have failed for decades, mostly because the coordination technology was not there to hold the context once you removed the layer that held it. Look at the same report: reorganisation is the top change at 67 percent, steady for years, while the actual cuts stayed flat. Most companies are reshuffling boxes, not building the shared understanding that would let flat actually work. Cut the layer without that substrate and you do not get a flat organisation. You get chaos with a tidier chart.
Olivier Wulveryck sharpened the same idea one level down, in a piece I could not stop thinking about: the product team with zero software engineers. The headline is half right and half a trap. The half that is right: the engineers are still there. They moved. Every piece of complexity the domain expert no longer sees still exists, relocated into the platform as guardrails, evaluation frameworks, context management, all of it built by very senior people. The trap is the word “mature”. The model only works if the platform underneath carries deterministic guardrails, measurable reliability, and full traceability. Most enterprises do not have that for their human teams, let alone their agents. Strip the platform away and “a team without engineers” just means unsupervised output shipping faster than anyone can check it.
That raises the obvious question: what is that platform, exactly? I put it to Kaspar von Grünberg, who put the Internal Developer Platform on the map, in a conversation I wrote up this month. His definition is the cleanest I have heard. A platform is a set of paths along a value stream to a business outcome, and an agentic platform paves those paths for agents rather than people. You keep the clean base, source control, CI, hosting, and add the two things agents actually need: path specifications so they stop wandering and burning tokens on every run, and the agent infrastructure that runs one agent safely and governs hundreds of them with identity, security, and observability. His line for where this leaves the org chart is the one I keep repeating to clients: the platform team is the new IT.
So what survives the wave, at the line and in the C-suite, is the same thing: judgment and the coaching of people. Information relay is automatable. Deciding what matters, de-risking a bet, keeping a team honest, that is not. The LeadDev data backs it: leaders are getting more technical, not less, and the ones who last make their value legible through the decisions they accelerate rather than the information they pass along. If your main contribution is moving information up and down, the wave is already on your floor. What do you add that no dashboard and no agent can?
The Scary Number Is Not $596k#
June’s lead was the bill arriving. July gave that bill a headline number for the boardroom, and a sharper way to think about it.
Tomasz Tunguz modelled the trajectory and the numbers are worth a board meeting. Anthropic already spends 2.3 times its payroll on compute, roughly two million dollars per employee per year. The rest of the market is nowhere near: the top 1 percent of software companies spend about 89,000 dollars per engineer per year on AI, the median spends 137. That is a 680-fold gap. Tunguz models three paths to 2029. Token deflation keeps it near 106,000 dollars. The middle case lands at 363,000. The bull case reaches 596,000, where one engineer’s AI bill equals an entire median employee’s revenue contribution.
Most CTOs will read that and reach for the obvious lever: cap the spend, ration the seats when the invoice lands. That is the wrong instinct, and I already see it in the field. The scary number is not 596,000 dollars. It is spending 596,000 dollars without knowing what it bought. Capping after the invoice is cost-cutting. What you want is cost control by design: every token instrumented, every agent run tied to the outcome it produced, the spend visible and steerable before it reaches the board. That is why we are building an AI gateway in our CTO office. Every request routes through one place, which gives us usage transparency, chargeback to the right project, and the option to run workloads locally where that is cheaper or required. FinOps for tokens. If you cannot see the return per token, you are flying blind at half a million a head.
The deeper point sits in that 680-fold gap. It is not mainly a budget story. The median firm at 137 dollars is barely using AI. The top 1 percent at 89,000 are compounding, because every token they spend teaches them where the return is. What separates them is knowing what each token buys. As one commenter pushed me, and rightly: you cannot measure value at the token level, only one layer up, at the workflow where a decision got made faster or a defect got caught before release. So instrument spend at the token and value at the workflow, then join the two. Most tools stop at the first half because it is the easy half, which is why the ROI conversation keeps stalling.
There is a wider lens on this that I find more useful than the bubble debate. A capital-cycle argument that has tracked bubbles for 200 years says stop watching demand, which can be faked, and watch supply, the real capital committed. Big Tech is on track to spend around 725 billion dollars this year, much of it circling between a handful of firms and counted again each pass as fresh demand. Railways in the 1840s, fibre in the 1990s, shale a decade ago: every one a real technology, every one still a bubble, and in every case the winners were not the pioneers who built the infrastructure but the settlers who bought it cheap afterward and ran disciplined businesses on top. For most enterprises the settler move is concrete: do not bet the company on one model or one vendor, own your platform layer, keep the model swappable, control the spend by design. When prices swing and returns compress, that discipline is what keeps you standing. Do you know what your most expensive AI request cost you last month, and who decided it was worth it?
AI Amplifies What Is Already There#
The most useful frame of the month came from Adam Bender at Google, and it is worth a leadership team’s hour: amplification is a magnitude, not a direction. AI gives you more of everything, more code, more tests, more confusion, and it does not care where any of it goes. Teams with strong fundamentals point that force somewhere useful. Teams without them make a bigger mess, faster. His thought experiment is the one to sit with. If your work suddenly had to handle ten times more activity, what breaks first? Not the glamorous AI parts. The boring ones. Compile times. Test compute. Code review, where reviewers stop reading carefully so they do not become the blocker, until nobody is really watching the codebase at all.
If the force is directionless, then supplying the direction is the whole job, and that direction comes from your operating model.
At our DevOps Meetup, Ralf Günthner said it even more plainly: AI amplifies what is already there. A learning organisation learns faster with AI. A dysfunctional one becomes more dysfunctional, faster. His numbers were blunt, 67 percent of AI initiatives miss their goals and fewer than 30 percent of pilots reach scale, and his diagnosis was that the technology rarely breaks. The organisation around it does: unclear responsibilities, decisions made too high up, roles never built for working with AI. On the same evening Dagmar Muth showed the team-level version, where the ratio of product managers to engineers collapses as bots close tickets, and warned that everyone now runs faster, often in different directions, so alignment has to scale with autonomy.
I lived the small, absurd version of this myself, and told the story on a podcast this month. I wanted a new AI tool internally, and got a ticket and a Word document to fill out. So I used Claude to fill it. The person on the other side then reviewed my document with AI. Two agents, filling out and reviewing the same form, and the only winner is the vendor selling the tokens. That is what a lot of AI adoption looks like right now: take an existing process, bolt AI on top, make it worse. The honest move was to delete the process, not automate it. Technology was never the blocker. Process and organisation are.
Trail of Bits is the sharpest case of what aiming the amplifier looks like, and I wrote it up here. In one study of 6,000 executives, 90 percent of firms reported zero productivity impact from AI over three years. On the same tools, Trail of Bits went from finding about 15 bugs a week to 200. The difference was not the model. Most companies handed out licenses and waited. They built a system, encoded their experts’ knowledge into reusable skills, and made AI a member of the team rather than a tab people open when stuck. That is the line between AI-assisted and AI-native, and it is an operating-model choice, not a purchasing one. I heard the same split on a manufacturing panel in Berlin: around 88 percent of the room had adopted AI, and only a handful could point to real value, because everyone rents the same model and the edge sits in the organisation you build around it.
None of this is a technology problem. It is the oldest problem in management, mistaking activity for progress, now with a much bigger engine. If you handed your teams AI a year ago and nothing changed, the AI was never the issue. So what in your operating model are you actually willing to redesign?
The Map Is Not the Territory#
I will close on a quieter note, because a paper landed this month that states cleanly a position I have built on for years.
Alexander Lerchner, who works at a frontier lab but posted this on his own, wrote a paper called The Abstraction Fallacy. His claim is structural, not biological. No matter how large the model or how clever the architecture, algorithmic symbol manipulation cannot produce experience. His argument runs backwards from the usual one. The standard story is physics, then computation, then consciousness. Lerchner reverses it: computation is a description we impose on physics, and imposing it takes a conscious agent who does the carving. The mapmaker sits upstream of the machine, never downstream. Or as he puts it, we are not engineering a new form of life, we are building increasingly accurate predictive maps. A perfect map of a city is still not the city.
I want to be honest about the status of this, the way Lerchner was. It is a single-author preprint, other serious researchers argue the opposite, and he leaves a narrow door open for non-biological consciousness under the right physics. It is not a settled result. But it states the position I built The Cybernetic Enterprise on: AI is the nervous system, humans are the soul, at the edge where the model meets reality. His practical takeaway, what he calls ontological relief, is to stop waiting for artificial general intelligence and start building applied intelligence, connected to feedback and used to empower teams.
That is the through-line under every story in this edition. Discipline, org design, cost control, all of it lands in the same place: the machine does not carry the judgment or the accountability. A person does. So the question I would leave you with is the one the paper sharpened for me. What is your organisation actually augmenting, the behaviour of the machine, or the judgment of the operator?
My Current AI Stack#
Claude Code: Still the primary tool for reports, meeting prep, coding, and everything that I do. The CLAUDE.md audit I ran this month is part of the workflow now: a few hard principles at the root, everything else treated as scaffolding I expect to replace at the next model upgrade. The discipline I keep writing about starts with my own setup.
Perplexity: Web research with real sources. Still where I go first when I need primary sources fast, and it earned its place again on the papers cited above.
NotebookLM: Documents in, audio and video summaries out. Useful this month for the longer reads, including the CodeScene paper and the Tunguz analysis.
Gemini: Image generation for the cyberpunk newsletter covers. Still the fastest for that style.
Where to Find Me#
I co-host the DevOps Meetup Zürich every month with Martin Thalmann at Digicomp, two talks each evening from 17:30. The next one is on 20 August, with Urs Enzler on separating planning and delivery cycles and Oleg Mayko on whether SRE has become the new operations. The autumn line-up runs monthly through to a February 2027 evening on running infrastructure without a single brain in the middle, with Tristan Smagghe on composable Kubernetes controllers and Torsten Boettjer on intent-based infrastructure for agents. We are booked out well into 2027, so it is worth grabbing a spot early.
Further out, DevOpsDays Zurich returns for its 10-year anniversary on 14 and 15 April 2027.
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.
Until August.
Romano
The CAIO is a monthly LinkedIn newsletter for C-level executives and senior leaders translating AI developments into operating models. Edition 7 covers posts published 27 June to 18 July 2026. Friday Fun posts excluded.
Get the next edition first
The CAIO lands in subscribers' inboxes before it appears here.