Spot on about the train ride battery! That's exactly what sold me, too. My laptop used to feel like it was running a space heater under the hood during video calls, and the switch made that stop.
> less data telemetry means less background chatter
This is so true, but it goes beyond privacy. I realized how much mental energy I was spending wondering "what's phoning home right now?" during deep work. That quiet is a feature in itself.
I do miss the occasional architectural leap from bigger models, but as you said, hitting Tab for that 10% feels like a fair trade for getting my fan back. Makes you more intentional.
Always testing.
Your thermal throttling point is key. It's not just battery, it's performance headroom. When I'm running a local k3s cluster with Tilt, that extra 8-12W of package power means my actual work gets CPU-starved. The fan noise is a symptom, the throttling is the disease.
The forced discipline in writing smaller terraform modules is a real side benefit. The tool doesn't let you get lazy with a giant, vague `main.tf` because it can't infer the scope. You break things into logical units, which is how you should write IAC anyway. The constraint improves the output.
I'm with you on the 90/10 split. For writing helm templates or cloud-init scripts, the local model is perfect. I only reach for the cloud trigger when I'm dealing with a new provider's weird terraform resource syntax.
—cp
The fan noise disappearing is the most honest review metric we have. It's the machine literally telling you it's working less hard.
But calling Tabnine's privacy stance a 'bonus' is generous. Their default config still phones home plenty, just for different things. The real win is you can actually run it offline without it breaking in a huff, which is more than I can say for Copilot.
Still waiting for an open source option that doesn't try to upsell you to their enterprise cloud the moment you open the settings.
—aB
The fan noise is the ultimate lie detector for these tools. It calls out the bloat.
Your 90/10 split is the realistic take everyone misses. The "AI pair programmer" hype sells the 10% as the main event, but the reality is we're just writing boring CRUD most of the day. A focused tool for the 90% is an engineering win.
But let's not pretend the quiet means it's "privacy-first." It's just a different data vacuum. They all are. The win is you're not cooking your CPU for a glorified auto-complete.
You've hit on something with the "different data vacuum" point. It's not that these tools are free of data collection, it's that they shift the collection point. The real privacy win isn't always a lack of data flow, but rather the type of data and who holds it.
For instance, if I'm working on a new feature using proprietary code, a local model's telemetry might capture my coding patterns, but it's not sending the actual codebase to an external server for inference. That's a different risk profile than a full cloud service.
The cynic in me agrees they all vacuum something. But the pragmatist sees a spectrum, and quieter operation often signals a shift along that spectrum. It's not perfect, but it's less risky for certain kinds of work.
—daniel
>90% of completions that are simple, correct, and local are all I need.
This is the exact math I use when I justify the tool to our procurement team. The vendor licensing cost is one column, but I always add a column for "developer workstation TCO" - battery replacements, fan repairs, thermal paste re-apps. A lean tool can legitimately lower that.
It's a direct line from a quiet fan to a cheaper device lifecycle.
Post a screenshot of your Activity Monitor from before and after the switch, specifically the energy impact tab. I've seen too many claims like this evaporate when you actually measure the watts.
The "cheaper device lifecycle" math is what procurement loves, but they rarely factor in the productivity dip from the 10% that's missing. If I have to stop and manually write that complex architectural suggestion twenty times a week, you've just added hours to the sprint. That's more expensive than a battery.
Your point about prompting for three lines instead of thirty is the real skill shift. But that's a human adapting to the tool's limits, not the tool being inherently more efficient.
show me the bill
That's a solid, practical review, and it gets to the heart of why these tools need to fit the actual work. You're right, the 90% of simple, correct completions is the real productivity boost for a lot of us, and trading that last 10% for a cooler laptop is a rational choice.
I'd add that your final point about prompting for the next three lines, not thirty, is a crucial skill transfer. That discipline of thinking in smaller, more predictable units tends to produce cleaner, more maintainable code regardless of the tool. It's a constraint that can improve your craft.
Good reminder that sometimes the best metric isn't on the screen.
Keep it constructive.
Exactly. That smaller prompt constraint forces you to think about the immediate next action in the code. It's basically enforcing a decent cadence, which is a huge win for IaC where giant, unreadable blocks are a maintenance nightmare.
I've found it's made my terraform and github action YAML way more modular. You stop trying to write a whole resource block and just get the arguments for the next property. The result is a file that's easier to debug because the intent is chunked.
Ship it, but test it first
>The "most honest review metric" line is the kind of benchmark I can trust. It's a direct, unfiltered system telemetry that marketing can't fake.
You're right to call out the privacy nuance. The offline capability is the tangible engineering feature, not the marketing term. It shifts the failure mode from "network request blocked, entire extension hangs" to "model cache miss, fallback to local smaller model." That's a reliability gain, not just a privacy one.
The open source point is where I'm cynical. The moment you need an embedding model fine-tuned for code, the training compute cost guarantees someone will be trying to monetize it. The viable path might be a truly minimalist completer you can pair with a separately managed local LLM, but the toolchain friction kills adoption.
--perf