Cursor: integração de agentes de IA ao fluxo de desenvolvimento

Janela de agentes e infraestrutura - Apresentação

Apresentando o curso e o instrutor

Boas-vindas a mais um curso da Alura, desta vez sobre o Cursor, no qual vamos explorar o desenvolvimento de software e como podemos tirar melhor proveito das ferramentas que ele oferece para o nosso dia a dia como pessoas desenvolvedoras.

Sou Ricardo Bugan, Head de Produto e Desenvolvedor, e serei seu instrutor neste curso.

Definindo o projeto e explorando a nova interface do Cursor

Neste curso, vamos desenvolver um projeto da Ermex Locadora. Vamos conectar o Figma do projeto ao Cursor para aproveitar os MCPs, trazendo todo o contexto de layout. Com isso, vamos criar nosso próprio layout e permitir que nosso assistente de IA gere esse layout.

Nós vamos aproveitar a nova interface do Cursor. A novidade é a interface do gerenciador — a janela de agentes, ou seja, o gerenciador de agentes que agora temos na ferramenta. Ele não está limitado à IDE (Ambiente de Desenvolvimento Integrado); porém, também está acessível nela. Aqui, mantemos a janela aberta, funcionando e organizada. A janela de chat continua disponível, e agora contamos com a janela de agentes, em que reunimos todos os agentes em um único lugar para gerenciá-los em vários projetos, em paralelo, ao mesmo tempo.

Nós vamos explorar essa janela em profundidade: como personalizá-la, como personalizar nossos agentes, onde configurá-los, qual é a importância das regras, como criar comandos e qual é a diferença entre comandos e as skills (habilidades) em relação às próprias regras, entre outros pontos.

Executando na CLI e integrando em pipelines de CI/CD

Também veremos nosso agente em execução na CLI (Interface de Linha de Comando) e como poderíamos executá-lo dentro de um pipeline (esteira) de CI/CD (Integração Contínua/Entrega Contínua).

Vamos aproveitar este curso sobre o Cursor.

Janela de agentes e infraestrutura - Conhecendo e configurando a ferramenta

Apresentando o curso e a ferramenta cursor

Vamos iniciar este curso no qual exploraremos a ferramenta Cursor para criar um IDE de desenvolvimento que nos auxilie, como pessoas desenvolvedoras, na criação de aplicações. Veremos as capacidades da ferramenta e como utilizá-las da melhor forma para orientar nossos agentes e liberar nosso tempo para organizar o dia a dia, conversar com as partes interessadas (stakeholders), alinhar com o time o que está acontecendo e delegar o trabalho de codificação aos agentes.

Estamos no site do Cursor, onde podemos acompanhar as novidades. Essas atualizações podem ser vistas na seção de recursos e no seu blog (blog), que é mantido atualizado, explicando o que está acontecendo. A novidade mais recente apresentada é o Grok 4.5. Há uma associação com a SpaceX, e esse é um modelo disponibilizado quando acessamos a seção de preços. Existem diferentes planos. É possível usar gratuitamente, mas a versão que apresentaremos e utilizaremos é o plano individual, ou, no mínimo, o plano individual é necessário neste contexto, porque precisaremos dos MCPs, de skills (habilidades) e de outros recursos que essa versão oferece. Além disso, há aumento de limites tanto para Grok quanto para Composer, que são modelos de IA oferecidos pelo próprio Cursor. O Cursor disponibiliza vários modelos, mas esses, por conta das associações, são destacados, embora possamos utilizar outros modelos também.

Acompanhando novidades e conhecendo a nova interface

Na área do blog (blog), podemos verificar as novidades do Cursor. Já deixamos uma aba aberta com a atualização de abril de 2026, quando foi lançada a nova versão do Cursor, que é a versão que estamos utilizando e na qual nos concentraremos. Entre as novidades, está a centralização de todos os agentes em um único lugar. Essa ideia se refere a uma nova interface criada para termos múltiplos espaços de trabalho em um mesmo ambiente.

