I Filtered LinkedIn AI Slop Using an Open Source Extension — Here's the Exact Setup

TL;DR: The feed shift happened fast. I remember when the cringe on LinkedIn was at least human cringe — the "I am humbled and honored" acceptance posts, the guy who cried in his car before a big presentation, the CEO sharing a parable about a starfish.

📖 Reading time: ~25 min

What's in this article

1. The Problem: LinkedIn Became Unusable
2. Tools You'll Actually Use (and Why I Settled on This Stack)
3. Installing LinkedIn Unfiltered
4. Configuring the Filter Rules
5. Filling the Gaps with uBlock Origin Custom Filters
6. Going Deeper with a Tampermonkey Userscript
7. Gotchas I Hit That Took Me Too Long to Debug
8. What This Setup Actually Changed for My LinkedIn Usage

The Problem: LinkedIn Became Unusable

The feed shift happened fast. I remember when the cringe on LinkedIn was at least human cringe — the "I am humbled and honored" acceptance posts, the guy who cried in his car before a big presentation, the CEO sharing a parable about a starfish. Annoying, sure, but those posts had a person behind them. What replaced it starting around mid-2023 is something fundamentally different: GPT-generated thought leadership that nobody actually wrote, posted by accounts that published nothing for years before suddenly going daily.

The specific patterns I started noticing — and couldn't unsee after — look like this:

• The 5-bullet "insight" post: "5 things nobody tells you about [X]." Every bullet is a vague platitude. The hook is designed by prompt, not experience. These things clock 800 reactions because the algorithm rewards early engagement, and engagement pods make sure they get it.
• Fake vulnerability bait: "I failed. Here's what I learned." Two sentences of manufactured struggle followed by a pivot to a product or newsletter. The emotional arc is too clean — real failure posts are messy.
• The carousel from someone who posted zero content before January 2023: You can check post history. Profile exists since 2018, zero activity, then suddenly a 10-slide "framework" carousel every Tuesday at 9am. That's not a journey, that's a content strategy someone bought.
• Hashtag stuffing with zero relevance: Posts ending with #leadership #innovation #growthmindset #AI #entrepreneur regardless of what the post actually says.
• The reply bait closer: Every post ends with "What do you think? Comment below 👇" — not because they want a conversation, but because comments boost distribution.

I dug into LinkedIn's own controls before building anything. There's a "Not interested" option per post, a mute button for people, and supposedly an algorithm preference panel where you can say you want "fewer" of certain content types. I spent a week clicking "Not interested" on every AI-reeking post I saw. The feed improved for about 20 minutes, then the exact same pattern posts came back from different accounts. The mute list doesn't transfer when new accounts copy the same playbook. LinkedIn's filter isn't fighting this — the engagement these posts generate is the product LinkedIn sells to advertisers, so there's no incentive on their end to suppress it.

What made me actually sit down and write code was opening LinkedIn one morning and seeing my entire above-the-fold feed — seven posts — were all structurally identical. Different topics, different faces, same 5-bullet format, same closing question, same manufactured energy. None of them from people I follow. All of them promoted by the algorithm because someone in my network "liked" them. That's the thing LinkedIn's settings can't touch: second-degree engagement amplification. Even if you could perfectly filter your direct follows, you can't stop the algorithm from surfacing content your connections interacted with. That's the actual attack surface, and no toggle in Settings fixes it.

If you're cleaning up more than just LinkedIn noise, check out our guide on Productivity Workflows — it covers a broader automation stack that pairs well with what I'll walk through here.

Tools You'll Actually Use (and Why I Settled on This Stack)

The Extension Doing 90% of the Work

I tried half a dozen approaches before landing on this stack, and the thing that surprised me most was how purpose-built LinkedIn Unfiltered is. Most content-filtering extensions are generic — they block by domain or keyword and call it a day. This one was written specifically to target the structural patterns LinkedIn's AI slop follows: the "I'm excited to announce" opener, the hollow motivational carousel, the fake vulnerability post. It hooks into the feed DOM directly and evaluates post content against a pattern set, not just a blocklist.

