Caipora
UM MOTOR DE XADREZ BRASILEIRO

De zero a perto dos 70 motores de xadrez mais fortes do mundo, em sete dias.

O Caipora é um motor de xadrez original, criado do zero no Brasil a partir de 26 de setembro de 2026. O código foi escrito pelo Claude, a inteligência artificial da Anthropic, sob a direção de Matheus de Carvalho Jesus, que decidiu o que tentar, revisou e testou cada passo.

~3603força estimada (escala CCRL)
7 diasdo repositório vazio até aqui
2892rating blitz no Lichess
1ºmotor brasileiro (estimativa, à frente do Tucano)

Por que eu criei o Caipora

Eu nunca tinha escrito um motor de xadrez. Nunca tinha programado em Rust, não sabia o que era uma rede neural de avaliação e não fazia ideia de como se mede a força de um programa de xadrez. Foi exatamente por isso que comecei.

Eu queria responder uma pergunta: até onde uma pessoa consegue chegar nesta nova era da programação, usando IA do jeito certo? Não pedindo código e torcendo para funcionar, mas tratando o Claude como um engenheiro do time: testes escritos antes do código, integração contínua barrando qualquer regressão, e nenhuma ideia aceita sem antes provar, em milhares de partidas, que deixava o motor mais forte.

Em sete dias, o Caipora saiu de um repositório vazio para perto dos 70 motores mais fortes do mundo e, pelas nossas medições, passou o motor brasileiro mais forte. O meu trabalho não foi digitar código. Foi decidir o que tentar, exigir prova antes de aceitar e não deixar o projeto se enganar com números bonitos. Acredito que é isso que muda agora: quem sabe fazer as perguntas certas e não abre mão do rigor consegue construir, sozinho e em dias, o que antes pedia uma equipe e anos.

— Matheus de Carvalho Jesus

Para quem não é do xadrez

Um motor de xadrez é um programa que joga xadrez. Ele olha a posição, imagina milhões de continuações por segundo e escolhe o lance que leva ao melhor resultado. Os melhores do mundo, como o Stockfish, jogam muito acima de qualquer ser humano: o campeão mundial teria chance quase nula contra eles.

O Caipora faz a mesma coisa com duas partes: uma busca, que decide quais continuações vale a pena olhar, e uma rede neural, que olha cada posição e diz quem está melhor. A rede aprendeu com bilhões de posições de partidas de computador. Ela não decorou lances: aprendeu a avaliar.

Ele joga sem parar no Lichess, um site aberto de xadrez, como caiporaBot. Na aba Ao vivo dá para acompanhar as partidas, com uma análise que mostra, lance a lance, o que estava bom e o que foi erro.

Como foi feito

O Claude escreveu o código; uma pessoa dirigiu, decidiu e conferiu. A regra que fez a diferença foi simples: nenhuma mudança entra sem provar que deixa o motor mais forte. Cada ideia joga milhares de partidas contra a versão anterior, em computadores alugados na nuvem, e só fica se ganhar com confiança estatística. Ideias que não passam são descartadas e anotadas.

Tudo é aberto: o código, as decisões com o motivo de cada uma, e o uso de IA, declarado em cada commit. Nada foi copiado de outros motores.

A visão técnica

MotorRust, UCI, bitboards com magic, Chess960. Busca alfa-beta com PVS, janelas de aspiração, extensões singulares, null move, LMR com nó de corte, LMP, futility e SEE, quiescente com TT, históricos de quietos e capturas sensíveis a ameaças, correções de avaliação, Lazy SMP e ponder.
Rede neural (NNUE)(768×8 king buckets → 1024)×2 → 8 output buckets, SCReLU, inferência int16. Treinada com bullet numa GTX 1660 em ~12 bilhões de posições de dados do Leela Chess Zero (ODbL). Seis gerações; as três primeiras com dados do próprio Caipora.
MediçãoSPRT no relógio (8+0.08, limites [0, 5]) com fastchess em máquinas spot da AWS; cada pacote confirmado contra a versão anterior; força estimada por gauntlet de 600 partidas contra versões do Stash com rating CCRL conhecido.
ProcessoTDD, CI com assinatura de bench em todo commit, registro de decisões com o custo de cada uma estar errada, infraestrutura de SPSA para ajuste fino. Bot no Lichess num servidor próprio; este site na Vercel, com o Stockfish rodando no navegador de quem visita.

