Uma conversa sobre como a IA entra no trabalho
O encontro de 9 de outubro em San Francisco reuniu o grupo da viagem em uma conversa sobre Cursor, agentes de IA e os desafios de transformar ferramentas em rotinas úteis. Os participantes apresentaram seus negócios e discutiram desenvolvimento de produto, organização do trabalho, distribuição e apoio a startups.
Uma ideia atravessou as respostas: o uso muda conforme a empresa, a função e o processo. Uma ferramenta pode ajudar alguém a programar, outra pessoa a preparar uma reunião e uma equipe a organizar informações. Entender essas diferenças é parte do trabalho de construir e distribuir um produto de IA.
Cursor e o contexto de SpaceXAI
Cursor combina um ambiente de desenvolvimento de software com recursos de IA para compreender e alterar código, além de agentes que podem executar tarefas. A relação com SpaceXAI mencionada na conversa também tem um registro público: em 14 de agosto de 2026, a Cursor anunciou sua aquisição pela SpaceX, após a parceria de treinamento de modelos iniciada em abril. Comunicado oficial da Cursor.
Nesse contexto, vale distinguir as experiências. O editor Cursor organiza o trabalho de desenvolvimento. Os Cloud Agents levam tarefas de programação a ambientes de nuvem. Já o Grok Bot é apresentado publicamente como um agente para tarefas em aplicativos e sites, com contexto e ferramentas de trabalho. A conversa aproximou essas possibilidades, sem que uma mesma rotina se aplique automaticamente a todas elas. Grok Bot e Cloud Agents.
Um produto que chegou à escala rapidamente
Um anúncio da própria Cursor, publicado em 13 de novembro de 2025, informou mais de US$1 bilhão em receita anualizada e uma equipe com mais de 300 pessoas. Os números são um retrato datado, anterior à aquisição. Receita anualizada representa um ritmo de receita convertido para uma base anual, não a receita contabilizada de um ano completo. Anúncio de novembro de 2025.
Para founders, a pergunta mais útil por trás desse crescimento é o que sustenta a adoção depois do primeiro teste. Programar envolve tarefas recorrentes, contexto acumulado e resultados que podem ser revisados. Quando uma ferramenta se integra a essa rotina, o usuário encontra motivos para voltar e incorporar seu uso ao trabalho.
A unidade de adoção é um fluxo de trabalho
Na conversa, a discussão partiu de usos de engenharia e avançou para atividades comerciais, recrutamento e operações. O desafio apresentado foi adaptar contexto, acessos e ferramentas às necessidades de cada organização. Um exemplo útil para uma equipe pode precisar de outra configuração quando chega a um negócio diferente.
A leitura para quem constrói produtos é começar por uma tarefa reconhecível. Quem precisa agir, qual informação utiliza, onde executa o trabalho e como sabe que terminou? Essas perguntas aproximam a promessa tecnológica da rotina. Também ajudam a decidir qual integração tem prioridade e qual etapa precisa permanecer sob revisão humana.
Uma prova de valor pode ser pequena: investigar uma falha, preparar um documento, classificar uma fila ou produzir uma alteração de software. O resultado precisa ter um destinatário e um critério de qualidade. Sem isso, fica difícil distinguir uso frequente de valor efetivamente entregue.
A qualidade também depende da implantação
Um relato do encontro descreveu a dificuldade inicial de obter bons e-mails de prospecção com IA. A evolução veio de mostrar exemplos de mensagens reais, analisar respostas e refinar a orientação. O caso chama atenção para o conhecimento do trabalho que precisa acompanhar o acesso à ferramenta.
Esse esforço ajuda a explicar a fadiga de IA mencionada na conversa. Novos lançamentos disputam o tempo necessário para testar, aprender e reorganizar rotinas. Para um produto, uma apresentação convincente precisa continuar em uma experiência de adoção que mostre como concluir a primeira tarefa útil.
A conexão entre produto e distribuição fica concreta aqui. A comunicação precisa mostrar um problema que o cliente reconhece. O onboarding precisa transformar esse interesse em prática. O suporte e os exemplos precisam ajudar quando o contexto real é mais complicado que a demonstração.
Aprender com quem usa faz parte da construção
A conversa destacou founders e startups como usuários que experimentam intensamente e precisam fazer mais com equipes menores. Seus relatos podem oferecer sinais para priorização: onde a ferramenta resolve uma dificuldade, em qual ponto exige trabalho adicional e o que impede a continuidade do uso.
Há uma conexão com o que a Cursor publica sobre sua forma de trabalhar. Uma página de carreiras descreve uma organização com pouca hierarquia, densidade de talento, debate e proximidade entre pesquisa, desenho e engenharia. A função de Field Engineer também é apresentada como uma ponte entre avaliação do produto, provas de conceito e retorno dos clientes. É a descrição pública da empresa sobre sua operação. Como a Cursor descreve esse trabalho.
Em 11 de março de 2026, a Cursor apresentou sua avaliação de modelos como um processo que combina testes offline com análise de uso em produção. O artigo inclui correção da solução, qualidade do código, eficiência e comportamento de interação entre as dimensões avaliadas. Para uma startup, essa lógica reforça a importância de observar o que acontece depois de lançar uma melhoria. Processo de avaliação publicado pela Cursor.
O conhecimento do especialista precisa viajar com a tarefa
Um dos exemplos discutidos foi o de um agente preparado com orientação de alguém que conhece os dados da empresa. Essa orientação ajudava a formular consultas e selecionar as informações relevantes. O ponto é o papel do conhecimento de domínio: saber quais fontes usar, o que cada informação significa e como apresentar o resultado.
A documentação da Cursor descreve Rules como instruções reutilizáveis para orientar o agente, com opções ligadas a projetos, usuários e equipes. Elas oferecem um mecanismo público para registrar padrões e contexto do trabalho. Sua utilidade depende da clareza e da manutenção dessas orientações. Rules na documentação oficial.
Para founders, documentar exemplos, critérios e decisões recorrentes pode ajudar tanto as pessoas quanto os agentes. Essa organização torna mais fácil revisar uma resposta e identificar se a falha veio da fonte, da interpretação ou da execução. Os exemplos compartilhados no encontro não detalharam sua arquitetura técnica interna.
Do pedido ao resultado que alguém pode revisar
Na conversa, foi relatado um fluxo em que uma ideia de funcionalidade chegava a um agente de código, virava uma proposta de alteração e retornava com imagens para revisão. O aprendizado está no encadeamento: reunir contexto, produzir uma mudança concreta e apresentar evidências para a decisão seguinte.
Essa possibilidade também aparece em um anúncio público da Cursor de 24 de fevereiro de 2026. A empresa descreveu agentes em máquinas virtuais com ambiente de desenvolvimento, capazes de testar mudanças e produzir capturas, vídeos e logs. Os artefatos ajudam a entender o que foi construído antes de decidir sobre a alteração. Anúncio dos agentes em nuvem.
O fluxo reorganiza a colaboração. O pedido precisa explicar o resultado desejado; o agente precisa devolver uma implementação e seus testes; a pessoa responsável precisa avaliar se a mudança atende ao negócio e pode ser usada. A velocidade de produção torna essa revisão ainda mais importante.
Dropbox: contexto é parte da adoção em escala
Em um caso publicado pela Cursor em 26 de janeiro de 2026, a Dropbox descreveu a adoção em um repositório com mais de 550 mil arquivos. O relato destaca a indexação do código como parte da construção de contexto para compreender sua estrutura e propor mudanças. São informações do caso divulgado pela fornecedora, com participação do cliente. Caso público da Dropbox.
O exemplo complementa a conversa: ampliar o uso exige entender o ambiente existente. Quanto maior o projeto, mais relevante é localizar o contexto e respeitar seus padrões. Uma startup pode aplicar essa leitura em escala menor, começando pela organização do próprio produto e pela qualidade das instruções que acompanha cada tarefa.
Escolher por tarefa, custo e qualidade
O encontro também discutiu a possibilidade de usar capacidades diferentes no planejamento e na execução de uma tarefa. O princípio útil é avaliar o que cada etapa exige, em vez de assumir que a mesma configuração produz o melhor resultado em qualquer atividade.
Essa avaliação precisa incluir custo, tempo, qualidade e trabalho de revisão. Um resultado rápido que exige muitas correções pode consumir a vantagem inicial. Uma escolha mais cara pode fazer sentido quando ajuda a resolver uma etapa difícil, mas isso precisa ser observado em tarefas reais, com comparação consistente.
Transformar a conversa em um experimento
- Escolher uma tarefa recorrente que tenha um resultado verificável.
- Registrar os exemplos e o contexto necessários para executá-la.
- Definir os acessos e a etapa de revisão de quem responde pelo trabalho.
- Medir tempo, conclusão, correções e custo durante um piloto.
- Investigar o que faz o usuário voltar depois da primeira experiência.
Fontes e referências
As informações sobre produtos, aquisição, crescimento e casos estão apoiadas nas fontes oficiais vinculadas ao texto, consultadas em 12 de outubro de 2026. As conexões para founders são leituras da NewHack sobre sua aplicação.
A participação está registrada no álbum do encontro.