Installing it takes about 90 seconds if you've done Chrome extension dev mode installs before. Clone the repo, run the build, load the unpacked extension from dist/:

git clone https://github.com/AminFazlMondo/linkedin-unfiltered.git
cd linkedin-unfiltered
npm install
npm run build
# Then: chrome://extensions → Developer mode ON → Load unpacked → select dist/

The thing that caught me off guard was how aggressive the defaults are on first run. A few legitimate posts from people I actually wanted to see got caught because they happened to use phrasing the filter pattern matched. Spend five minutes reading the config before you assume it's working perfectly — it's tunable, and the defaults are intentionally strict to show you what it can catch.

uBlock Origin as the Cleanup Layer

LinkedIn Unfiltered misses things. Specifically, it struggles with promoted content and the "People also viewed" sidebar rail that LinkedIn has started injecting AI-generated summaries into. This is where uBlock Origin earns its keep. I use it not for its default filter lists but for manual element picker rules — right-click any div that slips through, pick the selector, save it. It sticks until LinkedIn does a frontend deploy and reshuffles their class names, which happens roughly every 2–3 weeks. Annoying, but the fix is 30 seconds.

My current set of custom cosmetic filters for LinkedIn looks like this in uBlock's My Filters tab:

! Hide AI-generated "skills" suggestions injected into feed
linkedin.com##.scaffold-finite-scroll__content > div[data-finite-scroll-hotspot-top]

! Suppress "suggested post" blocks that survive Unfiltered's pass
linkedin.com##.feed-follows-module

! Kill the "Add to your feed" sidebar spam
linkedin.com##.ad-banner-container

These selectors will drift over time — that's not a flaw in uBlock, it's LinkedIn being LinkedIn. The habit I've built is checking once a week whether the filters still apply and tweaking any that broke.

Tampermonkey for When You Want Logic, Not Just Hiding

If you want to go beyond hiding elements — say, you want to log which users consistently post AI slop, or you want custom scoring that factors in engagement-bait language in comments — uBlock cosmetic filters can't do that. Tampermonkey can. A userscript runs in the page context and can read post text, check against your own patterns, even write to localStorage to track repeat offenders.

Here's a minimal Tampermonkey script skeleton that scans post text and marks posts containing classic AI phrasing:

// ==UserScript==
// @name         LinkedIn AI Slop Marker
// @match        https://www.linkedin.com/feed/*
// @grant        none
// @run-at       document-idle
// ==/UserScript==

const SLOP_PHRASES = [
  "excited to share",
  "humbled and honored",
  "thoughts? 👇",
  "big deal",
  "my journey"
];

function scanFeed() {
  document.querySelectorAll('.feed-shared-update-v2__description').forEach(post => {
    const text = post.innerText.toLowerCase();
    // Flag post if it hits 2+ phrases — single matches get false positives
    const hits = SLOP_PHRASES.filter(p => text.includes(p)).length;
    if (hits >= 2) {
      post.closest('.feed-shared-update-v2').style.outline = '2px solid red';
    }
  });
}

// LinkedIn's feed is a SPA — MutationObserver is the only reliable hook
const observer = new MutationObserver(() => scanFeed());
observer.observe(document.body, { childList: true, subtree: true });

This is meant as a starting point, not a production solution. The selector .feed-shared-update-v2__description will break whenever LinkedIn pushes a CSS update, so treat it as a template you'll need to maintain. The MutationObserver approach is the right architecture though — LinkedIn's infinite scroll feed loads content asynchronously and a one-shot DOMContentLoaded listener will miss 80% of posts.

What I Tried and Dropped

Two tools I specifically gave up on: SocialFocus and a generic keyword-blocking extension called Hide Feed. SocialFocus has a clean UI and some LinkedIn-specific features, but it operates at the sidebar/widget level — it hides UI chrome, not post content. It's genuinely useful if your problem is LinkedIn's right-rail distractions, but it does nothing about the slop in the main feed itself. Hide Feed was the other dead end. Keyword blocking sounds right in theory, but AI-generated posts are specifically designed to avoid anything that sounds like obvious spam. They don't contain "click here" or "buy now" — they contain perfectly grammatical motivational mush that no keyword list catches reliably without also blocking content you want.

