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. Não é um truque. É 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 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, 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.