I've been using Vim for years, and I've never really felt the need to move to an IDE.
Vim already gives me what I need: navigate a codebase, search, edit, inspect files, work with Git, and use the terminal. It is fast, predictable, and stays out of my way.
But agentic coding has changed something interesting.
It has changed what I need from my editor.
When an AI agent can investigate a codebase, create a plan, implement a feature across multiple files, run tests, fix failures, and review its own changes, I spend less time writing code and more time understanding and controlling what is being done.
And Vim fits this workflow extremely well.
The Change
Traditional coding looks roughly like this:
Think
↓
Write
↓
Compile
↓
Debug
↓
Repeat
The developer is doing most of the implementation, while Vim provides a fast interface for doing that work.
With agentic coding, it becomes:
Idea
↓
Discovery
↓
Investigation
↓
Plan
↓
Agent implements
↓
Testing
↓
Review
↓
Human approval
The agent is now capable of handling large portions of the implementation.
My role becomes more focused on:
Understand
Decide
Direct
Inspect
Correct
Approve
This doesn't make the editor less important.
It makes fast interaction with the repository more important.
And that is something Vim has always been very good at.
Start With a Vague Idea
Suppose I want to add refresh-token support to a Java application.
I don't immediately create a task saying:
Implement refresh tokens.
There are too many unknowns.
Instead, I start a discovery conversation with an agent:
I want to add refresh-token support.
Explore the existing authentication system and
help me understand what would be involved.
Do not modify anything.
The agent investigates the repository.
It might find:
AuthController
↓
AuthService
↓
UserRepository
TokenService
↓
JWT configuration
SecurityConfig
↓
Spring Security
Authentication tests
It can also identify things I didn't initially know about:
-
where tokens are generated
-
how authentication state is stored
-
whether refresh tokens already partially exist
-
how expiration is configured
-
which database tables are involved
-
which tests need to change
At this stage, I am not asking the agent to code.
I'm using it to reduce uncertainty.
Investigation Before Implementation
Once the general idea is understood, I ask the agent for a deeper investigation.
Investigate the authentication flow in detail.
Identify the relevant classes, configuration,
database entities, and tests.
Explain how refresh-token support should fit
into the existing architecture.
Do not modify source code.
The result might identify:
src/main/java/auth/AuthController.java
src/main/java/auth/AuthService.java
src/main/java/auth/TokenService.java
src/main/java/security/SecurityConfig.java
src/main/java/user/User.java
src/test/java/auth/AuthServiceTest.java
src/test/java/auth/TokenServiceTest.java
Now I can open the actual files in Vim.
:e src/main/java/auth/AuthService.java
Search:
/Auth
Jump to definitions:
gd
Open another file:
:vs src/main/java/auth/TokenService.java
Search the repository from the terminal:
rg "generateToken" src/
This is where Vim becomes particularly useful.
I'm not trying to write the feature yet.
I'm trying to understand the system.
Turn the Investigation Into a Plan
Once enough is understood, I ask the agent:
Based on the investigation, create an implementation plan.
Include:
- files to change
- database changes
- API changes
- tests
- security considerations
- potential risks
Do not implement anything yet.
The plan goes into something like:
plans/active/add-refresh-token.md
I open it:
:e plans/active/add-refresh-token.md
Now the important decision is mine.
Does the plan actually make sense?
Did the agent misunderstand the architecture?
Is a new database table really necessary?
Should the refresh token be stored differently?
Are the proposed API changes compatible with the existing clients?
This is an important part of agentic coding:
The agent can create the plan. It doesn't mean I have to accept the plan.
Vim gives me a very simple environment for checking the plan against the actual code.
Then Let the Agent Work
Once the plan is correct:
Implement plans/active/add-refresh-token.md
Follow the existing architecture.
Do not modify unrelated code.
Run the relevant tests after implementation.
Now the agent can do what it is good at.
It might modify:
AuthController.java
AuthService.java
TokenService.java
SecurityConfig.java
User.java
AuthServiceTest.java
TokenServiceTest.java
Maybe seven files.
Maybe twenty.
That's fine.
I don't need to sit there watching it type.
This is one of the biggest changes with agentic coding.
Typing is no longer the scarce resource.
Understanding the result is.
Back to Vim
When the agent finishes, I don't need a special AI interface to understand what happened.
I use Git.
git diff
And inspect the changes in Vim.
This is where the workflow becomes very natural.
I can search through the diff:
/refreshToken
Jump between files.
Open the implementation beside the tests.
Look at the database changes.
Inspect the API changes.
Compare the new code with the existing architecture.
The agent may have changed ten files, but I can move through them extremely quickly.
I am no longer using Vim primarily as a place to produce the code.
I'm using it to inspect the code produced by the agent.
Small Changes Are Still Mine
Agentic coding doesn't mean I never touch the code.
Suppose the agent produces:
if (refreshToken != null && refreshToken.isValid()) {
return generateAccessToken(user);
}
but I decide that the validation belongs inside TokenService.
I can simply edit it.
ci{
Move the code.
Search.
Save.
Done.
There is no need to ask an agent to perform every tiny change.
This creates a useful division:
Agent
↓
Large-scale changes
Vim
↓
Small-scale human changes
The agent is good at transforming a system.
Vim is good at letting me make exactly the change I want.
Testing Becomes a Conversation
After implementation:
./verify.sh
Suppose it reports:
42 tests passed
2 tests failed
AuthServiceTest
TokenServiceTest
I can investigate the failure myself or give it back to the agent:
Investigate these test failures.
Determine whether the implementation or
the tests are incorrect.
Do not modify unrelated code.
The agent investigates.
Maybe it discovers that the refresh-token expiration is being calculated using the wrong configuration property.
It fixes the problem.
Then:
./verify.sh
again.
This cycle can continue:
Agent
↓
Changes
↓
Vim
↓
Human inspection
↓
Tests
↓
Agent
Vim sits naturally in the middle because it doesn't need to own the entire development process.
Code Review Is Even More Important
The larger the changes an agent can make, the more important review becomes.
A developer might previously write twenty lines and immediately understand every line.
An agent can now produce two hundred lines across fifteen files in a few minutes.
That makes review a first-class activity.
I might ask the agent:
Review your implementation against the original plan.
Look specifically for:
- unnecessary changes
- architectural violations
- missing tests
- security issues
- error handling problems
- duplicated logic
Do not make changes yet. Report findings.
Then I inspect the result myself.
Again:
git diff
Vim is the human inspection layer.
If the agent says:
I found one potential issue in AuthService.
The transaction boundary may be incorrect.
I can immediately jump there, inspect the surrounding code, and decide what should happen.
The Editor Doesn't Need to Become the Agent
This is where I think agentic coding becomes particularly interesting.
There is a tendency to put everything into one environment:
Editor
├── Chat
├── Agent
├── Terminal
├── Git
├── Tests
├── Debugger
├── Planning
└── Everything else
But I don't think the agent needs to become part of Vim in order for Vim to work well with agentic coding.
The agent can simply be another tool.
For example:
agent investigate
agent plan
agent implement plans/active/add-refresh-token.md
agent review
And Vim remains Vim.
Human
│
▼
Vim
│
┌───────┴───────┐
▼ ▼
Agent Terminal
│ │
└───────┬───────┘
▼
Repository
This is a very simple architecture.
And I like simple architectures.
Vim as the Human Interface
The more I use agents this way, the more I see Vim as the human interface to the repository.
The agent understands and transforms the codebase.
The terminal executes things.
Git records and compares things.
Vim lets me inspect and manipulate things.
And I make the decisions.
Agent → implementation
Terminal → execution
Git → history and diff
Vim → inspection and editing
Human → decisions
None of these components needs to become everything.
What Actually Changes
The interesting change isn't that Vim suddenly became useful.
It was already useful.
The change is that the distribution of work has changed.
Before:
Human
↓
Vim
↓
Code
Now:
Human
↓
Agent
↓
Code
Human
↓
Vim
↓
Inspect / Edit / Review
The agent handles increasingly large transformations.
The human spends increasingly more time navigating, understanding, reviewing, and deciding.
Vim has always been excellent at those things.
So agentic coding doesn't require Vim to become an IDE.
It doesn't require Vim to become an AI assistant.
It can simply remain what it has always been:
a very fast interface between the developer and the codebase.
The difference is that now, on the other side of that interface, there is an agent doing much more of the implementation.
And that makes the combination surprisingly powerful.