Como configurar o Claude Code para qualquer linguagem

Eu trabalho principalmente com TypeScript e GDScript, mas ultimamente o Claude Code tem me levado a novos horizontes com projetos em Elixir e Rust, que eu nunca tinha tocado antes. Este post é sobre o que eu tive que adicionar para fazer isso funcionar.

O caso fácil: TypeScript

Se você usa o Claude Code em um projeto TypeScript, provavelmente já teve essa experiência: você pede para ele implementar algo, ele escreve o código, executa pnpm typecheck, vê três sublinhados vermelhos, os corrige, executa a verificação novamente e chega a algo verde. Você mal precisou observar.

Isso funciona porque o TypeScript fornece um compilador que produz um feedback rápido e estruturado, e todo projeto TS no mundo tem um script de typecheck. O Claude não precisa adivinhar se foo é um string ou um Promise; ele executa a verificação, lê a saída e se autocorrige.

Tire isso, e as coisas mudam.

O que exatamente é um "harness"?

Um harness é tudo ao redor do modelo que permite que ele veja se o seu próprio código está correto. O typecheck acima é um. Um linter é outro. Também serve um compilador com uma mensagem de erro útil, ou um navegador que o Claude consiga operar e ler o console.

Sem harness, sem autocorreção. O Claude escreve algo que parece plausível, você diz "legal", e três horas depois, descobre que ele importou uma função que não existe. Bom harness? O Claude percebe na mesma rodada, corrige e continua.

Todo o jogo de configurar o Claude Code para uma linguagem desconhecida é: dar a ele um loop de feedback que seja pelo menos tão bom quanto pnpm typecheck. De preferência, melhor.

Se você quer a explicação adequada sobre essa ideia, o blog do Martin Fowler tem um ótimo texto sobre harness engineering que aprofunda mais do que eu farei aqui.

O que é um LSP, e como alimentar o Claude com uma

Explicação chata: O Language Server Protocol é uma especificação (originalmente do VS Code) sobre como os editores conversam com o "cérebro" de uma linguagem de maneira padronizada. O cérebro (o servidor de linguagem) é aquilo que analisa o código, resolve tipos, encontra referências e reporta erros. O LSP em si é apenas o protocolo que eles usam para conversar. O editor pergunta, o servidor responde.

Explicação da vida real: aquelas linhas onduladas vermelhas no VS Code? Seu editor perguntou ao servidor de linguagem, "tem algo errado com este arquivo?" via LSP, e o servidor enviou de volta uma lista de intervalos e mensagens. Tooltips ao passar o mouse, ir para a definição, autocompletar — mesma lógica. O editor mostra o resultado; o servidor faz o trabalho.

Explicação gamer: é o Scan no FFIX. Você mira em algo específico, e o jogo te diz o HP, as fraquezas e o que ele está carregando. Não revela a batalha inteira (você tem que escolher quem escanear), mas quando faz isso, você obtém uma leitura real em vez de ficar cutucando os inimigos para descobrir o que funciona.

Nos bastidores, o servidor de linguagem é um programa real rodando na sua máquina: rust-analyzer, elixir-ls, gopls, seja qual for o que venha com a linguagem. Seu editor o inicia como um subprocesso e troca mensagens JSON-RPC com ele via stdin/stdout. (O protocolo também suporta sockets TCP para configurações remotas, mas stdio é o padrão e o que o Claude Code usa.) Cada hover, cada linha ondulada, cada "ir para a definição" é uma requisição JSON de entrada e uma resposta JSON de saída.

Aponte o Claude para o mesmo servidor de linguagem e ele poderá obter os mesmos sublinhados e hovers que você. Ele não está realmente "vendo" sua tela, mas fazendo ao servidor as mesmas perguntas que seu editor faz ("qual é o tipo deste argumento?", "esta função existe?", "onde isso está definido?"). Isso não é o mesmo que ter a experiência do seu editor de graça: só ajuda se o servidor for preciso, se a integração fizer as consultas nos momentos certos e se o modelo usar as respostas que recebe. Quando esses três fatores se alinham, as suposições diminuem drasticamente.

O plugin cuida da conexão do subprocesso, mas você ainda precisa do binário do servidor instalado no seu sistema (via rustup, mix, brew ou qualquer pacote para a sua linguagem).

Note que, para deixar tudo funcionando, dependendo da ferramenta LSP, você pode precisar adicionar:

  "env": {
    "ENABLE_LSP_TOOL": true
  },

ao seu ~/.claude/settings.json.

Três stacks, o mesmo padrão

Godot

Eu conheço bem o Godot e o GDScript, mas infelizmente, por ser uma linguagem dinâmica, não temos um equivalente ao pnpm typecheck para entregar ao Claude. O GDScript compila enquanto o jogo roda — o sinal de "isso funciona" vive principalmente dentro do editor.

A solução foram dois plugins. Um servidor MCP do Godot (para que o Claude possa consultar a árvore de cenas, inspecionar tipos de nós, rodar o jogo, ler o stdout) e um cliente LSP de GDScript (erros em tempo real, hovers, ir para a definição). Aqui estão os plugins que utilizei:

claude plugin marketplace add minami110/claude-godot-tools

claude plugin install gdscript-toolkit@claude-godot-tools
claude plugin install gdscript-lsp@claude-godot-tools
claude plugin install vscode-gdscript-tools@claude-godot-tools
claude plugin install gdunit4-toolkit@claude-godot-tools

claude mcp add godot -- npx @coding-solo/godot-mcp

Referências:

• https://github.com/minami110/claude-godot-tools/tree/main
• https://github.com/Coding-Solo/godot-mcp