Ao abrir essa interface, a aparência pode remeter a outras ferramentas que já vimos. Cloud Code, Antigravit e Codecs possuem uma interface semelhante, e o Cursor adotou uma abordagem parecida. O Cursor deixou de ser apenas um IDE; hoje, essa camada de agentes também está integrada ao IDE. Ao clicarmos na lateral, abrimos o IDE. Como acabamos de configurá-lo na máquina, algumas telas iniciais aparecem, que podemos ignorar, e então abrimos o projeto para visualizá-lo como em um IDE.

Nosso projeto atual está vazio. Podemos abrir uma página, escolher o projeto e, neste caso, selecionar o projeto Air Max. Ao abrirmos, a página estará vazia. Essa é a interface mais focada em IDE. Como trabalhamos com uma pasta vazia, a aparência lembra bastante o VS Code, com tema claro, e a área do agente permanecia na lateral, onde modificávamos esse agente no contexto da pasta do projeto em que estávamos.

Agora, com a nova interface, temos vários repositórios listados na lateral esquerda e podemos gerenciar todos os chats (conversas) e todas as conversas em paralelo. Assim, conseguimos trazer e manipular diferentes repositórios ao mesmo tempo. Essa é a versão da ferramenta que utilizaremos. Focaremos principalmente nessa nova interface, que será o ambiente com o qual trabalharemos. Ainda assim, ao lado, segue disponível o tema do IDE, que abre a versão anterior (como era antes), a qual continua a receber atualizações e pode ser utilizada sem problemas.

Preparando o projeto air max e iniciando a configuração

Antes de começarmos a criar nosso projeto, mencionamos que trabalharemos no Air Max e, para isso, já temos o design no Figma. Você terá acesso ao link desse Figma, e construiremos o projeto a partir dele. Para isso, precisaremos configurar o Cursor. Antes de pedirmos para criar qualquer coisa na pasta recém-criada, vamos realizar a configuração.

Para configurar, acessamos a área de personalização, que exibe várias abas para ajuste. Podemos, por exemplo, ir aos MCPs e criar um novo MCP; isso abrirá a configuração dos MCPs, onde podemos editar o JSON e definir o que for necessário. Em alternativa, podemos acessar o Marketplace, em Browse Marketplace (navegar pelo Marketplace), escolher Figma (que é o nosso caso) e apenas adicionar esse MCP ao Cursor. Ao adicionarmos o plugin (extensão), tudo já vem pronto: são trazidas todas as skills (habilidades) e todas as ferramentas, com o Figma instalado. Assim, o MCP do Figma fica configurado.

Percebemos que a aba lateral aparentemente não se atualiza em tempo real. Por isso, voltamos à parte de personalização e MCP para recarregar. Agora o Figma aparece, mas a configuração exibida na lateral não foi alterada. Fechamos essa área e testamos reabrir, considerando adicionar um novo servidor. Não é o caso: trata-se de uma configuração isolada para criar um servidor específico. Podemos manter nossos MCPs globais carregados.

Autenticando o figma e estabelecendo conexões

Com o Figma já listado, a interface indica que essa integração precisa de atenção, pois devemos autenticar o Figma. Selecionamos Conectar; o fluxo abre o navegador e inicia a solicitação de autenticação usando a metodologia OAuth, pedindo a conexão via OAuth.

A autorização já está concluída, porque já tínhamos o Figma carregado e também instalado localmente em nossa máquina. Ele deve ter herdado essa configuração, então o Figma já deveria estar configurado. Ao abrirmos no Cursor, ainda aparece que precisa de autorização. Se atualizarmos, ele informa que está autenticado localmente. Localmente está conectado, mas na nuvem ainda é possível autenticar. Podemos realizar uma segunda autenticação para a nuvem; ao abrir e concluir, ficamos com duas autenticações: uma local e outra na nuvem.

No Figma, conectaremos a ferramenta apenas realizando o login (autenticação). Se você estiver com o Figma instalado localmente, essa parte local será a necessária. Se não tivermos o Figma instalado localmente e o utilizarmos apenas na web, conectaremos à versão em nuvem. Aqui conectamos as duas, então, de qualquer lugar, poderemos conectar e usar esse Figma.

