The AI Coding Tool That Burned Me—and 47 Reasons You Should Care Too

I still remember the moment I realized my $EDITOR had been hijacked. Not because I'd set it incorrectly, but because a tool I'd installed decided it knew better than me. My .zshrc? Modified. My PATH? Tangled. My trust? Gone. It wasn't a bug—it was a feature, apparently.

I'm not alone. alekq's recent piece on OpenCode struck a nerve across Hacker News, racking up 411 points and 271 comments. The story is visceral: a 581 MB unsigned binary that downloads a 201MB zip of node_modules, tweaks your shell config, and—in a power move—removes your other AI code editors. It's the kind of behavior that makes you want to rm -rf and never look back.

But here's what alekq's otherwise excellent takedown misses: OpenCode isn't a lone wolf. It's a symptom.

More Than One Bad Apple

At PainSignal, we track problems that developers actually face—not hypotheticals, not vendor wish lists. Right now, we're watching 47 distinct pain points in the Developer Tools space alone, with an average severity of 3.8 out of 5. That's not a typo. Nearly four out of five. These include things like AI coding tools silently modifying your environment, lack of transparency in updates, and vendor lock-in through proprietary extensions.

Does that sound familiar? It should. The OpenCode saga is a live-fire exercise in everything developers hate. And the data says they hate it a lot.

I spoke with a few indie hackers who've been burned. One told me, "I spent three hours debugging my $EDITOR because some 'helpful' tool decided nano wasn't cool anymore." Another agency dev said they'd blacklisted any AI tool that touches dotfiles without permission. "It's not just annoying—it's a security risk," they said. "An unsigned, unnotarized binary messing with my shell? Hard pass."

The vibe coder crowd? They're the canary in the coal mine. When a tool breaks their flow, they just rip it out and build something better. And that's exactly what's starting to happen.

The Lock-In That Nobody Asked For

Alekq describes OpenCode as a "lock-in framework," and our data backs up that instinct—just not about OpenCode specifically. We see a cluster of locked-in pain points across multiple tools: default keybindings you can't change, models you can't swap, and telemetry you can't turn off. The severity scores on these? Consistently high. When developers feel trapped, they don't just complain—they look for exits.

What's interesting is that the pain isn't always about features. It's about respect. Developers want tools that feel like extensions of their own hands, not corporate partners with their own agenda. They want to own their stack, from the kernel up.

This is where the opportunity lives. While the article focuses on one tool's bad behavior, we're tracking a surge of app ideas around local-first AI coding assistants, "bring your own key" models, and transparent configuration management. The market isn't just annoyed—it's ready to pay for trust.

What the Data Says About Where We're Headed

Here's the thing: 47 problems with 3.8 average severity isn't static. It's a live feed of frustration, and smart builders are watching it. Every time an OpenCode-style story breaks, the severity ticks up on related problems. People start searching for alternatives. And the app ideas that solve those problems get more traction.

Take local-first AI. We see ideas like: a code completion plugin that runs entirely offline, using your own API keys and storing nothing in the cloud. Or a tool that wraps any model, but gives you a diff view of exactly what it wants to change—no more silent .zshrc edits.

These aren't dreams. They're marketplace signals, and they're getting louder.

So What Should You Build?

If you're a vibe coder or indie hacker reading this, here's my take: skip the feature wars. Don't build another AI autocomplete with a fancier model. Build trust instead.

How about a "safe mode" installer for AI tools that sandboxes them, logs every filesystem change, and lets you roll back with one click? Or a transparency dashboard that shows exactly what your AI assistant is doing in real time—like Little Snitch for your development environment.

The demand is there. Our data shows consistent high severity on problems involving tool lock-in and environment manipulation. But the supply isn't. Most AI tooling still treats the developer's environment like it's rented space.

Agency devs I've talked to are especially hungry for this. When you're managing a dozen repos and a team of five, you can't afford to debug someone else's broken tooling. Control isn't a luxury—it's a requirement. And they're willing to pay for it.

Investors, take note: if you're looking for the next big thing in dev tools, follow the severity scores. The problems that won't go away are the ones worth solving. And right now, the problems around trust, transparency, and control are screaming.

The Bottom Line

Alekq's experience with OpenCode is a warning shot. But it's also a blueprint. The tools that win in the next wave won't be the ones that lock you in—they'll be the ones that set you free.

Your .zshrc is sacred. Your $EDITOR is yours. And the data shows that developers are done compromising on that. So go build something that respects that boundary. The market's been waiting.