Resposta direta

Seu quadro de tarefas acabou de ganhar um funcionário que não dorme. No dia 23 de julho, o GitHub liberou o Copilot cloud agent no Linear. Agora eu posso atribuir uma issue ao Copilot, deixar ele trabalhar em um ambiente separado e receber um draft pull request para revisar.

Seu quadro de tarefas acabou de ganhar um funcionário que não dorme.

Capa estilo caderno Moleskine mostrando uma ordem de serviço entregue a um pequeno mecânico de IA

No dia 23 de julho, o GitHub liberou o Copilot cloud agent no Linear. Agora eu posso atribuir uma issue ao Copilot, deixar ele trabalhar em um ambiente separado e receber um draft pull request para revisar.

TL;DR:

  • Copilot no Linear transforma uma tarefa em um rascunho de código.

  • O agente trabalha em segundo plano, em ambiente temporário do GitHub Actions.

  • A equipe ainda precisa revisar, testar e aprovar. Delegar não é largar a chave do cofre.

O problema: tarefa vaga vira IA perdida

Eu vejo muito founder comprando IA como se comprasse café para o time: coloca na mesa e espera produtividade aparecer.

Não aparece.

A integração do Linear com o Copilot é útil, mas ela não salva tarefa mal escrita. Se o cartão diz "melhorar checkout", a IA vai chutar. Se diz "quando o estoque acabar, bloquear compra e mostrar Produto sem estoque", ela recebe uma ordem de serviço.

A diferença é chata, quase burocrática. Ou seja, é exatamente onde mora o ROI.

O Framework Ordem de Serviço

Eu usaria o Copilot no Linear com o Framework Ordem de Serviço. São 5 passos simples para não transformar automação em retrabalho.

1. Escreva o defeito

Comece pelo que está quebrado.

Exemplo: "O botão Comprar permite pedido mesmo quando o estoque está zerado".

Isso é melhor que "arrumar fluxo de compra". Uma frase aponta para o problema. A outra aponta para uma reunião.

2. Escreva o resultado esperado

Diga o que precisa acontecer quando a tarefa terminar.

Exemplo: "Mostrar Produto sem estoque e impedir o envio do pedido".

A IA precisa de chegada. Sem chegada, qualquer caminho parece bom.

3. Escreva os limites

Liste o que não deve ser mexido.

Exemplo: "Não alterar layout, meio de pagamento ou cálculo de frete".

Esse passo parece excesso até o agente trocar três arquivos que ninguém pediu. Aí vira sabedoria antiga.

4. Escreva a prova

Defina como alguém vai conferir.

Exemplo: "Criar ou atualizar teste para estoque zerado e rodar o fluxo manual no carrinho".

Se não existe prova, existe torcida. Torcida é ótima no Mineirão, péssima no deploy.

5. Atribua e revise

Atribua a issue ao Copilot no Linear. Ele analisa a tarefa, trabalha em um ambiente temporário, envia atualizações na timeline e abre um draft pull request.

Depois entra a parte que separa gente séria de show de IA: alguém revisa o código, roda testes e decide se aprova.

Como aplicar hoje em 5 minutos

Pegue uma tarefa pequena do seu backlog e reescreva neste formato:

Problema: o que está errado?
Resultado: o que deve acontecer?
Limites: o que não deve mudar?
Prova: como vou saber que funcionou?

Se você usa Linear e GitHub, instale o app GitHub Copilot for Linear. O GitHub diz que a configuração exige permissão de dono da organização no GitHub e admin do workspace no Linear.

Depois escolha uma tarefa de baixo risco: texto errado, teste faltando, bug isolado, documentação desatualizada.

Não comece por checkout, pagamento ou regra fiscal. Eu gosto de dormir.

Resultados esperados

Eu não venderia isso como "dev autônomo". Isso é balela.

O ganho esperado está em tirar tarefas pequenas da fila e devolver um rascunho mais rápido para revisão humana. O Copilot pode pesquisar o repositório, planejar, alterar arquivos e criar o pull request. O GitHub também diz que ele pode publicar progresso no Linear enquanto trabalha.

Na prática, eu mediria 4 números:

  • Tempo entre abrir a tarefa e receber o primeiro draft pull request.

  • Percentual de drafts aceitos sem retrabalho pesado.

  • Número de comentários de revisão por draft.

  • Bugs que voltaram depois do merge.

Se esses números não melhorarem em 30 dias, o gargalo não é ferramenta. O gargalo é briefing, teste ou governança.

Quando eu não usaria

Eu não colocaria o agente para mexer em regras críticas sem revisão forte.

Também não usaria em tarefa com contexto escondido na cabeça de uma pessoa. Agente não lê pensamento. Ainda bem, porque algumas reuniões seriam crimes de guerra.

Use em mudanças pequenas, verificáveis e com dono humano claro.

Perguntas rápidas

O que é o Copilot no Linear?

É uma integração que permite atribuir uma issue do Linear ao Copilot cloud agent. Ele trabalha em segundo plano e abre um draft pull request no GitHub.

O Copilot cria código direto em produção?

Não. Ele cria uma proposta de mudança. A equipe ainda precisa revisar, testar e aprovar antes de qualquer merge.

O agente trabalha no meu computador?

Não. O GitHub informa que ele usa um ambiente temporário, separado, com GitHub Actions.

Posso orientar o agente enquanto ele trabalha?

Sim. A publicação do GitHub diz que você pode mencionar o Copilot em um comentário no Linear para dar novas instruções durante a sessão.

Quem deve testar primeiro?

Eu começaria com um líder técnico, usando uma tarefa pequena. O founder deve olhar o processo e os números, não fingir que virou engenheiro às 23h.

Conclusão

Copilot no Linear é interessante porque leva a IA para onde o trabalho nasce: o quadro de tarefas.

Mas a regra continua simples: ordem ruim gera execução ruim. Escreva o problema, o resultado, os limites e a prova. Depois deixe a IA preparar o rascunho e coloque uma pessoa para revisar.

É menos mágico do que o hype promete. E é por isso que pode funcionar.

Para continuar, leia também [o que é agente de terminal](/blog/o-que-e-agente-de-terminal), [o que são agentes paralelos](/blog/o-que-sao-agentes-paralelos) e [o que é aprovação humana em agentes de IA](/blog/o-que-e-aprovacao-humana-em-agentes-de-ia).

Fontes que eu li