Screen glowing in the dark, everybody else checked out hours ago. Scrolling through tech Twitter when Bloomberg drops: "Claude Code and the Great Productivity Panic of 2026."
I read the whole thing. And I had that split reaction you get when a doctor describes your symptoms perfectly, then prescribes the wrong medication. Yes, the pain is real. No, thats not why it hurts.
Bloomberg wrote 3,000 words about AI agents producing too much code too fast. They never once mentioned that nobody tells the agents what to produce. Three thousand words about a disease, and they forgot the pathogen.
TL;DR - Bloomberg's "productivity panic" article nails the symptoms but botches the diagnosis. The panic doesn't come from AI writing too fast. It comes from the absence of specifications. Vibe coding without contracts produces code with 2.74x more security vulnerabilities, makes experienced developers 19% slower (while they think they're 24% faster), and creates a 40% perception-reality gap. The fix isn't slowing down your agents. Its telling them what to build before they start building.
The symptoms are real. The cause is somewhere else.
I run my own projects. No VP breathing down my neck about agent utilization rates. And still, for most of 2025, AI made me slower.
Not on paper. On paper everything looked incredible. Features shipped in hours. Commits piling up. The git log looked like I had a team of five. But I was debugging more than building. I was reading code I didn't recognize in my own repos. I was spending Tuesday fixing what Monday's "productive" session had broken.
If you've been in that loop, you already know the Bloomberg article is onto something.
A UC Berkeley study tracked a 200-person organization and found that even as employees offloaded work to AI agents, they worked longer hours. The researchers call it "task expansion." The AI creates output, the output creates cleanup, the cleanup creates overtime. A VP at DocuSketch told Bloomberg he needs "a few more AI interactions before bed," which sounds like addiction but reads like fear if youve ever worried about falling behind on a tool everyone else seems to already master.
So yes. The panic is real.
But Bloomberg stops at "agents create pressure" and never asks the follow-up: why does more output create more work?
Because the output has no spec. That's the whole answer. An agent without constraints is a junior dev with infinite energy and zero context. It will produce. It will produce confidently. And what it produces will be almost right, which is worse than wrong, because you won't catch it until production does.
Bloomberg never says this. Partly because Bloomberg is a financial media outlet and the intended audience isn't the engineer debugging at 2 AM, its the investor recalibrating a portfolio. This article dropped six days after Claude Code Security tanked cybersecurity stocks 5–9%. The timing isn't journalism. Its market context.
And partly because naming the real cause, "nobody writes specs before prompting," makes for a boring headline. "Productivity Panic" sells subscriptions. "Write Better Prompts" doesn't.
Bloomberg sells the panic. Nobody sells the fix.
The data Bloomberg should have led with
Everyone benefits from keeping the panic alive. "AI transformation" consultants get a new market. Governance vendors get a new segment. Financial media gets engagement. Senior devs get a reason to feel indispensable. Nobody has an incentive to point out that the fix is boring.
But the data points at boring anyway.
METR ran one of the few rigorous studies on this, a randomized controlled trial with 16 experienced open-source developers across 246 real tasks. Developers using AI tools were 19% slower than without. But here's the part that should terrify you: they perceived themselves as 24% faster. That's a 40% gap between reality and what your brain tells you.
I know that gap. I've lived inside it. Code appears on screen, your brain registers "progress," and you skip verification because everything feels fast. You become your own worst QA department.
Veracode tested AI-generated code across more than 100 LLMs in four languages. 45% contained security vulnerabilities. 2.74 times more vulnerabilities than human-written code. And not because the models are stupid. Nobody specified the constraints. An LLM will happily build a login flow with no rate limiting, no input sanitization, credentials in plaintext. It wasn't told not to. So it didn't.
CodeRabbit analyzed over 10 million pull requests and found AI code produces 2.25 times more business logic bugs. "Business logic" is literally the stuff a specification defines, things like user permissions, edge cases, state transitions. The exact territory vibe coding skips because "the AI will figure it out."
And Anthropic's own January 2026 study found developers using AI scored 17% lower on post-task quizzes. Biggest gap: debugging questions. We understand less of what we ship. We stopped defining what we expect before pressing enter, and then we're surprised the result doesn't match.
None of these numbers say "AI is dangerous." Every single one says "AI without spec is dangerous."
Bloomberg confused the tool with the usage. These studies have limits, METR was 16 developers, Veracode tested varied LLMs with who knows what prompts. METR's own follow-up from February 2026 hints at speedups as tools evolve, but their data also shows the perception gap persists, developers still can't tell how fast they're actually going. The exact numbers are arguable. The direction isn't.
How I became a stranger in my own codebase
Heres my real story and its dumber than you think. The guy writing about prompt contracts got wrecked by not using one. Cobblers kids, barefoot, the whole cliché.
I was building a dashboard for one of my SaaS apps. Standard stuff: metrics page, Convex backend, Clerk auth, some charts. The kind of thing I've done enough times to be dangerous. This was before I formalized prompt contracts, back when every session was pure vibes.
I opened Claude Code in full vibe mode. Didn't spec the architecture. Didn't list the libraries I wanted. Just "build me a dashboard with auth and charts." Twenty minutes later, working page. Data flowing. Charts rendering. I felt like I'd unlocked a cheat code.
Three days later I needed to add a filter. Simple feature. Should take 10 minutes.
I opened the codebase and found TanStack Query everywhere.
I don't use TanStack Query. I've never used TanStack Query. I barely knew what TanStack Query was. Claude had decided my data fetching layer needed a caching and synchronization framework I'd never touched, wired it into every component, and built the whole state management around it.
The dashboard worked. I couldn't explain why. I couldn't modify it without breaking something because I didn't understand the abstractions holding it together. Adding a date filter meant understanding TanStack Query's invalidation patterns, and I was Googling basic concepts about a tool in my own project like a tourist reading a phrasebook in a country I supposedly live in.
Two days learning a framework I never chose, to modify code I supposedly wrote, in a project I supposedly own. Actually, let me rephrase that. Two days paying the tax on a decision I never made.
A three-line spec would have prevented all of it: "Use fetch + Convex hooks for data. No external state management libraries. Keep it simple enough that I can debug it at 1 AM without documentation."
That wasnt a one-off. Over the next two months I tracked my sessions. The pattern was always identical. Launch agent with vague goal. Get code that compiles. Deploy. Discover the gap between what I meant and what I said. Debug something I didn't even know was there.
The worst part isn't the wasted time. Its the feeling. You built it but you don't own it. Your repo looks like someone elses house. The METR data about developers thinking they're faster suddenly makes perfect sense, you genuinely believe youre shipping, right up until you need to change something.
The agent wasn't the problem. My prompt was.
The fix: contracts, not conversations
This is where I stopped treating Claude Code like a chatbot and started treating it like a contractor who will absolutely tile your bathroom in marble if you don't specify ceramic.
Before every session: what the agent must produce, what it must not touch, how I verify the result. I call it a prompt contract. Not because its legally binding, but because it forces the same clarity. Both parties know the scope. Nobody wakes up to a framework they didn't invite.
I built the full prompt contracts framework after enough of these disasters. The short version: goal, constraints, expected output format, failure conditions. Four fields. Ninety seconds to write. Saves hours of debugging and zero surprise frameworks.
Im not the only one landing on this.
An arXiv paper from January 2026 documented a financial services team that switched from freeform AI prompting to spec-first workflows with OpenAPI contracts. Integration cycle time dropped 75%. The AI didn't get smarter. The humans got clearer.
Kent Beck, the guy behind TDD and Extreme Programming, published "Augmented Coding: Beyond the Vibes" where he built a production-competitive B+ Tree library in Rust using structured AI prompting. His framing: vibe coding produces code that works. Structured prompting produces code you can maintain. Theres a difference, and it shows up at month three.
And that's exactly what Red Hat found. Vibe-coded projects consistently hit a wall around the three-month mark. The code works, then it doesn't, and nobody can explain why because the original prompts are gone and the codebase has no documented intent. Just vibes. Former vibes. Dead vibes.
Prompt contracts won't save you on exploration. When you genuinely don't know what youre building, vibe away. Fast, cheap, disposable. The problem starts when vibe becomes the default for everything, including code that goes to production and code that other people depend on. That's not exploration. That's negligence with extra steps.
Specs arent bureaucracy. Theyre the shortest path to shipping.
The bodies vibe coding left behind
Bloomberg covers capital. These stories are about craft. Different panic, same root cause.
Daniel Stenberg maintains cURL, the tool running on roughly 20 billion devices. In July 2025 he documented that 20% of bug bounty submissions were AI-generated slop. Confident, detailed, completely fabricated vulnerability reports. Each one ate 3–4 security team members for hours. Confirmed rate collapsed under 5%. He shut the whole program down in January 2026. His words: "Time and energy that is completely wasted while also hampering our will to live."
The reporters werent malicious. They pointed an AI at cURL with no spec for what constitutes a real vulnerability. The model generated plausible garbage. Same pattern as my TanStack disaster, just at ecosystem scale.
Then there's Adam Wathan, who created Tailwind CSS. January 2026: 75% of his engineering team, laid off. Tailwind was more popular than ever, more downloads, more projects, more adoption. Revenue down 80%. Docs traffic down 40%. AI tools memorized Tailwind and generate classes inline, so nobody visits the docs anymore. The business model didn't fail. It got consumed by AI without attribution, context, or payment. I think about this one a lot, actually, because it means you can win the adoption game and still lose 💀
Mitchell Hashimoto, co-founder of HashiCorp (built Terraform and Vagrant), runs Ghostty, a terminal emulator. By January 2026 he was drowning in AI-generated drive-by pull requests. Low-effort, unreviewed, broken. His response: permanent bans. His framing: "This is not an anti-AI stance. This is an anti-idiot stance."
Three cases. Three domains. One structure: output generated with no definition of what "good" means. Code without contracts. Reports without criteria. PRs without standards.
The AI produced volume. The humans drowned in it. Bloomberg didn't cover any of this because Stenberg shutting down a bug bounty doesn't move stock prices. But if you build things, this is the panic that actually matters.
If you want to see structure over vibes applied to tooling, the same principle holds: define the interface before you build the feature.
What Bloomberg should have written
The "productivity panic" isn't an AI problem. Its a transition problem. We are in the phase where everyone has the tool and nobody has the method.
Bloomberg doesn't name this because an article about panic with no solution generates more engagement than a practical one with a fix. Describe the anxiety, sell the subscription, move on. That's the model. A diagnostic article with a cure is less shareable than one that lets every reader project their own fear onto it.
Think about what "AI fatigue" actually describes. The DocuSketch VP who says he needs more AI interactions before bed isn't addicted. Hes scared. If I don't master this tool, someone who does will take my seat. Bloomberg frames this as a wellness concern because "workers terrified of obsolescence" is a harder sell to the C-suite audience paying for Bloomberg Terminal access.
The only real answer to replaceability is competence. Not panic. Not longer hours. Not more prompts before bed.
Competence means knowing how to direct the tool, not just how to run it. It means writing a three-line spec before launching an agent. It means owning your architecture choices instead of discovering them three days later in someone else's framework. It means treating AI like a contractor, not a cofounder.
This isn't complicated. Its just not viral 🤷♂️
The panic is real. The diagnosis is wrong. And the article is the product.
I write about what actually works when you build with AI agents, no hype, no "10x your productivity" nonsense, just the stuff I tested and the stuff that broke. Subscribe button is right there if that's your thing.
*That cover image is AI-generated because my design skills peaked at centering a div in 2019 and its been downhill since.
Top comments (0)