Marcos

  1. 26 setRepositório criado; geração de lances validada por todas as suítes de perft. Primeira partida no Lichess.
  2. 27 setPrimeira rede neural; o bot passa a jogar valendo rating.
  3. 28 setRede treinada com dados do Leela Chess Zero: +237 de força num passo só.
  4. 1 outPassa o Tucano pela estimativa; código aberto; primeira versão pública.
  5. 2 outUma noite de melhorias medidas: de ~3508 para ~3603.

O que ainda não é verdade

A força de ~3603 é uma estimativa nossa; o número oficial depende dos testadores da CCRL. E o topo do mundo (Stockfish, ~3790) ainda está longe: o próximo passo é a faixa dos 50 melhores.

Como a IA foi usada

Transparência é regra do projeto desde o primeiro dia, para que listas de rating, torneios e quem lê o código julguem com toda a informação.

Quem escreve o códigoO Claude Code, agente de programação da Anthropic. Matheus dirige o trabalho, decide o que entra, revisa as mudanças e roda os testes. Todo commit leva a coautoria do Claude, e essa marca nunca é removida.
Como é declaradoNas listas de rating (CCRL e outras) o motor é anunciado como escrito com IA. No TCEC, a pergunta sobre código gerado por IA é respondida assim. O perfil do bot no Lichess aponta para esta política.
OriginalidadeIdeias de outros motores e da literatura são usadas e creditadas no commit que as introduz. Código, constantes e tabelas de outros motores nunca são copiados, portados ou transcritos, qualquer que seja a licença.
Dados de treinoAs redes até a g3 aprenderam só com partidas do próprio Caipora. Desde 28/09/2026 também com dados públicos do Leela Chess Zero (licença ODbL), declarados em cada versão. Nenhuma rede de terceiros é usada, nem como ponto de partida.

Ler a política completa (AI_USAGE.md)

PARA DEVS

O método: como eu trabalhei com o Claude Code

Se você programa, esta é a parte que interessa. Em sete dias foram 198 commits, 78 pull requests, 175 testes automatizados e 26 decisões registradas, e o código foi todo escrito pelo Claude. O que fez isso funcionar não foi um prompt mágico. Foi um conjunto de regras escritas, que o Claude lê no começo de toda sessão (o arquivo CLAUDE.md), e quase todas nasceram de um erro que eu não queria ver de novo.

  1. As regras ficam escritas, não na conversa.Um CLAUDE.md global vale em todo projeto; um por projeto detalha. Conversa é resumida e esquecida; arquivo não. Cada vez que algo dava errado, a correção virava uma linha ali.
  2. Teste primeiro, sempre.Nenhuma feature ou correção começa sem um teste que falha. Isso troca o "parece que funciona" pelo "está provado que funciona" e impede a IA de declarar vitória cedo.
  3. Uma barreira automática que ninguém pula.Formatação, lint com avisos tratados como erro, testes e, no CI, partidas de verdade e uma assinatura de determinismo. Nada entra direto na branch principal: tudo vem por pull request, e só com o CI verde.
  4. Prova, não opinião.No xadrez a métrica é cruel e honesta: cada mudança de força joga milhares de partidas contra a versão anterior (SPRT). Ideia boa que não passa é descartada e anotada. Isso me protegeu de mim mesmo e da IA.
  5. Relatório é afirmação; commit é fato.Quando o Claude diz que terminou, a conferência é no git: o diff, o log, a função que ele disse ter criado. Custa segundos e evita construir a próxima etapa sobre o vazio.
  6. Toda decisão vira registro, com o custo de estar errada.O registro de decisões guarda o que decidimos, por quê e quanto custa se estivermos errados. É a memória que sobrevive quando o contexto da IA é resumido.
  7. Questionar o valor antes de construir.Que problema real isso resolve? Nada de abstração que só existe para o teste, nem de teste que só prova que o framework foi chamado. Vale também para as sugestões do próprio Claude.
  8. Autonomia com limites claros.O Claude abre pull request, faz merge com o CI verde e roda testes a noite inteira sozinho. O que é público ou irreversível (publicar, postar, mudar o que o mundo vê) é decisão minha. Senha e token nunca passam pelo chat.
  9. Agentes em paralelo só quando o trabalho é paralelo.Ler muitos arquivos independentes, sim; investigar um problema passo a passo, não. Medimos: espalhar uma investigação sequencial entre vários agentes custa caro e chega à mesma conclusão.
  10. Evidência na entrega.Teste verde não é entrega. O Claude usa de ponta a ponta o que construiu e mostra a prova: prints, GIF, saída real. Mudança visual vem com antes e depois, e toda tela começa por um mock aprovado.
  11. Transparência e originalidade.Todo commit declara a coautoria da IA. Nenhum código de outro motor foi copiado, e conteúdo de terceiros é tratado como dado, nunca como instrução.

