Cursor, Kiro, ChatGPT: três harness, uma arquitetura

작성자

카테고리:

← 피드로
DEV Community · Tiago Vilas Boas (Montanha) · 2026-09-18 개발(SW)

Toda semana alguém me pergunta: “qual IDE com IA você usa?”. A resposta curta é “Cursor”. A resposta real é que Cursor é só a interface. O que faz funcionar é um vault Logseq que serve de memória, skills compartilhadas entre IDEs, e um orquestrador que decide o que vai pra onde.

Esse orquestrador é o Grok Bot, que permite criar agentes especializados com instruções persistentes dentro do Cursor. Pense nele como um ChatGPT customizado que vive dentro do Cursor: orquestra Cloud Agents, executa shell, e me avisa o que precisar de atenção. Com Kiro e ChatGPT, sou eu quem carrega o contexto manualmente.

Se você está pagando $20 aqui, $60 ali, e cada ferramenta vive numa ilha sem saber o que a outra fez ontem, esse post é pra você.

Índice

1. A arquitetura (não as ferramentas)

A maioria dos artigos de “Cursor vs Copilot vs Kiro” trata cada ferramenta como ilha. O meu setup funciona diferente:

Arquitetura: três harness, uma memória

O ponto: Kiro e Cursor consultam o mesmo cérebro e seguem as mesmas regras. ChatGPT fica isolado pro pessoal. O Grok Bot orquestra dentro do Cursor — com Kiro e ChatGPT, sou eu quem conecta os contextos.

2. Por que criei essa arquitetura

O problema que eu tinha:

  • Contexto perdido: toda sessão começava do zero
  • Ilhas desconectadas: Cursor não sabia o que eu fiz no ChatGPT ontem
  • Repetição de regras: mudava uma config, esquecia de mudar nas outras
  • Trabalho vazando pro pessoal: às 22h aparecia contexto do trampo no chat pessoal

O que eu queria:

  1. Uma memória central que todas as ferramentas consultam
  2. Skills que evoluem e valem em todos os lugares
  3. Separação clara entre trabalho/dev pessoal/vida
  4. Um ponto de orquestração que sabe o que vai pra onde

Por que bots especializados (não um bot genérico):

Esses bots vivem no Grok Bot. O ## 5 mostra cada um com seu papel. O ponto aqui é o porquê de criar vários ao invés de um só.

Um bot genérico tenta fazer tudo e acaba medíocre em tudo. Cada bot meu tem contexto delimitado, instruções específicas, e menos alucinação — quanto mais específico o domínio, menos o modelo inventa.

O pattern que emergiu:

Generalista (Chefe de gabinete)
    └── decide qual especialista chamar
         ├── Código (PRs, CI)
         ├── Vitrine (artigos, GitHub)
         ├── Inbox (emails, agenda)
         └── [domínio] (hobby, side project)

Enter fullscreen mode Exit fullscreen mode

Não planejei assim. Comecei com 1 bot, vi que ficava sobrecarregado, fui separando por domínio. Depois de 6 meses: 8 bots, cada um com sua especialidade.

3. O cérebro: Logseq hub-first

Muita gente associa RAG com embeddings e pgvector. O meu é mais simples: um vault Logseq com convenção de hubs.

Scope Hub O que vive ali pessoal pessoal/_hub.md Identidade, valores, mentoria, hobbies carreira carreira/_hub.md Portfolio, Staff track, artigos ops ops/_hub.md Incidentes, runbooks, squads meta meta/rag-contract.md Regras do vault, contratos

Regra hub-first: qualquer pergunta de domínio começa pelo hub do scope. O agent abre o _hub.md, segue os links canônicos, e só então faz grep se precisar.

Separação código vs memória:

  • Pergunta sobre como funciona o PaymentService? → Graphify (code graph)
  • Pergunta sobre o que decidi no incidente X? → Logseq (hub-first)

Por que não embeddings? Git-versioned, sem drift, debugável, cross-harness. Embeddings ficam no roadmap. Hub-first resolve a maior parte dos meus casos e custa zero infra.

4. Skills e steerings: regras que escalam

Tenho ~30 skills em ~/.cursor/skills/. Kiro e Cursor apontam pro mesmo path — refino uma vez, vale nos dois.

Skills: ativo manualmente

Skill O que faz security-audit OWASP ASVS 5.0, três portas de disclosure, hunt mode pra IDOR clean-code-review Lentes KISS, YAGNI, DRY, SRP + contexto calibrado pro time incident-analysis Fluxo Jira→ADO→Grafana→Sentry→banco, incident graph obrigatório write-for-dev-community Voz editorial, gate G0-G3, estrutura DEV.to

O pattern: skill + KB + runbooks. A skill security-audit não é só prompt — ela consulta o vault e tem docs vinculados: triage de falso-positivo, regras de disclosure, filtros de bounty.

Case real: numa sexta-feira, a skill de code review pegou um PR de reembolso com CI verde. Mas consultou as regras de domínio e identificou que faltava uma validação de período de carência. O comentário foi direto, o dev corrigiu, e evitou um bug em produção. Skill pagou o investimento naquela semana.

Exemplo real de skill (sanitizado): clean-code-review no gist — mostra a estrutura, o prompt principal e como o contexto do time é consultado.

Steerings: disparam sozinhas

Steering Tipo O que faz jira-issue-naming always Convenção de título padronizada grafana-dashboard-patterns fileMatch 10 regras pra criar dashboard confluence-page-location always Sabe onde cada doc deve ir

A diferença:

Skill Steering Ativação Manual Automática Escopo Domínio amplo Tarefa específica Compartilha Kiro + Cursor Só Kiro (por enquanto)

