Preciso tirar um peso do peito. Antes da minha entrevista no @cursor_ai, eu nunca tinha usado o Cursor de verdade.
Na Meta, o Claude Code estava explodindo. Cheguei a pagar um plano pessoal de $200 por mês para meus projetos paralelos. Adorava a simplicidade e como me sentia produtivo rapidamente. O ponto crucial para mim foi desenvolver meu próprio conjunto de habilidades que transformavam o cc em praticamente qualquer coisa que eu quisesse. Comecei até a criar minha própria ferramenta orquestradora de agentes em cima dele.
Durante a entrevista presencial, usei o Cursor por 2 dias para construir o projeto da entrevista. Isso foi antes do lançamento do Cursor 3, então estava usando a janela do editor. Já usava o vscode há tantos anos que a maioria dos atalhos de teclado ainda estava no meu contexto, então voltar para a IDE não foi tão difícil. Mas não vou mentir. Na primeira ou duas horas, senti falta da CLI. Clicar nas coisas parecia quase primitivo. Mas algumas coisas realmente me chamaram a atenção.
Primeiro, os modelos que eu estava acostumado na época — Opus e Codex — pareciam mais inteligentes, de alguma forma. E era incrível poder alternar entre modelos rapidamente e usar os dois ao mesmo tempo em partes diferentes do projeto (Opus para o frontend, Codex para sistemas). Antes da entrevista, eu já estava falando muito sobre revisão adversarial com múltiplos modelos, então fazer isso nativamente na UI parecia muito natural. Melhor ainda era a capacidade de gerar subagentes de diferentes modelos, para aproveitar o melhor dos dois mundos em uma única conversa.
Segundo, a compactação era incrivelmente rápida. Como usuário do cc, estava acostumado com a compactação levando vários minutos, e vivia em estado de vigilância constante sobre o uso de contexto e plano. Fiquei chocado com a rapidez no Cursor. Tanto que praticamente nunca precisei olhar quanto contexto estava usando. Simplesmente funcionava, enquanto no cc eu sentia que o modelo ficava muito "burro" após a compactação.
E a terceira coisa que notei foi o quanto as GUIs podem oferecer além das TUIs. Poder abrir o aplicativo diretamente no navegador do Cursor e fazer alterações de design com o Design Mode parecia intuitivo e me fez pensar em como UIs especializadas podem tornar a codificação agentica mais eficaz.
Construindo o Cursor com o Cursor
Desde que entrei no final de março, trabalho principalmente na janela de agente do Cursor 3 e a uso como minha ferramenta diária. Embora ainda ache que o cc é um produto legal com uma ótima equipe, notei que sua simplicidade tende a levar as pessoas a criar suas próprias abstrações em torno dele. No meu último emprego, parecia que toda semana anunciavam uma nova ferramenta orquestradora interna construída sobre o cc.
O @bcherny fala muito sobre essa ideia de "demanda latente":
"Existe uma ideia muito antiga em produto chamada demanda latente... você constrói um produto de forma que seja customizável, aberto o suficiente para que as pessoas o usem para outros casos. Então você observa como as pessoas o usam e constrói para atender a isso."
Era exatamente isso! As pessoas convergindo para ferramentas de orquestração expõem a demanda latente de que usar uma CLI faz de você, o humano, o orquestrador.
Mas todo fluxo de trabalho com agentes que eu tinha usado focava na coisa errada. Executar várias CLIs em uma GUI não era o objetivo. A abordagem que me interessava era construir confiança nos agentes.
Como ex-gerente de engenharia, percebi rapidamente que gerenciar agentes era semelhante a montar uma equipe de engenharia humana. Novos contratados precisam ser integrados para entender o código, mas também como o trabalho é feito. Eles chegam já treinados com habilidades adquiridas em experiências anteriores: como depurar, como escrever código e testes de alta qualidade e como se comunicar, entre outras.
Agentes são como novos contratados em um estado constante de amnésia e ignorância. Eles não lembram o que você diz e nunca aprendem algo novo. Mas podemos equipá-los com regras, habilidades, ferramentas e memória de longo prazo que aproximam isso. Eles são capazes, mas burros, e muito ensináveis. E vi seus modos de falha como oportunidades para ensinar tudo o que sei sobre engenharia rigorosa e profunda.
Porque quando não há rigor, os agentes farão tudo que for necessário para escrever o código que você pediu. E olha, eles escrevem muito. Paralelização ingênua só faz eles escreverem porcaria mais rápido.
Se quer ir rápido, vá fundo primeiro
Acredito que a orquestração de agentes pode ser produtiva. Mas precisamos ir fundo primeiro.
Estou abrindo o código do pstack, meu conjunto pessoal de habilidades e princípios de engenharia que uso todos os dias para construir o @cursor_ai. Comecei a desenvolver as primeiras iterações dessas habilidades em meus projetos paralelos e venho refinando desde então.
Baixe aqui: https://cursor.com/marketplace/cursor/pstack
Essas habilidades se tornaram algumas das mais usadas pela equipe do Cursor, então estou animado em compartilhá-las com todos vocês.
O pstack ensina agentes a serem mais rigorosos usando múltiplos modelos. Peguei todos os modos de falha que observei e os transformei em habilidades. O coração do plugin é o /poteto-mode, uma habilidade de ordem superior que dá aos agentes o plano certo a seguir para uma determinada tarefa. O objetivo não é maximizar LOC, mas o oposto: máximo impacto com o mínimo de código.
O rigor é aplicado abordando problemas da mesma forma que engenheiros experientes fazem. Por exemplo, uma ótima maneira de depurar é fazer uma busca binária no espaço do problema. Você começa com algumas hipóteses do que pode estar acontecendo e tenta eliminar sistematicamente cada uma até chegar à causa raiz. Se for difícil reproduzir, tenta forçar sinteticamente o bug a ocorrer. Ou adicionar instrumentação ou logs para verificar o estado do programa durante a execução.
Essas etapas formam um plano que pode ser usado por agentes para depurar problemas completamente, em vez de chutar, o que eles adoram fazer se você deixar. O pstack vem com várias habilidades e planos que permitem abordar a engenharia de software com esse mesmo nível de rigor. Atualmente, tenho planos para:
- Criação de habilidades e avaliações
- Trabalho autônomo
- Correção de bugs e análise forense em tempo de execução
- Desenvolvimento de funcionalidades
- Paridade visual e prototipagem
- E mais
Sempre que precisar de rigor, prefixe seu prompt com /poteto-mode. Por exemplo:
Você também pode invocar outras habilidades sob demanda:
- /how: quer um guia de como um subsistema realmente funciona.
- /why: quer saber por que algo foi construído dessa forma. usa seus MCPs disponíveis para consultar cada categoria de evidência em paralelo (controle de versão, rastreador de issues, documentação longa, chat em tempo real, observabilidade de infraestrutura, rastreamento de erros, analytics).
- /architect: está prestes a escrever código que cruza um limite de função e quer definir os tipos e estruturas de dados primeiro.
- /arena: quer N tentativas paralelas da mesma coisa e depois pegar as melhores partes de cada uma.
- /interrogate: quer que diferentes modelos revisem algo de forma adversarial.
- /tdd: está corrigindo um bug. escreva o teste que falha primeiro, depois a correção.
- /unslop: está limpando qualquer tipo de escrita de IA. faz com que eles falem de forma clara.
- /reflect: quer melhorar continuamente suas habilidades após conversas longas.
- /figure-it-out: fazendo algo incomum? projeta um plano rigoroso e auditável para a tarefa.
- /show-me-your-work: quer uma trilha de decisões revisável. registra decisões em um TSV que pode ser commitado.
E, finalmente, você pode criar sua própria habilidade de modo com /automate-me. Ele minera seus transcrições recentes, cria uma habilidade de modo personalizada a partir de como você trabalhou e roteia pelo pstack internamente.
O pstack funciona com qualquer ferramenta agentica de codificação, mas funciona especialmente bem em ferramentas com múltiplos modelos como o Cursor. Muitas habilidades usam fluxos de trabalho com múltiplos modelos para aproveitar os pontos fortes e fracos únicos de cada um. É orquestração de agentes, mas aplicada em profundidade, não em amplitude.
O gargalo com agentes é a verificação. Agentes podem escrever muito código rapidamente. Garantir que tudo esteja correto é extremamente difícil. Quando você consegue chegar lá, o verdadeiro paralelismo de agentes, como em uma fábrica escura para software, pode ser possível.
Mas primeiro, precisamos ir fundo e ser rigorosos. Acho que chegamos lá aumentando a confiança.
Experimente o pstack e me diga o que achou.
Zen e a Arte da Manutenção de Software
Essas habilidades me ajudam a me mover com mais confiança ao escrever código. Mas manter o código agora é um pesadelo com agentes escrevendo todo o código. Bugs, problemas de desempenho e solicitações de funcionalidades ainda levam tempo para serem resolvidos. E agora tem muito mais código!
Faço uso extensivo de automações do Cursor no Cursor. São agentes em nuvem que podem ser agendados ou executados em resposta a eventos, como novas mensagens em um canal do Slack. Um exemplo é meu bot Benny. Dei a ele as mesmas habilidades que tenho no pstack.
Benny ainda é um trabalho em andamento, mas minha visão é automatizar o máximo possível do processo de manutenção de software. A ideia é esta: se agora temos confiança para resolver problemas com o pstack de forma praticamente direta, com um bom grau de certeza de que a qualidade do PR é alta, certamente podemos automatizar também o feedback.
Essa fábrica começa com a triagem: coletar informações dos funcionários sobre relatos de bugs. Nós dogfoodamos muito o Cursor e, portanto, recebemos muitos feedbacks dos funcionários sobre nossos candidatos a lançamento. Benny entende anexos de imagens e vídeos, explora o código usando as habilidades do pstack e conversa com o relator para obter informações sobre etapas de reprodução, se não estiver claro.
Esta é uma parte importante do processo de relato de bugs. Sem etapas claras de reprodução e uma compreensão do que está quebrado, os agentes só podem adivinhar a solução. Precisamos dar a eles uma compreensão clara de exatamente onde e como algo quebra.
Após a triagem, Benny cria um ticket com suas descobertas ao examinar o código, o histórico do git para regressões recentes de bugs, o Slack para outras mensagens sobre o mesmo bug e até o Notion para decisões de design e produto sobre como uma funcionalidade deve funcionar: é um bug ou foi projetada para funcionar dessa forma?
Após o ticket ser criado, outro bot Benny o pega usando outra habilidade que criei, chamada /orchestrate.
Primeiro, ele tenta reproduzir o problema usando o computador. O Cursor Cloud Agents pode executar o próprio Cursor na nuvem, onde interagem com a área de trabalho, clicam em coisas e enviam entrada do teclado. Internamente, isso usa mais habilidades que criei para controlar nossos produtos programaticamente usando protocolos como CDP ou equivalentes.
Isso nos permite demonstrar se o relato de bug pode ser reproduzido. Se o bug for reproduzido de forma consistente, ele tenta corrigi-lo. Se for um problema de desempenho, Benny pode capturar traces de CPU e snapshots de heap antes e depois. Subplanejadores geram mais workers para verificar a correção usando habilidades do pstack e verificar o trabalho em relação ao ticket, se foi corrigido.
Workers adicionais são gerados nesta execução para gravar um vídeo do antes e depois, e, finalmente, um worker abre o PR para revisão com o vídeo na descrição.
Tudo isso ainda é um trabalho em andamento e há muito mais a fazer, mas estou animado em ter uma equipe de agentes para me ajudar a corrigir bugs com confiança enquanto durmo ou faço outras coisas. Tornar a revisão de código escalável é outra área importante, e acho que o Cursor terá alguns recursos interessantes em breve para ajudar.
Mas a chave para construir sua própria fábrica de software é a confiança. A menos que você confie em um agente para assumir um problema de ponta a ponta, incluindo a verificação, não é possível automatizar seus processos. À medida que você aumenta a confiança usando plugins como o pstack, que dão aos seus agentes mais profundidade em engenharia, pode começar a enfrentar problemas mais ambiciosos. Tentar paralelizar agentes em que você ainda não confia é um enorme desperdício de tokens e introduz mais porcaria no seu código.
Obrigado por ler!
