The world has spent a fortune on AI. For most enterprises, nothing changed. I’ve spoken to over 300 CEOs, CIOs and CFOs at the largest companies on Earth. I learned most companies apply AI onto their garbage processes, and the end result is just making garbage faster. Whether it’s buying thousands of Claude Code licenses, committing $50M in annual token spend, or running AI training sessions over Zoom, I’ve seen first-hand how inefficient AI adoption has been. It doesn’t have to be this way.
We’ve already gone down this path, multiple times in fact, and we ought to learn from history when it comes to AI adoption. In 1990, a former MIT computer science professor by the name of Michael Hammer wrote an article for the Harvard Business Review.
“Heavy investments in information technology have delivered disappointing results, largely because companies tend to use technology to mechanize old ways of doing business. They leave the existing processes intact and use computers simply to speed them up.”
If you swapped out ‘information technology’ for ‘AI’, you could publish that tomorrow. — Read More
Daily Archives: September 8, 2026
‘Model fatigue’ sets in as AI labs race to roll out new versions at frenetic pace
First, Anthropic updated Fable and Mythos. Then came model enhancements from Meta and Google. OpenAI followed suit by releasing GPT-6 Astra.
[F]or the users of AI models and services, it’s created complexity and chaos as CEOs and IT managers spend an outsized amount of time and resources comparing costs and capabilities to avoid getting left behind. — Read More
Bullshit Management Didn’t Die. It Got Automated.
Four years ago, I was pissed. I knew I wasn’t doing product management, but I couldn’t name what I was doing. Eventually, the term found me: bullshit management. I wrote exactly what I felt, published it, and moved on. Barely did I know what was about to happen.
That single article got over 1 million reads combined across LinkedIn, Substack, Medium, and my website. I ended up speaking about it at conferences in 12 countries. For a long time, I asked myself why this one traveled so far.
The answer is uncomfortable. People were tired of doing bullshit management, but they didn’t have a name for it. I gave this name and people embraced it. — Read More
Stealing Reasoning Traces from Proprietary LLM APIs
Leading large language model providers now conceal their models’ step-by-step reasoning, or chain-of-thought, to protect intellectual property and limit information leakage. Rather than storing these traces server-side, providers return them to the client as blocks of encrypted text, which the client passes back with each subsequent request. Building on prior research, we identify an architectural vulnerability: these encrypted blocks are fully compatible and interchangeable across different sessions, users, and models within a provider’s ecosystem. We exploit this compatibility to develop a scalable decryption jailbreak. By injecting an encrypted reasoning trace from a given model into a weaker, and less safeguarded model from the same provider, we force it to decode and output the trace verbatim in plaintext, without ever jailbreaking the more capable model directly. This vulnerability enables four distinct attack vectors. First, it circumvents anti-distillation mechanisms, allowing adversaries to extract a proprietary model’s reasoning, as we demonstrate across Anthropic, OpenAI, and Google. Second, it allows for large-scale private data extraction. Developers frequently share session logs publicly, unaware of contents of the encrypted blocks. By decoding 315,320 reasoning blocks scraped from public repositories, we recovered 367 Personally Identifiable Information (PII) artifacts and 182 credentials. Third, it inadvertently reveals hazardous information hidden within the reasoning process, even in cases where the model’s final, visible output safely rejects a malicious request. Fourth, attackers can leverage this flaw to execute invisible prompt injections, embedding malicious payloads entirely within encrypted blocks to poison public agentic rollouts. Following responsible disclosure, we propose concrete cryptographic and system-level mitigations to secure client-side reasoning. — Read More
Why AI Research Tools Struggle to Fact-Check the Web: Building an Adaptive Evidence Pool
This article grew out of the comments on my previous piece, Why AI Research Tools Struggle to Fact-Check the Web, where, using GPT Researcher as an example, I showed how common search engines and context-building methods undermine the very foundations of AI-based fact-checking.
Not that those tools were bad. They’re brilliant at standard (re)search tasks. But when finding genuinely diverse and independent sources matters, they start to show their limits. So we fixed that part. Adding source assessment through an admission policy was enough to make a difference.
But as the readers’ comments quickly showed, I was only touching the tip of the iceberg. — Read More
The Year Finding and Exploiting Bugs Became Cheap, and What to Do About It
Over the past few years, nearly every security researcher I know has incorporated LLMs into their process. What began with chatbots quickly evolved into scripts calling model APIs, then agents, skills, custom harnesses, autoresearch loops, and more approaches than anyone can reasonably keep track of.1PeckShield tracked 16 hacks in January 2026, 15 in February, 20 in March, around 40 in each of April, May, and June, and a record 50 in August. August losses were $136M, down 49.5% from July, so attackers are striking far more often while taking less from each incident. CoinGecko’s 2026 State of Crypto Security Report counts 245 incidents and $3.63B lost between January 2025 and July 2026.
Toward the end of 2025, something shifted. Models and the harness/systems around them became better, and AI-assisted bug finding and exploit development stopped feeling like an interesting experiment, but it became reality, while we start observing an increased amount of exploits1. — Read More
How well do agents use test/verification techniques?
We previously noted that, while it’s easier than ever to hit a particular quality bar by having coding agents use effective test techniques, software quality seems to be getting worse, indicating that whatever defaults developers are using may not work very well. Here, we test if simple instructions to agents to use particular techniques or libraries improve implementation correctness, as a kind of test to see how effective agents are when guided by someone with no expertise in testing who’s maybe heard that you should apply certain techniques or use certain libraries. — Read More
Rick's Cafe AI 