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:

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:

It gets finer still. --allow-tool='shell(git:*)' --deny-tool='shell(git push)' means "all git commands are fine, just no pushing." One rule to remember: deny rules always override allow rules — even when --allow-all is on.

Step 3: Prototype first — you don't know what you want until you see it

One of the most magical things about AI right now is how cheap early prototyping has become. Prototyping used to be a full project phase, often a luxury. Now it's a single sentence.

Take the date picker component. Sounds simple, but there are a ton of questions waiting: how does navigation work inside the component? What does a selected date look like? What about a selected range? How does the user switch between days, months, and years?

His move: ask for 20 in one sentence.

Give me 20 mocks for a date picker web component. Put them all in an HTML file so I can compare.

All 20 options on one page, with auto-generated categories up top: all 20 / minimal / expressive / range / mobile / contextual. The one on the right is a heatmap of daily busyness as green intensity. Screenshot from the GitHub blog post.

Among the 20 was one that starts from a year view — the "Year at a glance" on the left. He saw it and realized: this is what I want — let users zoom from year to month to day.

These are the kinds of things you don't consider until you see them.

These are the kinds of things you don't consider until you see them.

Humans process images, shapes, and visible layouts far faster than dense text. Low-cost visual prototypes make complex concepts instantly intuitive.

Even the invisible stuff gets drawn first

He needed to add an API endpoint — an interface for programs to call each other. There's no UI to look at. He asked for a visual prototype anyway.

Create a visual mockup of the API for this project. Add five options for how we could handle a new API endpoint that allows the user to download their analytics data.

One task — "download analytics data" — with five approaches laid out on a tree: account-level sync download, per-list sync download, async export job, content negotiation, and custom report submission. Below the diagram, it expanded the first option with a full request example and flagged it as the recommended minimal viable version. Screenshot from the GitHub blog post.

The GitHub Copilot desktop app supports Mermaid diagrams — a way to describe flowcharts in text, where a few lines render into boxes and arrows, so the AI can literally "write" a diagram. It turned the five options into a tree on the spot.

Picking a model: the middle tier, and never switch mid-task

His recommendation: use a mid-tier model for most everyday work — GPT-5.6 Terra or Claude Sonnet — with medium reasoning. The GPT-5.6 generation landed in Copilot on July 9 with three models: Sol (strongest reasoning), Terra (balanced), and Luna (lightest and cheapest). The Terra he recommends is the middle one.

His second piece of advice is worth more: for the same feature or the same bug, don't switch models or reasoning tiers mid-task. The reason is prompt caching — the model keeps your previous conversation cached so the next request is cheaper. Switch models or tiers, and the cache is invalidated. You're back to square one.

Step 4: Enter plan mode and let it surface the questions you didn't think of

Now you know what you actually want, not what you initially thought you wanted. Time for an implementation plan.

No new session needed. Just switch to plan mode.

/plan Build a date picker web component. I want the user to be able to zoom in and out of years, months, and days.

He admits the prompt is pretty vague. That's fine — this step exists precisely for that.

In theory, if you could assemble the perfect prompt, the perfect context, in the perfect order, the model could nail it on the first try. In theory. None of us can. Plan mode gets you closer to that ideal by surfacing, one by one, the questions you'd eventually have to answer if you were doing this by hand.

Here's what those questions look like. Each one decides something concrete:

There's a long tail of questions like these. You can't think of all of them, but the model can surface quite a few.

You can push back, too

The model asks "Which selection modes should the first version support?" with four options: single date (recommended), single date plus range, single date plus range plus multiple non-contiguous dates, and the fourth — "wait, what would non-contiguous date ranges actually look like?" That counter-question is a built-in option, no extra typing required. The top line, "Loaded skill grill-me," shows it loading the grilling skill. Screenshot from the GitHub blog post.

He had a rough idea of what the model meant, but asked anyway to make sure both sides were on the same page. Interjecting with a question doesn't interrupt the planning flow — it just keeps going.

Want it to push harder? Install a skill made for grilling

Install Matt Pocock's grill-me skill — the name means "grill me" — by one of the most well-known TypeScript educators. Chain the two commands together and the questions get far more numerous and far sharper. The skill's job: one question at a time, digging into the plan until you and the agent agree on every branch. (This is the first skill he used in the article.)

/plan /grill-me Build a date picker web component. I want the user to be able to zoom in and out of years, months, and days.

Step 5: Approve the plan and let Autopilot run it

