CodeCraftr

CodeCraftr turns plain-language app ideas into deployable Jira Forge projects with AWS Nova, versioned prompts, and auditable Lambda delivery for fast, controlled code generation.

Comment

Inspiration

We were inspired by a simple frustration: prompt-based code generation often looks impressive in a demo, but breaks down when you try to use it for a real project. In the Atlassian ecosystem, that problem is even sharper because Forge apps have strict platform rules, packaging constraints, and deployment expectations.

We wanted to build something more practical than “generate a whole app and hope for the best.” CodeCraftr started from the idea that code generation should be structured, testable, and release-ready, especially for Jira Forge apps.

We were also excited by the opportunity to build on Amazon Nova foundation models and see whether a constrained, production-oriented generation pipeline could produce better results than a generic single-prompt approach.

What it does

CodeCraftr turns a plain-language prompt into a generated Jira Forge app project that the user can download as a ZIP artifact.

In the current version, a user:

  • opens the app in Jira
  • enters a prompt
  • selects the Forge App stack
  • submits generation
  • waits for async processing to finish
  • downloads the generated project artifact

At the core of this workflow, CodeCraftr leverages Amazon Nova foundation models through Amazon Bedrock. The current runtime uses Amazon Nova 2 Lite to plan the app structure, generate the required files, and assemble a downloadable Forge project artifact.

How we built it

We built CodeCraftr as a combination of a Jira Forge frontend, Forge backend orchestration, and an AWS-based code-generation runtime.

The main pieces are:

  • a Jira Forge UI for prompt submission and status tracking
  • Forge resolvers and async queue consumers for orchestration
  • Forge Realtime API for user-facing progress and completion updates
  • an AWS Lambda generation API invoked with AWS_IAM
  • Amazon Bedrock as the model access layer
  • Amazon Nova foundation models as the core generation engine
  • S3-based artifact delivery for downloadable ZIP outputs

Challenges we ran into

The biggest challenge was reliability.

We had to solve:

  • async orchestration between Forge, Lambda, and the browser
  • realtime delivery races where fast jobs could finish before the UI subscribed
  • AWS IAM signing for external generation requests
  • sandbox restrictions inside Forge iframes
  • keeping sensitive prompt and Jira content out of long-term storage
  • making generated output usable inside Jira, not just technically possible

Using Nova foundation models for code generation also introduced a second class of challenges:

  • making model output consistent enough for automation
  • handling malformed structured responses
  • reducing “creative” but invalid output
  • keeping generation quality high while staying within model and runtime constraints

A major engineering challenge was learning where to constrain Amazon Nova 2 Lite and where to improve our runtime. Some failures were prompt problems. Others were contract and orchestration problems.

Accomplishments that we're proud of

We’re proud that CodeCraftr is not just a mockup.

We built:

  • a working end-to-end generation flow from Jira UI to downloadable artifact
  • a code generation pipeline powered by Amazon Nova foundation models
  • realtime async feedback inside Forge
  • a constrained generation architecture instead of a one-shot prompt demo
  • a safer flow that avoids persisting sensitive prompt data unnecessarily
  • a demoable user experience that feels integrated into Jira

We’re also proud that we made Amazon Nova models work in a disciplined way. Rather than using it as a black box, we built a system around it that improves output quality.

What we learned

We learned that useful code generation is much more about constraints than raw model power.

The biggest lessons were:

  • structured generation beats free-form generation
  • async UX matters as much as model quality
  • prompt fixes and runtime fixes should be treated as different categories
  • realtime systems need explicit handling for missed or fast-completing events
  • shipping inside a platform like Forge means respecting platform behavior early, not patching it later

What's next for CodeCraftr

Next, we want to expand CodeCraftr beyond the current demo flow and make it a stronger product for real teams.

Our near-term roadmap is:

  • support richer project types beyond the current Forge App path
  • make generated outputs easier to inspect before download
  • continue improving prompt packs and release versioning around Amazon Nova
  • strengthen packaging, promotion, and runtime controls for production use

Longer term, we want CodeCraftr to become a reliable system for structured app generation powered by Amazon Nova foundation models, not just for demos, but for repeatable developer workflows.

Built With

Share this project:

Updates