Habilitando ferramentas do figma e explorando o marketplace

Além disso, já temos as ferramentas disponíveis. Podemos capturar tela, obter o contexto de design, o contexto de motion (animação), acessar um arquivo FigJam, exportar um vídeo, acessar as libraries (bibliotecas) internas, fazer upload (envio) de assets (itens) ou download (baixa) de assets (itens). Isso é muito bom, pois será possível obter todas as imagens que temos naquele arquivo do Figma.

Com isso, o Figma está configurado e podemos escolher, na lateral, ativar ou não cada ferramenta. Se não quisermos que faça download (baixa) de assets (itens), desativamos essa opção. Se não quisermos que modifique o Figma, também desativamos o upload (envio) de assets (itens). Assim, escolhemos as ferramentas às quais daremos acesso ao Cursor para que ele possa utilizá-las.

Essa é a primeira configuração que precisamos fazer: instalar o MCP (Model Context Protocol, protocolo de contexto de modelos) do Figma para termos acesso a todas as ferramentas e recursos do Figma. Isso pode ser feito localmente, caso o Figma esteja instalado, ou na nuvem; em ambos os casos, a conexão será estabelecida.

Se voltarmos ao Marketplace (mercado), há muitos outros MCPs e ferramentas que podemos conectar ao Cursor: Datadog, Gmail, Google Drive, Amplitude (se estivermos fazendo algo que precise de Amplitude), AWS, Clore, Amplify, Location Service, entre vários serviços diferentes da AWS que podemos conectar. Podemos buscar as ferramentas que quisermos para integrar ao Cursor.

Configurando modelos disponíveis e preferências de uso

Outra configuração interessante, neste início, é ir ao ícone de engrenagem nas configurações do Cursor e acessar a seção de modelos. Lá são exibidos todos os modelos habilitados para uso no momento. Há o Cursor Grok 4.5, Composer 2.5, Opus 5 (da Anthropic), GPT 5.6, entre outros. Podemos habilitar e desabilitar os modelos que quisermos usar. Se houver um modelo com o qual você esteja mais acostumado e cuja resposta seja suficiente, pode escolhê-lo, inclusive modelos mais antigos ou mais leves. Por exemplo, o Gemini 3.5 pode ser habilitado.

Um recurso interessante nessa configuração: ao deixar o ponteiro do mouse sobre o nome do modelo, aparecem informações como se ele é rápido ou não, o tamanho da janela de contexto e a indicação de caso de uso. Por exemplo, o Grok é indicado para alto esforço (tarefas mais difíceis), enquanto o Composer é adequado para uso no dia a dia, com uma janela de contexto diferente, possivelmente menor. O Opus oferece uma janela de contexto maior e também é voltado para alto esforço. Assim, a interface apresenta os casos de uso e como cada modelo se comporta.

Por exemplo, o Fable tem 300.000 tokens (unidades de contexto) de janela de contexto e é indicado para alto esforço. Há um aviso de política especial de retenção de dados, justamente por ser um modelo da Anthropic, não do Cursor, da SpaceX.

Definindo o roteamento e iniciando a criação do projeto

Aqui configuramos todos os modelos que queremos utilizar e vemos a quais modelos temos acesso. Na parte superior, no nosso modelo de tarefa, podemos explorar o subagente, isto é, o modelo do subagente. Quando solicitamos algo ao Cursor, o agente principal, no modo padrão, analisa todos os modelos habilitados e escolhe automaticamente o ideal para cada tarefa. Ele faz um roteamento na tarefa principal para selecionar o melhor modelo de LLM a usar.

Se não quisermos usar esse roteamento, podemos optar por sempre usar o mesmo modelo para manter consistência nas respostas. Basta ir ao padrão e trocar para o modelo desejado. Por exemplo, escolher apenas o Composer 2.5. Com isso, todos os subagentes usarão sempre esse modelo, sem roteamento. Limitamos a capacidade ou garantimos que a resposta passe sempre por aquele modelo, o que pode ser uma escolha por conformidade, confiança ou consistência das respostas.

