Software 3.0 de Karpathy: o que estou construindo em 2026

Software 3.0 de Karpathy: o que estou construindo em 2026

Eu matei três projetos paralelos no fim de semana passado.

Um planejador de refeições que transformou fotos de supermercado em receitas. Um resumidor de notas de voz do "segundo cérebro". Uma extensão do Chrome que reescreveu as postagens do LinkedIn com sua voz. Todos eles meio construídos. Todos eles estão no meu cemitério ~/projects/abandoned/ agora, com um único arquivo KILLED.md em cada um explicando o porquê.

O motivo foi o mesmo nos três casos: um único prompt multimodal LLM já poderia fazer 80% do que o aplicativo fazia. Eu não estava construindo software. Eu estava construindo o encanamento em torno dos recursos que o modelo já enviava nativamente.

O que me levou a realmente abrir essas pastas e executar o mv ~/projects/[name] ~/projects/abandoned/ não foi o lançamento de um novo modelo. Foi a palestra Sequoia AI Ascent 2026 de Andrej Karpathy - aquela em que ele pronunciou vibe coding "obsoleto" doze meses depois de cunhar o termo, declarou a engenharia agentic como o novo padrão e disse algo que ficou comigo por dias: "A maioria dos aplicativos existentes não deveria existir."

Assisti a muitas palestras do AI este ano. A maioria deles são propostas de fornecedores disfarçadas de visão. O de Karpathy era diferente. Ele não me disse o que usar — ​​ele me deu uma estrutura para avaliar cada linha de código que estou escrevendo agora. Karpathy Software 3.0 não é um produto. É uma lente. E assim que comecei a pesquisar, não consegui parar de ver aplicativos mortos em todos os lugares.

Isso é o que estou processando. O que estou construindo agora. O que me recuso a construir. E o único teste — o teste MenuGen — agora executo em todos os projetos antes de escrever uma linha de código.

O que Karpathy realmente disse (e por que isso é importante agora)

Deixe-me esclarecer o enquadramento primeiro, porque a frase "Software 3.0" foi tão usada que está perdendo o seu valor.

