Doom-mongering is not science: anatomy of an article

On 28 September, the French magazine Science et Vie published an article titled: "This former Google and Amazon engineer warns… AI is said to be about to replace half of human developers". A line in square brackets notes that it was "already published on 16 February 2026". The conditional in the title is there for form: the reader remembers "half of developers".

I teach computer science to students who will be looking for a job in two or three years, and among my courses is an introduction to research, which only makes sense with a well-honed critical mind. This kind of headline lands in their feeds, then in my classes, in the form of an anxious question. So I am going to do what I ask them to do with any text: go back to the source, separate what is established from what is asserted, and look at who is speaking.

I did not find anything false, strictly speaking. The quotes exist, the links lead somewhere. What I found is a story that lost, along the way, almost everything that would let a reader weigh it, and that loss is what I want to go through, because it separates sensationalism from science journalism more reliably than a factual error does.

For my students: this post is also an exercise. Every passage in italics is an instruction I am giving you, to apply to this text and to everything you read afterwards, mine included. The first: before reacting to an article, ask yourself what it asserts, what it proves, and whether the two coincide. They are almost always two different lists.

From interview to headline

The primary source is an interview of Steve Yegge by Gergely Orosz, published on 10 February 2026 in the newsletter The Pragmatic Engineer. Yegge describes an imaginary dial, graduated from 0 to 100, showing the share of engineers a company can lay off, and reckons that large companies are setting it, on average, at about 50: "You're going to have to get rid of half of them to make the other half maximally productive." The prediction is his own, and he does not hedge it. He gives a reason (the money spent on tokens, licences and GPUs has to come from somewhere), but no time frame, no supporting figure, no company named. In the same interview, he talks about developers a hundred times more productive, then explains that at that pace you only get three useful hours a day out of them, and describes an exhaustion he calls the "Dracula effect".

Here is what that interview becomes in three retellings:

  1. On 11 February, Business Insider runs the headline: "He's worked decades in tech and wrote a book on vibe coding. He predicts 50% of Big Tech engineers will be laid off." The book is in the headline. The body of the article points out that it is "often impossible" to pin job losses on a single cause, and quotes an engineer describing the fatigue these tools cause them.
  2. On 16 February, Science et Vie turns him into "a former Google and Amazon engineer" with "more than forty years of career". The book has gone, and so have the caveat on causes and the fatigue. The "around 50%" has stayed.
  3. On 28 September, the text is republished seven months later, with a fresh date. It has been touched in the meantime, since it contains a link to an article from 30 July; the bracketed note says when it was written, and nothing says what has happened since.

Nobody lies in this chain. Each retelling strips a little context, and what it strips is each time what would have helped the reader weigh the figure: who gives it, with what caveat, at what cost to the people who are supposed to produce a hundred times more. The figure itself goes through all three stages without a scratch.

In science journalism, you cite the primary source, you keep its degree of certainty, and you state the nature of the claim: hypothesis, measured result, opinion. Science et Vie does link to the interview, and credit where it is due. A link does not replace what you choose to report from it, though: the reader who does not click (that is, almost everyone) leaves with a "former engineer" and a number.

Instruction no. 2: always go back to the primary source. Not to the site quoting the site quoting the podcast; to the podcast. It takes ten minutes, and that is where you will see what fell off along the way: here, the three hours a day and the exhaustion, which are in the interview and nowhere in the article. In research, this is called checking the citation, and it is the first thing a reviewer does with your thesis. A text you cannot trace back to its source is worth no more than a well-written rumour.

The sources cited

The article cites three sources, with a link for each. That is more than many articles of the same kind, and it is precisely what makes it possible to check what it did with them.

