Planning, Implementation and Review New MCP servers, custom‑built skills, and specialized agents appear constantly. Many developers assemble large toolchains yet observe limited real‑world productivity gains. Burke Holland, who builds AI‑powered developer tooling at GitHub, advises teams to resist the urge to test every new AI capability at once. Instead, adopt a mature agent harness and run complete real‑world tasks through it.
An agent harness refers to the full control plane powering AI agent execution. It covers context management, tool invocation orchestration, task sequencing, and permission guardrails. GitHub Copilot serves as the practical demonstration vehicle in this article. Note that Copilot itself is not a complete out‑of‑the‑box MCP‑first agent. Complex custom‑agent and team‑automation scenarios still demand extra extensions. This walkthrough uses a Date‑Picker UI component as a concrete example, walking through an eight‑stage workflow: prototype generation, requirement clarification, plan formulation, autonomous execution, manual iteration, secondary review, quality validation and session wrap‑up.
1. Tool Selection and Isolated‑Environment Setup
GitHub Copilot exposes consistent harness capabilities across CLI, Copilot app, VS Code, Visual Studio, and JetBrains IDE clients. Newcomers are recommended to start with GitHub Copilot CLI. Terminal‑based interaction makes agent file reads, tool invocations, and command execution transparent and observable.
Enable the Allow All (YOLO) permission mode. When activated, the agent can read files, access local paths, and run shell commands without manual approval for every single step. Repeated manual confirmation interrupts flow and creates mechanical busy‑work, reducing human attention for real review work.
Critical safety note: Do not activate Allow All inside local working directories holding sensitive project material. Use GitHub Codespaces, development containers, or comparable sandbox environments. Copilot CLI exposes
--allow‑all/--yoloflags. GitHub official documentation explicitly restricts full‑permission usage strictly to isolated sandboxes.
Sandbox isolation does not equal absolute security. Before enabling unrestricted permissions, audit workspace mounts, environment variables, and outbound network access. Codespace instances may expose tokens, SSH keys, and secrets; shell commands executed by agents can read these variables and make outbound network calls.
Burke recommends working inside temporary Git branches or git worktree directories. This preserves production‑grade source code and ensures changes remain revertible. Copilot CLI also supports allow‑list‑based granular permission controls: permitting git commit while blocking git push operations.
2. Generate Multiple Low‑Fidelity Prototypes
Instead of implementing the Date‑Picker component directly, prompt Copilot CLI to output 20 distinct visual prototypes. One candidate design starts with a year‑level overview and drills down into months and days. Generating multiple low‑cost visual alternatives makes design‑tradeoff discussions far more concrete compared to abstract requirement conversations.
Prototyping works beyond UI components. When designing new API endpoints, ask the agent to draw multiple architecture alternatives using Mermaid diagrams. Prototypes surface trade‑offs around data flow, interface boundaries, and contract constraints early, cutting rework during later coding phases.
When iterating prototypes, stick to stable model configurations and fixed reasoning intensity whenever possible. Stable settings improve prompt‑caching efficiency. Changing model variants, reasoning effort, context‑window sizes, active MCP servers or tool sets inside one session invalid cached prompt state. Cache may also expire after long idle periods. Actual caching behavior depends on Copilot backend implementation and your selected large‑model stack.
3. Refine Requirements via Plan Mode
Once a preferred design direction emerges, switch Copilot CLI into plan mode. The agent will systematically explore requirement boundaries by asking targeted clarification questions:
- Can start‑date and end‑date values be identical?
- Are partial‑range selections permitted?
- Should users be allowed to clear selections?
- Does “today” represent a static fixed calendar date?
- Is manual text input and date‑string pasting supported?
- What output format will serialized dates adopt?
These edge‑case details cannot be fully captured within a single opening prompt. The AI agent surfaces gaps, while human engineers make final trade‑off judgements. For deeper requirement exploration, developers can load external skills such as grill‑me. More questions do not automatically equal better specifications; human reviewers must validate every boundary condition and resolve ambiguous terminology.
After interactive requirement gathering completes, Copilot outputs a consolidated plan summary, listing component scope, interactive behaviors, accessibility constraints, styling requirements, public API surface, test validation points, and acceptance criteria. Human engineers explicitly approve or adjust this plan before execution proceeds.
4. Execute the Approved Plan Using Autopilot
After approving the generated plan, activate Autopilot mode. Autopilot continuously reads project files, applies code edits, and invokes shell commands until task completion, hard‑stop iteration limits, or manual human interruption. Within interactive CLI sessions you trigger Autopilot via keyboard shortcuts; scripted workflows accept the ‑‑autopilot flag with configurable maximum iteration thresholds.
Autopilot and /delegate implement two different internal mechanics. Autopilot runs locally within your active CLI session. /delegate offloads work to remote Copilot coding agents. You do not need custom‑agent configuration to leverage these built‑in harness capabilities. They ship as native Copilot functionality.
5. Manual Human Review and Iterative Fixes
The first functional Date‑Picker build is operational yet contains visible defects: inconsistent animation timing, insufficient text contrast, redundant UI headers, and incorrect “Today” button logic.
Engineers provide concrete natural‑language feedback describing observable defects rather than vague high‑level requests. Project‑specific design‑system definitions (Post‑card‑based CSS rules) can be packaged as skills to give the agent concrete visual‑spec references. Each iteration narrows down defects, and developers keep validating runtime behavior. Reaching “runs at all” status does not mark task completion. Final output quality heavily depends on human‑led observation and continuous correction.
For production‑grade projects, run existing project linters, type‑checkers, unit‑test suites, and build pipelines after every iteration.
6. Secondary Review with Rubber‑Duck Agent
After manual iteration stabilizes implementation, trigger a Rubber‑Duck review. This built‑in review‑agent examines existing plans, source‑code artifacts, and test coverage and returns independent feedback. Rubber‑Duck review can run against prototypes and plans, not only finished implementation code.
Burke Holland combines Autopilot and Rubber‑Duck review into a closed‑loop workflow: Autopilot implements changes; Rubber‑Duck performs independent auditing; human engineers adjust requirements or fix defects; repeat until marginal returns from further iterations become negligible.
This loop can uncover overlooked boundary‑case logic, yet it increases token consumption and model‑invocation volume. Terminate cycles when incremental defect fixes deliver minimal practical value. Remember that Rubber‑Duck agent review does not replace real unit‑testing or human code review performed by engineers.
7. Session Wrap‑Up and Context Management
When prototyping, planning, implementation, and multi‑round reviews finish, you can persist changes, commit code, or continue refining pull‑request content.
Copilot CLI consumes context window budget for every chat message, model reply, tool invocation, and tool‑return payload. Developers can inspect context‑window consumption and compress conversation history. Long‑running sessions bloat context size, degrade agent performance, and raise token‑usage overhead. Reset and start fresh sessions for logically‑separate workstreams.
Teams managing multi‑model agent workloads across different environments frequently evaluate API‑gateway solutions. 4sapi delivers unified routing capability for heterogeneous model endpoints, helping centralize observability and credential management across Copilot‑style agent workflows.
Important distinction: Enabling Allow All permission mode and strict human‑review workflows are not mutually exclusive. Unrestricted execution permissions remove repetitive manual‑approval busy‑work; human‑controlled checkpoints (planning sign‑off, manual QA, diff inspection, agent‑review loops) still enforce quality gates. Removing guardrails without substituting structured review processes creates substantial risk.
8. Suitable Scopes and Practical Boundaries for This Harness Workflow
This eight‑step harness workflow delivers best outcomes for tasks with clear deliverables, observable runtime results, and verifiable acceptance criteria: isolated UI components, independent modules, well‑defined bug‑fixes, and small‑scale refactoring.
Complex system‑overhaul projects can reuse this pattern, but split large‑scale work into smaller independent chunks. High‑risk changes including database‑schema migration, payment‑logic adjustment, and security‑critical refactoring require stricter human gates: manual acceptance‑criteria confirmation, pre‑change diff auditing, pre‑commit lint‑and‑build validation, and human code review.
Burke also outlines practical failure modes: agents produce plausible‑looking yet subtly broken logic; context‑window decay degrades long‑session output quality; autonomous loops consume unexpected token volume. Human engineers own scope definition, acceptance‑criteria setting, and final quality judgement. AI agents handle exploration, drafting, and repetitive implementation labor.
Final Conclusion
Today’s flood of novel prompts, custom‑skills, and agent frameworks tempt engineers to chase every new tool. In practice, mastering a complete end‑to‑end harness workflow delivers far more tangible value.
The practical workflow sequence repeats:
- Build multiple low‑fidelity prototypes to explore alternatives
- Use plan‑mode requirement gathering to lock down boundaries
- Approve the formal implementation plan
- Run Autopilot for code generation
- Manually inspect and iterate on visible defects
- Apply Rubber‑Duck agent secondary review
- Execute project‑standard lint, test and build validation
- Commit results and reset conversation context
You may layer MCP servers, custom skills, instructions and specialized agents on top of this baseline workflow. More tooling adds configuration burden and maintenance overhead. Master your core harness workflow before expanding tool‑chain complexity.
