I don't need AI to build me a new app. I need it to make Jira bearable

Last week I asked Claude to build me a Jira sidebar that shows cross-project dependency graphs — the kind Jira buries across 4 clicks and 3 page loads. 4 prompts. Works inside my actual Jira. It just used Claude Chrome extension that injects a panel into the page I already have open.

And I keep thinking: why isn't everyone doing this?

The entire AI coding conversation is about building new apps from scratch. Cool. But I don't need a new app. Most people spend their workday inside apps they didn't choose: Jira, Salesforce, Workday, ServiceNow, etc. These tools are not going anywhere. My company chose them in 2019 and they're entrenched until at least 2029.

Chrome extensions just reads what's already in the DOM and augments it.

Is there a fundamental reason this can't work at scale that I'm not seeing? Why isn't Claude's Chrome extension catching more attention?

21 points | by niel_hu 3 days ago

7 comments

  • Nathanf22 11 hours ago
    The dependency graph point resonates. There's a broader pattern here: the tools we use daily were designed around human navigation — menus, pages, clicks. But dependency relationships are fundamentally graph problems, and graphs don't render well in hierarchical UIs. Jira buries cross-project dependencies across 4 clicks because it was built around projects as the primary unit, not relationships. The data is there. The mental model isn't. The Chrome extension approach is clever precisely because it doesn't fight the entrenched tool — it layers the missing mental model on top. Same data, different lens. I've been thinking about this problem from the codebase side: your source code has the same issue. The architecture of a system is a graph, but we navigate it through a file tree. The file tree is a terrible lens for understanding how things connect. It's why onboarding on a new codebase takes weeks even when the code is clean. The real unlock — in Jira, in codebases, anywhere — is switching from the hierarchical lens to the relational one. We're just starting to build tooling that makes that switch easy.
  • CodeBit26 3 days ago
    This resonates so much. We’ve spent years automating the 'coding' part, but the 'process' part is still stuck in a click-heavy 2010s workflow. I don't want an AI that writes boilerplate; I want an AI that observes my Git commits and Slack discussions, then automatically updates the ticket status, linked PRs, and documentation. The real productivity killer in 2026 isn't the lack of code assistants, it's the 'administrative tax' of keeping project management tools in sync with reality
    [-]
    • KurSix 2 days ago
      Dumping a continuous firehose of Slack messages into an LLM context is a guaranteed way to bankrupt the company. Plus, the latency is a joke: by the time the agent parses the thread and hits the Jira API, you could've manually dragged the tickets across the board three times over yourself
      [-]
      • AnimalMuppet 2 days ago
        I don't need lower latency. I need to not have to do it myself.

        For that to work, though, I also need to not have to check it myself. The tool has to be reliable.

    • satvikpendem 1 day ago
      This is literally an LLM comment, the structure is the same.
      [-]
      • CodeBit26 23 hours ago
        Fair point on the structure, I've been using tools to help polish my English lately since it's not my first language. But the point about the 'administrative tax' in Jira/Slack is coming from my own daily frustration, not a prompt. I'd rather have an agent that actually syncs my PRs than another code assistant
  • PaulHoule 3 days ago
    It's definitely part of the SaaS-apocalypse story. LLMs shine at making little programs that integrate with an existing API to do some small task. Management has always overestimated the effort to develop that kind of thing and underestiamted the effort to develop applications with GUIs because... user interfaces are the Vietnam of computer science.

    The greatest danger of the current time is that the likes of Salesforce and LinkedIn who have something interesting behind an API or web site try to lock down access so instead of using competitive high-quality AI agents we're stuck with the brain damaged AI agents they want to force on us.

    [-]
    • niel_hu 3 days ago
      Yeah, totally agree. But I don't think they can keep it locked down any more, with the rise of computer use agents, the boundary between interfaces designed for humans and those designed for computers is becoming increasingly blurred.
      [-]
      • KurSix 2 days ago
        Cloudflare and Datadog are already training models to detect agent-like mouse movements and DOM interactions. They'll lock this down easily, and we'll just end up in an ML vs ML arms race. It's still way too easy to fingerprint a script vs a real human just by looking at input latency patterns tbh
      • PaulHoule 3 days ago
        Last year I was talking with somebody about business plans and we were talking about using browser extensions for social news applications to get around paywalls, another part of the "lockdown economy".

        I have an "image sorter" that ingests image galleries, it used to use a bookmarklet that cued a webcrawler but after a decade of having my time as a user wasted clicking on those Cloudflare thingies I finally had it get in the way of my webcrawler.

        I was talking about options w/ Junie and it suggested, "why not write a browser extension?" and I'm like "is that hard?" and it says "no" and 20 minutes later I have a prototype browser extension.

        So that plug-in you're talking about where an AI can see directly into your browser is another option, another is vibe-coding a custom browser extension. I think it was always pretty easy to write a browser extension but I had I done it myself my usual scholarly way I'd spend a few hours reading documentation before I started coding and never realized just how simple it is... Just the way people are discovering web crawlers and API integrations are easier than they thought.

        [-]
        • OkayPhysicist 3 days ago
          There really isn't hours worth of material to put together a browser extension. You can read all the relevant docs in tops an hour, but you can follow the MDN tutorial on it to get the "inject some Javascript into pages with a url matching this pattern" level in less than 10 minutes.
          [-]
          • KurSix 2 days ago
            Yeah, logging "Hello World" from a content script takes 10 minutes. But then you run into Manifest V3 service worker lifecycles, bypassing CSP on the host page, and syncing state across tabs, and suddenly your "quick one-hour project" turns into a completely burned weekend
          • skydhash 3 days ago
            Also most extensions are open sources. You can hack something from just glancing at the code of some samples.
  • KurSix 2 days ago
    Just because Claude hacked together a panel on top of Jira doesn't make it a scalable pattern. Most of these on-the-fly generated UIs are slow as hell, hijack native page events, and leak memory like crazy. It's fine for a personal PoC, but rolling this out to an entire team is pure insanity
    [-]
    • xp84 2 days ago
      As though Jira itself is a model of well-architected and performant frontend!
  • pants2 2 days ago
    I vibe-coded my own Jira interface at work. Everyone likes it better and half the company is using it now lol.
    [-]
    • niel_hu 2 days ago
      Curious about your approach. How did you implemented it ? how did it talk to Jira backend ?
  • andrei_says_ 3 days ago
    Did you create a new extension or a custom script for an existing one?
    [-]
    • niel_hu 3 days ago
      Neither. I asked claude through extension to modify the page directly
  • verdverm 3 days ago
    Rovo is sad you never pick it for these kinds of things
    [-]
    • niel_hu 3 days ago
      Rovo from atlassian? no thanks.