Introducción

JetBrains, la famosa empresa detrás de editores como IntelliJ IDEA o Android Studio, no ha querido quedarse atrás en la carrera de la inteligencia artificial. Aunque ya lo intentó con su propio modelo “Copilot” que, a mi parecer, fue un fracaso, esta vez nos sorprende con algo nuevo, algo que puede que en tiempo haga temblar a Cursor, el editor de código semi autónomo.

Y es que JetBrains nos presenta Junie, un agente al que podemos delegarle tareas y, como ya hace nuestro buen amigo Cursor, coge contexto del código de tu proyecto y a raíz de eso edita o crea las clases que necesites.

En este post estaremos viendo qué nos ofrece Junie, lo compararemos en las mismas condiciones con Cursor e intentaremos llegar a la conclusión de si merece la pena.

El problema de mantenerse al día

Así es, cada semana nos aparece una IA nueva con más capacidades que la anterior. Es casi imposible estar al día con todo lo nuevo que va saliendo, esta vez nos encontramos con Junie, que en vez de ser un editor diferente es un plugin que puede ir incorporado POR EL MOMENTO a los IDEs IntelliJ Idea, PyCharm y WebStorm.

¿Qué es Junie AI?

La gracia de Junie es olvidarnos de los “rudimentarios” chats donde la IA sólo tiene de contexto lo que hablas con ella. Aquí aprende de tu proyecto completo y te ayuda a hacer las tareas más repetitivas.

No solo revisa los archivos, sino que es capaz de ejecutar comandos, y por lo tanto tests. Así es, te ejecuta los tests y sabe si han ido bien o mal y los puede arreglar. La idea principal que nos presentan es que el desarrollador debe dejar de ocuparse de las tareas repetitivas y centrarse en las decisiones críticas del producto.

Características principales

• Aprendizaje contextual: Aprende de tu proyecto completo, no solo de los chats
• Ejecución de comandos: Puede ejecutar tests y arreglarlos si fallan
• Automatización de tareas repetitivas: Permite al desarrollador centrarse en decisiones críticas
• Integración con IDEs existentes: No requiere cambiar de editor

Estado actual y acceso

Por el momento, Junie solo puede accederse con beta cerrada apuntándose a la lista de espera, pero a mí me la concedieron hace un par de semanas, así que no os preocupéis, no es algo imposible.

👉 https://www.jetbrains.com/junie/

Tecnología detrás de Junie

Por si os lo preguntáis, utilizan LLMs de OpenAI y Anthropic, vamos, como todo el mundo. No es nada nuevo, pero lo que me ha sorprendido es que en ningún momento te deja elegir qué modelo quieres que utilice.

Como veis esta es la interfaz y no pone ningún selector. Entiendo que dependiendo del contexto usará un modelo u otro.

Funcionalidades adicionales y limitaciones

Otra cosa que tiene al igual que Cursor son los Guidelines, un archivo .md que puedes especificar por cada proyecto para que siga esas instrucciones. Os recomiendo la página cursor.directory que recopila muchas instrucciones de este tipo, y en este post lo usaremos para compararlo.

Tampoco se ve que tenga un apartado de index project, funcionalidad que tiene Cursor para poder acceder a ficheros del proyecto con mucha más velocidad. Esto es un problema y se nota, ya veréis que JUNIE nos va a ir mucho más lento.

Otra cosa a remarcar es que según sus políticas y lo que he estado viendo, parece que no hay límite de uso. Así como todos los editores de este estilo se marcan unos límites aunque pagues el premium, aquí no nos lo indica en ningún momento. Imagino que estará capado de alguna manera pero nada que se pueda ver a simple vista.

Por último, otra cosa que debéis saber es que solo podéis acceder a la beta si tenéis la licencia de pago. Si usáis la versión gratuita no vais a poder. Puede que por eso no haya límite de peticiones.

Comparación con Cursor

Vamos a probarlo en igualdad de condiciones con Cursor.

Para probar sus capacidades, no solo voy a basarme en la experiencia de uso que he tenido programando mis proyectos propios, sino que hice una prueba básica para compararlo bien con Cursor.

Me descargué un artefacto base de Spring Initializer, le puse un par de plugins como H2 y Lombok y alguno más, y dupliqué el proyecto para abrirlo en cada editor de código.

El prompt de prueba

El prompt que me preparé fue el siguiente:

Crea un proyecto de Spring Boot con Java 21 utilizando Maven. La aplicación debe gestionar una tienda simple con los siguientes requisitos:

Entidades:
	•	Product: con campos id, name, description, price, stock
	•	Customer: con campos id, name, email, address
	•	Order: con campos id, customer (relación ManyToOne), products (relación ManyToMany), totalAmount, orderDate

Base de datos:
	•	Usa H2 embebido, configuración en application.properties
	•	Crea las tablas automáticamente usando JPA (ddl-auto=update)

Repositorios:
	•	Usa interfaces JpaRepository para cada entidad

