GitHub’s ‘harness-first’ Copilot workflow puts process before plugins

The sequence

Six stages from prototype to review

Holland’s process has six stages:

• Choose one Copilot interface and learn its workflow.
• Use an isolated environment before granting broad command permissions.
• Produce several prototypes before choosing an implementation.
• Use the planning stage to expose requirements, constraints and edge cases.
• Let Copilot implement the agreed plan through Autopilot.
• Review, revise and ask another model to challenge the result before committing.

The stages separate exploration, decisions, execution and inspection before the agent moves from a loose request towards production code.

The prototypes

Use prototypes to compare decisions

GitHub’s example begins with a request for 20 date-picker mock-ups in a single HTML file. Comparing alternatives helps the author recognise an interaction pattern that might not have emerged from a written specification alone.

The same principle can apply beyond visual design. The article suggests diagramming several possible approaches to an API endpoint before choosing one. For a business team, comparable exercises might include:

• mapping alternative approval flows for a content tool;
• sketching how customer information moves through an internal assistant;
• comparing several document-classification schemes;
• visualising where a proposed integration reads, writes or retains data.

Prototypes give a team something concrete to question, which can expose misunderstood requirements before they are embedded in working software.

Label every prototype clearly, then check it for accessibility, brand rules, operational constraints and unsafe assumptions before treating it as a specification.

The plan

Planning exposes the decisions a person still has to make

The article then moves into Copilot’s plan mode. For the date picker, this produces questions about manual entry, clearing a selection, date formats and the treatment of past or partial dates.

AI can expand the list of considerations. The responsible person still decides which requirements apply and how to resolve conflicts.

For business software, the planning conversation should extend beyond functionality. Teams can ask:

• What personal, commercially sensitive or copyrighted material will the agent encounter?
• Which actions are reversible?
• What records are required for audit or incident investigation?
• Who owns the decision when an AI suggestion conflicts with policy?
• Which tests, accessibility checks and security controls define acceptance?
• What happens when a dependency, model or agent feature changes?

Holland warns readers not to accept every AI suggestion. The responsible person must test generated edge cases against subject knowledge, user research and the formal risk assessment; length alone does not make a plan better.

The boundary

Keep broad command permissions inside an isolated environment

The most consequential recommendation is to enable the permission setting described as “YOLO mode” or “Allow All”. According to the article, this allows an agent to execute commands without repeatedly waiting for approval. Holland argues that constant approval prompts obstruct useful autonomy and can condition people to approve requests without reading them.

He also says this mode should not be run on a local work machine and points readers towards sandboxed environments such as GitHub Codespaces or development containers.

A sandbox reduces exposure only when the team checks its boundaries. Before enabling broad command execution, an organisation should confirm:

• whether production systems, internal networks and live customer data are inaccessible;
• whether credentials are absent, temporary or restricted to the minimum scope;
• whether outbound network access should be limited;
• whether generated changes remain subject to testing and human review;
• whether actions and tool calls are logged;
• whether the environment can be discarded and recreated safely;
• whether licences, contractual duties and internal policies permit the intended data use.

The target is enough autonomy to work inside a deliberately restricted environment. GitHub recommends isolation; each organisation still needs a security and governance design for its own systems and data.

The execution loop

Verify Autopilot’s work outside the agent

GitHub describes Autopilot as a built-in loop that keeps working through the items in a plan. The article also says Copilot may select different subagents and models for activities such as exploring files or handling more complex work.

Autopilot can reduce manual prompting during implementation, yet the team must still verify the plan, each requirement and the result before release.

Treat the agent’s completion message as a progress report. Release requires evidence appropriate to the project, such as automated tests, code review, accessibility assessment, dependency scanning, threat modelling, performance checks or user acceptance testing.

The review

Review the result with people and, optionally, another model

The article gives human iteration a prominent role. Holland identifies inconsistent animation, poor colour contrast, unnecessary labels and incorrect navigation in Copilot’s first implementation, then supplies conversational feedback to refine it.

The example depends on a person who can recognise a weak result. If a team cannot define what good work looks like, faster generation may simply produce more material requiring correction.

GitHub’s additional “Rubber Duck” review asks a model from a different AI family to challenge the result. A second model can generate further questions. Two models may still share errors, misunderstand the same requirement or miss risks that require domain knowledge.

Review in this order:

• Run deterministic checks and tests.
• Compare the implementation with the agreed requirements.
• Use another model to generate additional lines of enquiry.
• Ask an accountable person to assess material findings and approve the next step.

Higher risk systems may also need independent security, legal, accessibility or specialist review.

Beyond coding

What this means for creative teams

The same sequence can guide creative production as well as coding. A creative team can separate AI assisted work into similar phases:

• generate several rough treatments;
• agree the brief, constraints and rejection criteria;
• produce within an isolated project space;
• review factual accuracy, rights, accessibility and brand fit;
• use another reviewer or model to challenge omissions;
• secure human approval before distribution.

For creative businesses, the controlled environment around a model needs source tracking, asset permissions, version history and publication approval.

The pilot

A practical pilot for a UK business

A small team could evaluate the approach through one contained, reversible task:

• Choose work that uses synthetic or non sensitive material and has a clear owner.
• Define success criteria, prohibited actions and the evidence needed for approval.
• Create several prototypes before choosing a direction.
• Ask the agent to identify assumptions, edge cases and information it lacks.
• Run implementation in an isolated environment with restricted credentials and logging.
• Test the result independently of the agent.
• Record the corrections, review effort, failures and useful outputs.
• Decide whether another skill, integration or custom agent solves a demonstrated problem.

A contained pilot can show whether visible stages, clear boundaries and accountable review make the work easier to control. GitHub offers the starting sequence; the business must gather its own evidence on productivity, cost and safety.