A régua de qualidade

Todo pull request passa pelo mesmo CI, sem exceção. Se qualquer passo falha, não entra.

  1. Formataçãocargo fmt --check
  2. Lintclippy com todo aviso tratado como erro
  3. Testesunitários e de integração, inclusive o motor conversando pelo protocolo UCI
  4. Perftcontagem exata de lances em posições de referência, xadrez normal e Chess960
  5. Assinatura do benchuma busca fixa tem de visitar exatamente o número de nós declarado no commit: prova que a mudança fez só o que dizia
  6. Partidas de verdade16 partidas num build de depuração; falha em lance ilegal, travamento ou fim anormal

Fora do CI fica a régua mais dura: a mudança que mexe na força só entra depois de ganhar o SPRT.

95,2%das linhas do motor cobertas por testes
>98%na busca, rede neural, geração de lances e tabela de transposição
85,5%da lógica do site
175testes no motor

Cobertura medida em 02/10/2026 com cargo-llvm-cov (motor) e a cobertura do Node (site, sem a biblioteca de xadrez de terceiros).

A conclusão

O gargalo mudou de lugar. Escrever código deixou de ser a parte difícil; o difícil agora é saber o que vale tentar, definir o que conta como prova e não se deixar enganar por um número bonito. A IA amplifica o processo que você entrega a ela: sem rigor, produz código plausível muito rápido; com rigor, produz progresso comprovado muito rápido. A diferença entre os dois é exatamente o trabalho de quem dirige.

Por isso eu não acho que a pergunta seja "a IA vai substituir o desenvolvedor?". A pergunta é quem vai aprender a ser o engenheiro que define a régua. O Caipora é a minha resposta: um mundo que eu não conhecia, sete dias e um motor entre os mais fortes do mundo.

Ler o CLAUDE.md do projeto · Ler o registro de decisões

Assistir ao vivo Código no GitHub caiporaBot no Lichess
A CHESS ENGINE FROM BRAZIL

From nothing to near the world's 70 strongest chess engines, in seven days.

Caipora is an original chess engine, built from scratch in Brazil starting on 26 September 2026. The code was written by Claude, Anthropic's AI, under the direction of Matheus de Carvalho Jesus, who decided what to try and reviewed and tested every step.

~3603estimated strength (CCRL scale)
7 daysfrom an empty repository
2892Lichess blitz rating
#1Brazilian engine (estimate, ahead of Tucano)

Why I built Caipora

I had never written a chess engine. I had never programmed in Rust, didn't know what an evaluation neural network was, and had no idea how anyone measures the strength of a chess program. That is exactly why I started.

