Karpathy: a IA automatiza tudo que dá para verificar

Andrej Karpathy tem o raro talento de dar nome ao que já estava acontecendo. Em 2017, o então diretor de IA da Tesla escreveu o ensaio Software 2.0 e transformou a ideia de rede neural como novo paradigma de programação em vocabulário comum da indústria. Em 2026, no palco do AI Ascent da Sequoia, ele fez de novo. Propôs o Software 3.0 e, junto com ele, uma pergunta desconfortável que reorganiza como pensar automação: o que, no seu trabalho, dá para verificar?

Três eras, uma diferença

A tese de Karpathy é uma escala de três degraus, e o que separa os degraus é o tipo de problema que cada um consegue automatizar.

O Software 1.0 é o código que humanos escrevem à mão. Ele automatiza o que dá para especificar como regra. Se você consegue transformar a tarefa num conjunto de instruções explícitas, um if aqui, um laço ali, o computador executa. É o território do procedimento.

O Software 2.0 são as redes neurais treinadas com dados. Ele automatiza o que dá para descrever com exemplos, mesmo quando ninguém consegue escrever a regra. Não sabemos especificar em código o que faz um gato ser um gato numa imagem, mas sabemos mostrar um milhão de fotos rotuladas. O peso da rede vira o programa, aprendido, não escrito.

O Software 3.0 é a novidade, e é onde estamos entrando. Aqui o humano programa por prompt, contexto, ferramentas, agentes e memória, e o modelo de linguagem executa. Nas palavras de Karpathy, o prompt é o programa, o modelo é o interpretador e a janela de contexto é a memória onde o programa roda. Você não escreve a regra nem treina do zero: você descreve, em linguagem, o comportamento que quer, e monta o contexto certo para o modelo entregar.

A frase que reordena tudo

O ponto mais afiado da fala não é o esquema das três eras, é o critério que define o que o Software 3.0 automatiza. E o critério é a verificabilidade. Segundo Karpathy, o modelo aprende bem, e rápido, aquilo que pode ser verificado por um humano ou por uma máquina: se a resposta pode ser checada por um conjunto de testes, por uma pontuação de jogo ou por um provador de teoremas, então dá para treinar ou instruir o modelo a produzi-la e melhorar sozinho. Onde há um jeito barato e confiável de dizer se está certo, a IA avança. Onde não há, ela patina.

Daí vem a virada que interessa a qualquer profissional. Karpathy sugere trocar a pergunta ansiosa "meu trabalho está seguro?" por outra, mais útil: "meu trabalho é verificável?". Ele acredita que quase tudo é automatizável no limite. A verificabilidade não decide se algo será automatizado, decide a ordem. As tarefas com critério objetivo de acerto vão primeiro. As que dependem de julgamento difícil de checar vão por último. Não é conforto, é um mapa de sequência.

A pergunta deixa de ser se a máquina consegue fazer o seu trabalho, e passa a ser se existe um jeito barato de saber quando ela fez certo.

Karpathy também cravou um marco temporal que vale registrar: para ele, dezembro de 2025 foi o ponto de inflexão em que a codificação com agentes deixou de ser experimental e virou confiável, quando programadores que antes corrigiam linha a linha passaram a delegar a refatoração de subsistemas inteiros. É uma observação de engenheiro, não de profeta, e por isso pesa.

Nossa leitura para quem opera IA

A tese de Karpathy é elegante, mas o valor dela, para quem coloca IA em produção, está no que ela obriga você a fazer antes de automatizar: construir a verificação. E é aqui que a fala do palco encontra o chão da operação.

A primeira consequência prática é que verificabilidade vira critério de priorização. Diante de uma lista de processos candidatos a receber IA, o filtro mais barato é perguntar, para cada um, se existe um jeito objetivo de dizer se a saída está certa. Onde existe, você tem um alvo de ganho rápido e mensurável. Onde não existe, você tem trabalho a fazer antes: precisa desenhar a régua. Isso conversa direto com o argumento de que avaliar é o gargalo real da IA em produção. A verificação não é etapa final, é a condição de entrada.

A segunda consequência é que a maior parte do trabalho de valor está justamente nas tarefas pouco verificáveis, e é lá que a automação ingênua quebra. Se a sua operação joga um agente numa tarefa sem critério de acerto, você não automatizou nada, apenas terceirizou a decisão para um sistema que ninguém checa. A saída não é evitar essas tarefas, é investir em torná-las verificáveis: definir o que é uma boa resposta, criar exemplos de referência, montar uma avaliação que rode a cada mudança. Tarefa que você consegue medir, você consegue melhorar. E isso vale para a infraestrutura que sustenta o agente, o mesmo encanamento de skills e ferramentas que vimos surgir nos lançamentos de ontem no Product Hunt.

A terceira é uma dose de realismo sobre o Software 3.0. Programar por prompt e contexto é poderoso, mas é também um convite ao descontrole se não houver verificação por baixo. A elegância de descrever o comportamento em linguagem esconde o risco de não saber quando o comportamento saiu do trilho. A disciplina que falta na euforia é exatamente a que Karpathy aponta: sem um critério que diga "isto está certo", o Software 3.0 vira aposta cara, não engenharia.

O mérito da fala é transformar uma angústia difusa em uma pergunta acionável. Em vez de temer a automação em abstrato, olhe cada tarefa e responda: dá para verificar? Se dá, prepare-se para automatizar e ganhe cedo. Se não dá, o seu primeiro trabalho não é usar IA, é construir a régua que vai dizer se a IA acertou. Quem monta essa régua antes sai na frente, e não por acaso.

Se você quer classificar as suas tarefas por verificabilidade e montar a régua de avaliação antes de automatizar, fale com a AI Boutique no WhatsApp. A gente ajuda a separar o que já dá para automatizar do que precisa de critério primeiro.