Com o modelo configurado e o Figma com o MCP (Model Context Protocol, protocolo de contexto de modelos) configurado, precisamos começar a criar nosso projeto. Já selecionamos a pasta, mas ela está vazia. Precisamos começar a montar o projeto. Antes, queremos assegurar que algumas coisas ocorram para viabilizar essa montagem. Para isso, teremos de aplicar regras no Cursor. Isso veremos no próximo vídeo.

Janela de agentes e infraestrutura - Criando as regras do projeto

Iniciando o projeto e acessando regras

Vamos criar nossa regra. Como mencionamos, queremos iniciar este projeto. A pasta do projeto estava vazia; quando abrimos a IDE (Ambiente de Desenvolvimento Integrado), não havia nada na pasta do projeto. Vamos reabrir aqui, porque a havíamos fechado no outro vídeo. Nosso projeto está vazio.

O que queremos fazer? Queremos adicionar uma regra para que, quando solicitarmos ao nosso assistente a criação da estrutura do projeto, ela já seja criada da maneira correta. O que podemos fazer? Como vimos no vídeo anterior, podemos acessar a seção Customize (personalizar) e, nela, a parte de Rules (regras). Há uma guia de regras para nosso agente e podemos abrir a documentação, que nos leva à página de documentação do Cursor diretamente na própria interface.

Definindo regras globais no sistema

Essas regras em Customize (personalizar) > Rules (regras) ficam em nível de system (sistema); podemos entendê-las como regras globais. Podemos adicionar uma nova regra, indicando o que ela faz e o texto dessa regra. Por exemplo: sempre que iniciarmos um projeto de front-end (interface de cliente), vamos limitar a front-end (interface de cliente), usar Vite. Confirmamos, e essa é a regra. É algo simples, que ficará sempre disponível, marcada como “regra de usuário”. Na documentação, “regra de usuário” é uma regra global que está no environment (ambiente) do nosso agente, ou seja, no chat.

Para registrar essa ideia como uma regra global simples, poderíamos deixar o texto assim:

Sempre que for iniciar um projeto frontend use o VITE

Criando regra específica do projeto via comando

Se quisermos uma regra específica para o projeto, podemos vir ao nosso chat (bate-papo). Já estamos com o projeto selecionado, pois escolhemos a pasta neste PC (computador). Temos um comando, acionado com a barra “/”. Com a barra “/”, temos o comando create rule, que cria uma regra para o projeto.

Primeiro, chamamos o comando:

/create rule

Em seguida, descrevemos a regra que queremos criar para este repositório, sobre a arquitetura e organização de pastas:

/create rule Crie uma regra para esse projeto, sobre a arquitetura e organização de pasta

Vamos criar uma regra para este projeto sobre a arquitetura e organização de pastas. Já deixamos pronto o texto que queremos inserir na regra. Vamos copiar esse texto, colá-lo no nosso prompt (prompt) e solicitar a criação dessa regra.

Gerando arquivos de regra no projeto

Vamos analisar em detalhes o que está sendo feito e quais são as regras que estamos definindo. Basicamente, vamos deixar a ferramenta organizar. Vamos criar uma regra de arquitetura na pasta do projeto com “always apply true” (sempre aplicar: verdadeiro), conforme o conteúdo que enviamos.

Ao criar, é gerada a estrutura “.cursor” e, dentro dela, a pasta “rules”. Se formos à IDE (Ambiente de Desenvolvimento Integrado), veremos que foi criada a pasta “.cursor” e, dentro dela, a pasta “rules”. A regra é criada conforme o comando que solicitamos com /create rule. Esse comando cria uma regra localmente no projeto.

O cabeçalho da regra (frontmatter) fica logo no topo do arquivo e, como queremos que ela sempre seja aplicada, definimos alwaysApply: true:

---
description: Regras de Estrutura e Arquitetura do Projeto
globs: 
alwaysApply: true
---

Comparando edição de regras globais e locais

