Cursor adiciona modo de equipe ao Projects: agentes dos colegas compartilham contexto e tarefas

Se você já tentou rodar vários agentes de programação em paralelo, sabe como isso é na prática. Uma pessoa, um coordenador, um monte de workers. Tudo funciona bem enquanto você trabalha sozinho. Assim que um segundo engenheiro entra na tarefa, cada um fica com seu próprio conjunto de chats, seu próprio contexto e sua própria versão do que está acontecendo. O Cursor decidiu resolver justamente esse problema: o Projects ficou «multiplayer».

O que mudou

Relembrando, o Projects é um modo em que o engenheiro conduz uma tarefa grande por meio de um coordenador, que distribui o trabalho entre agentes. Antes, esse sistema atendia uma só pessoa. Agora é possível convidar colegas para um Project, e toda a equipe trabalha no mesmo espaço, junto com todos os agentes.

A empresa destaca três coisas.

A primeira é um quadro de tarefas comum. Nele é possível ver quem está fazendo o quê, no que os agentes de cada participante estão trabalhando e qual pull request está por trás de cada tarefa. Pessoas e agentes olham para o mesmo quadro atualizado, em vez de montá-lo a partir de chats e threads.

A segunda é uma camada de contexto compartilhada. Cada participante continua tendo um chat pessoal com o coordenador e workers com seu próprio contexto local. Por cima dele fica uma base comum: requisitos, diagramas, especificações técnicas, mockups. Uma decisão tomada em um chat passa a estar disponível para todos os agentes do projeto. Quando uma nova pessoa entra em um Project, o contexto já está configurado e atualizado.

A terceira é a comunicação dos agentes entre si. Os coordenadores dos colegas veem o que os vizinhos estão fazendo e podem combinar as coisas sem a participação de pessoas.

Como isso aparece nos exemplos

O Cursor apresenta vários cenários. O mais terra a terra são os plantões (on-call). Várias equipes da empresa fazem o rodízio em um Project comum. Quando um engenheiro assumiu o turno de um colega, seu coordenador primeiro verificou se tudo estava correto e depois continuou de onde o anterior havia parado. Ele já sabia quais tarefas estavam em andamento, quais solicitações ficaram sem atenção, o que era preciso repassar sobre incidentes e anotações, e quais canais, quadros do Linear e threads acompanhar. O trabalho inacabado pode ser repassado diretamente: o agente do novo plantonista simplesmente o assume.

Os outros dois exemplos são sobre conflitos. Um engenheiro adiciona avaliações à página de um produto enquanto um designer a refaz ao mesmo tempo. Os coordenadores percebem a sobreposição com antecedência e as avaliações já são incorporadas ao novo design, sem refatoração depois. Ou sua funcionalidade lê do banco de dados e um colega muda o esquema: os agentes combinam previamente a ordem do trabalho e, no fim, não é preciso desembaraçar conflitos de merge.

A ideia é clara e familiar: o que antes se resolvia em uma reunião ou por mensagens é transferido para os coordenadores.

O que vale considerar

Tudo isso é, por enquanto, uma descrição do próprio fornecedor. Não há números: nem quanto tempo o contexto compartilhado economiza, nem com que frequência os agentes realmente detectam sobreposições, nem com que frequência erram. Os exemplos das avaliações e do esquema do banco parecem ilustrações, e não resultados de medições. Apenas os plantões são descritos como prática real, e mesmo assim dentro da própria empresa.

Também restam questões em aberto. Quem verifica a camada de contexto compartilhada, e como, se uma decisão incorreta cair ali e agora todos os agentes a virem? Como funcionam as permissões de acesso a documentos e canais? O que acontece se os coordenadores combinarem uma ordem, mas as pessoas pensarem diferente? O blog não responde a isso. Além disso, o modo acabou de chegar à beta.

O que fazer na prática

Se sua equipe já usa o Cursor, vale a pena testar um Project em uma tarefa pequena, mas real, com a participação de duas ou três pessoas. Bons candidatos: passagem de plantões, uma funcionalidade que se sobrepõe ao trabalho de outra pessoa, onboarding de um novo desenvolvedor. É possível criar um Project no menu à esquerda e depois convidar os colegas.

Faça imediatamente duas perguntas a si mesmo. Diminuiu o tempo gasto explicando o contexto para os novatos? Diminuiu o número de conflitos na hora do merge? Se as respostas forem positivas, é um sinal de que a camada de contexto compartilhada funciona. Se não, por enquanto é uma ideia bonita, e não uma ferramenta de trabalho. Para product managers e líderes de equipe, a principal conclusão é simples: a concorrência entre agentes de programação está passando de «o agente de quem é mais inteligente» para «o sistema de quem organiza melhor o trabalho de várias pessoas e vários agentes juntos».