Master the harness: GitHub's clear, repeatable 8-step workflow
- New MCPs, skills, and workflows drop every day—you can't keep up. GitHub's official blog put it plainly on July 27: stop chasing. Master the AI coding tool you already have—you'll get more out of it.
- Author Burke Holland does developer advocacy at GitHub and Microsoft, focused on GitHub Copilot, and has led developer tools advocacy teams. He shares the eight-step flow he runs every day, using only built-in Copilot features.
- Before writing code, he has the AI spit out 20 prototypes on one page to compare—even invisible work like "add an API endpoint" gets a diagram first. His reason: you won't think about what you never see.
- The last gate is another company's model poking holes: he codes with GPT-5.6 Terra; Copilot automatically calls Claude Sonnet to review. Different training data means different blind spots.
- He recommends full-permission mode—but only in a sandbox. AI investor Matt Shumer tried it on his own Mac; a misparsed env var and one recursive delete nearly wiped his home directory.
- The original title, "The harness is all you need (mostly)," ends with a mostly that matters: in this same post he installed two skills—one to grill a plan thoroughly, one to set the design tone.
GitHub's eight-step workflow, demonstrated by building a date picker
A practical AI developer workflow guide from GitHub's official channels. It targets a real anxiety: getting lost in the daily flood of new AI tools, elaborate prompts, or shiny tricks. What actually multiplies output is mastering the harness.
Author Burke Holland does developer advocacy at GitHub and Microsoft, focused on GitHub Copilot. Using "build a date picker component from scratch" as the example, he lays out a clear, repeatable eight-step workflow—all with built-in Copilot features, nothing extra to install.
These eight steps are the flow he runs every day. Tap a tab for what each one does:
Pick an entry point; beginners start with the CLI
Surfaces are converging on one harness—learn once, use everywhere.
Turn off approve buttons; run in a sandbox
No autonomy, no speedup—but full power needs isolation.
/allow-all (alias /yolo)
Ask for 20 prototypes on one page
You only know what you want once you see it.
Give me 20 mocks for a date picker web component…
Enter plan mode; let it surface edge cases
Vague requirements are fine—that's what this step fixes.
/plan Build a date picker web component…
Approve the plan; hand it to Autopilot
A built-in loop that keeps the model going until every plan item is done.
Human review—don't accept "good enough"
What it ships is rarely what you wanted; your taste sets the quality bar here.
Call another company's model to poke holes
Different vendors, different blind spots.
Perform a rubber duck review on…
Commit; new topic means a new session
Sessions should be topic-scoped—when the chat drifts, start fresh.
Step 1: Pick an entry point—beginners start with the CLI
The GitHub Copilot family alone has a stack of surfaces: the CLI, the new GitHub Copilot desktop app, VS Code, Visual Studio, JetBrains—and that's just a sample.
The good news: those surfaces are converging on the same harness. Details differ, but the core flow is identical: learn once, use everywhere.
His advice for beginners is to start with the CLI. To learn the harness, get as close to it as you can. The terminal is pure text—no UI surface to study. You type a line, the Agent works. The loop is more direct and immediate; in his words, "honestly pretty fun."
For this demo he used the new GitHub Copilot desktop app. It sits on top of the Copilot CLI and installs on macOS, Linux, and Windows. The headline feature is several Agent sessions at once, each in its own git worktree and branch so they don't collide. Session modes come in three flavors, which map cleanly to the steps below:
| Session mode | Who's in charge |
|---|---|
| Interactive | Back-and-forth—it takes a step, then waits for you |
| Plan | It drafts an implementation plan; you review and approve |
| Autopilot | Hands off—it chains steps until the task is done |
Step 2: Kill the approve buttons—but not on your own machine
YOLO mode (you only live once—dev slang for going all-in) is officially Allow All. How you enable it varies by tool; most of the time you just type /allow-all in chat. /yolo is the same command under another name. Once it's on, the Agent runs whatever commands it wants without asking at every step.
He insists on turning it on for one reason: the Agent needs autonomy before you see real speed gains. If every action needs an "Approve" click, you might as well do the work yourself. Sitting there clicking Approve all day is miserable. Worse, after enough clicks you stop reading and just approve—so the gate becomes theater.
He then links a July 10 tweet. Matt Shumer is an active AI investor and former CEO of the AI writing product HyperWrite. He ran GPT-5.6 Sol on his own Mac. While cleaning up files, the Agent assembled a recursive delete (rm -rf) and nearly wiped everything in his Mac home directory.
I'm pretty mad… OpenAI is looking into it, but this feels like something that should have happened with GPT-3.5—not mid-2026, on a frontier model at the top reasoning tier.
Matt Shumer, 2026-07-10
So his conclusion: YOLO is fine—just not on your local machine. That goes double at work, where org data lives and the blast radius is large. If you enable it, use a sandboxA disposable environment isolated from your machine—if everything inside gets wiped, your real files stay safe.. The easiest on-ramps are GitHub Codespaces (cloud dev environments) or a dev container (a containerized workspace on your machine).
Four permission tiers, from read-only auto-pass to full auto
This layer is what lets you move fast without getting burned. Copilot CLI does not block everything by default: read-only work—search, read files, run read-only commands—already auto-passes. What needs your nod is any action that changes the system: destructive commands, writing files, hitting the network.
Between "ask every step" and "full auto," there are a few more tiers: