Beyond Copilot

Copilot was the right starting point for this chapter. It is bundled in VS Code. The four gears (completion, chat, edit, agent) sit inside the same window, and a free Student tier is one form away. Those four gears cover what AI coding tools are. This page is about the rest of the ecosystem around them, which we did not need for the Wordle project. It is worth knowing what is out there even if you do not use any of it today.

There were moments in this chapter where you encountered Copilot’s limitations. When you asked Copilot to expand the test suite, it ran pnpm test without checking that watch mode would hold the terminal forever. It did not read your package.json scripts before deciding what command to use. When you turned it loose in agent mode for the word-validation feature, it edited game.tsx for a styling change you did not ask for. Neither of those was catastrophic, and both got resolved with a small correction in chat. But each one is a version of the same underlying issue: the agent is making decisions about what to read, what to run, and what to change, and you do not have many levers for shaping those decisions ahead of time.

A lot of what is happening in AI tooling right now is people building those levers.

Agentic CLIs

The first thing to know is that the agent does not have to run inside your editor. Anthropic’s Claude Code, OpenAI’s Codex CLI, and a growing list of similar tools run in a terminal as a regular command, claude or codex, and treat your project root as their working directory. You start one, type a prompt in the terminal, and the agent reads files, runs commands, edits code, and iterates the same way Copilot’s agent mode does, except the loop is happening at the shell rather than inside a VS Code panel.

Day to day the difference is small, but it changes what you can do with the agent. When the agent is a CLI, it composes with the rest of your shell: you can pipe output into it, run it inside tmux, hand it a script, hook it into CI. It also tends to handle longer-running tasks better than a Chat view, which is built to answer quickly.

Harness Engineering

You can also configure a lot around the agent, before you send it any prompt at all. People call this harness engineering: setting up the environment the agent runs in.

Concretely, that includes:

  • A project-level instructions file (Claude Code calls this CLAUDE.md) that lives at the root of your repo and gets read on every run. It tells the agent your stack, your conventions, the commands you use, and the rules you want it to follow. The agent does not have to guess; you have written it down.
  • Skills — reusable bundles of instructions the agent can invoke for specific tasks (“write a course note,” “review a PR,” “set up a test harness”). Each skill knows what files it cares about, what tools to call, and how to do its job.
  • Hooks — shell commands the agent’s runtime executes automatically at specific moments (before a tool call, after a session, when the agent stops). You can use them to validate, format, log, or gate.
  • Permissions and settings — explicit allowlists for which commands the agent can run without asking, and which it cannot run at all. This is a more advanced version of Copilot’s “Bypass Approvals” toggle.

If you install one of these CLIs and look at how experienced users have set theirs up, you will typically find a .claude/ (or equivalent) folder at the project root containing a handful of skill files, a CLAUDE.md with project conventions, and a settings.json with hooks and permissions wired up. None of that is required to use the tool, the same way none of .eslintrc or .prettierrc is required to write JavaScript. But once you have used an agent for a while, the value of being able to say “always run the build after editing a file” or “before answering, check if there is an existing memory about this project” gets obvious quickly.

MCP

The last piece is MCP, the Model Context Protocol. Once an agent can run commands, the next question is what else it is allowed to reach. MCP is a small open protocol (originally from Anthropic) that lets a tool author write a server exposing files, APIs, databases, or anything else, and lets an agent connect to that server as a client. The agent gains access to your team’s wiki, your task tracker, your design tool, your local Postgres — without anyone hardcoding any of those into the agent.

You do not have to write your own MCP server to use one. There is a growing ecosystem of pre-built ones (GitHub, Linear, Slack, Postgres, Playwright for browser automation, and many others), and the agent picks them up the same way an editor picks up extensions.

Context Engineering Again

All of these are the same idea we kept coming back to in this chapter: context engineering. Each one is a way of putting the right thing in the agent’s view. #file: does it by hand, for one request. CLAUDE.md does it for every run in a project. A skill does it for one kind of task. An MCP server does it for a system the agent could not otherwise reach. The names and the surfaces change, but the problem is the same one: get the model to see what it needs to see, and not much else.

Wordle did not require any of this because the project is small, single-language, and frontend-only, and Copilot is configured well enough by default for that case. On bigger codebases, with more services, stricter conventions, and real production constraints, you will hit the limits sooner, and the levers above are how you deal with that.

Tools in this space change every few months. Which CLIs, IDEs, and harnesses are ahead by the time you read this will not be the same as when I wrote it. What lasts is the way of working you have been practicing: describe clearly, attach the right context, review what comes back, and verify it works.