Na palestra da Karpathy [junho de 2025 YC AI Startup School] (https://x.com/karpathy/status/1935518272667217925), ele expôs uma história de software em três estágios:

• Software 1.0 — código que humanos escrevem. Regras explícitas, lógica determinística, toda a internet pré-2012. O que meu diploma de CS me ensinou.
• Software 2.0 — pesos de redes neurais treinados em dados. O modelo aprende a função em vez de o engenheiro especificá-la. Classificadores de imagens, sistemas de recomendação, toda a década do “aprendizado de máquina”.
• Software 3.0 — grandes modelos de linguagem como computadores programáveis. Você os “programa” em inglês (ou em qualquer idioma), com instruções, exemplos, ferramentas e contexto. O prompt é o código-fonte. O LLM é o intérprete.

Essa terceira categoria é aquela que quebrou o cérebro de todo mundo. Escrevemos 1.0 há cinquenta anos e 2.0 há uma década. Agora há uma terceira coisa - e ele não compila, não tem verificação de tipo, não se encaixa em nenhum dos nossos IDEs existentes ou modelos mentais de controle de versão.

Em seu serão no Sequoia 2026, Karpathy foi além: ele sinalizou dezembro de 2025 como o ponto de inflexão - o mês em que o código gerado por AI deixou de ser "útil, mas confuso" e começou a ser consistentemente bom o suficiente para confiar na produção. Sua própria proporção se inverteu naquele mês. Em novembro, ele estava escrevendo cerca de 80% do seu código à mão. Em dezembro, ele estava delegando 80% para agents.

Percebi a mesma coisa em minha própria máquina – simplesmente não tinha linguagem para isso. Em meados de dezembro, parei de revisar todas as diferenças Claude Code linha por linha. Parei de fazer o ritual de “passar o mouse sobre a função e ler caractere por caractere” que construí ao longo dos anos. As diferenças estavam... certas. Nem sempre perfeito, mas certo com frequência suficiente para que o custo da revisão completa exceda o benefício.

Foi nesse momento que o chão se moveu.

E aqui está o que ninguém está dizendo com clareza suficiente: o movimento do chão não significa que o teto subiu. Significa que a maioria dos aplicativos que as pessoas estão construindo atualmente não precisam mais existir.

O que nos leva ao teste.

O teste MenuGen (meu novo filtro pré-construído)

O exemplo de Karpathy foi MenuGen – um aplicativo que ele criou que tirava uma foto do cardápio de um restaurante e renderizava imagens de cada prato para que você pudesse ver o que estava pedindo. Ideia útil. Ele enviou.

Então aconteceu a atualização do Nano Banana do Gemini. Agora você pode fazer upload da foto do menu, digitar “mostre-me como é cada prato” e obter o mesmo resultado in-line. Nenhum aplicativo. Sem back-end. Sem gerenciamento API key. Nenhuma distribuição na App Store. Apenas um único prompt multimodal.

MenuGen tornou-se obsoleto no momento em que um modelo de fronteira pôde fazer o mesmo trabalho nativamente.

Agora executo o que chamo de teste MenuGen em cada ideia de projeto antes de me comprometer com ela:

"Se um único prompt LLM multimodal - para GPT-5.4, Claude Opus 4.7 ou Gemini 3 - puder fazer 80% do que este aplicativo faz, o aplicativo não deveria existir como um aplicativo independente. Ele deveria existir como um prompt, uma mensagem do sistema, uma habilidade salva ou nem deveria existir."

É isso. Esse é o filtro.

Veja a pontuação dos meus três projetos eliminados:

Planejador de refeições a partir de fotos de supermercado. Um usuário carrega uma foto do conteúdo da geladeira → o aplicativo extrai ingredientes → sugere receitas. Teste MenuGen: Coloque uma foto da geladeira no Gemini e digite "dê-me 3 receitas que posso fazer com o que está visível". Funciona. Melhor do que meu aplicativo, na verdade, porque Gemini conhece técnicas de culinária e eu teria passado dois meses em uma integração de visão instável do API. Morto.

Resumidor de notas de voz com integração do segundo cérebro. Grave memo de voz → transcreva → resumir → arquivar na hierarquia no estilo Obsidian. Teste MenuGen: Claude com entrada de áudio e um único servidor MCP apontado para meu cofre Obsidian. Feito. O “aplicativo” consistia em apenas três linhas de cola de orquestração. Morto.

Reescrever postagem do LinkedIn com sua voz. Colar postagem → reescrever no estilo tonal do usuário com base em postagens anteriores. Teste MenuGen: Esse eu tive que pensar. O prompt real pode ser feito em uma única chamada LLM - alimentar postagens anteriores como exemplos de estilo, colar o novo rascunho e reescrever. O trabalho que eu estava construindo não era a reescrita. Foi a autenticação, a integração do LinkedIn API, o agendamento, o espaço de trabalho da equipe, a análise. Nada do que o usuário realmente pediu. Eles pediram "reescrever esta postagem na minha voz". Morto.

Esse terceiro é onde o teste dói. Porque o que eu estava na verdade construindo era um wrapper SaaS em torno de um prompt de 12 linhas. E eu teria enviado. Eu teria cobrado por isso. E seis meses depois, quando ChatGPT ou Claude adicionaram um recurso "combinar meu estilo de escrita a partir de um documento conectado", meu SaaS teria morrido durante a noite junto com cerca de 4.000 outros wrappers "AI X para Y".

O teste MenuGen não é pessimismo. É um filtro de sobrevivência. Se o seu produto pode ser replicado por meio de um único prompt, você não está construindo software – você está construindo um recurso para o produto de outra pessoa.

Isso não significa que nada deva ser construído. Isso significa que temos que construir coisas diferentes.

É disso que se trata o resto.

O que Vibe Coding acertou (e por que Karpathy o enterrou)

Antes de chegarmos ao que construir, precisamos falar sobre a mudança no fluxo de trabalho - porque a maioria das pessoas que conheço ainda são vibe coding, e Karpathy acabou de declarar isso como uma atividade da liga júnior.

Vibe codificação, para ser justo, acertou bastante. Elevou o chão. Qualquer pessoa com bom gosto e paciência agora pode enviar aplicativos funcionais. Já vi não engenheiros enviarem integrações de lojas do Shopify, painéis de equipe internos e ferramentas pessoais em um único fim de semana. Essa elevação do piso é real. Não desapareceu.

Mas o argumento de Karpathy em 2026 é que vibe coding tem um teto – e é baixo. Você pode codificar com vibração para um protótipo funcional. Você pode codificar com vibração para uma v1 que seja bem demonstrada. Você não pode codificar com vibração para confiabilidade de produção. Você não pode vibrar o código por meio de uma auditoria de segurança. Você não pode codificar uma integração que lide com 10.000 usuários simultâneos com eventuais requisitos de consistência em três bancos de dados.

É aí que entra a engenharia agentic. A disciplina que ele está promovendo agora tem uma forma específica:

• Especificações antes do código. Escreva o que o sistema deve fazer, não apenas como você deseja que ele seja. (Meu artigo OpenSpec cobre a versão que eu realmente uso no dia a dia.)
• Planos antes das edições. Faça com que o agent proponha alterações antes de realizá-las. Revise o plano. Então execute. - Testes como sinal primário. Não vibrações. Não "parece certo". Testes reprovados e aprovados como prova de que algo funciona. - Ci loops em cada alteração. Lint, teste, verificação de tipo, verificação de segurança — automatizado, cada commit, sem exceções. - Inspeção de diferenças. Leia o que o agent mudou antes de aceitá-lo. Especialmente para qualquer coisa relacionada a autenticação, faturamento ou dados do usuário. - Isolamento de permissão. Não forneça uma raiz agent em sua máquina.

Use git worktrees para trabalho paralelo. Coloque na areia o que você puder.

Se essa lista parece familiar, é porque se trata apenas de... engenharia de software. As coisas que os engenheiros seniores sempre fizeram. A versão da prática que sobreviveu a uma década de “agir rápido e quebrar coisas”. Karpathy está essencialmente dizendo: AI não eliminou a disciplina de engenharia. Isso tornou a disciplina de engenharia mais importante, porque agora seu colaborador é um júnior fluente, mas não cuidadoso, que precisa do seu julgamento, não da sua velocidade de digitação.

A mudança em 2026 não é “AI substitui engenheiros”. São “engenheiros que podem supervisionar AI substituem engenheiros que apenas digitam código”.

Há uma coisa que digo a todos os desenvolvedores com quem trabalho agora: o valor do seu julgamento acabou de aumentar. O valor da sua digitação caiu. Se você ainda vende digitação, você já está obsoleto. Se você puder especificar, planejar, avaliar e revisar com sinal alto, você acaba de obter um multiplicador de alavancagem de 10x.

E, criticamente – Karpathy fez uma nota de advertência que quase todo mundo está encobrindo.

A armadilha dos "10 agentes" (onde me queimei)

Há um meme circulando agora: "Tenho 20 Claude Code agents rodando em paralelo, aqui está meu fluxo de trabalho." Karpathy olhou para isso e disse, essencialmente, não.

Seu enquadramento: a maioria dos construtores que tentam orquestrar de 10 a 20 agents simultâneos estão à frente do que os modelos atuais podem suportar de forma confiável. A carga de supervisão cresce de forma não linear. No momento em que você gerencia 15 agents, você está gastando todo o seu tempo como um gerente intermediário de troca de contexto e produzindo resultados piores do que um único agent sob supervisão cuidadosa.

Aprendi isso da maneira mais difícil. Há dois meses, tentei configurar um pipeline de geração de conteúdo totalmente paralelo: um agent para pesquisa, um para esboços, um para rascunhos, um para edição, um para verificações de SEO, um para cópia de distribuição. Seis agents. Todos funcionando simultaneamente. Todos "autônomos".

O que realmente aconteceu: cada agent estava produzindo trabalho que o próximo agent não conseguia usar, porque nenhum deles tinha contexto completo. A pesquisa agent revelou fatos que o contorno agent não sabia como pesar. O rascunho agent inventou os enquadramentos do editor agent e depois reescreveu pela metade. O SEO agent inseriu palavras-chave em prosa que o editor já havia polido. Quando o conteúdo chegou até mim, eu estava gastando mais tempo reconciliando seis saídas agents' do que gastaria fazendo tudo com um agent estilo Aria sob rígido controle de contexto.

Eu matei o gasoduto. Agora eu executo um agent por vez, profundamente, com contexto rico — exatamente a abordagem de contexto sobre configuração sobre a qual escrevi no início deste ano. O trabalho é enviado mais rápido. A qualidade é maior. A carga cognitiva sobre mim é menor.

A cautela de Karpathy mapeia perfeitamente o que observei: menos agents, gerenciado com cuidado, com loops de revisão, supera mais agents gerenciado de maneira flexível. Até que os modelos melhorem materialmente na coordenação multi-agent - o que acontecerá, mas ainda não chegaram lá - o movimento certo é otimizar o loop agent único.

Este é um daqueles momentos em que o discurso das redes sociais e a experiência real do profissional divergem acentuadamente. O Twitter quer que você pense que o futuro é 50 agents em um enxame. Karpathy — que tem mais contexto sobre a capacidade do modelo do que basicamente qualquer pessoa no planeta — está dizendo: ainda não. Não para a maioria dos construtores. Não em 2026.

Eu confio nele no Twitter. Você também deveria.

As quatro coisas que vale a pena construir agora

Ok. Portanto, a maioria dos aplicativos não deveria existir. A codificação Vibe é o aquecimento. A orquestração Multi-agent é prematura. O que realmente vale a pena construir?

Karpathy apresentou quatro pilares em sua palestra sobre Sequoia. Cada um passa no teste MenuGen, porque cada um é aditivo ao que os modelos de fronteira fazem nativamente — e não um invólucro em torno do que eles já fazem.

1. Ferramentas que aprimoram a compreensão (não apenas a velocidade)

A primeira onda de ferramentas AI vendeu velocidade. Código mais rápido. E-mails mais rápidos. Projetos mais rápidos. Essa corrida acabou – todos os modelos de todos os fornecedores agora são rápidos o suficiente.

A próxima onda vende clareza estratégica. Ferramentas que ajudam você a pensar melhor, decidir melhor, ver com mais clareza e evitar erros que você não teria detectado sozinho.

O padrão: em vez de “Vou escrever isso para você”, é “deixe-me mostrar o que está faltando”. Em vez de gerar resultados, a ferramenta traz à tona as perguntas que você não fez, as suposições que você está fazendo implicitamente, as decisões escondidas no que parece ser uma única escolha.

Estou construindo exatamente esse tipo de ferramenta agora para meu próprio fluxo de trabalho de conteúdo. Aria — o agent que escreve para rede da minha marca — não produz apenas postagens. Ele executa uma rubrica de autoavaliação em cada rascunho, pontua dez dimensões de retenção e se recusa a enviar até que a rubrica seja aprovada. A saída não é mais rápida. É mais claro, porque o agent revela o que é fraco antes que eu precise.

Esse é o padrão. Não "Eu farei isso por você". Mas "vou mostrar o que você não conseguiu ver e deixar você decidir".

Se você está construindo em 2026, pergunte-se: estou vendendo velocidade ou clareza? Velocidade é uma mercadoria. A clareza é um fosso.

2. Infraestrutura que prioriza o agente

É aqui que fica divertido. Passamos trinta anos construindo software para humanos — teclados, mouses, telas, GUIs. Cada API possui um “painel do desenvolvedor”. Cada produto tem um fluxo de integração. Cada banco de dados possui uma UI do construtor de consultas.

Agora agents são os clientes. E agents não quer UIs. Eles querem APIs. Eles querem metadados limpos. Eles querem esquemas legíveis por máquina. Eles querem respostas de erro previsíveis das quais possam se recuperar. Eles querem uma documentação estruturada, sem muita prosa.

A mudança é enorme e a maioria das equipes de produto ainda não a internalizou. Se o seu produto for usado por um AI agent em nome de um usuário, cada elemento da IU é um ponto de atrito. Cada “clique aqui para confirmar” é um lugar que o agent precisa fazer a ponte entre a intenção da máquina e a interface em forma humana.

Os movimentos concretos a serem feitos agora:

• Enviar um arquivo llms.txt. A adoção é de cerca de 10% no início de 2026. As evidências de aumento de citação são mistas. Mas a implementação leva de 1 a 4 horas e não há desvantagem se a especificação for adotada amplamente. É uma opção de baixo custo para um futuro de alto impacto. - Exponha uma variante Markdown de cada página. Rastreadores Agentic — GPTBot, ClaudeBot, PerplexityBot — preferem consistentemente Markdown a HTML quando ambos são oferecidos. Isso é real, observado e já aparece nas taxas de citação. - Documente seus APIs da mesma forma que você os documentaria para um LLM. Limpe entradas, limpe saídas, operações idempotentes, erros previsíveis. Evite a prosa com sabor de marketing. Um LLM não precisa ser vendido; isso precisa ser dito.

• Envie MCP servers para seu produto. Se sua ferramenta puder ser chamada de dentro de Claude Code, ChatGPT ou qualquer outro tempo de execução agent, você acabou de torná-la 10x mais útil para construtores. (Minha opinião sobre os MCPs indispensáveis cobre o que realmente está funcionando.)

• Trate agents como usuários de primeira classe. Não é um canal secundário para usuários avançados. Não é um "item do roteiro futuro". Trate a persona agent da mesma forma que você trata a persona móvel hoje.

As empresas que acertarem isso cedo parecerão óbvias em retrospectiva. Aqueles que continuam otimizando UIs para cliques humanos enquanto seus concorrentes silenciosamente se tornam nativos de AI-agent vão se perguntar por que seu crescimento estagnou.

3. Aplicativos de domínio verificável (onde RL tem um fosso)

Este é o pilar mais profundo e o menos compreendido. Karpathy argumentou que os verdadeiros fossos defensáveis ​​na próxima década não estarão nas tarefas de linguagem pura – elas estão se tornando rapidamente comoditizadas. Eles estarão em domínios verificáveis: áreas onde você pode verificar mecanicamente se a saída do modelo está correta.

O código é o óbvio. Você pode executar testes. Você pode fiapos. Você pode verificar o tipo. Você pode implantar e observar. Cada um deles é um sinal de feedback que permite que o aprendizado por reforço torne o modelo genuinamente melhor no código ao longo do tempo.

Mas o código não é o único domínio verificável. Veja a lista:

• Negociação algorítmica. P&L é um sinal verificável. Os backtests são reproduzíveis. O mercado é brutal, mas quantificável.
• Cadeia de fornecimento. Níveis de estoque, prazos de entrega, custo por unidade — tudo mensurável, tudo verificável, tudo passível de ajuste fino de RL.
• Limpeza de dados e ETL. Correção de esquema, validação de tipo, integridade referencial — tudo isso é verificável. O modelo pode ser treinado em pipelines de verdade.
• Conformidade e auditoria. Requisitos regulatórios são regras. Os dados os atendem ou não. Esse é um sinal de verificação.
• Simulação científica. Física, química, ciência dos materiais — em qualquer lugar você tem um modelo de referência que pode validar previsões.

Se você está construindo em um domínio onde a correção é verificável, você tem um verdadeiro fosso. Porque os dados que você coleta da produção se tornam dados de treinamento que tornam seu modelo específico melhor em sua tarefa específica - e seus concorrentes que estão chamando o vanilla GPT-5.4 com um prompt inteligente irão se estabilizar no mesmo lugar em que todos os outros concorrentes com prompt vanilla se estabilizarão.

Se você estiver construindo em um domínio onde a correção não é verificável – tarefas puramente criativas, decisões que “parecem certas”, julgamentos suaves – o fosso é muito mais fraco. O modelo de fronteira alcançará sua engenharia imediata eventualmente, e provavelmente em breve.

Este é o insight estratégico mais importante da palestra de Karpathy e quase ninguém o repete. A verificabilidade é o fosso. Se o seu produto tiver um sinal de correção mensurável, você pode combinar. Se isso não acontecer, você é um invólucro.

4. Aplicativos nativos Software 3.0 (planilhas não mais rápidas)

O quarto pilar é o mais difícil porque exige imaginação e não apenas engenharia.

A maioria dos "recursos AI" enviados em 2026 são aplicativos Software 1.0 com um AI integrado. Planilha com barra lateral que explica fórmulas. Cliente de e-mail com um botão "resumir este tópico". Rastreador de projeto com um comando "draft my standup update".

Estes são úteis. Eles não são Software 3.0.

Um aplicativo Software 3.0-native é aquele que não poderia ter existido antes que os LLMs fossem o substrato. Ele assume o LLM da mesma forma que um aplicativo 1.0 assume uma CPU. O modelo não é um recurso dentro do aplicativo — o modelo é o tempo de execução em que o aplicativo é executado.

Veja Vibe App Builder de monday.com. Pense no que realmente é: um sistema onde um não-desenvolvedor descreve um aplicativo em linguagem natural e a plataforma gera uma ferramenta interna funcional – UI, conexões de dados, permissões, tudo funciona. A monday enviou mais de 19 recursos e 26 testes A/B para aplicativos Vibe somente no primeiro trimestre de 2026. O ritmo crescente indica que eles encontraram algo real.

O interessante não é que ele gera aplicativos. É que o modelo de interação é fundamentalmente diferente das ferramentas sem código do passado. Não há arrastar e soltar. Não há fluxograma visual. O usuário descreve o que deseja em inglês, o LLM propõe um aplicativo funcional, o usuário refina através do chat. O aplicativo não existe como código estático — ele existe como uma conversa viva entre intenção e execução.

Esse é Software 3.0-native. A descrição em inglês é o código-fonte. O LLM é o compilador. O aplicativo é o executável.

Se você estiver construindo agora, a atitude de maior alavancagem é perguntar: o que se torna possível quando o LLM é o substrato, não um recurso? Não "como faço para adicionar AI ao meu aplicativo" - mas "qual aplicativo só poderia existir porque LLMs existem?"

Exemplos que estou observando de perto:

• Mecanismos de contexto pessoal — aplicativos que aprendem seus padrões específicos com profundidade suficiente para gerar ferramentas de trabalho personalizadas para você, não para "usuários". Consulte [a abordagem de habilidades CLAUDE.md do próprio Karpathy] (https://www.mejba.me/blog/karpathy-claude-md-skills-install-guide) para obter a versão inicial disso.
• Aplicativos efêmeros — aplicativos que existem para um fluxo de trabalho e são dissolvidos depois. Sem instalação, sem inscrição. O modelo os gira em resposta a uma necessidade.
• Serviços gerenciados por agente — produtos em que toda a camada voltada ao cliente é um agent, não uma UI, e o "produto" é o ciclo de raciocínio do agent.
• Sistemas de especificação contínua — software onde a especificação fica próxima ao código e as alterações se propagam através de ambas as camadas, automaticamente. (Traycer's Bart mode é um vislumbre disso.)

Isso não é ficção científica. Eles estão sendo construídos agora, em pequenos números, por construtores que ignoraram a armadilha "deixe-me adicionar um recurso AI ao meu SaaS".

Como estou reestruturando meu próprio trabalho

Chega de teoria. Aqui está o que realmente mudei em meu fluxo de trabalho depois de conversar por uma semana.

Um. Excluí três projetos paralelos e adicionei uma lista de verificação MenuGen test ao meu modelo de entrada de projeto. Cada nova ideia agora precisa responder à pergunta: um único prompt multimodal pode fazer 80% disso? Se sim, ele não é construído. Ele é salvo como um prompt na minha pasta Claude Skills.

Dois. Mudei minha configuração de agent de experimental paralelo para agent de profundidade única. Descartei um pipeline de conteúdo de seis agent e voltei a executar uma instância Aria por vez, com contexto rico, supervisão cuidadosa e ciclos de revisão rígidos. A qualidade da saída aumentou imediatamente. A postagem que você está lendo agora foi produzida dessa forma.

Três. Adicionei um llms.txt a mejba.me, ramlit.com, colorpark.io e xcybersecurity.io. Demorou talvez 90 minutos para todos os quatro. A adoção é moderada, as evidências de citação são mistas, mas o custo de ignorar será alto se a pesquisa AI continuar crescendo da mesma forma que vem crescendo. Opcionalidade barata.

Quatro. Comecei a auditar todos os projetos ativos em relação aos quatro pilares. Se um projeto não se enquadra em um deles - ferramenta de clareza, agent-first infra, domínio verificável ou Software 3.0-native - ele está em risco. Até agora, mais um projeto foi eliminado e dois foram reestruturados.

Cinco. Estou investindo agressivamente no lado disciplinar do desenvolvimento do AI — especificações, planos, análises, testes — e diminuindo a ênfase na velocidade de digitação, ajustes de prompt e coleta de ferramentas. A alavancagem está em julgamento agora. Eu ajo de acordo.

Seis. Estou aguardando a próxima inflexão. Karpathy estava certo em dezembro de 2025. A próxima grande mudança - quando a execução de 20 agents em paralelo realmente funciona, quando os modelos podem se autoespecificar de forma confiável, quando RL de domínio verificável produz capacidade sobre-humana genuína em um nicho - está chegando. Quero estar preparado para reconhecê-lo dentro de uma semana, não um quarto. Isso significa ficar perto do limite do profissional, não do limite principal.

A única coisa com a qual vale a pena sentar

Se você pegar algo da palestra de Karpathy e de todo este post, pegue isto:

O trabalho não é construir software. A tarefa é construir aquilo que o software agora torna possível.

Durante trinta anos, “construir software” foi o objetivo porque o software era a restrição. Você precisava de um aplicativo porque não conseguiria fazer nada sem ele. O aplicativo era o gargalo.

O software não é mais o gargalo. O tempo de execução LLM é o gargalo – e o gargalo está se movendo mais rápido do que qualquer equipe de produto pode. Portanto, construir “um aplicativo” dentro de uma categoria que já está comoditizada na camada do modelo é um jogo perdido. Você enviará e, três meses depois, o modelo incluirá você.

O jogo vencedor é construir para o modelo, em cima do modelo ou em domínios onde o modelo sozinho não pode vencer. Ferramentas de clareza. Infraestrutura que prioriza o agente. Experiência em domínio verificável. Experiências Software 3.0-native. Estas são as quatro apostas que parecem óbvias daqui a cinco anos.

Todo o resto — incluindo a maioria dos projetos que abri em meu IDE na semana passada — era MenuGen. E MenuGen agora é um recurso, não um produto.

Vá dar uma olhada na sua pasta ~/projects/ esta noite. Faça o teste em cada um deles. Seja honesto. A maioria de nós está construindo recursos em torno de capacidades que já existem no modelo. Alguns de nós estamos construindo algo que só existe porque o modelo existe.

A diferença entre os dois é a diferença entre um projeto paralelo e um projeto que define a carreira. Karpathy acabou de nos entregar o teste para diferenciá-los. O resto é por nossa conta.

O que você matou esta semana?

Perguntas frequentes

O que é Karpathy de Software 3.0 em inglês simples?

Software 3.0 é quando LLMs se torna o tempo de execução e a linguagem natural se torna o código-fonte. O software 1.0 era um código escrito à mão. O software 2.0 foi treinado com pesos de redes neurais. Software 3.0 está solicitando um LLM que interpreta sua intenção e a executa. Para o modelo mental completo, consulte a seção de abertura acima.

vibe coding morrerá em 2026?

Não – vibe coding ainda funciona para protótipos, projetos de fim de semana e elevação de piso para não engenheiros. O que Karpathy retirou foi vibe coding como abordagem de produção. Para software distribuível, a engenharia agentic – especificações, planos, testes, CI e revisão de diferenças – agora é o padrão. Consulte "O que Vibe Coding acertou" acima.

O que é o teste MenuGen?

O teste MenuGen pergunta: se um único prompt multimodal LLM pode fazer 80% do que seu aplicativo faz, o aplicativo não deveria existir como um produto independente. Ele vem do exemplo MenuGen de Karpathy – um aplicativo real que ele construiu e que se tornou obsoleto no momento em que a atualização Nano Banana do Gemini pôde fazer o mesmo trabalho em um prompt.

Devo construir um sistema multi-agent em 2026?

Provavelmente ainda não. Karpathy alertou explicitamente contra a execução de 10 a 20 agents simultâneos – os modelos atuais não coordenam tão bem e a carga de supervisão destrói a qualidade. Um agent sob supervisão cuidadosa supera seis mal gerenciados. Revisite isso em 6–12 meses.

O que é a infraestrutura agent-first?

A infraestrutura do agente primeiro é um software projetado para AI agents como usuários principais - APIs limpos, metadados legíveis por máquina, arquivos llms.txt, documentação Markdown-first, MCP servers e respostas de erro previsíveis. A mudança é tratar agents como uma persona de primeira classe, não como um canal secundário. Consulte o pilar 2 acima para movimentos concretos.

Vamos trabalhar juntos

Procurando construir sistemas AI, automatizar fluxos de trabalho ou dimensionar sua infraestrutura tecnológica? Eu adoraria ajudar.

• Fiverr (compilações e integrações personalizadas): fiverr.com/s/EgxYmWD
• Portfólio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design e marca): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io