The other thing I ruled out early was trying to do this entirely through LinkedIn's own "I don't want to see this" feedback loop. I spent a week clicking that button on every AI post and it had no measurable effect on feed quality. LinkedIn's algorithm optimizes for engagement metrics it controls, not your content preferences — the feedback UI is a placebo. The extension approach works because it operates client-side and doesn't ask LinkedIn's permission.

Installing LinkedIn Unfiltered

The Chrome Web Store version and the source version run the same code, but I always load from source when dealing with anything that touches a social feed. You get to actually read the content scripts before they run against your session cookies. Extensions have broad permissions by default — tabs, storage, and host access to linkedin.com — so spending 10 minutes reading the source is worth it. The repo is clean and readable; this isn't a "trust me bro" situation, but verify anyway.

Clone it wherever you keep your dev tools:

# ~300KB total, no heavy dependencies
git clone https://github.com/AminFazlMondo/linkedin-unfiltered.git
cd linkedin-unfiltered

No build step required. The extension ships as raw JS/CSS/HTML, which is part of why I trust it — there's no webpack bundle you'd need to deobfuscate to understand what's happening.

To load it in Chrome or any Chromium-based browser (Edge, Brave, Arc all work the same way):

1. Navigate to chrome://extensions
2. Toggle Developer mode on (top-right corner)
3. Click Load unpacked
4. Point it at the cloned folder — the one containing manifest.json

You'll see the extension appear with a local ID instead of a Store ID. That's expected. The thing that catches people off guard: Chrome will show a yellow warning banner on every startup saying "Developer mode extensions are enabled." You can dismiss it each time or just ignore it. It doesn't mean anything is broken.

Firefox users follow a slightly different path. Go to about:debugging, click This Firefox in the left sidebar, then Load Temporary Add-on, and navigate to the manifest.json file specifically — not just the folder. Fair warning: Firefox drops temporary add-ons on every browser restart, so you'll reload it each session. If that's annoying, look into Firefox Developer Edition or Nightly, where unsigned extensions can be made persistent via about:config → xpinstall.signatures.required = false.

The first time you reload your LinkedIn feed after installing, the reaction most people have is that something broke. The feed looks sparse — maybe three or four posts visible where there used to be thirty. That's not a bug. That's the filter working. A huge percentage of what LinkedIn serves you is AI-generated engagement bait, reshared "thought leadership" that matches the extension's heuristics, and promoted content. When it gets stripped out, you're left with actual posts from actual people, and the volume drop is genuinely shocking. Give it a few scrolls before you second-guess the install.

Configuring the Filter Rules

The thing that caught me off guard first: there are two ways to edit rules and they are not equivalent. The popup UI is fine for adding a quick keyword, but it serializes everything through a small form that silently drops certain regex syntax if it doesn't validate on input. If you're doing anything beyond plain keyword matching, open the JSON directly. In Chrome, that means going to chrome://extensions, enabling Developer Mode, clicking "background page" or "service worker" on the extension, and then running chrome.storage.local.get(null, console.log) in that DevTools console to find where the config actually lives. Some builds persist to localStorage under the key lf_rules, others use chrome.storage.sync. Check both.

Here's the keyword list I dropped in on day one that immediately killed the bulk of the slop in my feed. These phrases are almost never used by humans writing naturally:

• humbled — every award, promotion, and speaking gig announcement uses this word
• excited to share — precedes approximately 100% of AI-drafted announcements
• big deal — has never described anything that was actually a big deal
• I asked ChatGPT — the tell that precedes a 500-word post of pasted output
• — hallmark of AI openers, also banned in my own writing
• let that sink in — always bold, always follows a fake-profound sentence
• unpopular opinion — always followed by a completely popular opinion
• I used to think — opener for the "growth arc" post template that ChatGPT loves

Regex is supported, and the syntax that consistently works across versions is PCRE-ish without lookahead in older builds. Stick to this pattern format in your JSON and you won't get silent failures:

