Thoughts About Junie

A coding-agent up and coming

This was generated by AI. View the prompt flow.

Junie is a project-scoped coding agent offered by Jetbrains directly within the IntelliJ line of IDEs as a plugin. The following is my review of the service.

I’ve found giving Junie anything but the most specific instructions problematic on a lot of levels. I believe Junie is probably among the best in terms of capability among project-scoped coding agents, but the best is still not good enough. There are lots of silly mistakes, more than I’d expect a competent developer to make. And to be fair, there are a few really well-structured solutions too. The issue is the reliability.

Even when the code works, there is the issue of my relationship to the code. Code that I wrote myself seems to be very easy for my working memory to access, and I can jump around in projects like Aladdin in Agrabah. When I didn’t write it, updates and bugfixes take a lot longer and the experience just doesn’t appeal on the same level. I could take time to read what Junie wrote and sometimes that is interesting for side reasons but it is just not as engaging as writing it myself. If AI makes work a little more efficient but a lot more boring, I think it is still a net loss.

This is not a problem with Junie itself, which seems to be best-in-class. It is a problem with outsourcing the generation of your code to an intelligence that cannot understand the application of your code on a human level.

The happy medium I’ve found is defining workflows for Junie which is something like a template that you define in English rather than a markup language. The key here is that I know exactly what Junie should be creating, my working memory treats it like code I wrote myself even when a good chunk of it is Junie. Most often, these workflows focus on starting the file and taking all the boilerplate tasks that are unique to my project structure. She writes enough of my code to make me feel like I’m using AI effectively and the experience of coding is just as engaging, maybe a bit more because we are moving faster.

Here is an example of how I’ve defined these workflows, it is the general instructions and a few of the workflows, there are many more. Junie follows these instructions perfectly 99% of the time.

AI workflow functions (from guidelines.md)

The following functions define workflows and parameters. These may be invoked as prompts in the form of Workflow(argument). Perform the instructions in the body of the workflow given the provided arguments. Foo will be used as a placeholder for a type name. Unless otherwise directed, only create the content described in the function, do not worry about integration with the rest of the project. You may also modify this file (guidelines.md) with any information that may provide clarity for the next time you follow the steps outlined in the function.

CreateModel(Foo):

• Create a new data class in the form of data class Foo(val fooId: FooId) in the package ponder.ember.model.data. It must be serializable.

• Also create the value class value class FooId(override val fooId: String): TableId<String>.

CreateTable(Foo):

• Create a new table in the form of FooTable in the file FooTable.kt that will provide Foo objects.

• You may use Example and ExampleTable as examples. Add FooTable to dbTables in Dababases.kt.

CreateTableDao(Foo):

• Create a class FooTableDao in the package ponder.ember.server.db.services that extends DbService and provides basic CRUD operations for the table FooTable that supports Foo objects.

• You may use ExampleTableDao as an example.

CreateTableService(Foo):

• Create class FooTableService(val dao: FooTableDao = FooTableDao()): DbService { } in the package ponder.ember.server.db.services that extends DbService and takes a FooTableDao as an argument.

• Add a private global value before FooTableService: private val console = globalConsole.getHandle(FooTableService::class)

• Do not add any functions to the body of the class unless specifically asked.