Once the plan is done, GitHub Copilot usually offers to switch to Autopilot to implement it.

The plan summary has six items, from "build a component with no framework dependencies" to "verify all navigation, selection, form, keyboard, responsive, and animation states in the demo page." Two options below: approve and implement with autopilot (recommended), or exit plan mode and do it myself. Screenshot from the GitHub blog post.

Autopilot is a built-in loop. It keeps the model working by checking whether it has actually finished what it said it would — here, every item on the plan.

At this stage, Copilot automatically acts as the orchestrator: when it needs to read files in the codebase, it dispatches "Explore" subagents with a small model; when an action looks more complex, it usually dispatches a "General Purpose" subagent with a large model. If you want fine-grained control, you can use custom agents and custom instructions. But even if you do nothing, you still get the benefit of multiple subagents and models working together — even if you had no idea they existed.

When Autopilot stops

Autopilot stops in four situations: it thinks the task is done, it hits a problem it can't get past, you press Ctrl+C, or it reaches the maximum continuation count you set. That last one is controlled with --max-autopilot-continues, designed to prevent infinite loops. It's especially important in scripts, since you won't be there when things go wrong.

There's also a safety design that explains why the last step and this one go together: in autopilot mode, unless you've explicitly granted full permissions, it can't do anything requiring approval. Without enough permissions, it just keeps hitting auto-denies and never finishes the job.

Step 6: Review it yourself — don't accept "good enough"

This is the fun part: you finally see what the AI made.

But it probably won't be exactly what you wanted. That's normal. The model can't read your mind, and it makes mistakes. You have to go back and forth until it's actually what you want. Whether it's code or UI, your taste sets the quality of the final product.

The first year view: "12 YEARS" at the top, each year in a box with a 1-to-12 number beneath it. Both are things he'd delete moments later. Screenshot from the GitHub blog post.

Four problems he spotted immediately:

He used his own CSS framework, Postrboard — a design system with 40+ components — installed as a skill for the agent. The skill just points to where the CSS lives and how to use it. You don't need his. Pick any CSS framework you like; giving the model some design direction is hugely useful, and often a CSS framework is enough. (This is the second skill he used in the article.)

Then he fired off a string of feedback, completely unedited:

ok - we don't need a landing page here - just the component, output and settings panel in a minimal setting. Use the /postboard skill for the design and colors.

For the date picker, when I click on the day, it tries to zoom in, but can't because there is nothing to zoom to. There should be no zoom there.

It doesn't need to say "Zoom Out" at the top

When I mouse over a month or year that contains the selected day, I cannot read the hover text.

When I click "Today" it should take me to that day view, even if I'm on the month or the year.

The months don't need numbers under them and they don't need to be in boxes

Same goes for years. And it doesn't need to say "12 years" at the top."