{
  "rules": [
    {
      "pattern": "humbled (and|to)",
      "type": "regex",
      "flags": "i",
      "action": "hide"
    },
    {
      "pattern": "\\b(game[-\\s]changer|gamechanging)\\b",
      "type": "regex",
      "flags": "i",
      "action": "hide"
    },
    {
      "pattern": "^(\\d+) (lessons?|things?|reasons?) I learned",
      "type": "regex",
      "flags": "i",
      "action": "hide"
    }
  ]
}

The case-sensitivity gotcha burned me for two days. In versions prior to the commit that merged the flags field (check your installed version in the manifest — look for "version": "0.4.x" or later), all patterns are matched case-sensitively and there is no UI toggle for it. That means humbled passes through if someone writes Humbled at the start of a sentence, which they always do. The fix is either duplicate every entry — humbled and Humbled — or upgrade and use "flags": "i". I'd just upgrade, but if you're pinned on a corporate-managed browser profile, the duplication approach works fine.

Promoted posts deserve their own rule bucket, separate from organic AI slop, because the action you want is different. With organic posts I hide them outright. With promoted posts I want to always hide them regardless of content — even a perfectly written ad is still an ad. The extension exposes a separate promoted boolean filter on the post metadata it reads from LinkedIn's DOM. Set it like this in your config:

{
  "promoted_posts": {
    "action": "hide",
    "override_allowlist": true
  }
}

The override_allowlist flag matters. Without it, if a promoted post happened to come from a connection on your allowlist (yes, your connections run ads), the allowlist wins and the post shows up. I don't want to see ads from people I know any more than ads from strangers, so I set it to true. One more thing: LinkedIn occasionally changes the class name or aria attribute they use to mark promoted content, and the extension's selector breaks silently. If you suddenly start seeing ads again, open DevTools on your LinkedIn feed, inspect a promoted post, and check whether the attribute data-promoted or the class feed-shared-update-v2--promoted is still present. The extension's GitHub issues tab usually has a fix within a few days of LinkedIn deploying a selector change.

Filling the Gaps with uBlock Origin Custom Filters

When the Dedicated Extension Hits Its Limit

LinkedIn Unfiltered handles the obvious AI slop well — it catches a lot of the "I'm humbled to announce" posts and removes engagement bait. But two things keep slipping through: sponsored posts embedded directly in the feed and the "People you may know" sidebar block that reappears no matter how many times you dismiss it. Sponsored content is especially annoying because it renders like organic content intentionally. No extension targeting AI patterns will catch a paid ad. That's where uBlock Origin earns its keep as a second layer.

Getting Into the Right uBlock Dashboard Tab

Click the uBlock Origin icon in your toolbar, then click the grid/dashboard icon in the bottom-right of the popup (not the power button — that toggles the extension). Once inside, go to the My Filters tab. This is where you type raw filter rules. No import needed, no file format to learn. Type a rule, click Apply changes, and it's live immediately. The tab persists your rules across browser restarts and syncs if you have Chrome/Firefox sync turned on.

The Actual Filter Rules That Work

Here's what I have running right now. These target the sidebar noise and the suggested/promoted feed injections:

! Hide "People you may know" sidebar widget
linkedin.com##.scaffold-layout__aside .artdeco-card:has(h2:contains("People you may know"))

! Hide "Pages you may want to follow"
linkedin.com##.scaffold-layout__aside .artdeco-card:has(h2:contains("Pages"))

! Hide "Followed Hashtags" module in sidebar
linkedin.com##.feed-follows-module

! Hide sponsored/promoted posts in feed
linkedin.com##.feed-shared-update-v2:has(.update-components-actor__sub-description: "contains(\"Promoted\"))"

! Hide "Suggested for you" injected feed cards
linkedin.com##[data-view-name="feed-suggested-update"]

! Nuke the entire right sidebar if you don't use it
linkedin.com##.scaffold-layout__aside

