In practice: GitHub shows you how to get the most out of the harness — a clear, repeatable 8-step workflow
- Every day brings a new MCP, a new skill, a new workflow — you can't keep up. The GitHub Blog's July 27 post says stop chasing. Master the AI coding tool you already have and you'll get better results.
- Author Burke Holland does developer advocacy at GitHub and Microsoft, focused on GitHub Copilot, and has led dev-tool advocacy teams. He's sharing the eight-step process he runs every day, using only Copilot's built-in features.
- Before writing any code, he has the AI generate 20 prototypes on a single page for comparison — even for something invisible like "add an API endpoint." His reasoning: you don't know what you want until you see it.
- The final gate is a model from another company critiquing the work: he writes with GPT-5.6 Terra, and Copilot calls in Claude Sonnet to review. Different training data means different blind spots.
- He recommends full-permission mode, but only inside a sandbox: AI investor Matt Shumer once enabled it on his own Mac. A misparsed environment variable led to a recursive delete command that wiped out nearly everything in his home directory.
- The "mostly" in the original title, The harness is all you need (mostly), matters: he installed two skills for this very article — one to grill the plan, one to anchor the design.
The 8-Step Workflow GitHub Lays Out, Walked Through with a Date Picker
The GitHub Blog just published an unusually practical guide to AI-assisted development. It addresses a very real problem: don't let the endless stream of new AI tools, elaborate prompts, and clever tricks make you anxious. What actually makes you dramatically more productive is knowing your harness inside out.
Author Burke Holland does developer advocacy at GitHub and Microsoft, focused on GitHub Copilot. Using "build a date picker component from scratch" as his example, he lays out a clear, repeatable eight-step workflow built entirely on Copilot's built-in features — nothing new to install.
Here are the eight steps he runs daily. Click through the tabs to see what each one does:
Pick an entry point — beginners should start with the CLI
The entry points are converging on a single harness. Learn it once, use it everywhere.
Turn off the approval prompts — but only inside a sandbox
No autonomy, no productivity. But full permission demands an isolated environment.
/allow-all (alias /yolo)
Ask for 20 prototypes on one page
You don't know what you want until you see it.
Give me 20 mocks for a date picker web component…
Enter plan mode and let it surface the edge cases
Vague requirements are fine — that's exactly what this step is for.
/plan Build a date picker web component…
Approve the plan and let Autopilot run it
A built-in loop that keeps the model working until every item on the plan is done.
Review it yourself — don't accept "good enough"
What comes out usually isn't what you want. Your taste sets the quality bar.
Bring in a model from another company to critique it
Different training data means different blind spots.
Perform a rubber duck review on…
Commit — and start a new session when you change topics
Keep sessions focused on one subject. When you've drifted too far, it's time to switch.
Step 1: Pick an entry point — beginners should start with the CLI
The GitHub Copilot family alone has a pile of entry points: the CLI, the new GitHub Copilot desktop app, VS Code, Visual Studio, JetBrains — and that's just a few.
Here's the good news: these entry points are converging on a single harness. The details differ, but the core flow is the same: learn it once, use it everywhere.
For beginners, he recommends the CLI. The reasoning: to learn the harness, get as close to it as possible. The terminal is pure text — no UI to learn. You type a line, the agent works, and the interaction is more direct and immediate. His words: "Honestly, it's just more fun."
For this demo, he used the new GitHub Copilot desktop app. It's built on top of the Copilot CLI and runs on macOS, Linux, and Windows. Its big feature is running multiple agent sessions at once, each in its own git worktree and branch, without interference. There are three session modes, which map neatly to the steps ahead:
| Session mode | Who's in charge |
|---|---|
| Interactive | Back and forth — it acts, then waits for your input |
| Plan | It proposes an implementation plan; you review and approve |
| Autopilot | You step back; it runs step by step until the task is done |
Step 2: Turn off the approval prompts — but don't do it on your own machine
YOLO mode (you only live once — the programmer's "screw it" shrug), officially called Allow All, varies a bit by tool. Usually you just type /allow-all in the chat; /yolo is an alias for the same command. Once it's on, the agent runs whatever commands it wants, no more step-by-step asking.
His argument for turning it on: the agent needs autonomy before you'll see a real efficiency gain. If you have to approve every action, you might as well do it yourself. And sitting there clicking "approve" all day is a miserable experience. Worse, click enough times and you train yourself to approve without looking — at which point the approval gate is pointless.
He then drops a link to a July 10 tweet. Matt Shumer is an active AI investor and former CEO of the AI writing product HyperWrite. He was running GPT-5.6 Sol on his own Mac. While the agent was doing a file cleanup task, it assembled a recursive delete command (rm -rf) that wiped out nearly everything in his home directory.
I'm angry… the OpenAI team is looking into this, but stuff like this should have happened with GPT-3.5, not a frontier model in mid-2026 running at the highest reasoning tier.
Matt Shumer, 2026-07-10
His conclusion: YOLO is fine — just not on your machine. Especially at work, where data lives on corporate systems and a mistake is expensive. If you're going to do it, use a sandbox: an isolated, disposable environment where a wipe won't touch your own files. Easiest options are GitHub Codespaces (cloud dev environment) or a dev container (a container-isolated environment on your machine).
Four permission levels, from read-only to full auto
This is the layer that decides whether you save time without losing sleep. The Copilot CLI doesn't ask about everything by default: read-only operations — searches, reading files, running read-only commands — are auto-approved. The things that need a nod are system-changing actions: destructive commands, writing files, hitting URLs.
Between "ask every time" and "full auto" there are a few more rungs: