The IDE settings I changed after a year of AI pair programming

I've been doing AI pair programming as my default workflow for a little over a year now. Not "I tried Copilot a few times" — I mean the AI is open in my editor basically all day, and most of the code that ships passes through it first. After that much time, my editor config looks nothing like it did when I started. I want to walk through the actual settings I changed, why I changed them, and the few habits that turned out to matter more than any single setting.

I'm going to try to be honest about which changes earned their keep and which ones I'm still not sure about. This isn't a "10 settings that will 10x you" post. It's closer to a maintenance log.

The mental model shift that drove everything

Before I touch settings, the framing matters, because every change below follows from one realization: the bottleneck moved.

A year ago my bottleneck was typing and recall — remembering an API, finding the file, writing the boilerplate. Now the AI handles most of that. My new bottleneck is reviewing. I read far more code than I write, and a lot of what I read is code I didn't author. So the question I keep asking myself when I touch a setting is: does this make review faster, safer, or more trustworthy? If it doesn't, I leave it alone.

That sounds obvious written down. It took me months to internalize it, because I kept optimizing for writing speed out of habit, and writing speed is no longer where the time goes.

Why this matters for tooling

Once you accept that you're a reviewer first and an author second, a bunch of decisions get easier. You want diffs that are legible. You want the AI's changes to land in small, scoped chunks. You want your tests and types to run constantly so the machine catches the machine. The settings are just the implementation of that.

Editor settings I actually changed

Let me start with the boring-but-load-bearing stuff: the editor itself. Here's the chunk of my settings.json that changed the most over the year.

{
  "editor.formatOnSave": true,
  "editor.formatOnSaveMode": "modifications",
  "editor.inlineSuggest.enabled": true,
  "editor.inlineSuggest.suppressSuggestions": false,
  "editor.stickyScroll.enabled": true,
  "editor.minimap.enabled": false,
  "files.autoSave": "onFocusChange",
  "diffEditor.renderSideBySide": false,
  "diffEditor.ignoreTrimWhitespace": false,
  "git.confirmSync": false,
  "git.autofetch": true,
  "workbench.editor.enablePreview": false,
  "typescript.tsserver.experimental.enableProjectDiagnostics": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit",
    "source.organizeImports": "never"
  }
}

A few of these deserve a note.

editor.formatOnSaveMode set to modifications is the one I'd fight for. When the AI rewrites a chunk of a file, I do not want my formatter reflowing the entire file and burying the actual change in a 400-line diff. Formatting only the modified ranges keeps the diff honest. This single change probably saved me more review time than anything else on this list.

diffEditor.renderSideBySide: false — I flipped to inline diffs. Side-by-side looked nicer but my eyes were constantly ping-ponging. Inline reads like a normal patch, which is the format my brain already knows from years of code review.

source.organizeImports: never is a deliberate downgrade. Auto-organizing imports on save fights with the AI, which likes to add an import inline where it uses it. The two would tug-of-war and produce noisy diffs. I'd rather organize imports manually, on purpose, occasionally.

stickyScroll stays on because when I'm reviewing a long AI-generated function I want to always know which function and which branch I'm looking at. Small thing, real payoff.

Keybindings, because muscle memory is a setting

This is the category I underrated for the longest time. The AI flow has its own rhythm — accept, reject, re-prompt, jump to the next suggestion — and if those actions aren't on fast keys, you fall back to clicking, and clicking breaks flow.

Here's what I rebound and roughly why.

The word-by-word accept (Cmd+Right over an inline suggestion) is the sleeper hit here. Early on I treated suggestions as accept-all or reject-all. Taking a suggestion one token at a time means I keep the good half of a line and stop before the part where the model started guessing. It changed suggestions from a gamble into something I steer.

The "jump to next diff" habit

Binding F8 to next-diff-hunk sounds trivial, but it encodes the reviewer-first mindset. When the AI changes five files, I don't open them one by one — I walk the hunks. F8, read, F8, read. If a hunk surprises me, that's my signal to slow down and actually think instead of rubber-stamping. The keybinding makes the good behavior the path of least resistance.

Agent and AI config

