Introduction
JetBrains, the famous company behind editors like IntelliJ IDEA or Android Studio, did not want to be left behind in the artificial intelligence race. Although it already tried with its own “Copilot” model which, in my opinion, was a failure, this time it surprises us with something new, something that may in time make Cursor, the semi-autonomous code editor, tremble.
And it is that JetBrains presents Junie, an agent to whom we can delegate tasks and, as our good friend Cursor already does, takes context from your project code and as a result edits or creates the classes you need.
In this post we will be seeing what Junie offers us, we will compare it under the same conditions with Cursor and try to reach the conclusion of whether it is worth it.
The problem of keeping up
That’s right, every week a new AI appears with more capabilities than the previous one. It is almost impossible to keep up with everything new that is coming out, this time we find Junie, which instead of being a different editor is a plugin that can be incorporated FOR THE MOMENT into the IntelliJ Idea, PyCharm and WebStorm IDEs.
What is Junie AI?
The grace of Junie is to forget about the “rudimentary” chats where the AI only has the context of what you talk to it. Here it learns from your entire project and helps you do the most repetitive tasks.
It not only reviews files, but is capable of executing commands, and therefore tests. That’s right, it runs tests for you and knows if they went well or badly and can fix them. The main idea presented to us is that the developer should stop dealing with repetitive tasks and focus on critical product decisions.
Main features
- Contextual learning: Learns from your entire project, not just chats
- Command execution: Can run tests and fix them if they fail
- Repetitive task automation: Allows the developer to focus on critical decisions
- Integration with existing IDEs: Does not require changing editors
Current status and access
At the moment, Junie can only be accessed with closed beta by signing up for the waiting list, but I was granted it a couple of weeks ago, so don’t worry, it’s not impossible.
👉 https://www.jetbrains.com/junie/
Technology behind Junie
In case you’re wondering, they use LLMs from OpenAI and Anthropic, come on, like everyone else. It’s nothing new, but what surprised me is that at no time does it let you choose which model you want it to use.

As you can see this is the interface and there is no selector. I understand that depending on the context it will use one model or another.

Additional features and limitations
Another thing it has just like Cursor are the Guidelines, a .md file that you can specify for each project to follow those instructions. I recommend the page cursor.directory which collects many instructions of this type, and in this post we will use it to compare it.
It also doesn’t seem to have an index project section, a functionality that Cursor has to be able to access project files much faster. This is a problem and it shows, you will see that JUNIE is going to be much slower for us.
Another thing to note is that according to its policies and what I have been seeing, it seems that there is no usage limit. Just as all editors of this style set limits even if you pay for premium, here it does not indicate it at any time. I imagine it will be capped in some way but nothing that can be seen at first glance.
Finally, another thing you should know is that you can only access the beta if you have the paid license. If you use the free version you won’t be able to. Maybe that’s why there is no request limit.
Comparison with Cursor
Let’s test it on equal terms with Cursor.
To test its capabilities, I am not only going to base myself on the usage experience I have had programming my own projects, but I did a basic test to compare it well with Cursor.
I downloaded a base artifact from Spring Initializer, put a couple of plugins like H2 and Lombok and some more, and duplicated the project to open it in each code editor.
The test prompt
The prompt I prepared was the following:
Create a Spring Boot project with Java 21 using Maven. The application must manage a simple store with the following requirements:
Entities:
• Product: with fields id, name, description, price, stock
• Customer: with fields id, name, email, address
• Order: with fields id, customer (ManyToOne relation), products (ManyToMany relation), totalAmount, orderDate
Database:
• Use embedded H2, configuration in application.properties
• Create tables automatically using JPA (ddl-auto=update)
Repositories:
• Use JpaRepository interfaces for each entity
REST Endpoints:
• Implement a full CRUD for Product and Customer
• For Order, implement:
• Create an order assigning existing products to a customer
• Get all orders of a customer by ID
• Consult the total of an order
Controllers:
• Use @RestController and @RequestMapping("/api/…") to organize endpoints
• Validate input with @Valid where applicable
• Return responses using ResponseEntity
Extras:
• Use Lombok to avoid boilerplate
• Configure access to H2 console
• Follow best practices (clear names, layer division: controller, service, repository)
• If possible, implement DTOs for Order input/output to not directly expose entities
Expected output: complete code ready to compile, including:
• pom.xml with necessary dependencies
• Entity classes
• Repository interfaces
• Service classes if applicable
• REST Controllers
• Configuration in application.properties
Custom instructions
And apart from that, both in Cursor with custom rules and in Junie with its guidelines (which are basically the same) I have indicated this here so that they take it into account:
You are an expert in Java programming, Spring Boot, Spring Framework, Maven, JUnit, and related Java technologies.
Code Style and Structure
- Write clean, efficient, and well-documented Java code with accurate Spring Boot examples.
- Use Spring Boot best practices and conventions throughout your code.
- Implement RESTful API design patterns when creating web services.
- Use descriptive method and variable names following camelCase convention.
- Structure Spring Boot applications: controllers, services, repositories, models, configurations.
Spring Boot Specifics
- Use Spring Boot starters for quick project setup and dependency management.
- Implement proper use of annotations (e.g., @SpringBootApplication, @RestController, @Service).
- Utilize Spring Boot's auto-configuration features effectively.
- Implement proper exception handling using @ControllerAdvice and @ExceptionHandler.
Naming Conventions
- Use PascalCase for class names (e.g., UserController, OrderService).
- Use camelCase for method and variable names (e.g., findUserById, isOrderValid).
- Use ALL_CAPS for constants (e.g., MAX_RETRY_ATTEMPTS, DEFAULT_PAGE_SIZE).
Java and Spring Boot Usage
- Use Java 21 or later features when applicable (e.g., records, sealed classes, pattern matching).
- Leverage Spring Boot 3.x features and best practices.
- Use Spring Data JPA for database operations when applicable.
- Implement proper validation using Bean Validation (e.g., @Valid, custom validators).
Configuration and Properties
- Use application.properties or application.yml for configuration.
- Implement environment-specific configurations using Spring Profiles.
- Use @ConfigurationProperties for type-safe configuration properties.
Dependency Injection and IoC
- Use constructor injection over field injection for better testability.
- Leverage Spring's IoC container for managing bean lifecycles.
Testing
- Write unit tests using JUnit 5 and Spring Boot Test.
- Use MockMvc for testing web layers.
- Implement integration tests using @SpringBootTest.
- Use @DataJpaTest for repository layer tests.
Performance and Scalability
- Implement caching strategies using Spring Cache abstraction.
- Use async processing with @Async for non-blocking operations.
- Implement proper database indexing and query optimization.
Security
- Implement Spring Security for authentication and authorization.
- Use proper password encoding (e.g., BCrypt).
- Implement CORS configuration when necessary.
Logging and Monitoring
- Use SLF4J with Logback for logging.
- Implement proper log levels (ERROR, WARN, INFO, DEBUG).
- Use Spring Boot Actuator for application monitoring and metrics.
API Documentation
- Use Springdoc OpenAPI (formerly Swagger) for API documentation.
Data Access and ORM
- Use Spring Data JPA for database operations.
- Implement proper entity relationships and cascading.
- Use database migrations with tools like Flyway or Liquibase.
Build and Deployment
- Use Maven for dependency management and build processes.
- Implement proper profiles for different environments (dev, test, prod).
- Use Docker for containerization if applicable.
Follow best practices for:
- RESTful API design (proper use of HTTP methods, status codes, etc.).
- Microservices architecture (if applicable).
- Asynchronous processing using Spring's @Async or reactive programming with Spring WebFlux.
Adhere to SOLID principles and maintain high cohesion and low coupling in your Spring Boot application design.
The execution process
The moment of truth arrives, I execute both IDEs and let them process. In Cursor, to not make unfair competition, I have activated the automatic LLM option, since after all JUNIE also does it automatically and does not let you choose. I could have chosen Claude 3.7 Sonnet MAX Thinking but, apart from costing me an arm and a leg, it wouldn’t be fair.
After a while waiting, to be honest, Cursor finishes much sooner. Junie generally struggles more to perform operations.
Test results
I execute both codes and both compile and run without problems, that’s a good sign.
Junie AI
-
Advantages:
- Cleaner and more structured code
- Implementation of DTOs
- Error handlers included
- Basic CSRF configuration
- More efficient and contextual tests
-
Disadvantages:
- Longer response time
- No model selector
- No project indexing
I start reviewing Junie’s code and generally it has made good code. Obviously it has a very very basic architecture, and remember it is a super simple prompt, but I don’t dislike the structure and it has created DTOs, ErrorHandlers and even a basic CSRF config. Not bad at all for being in beta.



