There is an image in the piece published by The Conversation that is hard to shake off. It comes from an engineer describing two months of seven-hour coding days, with barely a weekend off:
"It's like putting your productivity candle on a flamethrower; you go faster, but you burn a lot more energy."
The article gives that malaise a name — vibecoding fatigue, or AI brain fry — and pulls together what had been circulating in fragments: practitioner threads, surveys from the Upwork Research Institute, a study published in March 2026 covering nearly 1,500 people. The figures it reports are harsh: a third more decision fatigue, more serious errors, a sharp rise in intent to quit.
It is not an anti-AI piece, and this response is not one either. Quite the opposite: the subject deserves to be taken seriously because these tools work.
A fatigue that comes from the right side of the fence
The most important detail is easy to miss. The people affected are not the ones enduring AI or refusing it. They are the most advanced: those already steering several systems at once. The article borrows Matthew Kropp's phrase, "the canary in the coal mine" — sentinels whose exhaustion foreshadows that of other professions.
In other words, this fatigue is not a signal that adoption failed. It is a signal that adoption has matured, and it looks a lot like other signals we have already met. When Uber consumed its annual AI budget in four months, it was not because the tool disappointed — it was because it worked, and the steering layer around it was missing. Here, the exhausted resource is not a budget in dollars. It is a team's attention. That can be steered too, and it is considerably more precious.
The irony of automation, forty-three years on
The explanation the article offers is the most solid we have read on the subject, and it is an old one. In 1983, the ergonomist Lisanne Bainbridge described the "ironies of automation": when you hand the easy tasks to the machine, the human is left with only the hard ones — plus supervision of the whole.
The sharpest formulation comes from an occupational physician quoted in the text: the simple tasks used to be moments of rest for the brain. When the machine takes them over, only the effort is left, with no respite. We thought we were removing drudgery; mostly we removed the breaks.
And this is where it concerns us directly. The work that remains — arbitrating, framing, verifying, coordinating — is exactly the work we build tools for. So we have no right to treat it as a free extra that humans will naturally absorb. It has become the work, and it carries a cognitive cost that deserves to be looked at squarely.
The three workarounds describe a cockpit
The final section of the article lists three guardrails the most advanced developers have invented for themselves. Reading them is a jolt: one by one, they are the three building blocks Survol is built on. Except that they hold them up by sheer willpower.
1. Write a draft — that is, write the spec
Before launching the tool, they write in plain words what they want to obtain. The article quotes a developer:
"You sit the AI down in front of you. You tell it: we are going to work on this functional specification. I give the idea, you ask the questions, and you write it up."
That is our founding principle, formulated by someone who rediscovered it through exhaustion: the approved spec IS the prompt. The reason the article gives is excellent — without a frame set in advance, "you mistake the plausible for the correct".
But notice what this workaround costs the person practising it: they have to remember, every single time, against the ease of simply opening a session. When the spec is the tool's entry point rather than an act of willpower, the guardrail stops being a discipline and becomes the normal path.
2. Re-appropriate the work — that is, structure the review
Second workaround: never settle for "it works". A developer with twenty years of experience explains that he reads and understands every line produced, "not to check that it works, but to understand what changed".
He is right in substance. But the article adds, very honestly, that this slowing down "has a cost" — and that is the heart of the problem. Reading every line an agent produces is a strategy that does not survive volume: it is precisely the definition of the burnout described above. A Faros AI study of more than 10,000 developers points to the same bottleneck: many more merge requests, and review time going through the roof.
Our stance is not to review less, it is to direct attention. One preview to approve per version rather than a continuous stream of diffs. Acceptance test books, run on a named environment, that say what must be checked instead of leaving everyone to guess. Human expert reviews on demand, for what deserves them. Vigilance remains essential; it stops being diffuse and permanent.
3. Refuse certain tasks — that is, set constraints
The third workaround is the most striking. Developers draw red lines: architecture choices, risk zones (payments, medical data, customer records), and the tasks that give their job meaning. One of them puts it bluntly:
"I spend half my time telling the AI what it must not do. Don't read that file. Don't refactor. Stay in your lane."
Half his time. Repeating, session after session, what could be said once.
That is exactly what our organisation technical constraints are: rules declared once at organisation level, cascaded down to the feature, injected at the start of every session and logged. And on the third category of refusal — the tasks that give the job meaning — we made a design decision that matters: in our model, a version written by hand, zero tokens, has exactly the same status as one produced by an agent. Same lifecycle, same review, same release. Keeping a task for yourself is not an exception to handle: it is a normal case.
The article's most serious objection
The text slips in a sentence aimed squarely at tools like ours, and it deserves quoting rather than dodging: companies that try to codify these refusals "will run into a well-known rule: the more rigid a constraint, the more it gets bypassed".
True — and it is precisely why our constraints have three levels rather than an on/off switch. Mandatory — never bypassed. Preference — applied by default, with no drama if the context justifies deviating. And between the two, the level that answers this objection directly: strong — the agent may challenge it with arguments, which opens a product decision for a human to settle.
A rule you can argue with is a rule you do not need to bypass. And since every application — like every challenge — is logged, a constraint that gets challenged over and over becomes visible: that is the signal the rule is bad, not that the team is undisciplined.
What a tool cannot do
Let us be blunt, because the subject is too serious for a sales promise.
- No tool cures burnout. If 88% of the most AI-productive employees report exhaustion, as the article relays, the answer is first a decision about workload and expectations. That belongs to management, not to software.
- One more cockpit can be one more burden. That risk is real, and our design guardrail fits in one word: derived. A feature's status follows from what is actually deployed, not from a box someone has to remember to tick. A dashboard you have to maintain by hand is extra drudgery, not relief.
- We only cover software. The article warns the wave will reach translators, lawyers, journalists — every profession built on language. Our ground is building digital products. For the others the reasoning transfers; the tooling remains to be invented.
What we claim is narrower: part of this fatigue comes from volume, and nobody can do much about that in the short term. Another part comes from disorder — settling the same decision twice, re-reading everything because nothing tells you what matters, holding the product map in your head. That part is a tooling problem, and it is addressable.
The takeaway
- Vibecoding fatigue hits the most advanced, not the laggards. It is a signal that adoption has matured, not an argument against AI.
- Bainbridge's explanation has held since 1983: automating the easy tasks removes the breaks and leaves continuous effort — plus supervision.
- The three workarounds invented in the field — write the spec first, structure the review, set explicit refusals — are sound. Their weakness is not their content, it is that they rest on one person's willpower, and they do not transfer.
- Turning those individual reflexes into shared infrastructure is exactly what we are building. It replaces neither rest nor a reasonable workload — but it removes the part of the fatigue that comes from disorder.
The article closes on a piece of advice we find remarkable: for anyone starting out, a good marker is to watch where experienced professionals refuse to use AI. Their refusals show, better than any framework, what you still need to learn to do yourself. We would add one thing: those refusals deserve to be written down somewhere. Otherwise they will leave with the people who learned them the hard way.
Source: "La 'vibecoding fatigue' : épuisés par l'IA, les développeurs informatiques inventent leurs propres parades", The Conversation, 28 July 2026 (in French). The figures cited (Upwork Research Institute, the March 2026 study on AI brain fry) are those reported by the article; quotations are translated from the French.
