'When Chat Is the Wrong UI': GitHub's Case for Copilot Canvases
GitHub's Burke Holland argues that three years into the AI era, the chat box is holding us back, and pitches 'canvases,' little full-stack apps that talk to the agent, as the fix.
The argument: chat is often the wrong UI
Three years into the mainstream AI era, the primary way we interact with large language models is still the humble chat box, and in a new GitHub Blog post, developer advocate Burke Holland argues that is a problem. His thesis is blunt: chat became the default because it was the first thing that clicked with people, and it works as a universal solution precisely because nobody knew what users would try to do with AI. But once you, the user, know exactly what you want to do, a freeform textarea is frequently the wrong tool for the job.
Enter the canvas
GitHub's answer, per Holland, is a feature called a canvas in the GitHub Copilot app. A canvas is a little full-stack application that runs inside the app with no browser chrome. Crucially, the agent can talk to the canvas's server, and the server can talk back, so you get a surface that can do anything a normal program can do while communicating bi-directionally with the Copilot agent. And building one is as simple as describing it: the app already knows what a canvas is, so a one-line request can spin up a custom UI on demand.
What you can actually build
The post walks through concrete examples. A playable Connect 4 game where you compete against the agent inside the app. A full UI for Winget that browses the package registry and installs or uninstalls local packages, with no AI in the loop at all, which Holland says is exactly the point. A SQLite front-end (complete with IntelliSense) so you can run your own queries instead of asking the agent to do it. He even resurrects a Windows Live Writer-style editor for Jekyll blog posts. Because canvases are real full-stack apps, they can call third-party APIs and execute code locally on your machine.
Why it saves tokens (and sanity)
Holland's sharpest practical point: when chat is the only interface, it nudges you to use the agent for everything, which is often a pure waste of tokens. It is almost always better to have the agent build a tool once, so that all future interactions are free, than to keep treating the agent itself as the tool. His example: stop asking the model to 'stage and commit', build a small UI and do it yourself instantly.
The bigger idea: take yourself out of the loop
The most compelling use, he argues, is automating your own development workflow. Holland describes his loop as research, prototype, plan, implement, iterate, finalize, and notes he does not actually need to be at the keyboard for most of it. The agent can research and generate prototypes, then ping him for review. The goal of working with agents, he says, is to take yourself out of the loop as much as you can, and that is hard to figure out when your only interaction surface is a textarea. A custom canvas can orchestrate that workflow and pull you in only when needed.
The takeaway
Holland is upfront that these are early ideas: some canvases (like the SQLite one) you can one-shot, while his workflow-automation canvas took the better part of a day to design. But the underlying point lands, being boxed into a chat UI may be quietly working against all of us, making it harder to solve real problems. His closing pitch is to think, as he puts it, outside the chat box. Canvases are available to try in the GitHub Copilot app now.
Related on Skillo
See also: JetBrains unveils JetBrains Air agentic dev system, Open-source ChatGPT alternatives you can run locally.
Sources
Published date reflects the original event date (2026-09-25). This article is original Skillo editorial written from the sources above; facts were verified in September 2026.
Written by
Skillo Staff
0 Comments
Sign in to join the discussion.
No comments yet. Be the first to share your thoughts.