Cursor
-
Advantages:
- Faster response
- Model selector available
- Better project indexing
-
Disadvantages:
- Folder structure in Spanish (inconsistent)
- Lack of error handlers
- Direct use of entities in controllers (without DTOs)
Reviewing Cursor’s code, I see that it has made part of the folder structure in Spanish. Curious, it is true that the prompt was in Spanish, but come on, here I see a red flag. Then I get more surprises: I don’t find any error handler and, wow, what is this? Cursor’s buddy is using in the controllers not only the same input and output object, but we enter the object and it is not even a DTO, it is directly the entity.
Truth be told, a surprise for the worse, I didn’t expect this botch, something that Junie has not failed and thank god.



As a last note in favor of Junie, I must tell you that I have been testing it to make tests for me and increase coverage and it is much more efficient than Copilot or similar, since having context of the whole project it knows exactly how to mock objects and can execute tests. Something I realized it also does if you ask it to edit existing code that already has tests: it edits it and runs its tests, which if they fail it fixes them for you. Something very curious.
Comparison table
| Feature | JUNIE | CURSOR |
|---|---|---|
| Price | JetBrains License (169€/year) | 177€/year approx |
| Limit | Unlimited | 500 premium request |
| Custom instructions | Yes | Yes |
| Custom models | No | Yes |
| Choice of LLM | No | Yes |
| Available models | OpenAI, Anthropic | OpenAI, Anthropic |
| Speed | Medium | Fast |
| Autocomplete | No | Yes |
| Autonomous agent | Yes | Yes |
| Accept/discard changes | Yes | Yes |
| Accept/discard by file | No | Yes |
| Changes comparison | Yes | Yes |
| Integrated chat | No | Yes |
Conclusion
Ultimately and putting all the data on the table, Junie is worth trying, but if you don’t have an IntelliJ license then it’s not worth buying just for this. I see that it is a quite useful tool in more robust applications than Cursor (which works better for lightweight applications with frameworks like Next.js), but I don’t think it’s the panacea either.
You have to be very careful with these tools, since even if you specify a lot, I have found that it does things in the code in a suboptimal and recommended way. Also, not to mention the danger of developers constantly depending on LLMs, although that is a separate topic that I will cover in another post.
For now, my recommendation is:
- If you already use JetBrains: Try Junie
- If you don’t have a JetBrains license: It’s not worth buying just for Junie
- For lightweight projects (Next.js, etc.): Cursor is still a better option



What do you think?
Leave your opinion, question or suggestion. Comments are synced with GitHub Discussions .