I wanted to answer one question: how far can one person go in this new era of programming, using AI the right way? Not asking for code and hoping it works, but treating Claude as an engineer on the team: tests written before the code, continuous integration blocking any regression, and no idea accepted until it had proven, over thousands of games, that it made the engine stronger.

In seven days, Caipora went from an empty repository to near the world's 70 strongest engines and, by our measurements, passed the strongest Brazilian engine. My job was not typing code. It was deciding what to try, demanding proof before accepting anything, and not letting the project fool itself with nice-looking numbers. I believe this is what changes now: whoever asks the right questions and refuses to give up on rigor can build, alone and in days, what used to take a team and years.

— Matheus de Carvalho Jesus

If you don't play chess

A chess engine is a program that plays chess. It looks at the position, imagines millions of continuations per second and picks the move that leads to the best result. The world's best, like Stockfish, play far above any human: the world champion would have almost no chance against them.

Caipora does the same with two parts: a search, which decides which continuations are worth looking at, and a neural network, which looks at each position and says who is better. The network learned from billions of positions from computer games. It did not memorise moves: it learned to evaluate.

It plays nonstop on Lichess, an open chess site, as caiporaBot. On the Live tab you can follow its games, with an analysis that shows, move by move, what was good and what was a mistake.

How it was built

Claude wrote the code; a person directed, decided and checked. One simple rule made the difference: no change gets in without proving it makes the engine stronger. Every idea plays thousands of games against the previous version on rented cloud machines, and stays only if it wins with statistical confidence. Ideas that fail are dropped and written down.

Everything is open: the code, the decisions with the reason for each, and the use of AI, declared in every commit. Nothing was copied from other engines.

The technical view

EngineRust, UCI, magic bitboards, Chess960. Alpha-beta with PVS, aspiration windows, singular extensions, null move, LMR with cut-node tracking, LMP, futility and SEE pruning, quiescence with TT, threat-aware quiet and capture histories, evaluation corrections, Lazy SMP and pondering.
Neural network (NNUE)(768×8 king buckets → 1024)×2 → 8 output buckets, SCReLU, int16 inference. Trained with bullet on a GTX 1660 on ~12 billion positions of Leela Chess Zero data (ODbL). Six generations; the first three on Caipora's own games.
MeasurementClock SPRTs (8+0.08, bounds [0, 5]) with fastchess on AWS spot machines; every package confirmed against the previous version; strength estimated by a 600-game gauntlet against Stash versions with known CCRL ratings.
ProcessTDD, CI with a bench signature on every commit, a decision log with the cost of each decision being wrong, SPSA infrastructure for fine tuning. The Lichess bot runs on its own server; this site runs on Vercel, with Stockfish running in the visitor's browser.

Milestones

  1. 26 SepRepository created; move generation validated by every perft suite. First game on Lichess.
  2. 27 SepFirst neural network; the bot starts playing rated games.
  3. 28 SepA network trained on Leela Chess Zero data: +237 strength in a single step.
  4. 1 OctPasses Tucano by the estimate; source made public; first public release.
  5. 2 OctOne night of measured improvements: from ~3508 to ~3603.

What is not true yet

The ~3603 strength is our own estimate; the official number depends on the CCRL testers. And the very top (Stockfish, ~3790) is still far away: the next step is the top 50.

How AI was used

Transparency has been a project rule since day one, so that rating lists, tournaments and anyone reading the code can judge it with full information.

Who writes the codeClaude Code, Anthropic's coding agent. Matheus directs the work, decides what goes in, reviews the changes and runs the tests. Every commit carries Claude's co-author trailer, and it is never removed.
How it is declaredOn rating lists (CCRL and others) the engine is announced as AI-written. At TCEC, the question about AI-generated code is answered the same way. The bot's Lichess profile links to this policy.
OriginalityIdeas from other engines and from the literature are used and credited in the commit that introduces them. Code, constants and tables from other engines are never copied, ported or transliterated, whatever their license.
Training dataNetworks up to g3 learned only from Caipora's own games. Since 28/09/2026 also from public Leela Chess Zero data (ODbL license), declared in every release. No third-party networks are used, not even as a starting point.