Endpoints REST:
	•	Implementa un CRUD completo para Product y Customer
	•	Para Order, implementa:
	•	Crear un pedido asignando productos existentes a un cliente
	•	Obtener todos los pedidos de un cliente por ID
	•	Consultar el total de un pedido

Controladores:
	•	Usa @RestController y @RequestMapping("/api/…") para organizar los endpoints
	•	Valida la entrada con @Valid donde aplique
	•	Devuelve respuestas usando ResponseEntity

Extras:
	•	Usa Lombok para evitar boilerplate
	•	Configura el acceso a la consola de H2
	•	Sigue buenas prácticas (nombres claros, división por capas: controller, service, repository)
	•	Si es posible, implementa DTOs para la entrada/salida de Order para no exponer directamente las entidades

Salida esperada: código completo listo para compilar, incluyendo:
	•	pom.xml con dependencias necesarias
	•	Clases Entity
	•	Interfaces Repository
	•	Clases Service si aplica
	•	Controladores REST
	•	Configuración en application.properties

Instrucciones personalizadas

Y a parte, tanto en Cursor con las rules personalizadas y en Junie con sus guidelines (que vienen a ser lo mismo) les he indicado esto de aquí para que lo tengan en cuenta:

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.

El proceso de ejecución

Llega la hora de la verdad, ejecuto ambos IDEs y dejo que procesen. En Cursor, para no hacer una competencia desleal, he activado la opción de LLM automático, ya que al fin y al cabo JUNIE también lo hace automático y no te deja elegir. Podría haber elegido Claude 3.7 Sonnet MAX Thinking pero, aparte de costarme un ojo de la cara, no sería justo.

Después de un rato esperando, para ser sinceros, Cursor termina mucho antes. A Junie por lo general le cuesta más realizar las operaciones.

Resultados de la prueba

Ejecuto ambos códigos y los dos compilan y se ejecutan sin problemas, eso es buena señal.

Junie AI

• Ventajas:

  • Código más limpio y estructurado
  • Implementación de DTOs
  • Error handlers incluidos
  • Configuración CSRF básica
  • Tests más eficientes y contextuales

• Desventajas:

  • Mayor tiempo de respuesta
  • Sin selector de modelos
  • Sin indexación de proyecto

Me pongo a revisar el código de Junie y por lo general ha hecho un buen código. Obviamente tiene una arquitectura muy muy básica, y recordemos que es un prompt super simple, pero la estructura no me disgusta y nos ha creado DTOs, ErrorHandlers e incluso una config de CSRF básica. No está nada mal para estar en beta.

Cursor

• Ventajas:

  • Respuesta más rápida
  • Selector de modelos disponible
  • Mejor indexación de proyecto

• Desventajas:

  • Estructura de carpetas en español (inconsistente)
  • Falta de error handlers
  • Uso directo de entidades en controladores (sin DTOs)

Revisando el código de Cursor, veo que me ha hecho parte de la estructura de carpetas en español. Curioso, sí que es verdad que el prompt estaba en español, pero vamos, aquí veo una red flag. Luego me llevo más sorpresas: no encuentro ningún error handler y, vaya, ¿qué es esto? El coleguita de Cursor me está usando en los controladores no solamente el mismo objeto de entrada y salida, sino que entramos al objeto y no es ni un DTO, es directamente el entity.

La verdad que una sorpresa para mal, no me esperaba esta chapuza, cosa que Junie no ha fallado y gracias a dios.

Como último apunte a favor de Junie, os debo decir que he estado probando que me haga tests y me suba el coverage y es mucho más eficiente que Copilot o similar, ya que al tener contexto de todo el proyecto sabe exactamente cómo mockear los objetos y puede ir ejecutando los tests. Cosa que me he dado cuenta que también hace si le pides editar código existente que ya tiene tests: te lo edita y ejecuta sus tests, que si fallan te los arregla. Algo muy curioso.

Tabla comparativa

Conclusión

En definitiva y poniendo todos los datos sobre la mesa, Junie merece la pena probarlo, pero si no tienes licencia de IntelliJ entonces no vale la pena que lo compres solo por esto. Veo que es una herramienta bastante útil en aplicaciones más robustas que Cursor (el cual funciona mejor para aplicaciones livianas con frameworks como Next.js), pero tampoco pienso que sea la panacea.

Hay que tener mucho cuidado con estas herramientas, ya que aunque le especifique mucho, me he encontrado que hace cosas en el código de manera poco óptima y recomendable. Además, por no hablar del peligro que tiene que los desarrolladores dependan constantemente de los LLM, aunque eso es un tema aparte que trataré en otro post.

Por ahora, mi recomendación es:

• Si ya usas JetBrains: Prueba Junie
• Si no tienes licencia JetBrains: No merece la pena comprarla solo por Junie
• Para proyectos ligeros (Next.js, etc.): Cursor sigue siendo una mejor opción