Com ambos instalados (além de extras para VSCode e GDUnit, um framework de testes), o Claude parou de inventar nomes de nós. Ele lê a árvore de cenas, vê que Playertem um filho HealthBar do tipo ProgressBar, e o chama corretamente na primeira vez. Meus prompts foram de "aqui está a estrutura da cena, o jogador está em /root/Main/Player, ela tem um sinal chamado…" para "adicione um flash de dano quando a vida cair."

Elixir

Recentemente entrei em um código secreto de Elixir no trabalho, minha primeira vez mexendo na linguagem. "Isso compila" é um critério perigosamente baixo em Elixir — código idiomático é uma habilidade totalmente diferente: quando usar GenServer vs Task.async, por que :float é uma armadilha em colunas de dinheiro, se o seu job do Oban é idempotente. Nada disso aparece como um erro de compilação.

Duas coisas ajudaram:

1. elixir-ls-lsp@claude-plugins-official para o LSP. Mesma história do Godot: tipos reais, diagnósticos reais, respostas reais de "esta função está realmente definida". Chega de Claude inventando módulos.
2. oliver-kriska/claude-elixir-phoenix, um conjunto de habilidades de Elixir/Phoenix e agentes especialistas. Ele codifica os bugs que desenvolvedores Elixir encontram em produção: assign_new pulando silenciosamente na reconexão, queries N+1 no Ecto, jobs do Oban não idempotentes. O tipo de revisão que eu não consigo dar.

claude plugin marketplace add oliver-kriska/claude-elixir-phoenix

claude plugin install elixir-phoenix

claude plugin install elixir-ls-lsp@claude-plugins-official

Referências:

• https://github.com/oliver-kriska/claude-elixir-phoenix
• https://github.com/anthropics/claude-plugins-official

Juntos, o conjunto agora faz o que eu faria se soubesse Elixir.

Rust

Rust é a outra linguagem que eu mal conheço. Eu queria uma CLI para alternar entre minhas contas do Claude Code que me permitisse retomar as mesmas sessões entre contas diferentes sem copiar arquivos JSON manualmente, então eu construí uma: claude-account-switcher ou ccsw, agora no crates.io, dê uma olhada se você também tiver interesse nisso. E aqui está o repositório.

A estrutura era a mesma do Elixir:

• rust-analyzer-lsp para diagnósticos em tempo real, tipos e erros do borrow-checker. O Claude recebe as mesmas marcações que eu receberia no VS Code, com a diferença de que ele realmente as lê.
• rust-skills@rust-skills para verificações de idiotismos e as armadilhas comuns do Rust. Mesmo espírito do plugin do Elixir: opiniões que eu ainda não tenho.

claude plugin install rust-analyzer-lsp@claude-plugins-official

claude plugin marketplace add actionbook/rust-skills

claude plugin install rust-skills@rust-skills

Referências:

• https://github.com/actionbook/rust-skills

O compilador do Rust já é famosamente bom em feedback. O LSP acima dele encurtou o ciclo de "escrever → cargo check → ler erros → corrigir" para "escrever → saber que está errado antes de terminar de escrever". Menos idas e vindas, e um crate publicado que eu não teria conseguido revisar linha por linha.

O navegador também conta

Nem todo feedback vive no compilador, já que alguns vivem no navegador. Se o botão é clicável, se o console está gritando, se o layout muda quando dados reais chegam, chrome-devtools-mcp@chrome-devtools-plugins é o que mantenho aberto para qualquer trabalho de frontend. O Claude pode abrir uma página, clicar por aí, ler o console, inspecionar elementos e executar uma auditoria do Lighthouse. É assim que a estrutura vai além do código e chega ao app em execução. Se você está entregando UI, este aqui não é opcional.

Modo automático: agora você pode realmente se afastar

Uma vez que a estrutura está boa, o gargalo muda. O Claude pode se autocorrigir, mas você ainda está clicando em "aprovar" em cada escrita de arquivo e em cada comando bash. Esse ritmo faz sentido quando a estrutura é simples e você quer um humano no loop. É fricção desnecessária quando a própria estrutura está dizendo ao Claude "não, isso não compila" cem vezes por sessão.

O modo Auto é o meio-termo do Claude Code entre a aprovação manual e o --dangerously-skip-permissions. Um classificador inspeciona cada ação antes de ela ser executada, permite que as seguras passem e bloqueia ou redireciona as arriscadas. Execute claude --enable-auto-mode, alterne para ele com Shift+Tab e vá tomar um café.

Não é uma solução definitiva. O classificador pode deixar passar coisas arriscadas quando seu ambiente fornece sinais ambíguos, e você ainda não deve apontá-lo para máquinas de produção. Mas combinado com uma configuração adequada de LSP + MCP + skills, é a primeira vez que consigo entregar um ticket ao Claude e voltar vinte minutos depois para revisar o diff, e não as aprovações.

Conclusão

Em TypeScript, você nunca precisou construir a estrutura, alguém já fez isso e chamou de tsconfig.json (embora também seja útil ter o typescript-lsp conectado). Em qualquer outro lugar, esse é o seu trabalho. Faça isso uma vez por repo, e o Claude deixa de ser preguiçoso nas linguagens que você não fala.

Espero que isso torne seu desenvolvimento muito mais fluido com engenharia agentica, tudo de bom!

Referencias

• https://github.com/anthropics/claude-plugins-official
• https://github.com/minami110/claude-godot-tools/tree/main
• https://github.com/Coding-Solo/godot-mcp
• https://github.com/oliver-kriska/claude-elixir-phoenix
• https://github.com/actionbook/rust-skills
• https://github.com/anthropics/claude-code/issues/18125#issuecomment-3843601648
• https://martinfowler.com/articles/harness-engineering.html

We want to work with you. Check out our Services page!