Se, em vez disso, usarmos a regra de personalização em Customize (personalizar) e adicionarmos uma regra, ela será criada no nosso system (sistema) e aplicada a todos os projetos de maneira global. Particularmente, não gostamos de como a edição dessa regra global funciona aqui; editar é ruim. Se quisermos, por exemplo, pegar o mesmo texto que havíamos colocado e colá-lo ali — um texto grande, com várias regras menores, cabeçalho da regra, como será aplicada, estrutura do projeto e estrutura de pastas — não é fácil manipular e editar por essa interface.

Nesse sentido, as regras globais são úteis: ficam disponíveis e servem para todos os projetos. Nota-se que o time da Cursor, ao criar essa ferramenta, pensou nas regras globais como itens muito específicos ou pontuais, como a linha de uma regra que pode ser aplicada de forma geral ou com alguma validação de projeto. Já a regra específica do projeto, que está aqui no arquivo estrutura e a arquitetura.mdc, por estar dentro da IDE (Ambiente de Desenvolvimento Integrado), tem uma forma e aparência muito mais fáceis de editar.

Entendendo a estrutura e aplicação das regras

Perfeito. Agora, vamos entender qual regra definimos e como essas regras funcionam.

O que uma regra precisa ter? Ela deve conter um cabeçalho. Aqui em cima, temos o cabeçalho, que sempre começa com --- e inclui algumas propriedades. A propriedade description informará ao agente em quais momentos a regra deve ser utilizada. Adicionamos também a propriedade always apply, pois, neste caso, o agente não lerá a description para decidir se deve aplicar a regra; ele sempre utilizará a regra porque always apply está definido como true. Assim, a regra será sempre aplicada. A regra vem como texto em Markdown (linguagem de marcação) logo abaixo.

Documentando a regra de arquitetura do Hermex

Regra de estrutura e arquitetura do projeto. Este projeto estabelece especificações e regras para a estrutura de pastas, caminhos de importação e configurações do Vite no projeto Hermex.

Para deixar isso explícito no corpo do documento de regras, inserimos a seção principal e, logo na sequência, detalhamos a estrutura de pastas do frontend:

# Regras de Estrutura e Arquitetura do Projeto

Este documento estabelece as especificações e regras para a estrutura de pastas, caminhos de importação e configurações do Vite no projeto Hermex.

## 1. Estrutura de Pastas do Projeto (Frontend)

O projeto deve ser organizado estritamente por responsabilidade (domain/responsibility-based) e não por tipo genérico de arquivo, garantindo escalabilidade e modularidade.

Detalhando a estrutura de pastas e aliases

Estrutura de pastas do projeto. O projeto deve ser organizado estritamente por responsabilidade, e não por tipo genérico de arquivo, garantindo escalabilidade e modularidade. A estrutura dentro da pasta "source" deve ser a seguinte:

• "components"
• "contexts"
• "hooks"
• "pages"
• "services"
• e assim por diante.

Em seguida, apresentamos a descrição de cada um desses itens.

Para tornar isso concreto no documento, incluímos o mapeamento da pasta src/:

src/
├── components/     # Componentes reutilizáveis de apresentação ou negócio
├── contexts/       # Provedores de estado globais (React Context)
├── hooks/          # Hooks customizados contendo lógica de negócio
├── pages/          # Componentes de rota (um arquivo principal por rota)
├── services/       # Inicialização de clientes externos (supabase, axios, etc.)
├── stores/         # Gerenciamento de estado global da aplicação (Zustand)
├── styles/         # Estilos globais e tokens de design (Tailwind, etc.)
├── utils/          # Funções puras de apoio e dados (sem estado do React)
└── types/          # Interfaces e declarações de tipos do TypeScript por domínio

Como parte das regras, também indicamos que os caminhos de importação devem usar alias configurado no Vite, evitando imports relativos frágeis. Esse ponto aparece no documento de regras para que a ferramenta e os colaboradores sigam um padrão consistente:

// vite.config.ts
import path from 'path';

export default defineConfig({
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src')
    }
  }
})

E, para harmonizar com o TypeScript, definimos os mesmos aliases no tsconfig:

"compilerOptions": {
  "baseUrl": ".",
  "paths": {
    "@/*": ["src/*"]
  }
}

Centralizando regras e objetivos do projeto

