Skip to main content

Continuous AI lands in VS Code too

Yesterday I wrote about Automations in the GitHub Copilot app as a hands-on example of Continuous AI — recurring, event-triggered AI tasks running in the background instead of you kicking them off by hand every time.

The inkt is not evey dry, or the same concept landed in the latest VSCode release: the VS Code Agents window now has its own Automations feature (still in preview at the moment of writing this post). Let's take it for a spin.

Turning it on

Automations live in the Agents window sidebar. Two prerequisites:

  • Have the Agents window set up with an available agent.
  • Enable the chat.automations.enabled setting.

Creating one

  • In the Agents window sidebar, select Automations, then Create Automation — or start from one of the templates under Start with a template, which pre-fills a prompt and schedule for you.


  • Give it a Name and write the Prompt. Be specific about scope and expected output. Straight from the docs, a solid example: 
Review all the commits I did the last time I worked on this repository. Summarize them by feature and present them in a nice overview. Do not modify files.
  • Choose the workspace the agent should work in, or No workspace for a task that doesn't touch project files. For Git workspaces, you can select New Worktree with a base branch if the agent supports isolation. That worktree option is a nice touch: your recurring automation gets its own branch to work in instead of poking at whatever you happen to have checked out.
  • Pick an agent and review the Session configuration: model, permissions, and session mode (Interactive, Autopilot, Plan).

  • Set Schedule to Manual first and Create.


    Check before you schedule

    Click Run now on the automation card. It starts a session, and the run shows up under History. Open it, read the response, check any changes before you trust it. 

    Only once that first run looks right do you go back in, pick a real Schedule, and save. Compared to the Copilot app, the schedule options here are simpler: Manual, Hourly, Daily, or Weekly with a day and time. No CRON expression, no issue or pull request triggers, this is time-based only, at least for now in preview.


    A few operational details are mentioned in the documentation that are worth knowing before you rely on this:

    • The machine (or Agent Host process) running the automation needs to stay available. Don't assume a local automation survives you closing VS Code.
    • Miss a scheduled run because your machine was off? You might get a catch-up run, but don't count on every missed occurrence being replayed.
    • One automation runs one session at a time. A new scheduled tick doesn't stack a parallel run on top of one still going.

    Managing them

    Editing, disabling, and deleting are all on the automation card or its name:

    • Edit the prompt, target, session config, or schedule anytime.
    • Disable by clearing Enabled. The automation stays, just stops firing, until you flip it back on.
    • Stop a run in progress from History. Disabling doesn't stop something already running.
    • Delete removes the automation and its run history for good.

    Where this sits

    This is the same Continuous AI shape I wrote about with the Copilot app, just moved one layer closer to where the code actually lives. No context switch to a separate app; the automation and the session it produces both live right there in the Agents window, next to the worktree it worked in.

    It's still preview, the trigger model is narrower than the Copilot app's, and the docs are upfront that things might change before general availability. Worth trying on something low-stakes first (e.g. a daily commit summary is a good, safe place to start) before you hand it anything that touches production code unattended.

    More information

    Labels:

    Popular posts from this blog

    Podman– Command execution failed with exit code 125

    After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...
    Read more

    Cache stampede: when our cache turned against us

    While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...
    Read more

    VS Code Planning mode

    After the introduction of Plan mode in Visual Studio , it now also found its way into VS Code. Planning mode, or as I like to call it 'Hannibal mode', extends GitHub Copilot's Agent Mode capabilities to handle larger, multi-step coding tasks with a structured approach. Instead of jumping straight into code generation, Planning mode creates a detailed execution plan. If you want more details, have a look at my previous post . Putting plan mode into action VS Code takes a different approach compared to Visual Studio when using plan mode. Instead of a configuration setting that you can activate but have limited control over, planning is available as a separate chat mode/agent: I like this approach better than how Visual Studio does it as you have explicit control when plan mode is activated. Instead of immediately diving into execution, the plan agent creates a plan and asks some follow up questions: You can further edit the plan by clicking on ‘Open in Editor’: ...
    Read more