The :has() selector is the powerful one here — it lets you target a container based on text inside a child element, so even if LinkedIn shuffles their wrapper class names, the rule survives as long as the visible label text stays the same. The last rule is a nuclear option I use when I'm heads-down and don't want any distraction. Re-enabling it takes five seconds.

Finding New Spam Containers with the Element Picker

When something new appears that bothers me, my workflow is: right-click the offending element → uBlock Origin → Block element. The element picker opens and highlights the DOM node. I almost never use the generated selector directly — it's usually too specific (hashed class names, instance IDs). Instead I look at what it generated, then manually walk up the DOM in DevTools to find a stable parent with a meaningful class. Then I write the rule by hand and paste it into My Filters. The picker is mostly useful for telling me where in the DOM something lives, not for generating production-ready filters.

The Class Name Churn Problem

LinkedIn ships frontend changes constantly and they don't follow any deprecation schedule for CSS classes. A filter that worked last Tuesday can silently fail by next Thursday with zero indication — the element just reappears. The filters using :contains() on human-readable text survive longer because LinkedIn can't rebrand "Promoted" to something else without user-facing confusion. But purely class-based selectors like .feed-follows-module will eventually die. My habit is to do a five-minute filter audit every few weeks — just scroll LinkedIn for a couple minutes and see what's back. When something reappears, I open DevTools, inspect the new class, update the rule. Takes under two minutes once you have the workflow memorized.

Going Deeper with a Tampermonkey Userscript

Who Actually Needs This Level of Control

If the browser extensions covered earlier got your feed to a tolerable state, honestly stop here. Tampermonkey is the right tool when you need logic that no pre-built extension exposes — like custom heuristics, per-account rules, or pattern matching that goes beyond simple keyword lists. I went down this path because I wanted to filter on structure, not just vocabulary, and no existing tool gave me that. If your annoyance is mostly "posts with 'I'm humbled' or 'big deal'" you don't need a userscript. If you want to nuke single-sentence paragraph salads, keep reading.

Installing Tampermonkey

Chrome Web Store link: chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo. Firefox users: it's on addons.mozilla.org under the same name. After install, click the Tampermonkey icon → Dashboard → the plus icon to create a new script. One thing that trips people up on Chrome after MV3 enforcement: Tampermonkey v5+ handles this fine, but you need the paid beta channel or the stable 5.x release — older 4.x builds will silently fail on some pages. Check your version before you waste an hour debugging.

A Minimal Userscript Skeleton

This is the boilerplate I actually use. The @run-at document-idle matters — LinkedIn's feed is SPA-rendered and firing too early gets you nothing:

// ==UserScript==
// @name         LinkedIn AI Spam Filter
// @namespace    http://tampermonkey.net/
// @version      0.3
// @match        https://www.linkedin.com/feed/*
// @grant        none
// @run-at       document-idle
// ==/UserScript==

(function () {
  'use strict';

  // LinkedIn re-renders on scroll, so we observe the feed container
  const observer = new MutationObserver(() => filterPosts());
  const feed = document.querySelector('.scaffold-finite-scroll__content');
  if (feed) observer.observe(feed, { childList: true, subtree: true });

  function filterPosts() {
    document.querySelectorAll('.feed-shared-update-v2').forEach(post => {
      const text = post.querySelector('.feed-shared-text');
      if (!text) return;
      if (shouldHide(text.innerText)) {
        // Collapse rather than delete — less likely to break LinkedIn's JS
        post.style.display = 'none';
      }
    });
  }

  function shouldHide(text) {
    // plug your detection logic here
    return false;
  }
})();

The selector .feed-shared-update-v2 has survived LinkedIn's rebranding waves since roughly 2022, but LinkedIn does break selectors without warning. If things stop working, open DevTools and re-inspect the feed container — it's usually just a class rename.

Detecting Consecutive Single-Sentence Paragraphs

This is the most reliable structural tell I've found. Real human posts occasionally do this. AI posts do it every time, usually 5–8 consecutive one-liners with a blank line between each. The detection is surprisingly simple:

