Colofão
Como isto foi construído
A maioria dos sites não se explica. Este explica, porque como ele foi feito é parte do que ele é: um experimento deliberado de construir bem, com colaboradores incomuns, e um registro que vale a pena preservar.
CONCORD
Este site foi projetado e construído por meio de um protocolo chamado CONCORD: uma colaboração estruturada entre uma pessoa e três sistemas de IA distintos, cada um em um papel próprio. É um método de trabalho, com sua própria governança, seu próprio registro de decisões, e uma única pessoa responsável por cada escolha que foi publicada.
A premissa é simples. Modelos de IA diferentes têm forças diferentes, e um problema difícil se beneficia de mais de uma perspectiva mantidas em tensão. Por isso o trabalho foi dividido por papéis, e uma pessoa ficou no centro, fazendo a ponte entre eles, ratificando o que era sólido e rejeitando o que não era.
O CONCORD não foi adotado de lugar nenhum. Foi concebido por Rodolfo Nützmann para este projeto, a partir de uma necessidade prática: como recorrer a vários sistemas de IA ao mesmo tempo, cada um realmente bom em algo diferente, sem abrir mão do único fio de responsabilidade humana que o trabalho real exige. A resposta foi dar a cada sistema um posto definido, impedir que negociassem entre si e encaminhar cada troca por uma única pessoa que mantinha a visão do todo. Esse arranjo tem um nome mais antigo. Os sistemas de IA são agentes: agem por instrução e em nome de outra pessoa. O PRIME é o principal: quem de fato decide, quem exerce o julgamento e quem carrega as consequências e o nome.
A vantagem é dos agentes. A responsabilidade é do principal, e não se transfere.
Começou de modo informal — como uma forma de dividir o trabalho — e se consolidou ao longo da construção num método com nome: postos fixos, uma única regra acima de tudo, que nada é publicado sem que o PRIME ratifique, e um registro escrito de por que cada decisão foi tomada. O nome declara o objetivo: concórdia, um acordo alcançado de propósito por meio de um processo, não o que uma ferramenta sem supervisão venha a produzir.
A mecânica, em termos claros
Os assentos
- PRIMERodolfo NützmannHumano
O único ratificador. Cada decisão, cada linha publicada, passou por uma pessoa que tinha o quadro completo e assumia a responsabilidade final. As IAs propunham; PRIME decidia.
- ANVILEngenhariaAnthropic · Claude Fable 5 → Opus 4.8
O assento de engenheiro-chefe. Arquitetura, código, estrutura de conteúdo, e a própria build, convertidos da intenção em um site funcional, testado e implantável.
- SCOUTEstratégia e marcaOpenAI · ChatGPT 5.5
O assento da estratégia e do posicionamento. As perguntas sobre o que isto é, para quem é, e como deve se apresentar ao mundo.
- PRISMDesignGoogle · Gemini 3.1 Pro
O assento do design. A linguagem visual, a tipografia, a cor e a sensação do conjunto, moldados em um sistema coerente.
Versões dos modelos de IA em junho de 2026.
Como foi feito
Alguns princípios valeram do início ao fim, e são visíveis se você souber onde olhar.
Calcular, nunca chutar
As ferramentas deste site calculam respostas de forma local e determinística. Elas não chamam um servidor com a sua informação, e não aproximam. O que roda no seu navegador, fica no seu navegador.
Aberto no núcleo
A lógica determinística que cada ferramenta executa é a ferramenta inteira: não há etapa oculta no servidor, nem conta, nem telemetria. Tudo é executado no seu navegador.
Documentado por construção
Cada parte do código é comentada e documentada, não como algo deixado para depois, mas como regra permanente. A build é feita para ser legível, para quem a mantém e para qualquer um que a herde.
Construído para durar e para viajar
O site é uma exportação estática: rápida, cacheável e sem depender de nada em tempo de execução. É estruturado desde a base para muitos idiomas, de modo que pode se dirigir a uma audiência global sem ser reconstruído.
A stack
Para quem se importa com essas coisas, a fundação técnica, exposta com clareza.
- Framework
- Next.js 15 e React 19, exportados como site totalmente estático
- Internacionalização
- next-intl, com 16 idiomas e suporte da direita para a esquerda
- Sistema de design
- Um motor de temas personalizável, baseado em tokens; o tema padrão é o Obsidian
- Tipografia
- Inter para o texto, JetBrains Mono para dados e códigos
- Motor de ferramentas
- Uma camada de computação determinística que roda inteiramente no navegador
- Busca
- Busca de texto completo estática, no lado do cliente; sem servidor de busca
Como as traduções são marcadas
O inglês é escrito e revisado por uma pessoa. O português brasileiro e os demais idiomas são traduzidos por máquina, e marcados pelo quanto já avançaram: azul quando um idioma cobre o site inteiro, amarelo enquanto conteúdo novo ainda está em inglês e se atualizando. Idiomas marcados em vermelho ainda não têm tradução e são exibidos em inglês por ora. Páginas traduzidas por máquina também trazem um aviso curto, e você é bem-vindo a ajudar a melhorar qualquer uma delas.
- Revisado por uma pessoa
- Automática, completa
- Automática, em andamento
- Ainda não traduzido
Padrões e frameworks
Cada ferramenta aqui implementa uma especificação publicada, não um palpite. Os decodificadores e as calculadoras são construídos sobre os documentos que definem seus formatos e fixados aos vetores de teste que esses documentos publicam, de modo que cada resposta é conferida contra a fonte da verdade, e não contra si mesma.
As especificações
JSON Web Tokens seguem a RFC 7519, com assinaturas e algoritmos nas RFC 7515 e 7518; PKCE é a RFC 7636; Base64 e suas variantes são a RFC 4648; UUIDs são a RFC 9562 (que tornou obsoleta a RFC 4122 em 2024 e traz seus próprios vetores de teste); HMAC é a RFC 2104, sobre a família SHA padronizada em FIPS 180-4 e FIPS 202; certificados X.509 são a RFC 5280; IPv4 e a notação CIDR são a RFC 4632; o endereçamento IPv6 e sua forma textual canônica são as RFC 4291 e RFC 5952; e o decodificador de cipher suites é guiado pelo registro oficial IANA TLS Cipher Suites, cruzado com as especificações do TLS 1.3 e 1.2 (RFC 8446 e 5246), as regras de atualização do registro que definem a coluna “Recommended” (RFC 8447) e a proibição do RC4 (RFC 7465). Onde um registro é a autoridade, seus dados são incorporados diretamente, em vez de redigitados.
Vetores de referência
Cada ferramenta traz um conjunto de vetores de referência: entradas conhecidas pareadas com saídas sabidamente corretas, extraídas das RFCs e dos órgãos de padronização pertinentes. Eles rodam a cada build, de modo que uma refatoração que altere silenciosamente uma resposta quebra o build em vez de ir ao ar.
OWASP
As ferramentas de segurança são definidas com base nos frameworks da OWASP, e não montadas de improviso. As ferramentas de criptografia e TLS mapeiam para as áreas Cryptographic Failures e Security Misconfiguration do OWASP Top 10 e para as verificações correspondentes do Application Security Verification Standard; a ferramenta de tokens segue a orientação da OWASP para inspecionar e validar JWTs. As prevention cheat sheets da OWASP também definem regras rígidas para o que vem a seguir: qualquer tratamento de XML ou SAML acrescentado aqui precisa ser endurecido contra XXE antes de ir ao ar.
Vermelho e azul
A mesma decodificação-e-explicação que permite a um red-teamer ler um token capturado permite a um blue-teamer entender o que a própria stack está emitindo. A plataforma fica deliberadamente do lado da análise dessa linha: ela identifica, decodifica, converte e explica, e não chega a forjar, injetar ou derrotar controles. Essa fronteira é uma decisão de projeto, não um descuido; estas ferramentas existem para ensinar e diagnosticar, não para servir de arma.
Local e determinístico
Tudo roda no navegador. A ferramenta chama uma função pura: dada a mesma entrada, ela retorna a mesma saída, não guarda estado e não envia nada para um servidor. Sem cookies, sem analytics, como a página de Privacidade detalha por completo.
O teto, dito com clareza
Este site roda como um único Cloudflare Worker servindo arquivos estáticos, e essa plataforma tem limites rígidos e publicados que merecem honestidade. Uma versão de Worker pode carregar no máximo 20.000 arquivos estáticos no plano gratuito e 100.000 no plano pago (elevado de 20.000 em setembro de 2025, e somente ao publicar com o Wrangler 4.34 ou mais novo), com nenhum arquivo acima de 25 MiB. As requisições aos próprios arquivos estáticos são gratuitas e ilimitadas; apenas as invocações do script do Worker, como a API, são medidas.
Esses números importam porque esta arquitetura multiplica conteúdo de propósito. Cada página renderizada é publicada como cerca de três arquivos: seu HTML, o payload de navegação do framework e um fragmento do índice de busca, em todos os dezesseis idiomas, e as páginas em inglês e português ainda ganham gêmeas em Markdown legível por máquina. Na prática, uma ferramenta custa cerca de cinquenta arquivos e uma ferramenta com seu artigo companheiro cerca de cem, então o site atual está um pouco acima de dezoito mil arquivos. Sob o teto do plano pago, isso deixa espaço para centenas de ferramentas a mais; o build é medido contra esses limites e, se um dia a caixa de ferramentas realmente superar um único Worker, o caminho de expansão já está traçado: dividir rotas entre Workers adicionais, cada um com sua própria cota, e por fim armazenamento de objetos sem limite algum de contagem.
Isto é vibe coding?
O código é 100% sintetizado pelo Claude.
É uma pergunta justa, e vale a pena respondê-la com clareza. Vibe coding é um termo que o pesquisador de IA Andrej Karpathy cunhou no início de 2025 para uma forma de construir software em que você descreve o que quer a um modelo de linguagem, aceita o que ele escreve sem ler com atenção e se orienta pelos resultados, não pelo próprio código. Ele o descreveu como se entregar à vibe e esquecer que o código sequer existe, e deixou claro que servia mais para projetos rápidos e descartáveis do que para sistemas dos quais as pessoas dependem.
Por essa definição, parte deste site foi construída assim, e é melhor assumir do que esconder. A superfície da aplicação, a ligação do framework, os componentes, a estilização, o encanamento que mantém as páginas juntas, foi produzida rapidamente com um engenheiro de IA e orientada pelo resultado e por um conjunto fixo de regras internas, não digitada à mão linha por linha. Para essa camada, onde um erro é visível e facilmente corrigido, a velocidade era o ponto.
As partes que mais importam seguem um padrão diferente. Tudo o que computa os seus dados é verificado, não feito na vibe: o núcleo de cada ferramenta é conferido contra o padrão publicado que implementa, os RFCs e especificações pertinentes, e a sua saída é confirmada contra referências independentes antes de ser publicada. Como diz uma frase muito citada do programador Simon Willison, código que você revisou, testou e entendeu não é vibe coding de forma alguma. O próprio Karpathy agora chama a versão disciplinada de agentic engineering: manter a alavancagem da IA sem abrir mão da qualidade do resultado. É essa a linha que este projeto traça. Rápido onde a velocidade sai de graça, rigoroso onde importa, e uma pessoa responsável por tudo.
Agradecimentos especiais
Mariana, Ulli, Richard, Ocyrema, Felisberto, Regine, Eduardo, Ricardo, Pedro, Liliane, Tereza, Cezar, Leonardo, Eduardo, Victor, Miu, Nina, Luna, Tux, Kiki, Greg and Theo.
Uma nota sobre o método
Construir software com colaboradores de IA é novo o bastante para que o honesto seja ser transparente a respeito. Nada aqui foi publicado sem que uma pessoa decidisse que deveria ser. As IAs foram instrumentos, instrumentos capazes, mas instrumentos. O julgamento, a responsabilidade e o nome no trabalho são humanos.