Por que troquei Claude Code, Cursor e OpenCode pelo OMP

Eu não troquei de ferramenta porque um modelo venceu um benchmark. Troquei porque o harness ao redor do modelo mudou quanto controle eu tinha sobre meu trabalho diário de engenharia.

Por um tempo, meu trabalho passou por Claude Code, Cursor e OpenCode. Cada um resolvia uma parte real do problema. O Cursor era forte quando o editor era o centro de gravidade. O Claude Code era um agente de terminal capaz, com um fluxo maduro de instruções, skills, hooks, MCP e múltiplas superfícies. O OpenCode me dava uma experiência open source, flexível quanto a providers, no terminal e no IDE.

Depois comecei a usar Oh My Pi, normalmente chamado de OMP. Fiquei não por causa de uma feature isolada, mas pela combinação: um agente terminal-first com o IDE conectado ao harness, liberdade de modelo e provider, language servers e debuggers de primeira classe, kernels persistentes de avaliação, subagentes estruturados, regras durante o streaming e um sistema de plugins capaz de carregar minha configuração inteira.

OMP é um harness, não outro modelo

OMP é um agente de programação construído sobre o Pi, com interface de terminal e uma superfície ampla de ferramentas. Ele não precisa ser dono do modelo. O modelo é uma parte substituível do sistema; o harness controla o loop ao redor dele.

Esse loop inclui:

• leitura e busca de código;
• edição com validação estruturada;
• operações LSP para definições, referências, renomes e diagnósticos;
• acesso DAP a debuggers reais;
• kernels persistentes de Python e Bun;
• servidores MCP e ferramentas externas;
• roles de modelo, fallbacks, sessões, memória e plugins;
• subagentes que retornam resultados estruturados em vez de handoffs em prosa.

Essa distinção importa porque muitas ferramentas de IA são apresentadas como produtos de modelo com um modo agente acoplado. O OMP parece mais uma camada operacional para agentes de programação. Posso trocar modelo, provider, camada de prompt, extensões e política de ferramentas sem substituir o ambiente onde o trabalho acontece.

O que o Cursor otimiza

Cursor é um produto editor-first. Isso é uma qualidade, não uma crítica. Seu fluxo é construído ao redor de um IDE onde navegação de código, alterações inline, revisão, menções de contexto, regras, MCP e trabalho agentivo ficam disponíveis sem sair do editor. A documentação oficial o descreve como um agente para entender a base de código, planejar e construir features, corrigir bugs e revisar mudanças.

Eu ainda prefiro Cursor quando a pergunta principal é visual: quais linhas mudaram, como esse componente renderiza ou como navegar rapidamente por uma base conhecida a partir do editor?

OMP otimiza um centro diferente:

• sessões de terminal são de primeira classe;
• ferramentas são inspecionáveis e scriptáveis;
• o mesmo agente pode dirigir LSP e um debugger ativo;
• roles de modelo podem ser escolhidas separadamente para trabalho default, plano, visão, rápido, lento, tarefas e revisão;
• o ambiente pode ser configurado como plugin e instalado em outra máquina.

Cursor deixa o editor ser o harness. OMP deixa o harness dirigir as capacidades do editor. Essa diferença se tornou importante quando eu quis cobrir debugging web, backend, projetos mobile, inspeção de banco e automação de terminal com um único fluxo, sem fazer do IDE a fronteira do sistema.

O que o Claude Code faz bem

Claude Code tem uma identidade clara de terminal e uma superfície de workflow ampla. Ele edita arquivos, executa comandos, trabalha com MCP, usa CLAUDE.md, carrega skills, executa hooks, cria subagentes e opera em superfícies de terminal, IDE, desktop e web. A documentação dele deixa essa amplitude explícita.

Eu não saí porque ele fosse incapaz. Saí porque queria o mesmo tipo de fluxo com outro control plane.

As diferenças que importaram para mim foram:

1. Escolha de provider como decisão normal de configuração. Eu queria direcionar roles diferentes para modelos e gateways diferentes sem tratar o provider como o produto.
2. Capacidades do IDE dentro do loop do agente. LSP e debugging deveriam ser ferramentas que o agente pudesse invocar, não apenas recursos que eu usasse manualmente no editor.
3. Runtime mais inspecionável. Avaliação persistente, metadados de ferramentas, APIs de extensão e recursos locais tornam mais fácil entender o que o agente está fazendo.
4. Ecossistema de plugins ao redor do harness. Eu queria empacotar skills, extensões, definições MCP, temas e configuração compartilhada como uma unidade instalável.

Claude Code pode ser bastante customizado, inclusive com skills, hooks, MCP e subagentes. A afirmação não é que ele não faça essas coisas. É que o OMP fez essa combinação específica parecer o produto principal, em vez de uma coleção de add-ons ao redor de uma experiência centrada no provider.

O que o OpenCode me deu primeiro

OpenCode foi o predecessor mais próximo do meu fluxo atual. É open source, roda no terminal, em desktop e em extensão de IDE, e suporta múltiplos providers de modelo. Sua configuração gira ao redor de configurar um provider, inicializar um projeto e usar modos de plano e build com instruções de projeto.

Essa base tornou a migração para OMP mais fácil. Eu já valorizava:

• um agente que rodasse localmente a partir de um repositório;
• configuração de provider fora de um único fornecedor de modelos;
• instruções de projeto em AGENTS.md;
• um fluxo de terminal que não exigisse um editor específico.

