From Frustration to Flow: Building an AI Copilot for Jira with Forge

[#1]

A developer's journey through KVS hacks, Custom UI revelations, and the quest for cleaner tickets

The Wall of Words Problem

Picture this: You're reviewing a Jira ticket that starts with "so basically the thing is broken and we need to fix it ASAP!!!" followed by three paragraphs of stream-of-consciousness debugging notes. Or maybe you're internally screaming "Turns out if you don't test stuff, it breaks. Wild." — but you need to write something constructive for your teammates instead of venting your frustration in the comments.

We've all been there. The reality is that most Jira tickets fall into two categories: sparse one-liners that leave everyone guessing, or overwhelming walls of text from rigid templates that nobody actually reads. As a team of developers who've lived in the Atlassian ecosystem for years, we felt this pain daily.

That's when we asked ourselves: What if teams could write however they want — brain dumps, emotional rants, rough notes — and AI could transform it into clear, professional communication that actually gets work done?

Why We Bet on Forge

When we decided to build our AI Copilot for Jira, we had options. We could have gone external, or tried something entirely different. But Forge felt like the future of Atlassian development, and honestly, we wanted to be part of that future.

The appeal was immediate:

• Zero infrastructure headaches: No Kubernetes clusters to manage, no servers to provision. Just forge deploy and go.
• Native Jira integration: Our widgets live right where users need them — on the issue page.
• Built-in environments: Each developer gets their own playground. No more "it works on my machine" debates.

The development experience blew us away. Forge tunnel for hot reloading? Check. Automatic environment provisioning? Check. The ability to focus on building features instead of managing infrastructure? Priceless.

The Custom UI Revolution

Our journey started with Forge UI, and we fought hard to make it work. First, one component didn't quite fit our needs. Then another. Before we knew it, we were rewriting everything.

The turning point came when we switched to Custom UI. Suddenly, our AI-powered code generation tools could actually help us build. We could use Storybook for component development. Modern React patterns just worked. What had been a struggle became a sprint.

This wasn't just about developer convenience — it fundamentally changed what we could deliver to users. Complex interactions, smooth animations, and a genuinely delightful UX became possible. The development velocity increase was so dramatic that it became our "aha!" moment — when we made the switch, everything just clicked and development flew forward.

Adventures in KVS Land

Here's where things get interesting (read: hacky). Forge's Key-Value Storage is powerful, but we quickly discovered it lacks built-in indexing. Our solution? Build our own index system.

We learned to avoid Custom Entity Storage after discovering that schema management can become a real headache. Once you add an entity schema to your manifest and deploy it, removing it later becomes surprisingly difficult — it tends to clutter your manifest indefinitely. Instead, we use simple entities with our own indexing layer on top.

We created separate index entities that update whenever main entities change, with a failsafe that rebuilds the entire index every three hours — just in case something breaks. Is it elegant? Not particularly. Does it work? Absolutely.

The real pain point is the lack of atomic operations. We desperately need things like atomic increment-and-get operations. Without them, we're building elaborate workarounds for what should be simple operations. We're eagerly awaiting the GA release of Forge's cache with TTL and atomic operations — it can't come soon enough.

Concurrency, Queues, and the Dream of Real-Time

Managing concurrency in a serverless environment is... interesting. When two users open the same issue simultaneously, our analysis function runs twice. Without proper locking, this leads to duplicate work and wasted compute.

We've experimented with two locking approaches:

1. Backend locks using issue properties
2. Lock management through queues

Both add latency and hurt the user experience, but they're necessary evils for now. This is just one of our concurrency challenges — we also use Forge Queues creatively for other problems, like managing AI usage limits across customer instances to ensure fair usage and prevent any single customer from overwhelming our system.

What we really need is Forge Realtime. The ability to listen to Jira events, process them on the backend, and push updates to the frontend would transform our architecture. We're not just waiting for it — we're already dreaming up all the ways we'll refactor once it arrives.

Building Intelligence, One Playbook at a Time

Our AI Copilot does more than just fix grammar. It understands context, tone, and team standards. Here's what we love most about what we've built:

• Brain dump → Clear ticket: Turn scattered thoughts into structured issues
• Emotional → Professional: Transform "This is completely broken and I'm losing my mind" into "I've identified a critical issue that requires immediate attention"
• Comment summarization: Update descriptions with all decisions made in comments
• Team playbooks: Different rules for different projects — support tickets get one tone, internal dev tickets another

The moment we knew we were onto something? When we discovered our copilot excels at "corporate translation." You can write your genuine frustration, and it transforms it into constructive feedback. It's therapeutic and practical.

The Power of Community

Building on Forge means you're never alone. The Atlassian developer community has been invaluable. When you're deep in the weeds wondering if that weird behavior is a platform bug or your code, finding an open ticket with other vendors experiencing the same issue is incredibly reassuring.

Bug reports with workarounds have saved us countless hours. Seeing how other teams solve similar problems helps us avoid reinventing the wheel. It's like having a distributed team of colleagues who've already been where you're going.

Our Forge Wishlist

We love Forge, but we're developers — we always want more:

1. Forge Realtime: This would solve so many architectural challenges
2. Atomic KVS operations: Please, just give us increment-and-get
3. Production-ready cache: With proper TTL and atomic operations
4. Faster iframe loading: It's the one thing we can't optimize on our end

We understand Forge is evolving rapidly, and we're here for the journey. Each new feature unlocks possibilities we hadn't imagined.

Why This Journey Was Worth It

Looking back, choosing Forge was the right call. Yes, we've had to build creative workarounds. Yes, we're eagerly waiting for certain features. But Forge let us ship a real product that solves real problems for real teams.

We didn't have to manage servers, worry about scaling, or build our own plugin system. We could focus on what matters: helping teams communicate better in Jira.

Every hack, every workaround, every late-night debugging session was worth it when we see teams transform their chaotic tickets into clear action items, or watch a frustrated developer turn their rant into constructive feedback with one click.

"We're not here to build dashboards or static templates — we want to help teams communicate better inside Jira. Forge made it feel possible."

---

The authors are the team behind AI Copilot for Jira (https://marketplace.atlassian.com/apps/1238320), available on the Atlassian Marketplace. When they're not building custom KVS indexes or dreaming about Forge Realtime, they're probably turning their own frustrated commit messages into something their future selves will actually understand.