Cursor, Windsurf, Kiro, Aider: those are the names that come up most often when people talk about AI-powered IDEs and AI agents. But there's one we don't hear much about: Junie from JetBrains.

I've always developed with PhpStorm, that's where my habits live. Over the years, I've customized it into the IDE I know inside out, the one I can drive with my eyes closed.

When the first AI agents showed up, let's be honest: JetBrains took forever to get on board and even fell considerably behind. The AI Assistant launch was pretty underwhelming. Beyond autocomplete, the built-in chat tool was fairly limited: no code generation, slow, no model choice; its only real strength was how well it sat inside the environment.

Since then, the tool has improved. They shipped their first real AI agent, Junie (9 months after everyone else), and it's gotten a lot better since (faster, model choice, IDE integration still top-notch, MCP support, and so on).

Today I want to show you how I use Junie day to day, how I've set it up, and a few tips to get the most out of it. I'm not claiming this is the best way, but it's the one I use and, for now, it works really well for me (and it keeps evolving as I work with it).

Installation

Before we start, know that Junie gives you "free" 3 credits per month for prompts, which is enough for a few prompts with cheap LLMs like Gemini 3 Flash; you can't even get one done with Opus, for example. So I'd recommend picking at least the Pro plan (10 credits) with a cheap LLM to try it out. You can also buy extra credits (1 credit = €1 excl. VAT, valid for 1 year) if you go over your monthly quota.

Start by grabbing the plugin from the marketplace. Two new icons will show up on the right and in the top-right of your window.

The icon on the right opens the Junie panel; the one at the top gives you info about your remaining quota, access to settings, and so on.

Settings

Several options can be configured from Junie's Settings:

• Action Allowlist to define which commands Junie can run without asking for confirmation
• Mcp Settings to configure the MCPs Junie can access. Note that from this window you add MCPs for all projects. If you want project-specific MCPs, add their config in .junie/mcp.

{
  "mcpServers":
  {
    "nuxt-ui" : {
      "command": "npx",
      "args": ["mcp-remote", "https://ui.nuxt.com/mcp"]
    },
    "nuxt": {
      "command": "npx",
      "args": ["mcp-remote", "https://mcp.nuxt.com/sse"]
    },
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp", "--api-key", "YOUR_API_KEY"]
    }
  }
}

• Models to choose which model to use
• Project Settings to set the project path and the path to your guidelines or rules folder

Guidelines and Skills: steering Junie

Like Cursor with its cursor rules, Junie has its own guidelines system for defining your development rules.

Everything lives in your .junie directory.

Guidelines

By default, Junie looks at .junie/guidelines.md, which you need to create at the root of your project. That file will hold all of your project-specific rules: architecture, best practices for the languages and frameworks you use, and so on.

Since that can quickly turn into a mess if you dump everything into a single file, Junie recently added support for a rules directory instead of a single file (yes, Cursor has been doing that for a while). In Junie's settings, rather than pointing guidelines at guidelines.md, point them at .junie/rules. You can then drop your different rule files in there.

project-root/
|-- .junie/
    |--rules/
      |--typescript.md
      |--nuxt.md
      |--zod.md

These rule files are loaded and read by Junie on every new prompt window (so on the first prompt only). If you edit these rules, you'll need to open a new prompt window.

Skills

While I was writing this article, Junie shipped an update that adds support for Agents Skills.

Simply put, a skill tells Junie how to carry out specific tasks, like generating a PDF for example. I'll let you check the official docs for more detail, but it's a nice extra to keep Junie from just doing whatever she wants.

Skills can be placed in .junie/skills.

project-root/
|-- .junie/
    |--rules/
        |--typescript.md
        |--nuxt.md
        |--zod.md
    |--skills
        |--my-super-skill
            |--SKILL.md # required, contains the instructions
            |--scripts/ # optional, executable code
            |--references/ # optional, documentation
            |--assets/ # optional, contains templates, resources, etc....

