HBR Paper Names the LLM "Trendslop" Phenomenon, a Three-Way Coding Agent Comparison Puts Engineering Behavior to the Test, METR's RCT Shows AI Use Made Development 19% Slower, and More

The "Trendslop" Bias Lurking in LLM Strategic Advice — A New Concern Flagged by an HBR Paper

In March 2026, a paper published in Harvard Business Review by Romasanta, Thomas, Levina, and colleagues gave a name — "Trendslop" — to the systematic bias found in LLM strategic advice.

Ask ChatGPT or Claude "cost leadership or differentiation?" and the LLM will almost invariably push "differentiation." Ask "automation or human augmentation?" and you will get "augmentation" back with high probability. The paper empirically demonstrated that this skew is no accident — it stems from the trendy vocabulary and concepts that are overrepresented in LLM training data.

The phenomenon becomes a practical problem when executives mistake LLM responses for "objective, comprehensive analysis" and overlook options they should have weighed (such as cost reduction or efficiency gains). When using LLMs for strategic decision-making, you need to apply corrections that assume this systematic bias up front.

An In-Depth Three-Way Coding Agent Comparison: Claude Code vs Codex vs Gemini

A comparison report published on Zenn handed the same design document to Claude Code, Codex, and Gemini, had each of them implement a small-scale application covering a backend, a web frontend, and a mobile app, and then evaluated and compared the deliverables.

The point of the evaluation was not simply whether each agent could "build a working app," but whether, when given instructions, it implemented things with the concerns a real engineer should have — operability, maintenance, running costs, and the like — in mind. To ensure fairness, Codex handled the specification design, which was refined through reviews by Claude Code and Gemini until no further issues were raised, and only then handed off for implementation.

The report says the differences in each agent's default behavior were thrown into sharp relief. See the original article for the detailed evaluation results, but the key takeaway is that when choosing a coding agent, how you evaluate "behavior as a good engineer" — not just raw code generation ability — is becoming a critical point of debate.

What METR's RCT Reveals About the "AI Backfire Effect" — Are Experienced Developers More Prone to the Trap?

In a randomized controlled trial (RCT) run by METR, an AI capability evaluation organization, experienced developers using AI tools expected to get 24% faster — but in fact turned out to be 19% slower. Even more striking, in the self-assessments they gave after finishing, the participants themselves believed they had become 20% faster.

This data is analyzed in detail in a Zenn article titled "5 Engineer Profiles That Get Slower the More They Use Claude Code." The article argues that AI tool mismatches manifest as a matter of "who is using them" rather than "how they are used," extracts five "backfire personas," and presents a framework for self-diagnosis and deciding when to walk away.

These results add an important correction to the assumption that adopting AI tools always leads to productivity gains. Of particular concern is the finding that the more experienced developers are, the more they tend to overestimate their own judgment.

The "Incrementalism" of ML PhD Research Sparks Debate — What Does Research Quality Mean?

A lively debate has erupted in Reddit's MachineLearning community over whether research in modern ML PhD programs has become too incremental.

The poster points out that much ML PhD research follows a predictable pattern: "combine an existing idea with another existing idea, apply it in a slightly different setting, and claim SOTA on a benchmark." The same pattern shows up in papers at top conferences, prompting the question: "once you strip away the SOTA claims, how much insight actually remains?"

The discussion also includes self-criticism of the ML field's incentive structure, which rewards "publishable deltas." The poster themselves admits, "I see the same pattern in my own research," and the debate has unfolded as a structural problem for the field as a whole.

What separates "a truly excellent incremental ML PhD thesis" from "a polished collection of benchmark papers"? No consensus has yet formed around this question, but one thing is certain: an important conversation has begun within the community.