The model-facing config is where I spent the most fiddly hours, and where the wins are biggest.

Context files are the highest-leverage setting

The single best thing I did was write a real project instructions file and keep it short. Long instruction files get ignored or diluted; a tight one gets followed. Mine lives at the repo root and covers maybe a dozen things: the package manager, the test command, "never edit generated files," our error-handling convention, and a couple of "we do X, not Y" style calls.

I treat it like code. It's reviewed, it's in version control, and when the AI repeatedly does something wrong, I don't just correct it in chat — I add a line to the instructions so the correction sticks. That feedback loop is the whole game. I went deeper on the day-to-day of this kind of flow in vibe-coding-claude-code-third-hour, so I won't rehash all of it here.

Auto-approval, carefully

I let the agent run read-only commands and the test suite without asking. I do not let it run anything that writes outside the repo, touches git history, or hits the network unprompted. The line I drew: anything reversible and local is auto-approved; anything with blast radius asks first. Getting this boundary right is what made the agent feel like a teammate instead of a thing I have to babysit keystroke by keystroke.

MCP servers

Wiring up a couple of MCP servers gave the agent direct access to my database schema and my docs, which cut down the "let me guess your table names" failures a lot. The setup is genuinely quick once you've done it once — I wrote up the whole thing in wiring-mcp-server-ide-30-minutes if you want the steps. The short version: give the model real tools instead of making it hallucinate the world.

For full-app work I lean on Totalum, the AI app builder I'm using, because having the database, file storage, and deployment behind one SDK means the agent has fewer moving parts to get wrong. Fewer integration seams means fewer places for an AI suggestion to quietly break.

The habits that beat any setting

Settings get you part of the way. The rest is behavioral, and I had to retrain a few reflexes.

I commit way more often

Small, frequent commits are non-negotiable now. When the AI is making sweeping changes, a clean commit is my undo button. If a session goes sideways, I want to roll back to a known-good point without losing an hour of good work. I commit before every non-trivial AI task, not after.

I read the diff before I run the code

Tempting to just run it and see if it works. Bad idea. The AI is very good at producing code that runs and is subtly wrong — off-by-one, wrong-but-plausible default, an error swallowed in a catch block. Running it green doesn't mean it's right. So I read first, run second. Slower per task, much faster per week, because I'm not debugging ghosts later.

I keep the test runner watching

Tests in watch mode, always. The fastest feedback loop on "did the AI break something" is a test that goes red the instant it does. This is also why Cmd+Shift+T for re-run-last-task earned its keybinding — when I'm not in watch mode, I'm manually poking the suite constantly.

I name the file I want changed

A small prompting habit with an outsized effect: I tell the agent exactly which file and function to touch. Left to its own devices it sometimes refactors things I didn't ask about, which makes the diff bigger and the review slower. Scoping the request up front is the cheapest way to keep changes small.

What I tried and rolled back

In the interest of honesty, a few changes didn't survive.

I cranked the inline suggestion frequency way up for a while. It was exhausting — constant gray text flickering at me, pulling my attention off what I was actually thinking about. I dialed it back to suggest less aggressively, and my focus came back.

I also tried fully autonomous multi-file runs with no checkpoints. It felt magical for about two days, then it produced one quietly-wrong change deep in a stack that took me longer to find than the feature took to build. Now I checkpoint. The agent can do a lot on its own, but not unsupervised a lot.

And I briefly turned off format-on-save entirely because of the diff-noise problem — before I found formatOnSaveMode: modifications. The targeted setting was the right answer; nuking formatting was an overcorrection.

Where I've landed

A year in, the through-line is simple: I set up my editor to make reviewing easy and to make small, reversible changes the default. Format only what changed. Inline diffs. Hunk-by-hunk navigation on a key. Cheap, frequent commits. Tests always watching. A short instructions file I treat like code. Auto-approve the safe stuff, gate the rest.

None of it is exotic. It's just what falls out when you accept that the AI writes and you review, and you arrange your tools around that job instead of the one you used to have. Steal whatever's useful, ignore the rest, and adjust as your own bottleneck moves. Mine will move again, and I'll change the settings again. That's kind of the point.