function shouldHide(text) {
  // Split on double newlines to get visual paragraph breaks
  const paragraphs = text.split(/\n{2,}/).map(p => p.trim()).filter(Boolean);

  let consecutiveSingleSentences = 0;
  let maxRun = 0;

  for (const para of paragraphs) {
    // Rough sentence count: ends with . ! ? and has no internal sentence-ending punctuation
    const sentences = para.split(/(?<=[.!?])\s+/);
    if (sentences.length === 1 && para.length > 20) {
      consecutiveSingleSentences++;
      maxRun = Math.max(maxRun, consecutiveSingleSentences);
    } else {
      consecutiveSingleSentences = 0;
    }
  }

  // 3 in a row is suspicious. 4+ is almost certainly AI-structured content.
  return maxRun >= 4;
}

I tuned the threshold to 4 after running it for a week with console logging — at 3 you start hiding legitimate bullet-point style posts from actual humans. At 4, the false positive rate dropped to nearly zero in my feed. You can tighten it further by also checking for the emoji-as-bullet-point pattern (/^\p{Emoji}/u on each paragraph), which appears in a huge fraction of AI posts but almost never in normal ones.

Community Scripts on Greasy Fork

Before writing everything yourself, check greasyfork.org/en/scripts?q=linkedin. The quality varies wildly — some scripts haven't been touched in two years and use selectors that stopped working — but a few are actively maintained. Search for "LinkedIn feed" and sort by "Updated" not "Installs". The install count is misleading because popular scripts that broke stay at the top. What I'd look for specifically: scripts with a GitHub link in the description (maintainer is reachable), update within the last 3 months, and a comment section where people are reporting selector fixes. Fork rather than install directly if you plan to customize — Greasy Fork updates can overwrite your changes.

Gotchas I Hit That Took Me Too Long to Debug

The infinite scroll issue caught me completely off guard. Posts load fine when you first open LinkedIn, the extension does its thing, and then you scroll down — and suddenly "thought leadership" content starts bleeding through again. What's happening is that LinkedIn's infinite scroll injects new DOM nodes asynchronously, and the MutationObserver in some extension builds only fires on the initial load, not on subsequent insertions. The fix depends on which version you're running, but the diagnostic is always the same: open DevTools, go to the Elements panel, scroll down until the spam reappears, and check whether newly loaded .feed-shared-update-v2 nodes are missing the data-filtered attribute the extension normally stamps on matched posts. If they're clean, the observer isn't catching them.

LinkedIn pushes frontend changes constantly, and at least twice since I started using the extension, it completely stopped working within 48 hours of what looked like a major LinkedIn UI sprint. The symptom is always the same: zero filtering, no console errors, extension popup shows "active." The root cause is usually that LinkedIn renamed a class or restructured the feed container that the extension uses as its root selector. Before you spend an hour debugging, check the repo's GitHub Issues tab first — someone else has almost certainly already filed it, and there's usually a hotfix branch or a config override you can paste in within a day or two. I set up a watch on the repo's releases just for this reason.

If you're running uBlock Origin alongside this extension (and I do), you'll eventually hit a case where a post vanishes and you can't tell who killed it. The way I sort this out:

1. Right-click the invisible post's container and hit Inspect.
2. Look for display: none or visibility: hidden in the computed styles. uBlock applies display: none !important via a stylesheet injection; the LinkedIn extension usually sets a class like .lnkd-filtered or toggles the element's style directly.
3. Temporarily disable uBlock on LinkedIn (uBlock popup → Power icon), reload, and see if the post comes back. If it does, uBlock owns that hide. If not, it's the extension.
4. Check the uBlock logger (Ctrl+Shift+J inside uBlock's dashboard) filtered to the current tab — it shows exactly which cosmetic filter matched the element.

The conflict usually happens on promoted posts. LinkedIn marks them with .feed-shared-update-v2--sponsored and both tools want to handle them. Letting uBlock own ad removal and the extension own AI-content filtering is the cleaner division — you can add a #!# exception in uBlock for the specific selector if they're fighting over the same node.

Manifest V3 on Chrome 120+ will give you a specific error when loading unpacked that looks deceptively fatal:

Uncaught TypeError: chrome.webRequest is not a function
    at background.js:14:18

MV3 killed webRequest blocking in unpacked extensions unless you're on an Enterprise policy that re-enables it. The workaround that actually works: open chrome://flags, search for Extension Manifest V2, and flip it to Enabled. That flag still exists as of Chrome 124 — it won't survive forever, but it buys time. Alternatively, check if the repo has a manifest_v3 branch; some maintainers ship a parallel version that replaces webRequest with declarativeNetRequest and a content-script-only filtering approach, which works fine under MV3 without any flags.

Your keyword filter list has a shelf life, and I've learned this the hard way. Terms like "learnings", "unpack", and "democratize" felt like reliable AI tells in early 2023 — now they're just how people write, AI-assisted or not. I review my filter list every three months and I've removed more entries than I've added in the last two rounds. A better signal than vocabulary is structural: AI-generated posts tend to follow a specific rhythm — a bold hook sentence, three to five bullet points each starting with an emoji, a closing "What do you think?" The extension supports regex in most builds, so I've moved toward patterns like /^(🔥|💡|✅).+\n/m combined with post length thresholds rather than specific words. Fewer false positives, more durable filtering.

What This Setup Actually Changed for My LinkedIn Usage

My LinkedIn feed used to be something I'd open and then immediately regret. Not because of anything dramatic — just that low-grade irritation of scrolling past eight AI-written reflections on "the power of showing up" before finding one post someone actually wrote from experience. After running the extension for about six weeks, I don't feel productive superpowers. I feel slightly less annoyed. That's the honest story.

The concrete change is the ratio shift. I scroll maybe 40% less before hitting something I care about, and when I do click through to a post, I'm more likely to actually read it rather than abandon halfway through. The extension doesn't transform LinkedIn into a curated knowledge base — it just nudges the signal-to-noise ratio enough that the app feels worth opening again. I went from checking it twice a week with dread to checking it every other day with mild curiosity. That's the ceiling of what a content filter can actually do.

The posts that still get through are the sneaky ones — hybrid content where someone clearly had an AI help polish a real experience they wrote, or short posts with no paragraph structure to pattern-match against. The extension's heuristics work well on the obvious stuff: those 10-line stacked paragraphs with a bullet list conclusion, posts that open with a rhetorical question and close with "What do you think? Drop it in the comments." But a three-sentence post that sounds vaguely inspirational? It'll slide right through. I've accepted this. Catching that stuff would require catching real posts too, and I'd rather have a few false negatives than start filtering out actual humans.

There's a real tradeoff I think about with specific people I follow. Someone I respect who does solid technical deep-dives also occasionally posts what is obviously AI-generated "thought leadership" filler between their good stuff. The filter catches those filler posts — which is exactly what I want — but there's a nonzero chance it also catches one of their real posts if they happened to format it the same way. I've started checking the filtered-post queue occasionally (most extensions surface this as a collapsed section or a badge count) just to rescue anything that looks like it got caught unfairly.

My actual recommendation on the unfollow question: if someone's entire output has shifted to AI-generated content and you're only keeping them because you followed them three years ago, just unfollow. The extension is for people who post valuable things sometimes but also post noise. Using it as a way to avoid unfollowing ten people who genuinely provide no value anymore is backwards. Unfollowing is free, permanent, and doesn't cost any CPU on every page load. I unfollowed about a dozen people alongside setting up the extension, and that combination was more effective than the extension alone would have been.

The thing that surprised me most was what the filter revealed about my own habits. When filler content got removed, I realized I was also clicking on certain people's posts mostly out of social obligation — we'd worked together, we'd exchanged comments before — not because the content itself warranted it. The filter has no concept of social obligation. It just blocks the pattern. That bluntness ended up being useful in ways I didn't expect.

Disclaimer: This article is for informational purposes only. The views and opinions expressed are those of the author(s) and do not necessarily reflect the official policy or position of Sonic Rocket or its affiliates. Always consult with a certified professional before making any financial or technical decisions based on this content.

Originally published on techdigestor.com. Follow for more developer-focused tooling reviews and productivity guides.