(His original text spells the framework name /postboard, missing an "r" — it's actually Postrboard.)

Notice how conversational this is. Don't overthink it. When you're fixing a bunch of small things, just talk to the model. If you have the context, you have the prompt.

Notice how conversational this is. Don't overthink it.

After the revisions: only the component on the left, a live-updating settings panel on the right — view hierarchy, selectable range, which days to disable, all adjustable in real time. The boxes and numbers are gone. Screenshot from the GitHub blog post.

Step 7: Bring in a model from another company to critique it

Once you're happy with the changes, call for a rubber duck review. No special format needed. A plain sentence does it.

Perform a rubber duck review on this date picker component implementation

Here's the mechanic: GitHub Copilot finds a model from a different family than your current session model — in practice, that means a different company. He was using GPT-5.6 Terra, so it brought in Claude Sonnet to review. The logic is simple: different models are trained on different data, so their blind spots differ. A model reviewing itself tends to miss the same things.

The duck looks but never touches — even critique has boundaries

The rubber duck is a built-in agent: read-only, no file changes. It only gives feedback; whether to act on it is up to the main agent and you. Its feedback comes in three tiers: blocking (can't ship without fixing), non-blocking (should fix, usable as-is), and suggestion (low priority, genuinely useful). It's also explicitly told not to nitpick formatting, naming, or comment syntax — things that don't affect the actual problem. If it finds nothing, it says so.

It's not just for the final step. Prototypes can be reviewed, plans can be reviewed — it's up to you where you want a second AI's opinion.

Its best moment is after the plan is done but before any code is written — that's when changing direction is cheapest. Beyond that, three other good moments: mid-implementation to check for blind spots, after tests are written to verify coverage, and when something keeps failing — get a fresh mind on it instead of trying the same angle repeatedly. For small changes, it usually skips the review to stay out of the way.

You can also call it manually at any time: just type /rubber-duck what edge cases are still missing?

Go further: let two models hammer each other

The rubber duck and Autopilot can be chained into a loop.

/autopilot rubber duck this date picker implementation. When you have the result, review it carefully and make any necessary adjustments. Repeat the rubber duck review until both you and the reviewing model agree that the only items that remain have diminishing returns.

It costs more tokens. But as he puts it, you're using two models to hammer the code into shape — which is really saving your future self from stepping on the same rakes.

Step 8: Commit — and start a new session when you change topics

When it's done, commit. Or keep adding the next feature to the same change. He also has a session-management tip: if the next task is unrelated, start a new session. Sessions should be organized by topic. When you've drifted far off track, that's usually a sign to switch.

Here's the finished product — zooming from year to month to day, with the component on the left and a live-updating settings panel on the right:

He admits the example is a bit contrived — but it still makes you pause. The date picker used to be one of the hardest front-end jobs. Ask anyone who's built one.

He Said No Skills Needed — Then Installed Two

The article opens with "If you feel overwhelmed by AI right now, you're not alone," then lists the never-ending parade: new tools, new MCPs, new skills, new workflows, and the eternal "Look! I figured out AI with this one weird prompt!" His reply is one line:

I…don't believe you.

I…don't believe you.

He uses AI every day, and his conclusion is the fewer things you install, the deeper your understanding, the better your results. Plugins, rules, tricks to coax the agent into doing more — all interesting, but to him they're parlor tricks. What actually moves the needle is how he uses the harness and how well he knows it.

He has a line about the garbage flooding the market, too: ask an agent to generate a skill and it will happily produce one. Whether it actually works is another question. And that thing can be posted to any skill marketplace or MCP registry.

His closing summary has three layers:

First, a simple workflow is enough for most people. Simple has a side benefit: when you're running several things at once, it's easier to tell what state each agent is in and where you left off. Your context window only holds so much — a model can only remember so much at a time.

Second, the AI space has no ceiling: MCPs, skills, instructions, custom agents, workflows, loops, letting agents prompt agents, standing up an entire virtual dev team — all of it is on the table.

Third, and last, his final line:

Nobody really knows what they're doing right now. We're all figuring it out as we go. Many of today's magic incantations will become tomorrow's cautionary tales.

nobody really knows what they are doing right now.

Look back at that "mostly" in the title. It carries weight. Throughout the article, he used two skills: Matt Pocock's grill-me to interrogate the plan, and his own Postrboard to anchor the design. He admits as much in the opening disclaimer.

So the real meaning of "the harness is all you need" is this: you don't have to chase every new thing that appears each day. The built-in features of the tool you already have are enough to do excellent work. When you actually hit a complex workflow that needs automation, that's when you add the extras.

His example is a date picker — that little control you click to pick a date on the web. Sounds simple, but a ton of questions hide inside: how do you switch between years, months, and days? What does a range selection look like? Can you type a date manually?

Prototyping used to be an entire project phase — building even one version was a luxury. So most people wrote code straight from the image in their head and realized halfway through that it wasn't what they wanted.

One of the 20 started from a year view. He saw it and realized what he actually wanted: zoom in year → month → day. You don't know what you want until you see it. Even for something invisible like "add an API endpoint," he had the AI draw five options as a tree before choosing.

He recommends turning off the "approve this step?" prompts entirely and letting the AI run whatever commands it wants. His reasoning: if you're approving every step, you might as well do it yourself — and approve enough times, and you train yourself to click without looking, which makes the whole gate pointless. The catch: do it somewhere else.

There's one more gate after you're satisfied: a single plain sentence triggers a "rubber duck review," and the tool automatically picks a model from a different family than your current session. He writes with GPT-5.6 Terra; the reviewer is Claude Sonnet. Models trained on different data have different blind spots. Self-review tends to miss the same things.

The name comes from an old software tradition: you explain your thinking to a rubber duck, and the simple act of speaking often reveals the flaw. The difference: this duck talks back. The best time to call it is after the plan is done and before code is written — that's when changing direction is cheapest.

That flow, the seven copy-paste-ready prompts, and the numbers (20 prototypes, 7 edge cases) are all from Burke Holland's GitHub blog post. The permission levels and the duck's three feedback tiers come from GitHub's official docs. He does developer advocacy at GitHub and writes about his own product — but the method is tool-agnostic.