GitHub has planted a flag in the middle of the AI-tooling arms race, and it points away from the hype. In an essay published July 27 titled “The harness is all you need (mostly)”, GitHub’s Burke Holland argues that the biggest productivity gains with AI coding agents come not from prompt tricks, skill registries, or MCP servers, but from understanding and using the harness — the layer of software wrapped around the model. His claim is blunt: “You do not need any of those things to be highly successful with AI.” What you need, he says, is a simple, repeatable workflow built on features GitHub Copilot already ships.
That is a notable message from the company that operates one of the largest ecosystems where skills and custom agents are traded. It is worth unpacking both the workflow itself and what GitHub is signaling by publishing it.
What GitHub means by “harness”
Holland uses “harness” interchangeably with GitHub Copilot itself: Copilot, in his framing, is an agent harness — the scaffolding that manages context, tools, permissions, planning, and execution loops around whatever model you pick. The essay’s practical corollary is that GitHub is centralizing its many surfaces — the Copilot CLI, the new GitHub Copilot app, VS Code, Visual Studio, and JetBrains IDEs — on the same underlying harness. “Learn the harness once, use it everywhere,” as he puts it.
For newcomers, Holland recommends starting with the CLI precisely because it is the thinnest wrapper: a terminal interface with almost no UI to learn, where the interaction with the agent is most direct. The essay’s demonstrations, however, use the Copilot app, and the harness behavior is the same across both.
This convergence matters more than it might appear. When every surface shares one harness, the workflow knowledge you build in the terminal transfers intact to the IDE and back — and the harness, not the editor, becomes the durable skill. That is a meaningful shift for teams standardizing AI tooling across members who work in different editors, because the training investment stops fragmenting by tool choice.
The workflow, step by step
The essay lays out an eight-step loop. Condensed, it runs like this:
Grant autonomy — inside a sandbox. Turn on “Allow All” (Holland calls it YOLO mode, typically an /allow-all command) so the agent can execute commands without per-action approval. His reasoning is ergonomic and psychological at once: approving every action erases the productivity gain, and pressing “Approve” repeatedly “just trains you not to read what you are being asked to approve.” The hard caveat: never run an unrestricted agent on your local machine, especially at work. GitHub Codespaces or development containers are the suggested sandboxes.
Prototype before you build. Because generation is nearly free, Holland front-loads visual prototypes — his example prompt asks for “20 mocks for a date picker web component” in a single HTML file. The point is discovering requirements you would not have articulated: one generated mock started with a year view, which reshaped the design he actually wanted. This applies to non-visual work too; for a new API endpoint he has the agent produce Mermaid diagrams (which the Copilot app renders natively) mapping five implementation options.
Plan methodically. Copilot’s plan mode (/plan) interrogates the task the way a senior engineer would — asking about edge cases like whether a date range can be empty, whether manual entry is allowed, what format dates are stored in. Holland stresses that rubber-stamping the plan negates its value: “The point is for you to deeply engage with the problem and guide the model.” For a more aggressive interrogation, he points to the community “grill-me” skill from Matt Pocock.
Implement with Autopilot. Autopilot is Copilot’s built-in execution loop: it forces the model to keep working until every item in the plan is verifiably done. Under the hood, the harness orchestrates automatically — routing file exploration to an “Explore” subagent running a small model and complex actions to a “General Purpose” subagent on a larger one. Holland’s point is that users get subagents and multi-model workflows out of the box “even if you did not know that any of these things existed.”
Review, iterate, and insist on quality. The first output will be flawed — his date picker had contrast bugs, redundant labels, and “looked a little too much like it was created by AI.” The remedy is conversational iteration, and taste: “The most important thing is not to settle for AI output that is ‘good enough.’ Insist on quality. Be ruthless about it.”
Rubber duck across model families. Before committing, Holland requests a “Rubber Duck review,” in which Copilot asks a model from a different AI family to critique the work — in his run, GPT 5.6 Terra’s output was reviewed by Claude Sonnet. Different training data means different blind spots, so the cross-review catches issues a single model misses. It can even be looped with Autopilot until both models agree only diminishing returns remain.
Then commit, and start a fresh chat session for the next task — sessions, he argues, should stay topical.
The token economics buried in the advice
Two of the essay’s recommendations are really cost-management guidance. Holland suggests a medium-sized model — he names GPT 5.6 Terra and Claude Sonnet — on medium reasoning for most work, and, less intuitively, sticking with one model for the duration of a feature. The reason is prompt caching: as long as you do not switch models or reasoning levels, previous chats remain cached with the model and subsequent requests are discounted. Model-hopping mid-task quietly resets that discount. The rubber-duck loop, he concedes, costs extra tokens, but he frames it as “an investment in your future self” — edge cases caught now instead of in production.
A quiet argument against the skills arms race
The most pointed passage in the essay is about ecosystem hygiene. “There is a lot of slop out there,” Holland writes, noting that an agent will happily generate a skill for anything at all, and that whether or not it works, “it can be easily published to any number of skill or MCP registries.” From the company whose platform hosts much of that ecosystem, that is a striking admission — and a useful filter for open-source builders deciding where to spend attention.
The “mostly” in the title is doing honest work, though. Holland is explicit that skills, MCP servers, custom instructions, and custom agents “will become quite important as you progress and need to define complex workflows and automate things for your teams” — he uses several in the post itself, including a skill pointing at his own Postrboard CSS framework to give the agent design guidance. The claim is not that the extension ecosystem is worthless; it is that it is optional at the start, and that fundamentals beat configuration.
His closing line captures the essay’s real thesis about a field moving too fast for cargo cults: “A lot of what is today’s magical incantation for AI will be tomorrow’s anti-pattern. Just focus on getting a repeatable, high-quality result in the simplest way that you can.” For developers exhausted by the weekly churn of new agent frameworks, that is unusually grounded advice from a vendor — learn the loop, not the lore.