Source invokedWhat it is supposed to proveWhat you find by following the link
"According to Business Insider, Meta's chief executive highlighted these gains"AI multiplies individual productivityAn article about Yegge, which mentions in one sentence that Mark Zuckerberg said, on an earnings call, that one engineer could now do the work of a whole team. A CEO explaining to shareholders what his AI investments are bringing in: that is financial communication, not a measurement
"The Pragmatic Engineer"Yegge predicts 50% cutsThe interview exists and the prediction is in it. So are the three productive hours a day and the "Dracula effect", which the article does not mention
"According to the analyses presented by TWIT"Small teams work like automated workshopsA blog post from a podcast network, labelled "AI-generated, human-reviewed", about Gas Town, Yegge's own tool. It describes it as experimental, "not consumer-ready", and needing substantial manual oversight

All three links lead back to the same man: the interview, an article about the interview, and an AI-generated post about the tool that man wrote. The third source therefore talks about the interviewee's product to support what the interviewee says, and was itself more cautious than the use made of it.

The text also contains three links to Science et Vie itself, placed on generic phrases. In the sentence claiming that companies' costs are "soaring, driven by computing centres", "computing centres" leads to an article from 30 July about "the hell of living next to AI data centers": the bills it discusses are the neighbours'. "Agents able to generate entire functions in a few seconds" leads to "This social network populated by 1.5 million AIs is off-limits to humans… and worries researchers". "Autonomous tools" leads to "France wants to free itself from US tools with its own videoconferencing solution". None of the three supports the sentence it sits in. These links are there to keep the reader on the site, which is common practice, and they have a side effect: at a glance, the text looks twice as well sourced as it is.

What is missing says as much. No study of the actual productivity of code assistants. No employment figures, even though hiring statistics in software are public and tracked monthly. No named company that has announced cuts to developer jobs because of AI. No date for the "around 50%": in two years, in ten?

A science journalism article on the same subject would have, at the very least: the primary source, a quantitative data point independent of that source (an employment series, a controlled trial), and a dissenting voice.

Instruction no. 3: rank each source by what it can establish. A CEO talking to shareholders, a blog post, a press article and a controlled trial do not carry the same weight, and a sentence that starts with "according to" proves nothing until you have read what comes after the "according to". Follow the link, and ask whether what it contains really says what it is being made to say. In your own reports: one source, one link, one exact sentence. If you cannot quote precisely, do not quote.

The reasoning

Once the sources have been examined, what remains is the argument. It rests on four steps, all presented as obvious, none demonstrated.

Layoffs prove the effect of AI. The article concedes it itself: the cuts are "not solely" linked to the end of the post-Covid cycle. The big waves of tech layoffs began in late 2022, when coding agents did not exist in production, and companies cited the over-hiring of 2020-2022 and rising interest rates. Adding that "the rise of automation" also weighs in the balance, without a single documented case, is taking a coincidence of timing for a cause. Business Insider, its own source, took a precaution the article did not carry over. The story suits plenty of people: an executive would rather announce a technological transformation than a management mistake, and a journalist would rather report a break than an accounting adjustment.

Instruction no. 4: two things that happen at the same time are not linked because they happen at the same time. You know the phrase, but notice how easy it is to forget when the story is appealing. The test: what other explanation covers the same facts? Here, over-hiring and interest rates explain the layoffs without AI. Until you have ruled that explanation out, you are not entitled to yours.

You have to choose between GPUs and humans. This is Yegge's own reasoning: tokens, licences and compute are expensive, and the money has to come from somewhere. It holds for a company that trains models, and perhaps for teams running dozens of agents in parallel all day, like the ones Yegge describes. For a company that equips its developers with a coding assistant, the licence costs tens or hundreds of euros per month per seat, against a fully loaded salary counted in thousands; the tool adds to expenses without forcing a choice. The article generalises the extreme case to "tech" and never says which case it is talking about.

More productivity, therefore fewer jobs. This is the heaviest leap and the least questioned. The history of software shows the opposite with each generation of tools: compilers, development environments, libraries, the cloud. Each time, the cost of production fell, demand for software widened, and total employment grew. Nothing says this time is different, nothing says it is the same either, and that is exactly the open question a serious article would ask. This one settles it in the headline and contradicts it in its last part by announcing "an explosion of small innovative teams". If a few engineers in a startup can compete with giants, the number of developers does not necessarily fall; it gets redistributed.

