Should You Code Your Forge App or Let AI Generate It? A Trade‑Off Guide for Jira Teams

[#1]

If you want improvements for your Jira, as custom apps, issue panels, checklists, dashboards, or widgets, there are now two main ways to get a Forge app:

• write code with Forge UI Kit (or Custom UI),

• or describe what you want and let an AI Apps Builder generate the Forge app for you.

Both options create secure, native Forge apps, but each requires different skills and time for your team.

How Forge apps work (in simple terms)

Behind the scenes, every Forge app follows the same basic pattern:

• Product UI in the browser: Jira shows your app inside a secure iframe on the issue view, project page, or dashboard area. The app’s UI is rendered using Forge’s render functions, and user clicks trigger events.

• UI layer: You can build the UI with Forge UI Kit (using server-driven components) or with Custom UI (your own frontend, usually with React). In both cases, the UI runs in an iframe and cannot directly call Jira APIs or external services outside Forge. Any app‑level Jira or external API access goes through the Forge backend (via forge/api), which enforces scopes, permissions, and admin control.

• Bridge to the backend: The app’s UI is rendered using Forge’s UI entry points, and user interactions inside the iframe are handled by your UI code, which typically calls backend functions through the bridge.

• Forge Runtime as the app’s brain: Resolver functions handle UI requests, call Jira using requestJira(), use Forge Storage or SQL, and connect to external APIs through Atlassian’s API gateway with the scoped permissions.

• Security and permissions: All Jira and API access goes through forge/api and the Atlassian API Gateway, which enforces app scopes, user access, and audit trails.

In practice, a simple interaction works like this:
A user clicks a button in an issue panel, the UI calls invoke("doSomething"), the resolver runs the business logic and calls requestJira(), the result is stored or returned, and the UI updates with the new data.

No matter if you code the app yourself or use an AI Apps Builder, your Forge app still runs within this same architecture.

Coding with Forge UI Kit – you get control, but also take on the complexity

What it really means to code a Forge app

Building a Forge app with UI Kit is less about creating a fancy frontend and more about writing clear logic:

• You focus on flows, like: “When the user clicks this, call the backend, fetch Jira data, save something, and update the UI.”

• You write JavaScript for resolvers, triggers, and state, and also create a manifest.yml file that connects modules, resources, and permissions.

• With UI Kit, you describe the UI using Atlassian components instead of raw HTML/CSS, and any action that needs Jira, storage, or external data calls the backend via invoke().

Learning curve and time to value

In practice, becoming productive with Forge is less about “install the CLI and go” and more about building up a mix of JavaScript skills and platform intuition.

For most people who already know at least basic JavaScript, the first stage looks like this:

After 3–6 months of steady practice (around 5–10 hours a week), you can usually:

• Understand Forge examples.

• Modify templates.

• Build and ship simple apps (for example, an issue panel that reads some Jira fields and stores a small configuration).

Over 1–2 years of regular use, you typically reach the point where you can:

• Choose a reasonable architecture without guessing all the time.

• Handle edge cases and permission issues.

• Maintain apps over multiple releases without feeling like you’re starting from scratch on every change.

The time to build a single app still varies a lot depending on experience and scope, but these are realistic ballparks once you know the basics of Forge:

Simple app (single panel, one or two Jira calls)
Example: an issue panel with one button, a requestJira() call, and a bit of storage. Roughly 1–3 days for someone who already understands Forge modules, scopes, and deployment.

“Real” app (multiple resolvers, Custom UI, events, or external APIs)
Example: a custom dashboard or issue panel with Custom UI, several resolvers, maybe a scheduled trigger, and a third‑party integration. Often 1–2 weeks to get to something stable enough for real users.

Complex, production‑grade app
Example: multiple screens, queues for background work, performance considerations, security review, and careful error handling. Typically measured in months and usually involves a small team, not a single developer.

And importantly, most of this time is not spent typing code. It goes into:

• Clarifying requirements and edge cases with stakeholders.

• Reading Forge and Jira REST documentation.

• Debugging permission issues and platform‑specific behavior.

• Iterating on UX to make the app feel natural within Jira.

UI Kit’s changes, deprecations, and migration challenges

Even in 2026, the history of Forge UI Kit still affects both legacy apps and new ones.

UI Kit 1 is gone, but its impact remains

UI Kit 1 has not been supported or functional since 28 Feb 2025. Any modules that still use it now render error messages instead of UI, which is why some older apps feel “partially broken” even though they are still installed.

For vendors and teams still cleaning up old apps, the key points are:

1. Migrating to the latest UI Kit required real refactoring, not just a version bump:

• Components like Avatar and AvatarStack were removed in favour of User and UserGroup.

• Props changed on Badge and Button (e.g., disabled → isDisabled, text moved into children).

• The manifest had to be updated to use resources + render: native instead of older function wiring.

2. If the migrated app needed new scopes, that forced a major version bump, and each customer admin had to manually approve the new permissions. In practice, this left some customers stuck on old, now‑broken versions because nobody clicked “Approve.”

This is less about the date and more about understanding why some legacy UI Kit 1 features broke and why migration took longer than expected.

What the UI Kit’s history means if you choose it today

If you are building or maintaining apps on the latest UI Kit now, the useful lessons are about stability and expectations:

• UI Kit is tightly linked to Atlassian’s design system. When Jira’s global UI changes, your app can change visually too, for example, when the Tag component shifted from solid-coloured labels to subtly outlined chips, making colour cues less obvious without you deploying a new version.

• Atlassian has used several incompatible UI stacks over time (AUI, Atlaskit, UI Kit 1, and the latest UI Kit). Because of this, many partners think carefully about long-term maintenance before investing heavily in UI Kit.

• The latest UI Kit is far more capable than the original: you get charts, richer comments, interactive elements like Pressable, and layout primitives (Stack, Inline, Box), plus options like Frame to integrate more flexible content. But those gains arrived together with breaking API changes that required code changes and testing.

So in 2026, this story is still relevant, but as context and trade‑offs:

• UI Kit gives you a fast, opinionated UI that stays visually aligned with Jira.

• In return, you accept a higher chance of future breakage when Atlassian evolves the design system or the UI Kit API, and you plan time for refactors and customer approval flows when scopes change.

AI Apps Builder – get Custom UI power with plain-language prompts

Now let’s look at the second option: using an AI Apps Builder that creates Forge apps with Custom UI from natural language prompts.

You start with your idea, not the technical details

Instead of thinking about modules, manifests, and components, you just describe what you want in Jira terms:

• “Generate a gadget that shows issues assigned to the current user with due dates in the next 7 days. Display issue key, summary, status, and due date. Sort by nearest due date. Use a simple list layout.”

• “Generate an issue panel that reads the issue due date and displays a live countdown timer. If overdue, show "SLA Breached".

You don’t have to decide which resolvers or scopes to add. You just share your idea for Jira, and the AI turns it into a Forge app.

What the AI agent does in AI Apps Builder

AI Apps Builder works like an internal developer who knows Forge:

• Picks Custom UI depending on the requested experience.

• Generates the frontend code, backend resolvers, and manifest.yml.

• Selects the scopes necessary for the described behavior.

• Validates the app and prepares it for deployment.

From Forge’s point of view, the result is a standard Forge app with JavaScript code, a manifest, resources, and scopes. For you, it feels like you just describe what you want, see a working app in Jira, and make changes if needed.

AI Apps Builder offers two ways to deploy:

Manual deployment:

• Download a ZIP file with the generated Forge project.

• Review scopes.

• Run the Forge installer.

• Provide your Jira Cloud site, email, and an API token, and confirm installation as a Jira admin.

Automatic deployment:

• Provide your Jira Cloud site, email, and an API token

• Review the scopes and confirm the installation as a Jira admin.

In both cases, your Forge app follows Atlassian’s standard security and governance rules.

Why this no-code approach is especially helpful

UI usually means working with React, bundlers, state management, styling, and strict security rules for the iframe. An AI Apps Builder handles all of that and uses Forge best practices for you:

• AI chooses good patterns for layouts and states, so you don’t have to learn React from scratch.

• AI makes sure all data access goes through the Forge backend and forge/api, respecting scopes and user permissions.

This means Jira admins, PMs, and team leads can:

• Quickly prototype internal tools like issue panels, project dashboards, checklists, and custom reports.

• Make changes by chatting with AI rather than editing the code.

• If needed, hand off successful apps to developers for optimization or expansion without losing the initial work.

How developers can still benefit from AI Apps Builder

Even for teams with lots of developers, an AI Apps Builder can speed things up:

• Use it to generate the app, including modules, the manifest, basic UI, and boilerplate resolvers.

• Let engineers focus on complex business logic, performance, and integrations, rather than on setup and wiring.

• Treat the AI-generated app as a starting point.

Because the output is standard Forge code, your team can keep its normal tooling, review processes, and security checks.

Watch a 3-minute demo of AI Apps Builder in action

Coding + UI Kit or AI Apps Builder: which one is right for you?

If you’re trying to choose between classic coding with UI Kit and using an AI Apps Builder, it can help to think about the kinds of questions Jira users might have.

Questions	Coding + UI Kit	AI Apps Builder (Custom UI + LLM)
How fast can I get a first working app?	After learning Forge basics and JavaScript; simple apps in days, larger ones in weeks.	Often within minutes: describe the issue panel, dashboard, or page you want, and let the agent generate a deployable Forge app.
Do I need to code?	Yes. You must understand JS, Forge modules, manifests, scopes, and how to manage UI Kit migrations.	Not for initial versions. You work in prompts; you can still download and edit the generated code.
How stable is the UI over time?	Tightly tied to Atlassian’s design updates. UI Kit components can change appearance or APIs (e.g., Tag, Avatar, Button), requiring refactors and major app updates.	Uses Custom UI, giving more control over layout and styling. Still subject to Forge changes, but less exposed to UI Kit‑specific breaking visual changes.
Who is this best for?	Teams with developer capacity who want maximum control and are comfortable maintaining code and handling platform migrations.	Power Jira users and teams with limited dev time who want to ship internal Jira tools quickly.
How does it behave in Jira?	As a standard Forge app using UI Kit, running in an iframe with resolver‑based backend logic, scopes, and auditability.	As a standard Forge app generated by the AI: Custom UI frontend, resolvers, scopes, all within Atlassian’s Forge model.

Which option is right for you?

Go with Code + UI Kit if:

• You have developers available, or you’re handling development yourself.

• You want full control over how your app works and runs.

• You plan to keep improving your app and want to use your usual code repository and tools.

Pick AI Apps Builder if:

• You need a working solution quickly, from prototype to usable app.

• You’re a Jira user who doesn’t have time to learn Forge or a developer who wants to save time.

• You want to generate and deploy your app easily, and also have the option to give the code to developers

If your main challenge is limited time, Forge’s complexity, or not enough developer resources, AI Apps Builder lets you build apps by having a simple conversation.