Vibecoding fatigue: we were promised less work, we got zero breaks

« I spend half my time telling the AI what it shouldn't do. » The phrase comes from a developer interviewed by Morgan Blangeois, a PhD student in management sciences at Clermont Auvergne University, in an article published on July 28 on The Conversation. If you have been coding for more than five years, you are probably nodding your head in front of your screen.

We were sold an assistant. We received an unkillable intern, very fast, very confident, who never sleeps and needs to be proofread line by line. This is not quite the same contract.

The thing has a name now

The term « vibecoding fatigue » was popularized in August 2025 by Jorge Raad, a former Google employee. Vibe coding involves describing what you want in plain language, then letting the machine produce the code. The fatigue that comes with it was not in the brochure.

In March 2026, the Harvard Business Review published a study conducted with 1,488 American employees by researchers from the Boston Consulting Group. They gave the phenomenon a name that is significantly less elegant: « AI brain fry ». The brain that fries. The definition is precise: cognitive exhaustion caused by the use or monitoring of AI beyond one's own mental capacities. Participants describe a fog, a buzzing, or the sensation of having twelve browser tabs open at the same time in their heads.

The numbers confirm the problem. People who report this brain fry have about a 33% increased risk of suffering from decision fatigue. They also have a 40% increased risk of actively wanting to quit. Matthew Kropp, one of the authors, specifies that engineers who manage multiple agents in parallel are the canaries in the coal mine. In other words, they detect danger before others. Being the canary is flattering for four seconds, until you remember what happens to it.

The only gray tab is the one for what you were doing before.

The numbers, and they are not pretty

The Upwork Research Institute has been hammering the same nail for two years. In 2024, 77% of professionals using AI felt it had increased their workload. In 2025, after surveying 2,500 workers in four countries, the result is even more twisted. Among those who gain the most in productivity thanks to AI, 88% report being burned out. They are also twice as likely to consider leaving. To top it all off, 62% do not understand the connection between their daily use of AI and their company's goals.

On the technical side, Google's DORA 2025 report says the same thing with different measures. Among respondents, 90% use AI and over 80% believe it makes them more productive. However, 30% have little to no confidence in the code it produces. Most importantly, the adoption of AI goes hand in hand with a higher delivery pace, but also with more instability: more failures after a change, more rollbacks, and incidents that take longer to resolve.

To sum up. We deliver faster, we break more often, we don't trust what we deliver, and we are burned out. Excellent quarter.

Irony is forty-three years old

This mechanism is nothing new. That's the funniest part. In 1983, Lisanne Bainbridge wrote a classic text on the « ironies of automation », starting from airplane cockpits and industrial control rooms.

Its observation occurs in two stages. First, automation takes the easy tasks, those that can be clearly described. Therefore, what remains for humans are the tricky cases, precisely those that require the most experience. Next, they are asked to constantly monitor a machine while they no longer perform those tasks themselves. They are stripped of training and left with the examination.

The deal in one image. You have earned the right to only do the difficult parts.

In our profession, the mechanism is simple. Rereading code that you did not write can cost more than writing it. You first need to reconstruct the intention, then judge the result. When you write, you make a decision and you roll it out. When you reread, you must revisit the decision at every line. And, as DORA notes, the tool cannot signal its own doubts. It churns out nonsense with exactly the same confidence as a good answer. Impossible to sort quickly. You have to open everything.

The promise was less work. The real contract is zero repetitive tasks and 100% decisions. It’s like removing the straight lines from a rally, then explaining to the driver that you just made them save time.

Three days for the demo, twenty-seven for the rest

The best quantified counterbalance I have read recently comes from Luc Bonnin, who pushed the experience to the limit. He built ClearSpot.me, a web application for geolocation that locates wind turbines. He created it entirely with AI, in 30 days, without writing a single line of code by hand.

The first version was released in 3 days. It required 105 prompts, meaning 105 instructions given to the AI, to produce 80,782 lines. Stunning, really. Then it took an additional 27 days to obtain a truly usable application in production. Total: 1,117 prompts, 2.5 billion tokens (the pieces of text that the model reads, writes, and bills), and 206,347 lines in total. Most importantly, 90% of the tokens were consumed after the POC, the prototype used to verify that the idea holds up.

Three ways to measure the same project. All three say the same thing and none say what we wanted to hear.

His conclusion is clear: “Pareto applies perfectly to achieve an ultra-fast POC, but it’s a mirage if you really want to achieve a prod-ready application.” The database went from 40 MB to 40 GB, and it took writing 40 ingestion algorithms, meaning mechanisms responsible for importing and processing the data. Then the first trial with ten users revealed performance issues that were completely invisible during a solo demonstration. At his place, ten people were enough to conduct a load test.

The detail that everyone forgets is that the result was of good quality, with tests, documentation, and a clear architecture, solely because an expert supervised the process continuously. Zero lines written by hand does not mean zero skill required. The skill simply moved from the keyboard to the review. And no one thought to ask if it was less tiring.

What old monkeys are already doing

The most useful part of Blangeois's survey is that he does not dispense advice. He describes the solutions that the most experienced developers have already found on their own, without waiting for someone to ask them. Three strategies emerge.

The first is the draft. Before opening the tool, you write in simple words what you really want. “You set the AI in front of you. You tell it: we are going to work on this specification.” Without this framework, the machine produces something plausible. And the plausible is the number one enemy because it looks a lot like the right answer.

The second is reappropriation. A developer puts it very well: “I reread and understand every line produced. Not to check that it works, but to understand.” The test they impose on themselves is simple: could I defend this line in front of a colleague, without notes?

The third is refusal. We draw red lines and keep certain tasks to ourselves. This is the case for architectural choices that commit the system for years. The same goes for high-risk areas: payments, medical data, or client files. Finally, we keep the tasks that give meaning to the job. Otherwise, there is not much interesting left in the day.

The red tape on the desk is not in the official documentation of the tool.

The phrase from Blangeois that I remember is simple: looking at where experienced professionals refuse to use AI indicates what still needs to be learned to master it ourselves. It is the best career advice I have read this year, and it fits in one line.

The most ironic thing is that these three countermeasures consist of putting back the brakes that the tool had just removed.

The job is not dead, its easy part is

Bonnin ends his experience by quoting Jevons, an economist from 1865: when a resource costs less to use, we use it more, not less. If we produce more code, we create more systems, more dependencies, and more technical debt. Therefore, it requires more people to keep the whole thing standing. Seen this way, we will not lack work. It is rather the opposite that worries me.

So the real question does not seem to be “am I going to be replaced.” It is rather: can we last thirty years with days composed solely of decisions, arbitrations, and proofreading? Bainbridge did not answer this in 1983. Forty-three years later, we are still discovering the problem.