Preciso desabafar sobre uma coisa. Antes da minha entrevista na @cursor_ai, eu nunca tinha usado o Cursor de verdade.
Na Meta, o Claude Code estava explodindo. Cheguei a pagar um plano pessoal de US$ 200 por mês para meus projetos paralelos. Adorava a simplicidade e como me sentia produtivo rapidamente. O ponto crucial para mim era desenvolver meu próprio conjunto de habilidades que transformavam o cc em praticamente qualquer coisa que eu quisesse. Cheguei até a começar a desenvolver minha própria ferramenta de orquestração de agentes baseada nisso.
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á uso o vscode há tantos anos que a maioria dos atalhos de teclado ainda estava no meu contexto, então me readaptar à IDE não foi tão difícil. Mas não vou mentir. Nas primeiras horas, senti falta da CLI. Clicar nas coisas parecia quase primitivo. No entanto, algumas coisas realmente me chamaram a atenção.
Primeiro, os modelos que eu usava na época — Opus e Codex — pareciam mais inteligentes, de alguma forma. E era incrível poder alternar entre modelos rapidamente e usar ambos ao mesmo tempo em diferentes partes 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 interface parecia muito natural. Melhor ainda era a capacidade de gerar subagentes de diferentes modelos, aproveitando o melhor dos dois mundos em uma só conversa.
Segundo, a compactação era incrivelmente rápida. Como usuário do cc, estava acostumado com a compactação levando muitos minutos, e vivia em estado de vigilância constante do meu contexto e uso de planos. Fiquei totalmente chocado com a velocidade no Cursor. Tanto que praticamente nunca precisei me preocupar com quanto contexto estava usando. Simplesmente funcionava, enquanto no cc, muitas vezes sentia que o modelo ficava extremamente limitado após a compactação.
E a terceira coisa que notei foi o quanto as interfaces gráficas (GUIs) podem oferecer em comparação com as interfaces de terminal (TUIs). Poder abrir o aplicativo diretamente no navegador do Cursor e fazer alterações de design com o Modo Design era intuitivo e me fez pensar em como interfaces especialmente projetadas podem tornar a codificação com agentes mais eficaz.
Construindo o Cursor com o Cursor
Desde que entrei no final de março, tenho trabalhado principalmente na Janela de Agente do Cursor 3, usando-a como minha ferramenta principal. Embora ainda ache que o cc é um produto interessante com uma ótima equipe, notei que sua simplicidade tende a levar as pessoas a querer criar suas próprias abstrações em torno dele. No meu último emprego, parecia que toda semana era anunciada uma nova ferramenta de orquestração 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 personalizável, que seja aberto o suficiente para que as pessoas possam usá-lo de maneiras não previstas para outros casos de uso. Então você observa como as pessoas o usam de forma criativa e constrói para atender a essa demanda."
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 todos os fluxos de trabalho com agentes que eu tinha usado focavam na coisa errada. Executar várias CLIs em uma interface gráfica perdia completamente o sentido. A abordagem que me interessava era construir confiança nos agentes.
Como ex-gerente de engenharia, rapidamente percebi que gerenciar agentes era semelhante a construir 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á pré-treinados com habilidades adquiridas em experiências passadas: como depurar, como escrever código e testes de alta qualidade e como se comunicar, para citar algumas.
Agentes são como novos contratados em um estado constante de amnésia e ignorância. Eles não se lembram do que você lhes diz e nunca aprendem nada de novo. Mas podemos equipá-los com regras, habilidades, ferramentas e memória de longo prazo que podem aproximar 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 fazer engenharia profunda e rigorosa.
Porque quando não há rigor, os agentes farão de forma bajuladora tudo o que for preciso para escrever o código que você pediu. E, cara, eles podem e vão escrever uma tonelada dele. A paralelização ingênua só os faz escrever porcaria mais rápido.
Se você quer ir rápido, vá fundo primeiro
Acredito que a orquestração de agentes pode ser feita de forma produtiva. Mas precisamos ir primeiro em profundidade.
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 iterações iniciais dessas habilidades em meus projetos paralelos e venho refinando-as desde então.
Obtenha aqui: https://cursor.com/marketplace/cursor/pstack
Essas habilidades se tornaram algumas das mais usadas pela equipe do Cursor, então estou animado para compartilhá-las com todos vocês.
O pstack ensina os 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 fornece aos agentes o roteiro correto a seguir para uma determinada tarefa. O objetivo não é o máximo de linhas de código, mas o oposto: máximo impacto com o mínimo de código.
O rigor é aplicado abordando os problemas da mesma forma que engenheiros experientes. 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 sistematicamente descartá-las até chegar à causa raiz real. Se for difícil reproduzir, você pode tentar forçar sinteticamente o bug a ocorrer. Ou adicionar instrumentação ou logs de console para verificar o estado do programa enquanto ele é executado.
Esses passos formam um roteiro que pode ser usado pelos agentes para depurar minuciosamente, em vez de chutar, o que eles adoram fazer se você deixar. O pstack vem com muitas habilidades e roteiros que permitem abordar a engenharia de software com esse mesmo nível de rigor. Atualmente, tenho roteiros 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 opcionalmente invocar as outras habilidades sob demanda:
- /how: você quer um passo a passo de como um subsistema realmente funciona.
- /why: você 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, data warehouse de análises).
- /architect: você está prestes a escrever código que cruza um limite de função e quer definir os tipos e estruturas de dados primeiro.
- /arena: você quer N tentativas paralelas para a mesma coisa e depois pegar as melhores partes de cada uma.
- /interrogate: você quer que diferentes modelos revisem algo de forma adversarial.
- /tdd: você está corrigindo um bug. escreva o teste que falha primeiro, depois a correção.
- /unslop: você está limpando qualquer tipo de escrita de IA. faz com que eles falem de forma clara e direta.
- /reflect: você quer melhorar continuamente suas habilidades após conversas longas.
- /figure-it-out: fazendo algo incomum? projeta um roteiro rigoroso e auditável para a tarefa.
- /show-me-your-work: você quer uma trilha de decisões revisável. registra decisões em um arquivo tsv que pode ser commitado.
E, finalmente, você pode criar sua própria habilidade de modo com /automate-me. Ele minera seus transcripts recentes, elabora um esboço de habilidade "seu-modo" a partir de como você trabalhou e roteia através do pstack internamente.
O pstack funciona com qualquer ferramenta de codificação agentica, mas funciona especialmente bem em ferramentas multimodelo como o Cursor. Muitas das habilidades usam fluxos de trabalho multimodelo para aproveitar os pontos fortes e fracos únicos de cada modelo. É orquestração de agentes, mas aplicada em profundidade primeiro, em vez de largura.
O gargalo com agentes é a verificação. Agentes podem escrever uma grande quantidade de código rapidamente. Garantir que tudo esteja correto é extremamente difícil. Quando você conseguir 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 os agentes escrevendo todo o código. Bugs, problemas de desempenho e solicitações de funcionalidades ainda levam tempo para serem resolvidos. E agora há muito mais código!
Faço uso extensivo das 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.
O 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 de uma vez" a maioria dos problemas com o pstack, com um bom grau de certeza de que a qualidade do PR é alta, certamente podemos automatizar o feedback também.
Esta fábrica começa sua vida com a triagem: coletando informações dos funcionários sobre relatórios de bugs. Nós mesmos usamos muito o Cursor, então recebemos muitos feedbacks dos funcionários sobre nossos candidatos a lançamento. O 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 as 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 um entendimento do que está quebrado, os agentes só podem chutar a solução. Precisamos dar a eles uma compreensão clara de exatamente onde e como quebra.
Uma vez triado, o Benny cria um ticket com suas descobertas ao olhar 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 através do uso do computador. Os Cloud Agents do Cursor podem executar o próprio Cursor na nuvem, onde interagem com a área de trabalho, clicam em coisas e enviam entrada de teclado. Internamente, isso usa mais habilidades que fiz para controlar nossos produtos programaticamente usando protocolos como CDP ou equivalente.
Isso nos permite demonstrar se o relatório de bug pode ser reproduzido. Se ele reproduzir o bug de forma consistente, ele tenta corrigi-lo. Se for um problema de desempenho, o Benny pode capturar traces de CPU e snapshots de heap antes e depois. Subplanejadores geram mais workers para verificar a correção usando as habilidades do pstack e verificando 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.
Isso ainda é um trabalho em andamento e há muito mais a fazer, mas estou animado por 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 grande área, 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ê possa confiar em um agente para assumir um problema do início ao fim, incluindo a verificação, você não pode automatizar seus processos. À medida que você aumenta a confiança usando plugins como o pstack, que dão aos seus agentes mais profundidade de engenharia, você pode começar a enfrentar problemas mais ambiciosos. Tentar paralelizar agentes nos quais você ainda não confia é um enorme desperdício de tokens e introduz mais porcaria no seu código.
Obrigado por ler!