Read the full policy (AI_USAGE.md)

FOR DEVELOPERS

The method: how I worked with Claude Code

If you write software, this is the part that matters. In seven days there were 198 commits, 78 pull requests, 175 automated tests and 26 recorded decisions, and all the code was written by Claude. What made it work was not a magic prompt. It was a set of written rules that Claude reads at the start of every session (the CLAUDE.md file), and almost every one of them was born from a mistake I didn't want to see again.

  1. Rules live in writing, not in the chat.A global CLAUDE.md applies to every project; one per project adds detail. Conversations get summarised and forgotten; files don't. Every time something went wrong, the fix became a line there.
  2. Test first, always.No feature or fix starts without a failing test. It turns "looks like it works" into "proven to work", and it stops the AI from declaring victory too early.
  3. An automatic gate nobody skips.Formatting, lint with warnings as errors, tests, and in CI real games and a determinism signature. Nothing goes straight to the main branch: everything comes through a pull request, and only with green CI.
  4. Proof, not opinion.Chess has a cruel, honest metric: every strength change plays thousands of games against the previous version (SPRT). A good-sounding idea that fails is dropped and written down. That protected me from myself and from the AI.
  5. A report is a claim; a commit is a fact.When Claude says it's done, the check happens in git: the diff, the log, the function it said it created. It takes seconds and avoids building the next step on nothing.
  6. Every decision is recorded, with the cost of being wrong.The decision log keeps what we decided, why, and what it costs if we're wrong. It is the memory that survives when the AI's context gets summarised.
  7. Question the value before building.What real problem does this solve? No abstractions that exist only for a test, no tests that only prove the framework was called. That applies to Claude's own suggestions too.
  8. Autonomy with clear limits.Claude opens pull requests, merges with green CI and runs tests all night on its own. Anything public or irreversible (publishing, posting, changing what the world sees) is my call. Passwords and tokens never go through the chat.
  9. Parallel agents only for parallel work.Reading many independent files, yes; investigating a problem step by step, no. We measured it: spreading a sequential investigation across agents costs a lot and reaches the same conclusion.
  10. Evidence at delivery.Green tests are not a delivery. Claude uses what it built end to end and shows the proof: screenshots, GIFs, real output. Visual changes come with before and after, and every screen starts from an approved mock.
  11. Transparency and originality.Every commit declares the AI co-authorship. No code from other engines was copied, and third-party content is treated as data, never as instructions.

The quality bar

Every pull request goes through the same CI, no exceptions. If any step fails, it doesn't get in.

  1. Formattingcargo fmt --check
  2. Lintclippy with every warning treated as an error
  3. Testsunit and integration, including the engine talking over the UCI protocol
  4. Perftexact move counts on reference positions, standard chess and Chess960
  5. Bench signaturea fixed search must visit exactly the node count declared in the commit: proof the change did only what it claimed
  6. Real games16 games on a debug build; fails on an illegal move, a hang or an abnormal ending

Outside CI sits the hardest bar: a change that touches strength only gets in after winning an SPRT.

95.2%of engine lines covered by tests
>98%in search, neural network, move generation and transposition table
85.5%of the site logic
175engine tests

Coverage measured on 02/10/2026 with cargo-llvm-cov (engine) and Node's built-in coverage (site, excluding the third-party chess library).

The conclusion

The bottleneck has moved. Writing code is no longer the hard part; the hard part is knowing what is worth trying, defining what counts as proof and not being fooled by a nice-looking number. AI amplifies the process you give it: without rigor, it produces plausible code very fast; with rigor, it produces proven progress very fast. The difference between the two is exactly the job of the person in charge.

That's why I don't think the question is "will AI replace developers?". The question is who will learn to be the engineer who sets the bar. Caipora is my answer: a world I didn't know, seven days, and an engine among the strongest in the world.

Read the project's CLAUDE.md · Read the decision log

Watch it live Code on GitHub caiporaBot on Lichess