Why I Built AgentLink, a Coding Agent Harness for VS Code

The tools are becoming part of the craft

A carpenter doesn't become less of a carpenter because they care about their chisels. They tune their tools and arrange their workshop around the quality of the work they want to produce.

I think software engineers are entering an artisan stage with AI. The models can write a remarkable amount of code, but the quality of the result still depends on the environment they work in and the judgment applied along the way. If every engineer has access to capable models, the advantage isn't just using an agent. It's knowing where it needs context, when to intervene, and which parts of your workflow are worth turning into tools.

That's why I built AgentLink. It's a coding agent harness that lives in VS Code. I wasn't trying to build another model or replace my editor. I wanted the agent I use every day to work in a way that matches how I actually engineer software.

What I was missing from the agent workflow

I wrote before about AI-directed development versus vibe coding. My distinction wasn't whether an agent writes the code. It was when I get to shape the decisions behind that code. On work I'll maintain, I want to catch a wrong assumption early, not reconstruct it from a finished pull request.

The awkward part is that many agent workflows make this harder than it needs to be. An agent meets the repo as a pile of files, makes changes somewhere else, then hands back a large diff. A command might run without much visibility. By the time I see the result, several decisions have already compounded. You can still review it, but now you're doing archaeology.

I wanted a tighter loop: understand the code, propose a change, see it in the editor, redirect if needed, and keep moving. That isn't a rejection of autonomy. It's a way to make autonomy useful without giving up ownership of the outcome.

Why I stayed in VS Code

When I built this site with an AI agent, I still reviewed the files, made the design calls, and stayed responsible for what shipped. I liked the acceleration, but I didn't want to give up the place where I already understand and work on the code.

VS Code knows more about a project than a shell command reading text. Language tooling can show definitions, references, types, symbols, and diagnostics. AgentLink gives the agent access to that information, so it can reason about a change with more than a search result and a guess. When it edits a file, the proposal opens as a native diff that I can accept, reject, or adjust. Commands run in a terminal I can see.

This isn't about insisting on a human click for every line. It's about preserving the editor as the place where both of us can see the work. I can use my extensions, inspect a call site, notice an error, or change direction while the context is fresh. I don't have to switch to a new editor or an opaque remote workspace to get help from an agent.

What makes AgentLink different to me

Plenty of agents can search code, edit files, and run tests. I wouldn't claim those abilities are unique. The difference I'm building toward is how they fit together for real work:

• The editor is part of the agent's working environment. Language server navigation and diagnostics help it understand the project, while VS Code diffs put proposed changes in front of me where I already review code.
• Autonomy is adjustable. I can review risky edits and commands closely, then use focused rules or Approve for Me when a task is well understood. Supervision isn't a choice between approving everything and seeing nothing.
• Work stays visible. Tool calls, questions, approvals, and background agent progress have a place in the same workflow. I can tell whether the agent is reading, changing files, running a command, or waiting for me, instead of staring at a spinner.
• A second opinion can come from another provider. For important changes, AgentLink can route review to a model from a different provider. That doesn't guarantee the reviewer will be right, but it gives me a chance to catch assumptions the first model might share with itself.
• The model isn't the whole product. AgentLink uses the provider accounts I choose, can connect other tools through MCP, and keeps local code retrieval on my machine. The value is in the context, feedback, and control around the model, not a proprietary model hiding behind the interface.

Consider a change to a shared TypeScript interface: the agent can inspect its references in VS Code, then propose a diff I can review while the decision is still small. Diagnostics can catch missed callers as the edits land. That's a much better use of my attention than reviewing a huge patch at the end.

AgentLink isn't finished software with every edge polished. Some capabilities, like best-of-N runs and scheduled automations, are still maturing. The browser view is deliberately narrower than the editor, not a second place to run a shell. Those boundaries matter to me as much as the feature list does.

The extension is the heart, not the only surface

VS Code is where AgentLink does its best work, and that isn't changing. But I don't always want to open an editor to ask an agent something, and plenty of engineers prefer to work from a terminal. Other harnesses have shown there's real value in those experiences, so I've started building supporting surfaces for AgentLink too:

• The desktop app is a standalone Ask Agent chat for macOS. I can ask a question or explore an idea without VS Code open, then switch into my running VS Code sessions from the same window. It's an early, unsigned preview.
• The CLI is a terminal coding agent for people who live in the shell. It's in private preview on macOS for now, and already covers durable sessions, reviewed file writes and commands, MCP tools, background agents, and optional TypeScript language intelligence.
• The browser remote stays what it's always been: a way to supervise sessions from another device, with read-only diffs and no remote shell.

The hard part is doing this without flattening AgentLink into another generic chat box. The things that make it worth using have to travel with it. So each surface is built on the same core rather than a separate reimplementation, and the same rules apply: writes show the complete diff before they land unless I've chosen to grant more autonomy, commands and approvals stay visible, and my accounts, models, and preferences follow me between surfaces.

The CLI is a good example. A terminal agent could easily fall back to text search and trust. Instead, it can use managed TypeScript language intelligence for diagnostics and references, and every write still opens as a full diff in the terminal UI for review. It won't match the editor exactly, but it brings the parts that matter most to the shell.

The extension will stay the most complete experience. The other surfaces exist so AgentLink can meet you where you're working, not so it can become something else.

The artisan stage isn't about building everything yourself

I don't think every engineer needs to make their own coding agent. A carpenter can buy a good chisel and still adapt their workshop to the job. The point is to stop treating the default toolchain as a fixed answer when the work has changed underneath it.

Sometimes that means writing a small script. Sometimes it means improving tests, documenting a convention in AGENTS.md, or building a better review loop. For me, the friction was important enough that it became AgentLink. Building it forces me to be specific about what I expect from an agent: useful context, honest status, changes I can inspect, and control that scales with the risk of the task.

That skill compounds. As models improve, the code they can produce becomes less scarce. The ability to define the problem, build a good working environment, recognise a bad assumption, and stand behind what ships becomes more valuable. I think engineers who invest in their own tools and judgment will be better placed to do high-quality work, not just produce more of it.

The bottom line

In my AI-directed development post, I argued for shaping the solution early rather than cleaning it up late. AgentLink is my attempt to make that practical in the editor I already use. The agent can do more, while I can still see what it's doing and steer it before a small mistake becomes the architecture.

If you're working with agents, look at where your current workflow makes you guess, wait, or review too late.

Fixing even one of those loops might be more valuable than switching to the next model.

If the VS Code approach resonates, take a look at AgentLink, or go straight to the source on GitHub.

---

Have thoughts on this? Join the conversation on LinkedIn.