THE IDE: BEST FRIEND? OR MORTAL ENEMY

I've seen some people asking about IDE's, and though this may be a bit _dense_ for a beginner, it's worth it - I went from 0 technical computer experience to vibe coding and my first IDE was nvim and i'm so happy I stuck with it.

ymmv of course, but i think this matters more than people realize.

if you’re reading `context.md` files, following references, comparing drafts, auditing agent output, checking diffs, jumping between workspace layers, and constantly moving between docs, then your ide is not just where the text lives. it’s part of the workflow.

that’s really all i’m trying to say here.

also this is still kinda scratching the surface. the real sauce is when your tools start piping into each other cleanly. if theres an audience for this, I have plenty more to share.

but this is also not me trying to sell anybody on nvim as a religion lol (although nvim do go brrrr). i use _lazyvim_ and i like it a lot, but the actual takeaway is bigger than that:

- move through context fast

- compare artifacts without friction

- change workspace scope fast

- make file navigation structural instead of annoying

- keep git/review close to where you think

if you can do that in something else, sick. keep cooking.

but i'm a man of culture. and if i have to get something done, i have a shortcut for it.

lemmebreakitdown4ya

## 1. treat links like movement

this is probably the biggest one for me.

in markdown i use `gf` to open the link under the cursor and `gF` to open it in a vertical split.

tiny feature, huge difference.

instead of reading a router doc and then manually hunting for the next file like a caveman, i just move. with finesse. elegance. poise.`context.md` points to a workflow doc? go there. workflow doc points to a voice guide? go there. that points somewhere else? keep going.

it makes the workspace feel traversable.

and that is a massive deal in icm because the whole system is built around context handoffs. if following those handoffs feels clunky, you are adding friction right where the method is supposed to be clean.

so yeah, if you steal one thing from this post, steal this:

**make references easy enough to follow that moving through context feels natural.**

clickable links, hotkeys, split-open behavior, whatever. just make it easy.

## 2. use splits like an adult

i mean this lovingly.

if i’m reviewing a draft against a router, checking a spec against source material, or comparing two versions of a file, i do not want to keep alt-tabbing between buffers like our ancestors, and I don't want to move my hand off the keyboard because im cozy.

just put them side by side brother.

in my setup:

- `gF` opens a referenced file in a vertical split

- `<leader>bv` opens the alternate buffer in a vertical split

- `H` and `L` cycle buffers

- `<C-j> <C-l> <C-k> <C-i>` move between windows

once moving between windows feels normal, splits stop feeling fancy and just start feeling correct.

and this is huge for icm work because the job of .md files are the heartbeat of ICM, being able to navigate them confidently will increase your understanding.

- Comparing scripts? split

- is this draft still aligned with the angle? splittyyyyyy

- what changed between these versions? split it

- what does upstream context say vs what the downstream artifact did?

bananasplit

make comparison easy and your judgment gets better.

movie.

## 3. build a navigation system, not just a file tree

most people have one sidebar and they kinda just jab at it until the right file opens.

again, ymmv, but i’ve gotten way more value out of treating file navigation like part of workspace design.

my nvim setup uses dual oil rails:

- one file tree for the main workspace/root

- another rail for a second directory i want nearby

that means instead of constantly collapsing folders, reopening folders, `cd`ing around, forgetting where i was, reopening the same path 19 times, etc, i can keep two context surfaces visible.

that gets useful fast.

example:

- top rail = current workspace root

- bottom rail = adjacent docs folder, another project, scratch area, whatever i need nearby

now i can scout, compare, and create files from both zones without losing my place.

that’s what i mean when i say workspace builder.

your ide should help you shape the surface you work on.

not just "open file pls"

more like:

- what context do i want visible right now?

- what two areas am i moving between the most?

- what should stay nearby while i’m working?

if your current setup makes that annoying, i honestly think it’s worth fixing.

## 4. make file and folder creation stupid easy

this sounds low stakes until you notice how much bad structure comes from tiny friction.

