AI Didn't Break Your Productivity. It Broke Your Filter.

The cost of building used to filter your ideas automatically. AI removed that cost. Now you need a new filter.

8 min read

I was finishing a dashboard to track my accounts. Nothing fancy (a few metrics, clean display, real-time data). The kind of thing that had been sitting in a GSheet for months because "no time." I opened Claude Code at 2pm. By 4:30 it was running.

4:31. I was about to close the laptop and grab my daughter from school early. Then Claude suggested a webhook. The webhook revealed a gap in the data. The gap could become a feature. The feature could sell.

Not bad, I think. GO. (I have never just shipped a feature. I have shipped a feature plus three new ideas it generated.)

4:45. Wait (we could also pull the data directly from the account APIs). Is that possible? Claude: yes, let me check available APIs, etc...

At 6pm I had three branches open, nothing shipped, and the vague feeling of having been incredibly productive.

TL;DR: AI didn't break your productivity. It broke the economic filter that was selecting your ideas for you (silently, the whole time). This article explains the mechanism and how to rebuild it in three questions and two minutes.

Overwhelmed office worker confronted by superhero character amid complex AI productivity dashboards

The Filter You Never Knew You Had

Before Claude Code, every new idea had to pass a test. Not a conscious one (you never sat down with a spreadsheet and weighed options). The test was automatic, and it ran on a single variable: time (or cost, same thing).

"Would this take three weeks?" If yes, the idea died quietly. No decision required. The cost decided for you.

That filter was free. It cost nothing to run. It was also brutal (it killed probably 90% of your ideas before they became projects). And you never noticed, because ideas that die at conception leave no evidence.

Think about it differently. Every time you heard "eh, not worth it" in your head after a shower idea, that wasn't discipline. That wasn't good judgment. That was behavioral economics running in the background. Perceived cost above threshold: idea exits the queue. No conscious processing needed. Developers who've been building for years have had this filter calibrated by actual pain (three-week projects that went nowhere, features nobody used, rewrites that introduced new bugs).

The filter was doing real work. It just never sent you an invoice.

You didn't make decisions. The cost made them for you.

When Execution Costs Nothing, Everything Survives

The problem isn't AI. The problem is that AI works.

In microeconomics, when marginal cost approaches zero, demand becomes theoretically infinite. That's not a metaphor (it's what's happening in your backlog right now). When "build a webhook integration" goes from three days to forty minutes, every idea that was previously dead on arrival suddenly clears the bar. All of them. At once.

This isn't a discipline failure. It's a mechanical property of the tool. The filter didn't break because you got lazy. It broke because the variable it was running on changed value.

Actually, let me put it differently. A randomized controlled trial published by METR in July 2025 ran 16 experienced developers on their own real repositories using AI tools. Before the sessions, developers predicted they'd be around 24% faster. After, they estimated they'd been 20% faster. Measured actual productivity: 19% slower. Felt 20% faster. The gap is 39 points and a lot of open branches.

The study isn't making a broad claim that AI slows everyone down (the task scope is specific and the research is still being discussed). What it demonstrates clearly: the tool distorts your perception of forward movement. You feel like you're shipping. The branch count doesn't lie.

Two states side by side, minimal and flat. Left panel "Before AI": vertical axis...
Two states side by side, minimal and flat. Left panel "Before AI": vertical axis...

Feeling productive and actually moving toward shipping are two different things. AI is very good at generating the first feeling.

One caveat worth naming: in a team, you have partial filters elsewhere (roadmap reviews, PR approvals, someone saying "that's out of scope"). The solo builder has none of that. Every filter is self-imposed. Which means when the cost filter disappears, there's nothing left.

It's not you who cracked. The filter just left.

The Inventory: Two Projects at 60%, None Shipped

Let me show you the actual state of things.

Dashboard to track my accounts: core functionality done, running in prod. But there's a webhook branch, an API integration branch, and a "what if we added projections" commit that hasn't been touched in a week. The original task is done. I'm still in the repo.

