Evolving GitHub Copilot through LLM Experimentation and User-Centered Design

github · Tech · 2023 · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: AI-assisted software development

GitHub needed to evolve Copilot beyond code completion into pull requests, documentation, chat, and CLI workflows while keeping model errors understandable, editable, and verifiable for developers.

Constraints:

The team was working with early GPT-4 access and had to identify which prototypes were valuable enough to build.
AI outputs could be wrong, so GitHub needed user experiences where mistakes were visible and low-cost.
Pull request, documentation, and command-line workflows each had different interaction patterns and risk profiles.
The March 2023 announcement timeline forced product teams to focus on prototypes that could reach technical preview quality.
Developer trust depended on presentation, references, explanations, and user control as much as model capability.

Architecture

GitHub Next used GPT-4 experimentation to create multiple Copilot extensions: pull-request summaries presented as editable suggestions, documentation Q&A backed by retrieval over documentation, CLI command generation with structured explanations, and Copilot Chat. The architecture treated LLM output as workflow assistance rather than authority, surrounding model responses with references, editable previews, explanations, and developer verification.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  github-next-prototyping-team["GitHub Next prototyping team"] --> gpt-4-model["GPT-4 model"]
  github-next-prototyping-team --> product-selection-process["Product selection process"]
  product-selection-process --> copilot-technical-previews["Copilot technical previews"]
  gpt-4-model --> copilot-for-pull-requests["Copilot for Pull Requests"]
  gpt-4-model --> copilot-for-docs["Copilot for Docs"]
  documentation-retrieval-engine["Documentation retrieval engine"] --> copilot-for-docs
  gpt-4-model --> copilot-for-cli["Copilot for CLI"]
  copilot-for-cli --> explanation-field["Explanation field"]
  copilot-for-pull-requests --> developer-verification-loop["Developer verification loop"]
  copilot-for-docs --> developer-verification-loop
  explanation-field --> developer-verification-loop
  developer-verification-loop --> copilot-technical-previews

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`GitHub Next prototyping team`	Explored GPT-4 capabilities and identified concepts that could become Copilot technical previews.	`Product selection process`, `GPT-4 model`
`GPT-4 model`	Generated candidate pull-request descriptions, documentation answers, CLI commands, and chat responses.	`Copilot for Pull Requests`, `Copilot for Docs`, `Copilot for CLI`
`Product selection process`	Chose prototypes that showed enough value for March 2023 technical previews.	`GitHub Next prototyping team`, `Copilot technical previews`
`Copilot for Pull Requests`	Generated pull request descriptions and walkthroughs as editable suggestions for authors.	`Developer verification loop`, `GPT-4 model`
`Copilot for Docs`	Used retrieval over documentation to ground answers and expose references for verification.	`Documentation retrieval engine`, `Developer verification loop`
`Documentation retrieval engine`	Searched documentation and fed topical results into prompts for Copilot for Docs.	`Copilot for Docs`, `GPT-4 model`
`Copilot for CLI`	Converted natural language intent into shell commands and structured explanations.	`Explanation field`, `Developer verification loop`
`Explanation field`	Made generated shell commands scannable and safer to verify before execution.	`Copilot for CLI`, `Developer verification loop`
`Developer verification loop`	Kept the developer in charge by making outputs editable, linked, explainable, and easy to reject.	`Copilot for Pull Requests`, `Copilot for Docs`, `Copilot for CLI`
`Copilot technical previews`	Released selected Copilot Chat, pull request, docs, and CLI concepts for broader developer use.	`Product selection process`, `Developer verification loop`

Data flow

GitHub Next prototyped ideas with GPT-4, product teams selected promising concepts, and each workflow wrapped the model output in a UX control. Pull requests used generated descriptions as editable suggestions, Docs used a retrieval engine to compose topical answers from documentation, CLI transformed natural language requests into shell commands plus explanations, and developers verified or edited outputs before acting.

“Over the course of several months, researchers from GitHub Next used the GPT-4 model to develop potential new tools and features that could be used across the GitHub platform.”article, stated

“we realized we could use the retrieval engine to search a large corpus of documentation, and then compose those search results into a prompt that elicits better, more topical answers based on the documentation”article, stated

Why this architecture

GitHub optimized around predictable, tolerable, steerable, and verifiable AI experiences because model correctness alone did not make developer workflows successful. The same pull-request content became useful when reframed as an editable suggestion, Docs answers became more tolerable with references, and CLI commands needed explanations so developers could inspect generated actions.

“The developers were concerned that the AI would be wrong. But there’s two things: you have the content the AI generates and then you have the way that it’s presented to the user”article, stated

“Solutions must be easy to evaluate. The models are not perfect, but they can be very helpful tools if users verify their outputs.”article, stated

Models used: GPT-4 · GitHub Copilot Chat · Copilot for Pull Requests · Copilot for Docs · Copilot for CLI · Documentation retrieval engine · Vector database prototype

Scale