5. Grok Bots e agents: orquestração

Grok Bots

Bot Papel Chefe de gabinete Orquestra, corta escopo Código PRs pequenos, CI verde Vitrine GitHub profile, DEV.to Inbox Gmail + Calendar em lote AppSec Dependabot, Sentry quente + 3 side projects Quinto, LotRace, IronToy

Limitação honesta: o Grok Bot vive dentro do Cursor — não pilota Kiro nem ChatGPT. Ele executa Cloud Agents e Shell, e me diz o que fazer nos outros harnesses. A conexão entre eles sou eu.

Agents no Kiro

Cap duro: ≤3 agents. Domínio fica em skills, não em mais agents.

Agent Modelo Papel montanha-staff Opus 5 Gate Staff: SHIP/REVISE/SPLIT back-specialist Sonnet 5 Backend front-specialist Sonnet 5 Frontend

Por que só 3? Agent é caro (contexto, latência). Skill é barata (texto sob demanda). O pattern: agent orquestra, skill informa.

6. MCPs: o tecido conectivo

Model Context Protocol permite que Kiro e Cursor falem com sistemas externos.

Cursor: graphify, logseq-kb, jira, azure-devops, grafana, sentry, context7, git, browser-tools

Kiro: graphify, logseq-kb, jira, azure-devops, grafana, sentry, context7, git, browser-tools

ChatGPT: no meu setup, o contexto ainda é manual. Forte em mentorias, planilhas, Canvas.

Exemplo de investigação: recebo um card de bug. No Kiro:

  1. jira_get_issue → descrição e anexos
  2. repo_pull_request → PR relacionado
  3. grafana → logs do horário
  4. sentry → stacktrace
  5. banco → confirma hipótese
  6. logseq_write_file → documenta no vault

Tudo sem trocar de aba. O contexto fica no vault, não no meu cérebro.

7. Como isso aparece num dia típico

Manhã — trabalho técnico (Kiro)

8h — Peço “PRs abertos”. O agent consulta Azure DevOps via MCP, mostra 4 PRs. O steering de contexto do time já carregou — ele sabe o padrão de cada dev e ajusta os comentários de review.

8h30 — Code review. Carrego a skill. O agent lê o diff, aplica as lentes, sugere dois comentários. Um sobre nomenclatura, outro sobre validação que podia ser extraída.

10h — Bug de produção. Troco pra Opus 5. Carrego incident-analysis. Em 3 minutos: hipótese documentada no vault.

Tarde — projetos pessoais (Cursor)

14h — Artigo DEV.to. Chamo o Grok Bot Vitrine: “continua o draft”. Ele sabe onde parou porque o contexto tá no Logseq. A steering editorial define tom, gates, estrutura.

21h — Side project. Cada projeto tem seu próprio steering de contexto. Mesma arquitetura do trabalho, domínio diferente.

Noite — vida (ChatGPT)

18h30 — Mentoria. Canvas pra material colaborativo. Contexto isolado do trabalho.

19h30 — Faculdade. Estudo, exercícios. Se preciso de algo do vault, copio manualmente.

Mobile — consultas rápidas (Grok Bot)

12h — Almoço fora. Alerta no Sentry. Pelo celular: “verifica o alerta X”. Grok Bot roda no Mac, consulta os MCPs, me manda síntese.

O ponto: não copiei um link entre ferramentas o dia inteiro. O contexto fluiu.

8. O que eu pago

Ferramenta Custo/mês Quem paga Pra quê Logseq $0 — RAG central Kiro ~$20 — Trampo Cursor $60 Eu Grok Bots + modelos de ponta ChatGPT $20 Eu Pessoal

Total pessoal: $80/mês. O Logseq é gratuito, mas é a peça mais crítica. Sem ele, as outras três são ilhas.

Custo de manter:

  • ~2h/mês refinando skills
  • ~1h/mês ajustando steerings
  • ~30min/semana sincronizando vault

Compensa porque economizo isso toda semana em “deixa eu te explicar o contexto de novo”.

9. O que não funcionou

Tentei Por que não ficou Embeddings Overhead, drift, difícil debugar Mais de 3 agents Latência e custo. Passei de 6 pra 3 Dois code-read tools juntos Confusão de contexto ChatGPT pra trabalho Contexto manual no meu setup, virou cópia/cola Grok Bot pilotando UIs Não existe API

O pattern: começo ambicioso, corto quando o custo supera o benefício.

10. Como começar

  1. Escolhe um vault: Logseq, Obsidian, pasta de markdown. Git-versioned é bônus.
  2. Define scopes: ops, carreira, pessoal. Cada scope tem um hub.
  3. Compartilha skills: aponta Cursor e Kiro pra mesma pasta.
  4. Configura MCPs: começa com Jira ou GitHub.
  5. Limita agents: 3 é suficiente.
  6. Separa pessoal de trabalho: não mistura harnesses.
  7. Documenta o que não funcionou: evita repetir erro.

Checklist mínimo pra semana 1:

[ ] Criar pasta ~/vault/ com 3 hubs
[ ] Instalar MCP do Jira ou GitHub no Cursor
[ ] Criar 1 skill (pode ser só o contexto do projeto)
[ ] Definir regra: trabalho = IDE X, pessoal = IDE Y
[ ] Usar uma semana e anotar o que não funcionou

Enter fullscreen mode Exit fullscreen mode

Gists relacionados:

A pergunta “qual IDE com IA você usa?” está errada. A pergunta certa é: “como suas ferramentas de IA conversam entre si?”.

Se não conversam, você está pagando por ilhas.

Qual é o primeiro passo que faz sentido pra você — vault unificado, skills compartilhadas, ou MCPs?

원문에서 계속 ↗