How I configure VS Code for agentic coding

Agents have profound implications for how LLMs integrate into the day-to-day work of building software. Whereas the chat LLMs of 2022-2024 required the use of context engines and heavy UIs within the editor, agents fetch their own context through the use of tools. As a result, we no longer need much of the UI developed for the chat LLM era where the human was deeply involved in curating context and steering the LLM at every step.

The optimal UX for coding agents feels like it should be far more command-driven than the RAG chatbots and AI IDEs of the RAG-bot era. Tools like Aider and Claude Code have demonstrated the potential of the CLI and even called into question whether the IDE is still necessary. For now, however, I’m still making heavy use of the editor for agentic coding, but I’m using it in a very different way than before.

Amp is the coding agent that we’re building at Sourcegraph and that I’m using day-to-day. It’s available as both a CLI and a VS-Code-compatible extension:

• I use the CLI for parallelizing lightweight tasks across multiple worktrees in tmux.
• I use the editor extension for larger, more complex features and tasks.

This post describes the latter and how I’ve configured my editor to streamline agentic coding.

The workflow

The way I use the editor has changed a lot in the past 3 months. The actual editor pane is now secondary. I now prefer to “write” code primarily through the agent, rather than manually typing code myself. The primary views in my workflow are the Amp panel and the diff view. I alternate mainly between two modes: writing code through Amp and reviewing code through the diff view.

When starting a new feature or task, I begin with a detailed prompt to Amp in the right-hand side panel:

After the agent has finished and awaits human input, I open the diff view to review its changes:

One of the nice features of the VS Code diff view is that code intelligence actions like go-to-definition and find-references work in the green side of the diff. I review the changes file-by-file and stage the changes that look good enough to keep. If there are changes I don’t like, I either ask Amp to make modifications or I manually edit the files.

After I’m satisfied, I commit the changes, close the diff view, and hop back to Amp for the next task. As a general rule, I prefer creating new threads for subsequent tasks (LLMs are generally smarter when less of the context window has been used). The exception to this is when the next task is closely related to the change I just made and would be helped out by the existing Amp thread context.

Zooming out, here is the overall workflow:

1. Describe the change I want Amp to make
2. Review changes in the diff view, making and staging edits
3. Repeat

In addition to the diff view, the panels for Problems (editor diagnostics), Debug Console, and Terminal are also useful in the review stage, so I have them hot-keyed for easy access:

The shortcuts

Good keybindings have long been essential to streamlining software development and agentic coding is no different. I highly recommend the following keybindings to make the views in the workflow I’ve just described easily accessible:

All these key-bindings involve the ⌘⌥ modifier keys and a character from the right-hand home row:

Here’s how they map visually to the VS Code UI:

These keybindings have been very helpful to me in building the muscle memory of agentic coding. I’m slightly proud of them, because I make use of keybinding contexts to get the toggling behavior that feels most intuitive, so a given shortcut opens a view if it is not already open, but closes it if it already is visible. If you’d like to use them, you can copy the following config into your VS Code, Cursor, or Windsurf keyboard shortcuts (Cmd-Shift-P > Preferences: Open Keyboard Shortcuts (JSON)):

  {
    "key": "cmd+alt+h",
    "command": "workbench.view.scm",
    "when": "!sideBarFocus || !(activeViewlet == 'workbench.view.scm')"
  },
  {
    "key": "cmd+alt+h",
    "command": "workbench.action.toggleSidebarVisibility",
    "when": "sideBarFocus && activeViewlet == 'workbench.view.scm'"
  },
  {
    "key": "cmd+alt+j",
    "command": "workbench.panel.markers.view.focus",
    "when": "!panelVisible || activePanel != 'workbench.panel.markers'"
  },
  {
    "key": "cmd+alt+j",
    "command": "workbench.action.togglePanel",
    "when": "panelVisible && activePanel == 'workbench.panel.markers'"
  },
  {
    "key": "cmd+alt+k",
    "command": "workbench.debug.action.focusRepl",
    "when": "!panelVisible || activePanel != 'workbench.panel.repl'"
  },
  {
    "key": "cmd+alt+k",
    "command": "workbench.action.togglePanel",
    "when": "panelVisible && activePanel == 'workbench.panel.repl'"
  },
  {
    "key": "cmd+alt+l",
    "command": "workbench.action.terminal.focus",
    "when": "!panelVisible || activePanel != 'terminal'"
  },
  {
    "key": "cmd+alt+l",
    "command": "workbench.action.togglePanel",
    "when": "panelVisible && activePanel == 'terminal'"
  },
  {
    "key": "cmd+alt+;",
    "command": "workbench.action.toggleAuxiliaryBar"
  },

The future

Developer tools are in a weird state right now, with some claiming you need a special AI IDE to fully leverage LLMs while others are saying the IDE is already dead. In my own day-to-day experience, I’ve found what works for me in practice is a bit more nuanced:

• I generate more than 90% of my code through the agent.
• I still rely on the editor for the rich diff view and diagnostics, which enable my human brain to review and grok the generated code.
• I’ve found most of the UI for AI IDEs and RAG assistants to be unnecessary with agentic coding (and often a distracting crutch), so I just install Amp into vanilla VS Code with Copilot disabled.
• I use CLI agents in tmux for tasks that are easier to fully automate and parallelize.

No doubt the UX of coding agents will continue to evolve with the capabilities of models and more innovation in the application layer. It’s a good time for all developers to be actively exploring new tools and ways of working. If you’ve found your own new workflows or patterns that work well for you, I’d love to hear about them.