O OMP me convenceu ao aprofundar o harness. A camada de ferramentas é mais explícita, com operações dedicadas de LSP, operações de debugger, seletores estruturados de arquivo e ferramentas conscientes de output. O runtime também expõe pontos de extensão para comandos, ferramentas, renderizadores, providers, recursos e eventos de sessão.

OpenCode continua sendo uma boa escolha quando sua superfície combina com seu fluxo. Minha mudança não foi “OpenCode é ruim”. Foi que o OMP me deu mais controle sobre a camada que eu já estava modificando cada vez mais.

As features que mudaram meu trabalho diário

LSP e debugger como ferramentas do agente

A maior diferença prática foi tratar inteligência de IDE como parte da superfície de ferramentas do agente. Um rename pode usar o language server em vez de substituição textual. Um bug em um processo Go, Python ou nativo pode levar a uma sessão de debugger em vez de mais um print.

Isso encurta um loop comum: ler código, adivinhar, editar, descobrir que um tipo ou fato de runtime era diferente e desfazer o palpite. O agente pode fazer as mesmas perguntas que um IDE ou debugger responderia.

Subagentes estruturados

A superfície task do OMP permite que um agente pai distribua trabalho a workers e receba resultados tipados. O importante não é apenas o paralelismo. Um subagente pode ter role explícita, worktree isolado, política de ferramentas e schema de saída.

Isso é diferente de pedir para vários agentes “darem uma olhada” e depois interpretar uma pilha de prosa. O contrato de orquestração vira parte da chamada de ferramenta.

Regras durante o streaming

OMP pode interromper uma geração quando uma regra é identificada, injetar uma correção e refazer a partir do mesmo ponto. Isso é útil para regras que só devem agir quando o modelo está prestes a cometer um erro conhecido.

Uma instrução estática consome contexto em todos os turnos. Uma stream rule pode ficar dormente até o padrão arriscado aparecer. É um detalhe arquitetural pequeno, mas com efeito perceptível em sessões longas.

Kernels persistentes de avaliação

Os runtimes de avaliação de Python e Bun tornam o uso de ferramentas composável. Um kernel pode chamar as próprias ferramentas do agente, carregar dados, calcular um resultado e manter estado entre etapas. Isso é útil para auditorias, trabalho com dados, sondagem de APIs e qualquer tarefa em que iniciar scripts descartáveis repetidamente faria você perder contexto.

Roles de modelo em vez de um único default

Parei de pensar em “qual é meu modelo de programação?” e comecei a atribuir roles:

• um default forte para implementação;
• um modelo de planejamento para arquitetura;
• um modelo de visão para imagens;
• um modelo barato para exploração;
• um modelo lento para raciocínio difícil;
• um modelo de tarefas para subagentes;
• um advisor separado para notas de revisão.

O catálogo de modelos e a política de fallback viram configuração, não memória muscular. Quando um provider muda, o fluxo continua reconhecível.

Plugins e marketplaces

A razão final da troca foi operacional. Eu não queria reconstruir minha configuração em cada computador. Plugins do OMP podem carregar skills, extensões, temas, definições MCP e um perfil de configuração compartilhado. Um marketplace privado transforma esse pacote em uma instalação repetível.

É disso que trata o post complementar: como criar um marketplace pessoal para OMP. A ideia central é simples: versionar a superfície que você quer compartilhar, manter segredos e estado da máquina locais e atualizar o plugin em vez de manter uma rede de symlinks.

O que o OMP não substitui

OMP não é automaticamente a melhor escolha para todo mundo.

Use Cursor quando interação nativa no editor, revisão inline e contexto visual forem prioridade. Use Claude Code quando seu provider, suas superfícies e seu fluxo estabelecido combinarem com sua necessidade. Use OpenCode quando quiser um agente de programação open source e flexível quanto a providers, com uma configuração mais simples. Use OMP quando quiser controlar mais o harness e aceitar configurá-lo.

Esse é o custo. OMP expõe mais decisões: providers, roles, fallbacks, carregamento de extensões, confiança em MCP, adapters LSP, debuggers, compactação de output e versões de plugins. Mais controle significa mais responsabilidade. Um MCP quebrado, um model ID antigo ou uma extensão incompatível passam a ser problemas do seu ambiente para diagnosticar.

Por que troquei

A decisão foi cumulativa:

• eu queria trabalho terminal-first sem abrir mão da inteligência do IDE;
• eu queria LSP e debuggers reais dentro do loop do agente;
• eu queria modelos e providers substituíveis;
• eu queria subagentes com contratos em vez de delegação apenas em prosa;
• eu queria regras que pudessem ativar no momento de risco;
• eu queria avaliação persistente para dados e investigação;
• eu queria uma configuração versionada entre computadores.

OMP não eliminou configuração. Ele transformou configuração em parte da superfície do produto. Essa troca funcionou para mim porque eu já pagava o custo da complexidade manualmente entre várias ferramentas.

Checklist antes de trocar

• Decida se sua prioridade é fluxo nativo no editor ou controle do harness.
• Teste disponibilidade de LSP e debugger para suas linguagens.
• Liste os roles de modelo que você realmente usa em vez de escolher um único default.
• Mantenha credenciais de provider e estado OAuth fora da configuração compartilhada.
• Trate servidores MCP como integrações privilegiadas, não como configurações inofensivas.
• Comece com um plugin contendo skills e extensões antes de empacotar tudo.
• Mantenha a ferramenta atual disponível até o novo harness passar por um fluxo real de projeto.

A comparação útil não é “qual ferramenta tem o modelo mais inteligente?”. É “qual harness me dá o controle certo sobre o trabalho que faço todos os dias?”. Para mim, a resposta passou a ser OMP.