Essas regras — e tudo o que formos gerando aqui, como regras, skills (habilidades) e comandos — ficarão acessíveis. O objetivo é demonstrar a funcionalidade: como criamos e onde fica cada um desses elementos.

Temos, então, a primeira regra, que define a estrutura do projeto. Se criarmos o projeto agora, esperamos que ele siga essas regras.

Configurando modos de aplicação e globs

Um ponto interessante: no cabeçalho, usamos always apply, e há também a condição de quando a regra será aplicada, configurada por um menu suspenso, que, por enquanto, está em always apply (aplicar sempre). Se selecionarmos apply intelligently (aplicar de forma inteligente), o sistema tentará ler a description para decidir se usará a regra. Se escolhermos apply in specified files ou specific files (aplicar em arquivos especificados), o sistema tentará aplicar a regra com base em um padrão de arquivo. Podemos, por exemplo, definir que todos os arquivos .js sigam essa regra; ao indicar *.js, o sistema entenderá que a regra se aplica a todos os arquivos .js. Ao fazer isso, observamos que o arquivo é alterado e a descrição é removida. Também existe a opção apply manually (aplicar manualmente), que exige que invoquemos explicitamente a regra quando quisermos utilizá-la. Veremos casos de uso interessantes para essa opção.

Para ilustrar a configuração de aplicação por padrão de arquivo (globs), teríamos um cabeçalho como este:

---
description: Regras de Estrutura e Arquitetura do Projeto
globs: *.js
alwaysApply: false
---

Caso optemos por aplicar de forma inteligente, precisaremos da description. Assim, neste documento, vamos pegar a mesma description e colocá-la abaixo como texto para que seja utilizada. O cabeçalho garantirá que a regra seja aplicada quando quisermos, no momento em que quisermos, e essas são as opções de aplicação de regras.

Exemplificando cabeçalhos para aplicação inteligente e sempre ativa

Um exemplo de cabeçalho com a descrição explícita para orientar a aplicação inteligente seria:

---
description: Este documento estabelece as especificações e regras para a estrutura de pastas, caminhos de importação e configurações do Vite no projeto Hermex.
globs: 
alwaysApply: false
---

No nosso caso, queremos always apply, e, portanto, não é necessária a description, pois a regra será aplicada sempre. Voltamos, então, o cabeçalho para o modo “sempre aplicar”:

---
description: Regras de Estrutura e Arquitetura do Projeto
globs: 
alwaysApply: true
---

Iniciando a criação da estrutura do projeto

Nosso projeto já está com a primeira regra definida. Agora podemos solicitar: iniciar a estrutura de um projeto front-end (camada de interface), para Hermex. Em seguida, o sistema deve criar toda a estrutura do projeto, já seguindo a regra criada, de forma que o projeto seja gerado como desejamos.

Para acionar essa criação, podemos enviar a instrução diretamente no chat:

Inicie a estrutura de um projeto front-end para o Hermex

Ao trabalhar em um projeto novo, o ideal é garantir primeiro as regras desejadas: criamos as regras e, só então, pedimos para iniciar a criação da estrutura. Assim, economizamos tokens (unidades de contagem), pois a estrutura será criada diretamente no formato esperado, e garantimos a consistência do repositório. Fazemos isso para evitar solicitar a criação e, de repente, receber um conjunto de bibliotecas ou dependências indesejadas por falta de regras a seguir. Portanto, criamos as regras, deixamos tudo configurado no projeto e, depois, iniciamos a criação efetiva do projeto.

Vamos deixar a criação em andamento e retornaremos em breve.

Sobre o curso Cursor: integração de agentes de IA ao fluxo de desenvolvimento

O curso Cursor: integração de agentes de IA ao fluxo de desenvolvimento possui 111 minutos de vídeos, em um total de 42 atividades. Gostou? Conheça nossos outros cursos de IA para Desenvolvimento de Software em Inteligência Artificial, ou leia nossos artigos de Inteligência Artificial.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Janela de agentes e infraestrutura
• Worktrees e habilidades
• Arquitetura da ferramenta
• Fluxo paralelizado
• Cursor CLI