Choosing the Agent Layer: IDE Plugin, Junie, Aider, or Something Else?

At this point in the experiment, I have Ollama running locally and I've tested four models on my M2 Mac.

The next piece is the agent.

My initial architecture has the agent sitting somewhere between the IDE and Ollama:

But how do I choose the agent?

Should it be an IntelliJ plugin? A VS Code extension? A command-line tool? Should it own the model connection? Should it manage Git? How does it find files? Can it run tests? Can I replace Ollama with a remote model later?

Before installing another tool, I need to define what I actually expect from it.

What does the agent layer need to do?

The agent layer is the software responsible for making this loop possible.

For my experiment, the basic requirements are:

• read and search files;
• understand the repository structure;
• modify existing files and create new ones;
• work across multiple files;
• execute terminal commands;
• run builds and tests;
• read errors and test failures;
• continue working based on those results;
• inspect Git status and diffs.

This is very different from asking an AI chat to generate a Java method and manually copying it into IntelliJ.

Eventually, I want to give the agent something like:

Add validation to the transaction creation endpoint.
Follow the existing project patterns and add the necessary tests.

From there, it should figure out which files it needs, make the changes, run the tests, inspect any failures, and show me the result.

Does the agent really need to live inside the IDE?

IDE integration initially seems like an obvious requirement.

I use IntelliJ for Java and Spring Boot. I use VS Code for Next.js. Having the agent directly inside each IDE sounds convenient.

But this creates an architectural problem.

Which agent can serve both environments? Are there plugins or extensions that work in both?

If I choose an IntelliJ-specific agent, what happens when I work on the frontend?

If I choose a VS Code extension, what happens to the backend workflow?

And what happens later when one task crosses both projects?

For example:

Backend API response changes
            ↓
Frontend TypeScript type changes
            ↓
UI consuming the response changes

The repository starts to look like a better center for the agent than the IDE.

So I revise the architecture:

The IDE remains important, but it becomes my development and review interface rather than the place where the agent must live.

This also opens the door to command-line agents.

The model also needs to be replaceable

There is another requirement I don't want to lose.

I'm starting with Ollama and local models, but I want the environment to remain flexible for later experiments:

If I eventually replace the local model with a remote one, I don't want to replace the entire coding workflow with it.

So the agent should ideally support:

• Ollama now;
• different local models;
• remote endpoints later;
• commercial model providers if needed.

The model should be a component of the system, not the system itself.

Context needs to be discovered, not constantly pasted

Another important requirement is how the agent finds context.

If I ask:

Fix the failing test in TransactionServiceTest.

I don't want to manually provide every file it might need.

The workflow I'm looking for is closer to:

Find TransactionServiceTest
        ↓
Read it
        ↓
Find TransactionService
        ↓
Read it
        ↓
Follow Repository / Entity dependencies
        ↓
Decide what needs to change

The agent should actively discover the project instead of depending on me to build the perfect prompt with all the necessary source code attached.

Later, I'll need to test how well each agent actually finds and manages this context.

Safety is part of the architecture

Giving an agent terminal and filesystem access also means deciding what it should be allowed to do.

My starting point is:

Operation	Permission
Read/search files	Allow
Edit/create files	Allow
Run tests/builds	Allow
git status / git diff	Allow
Delete files	Ask
Install dependencies	Ask
Git commit	Ask
Git push	Ask
Database migrations	Ask
Production commands	Never

I don't necessarily need an agent that implements this exact permission table.

I do need enough control to approximate it.

The workflow I'm aiming for still ends with me:

Autonomy inside the task doesn't mean unlimited authority over the project.

So what should I actually evaluate?

Once IDE integration stops being the main requirement, the selection criteria become much clearer.

Requirement	Priority
File/search/edit tools	Required
Terminal/build/test execution	Required
Iterative agent loop	Required
Ollama/local models	Required
IDE independence	Required
Multi-file work	Required
Cross-project awareness	Strong preference
Remote model providers	Strong preference
Permission controls	Strong preference
IntelliJ integration	Optional
VS Code integration	Optional

The order matters.

A beautiful IntelliJ integration won't help much if the agent can't reliably inspect the repository or run the project tests.

Two candidates make the shortlist

There are many coding-agent tools I could test, but evaluating five or six would quickly turn this experiment into a survey of AI products.

I want two candidates that satisfy the main requirements while taking different approaches.

The shortlist is:

1. Junie CLI
2. Aider

Junie CLI is interesting because it closely resembles the agent architecture I'm trying to build: a command-line agent that can work with files and tools, execute multi-step tasks, connect to Ollama, and leave room for other model providers later.

Aider approaches coding more from the repository and Git workflow. It also supports Ollama, multiple files, code changes, tests, and other model providers. Its different approach makes it a useful comparison rather than simply another implementation of the same idea.

At this stage, I only need to determine whether both satisfy enough of my requirements to deserve a real test.

Based on their capabilities, they do.

The next step is to find out whether those capabilities actually work with my local setup.

The harness is part of the experiment now

Until this point, most of my attention has been on models.

7B versus 14B. Coding-focused versus reasoning-focused. Speed versus quality. Memory pressure versus capability.

Now another variable enters the experiment:

Model + Agent harness + Context + Tools + Permissions = Coding experience

A better model doesn't automatically create a better coding agent. The harness determines how the model interacts with the repository and what it can actually do with its reasoning.

Junie and Aider both look capable enough to test.

But I don't want to decide which architecture works better from documentation and feature lists. I'll connect both to the local models, give them the same kind of tasks, and see what actually happens.