The AI Productivity Trap - Aniruddha

Aniruddha

SubscribeSign in

The AI Productivity Trap

Aniruddha<br>Jun 30, 2026

Share

Everyone is doing more with AI. More spend, more tokens, more usage, and that’s become the thing people point at to show they’re getting value. Look how much we’ve ramped. Look at the adoption curve. And yet the same people quietly complain the impact isn’t landing the way they expected. The usage went up. The shipping didn’t.<br>I’ve been chewing on this for a few weeks. I think two things are going on. Most people are wrong about what good use of AI actually is. And there’s a structural reason they drift away from it even when they know better.<br>Most things fail

Start from what the job actually is: ship things customers want and will pay for. Then sit with an uncomfortable fact. Most of what we build fails. At a large company, you might be slightly better than average, but it’s really hard to tell the good bet from the bad one in advance.<br>I learned this the hard way at Mixpanel. I worked on a feature that let customers bring all kinds of data into Mixpanel and analyze it there. We spent months building the best possible version. We did almost all of it without putting anything in front of a customer. When we launched, it flopped. We’d built in a vacuum, and never shipped the rough, embarrassing version early enough to let customers tell us what was wrong. Over the years, I’ve seen this exact thing play out multiple times at various companies.<br>So the lever isn’t being smarter. It’s more attempts you can learn from. Not a thousand things flung at customers at once, but tighter cycles. Get something a customer can react to in front of them fast, keep what sticks, throw the rest away.<br>In my view, effective use of AI is something that makes this iterative shipping faster, better, safer.<br>Path of least resistance

Most people are not using AI this way. Code generation was AI's first big win, and the lowest-friction thing to reach for. You type, code appears, it mostly works. It feels fantastic.<br>So that’s where everyone went. Not by choosing it. By following the gradient. The fast thing feels good, so people go looking for more work that uses the fast thing. More features to build, more to refactor, more tooling, more dashboards, more one-off skills for everything. And the comfortable AI work is low-ROI precisely because it’s the work that lets you keep doing the one thing AI made easy. The path of least resistance and the path to shipping faster are not the same path. They feel the same from the inside, because both involve doing a lot.<br>Sometimes the rewrite or cleanup genuinely is the top priority, when it’s unblocking your ability to ship or it’s a real objective this quarter. That’s legitimate, but it clears a high bar. The trap isn’t doing non-shipping work. It’s reaching for it because it’s easy and calling it priority after the fact.<br>Writing code was always just one bottleneck among several. Remove it and the constraint doesn’t disappear. It moves: to review, to verifying the thing does what you meant, to getting it to production, to debugging. Somewhere uphill, somewhere less fun than typing. The skill is going there anyway: find the next bottleneck, point AI at it, move to the next. The people who say AI never delivered the gains they were promised optimized the one downhill step and hand-crank everything after it. They’re in the loop far more than they need to be.<br>Loops

Climbing means a different relationship with the tool. Stop steering AI one instruction at a time like a task monkey. Treat it as a non-deterministic blackbox you point at a goal. Define the end state and how to verify it, then let it churn. Review loops, browser tests, verification scripts, self-correction harnesses. The longer your agent runs before it needs you, the more you’re getting out of it.<br>Here’s the discomfort. It’ll sometimes write less efficient code, and occasionally hand you a bug. That cost is tolerable, but only because you invested in the harness that catches it. The verification is what makes the speed safe. It is not the thing you skip in order to go faster.<br>The engineers getting the most out of this look different from a year ago. They set goals instead of joining loops. They go from customer need to prototype to production in tighter cycles than before, and throw code away without flinching, because the code was never the point. The signal was.<br>What’s left

If AI does the cranking, what’s left for the engineer isn’t keystrokes. It’s taste, customer understanding, judgment about what’s worth building. AI doesn’t know your customer. That’s the part of the job that didn’t get easier, and it’s the part worth your time.<br>So before you reach for AI on anything, ask one question. Does this compress my time to ship something a customer can react to?<br>If yes, lean in hard. Build the loops, build the verification, get out of the way. If no, be honest. The work might be worth doing, but it’s not where the...