Cooking with Agents in VS Code

Can one prompt create an entire application and solve all its problems? That expectation is the starting problem. Agents now appear in terminals, CLIs, chat windows, and editors, adding choices and cognitive load before they deliver useful work. Liam Hampton connects those expectations to the questions businesses ask next: where are the productivity gains, what is the return on investment, and when does spending on infrastructure and services produce a benefit? Using an agent deliberately starts with understanding the work you are handing over.

Token spending is another concern, distinct from overall productivity. Hampton recounts seeing an unidentified repository on LinkedIn that claimed pirate-style chatbot speech reduced token use. He supplies no measurement; the anecdote captures how actively developers are experimenting with cost. The more practical investigation here is what agents can access in a workspace, how they operate, and how to use them through VS Code and the CLI. Those questions apply beyond GitHub Copilot.

A local agent works alongside you in VS Code. Local describes the interaction and workspace, not necessarily where inference happens: the agent can use a remote model or a locally hosted model. The defining feature is close, ongoing developer participation.

A background agent, here provided by GitHub Copilot CLI and accessible within VS Code, works more independently. Its changes live in a Git worktree: a separate working directory attached to the same repository. In this workflow, that directory has its own branch. A worktree need not be a subdirectory, and Git also supports worktrees with a detached HEAD. This separates working files without requiring a separate repository.

A cloud agent moves execution onto remote infrastructure using GitHub services. Hampton uses it for work he wants to supervise less closely, such as documentation. The three environments therefore offer different ways to participate, rather than three levels of model intelligence.

Tests stay local because Hampton wants to understand what they cover. Front-end implementation gets a background agent because repeated interaction can become arduous; he introduces Autopilot for that assignment. Documentation—README files and open source preparation, potentially using skills—goes to the cloud. His description of background work as fifty-fifty is a qualitative balance of involvement. VS Code supplies one entry point for these environments and third-party agents, reducing the need to manage each through a different interface.

The recorded walkthrough starts with a plain Python product store supporting create, read, update, and delete. Hampton uses a prerecorded build to fit the session. The application works, but its presentation needs attention, so GitHub issue 25 requests a better front end. He selects a CLI background agent and asks: “Summarize and plan a solution to issue 25.” Planning comes before implementation.

The background agent can iterate without Hampton watching every action. He enables Autopilot, described as a preview feature in the recording, to avoid repeated approval questions for tool calls, including MCP calls. He also warns that this can be dangerous. Once the plan is ready, he authorizes implementation with a boundary: stop before creating a pull request and let him test locally. The useful delegation includes both the assignment and the point at which control returns to the developer.

With the front-end assignment running, Hampton opens another chat and starts a cloud agent. This repository lacks the supporting files expected of an open source project, so he requests a README, contribution guidelines, and the other necessary documentation. That assignment can proceed while he returns to the code.

The next missing piece is tests. An existing custom agent contains guidance for writing tests for this Python application. Hampton selects a local session, chooses Claude Opus 4.6 with medium reasoning for speed, and asks it to write unit tests. He can inspect the work as it proceeds while the cloud agent prepares documentation and the background agent builds the front end.

The local agent writes and runs tests, and Hampton reports that they pass. Inspection then reveals a different problem: the route errors are unfriendly. He asks the agent to update both the route error handling and its tests. Passing tests do not end the interaction; they create a checkpoint from which the developer can identify behavior that the original request did not address.

For a Python product store, that paired change can be expressed with a small error contract and a test for it. Here is an illustrative missing-product example using Python’s standard library:

import unittest


def get_product(products, product_id):
    product = products.get(product_id)
    if product is None:
        return {"error": "Product not found"}, 404
    return product, 200


class ProductErrorTests(unittest.TestCase):
    def test_missing_product_has_a_clear_error(self):
        body, status = get_product({}, "missing")
        self.assertEqual(status, 404)
        self.assertEqual(body, {"error": "Product not found"})


if __name__ == "__main__":
    unittest.main()

The behavior and its expectation change together. In the walkthrough, this close feedback loop remains local while the other assignments continue independently.

