GitHub Copilot aposta em canvas quando chat não é a interface ideal

A tese: chat nem sempre é a interface ideal

Em post no blog do GitHub, Burke Holland argumenta que, três anos após o início do experimento da IA generativa, a principal superfície de interação com LLMs continua sendo o chat - e que isso nem sempre é o formato certo. Ele cita Steven Pinker, que avaliou que a primeira implementação em larga escala de IA foi 'uma espécie de truque - um chatbot em primeira pessoa', mas que há enorme potencial em uma IA orientada a tarefas. Para Holland, o chat prevaleceu porque foi a primeira interface que as pessoas adotaram e funciona como solução universal, já que ninguém sabe o que cada usuário vai fazer com IA. Mas, quando o usuário sabe o que quer fazer, 'o chat costuma ser a interface errada'.

O que é um canvas

A resposta do GitHub Copilot app é o canvas: um pequeno aplicativo full-stack que roda dentro do app, sem a moldura de um navegador. O agente pode conversar com a parte de servidor do aplicativo, e o servidor responde de volta - uma comunicação bidirecional. O resultado é uma superfície capaz de fazer o que qualquer programa de computador faz e, ao mesmo tempo, conversar com o agente do Copilot.

Criar um canvas é simples: basta pedir, em linguagem natural, que o app crie um canvas com uma função específica - o app já 'sabe' o conceito e não exige mais explicação. Como são aplicações full-stack, os canvases podem chamar APIs de terceiros e também executar código localmente na máquina do usuário.

Exemplos práticos

Holland demonstra o conceito com um canvas do jogo Connect 4, em que é possível jogar contra o próprio agente dentro do app. Outros exemplos: uma interface para o Winget, que navega no registro de pacotes e gerencia pacotes locais (instalar e desinstalar) sem nenhuma IA; um canvas para SQLite, que permite escrever SQL diretamente, com autocompletar, em vez de pedir ao agente por chat; e até uma recriação do Windows Live Writer para escrever posts de blog Jekyll em Markdown.

Eficiência de tokens e automação do fluxo de trabalho

Um ponto central do argumento é econômico: quando o chat é a interface principal, o usuário tende a usar o agente para tudo - o que muitas vezes é desperdício de tokens. Para Holland, é quase sempre melhor que o agente construa uma ferramenta, na qual as interações futuras são gratuitas, do que tratar o próprio agente como a ferramenta. Ele critica o hábito de pedir a modelos caros comandos como 'stage and commit', admitindo que também o faz.

O exemplo mais elaborado é a automação do próprio fluxo de trabalho de desenvolvimento, que Holland descreve como: pesquisa, protótipo, plano, implementação, iteração e finalização. Cada etapa normalmente exige que ele esteja no teclado, mas o agente é capaz de pesquisar, gerar protótipos e avisar quando estiver pronto para revisão. O objetivo dos agentes, segundo ele, é se tirar do circuito o máximo possível - algo difícil com apenas uma caixa de chat. Um canvas pode automatizar esse fluxo, deixando o desenvolvedor dentro ou fora do circuito conforme a escolha.

Conclusão

Holland ressalva que não pretende prescrever o fluxo ideal, mas defende que estar 'preso à interface de chat pode estar trabalhando contra todos nós', dificultando a resolução de problemas reais quando a única interação é uma caixa de texto. Na prática, ele observa variações de esforço: o canvas de SQLite é possível em uma única solicitação, enquanto o de fluxo de trabalho levou quase um dia para acertar design e automação. A sugestão final é experimentar os canvases no GitHub Copilot app.