Este fim de semana, Andrej Karpatiao ex-diretor de IA da Tesla e membro fundador da OpenAI, decidiu que queria ler um livro. Mas ele não queria ler sozinho. Ele queria lê-lo acompanhado por um comitê de inteligências artificiais, cada uma oferecendo sua própria perspectiva, criticando as outras e, eventualmente, sintetizando uma resposta final sob a orientação de um "Presidente."
Para que isso acontecesse, Karpathy escreveu o que chamou de "projeto de código vibe" – um software escrito rapidamente, em grande parte por assistentes de IA, destinado à diversão e não à função. Ele postou o resultado, um repositório chamado "Conselho LLM," para o GitHub com um aviso severo: "Não vou apoiar isso de forma alguma… O código é efêmero agora e as bibliotecas acabaram."
No entanto, para os decisores técnicos em todo o cenário empresarial, olhar para além da isenção de responsabilidade casual revela algo muito mais significativo do que um brinquedo de fim de semana. Em algumas centenas de linhas de Pitão e JavaScriptKarpathy esboçou uma arquitetura de referência para a camada mais crítica e indefinida da pilha de software moderna: o middleware de orquestração situado entre aplicativos corporativos e o mercado volátil de modelos de IA.
À medida que as empresas finalizam seus investimentos em plataforma para 2026, Conselho LLM oferece um olhar despojado "construir vs. comprar" realidade da infraestrutura de IA. Ele demonstra que, embora a lógica de roteamento e agregação de modelos de IA seja surpreendentemente simples, o invólucro operacional necessário para torná-lo pronto para a empresa é onde reside a verdadeira complexidade.
Como funciona o Conselho LLM: Quatro modelos de IA debatem, criticam e sintetizam respostas
Para o observador casual, o Conselho LLM O aplicativo da web parece quase idêntico ao ChatGPT. Um usuário digita uma consulta em uma caixa de bate-papo. Mas nos bastidores, o aplicativo aciona um fluxo de trabalho sofisticado em três estágios que reflete como funcionam os órgãos humanos de tomada de decisão.
Primeiramente, o sistema despacha a consulta do usuário para um painel de modelos de fronteira. Na configuração padrão do Karpathy, isso inclui OpenAI GPT-5.1do Google Gêmeos 3.0 PróAntrópico Soneto de Claude 4.5e xAIs Grok 4. Esses modelos geram suas respostas iniciais em paralelo.
Na segunda etapa, o software realiza uma revisão por pares. Cada modelo é alimentado com respostas anônimas de suas contrapartes e solicitado a avaliá-las com base na precisão e no insight. Esta etapa transforma a IA de gerador em crítica, forçando uma camada de controle de qualidade que é rara em interações padrão de chatbot.
Finalmente, um designado "Presidente LLM" – atualmente configurado como Gemini 3 do Google – recebe a consulta original, as respostas individuais e as classificações dos pares. Ele sintetiza essa massa de contexto em uma resposta única e confiável para o usuário.
Karpathy observou que os resultados foram muitas vezes surpreendentes. "Muitas vezes, os modelos estão surpreendentemente dispostos a selecionar a resposta de outro LLM como superior à sua," ele escreveu no X (antigo Twitter). Ele descreveu o uso da ferramenta para ler capítulos de livros, observando que os modelos elogiaram consistentemente o GPT-5.1 como o mais perspicaz, enquanto classificavam Claude como o mais baixo. No entanto, a avaliação qualitativa do próprio Karpathy divergiu do seu conselho digital; ele encontrou GPT-5.1 "muito prolixo" e preferiu o "condensado e processado" saída de Gêmeos.
FastAPI, OpenRouter e o argumento para tratar modelos de fronteira como componentes trocáveis
Para CTOs e arquitetos de plataforma, o valor de Conselho LLM não reside na sua crítica literária, mas na sua construção. O repositório serve como um documento principal que mostra exatamente como seria uma pilha de IA moderna e mínima no final de 2025.
O aplicativo é construído em um "afinar" arquitetura. O back-end usa API rápidaum moderno Pitão framework, enquanto o frontend é um padrão Reagir aplicativo construído com Rapidamente. O armazenamento de dados não é feito por um banco de dados complexo, mas por simples Arquivos JSON gravado no disco local.
O eixo de toda a operação é OpenRouterum agregador de API que normaliza as diferenças entre vários provedores de modelos. Ao encaminhar solicitações por meio desse corretor único, Karpathy evitou escrever código de integração separado para OpenAI, Googlee Antrópico. O aplicativo não sabe nem se importa com qual empresa fornece a inteligência; ele simplesmente envia um prompt e aguarda uma resposta.
Esta escolha de design destaca uma tendência crescente na arquitetura empresarial: a comoditização da camada de modelo. Ao tratar os modelos de fronteira como componentes intercambiáveis que podem ser trocados editando uma única linha em um arquivo de configuração — especificamente a lista COUNCIL_MODELS no código backend — a arquitetura protege o aplicativo contra dependência de fornecedor. Se um novo modelo da meta ou Mistral estiver no topo das tabelas de classificação na próxima semana, poderá ser adicionado ao conselho em segundos.
O que falta do protótipo à produção: autenticação, redação de PII e conformidade
Embora a lógica central da Conselho LLM é elegante, também serve como uma ilustração nítida da lacuna entre um "hack de fim de semana" e um sistema de produção. Para uma equipe de plataforma empresarial, clonar o repositório do Karpathy é apenas o primeiro passo de uma maratona.
Uma auditoria técnica do código revela a falta "tedioso" infraestrutura que os fornecedores comerciais vendem por preços premium. O sistema não possui autenticação; qualquer pessoa com acesso à interface web pode consultar os modelos. Não existe conceito de funções de usuário, o que significa que um desenvolvedor júnior tem os mesmos direitos de acesso que o CIO.
Além disso, a camada de governação é inexistente. Num ambiente corporativo, o envio de dados para quatro fornecedores externos diferentes de IA simultaneamente desencadeia preocupações imediatas de conformidade. Não há nenhum mecanismo aqui para redigir informações de identificação pessoal (PII) antes que elas saiam da rede local, nem há um registro de auditoria para rastrear quem perguntou o quê.
A confiabilidade é outra questão em aberto. O sistema assume a API OpenRouter está sempre ativo e que os modelos responderão em tempo hábil. Faltam disjuntores, estratégias de fallback e lógica de repetição que mantêm os aplicativos críticos para os negócios em execução quando um provedor sofre uma interrupção.
Estas ausências não são falhas no código de Karpathy – ele afirmou explicitamente que não pretende apoiar ou melhorar o projeto – mas definem a proposta de valor para o mercado comercial de infraestrutura de IA.
Empresas como LangChain, Base da AWSe várias startups de gateway de IA estão essencialmente vendendo o "endurecimento" em torno da lógica central que Karpathy demonstrou. Eles fornecem os wrappers de segurança, observabilidade e conformidade que transformam um script de orquestração bruto em uma plataforma empresarial viável.
Por que Karpathy acredita que o código é agora "efêmero" e bibliotecas de software tradicionais estão obsoletas
Talvez o aspecto mais provocativo do projecto seja a filosofia sob a qual foi construído. Karpathy descreveu o processo de desenvolvimento como "99% codificado por vibração," o que implica que ele dependia muito de assistentes de IA para gerar o código, em vez de escrevê-lo linha por linha.
"O código é efêmero agora e as bibliotecas acabaram, peça ao seu LLM para alterá-lo da maneira que desejar," ele escreveu na documentação do repositório.
Esta declaração marca uma mudança radical na capacidade de engenharia de software. Tradicionalmente, as empresas constroem bibliotecas e abstrações internas para gerenciar a complexidade, mantendo-as por anos. Karpathy está sugerindo um futuro onde o código será tratado como "andaime pronto" – descartável, facilmente reescrito pela IA e não feito para durar.
Para os decisores empresariais, isto coloca uma questão estratégica difícil. Se as ferramentas internas puderem ser "vibração codificada" em um fim de semana, faz sentido comprar pacotes de software rígidos e caros para fluxos de trabalho internos? Ou as equipes de plataforma deveriam capacitar seus engenheiros para gerar ferramentas personalizadas e descartáveis que atendam exatamente às suas necessidades por uma fração do custo?
Quando os modelos de IA julgam a IA: a lacuna perigosa entre as preferências da máquina e as necessidades humanas
Além da arquitetura, o Conselho LLM O projeto inadvertidamente ilumina um risco específico na implantação automatizada de IA: a divergência entre o julgamento humano e o da máquina.
A observação de Karpathy de que seus modelos preferiam o GPT-5.1, enquanto ele preferia o Gemini, sugere que os modelos de IA podem ter preconceitos compartilhados. Eles podem favorecer a verbosidade, a formatação específica ou a confiança retórica que não necessariamente se alinha com as necessidades humanas de brevidade e precisão dos negócios.
À medida que as empresas dependem cada vez mais de "LLM como juiz" sistemas para avaliar a qualidade de seus bots voltados para o cliente, essa discrepância é importante. Se o avaliador automatizado recompensa consistentemente "prolixo e espalhado" respostas enquanto os clientes humanos desejam soluções concisas, as métricas mostrarão sucesso enquanto a satisfação do cliente despenca. A experiência de Karpathy sugere que confiar apenas na IA para avaliar a IA é uma estratégia repleta de problemas de alinhamento ocultos.
O que as equipes de plataforma empresarial podem aprender com um hack de fim de semana antes de construir sua pilha de 2026
Em última análise, Conselho LLM atua como um teste de Rorschach para a indústria de IA. Para o hobby, é uma forma divertida de ler livros. Para o fornecedor, é uma ameaça, provando que a funcionalidade central dos seus produtos pode ser replicada em algumas centenas de linhas de código.
Mas para o líder em tecnologia empresarial, é uma arquitetura de referência. Desmistifica a camada de orquestração, mostrando que o desafio técnico não está no roteamento dos prompts, mas no controle dos dados.
À medida que as equipes da plataforma avançam para 2026, muitos provavelmente se verão olhando para o código de Karpathy, não para implantá-lo, mas para entendê-lo. Isto prova que uma estratégia multimodelo não está tecnicamente fora de alcance. A questão que permanece é se as próprias empresas construirão a camada de governança ou pagarão alguém para envolver a camada de governança. "código de vibração" em armadura de nível empresarial.