Hampton next checks the running assignments. Updated code and tests appear; the background assignment is reported finished, and the local tests pass. He remarks that some footage was not sped up, but the walkthrough supplies no timed speedup comparison. VS Code keeps the sessions visible together, so he can move between closely supervised work and delegated work without leaving the editor.

The pull request extension shows a documentation pull request from an earlier run. The cloud chat started during this walkthrough is still taking time. That distinction matters: the displayed pull request demonstrates the review path, not completion of the current cloud assignment.

The background agent has respected the requested pause before a pull request, but its initial instructions for testing are wrong. Hampton reminds it that the application is in a Git worktree. The local validation sequence is then:

1. Identify the separate worktree containing the generated front end.
2. Enter that directory and run the Python application there.
3. Resolve the port conflict that interrupts startup.
4. Open the resulting Product Store UI and inspect the change.

The distinction between directories is operational: running the original checkout would not show the agent’s isolated changes. Once startup succeeds, the browser preview shows a styled Product Store with name and description fields, an Add product button, and an empty product list.

Hampton also demonstrates new error checking, then recaps the division of labor: local tests for close involvement, a background front end for more independent implementation, and cloud documentation for a longer handoff. The application has been exercised locally; the recording does not show a final merge or production deployment.

Cloud agents run in isolated GitHub Actions environments. Hampton raises cost as a common question, but the explanation that follows concerns execution and capabilities, without a price or billing calculation. MCP servers extend the agent’s tools and context: GitHub access supports repository work, and Playwright supports screenshots and automated front-end testing. He also mentions workflow authoring and dynamic workflows.

Hampton describes network allowlists and restrictions on direct pushes to main as safeguards. These constrain an agent’s actions; they do not establish blanket safety. Current documentation, which postdates the demonstration, makes the boundaries more precise: built-in MCP defaults give GitHub repository-scoped read-only tools and Playwright localhost access; the firewall excludes MCP servers and setup-step processes. The branch restrictions govern where the agent can push, not whether it can read the default branch. Human review and testing remain necessary.

The custom test agent is one of several ways to supply repeatable guidance. Hampton introduces four building blocks that also have counterparts in other agent tools:

• Custom instructions define how the agent should operate.
• Custom agents specialize behavior for an assignment, such as writing or fixing tests.
• Prompt files make useful prompts reusable.
• Agent skills package task-specific guidance and resources.

Hampton compares skills to a newer version of AGENTS.md. Treat that as an analogy: Agent Skills use SKILL.md directories, can include scripts and resources, and load on demand. They complement standing instructions rather than simply replacing them.

The interface tour brings those pieces into one place. Hampton opens the GitHub Copilot chat pane and clicks its cog to reach the customization interface. The agent list contains his custom test agent and the built-in Ask, Explore, and Plan entries. Supplied, editable skills include addressing a pull request comment and creating a pull request.

Instructions and prompts have their own entries; creating an agent is one prompt example, and prompts can initiate skills. Hooks and MCP servers are configurable too, although this workspace has no instructions or hooks configured. The same interface also exposes Claude customization, including plugins, hooks, instructions, and skills. It is a place to inspect and configure the agents’ behavior, not just a menu for starting chats.

Awesome Copilot provides an open source starting point for customizations. Its material targets Copilot, but Hampton encourages adapting it for other AI tools. He also describes an MCP server for accessing the project from a workflow.

MCP, the Model Context Protocol, connects models and agent workflows to additional tools and services. Hampton uses Azure, GCP, and AWS resources as examples of authenticated access. He contrasts these with tools and documentation servers that can be used without authentication, including Playwright and Microsoft Learn. The authentication requirements depend on the service being exposed.

The closing capability list returns to VS Code as the shared entry point: first-party and third-party plugins, chat customization, what Hampton describes as full MCP specification support, and connections to GitHub Copilot CLI sessions. Together, these let the developer manage different execution environments within the same workflow. Hampton ends by inviting discussion of how others organize their agent work—the central design choice throughout the demonstration is how much involvement each assignment needs.