An example of a skill could be a doctrine-migration that would tell Junie how to run a Doctrine migration.

Prompt window

Open your Junie panel.

On the left you have your prompt window, on the right the list of recently run prompts and a few example prompts suggested by JetBrains.

From the prompt window, several options:

• + gives you access to several options:
  • Attach an image to your prompt
  • Access the guidelines (we'll come back to that later)
  • Create a .aiignore (same idea as .gitignore, lets you exclude files/folders from your agent)
  • Attach a recently opened file to your prompt window
• Next to the +, you have 3 choices (Auto by default) to tell Junie what you want her to do:
  • Auto lets Junie decide whether she should just answer you, write code, or both
  • Code: Junie must produce code
  • Ask: Junie will reply in a .md
• Then you have Brave Mode to allow Junie (or not) to run commands without asking for confirmation (be careful with that one)
• And finally, Think More to give Junie more time (or not) to process the request. For complex requests, it can improve the result, but it obviously burns more credits.

Let's prompt

Now that your Junie is set up, we can get going.

Structuring your prompt

We've known this for a while, but a prompt needs to be as precise as possible about the feature you want built or what you want your agent to do. Forget the implement feature X for me prompts that leave the agent way too much freedom. The point isn't to copy the contents of the rules either, but to steer the AI as much as possible. For that, I split my prompts into several parts:

• Objective: we define the overall goal of the prompt
• Rules: we define the rules the feature must follow
• Steps: the steps our agent should follow
• Examples: we can also add examples to help Junie even more.

Take this prompt as an example:

# Objective
Be able to create income types

# Rules
* The entity is called "income type".
* The entity has the folowing parameters
  * id --> auto generated UUID
  * name --> string, length 255, mandatory
  * user --> The user who created the income type. It's a Uer object.
* A User can be associated with multiple income types, but an income type is linked to only one User.
* This entity must be exposed as an API resource with GET, GET collection, POST, PUT, and DELETE operations.
* It must be secured: only the User associated with the income type can PUT, GET (both collection and single), and DELETE it (based on JWT).

# Steps
* Create the IncomeType entity
* Run `make migration`
* DO NOT run `make exec-migration`

Feel free to format your prompt in a scratch file, for example.

When your prompt is ready, run it, and Junie will start working a bit.

Before producing your code, Junie will put together a plan based on your prompt. Example:

After that, Junie will produce the needed code, and after a more or less long wait:

Reviewing the result

Nice, you've got your little done showing up, plus a short recap and the files that were modified/added/deleted. Clicking one of them lets you see the additions right away via a git diff. At this point, you should always review what Junie produced. If really nothing works for you, you can still roll back from the result in Junie.

One caveat though: you can't roll back only part of the produced code; at best you can roll back a specific file. Likewise, if you run a new prompt in the same window, you won't be able to roll back the previous prompt unless you roll back the later ones first.

While reviewing, avoid asking Junie for too many fixes, especially minor ones: you'll burn credits for nothing, bloat the context, and risk falling into an infinite loop where the AI gets lost (and you along with it).

If the result looks good, you can commit it and move on to the next one! Also try to keep one window per feature so contexts stay clear and light.

My take

I've walked you through a bit of my workflow with Junie, how to set it up, and how it works in broad strokes. I'm not really sure how to give my opinion so let's do a classic pros/cons.

• The +
  • Perfect IDE integration that gives it direct access to the whole project
  • Finally a wide choice of models
  • The fact that Junie shows its plan before running
  • Fairly clear quota tracking
• The -
  • A bit slow
  • The interesting features that land months after the competition (even if things have been speeding up)
  • History disappears on every update
  • A preview of how many credits a run used at the end would be nice
  • Expensive (Ultimate at €36/month is mandatory, Pro at €10 is way too limited in terms of usage)

A few resources

I hope I've given you a clear picture of how to get the most out of Junie. I've been using it regularly for almost a year, and even if it isn't perfect, it keeps evolving and it gets the job done.