GitHub Copilot grew from an experiment with OpenAI Codex into a tool that writes about half of the code in enabled files.
2
Copilot Workspace connects a GitHub issue to repository analysis, an implementation plan, and a code diff while keeping the developer in control.
3
Thomas Dohmke expects AI agents to handle repetitive work such as security fixes, so developers can spend more time building features.
Summary
Thomas Dohmke describes how GitHub Copilot began during the 2020 lockdown, when GitHub engineers experimented with OpenAI Codex. The first product was an autocomplete tool, and internal usage quickly showed strong interest. GitHub later found that Copilot generated about 25% of the code in enabled files, rising to about half over time. Dohmke explains that Copilot Workspace extends this idea from code completion to task implementation. It takes an issue or idea, examines the repository, proposes a plan, and produces a diff that a person can edit. He argues that the developer should remain involved rather than handing work to a fully autonomous system. He also describes a wider future in which AI handles security, compliance, and other work that slows development. His advice is to treat the technology as another major change in how software is built, while using it to give more people access to programming and institutional knowledge.
In 2020, during lockdown, GitHub engineers experimented over Zoom with an early preview of OpenAI's Codex, a version of GPT-3. Dohmke's first surprise was that the model could write JavaScript with correctly placed curly braces and could switch between programming languages without working like a compiler or using an explicit syntax tree. The team kept exploring the model and decided to build an autocomplete product. GitHub developed it while engineers worked from home, which Dohmke uses as evidence that innovation does not require everyone to share an office.
Early Copilot adoption changed GitHub's expectations
GitHub first shipped Copilot internally through what it called a staff ship. The internal NPS result was around 72 or 73, which Dohmke says was unusually high for an early product with hallucinations and an unfinished interface. After the product launched in 2021, telemetry showed that Copilot wrote about 25% of the code in files where it was enabled. Dohmke initially thought the measurement was wrong, but GitHub validated it. He says the figure is now about half, with some languages such as Java showing higher acceptance and more lines written.
GitHub has to change its plans as AI changes quickly
Dohmke says leading an AI product requires constant reconfiguration. GitHub cannot rely on a long-term feature plan and simply work through a backlog because the field changes almost daily. He also says the company tries to meet developers where they already work. GitHub calls the product Copilot because it aims to build AI for engineers rather than an AI engineer that replaces the person. Dohmke connects this approach to GitHub's own work: improvements in developer productivity also help GitHub build its AI products.
Keeping suggestions inside the editor helps developers stay in flow
Dohmke explains that Copilot's original ghost-text interface reduced the cost of imperfect suggestions. Developers already adjust ordinary autocomplete, so they can treat AI completions in the same way. Without Copilot, a developer who gets stuck may switch from the editor to Google, Stack Overflow, or GitHub, copy code, and modify it. Those sources can also become outdated as languages and APIs change. Copilot keeps the developer in the editor and reduces that context switching. Dohmke says the central feature is helping developers stay in flow, rather than the AI label itself.
Workspace turns an issue into an editable implementation
Copilot Workspace extends Copilot beyond autocomplete and the IDE chat sidebar. It starts with a GitHub issue, task, or idea and works through the repository to determine how the requested change could be implemented. The process moves from the task description to a specification, repository analysis, a plan covering the files that need changes, and an implementation diff. The person can edit the plan's bullet points and change the code. Dohmke presents this as a way to understand an unfamiliar codebase, including its current behavior and the tests or files that need modification.
Workspace can give product managers a view into implementation
Dohmke says Workspace also helps people who do not write code every day. After its announcement, a product or program manager told GitHub that the tool could show what a user story would mean in the codebase. This addresses a common problem with task descriptions: details often seem obvious until implementation begins. Workspace can help determine whether a task is specific enough to produce code and can expose the plan required to complete it. Dohmke also connects this to estimation, arguing that teams are often poor at predicting how long work will take.
Natural-language tools can widen access to programming and company knowledge
Dohmke says the models behind Copilot can work across major human languages, so people can explore programming in English, German, Hindi, Brazilian Portuguese, Spanish, or Chinese. He imagines children using Copilot to move from games such as Super Mario or Minecraft toward creating their own games and web pages. He also says Copilot can help people who lack technical support at home. In companies, the same idea applies to institutional knowledge. New employees can ask about how work is done instead of feeling pressure to ask colleagues a thousand questions.
Useful agents should take care of work that developers do not want
Dohmke defines an agent through the example of a dishwasher: someone loads it, lets it work, and takes the output when it is finished. He says existing systems such as bots, CI/CD, GitHub Actions, and monitoring already perform autonomous jobs. The harder problem is that software teams still spend time on boilerplate, security, and compliance. Security tools can add items to a backlog by identifying problems without fixing them. Dohmke wants AI agents that can automatically fix security issues and reduce that backlog, leaving developers more time for creative work and new features.
AI needs to add an abstraction layer to software development
Dohmke says engineering leaders must balance security, compliance, accessibility, customer trust, and innovation. A team cannot spend all its time on security, but a security incident can damage trust. AI agents may help by reducing the amount of operational work that competes with feature development. He also says software teams need new abstraction layers because modern development contains so many steps beyond writing code. His advice is to embrace the new tools as another step change in software development, alongside the PC, open source, the internet, GitHub, and mobile software.
"The core feature of Copilot that helps developers to stay in the flow, to get the job done, and not be in this constant distraction between the editor and the browser."06:51
Who should watch
You are building developer tools and need to decide how much work should remain in the IDE versus move into repository-level workflows.
You are a product manager or engineer who wants to turn issues into implementation plans while keeping a person involved in reviewing the changes.
You are exploring AI agents for security, compliance, and other development work that fills the backlog.