ProspectMiner (my tool for finding clients for the SaaS): built the scraping module, built the data enrichment scripts, built three different list formats. Sitting on a hard drive. Unused for two months. Because I kept extending before using. Classic YAGNI violation (You Aren't Gonna Need It, the rule I know by heart and break on schedule).

Both projects are defensible. Both have real use cases. Neither is fully shipped.

A June 2025 report from Faros AI studied over 10,000 developers across 1,255 teams with high AI adoption. The results: 47% more tasks processed, 98% more pull requests per day. Sounds like a win. Also: review time up 91%, PR size up 154%. The bottleneck didn't disappear. It moved. For teams, there's at least a pipeline downstream to absorb the volume. For the solo builder, there's no one downstream. Branches accumulate. Nothing reviews itself.

This is systemic. Not a personal weakness. The tooling created structural pressure and nobody put it in the release notes.

The paradox is specific: 10 hours a day of real, focused work. Nothing shipped. And somehow you've never felt busier. 😵‍💫

10 hours on AI. Nothing shipped. And yet you've never felt this occupied.


Rebuilding the Filter: The Fictitious Cost Framework

The real cost disappeared. So we build a fictitious one.

Not to slow down. To force the conscious decision that the real cost used to make automatically. Three questions. Under two minutes. Run them before starting any new idea or opening a new branch.

1. "Would I build this if it took 3 weeks?"

This reintroduces the old filter artificially. Most ideas that feel brilliant at 4:31pm don't survive this question. The ones that do are telling you something real. Watch out for the obvious cheat: "well with AI it won't take 3 weeks." Irrelevant. The question is about perceived value, not actual time. If it's not worth 3 weeks of your life, it's not worth 40 minutes of drift either.

2. "Does this advance something that already exists?"

The distinction is extend vs. start. Extending a shipped project: legitimate. Opening a new branch on an unfinished project because AI made it easy: that's the trap. This question forces you to locate the idea on a map. If the answer is "it's a new thing," the bar just got higher.

3. "What dies if I start this now?"

Make the opportunity cost explicit. Before AI, this was implicit (you knew a 3-week project meant 3 weeks of nothing else). Now nothing has a visible cost, so you have to manufacture one. Name what gets deprioritized. Out loud or in writing. If you can't name it, you're not ready to start.

All three yes: go. Anything else: backlog or delete immediately.

The framework plugs into a larger system. I built the full Prompt Contracts approach after enough of these disasters (it controls what you build inside a session). The Fictitious Cost Framework controls whether to open the session at all. Together they cover the full loop.

One thing this framework doesn't handle: ideas that surface mid-flow on an existing project. You're deep in something, Claude flags something interesting, you don't want to lose it. Solution in the next section.

Decision flowchart for the Fictitious Cost Framework. Single entry point at top:...
Decision flowchart for the Fictitious Cost Framework. Single entry point at top:...

The fictitious cost doesn't slow you down. It makes the decision the real cost used to make for you.

How I Apply It: The IDEAS.md Contract

Every active project gets an IDEAS.md at root. One rule: any idea that surfaces during a session goes in that file with a date and a one-line answer to each of the three questions. Then I close the file. I don't open it again until the next session starts.

Two weeks ago on ProspectMiner.

We were building the enrichment module. Claude flagged three possible additions: automatic sector scoring, a CSV export, and an integration with Twenty (open-source CRM, genuinely good). I noted all three. Closed the laptop.

Next morning:

Sector scoring: survived. Real problem, clear use case, I could already picture the query structure.

CSV export: dead. (I love CSVs. Clean files, open them in nano, done. No electron wrapper, no config panel, just data. But GSheet already handles this. I was in love with the format, not the problem.)

Twenty integration: I had no memory of why I'd written that. None. The note just said 'Twenty - interesting??' Two question marks. Past me left no other clues. Deleted.

Two out of three dead by morning. Those two ideas cost zero development time, zero repo pollution, zero branch. The 24-hour filter did the work.

Ideas that survive 24 hours in IDEAS.md deserve to exist. The others were dopamine.

What the Filter Is Actually Protecting

You might think the filter protects your time. It doesn't. Not primarily.

The filter protects your identity as a builder.

Someone with 12 projects at 60% isn't a builder. They're an explorer. Not a judgment (a functional distinction). Explorers generate surface area. Builders reduce it. Both are useful activities. They are not the same activity, and confusing them is expensive.

AI tools are intent amplifiers. If your intent is clear going in, they amplify execution. If your intent is fuzzy, they amplify the fuzz. The Fictitious Cost Framework forces a clear intent declaration before each session. It doesn't change what Claude can do. It changes what you ask it to do.

There's one skill that's been quietly missing from the AI developer toolkit since this whole thing started. Not prompting. Not context management. Not knowing which model to call.

Deciding what deserves to exist.

Every other skill has tutorials. This one you mostly learn by staring at a branch list on a Tuesday evening and counting the 60-percenters. 🤷‍♂️

AI gave you the power to build almost anything. Nobody taught you how to decide what should be built.

The market will keep selling AI productivity. Frameworks. Prompt systems. "100x developer" workflows. (Sheeeh.) Nobody sells the real problem, because the real problem is that the tool works too well.

But the builders who ship are doing three things differently. They decide before they code. They name the opportunity cost out loud. They have a text file that says no for them.

AI changed the question. You just have to ask it before you open VS Code.

My wife had to go pick up my daughter. Because I forgot. I'm not proud. 😬


Sources

  • METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," July 2025
  • Faros AI, "AI Productivity Paradox Report," June 2025

If this kind of framework lands for you (practical, no LinkedIn carousel energy), follow. One article when something is worth saying, nothing when it isn't.

(*) The cover is AI-generated. I used it to visualize the precise moment I forgot to pick up my daughter. No regrets. (Some regrets.)


When AI drops the execution cost to near-zero, every half-baked idea suddenly looks like a potential product. Learn how to rebuild your productivity filter in the AI era.

Get the Production Shipping Kit