if making a new folder, new markdown file, or little support doc is annoying, you will avoid doing it.

then the workspace turns into soup and everybody acts shocked.

in icm, structure is not some optional aesthetic choice. if a workspace wants:

- a router

- workflow docs

- support docs

- draft folders

- handoff files

then making those things should feel instant.

that’s one reason i like handling a lot of this from inside the file explorer instead of always dropping to shell or clicking around finder.

less resistance between "this should exist" and "ok now it exists in the right place."

that compounds.

## 5. use workspace jumps to zoom scope in and out

zoxide absolutely rips if you have a bunch of active projects.

for me it’s not just a faster `cd`. it’s scope control.

in my setup:

- `<leader>zz` sends a zoxide-picked dir to the top rail

- `<leader>zo` sends one to the bottom rail

- `<leader>fz` gives me a broader zoxide picker

so if i want to jump from one workspace root to another, or move from a local draft area back up to a bigger workspace surface, i can do it fast without losing rhythm.

that matters a lot in icm because the work is almost never just "sit in one folder forever and vibe."

you’re constantly changing scope:

- root workspace

- current lane

- current draft

- sibling project

- adjacent reference material

if changing scope is slow, your workflow gets sticky.

## 6. keep git close

i’m a big fan of being able to check git state without leaving the editor.

for me that usually means lazygit.

i can pop in, inspect a diff, sanity check what changed, and bounce right back out.

that is especially useful when agents are involved because half the battle is audit the logs brother audit the logs.

you want to be able to answer quickly:

- what changed?

- was it the right file?

- did it actually do what i asked?

- is this clean or did some random blast radius nonsense happen?

and you want it to be as fast as typing "gg".

because if checking that requires a whole ceremony, you’ll do it less.

and if you do it less, weird shit slips through.

so yeah. keep git close.

## 7. optimize for the work you actually do

this is the meta point underneath all of it.

people copy configs without asking what kind of work they’re actually trying to make easier.

my setup is heavily tuned for markdown, routing, workspace docs, and writing. so naturally i care about things like:

- markdown rendering in-editor

- browser preview when needed

- heading navigation

- outline sidebar

- spell/writing ergonomics

- fast buffer movement

- opening links internally

that may not be your exact stack.

cool. doesn’t matter.

the principle still holds:

**optimize your ide around the work you actually repeat.**

not the work some repo says elite users do.

not the work a plugin demo makes look sexy.

not the work your fantasy self might do one day.

i mean the real work. the repeated work. the boring daily work.

that’s where the gains are.

## 8. don’t copy my keybinds blindly

i do think some of these patterns are strong:

- `gf` / `gF` for moving through markdown links

- `H` / `L` for buffer cycling

- `<C-j> <C-l> <C-k> <C-i>` for directional window movement

- dual file tree rails for active + scouting context

- zoxide jumps for fast scope changes (leader zz and leader zo)

- lazygit for quick diff review

but the lesson is not "copy my exact config and attain enlightenment king"

the lesson is: build a surface that supports how you think.

if you work in icm, your ide should probably help you:

- read context in sequence

- move between files fast

- compare artifacts side by side

- reshape folders/docs quickly

- audit output without breaking flow

how you get there is up to you.

## 9. closing thought

i’ve only been using nvim for like 8 months and i already feel way more fluent in my workspace because of stuff like this.

not because i became a wizard overnight. just because i started paying attention to how the editor participates in the workflow.

that’s the thing i wish more people took seriously.

we talk a lot in icm about routing, context, handoffs, constraints, workspace design, all that good stuff. but the local surface where you actually read, compare, traverse, and shape those files matters too.

whether you're conscious of it or not _you are always routing yourself mentally as well_ so your surface should help you with that.

so yeah, that’s my whole pitch if you even wanna call it that:

don’t just make your ide look cool. (it will tho)

make context easier to follow.

make review easier.

make the workspace easier to navigate.

make it easier to think.

outsource work. don’t outsource your thinking.

your ide can help with that way more than people think.

- yucky

0 comments