Colofão
Como este site foi construído
A maioria dos sites não se explica. Este se explica, porque o modo como foi feito faz parte do que ele é: um experimento proposital de construir bem, com colaboradores fora do comum, e um registro que vale guardar.
Tudo no ronutz
O diretório completo, agrupado pelo que você veio fazer.
Entender
ler
- Aprender751 artigos
- Séries de artigos70 séries
- Histórias9 narrativas
- Guias de estudo13 trilhas de leitura
- Materiais abertos1 curso
- Guias de certificação105 guias
- Glossário1817 verbetes
- A Prática64 publicados
Explorar
rastrear
- Indústria364 empresas
- Hubs de fabricantes8 hubs de fabricantes
- Pessoas
- Os Papéis43 cargos
Trabalhe comigo
contratar
- Sobre
- Depoimentos89 na íntegra
- O registro de carreira21 capítulos
- Treinamentos que ministro28 cursos de 4 fabricantes
- Consultoria
- Palestras
- Red Education
CONCORD
Este site foi projetado e construído com um protocolo chamado CONCORD: uma colaboração estruturada entre uma pessoa e três sistemas de IA diferentes, cada um num papel próprio. É um método de trabalho, com governança própria, registro de decisões próprio e uma única pessoa responsável por cada escolha que foi ao ar.
A premissa é simples. Modelos de IA diferentes têm pontos fortes diferentes, e um problema difícil ganha com mais de uma perspectiva mantida 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 outro lugar. 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 forte em algo diferente, sem abrir mão do fio único de responsabilidade humana que o trabalho de verdade exige. A resposta foi dar a cada sistema uma cadeira definida, impedir que negociassem entre si e fazer cada troca passar por uma única pessoa, que tinha a visão do todo. Esse arranjo tem um nome mais antigo. Os sistemas de IA são agentes: agem sob orientação e em nome de outra pessoa. O PRIME é o principal: quem de fato decide, quem exerce o julgamento e quem carrega tanto as consequências quanto o nome.
A alavancagem é dos agentes. A responsabilidade é do principal, e não se transfere.
Começou de modo informal, como um jeito de dividir o trabalho, e ao longo da construção se firmou como um método com nome: cadeiras fixas, uma única regra acima de todas (nada vai ao ar sem que o PRIME ratifique) e um registro escrito do porquê de cada escolha. O nome diz o objetivo: concórdia, um acordo alcançado de propósito, por meio de um processo, e não o que quer que uma ferramenta sem supervisão acabe produzindo.
Como funciona, em termos simples
As cadeiras
- PRIMERodolfo NützmannHumano
O principal, e o único ratificador. Cada decisão, cada linha que foi ao ar, passou por uma pessoa que tinha a visão do todo e carregava a responsabilidade final. Os agentes propunham; o PRIME dispunha.
- ANVILEngenhariaAnthropic · Claude Fable 5 → Opus 4.8
A cadeira de engenheiro-chefe. Arquitetura, código, estrutura de conteúdo e o próprio build, transformados de intenção em um site que funciona, testado e pronto para deploy.
- SCOUTEstratégia e marcaOpenAI · ChatGPT 5.5
A cadeira de estratégia e posicionamento. As perguntas sobre o que isto é, para quem é e como deve se apresentar ao mundo.
- PRISMDesignGoogle · Gemini 3.1 Pro
A cadeira de design. A linguagem visual, a tipografia, a cor e a sensação do conjunto, moldadas num 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 do catálogo calculam as respostas localmente e de forma determinística. Elas não chamam um servidor com a sua entrada e não fazem aproximações: o que roda no seu navegador fica no seu navegador. A sala vermelha é a exceção declarada: umas poucas ferramentas cujo trabalho é consultar um serviço ao vivo, e que avisam isso antes de você apertar Perguntar. As ferramentas mais antigas têm linhagem: uma calculadora de bits e bytes, uma calculadora de endereçamento IP e uma pinagem de cabos já estavam no nutzmann.net em 2004 e no ntz.com.br em 2013, e o Internet Archive ainda as guarda.
Aberto no núcleo
A lógica determinística que cada ferramenta do catálogo executa é a ferramenta inteira. Não há etapa escondida em servidor, não há conta, e nada sobre o seu uso de uma ferramenta é enviado a lugar nenhum. Tudo no andar principal roda no seu navegador.
Documentado por construção
Cada parte do código é comentada e documentada, não como algo pensado depois, mas como regra permanente. O build é feito para ser legível, para quem o mantém e para quem vier a herdá-lo.
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. Foi estruturado desde a base para muitos idiomas, e por isso pode falar com um público global sem ser reconstruído.
Assimilado, com fontes
Boas ideias são adotadas aqui, venham de onde vierem: a nota de um leitor, uma revisão externa, a documentação de um fabricante, um padrão, um hábito de outro site que vale a pena ter. Cada uma chega com a fonte identificada, na entrada do changelog que a adota e na página que a traz, para que o caminho da ideia até a origem nunca se perca. Dois headers de resposta dizem a mesma coisa a quem lê headers: o X-Clacks-Overhead leva o nome de Terry Pratchett no overhead, como milhares de sites fazem desde 2015, e o X-Collective declara o método em seis palavras. A resistência é inútil; a atribuição é obrigatória.
A stack
Para quem se interessa por essas coisas, a base técnica, dita sem rodeios.
- Framework
- Next.js 15 e React 19, exportados como site totalmente estático
- Internacionalização
- next-intl, com 16 idiomas e suporte à escrita da direita para a esquerda
- Design system
- 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 é a fonte: escrito com IA e publicado só quando uma pessoa decide que deve ser. O português do Brasil também é escrito com IA e revisado aos poucos; os demais idiomas são traduzidos por máquina. Cada idioma é marcado pelo quanto já avançou: azul quando cobre o site inteiro, amarelo enquanto conteúdo novo ainda está em inglês e se atualizando, vermelho quando ainda não tem tradução e aparece em inglês por ora. Todo idioma além do inglês traz um aviso curto, e você é bem-vindo a ajudar a melhorar qualquer um deles.
- 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 a partir dos documentos que definem os seus formatos e amarrados aos vetores de teste que esses documentos publicam, de modo que cada resposta é conferida com a fonte da verdade, e não consigo mesma.
As especificações
Os JSON Web Tokens seguem a RFC 7519, com assinaturas e algoritmos nas RFCs 7515 e 7518; o PKCE é a RFC 7636; o Base64 e as suas variantes são a RFC 4648; os UUIDs são a RFC 9562 (que tornou obsoleta a RFC 4122 em 2024 e traz os próprios vetores de teste); o HMAC é a RFC 2104, sobre a família SHA padronizada nos FIPS 180-4 e FIPS 202; os certificados X.509 são a RFC 5280; o IPv4 é a RFC 791 e a notação CIDR é a RFC 4632; o endereçamento IPv6 e a sua forma textual canônica são as RFCs 4291 e 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 (RFCs 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). Quando a autoridade é um registro, os dados dele são incorporados diretamente, e não redigitados.
Vetores de referência
Cada ferramenta vem com um conjunto de vetores de referência (golden vectors): entradas conhecidas, cada uma com a sua saída sabidamente correta, tiradas das RFCs e dos órgãos de padronização pertinentes. Eles rodam a cada build, e por isso uma refatoração que mude uma resposta sem ninguém perceber 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 de TLS correspondem às áreas Cryptographic Failures e Security Misconfiguration do OWASP Top 10 e às verificações equivalentes do Application Security Verification Standard; as ferramentas de tokens seguem 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 vier a seguir: qualquer tratamento de XML ou SAML acrescentado aqui precisa passar por hardening contra XXE antes de ir ao ar.
Red team e blue team
O mesmo decodificar e explicar que deixa um red-teamer ler um token capturado deixa um blue-teamer entender o que a própria stack está emitindo. A plataforma fica, de propósito, do lado da análise dessa linha: ela identifica, decodifica, converte e explica, e para antes de forjar, injetar ou burlar controles. Esse limite é uma decisão de projeto, não um descuido; estas ferramentas existem para ensinar e diagnosticar, não para virar arma.
Local e determinístico
Toda ferramenta do catálogo roda no navegador. Ela chama uma função pura: para a mesma entrada, devolve a mesma saída, não guarda estado e não manda nada para servidor nenhum. As ferramentas da sala vermelha são a exceção declarada: consultas ao vivo que dizem o nome do serviço que consultam. Sem cookies e sem analytics de terceiros; a contagem agregada de requisições que o próprio site faz está descrita na íntegra na página de Privacidade.
O teto, sem rodeios
Este site roda como um único Cloudflare Worker que serve arquivos estáticos, e essa plataforma tem limites rígidos e publicados sobre os quais vale ser honesto. Uma versão de Worker pode levar no máximo 20.000 arquivos estáticos no plano gratuito e 100.000 no plano pago (limite elevado de 20.000 em setembro de 2025, e só ao fazer o deploy com o Wrangler 4.34 ou mais recente), e nenhum arquivo pode passar de 25 MiB. As requisições aos arquivos estáticos em si são gratuitas e ilimitadas; só as invocações do script do Worker, como a API, são medidas.
Esses números importam porque esta arquitetura multiplica o conteúdo de propósito. Cada página renderizada vai ao ar como uns três arquivos (o HTML, o payload de navegação do framework e um fragmento do índice de busca), nos dezesseis idiomas, e as páginas em inglês e em português ainda ganham gêmeas em Markdown, legíveis por máquina. Na prática, uma ferramenta custa uns cinquenta arquivos, e uma ferramenta com o artigo que a acompanha, uns cem; por isso o site está hoje com pouco mais de dezoito mil arquivos. Dentro do teto do plano pago, isso deixa espaço para centenas de ferramentas a mais; o build é conferido com esses limites e, se um dia a caixa de ferramentas realmente ficar grande demais para um único Worker, o caminho de expansão já está traçado: dividir as rotas entre Workers adicionais, cada um com a sua própria cota, e, por fim, um armazenamento de objetos sem limite nenhum de quantidade.
Isso é 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 feita assim, e é melhor assumir isso do que esconder. A superfície da aplicação (a integração com o framework, os componentes, os estilos, a cola que mantém as páginas unidas) foi produzida rápido com um engenheiro de IA e guiada pelo resultado e por um conjunto fixo de regras da casa, não digitada à mão, linha por linha. Nessa camada, onde um erro fica visível e é fácil de corrigir, o que importava era a velocidade.
As partes que mais importam seguem outro padrão. Tudo o que faz cálculo com os seus dados é verificado, não feito na vibe: o núcleo de cada ferramenta é conferido com o padrão publicado que ela implementa, as RFCs e especificações pertinentes, e a saída é confirmada com referências independentes antes de ir ao ar. Como diz uma frase muito citada do programador Simon Willison, código que você revisou, testou e entendeu não é vibe coding de jeito nenhum. O próprio Karpathy hoje 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 ainda é tão novo que o honesto é ser transparente sobre isso. Nada aqui foi publicado sem que uma pessoa decidisse que deveria ser. As IAs foram instrumentos, e capazes, mas instrumentos. O julgamento, a responsabilidade e o nome que vai no trabalho são humanos.