In early September, the French technology channel Underscore_ published a long interview with Quentin Adam, the CEO of Clever Cloud, an independent European cloud provider. His hosts, Micode and Matthieu Lambda, gave the episode a title that translates roughly as "We no longer pay developers to write code." Over the conversation, Adam describes moving a company of about seventy developers into agent-assisted work, and what changed inside the company as a result. Clever Cloud writes the software that runs its own cloud, down to the operating system and a homegrown database, so the code he is talking about is load-bearing.
Watching it, I recognised almost all of it.
I want to be careful about what that means. Adam is describing his own company, from the position of a founder who had to convince his own engineers, and he is talking about systems quite unlike the ones I write about here. I work in IT and security leadership, on different problems. The overlap is interesting for that reason. When the same conclusion appears twice from different vantage points, it is a stronger signal than either account alone.
It is still two accounts. I treat his story the way I would treat any first-hand report: as strong evidence from one organisation, and as something short of a measurement.
The value was in work nobody would have commissioned
For two years, the argument for AI in software has mostly been speed: the same work, faster. Adam's account points somewhere more useful.
He is blunt that a model should not be treated as a junior developer. His framing is that the model is inhuman, and that you should therefore ask it for inhuman tasks. In French, inhumain here means beyond human capacity or patience; the closest English word is superhuman. That distinction is the substance of this article.
His clearest example is administrative. Clever Cloud runs a large monolith that roughly thirty people touch every week. The hard problem with thirty contributors is coordination, so that is what he aimed the agent at. It read every active branch, the test results, the pull request comments, the issues, the email and the chat history, and prepared the weekly synchronisation meeting for him. It mapped the real friction: which changes were colliding, where discussions were heating up in writing, which architectural decision was about to be needed.
He estimates the resulting document as three or four days of human work. The agent produced it in about twenty minutes. Nobody would ever have commissioned that document, because it was never worth a person's week. The meeting ran on whatever people happened to remember.
The work had always been possible. It had never been affordable. At twenty minutes a week, the arithmetic changed.
What becomes affordable
Once you look at agents this way, the promising candidates change. Adam names several from his own operation.
Verification on every commit. Every change entering the repository now runs through automated security scanning, and he runs several models against his own systems. His reasoning is simple: if one scanner misses a vulnerability, another may find it.
Simulation. Clever Cloud's own database is built on FoundationDB, whose simulator injects network loss, restarts and partial failures into a distributed system. He describes extending that kind of formal simulation across more of the platform, so a commit is checked against adversarial conditions that would take hundreds of hours to reproduce by hand.
Migration you would not otherwise attempt. He gives the example of rewriting a library in another language purely to compare performance, because the cost of regenerating and re-verifying it has collapsed. The previous answer was no, because a migration meant two weeks of work and an unpredictable outage.
Eliminating legacy. His stated goal is that Clever Cloud should eventually run nothing older than the code it wrote this year, and decommission a decade and a half of accumulated software. He describes that as a target, with the outcome still open.
The pattern is the same in all four. These are things a capable person could have done. They were never worth the time, so they stayed undone.
That changes the productivity question. Which tasks can be accelerated is still worth asking. The more useful question is which tasks were never affordable, and what becomes possible now that they are.
Feedback loops are the real constraint
Adam's technical observation is worth separating from the culture story. He argues that models work best in strongly constrained languages, and his example is Rust.
The mechanism he describes is entirely mechanical. A strict compiler, a strong type system and a borrow checker turn a category of mistakes into explicit errors at build time. Those errors are exactly the kind of feedback an agent can act on without human input, so the model corrects itself inside a tight loop. In loosely constrained ecosystems, more verification is deferred to runtime, which is later, slower and more expensive to recover from.
He adds a less obvious point about training data. A language needs to be old enough to have a large body of code, but not so old that it accumulated many breaking versions, because a model trained across incompatible eras will confidently produce the wrong one. His illustration is generated Java that reads like Java 8.
Neither claim is a controlled finding. They are the inferences of someone who has watched agents work across a language boundary. They are consistent with the theme of this series, that the more of your expectations you can express as mechanical, machine-checkable feedback, the more work you can safely hand over.
What you keep is the specification
The claim I keep returning to concerns what stays valuable. Adam's argument is that because regeneration is cheap, you will rarely rewrite a file by hand again. What you will maintain is the specification, the architecture, the tests and the environment.
This is the same conclusion I drew in the first article of this series from OpenAI's internal case study: make the repository legible, make success executable, and keep the system replaceable. The durable asset is the description of what the system must do, together with the evidence that it does it. The lines themselves are disposable.
It also clarifies what a developer remains accountable for. If generated code is disposable and the specification is not, then the part of the job that carries forward is the part that states intent and defines proof.
The senior developer was under-used
One finding complicates the third article in this series.
Adam says the senior developers adapted fastest, and that many became far more productive than before. He does not put this down to better prompting. Their bottleneck had never been typing. A senior engineer leading a team spends the day in meetings, writing specifications and explaining intent to other people. Agents removed that overhead, and the judgement they already had finally reached the code. Some told him they had never written so well.
The third article argued that the apprenticeship route is at risk, because the routine work juniors learn from is exactly the work agents now absorb. Adam's account does not contradict that. It shows the same problem from the other end. Agents first amplified the people with the most judgement, and the people with the least to fall back on are the ones who lose the practice.
Both readings fit one premise. Value is moving towards judgement, and judgement still has to be built somewhere.
What the interview cannot tell us
I want to be honest about the limits of a single interview, including one I found persuasive.
It is one company, described by its own CEO, with no control group and no baseline. Adam mentions roughly 2% attrition during the transition and says the company is hiring, but an outsider has no comparison point that would separate the effect of the agents from the effect of a determined leader. He is also arguing for a position he has a stake in, and the episode carries a sponsor. None of that makes him wrong. It tells us how much weight the account can carry.
The measures that would matter most are not in the conversation: review load, defect rates, incidents, whether quality actually held. And his approach to tooling, where he deliberately dropped a unified policy and lets engineers expense whatever they want, depends on a cohesive team of strong engineers. In a context that needs auditability, or where the team is less settled, the same policy would produce chaos.
Any of these reservations could also be the reason his account looks naive in a year. I am reporting it as evidence from one organisation, not as a template.
A note on the sovereignty argument
The interview closes by turning to digital sovereignty, a subject Adam has argued before, and it is a different kind of claim from the engineering discussion. Where he describes what happened inside his own company, I can weigh it as experience. Where he prescribes policy, I am less convinced by making sovereignty the goal, when I would treat it as one risk among several. That deserves its own treatment.
The bottom line
The most useful thing I took from the conversation is a way of choosing work.
For two years, we have asked agents to do human tasks faster. The better question is which tasks were never worth a person's time, because those are now available. Reading every branch before a meeting, testing a migration you would never have scheduled, scanning every commit, decommissioning a decade of legacy. This is the work that never made the list.
Adam and I arrived at that from different seats, working on different systems. That overlap is the signal.
Give the agent superhuman work, keep the specification and the tests, and stay accountable for what ships.