GitHub Copilot had been in public preview since 2021 before this broader Copilot evolution.
“since GitHub Copilot’s initial preview release in 2021, we’ve been thinking a lot about how generative AI can (and should) empower developers”article, stated
GitHub Next spent several months using GPT-4 before selecting preview candidates.
“Over the course of several months, researchers from GitHub Next used the GPT-4 model to develop potential new tools and features”article, stated
The Copilot evolution shipped as technical previews on March 22, 2023.
“And on March 22, 2023, the technical preview for what GitHub Copilot would evolve into was released to the world”article, stated
The CLI effort started from a thirty-minute prototype before being refined into a preview.
“That thirty-minute prototype was the genesis for what would become Copilot for CLI.”article, stated

Alternatives considered (roads not taken)

Post AI-generated pull-request summaries as comments.

Rejected because: Internal testing showed that developers worried the AI would be wrong when the generated content appeared as a workflow artifact rather than an editable author suggestion.

“At first, we focused a lot on the first bit, the AI-generated content, but it turned out that the second bit was far more crucial in getting this thing to fly”article, stated

Return documentation answers without references.

Rejected because: The team found that linked documentation made imperfect answers easier to evaluate and use as search assistance.

“developers didn’t mind if the output wasn’t always perfectly correct if the linked references made it easier to evaluate what the AI produced”article, stated

Let the CLI model explain commands as an unstructured paragraph.

Rejected because: Plain language model explanations were too long, hard to scan, and sometimes omitted the details developers needed.

“if you just ask the AI to explain a shell command, it would feed you a long paragraph that is not readily scannable and might not include the details you want”article, stated

Patterns

`human-in-the-loop-gate` (developer verification)

GitHub designed Copilot outputs as editable, inspectable suggestions so developers could verify and steer the AI before accepting work into the workflow.

“When the content was served as a suggestion that the developer had the authority to accept and edit, the typical attitude toward the feature changed.”article, stated

`rag-retrieval` (documentation grounding)

Copilot for Docs used retrieval over documentation to compose more topical answers and expose links for verification.

“we built in the capability for our answers to provide references or links to other documentation”article, stated

`eval-driven-development` (internal product testing)

GitHub used internal Hubber studies and public preview feedback to discover where the AI feature failed because of workflow presentation rather than generated content.

“We did an internal study of the feature with Hubbers and it didn’t go well”article, stated

Tradeoffs

How to place AI-generated pull-request descriptions in the review workflow.

Chose Editable suggestion preview over Automatically posted first comment.

Rationale: The suggestion framing kept the author in control and changed feedback without changing the generated text.

“Instead of a comment, we put it as a suggestion to the developer that let them get a preview of what the description of their pull request could look like”article, stated

How to make documentation answers useful despite imperfect model accuracy.

Chose Reference-backed search-assistant behavior over Authoritative answer-only chat.

Rationale: References lowered the cost of mistakes by letting developers verify the answer and continue from relevant documents.

“They were using Copilot for Docs as a search engine”article, stated

How much UI surface to spend on CLI command explanation.

Chose Structured explanation field over Minimal command-only or paragraph-only UI.

Rationale: The explanation helped developers learn, verify safety, and inspect command effects inside a compact application.

“When you have such a small application, you want every feature to have multiple different uses so that you can package up a lot of complexity in something that visually is very simple.”article, stated

Gotchas (what bit them)

Correct or useful AI content can still fail if it is presented as an authoritative workflow artifact.

Root cause: The first pull-request design put generated content into the workflow in a way that made developers worry about wrong AI output.

Resolution: Move the same generated content into an editable suggestion that the developer previews and controls.

“The content was exactly the same as before, it was just presented differently.”article, stated

Documentation Q&A can produce the wrong answer or the wrong document.

Root cause: LLMs and retrieval can miss the exact answer, so unsupported responses are hard to trust.

Resolution: Attach documentation references so users can evaluate and treat the tool as guided search.

“the models don’t always give the right answer or the right document”article, stated

LLMs do not naturally produce compact, structured CLI explanations.

Root cause: Asking for a shell-command explanation tended to produce unscannable long paragraphs.

Resolution: Add a structured explanation field that doubles as a security and learning aid.

“It’s also a security feature because you can read in natural language whether the command will change files you didn’t expect to change”article, stated

Evaluation

GitHub evaluated prototypes through internal Hubber studies, public preview feedback, and UX observations about whether developers could tolerate, steer, and verify imperfect model output.

Metrics: Internal study feedback from Hubbers · Developer attitude toward suggestions versus comments · Public testing feedback on documentation-answer quality · Ease of verifying CLI commands through explanations

“all of a sudden the feedback changed to ‘wow, these are helpful suggestions.’”article, stated

“once the preview reached public testing, he got some interesting feedback about the quality of the AI outputs”article, stated

Outcomes

GitHub released technical previews for Copilot Chat, Copilot for Pull Requests, Copilot for Docs, and Copilot for CLI.
Pull-request summaries became more acceptable when framed as editable suggestions.
Documentation answers became more usable when references let developers evaluate model output.
CLI explanations provided a safety and learning layer around generated commands.

The work extended Copilot from code completion into multiple stages of the developer lifecycle, with previews announced around GPT-4's March 2023 release.

“the technical preview for what GitHub Copilot would evolve into was released to the world with GitHub Copilot Chat”article, stated