There are a great many claims about AI-assisted development, and very few counters. Luc Bonnin, a founder and developer, did the opposite: he set his development team aside for 40 days and replaced it with agents, on a real product, measuring every step.
The setting was deliberately unfavourable, which is what makes the exercise worth reading: playthatsheet.com, a PHP/MySQL monolith of roughly 200,000 lines, with no framework, and no framework on purpose. The point was to stop the AI leaning on well-known patterns and to avoid what he calls the "greenfield effect" - those demonstrations where AI shines because it starts from a blank page. "So I picked the worst possible case," he writes, "deliberately, to match a real-world situation."
The counters, at the finish line:
- 1,477 prompts and 2.3 billion tokens, i.e. 61.2 million tokens a day;
- a codebase going from 178,938 to 439,502 lines - +145.62%, a factor of 2.45;
- a final split of 59% AI to 41% human;
- and 260,564 lines reviewed line by line by a human.
That last number is the one to stop on. It does not describe what the AI produced: it describes what it took to make what the AI produced usable.
The iceberg effect: debt doesn't vanish, it changes place
The central metaphor of the write-up is an iceberg. Above the waterline, the visible part: features delivered, a repository growing, demos that impress a board. Below it, everything nobody counts.
Below the line, in this experiment, sat "several thousand lines" removed by git revert because they
were hallucinations: incorrect, inconsistent or dangerous code. And here is the observation that matters:
none of it was detectable without a human reading line by line. It compiled. It passed the tests.
It simply did not do the right thing.
Technical debt does not disappear with AI: it moves and it hides. And it accelerates if no human is watching.
The corollary is uncomfortable for anyone steering without reading the code: the faster the visible part grows, the faster the submerged part grows too - and nothing in a delivery dashboard says so.
"Monkey money": a cost nobody can forecast
The most useful passage is not the one about code quality, it is the one about the invoice. Bonnin borrows a retail term, monkey money - the loyalty point that whoever issues it is free to re-price at will, because it is indexed to nothing. In agentic AI, that currency is called the token.
The demonstration is experimental, which is what makes it solid. He wrote four prompts to connect four third-party authentication platforms: same structure, same model, same rules, same codebase, a feature that has existed on thousands of sites for years - squarely inside any LLM's comfort zone. He should have seen similar consumption, or decreasing consumption as the model reused the first iterations. He measured a 350% spread between the cheapest and the most expensive of the four.
His question to executives is the right one: "what entrepreneur would invest in a tool whose usage can vary by 350% for no explainable reason?" - knowing that risk is multiplied by the number of developers using the tool, and that a line has to go somewhere in a budget.
We have written here that Uber burned its annual AI budget in four months and read it as maturity rather than failure. This write-up explains the mechanism from underneath: it is not only that consumption is high, it is that it is unpredictable at the level of a single prompt. A budget can absorb a high cost. It absorbs far less well a cost you cannot estimate before spending it.
The bazooka-for-flies syndrome
A third effect, and this one comes not from the machine but from the humans steering it: the habit of calling the most powerful model of the moment for the smallest task. Changing one CSS line, renaming a variable, fixing a typo in a label - frontier model, every time.
The advice that follows is prosaic and rarely applied: look at small models, often just as good on modest tasks, and at open models that can run locally. The gain is not only on the invoice; it is also environmental.
That reflex has a more worrying cousin, which the write-up calls atrophy: stop checking for long enough and you lose the ability to check. Hence a recommendation that sounds conservative and is not: deliberately keep some parts of the code hand-written, so the team retains the skill it will need the day it has to overrule a choice the AI made on its behalf.
The ship of Theseus: who still owns this code?
The most literary metaphor in the piece is also the most accurate. The ship of Theseus, preserved in Athens, has its planks replaced one by one until none of the originals remain. Is it still the same ship?
Applied to a codebase: when 59% of the lines were written by a machine in 40 days, does the team still own its product? It owns it legally. The question is about something else - the fine-grained mastery that lets you diagnose an outage at 3am without re-reading thirty files.
AI makes the visible part of the iceberg grow extremely fast, but humans lose mastery and authorship of their own work just as fast.
"Would I know if the code was wrong?"
This is exactly where Bonnin's account meets another one published days earlier, by Elie Nehmé, who built an enterprise software-assets platform in two months - Spring Boot backend, Angular frontend, 14,226 lines of production code, 16,092 lines of test code, 25 database migrations - almost entirely with Claude Code.
His conclusion is not that AI removes the need for engineering. It is that it moves where engineering applies:
The important question is no longer "Can AI write this code?". It clearly can. The better question is: "Would I know if the code was wrong?"
He has a method for that, and it is counter-intuitive: ask the AI to attack your design before writing a single line, rather than to help you build it. Three defects found up front, two of which would never have raised an exception:
- A validation rule that hid an entire period. A deliberate business decision made the inventory period read the previous year's data; an older validation rule, still sitting on seven asset routes, required a year of 2025 or above. Each rule was correct. Their combination returned a 400 and rendered an empty screen. "The problem lived between two correct-looking rules. That is architecture."
- A half-fix that looked finished. The migration copied one table; the actual query joined two year-scoped tables. The application started, the tests passed, two organisational levels were simply empty.
- A security gap already in production, found while reviewing something else: the asset routes did not apply the period-visibility rule that the category routes applied correctly.
And one last example that belongs in every training deck: the AI proposed
set_config('app.changed_by', ?, false) to tell PostgreSQL who was acting. The third parameter sets the
scope: true for the transaction, false for the whole session. The application uses a
connection pool. With false, the value stays attached to the pooled connection after the request, and
the next request - from another user - writes its audit records under the previous user's name. Every test still
passes. One character, and the audit log becomes a liability.
What the two accounts share: generating code is no longer the problem. What remains hard, expensive and non-delegable is knowing that what was produced is right.
The ROI, and what it leaves out
The write-up puts a number on the return: 18.15×. The calculation compares 826 person-days from a five-person Agile squad at €500 a day - a deliberately low rate, so as not to overstate the human cost - against €260 of Cursor subscription plus fifteen days of CTO time at €1,500 a day. Roughly €413,000 against €22,760.
The figure is spectacular, and its author is the first to state its limits: it accounts for neither the iceberg effect, nor the loss of mastery, nor the dependency created towards the token vendors.
There is one more limit worth naming. The fifteen human days in the calculation cover writing the detailed technical specifications, the 1,477 prompts and reviewing the 260,564 lines. That is roughly 17,000 lines reviewed a day, specs and prompts included. You can perfectly well argue that code review runs at that pace when you know your own product by heart; you can equally argue that fifteen days understates the real supervision load. Under the second reading the ROI stays firmly positive - it simply is not 18.
This is not a criticism of the experiment: it is exactly the kind of assumption a company should make explicit before redoing the sum in-house, with its own rates and its own developers, who do not all know the codebase as well as its author does.
The "+30%" paradox, finally explained
Which is why this write-up deserves a board's attention more than an engineering team's. It answers a question many executives ask without getting a coherent answer: why do my teams report a 30% time saving from AI while the delivery plan does not move?
The answer fits in one sentence: the velocity gain is real, but it is absorbed - by the human supervision required, by the hidden debt, by the unpredictability of tokens, and by the absence of anyone whose job it is to steer all of that.
It is also what the 8.1 million pull requests measured by LinearB said from another angle: human code merges at 84.5%, AI code at 32.7%. Producing was never the limiting step. Validating has become one.
The question to ask on Monday morning
The closing advice is a Pareto approach: use AI where it beats humans outright, and spend 20% of human time keeping mastery of your code, your agility, and your ability to do without AI if token costs ever went out of control.
And one question, which can be read out as-is in a board meeting:
Who, in your company, owns the AI strategy and the forecast of your token consumption? If the answer is nobody, start there.
What Survol does with this
Three of the four problems above are governance problems, not model problems - and governance is precisely the layer Survol operates at.
- Debt that hides. With us the approved specification is the source of truth, not a disposable prompt. A gap between what was decided and what was produced is a visible gap, not a discovery made six months later.
- Unpredictable cost. Model choice follows the task automatically, and the injected context is cut to what is needed - the subject of our piece on a context tailored to size. A smaller context means fewer tokens and lower variance. The bazooka stays holstered for a fly.
- Authorship lost. Every session leaves a trace: who asked what, of which agent, on which branch, with which context, and which organisation constraints the agent pushed back on. The codebase stays tellable, which is the only operational definition of "mastering" it.
That leaves the fourth problem, the captain. No tool solves it: it takes a person. But a tool can at least hand that person the numbers they will need to hold the post.
Sources
- Luc Bonnin, “J'ai viré mon équipe de dev pour une équipe 100 % IA pendant 40 jours et 2,3 milliards de tokens”, LinkedIn, 13 May 2026.
- Elie Nehmé, “AI Writes the Code. So What Is the Engineer's Job Now?”, Medium, 15 August 2026.