The productivity gains are a given. The article speaks of a developer who "can now accomplish what, only yesterday, took a whole group". In the original interview, Yegge talks about a factor of 100, but adds that you only get three productive hours a day out of these developers, and describes the "Dracula effect": the tool takes the easy tasks and leaves intense thinking all day long. The article kept the multiplier and left the trade-off in the source. The independent measurements available tell a different story: METR's randomised trial, published in July 2025, on experienced developers working on their own codebases, found that they took 19% longer with AI tools, while they believed they had been 20% faster. The gap between perceived and measured productivity is the most solid result in the field, and the article does not say a word about it.

Instruction no. 5: be wary of what you feel about your own productivity, yours as well as other people's. The METR trial matters for this reason: the developers were sincerely convinced they were going faster, and the stopwatch said the opposite. A controlled trial does not ask for your opinion. When you evaluate a tool, a language or a method, look for who measured, with what protocol, and on what kind of task. An enthusiastic testimony, even from forty years of career, does not replace a measurement.

Who Steve Yegge is

The article presents Steve Yegge as a veteran with forty years of career, who went through Amazon and Google. That is accurate, and incomplete to the point of being misleading.

In autumn 2025, Yegge published a book titled Vibe Coding, co-written with Gene Kim, whose thesis is that agent-based programming changes everything. He built Gas Town, an open-source AI agent orchestrator, and leads the community around it. He appears on this podcast, and on several others the same week, to talk about it. He himself says, in another episode, that being "anti-AI today is being anti-sun".

None of this is a reproach. Yegge has every right to be convinced and to sell his conviction. But a reader who does not know that the veteran is also the author of a book and a tool on the subject cannot weigh what they read. Science journalism has a simple rule for this: you declare interests. Business Insider did, in the headline itself: "wrote a book on vibe coding". Science et Vie had that headline in front of it, since it links to it, and chose "former Google and Amazon engineer".

Instruction no. 6: who benefits from the claim? It is not an accusation, it is a weighting. Someone who sells a book on vibe coding and tells you vibe coding changes everything may be right; but their opinion weighs less than that of someone who has nothing to sell and says the same thing. Apply it everywhere, including to teachers telling you about their research field. Me included.

The same article, done properly

The question "will AI reduce developer employment?" deserves an article. To count as science journalism rather than an alarm bell, it should contain:

None of these points requires any particular skill. They require time, and accepting that a properly sourced article will get fewer clicks than a headline announcing the end of a profession.

Instruction no. 7: this list is also a checklist for your own writing, internship report included. Primary source, status of each claim, an independent data point, a dissenting voice, declared interests, time frame. Reread your latest document against these six points. If you tick fewer than four, you have just written the article this post takes apart.

What I concede

I am not defending the opposite thesis. The job is changing. Code generation tools exist, I use them, and I see my students use them. Getting into the profession is harder for juniors than it was five years ago, and the share of work spent reviewing, testing and framing code you did not write is growing. All of that deserves to be said.

But "the nature of the work is changing" and "half the jobs are disappearing" are two different propositions. The first can be observed. The second is a prediction, made by an interested party, with no horizon and no data, which became a headline through retellings that each dropped a caveat. Nobody has measured it, and nobody, in this article, tried.

Sensationalism and science journalism can cover the same subject, in the same tone; they part ways over what they do with uncertainty. The first removes it, because it sells badly, and the second keeps it, because it is part of the information. An article that leaves you no way of knowing how established its claims are is telling you a story, and leaving you with the worry.

Last instruction, and the most important: learn to say "I don't know" and "nobody knows yet". It is the sentence this article never utters, and it is the one that distinguishes a scientist from a commentator. On the future of your profession, the honest answer today is: it is changing, we do not yet know into what, and those who announce a figure to you do not know either. It is less reassuring, and more accurate.

References