Thomas Dohmke on GitHub Copilot, Coding Agents, and the Future of Software

Matthew Berman speaks with Thomas Dohmke, then GitHub’s CEO, about Copilot’s beginnings, coding education and agents. The interview was recorded in May 2025; announcements and forecasts are presented in that context.

Berman recalls seeing AI code completion for the first time and asks what Dohmke thought of early GPT models. Dohmke says he initially doubted that a model could reliably keep the syntax of different languages apart.

In summer 2020 he saw GPT-3 and OpenAI Codex generate syntactically correct methods for tasks such as sorting or prime detection, without the compiler tool-calling step used in later agent systems. That experience changed his view.

GitHub tested Copilot internally months before its 2021 preview. Dohmke says early telemetry showed it wrote about 25% of code in files where it was enabled, with differences by language. This was an internal measurement for that setting, not a universal productivity figure.

He recalls unusually positive developer feedback despite the team’s concern about inserting suggestions into highly personalized editor environments. The preview attracted users who, like him, first doubted the feature and then found it useful.

Berman asks why tab completion became the interaction. Dohmke explains that editor completion and IntelliSense already existed, so developers were familiar with accepting suggestions for methods and parameters.

Developers also routinely found snippets in documentation, repositories and forums, then adapted them to local variables and libraries. Copilot combined that familiar workflow with a model that could suggest code in the editor, while still making mistakes.

Dohmke says the goal was to preserve the developer’s flow: stay in the editor, accept or change a suggestion, compile and keep building. The satisfaction comes when an idea becomes something that runs.

Berman asks whether children should still learn programming as AI improves. Dohmke says yes: software shapes phones, homes, cars, travel and work, and understanding code and basic computing helps people understand their world even if they do not become engineers.

GitHub’s newly announced coding agent takes an issue and an existing repository and proposes a change as a pull request, Dohmke says. The engineer must verify the result, including whether it is secure and consistent with business and customer expectations.

For Dohmke, learning AI-assisted development is part of learning an evolving craft. He compares today’s tools with the spread of open source and changes in full-stack work over the preceding decades.

He expects software engineers to understand models alongside front-end and back-end systems. Different tasks may use different models: low latency matters for completion, whereas an agent may have more time and need strong tool use.

Berman asks about the announcement to open source Copilot. Dohmke specifies Copilot in VS Code: the client-side implementation would be integrated into the VS Code project. This should not be read as a claim that every model and backend service was open sourced.

Dohmke points to VS Code’s public planning, documentation and releases as the precedent. He says Copilot had evolved from completion to chat, voice, agent mode and model choice, and a free tier made community participation more accessible.

He says developers could study or adapt the client under the MIT license for other editors or tools, while GitHub and Microsoft APIs remain part of the service business. The announcement concerns the client code described in the interview, not an unrestricted license to all underlying systems.

Berman asks what contributions might emerge. Dohmke suggests new model integrations, subject to evaluation and responsible AI testing, and extensions that help migrate applications in languages beyond the initially announced Java and .NET cases.

Other contributions might improve how an agent applies or rolls back changes. Dohmke hopes a public project will let developers propose changes or maintain forks suited to their own workflows.

On software architecture, Berman asks where deterministic code and non-deterministic generation meet. Dohmke says a prompt may yield different code and engineers need to work between natural-language intent and implementation. Real program behavior can also depend on inputs and environment.

He compares model interpretation with the ordinary misunderstandings that occur between product managers, designers and engineers. A team’s implementation of a CEO’s request is rarely identical to the original mental picture because people bring context and constraints of their own.

One workflow is to brainstorm a feature specification with a model, inspect the repository and possible libraries, then divide the specification into smaller tasks for an agent. The engineer judges when a task is sufficiently bounded and when direct implementation is better.

Berman asks whether an operating system might eventually be generated on demand. Dohmke expects some underlying kernel to remain, but imagines the system becoming less visible as people interact primarily with an assistant.

An agent could use software or a browser to book a trip or order food. Dohmke notes that physical delivery still has practical constraints; a convenient software interaction does not automatically solve the last physical steps.

He imagines small personalized applications generated for a particular need. A family allowance tracker, for example, could be tailored to parents and children instead of requiring a general service and its account and permission setup.

Berman likes the idea of building such an app with his child. Dohmke suggests children could continue exploring and asking questions in their own language when a parent has run out of time or answers, while learning from the process.

The conversation returns to coding agents and vibe coding. Berman asks whether people can take their hands off the wheel and focus only on the result. Dohmke prefers the analogy of driver assistance: the person remains accountable and must stay engaged.

He expects agents to handle some bounded applications with less code inspection in the future, but says much professional software work involves an existing codebase built by other people. Understanding and maintaining that code remains part of the craft.

Vibe coding is powerful for quickly turning an idea into a prototype without spending the day on setup and boilerplate. Dohmke distinguishes this from production work, where teams must consider security, quality, standards, efficiency and budgets.

For production, he describes agents proposing pull requests and developers reviewing them alongside code review tools, tests and CI/CD. Agents could take on bugs, security checks and test creation while people retain responsibility for the work.

Berman says non-programmers are already making useful applications but may hit a complexity threshold. Dohmke compares this to earlier low-code tools: AI expands what people can build without code, yet scaling and authentication still require system understanding.

Dohmke expects people’s ambitions to grow with their tools. Most software teams already have long backlogs, technical debt, compliance, accessibility and dependency work. He hopes agents can reduce that backlog, while teams still decide what features to build and why.

Berman is optimistic that cheaper software creation could increase the number of problems people solve. Both frame this as a possible future, not evidence that all developers’ jobs are guaranteed or that displacement cannot occur.

Asked whether coding interfaces will converge, Dohmke says both integration and variety are likely. Different organizations and incentives produce different agents, but those agents can connect through existing integrations and emerging protocols.

He imagines a personal assistant retaining personal history and a work assistant holding institutional knowledge. They could connect during employment and separate when a person leaves, although the boundary between personal and company information can be complicated.

A travel agent or task-specific service might connect to either assistant through agent-to-agent protocols or tools. Dohmke hopes users will have a coherent language interface even when multiple systems operate underneath.

Berman asks what reassurance he would offer people worried about their jobs. Dohmke acknowledges that some tasks, such as certain translation scenarios, may require fewer people as automation improves.

He also expects new work and hopes people can use AI to reskill. He cites historical changes in software testing roles as an example, but past transitions do not guarantee that every displaced worker will find an equivalent job or transition easily.

Dohmke closes by arguing that earlier technological shifts created new opportunities and expressing confidence that AI agents can do the same. Berman thanks him for the conversation.