O que finalmente queremos ensinar ao modelo é a mesma coisa que ensinamos às crianças.

Autor do artigo, fonte: Machine Heart

Muitas pessoas dizem que, na era da IA, o gosto é a última muralha defensiva da humanidade. Mas Boris Cherny não concorda.

Ele é membro técnico da Anthropic e um dos principais construtores do Claude Code. Ele usa modelos para escrever código todos os dias e também os utiliza para estudar modelos. A tendência que ele observou é que o chamado "gosto" também está sendo rapidamente aprendido pelos modelos.

Se até o que fazer puder ser dominado pelo modelo, o que ainda resta ao ser humano?

Em uma entrevista recente, Boris falou sobre esse assunto.

Como o Claude Code transforma fundamentalmente os sistemas das empresas;

Quando modelos podem escrever a maioria do código, ainda vale a pena contratar engenheiros? Se sim, o que deve ser considerado?

Por que muitas pessoas dentro da Anthropic são Member of Technical Staff, sem níveis e divisões de funções claros?

Um conselho antiintuitivo para todos os empreendedores: por que “contrate menos pessoas e dê mais tokens”?

……

Essas questões aparentemente tratam do nascimento e da iteração de um produto, mas cada resposta aponta para a mesma mudança mais fundamental: a forma como a organização opera está sendo redefinida pelo próprio modelo.

A resposta dada por Boris merece uma reflexão calma.

Como o Claude Code nasceu?

Quando o apresentador perguntou sobre a origem do Boris Claude Code, a resposta dada foi um pouco inesperada.

Em sua narrativa, o Claude Code não era originalmente um produto central planejado pela Anthropic, e em certa medida pode ser considerado um produto acidental.

No final de 2024, Boris juntou-se à equipe de Labs da Anthropic. A responsabilidade dessa equipe não é manter produtos existentes, mas explorar futuras formas de produtos. Por um lado, eles precisam constantemente empurrar os limites das capacidades do modelo; por outro lado, também estão buscando novos produtos que possam realmente liberar essas capacidades.

Na época, a equipe tinha uma sensação muito forte: o modelo já possuía capacidades muito além dos produtos existentes, mas ainda não havia no mercado nenhum produto capaz de aproveitar plenamente essas capacidades. Isso era especialmente verdadeiro no campo da programação.

Naquela época, as ferramentas de programação baseadas em IA no mercado ainda se limitavam a duas abordagens. Uma era a preenchimento automático, ajudando desenvolvedores a completar a próxima linha de código; a outra era a de assistentes de perguntas e respostas, nos quais desenvolvedores podiam perguntar sobre o significado de um trecho de código ou a solução para um erro. Mas Boris acreditava que, naquela época, ainda não existia um Coding Agent verdadeiro.

Então, a equipe decidiu fazer uma tentativa mais ousada: em vez de usar o modelo como uma ferramenta de apoio, transformá-lo diretamente no núcleo do desenvolvimento. Eles queriam ver o que aconteceria se construíssem do zero um produto de programação inteiramente centrado em Agentes.

No entanto, Boris também admitiu francamente que o Claude Code inicial não era fácil de usar.

Por muito tempo, ele só conseguia realizar cerca de 10% a 20% do trabalho. A maior parte do código ainda precisava ser escrita manualmente por ele. O Claude Code que as pessoas veem hoje é completamente diferente do produto daquela época.

Por que a Anthropic dá tanta importância ao Coding?

Muitas pessoas acreditam que a razão pela qual a Anthropic valoriza a programação é simples — o mercado de programação é grande o suficiente e tem valor comercial suficientemente alto. Mas a explicação dada por Boris é completamente diferente.

Ele disse que, se você parar aleatoriamente um funcionário no escritório da Anthropic e perguntar por que veio aqui, a resposta provável será a mesma: AI Safety.

Para Boris, a missão mais central da Anthropic desde sua fundação sempre foi a segurança da IA. Seja por meio de pesquisas em explicabilidade, alinhamento ou outras diversas direções de segurança, todas buscam compreender o comportamento dos modelos. No entanto, todas essas pesquisas acabam enfrentando o mesmo problema: observar os modelos apenas em laboratório não é suficiente; os pesquisadores também precisam observar o que acontece quando os modelos entram no mundo real.

E Coding é, por acaso, um campo de experimentação quase ideal.

Ao contrário da escrita, pintura ou outras tarefas abertas, a programação possui um mecanismo de feedback extremamente claro. O código pode ou não ser executado, o programa pode ou não passar nos testes, a compilação pode ou não ter sucesso — as respostas geralmente são muito claras. Ao mesmo tempo, a internet fornece uma quantidade massiva de código como dados de treinamento. Em comparação com tarefas como a criação de poesia, que podem ter inúmeras respostas excelentes, o espaço de soluções corretas para problemas de programação é muito mais convergente, tornando mais fácil validar a capacidade do modelo.

Por isso, a Anthropic tem se concentrado fortemente em Coding, Tool Use e Computer Use desde cedo. Essas áreas não apenas possuem valor comercial, mas, mais importante ainda, oferecem um ambiente experimental natural para estudar como os modelos interagem com o mundo real.

Do ponto de vista deste contexto, o Claude Code nunca foi apenas uma ferramenta de produtividade voltada para programadores. Na narrativa de Boris, ele também serve como uma importante plataforma experimental da Anthropic para compreender os futuros sistemas de IA.

Por que o Claude Code ficou repentinamente mais forte?

Após apresentar a origem do Claude Code, o apresentador fez uma pergunta que muitos queriam saber: como, se no início o Claude Code conseguia realizar apenas cerca de 10% a 20% do trabalho de Boris, acabou por acontecer algo tão significativo que, hoje, Boris já declarou publicamente que não escreve código manualmente há seis meses? De realizar apenas uma pequena parte das tarefas a quase assumir totalmente o desenvolvimento, claramente ocorreu uma transformação enorme.

Para essa questão, a resposta de Boris foi surpreendentemente simples. Ele disse que o público geralmente concentra a atenção nas funcionalidades do produto, mas, se ele refletisse sobre os momentos que realmente trouxeram saltos de capacidade, a razão mais importante seria apenas uma: o modelo ficou mais forte.

Ao longo do último ano, a equipe da Anthropic realmente aprimorou continuamente o Claude Code em si. Eles realizaram um grande trabalho de engenharia, adicionando diversas novas formas de interação e formatos de produto. Inicialmente, o Claude Code era apenas uma ferramenta de linha de comando, mas posteriormente expandiu-se para ambientes desktop, móvel, Slack, GitHub e outros cenários. A equipe também experimentou constantemente novas funcionalidades, como modos de planejamento (Plan Mode) e outros mecanismos que ajudam desenvolvedores a colaborar com Agentes. Mas, segundo Boris, todos esses são melhorias incrementais.

O que realmente determina o limite do Claude Code é o modelo subjacente em si.

Ele mencionou vários pontos-chave. Desde o Sonnet 4 e o Opus 4 até o posterior Opus 4.5, cada aumento na capacidade do modelo se reflete diretamente no desempenho do Claude Code.

O apresentador perguntou em seguida se a experiência de uso do Claude Code influenciaria de volta o desenvolvimento do modelo. A resposta de Boris foi que quase todos na Anthropic usam o Claude Code todos os dias, incluindo as pessoas que desenvolvem modelos, as que desenvolvem produtos... toda a empresa o utiliza.

Portanto, não existe um canal de feedback dedicado. O feedback é parte integrante do dia a dia da empresa.

Quando os pesquisadores encontram problemas durante o uso, a equipe de modelos os vê; após o aprimoramento das capacidades do modelo, todos imediatamente sentem as mudanças no trabalho prático. O produto e o modelo não são duas linhas paralelas, mas sim evoluem juntos dentro de um mesmo ciclo.

Quanto aumento de produtividade o Claude Code trouxe para a Anthropic?

Boris disse que, após trabalhar por muito tempo em laboratórios de IA, as pessoas acabam se acostumando a pensar em termos de crescimento exponencial. Muitas métricas internas — seja receita, uso ou capacidade do modelo — parecem mais como curvas exponenciais, portanto, elas até se acostumam a usar escalas logarítmicas para observar as mudanças.

E a produção de código também apresentou uma tendência semelhante.

Com base nos dados anteriormente divulgados pela Anthropic, desde que o Claude Code passou a ser amplamente utilizado internamente, a quantidade de código produzida por cada engenheiro aumentou cerca de três vezes. Mas Boris enfatizou especialmente que esses dados já estão desatualizados. O aumento real é muito superior a esse número.

Mais interessante ainda, esse crescimento ocorreu durante um período de expansão rápida da empresa.

Segundo a experiência tradicional, quanto mais engenheiros uma empresa tiver, menor tende a ser a produtividade média. Novos funcionários precisam aprender o sistema, e os funcionários mais antigos precisam responder perguntas, fazendo com que os custos de comunicação organizacional continuem aumentando.

Mas o que Boris observou foi exatamente o oposto. Anteriormente, um novo engenheiro poderia levar semanas para se familiarizar realmente com os sistemas internos. Agora, esse processo geralmente leva apenas dois dias.

A razão não é uma revolução no sistema de treinamento, mas sim porque todos já estão acostumados a perguntar diretamente ao Claude. Novos funcionários não precisam saber como consultar o banco de dados. Eles nem precisam saber a quem perguntar. Na Anthropic, quando alguém pergunta “como consultar o banco de dados?”, a resposta comum é: “Abra o Claude e peça ao Claude para consultar o banco de dados.” Muitos conhecimentos tácitos anteriormente exigidos de engenheiros sênior começaram a ser transferidos para os Agentes. Para Boris, esse talvez seja a mudança mais importante.

O Claude Code não apenas aumenta a velocidade de geração de código, mas também está gradualmente reduzindo o custo de transmissão de conhecimento dentro das organizações. Anteriormente, as empresas dependiam de cadeias de transmissão de conhecimento para realizar a fluidez de informações. Agora, cada vez mais conhecimento está sendo diretamente encapsulado nos modelos.

Da fita perfurada ao Vibe Coding, a humanidade simplesmente elevou novamente o nível de abstração da programação

Como o Claude Code é tão poderoso, os engenheiros recém-contratados da Anthropic ainda escrevem código? Quando o apresentador fez essa pergunta, o foco da discussão mudou imediatamente para: como você define "escrever código"?

Na visão de Boris, a história do desenvolvimento de software é, essencialmente, uma história de constante elevação dos níveis de abstração.

Seu avô programava usando cartões perfurados na era soviética. Naquela época, os programadores precisavam perfurar buracos em cartões de papel e enviá-los para o computador, aguardando os resultados. Depois, surgiram linguagens de montagem. Mais tarde, apareceram Fortran e COBOL. Em seguida, Java, Python e JavaScript. Cada aumento no nível de abstração era acompanhado por quem dizia: “Isso já não é programação real”. Os que escreviam em linguagem de montagem desdenhavam os que usavam linguagens de alto nível, e os que programavam em C achavam Python muito simples. Mas Boris acredita que o que está acontecendo hoje é essencialmente o mesmo. Os seres humanos simplesmente elevaram novamente o nível de abstração da programação.

Ele descreveu a evolução do seu trabalho ao longo do último ano. No início, ele era como a maioria dos desenvolvedores: abria o IDE, escrevia código e ocasionalmente usava preenchimento automático — um método tradicional de desenvolvimento de software.

Depois que o Claude Code surgiu, seu método de trabalho passou a ser: descrever as necessidades ao Claude, deixar que o Claude escreva o código e assumir a responsabilidade por revisar e corrigir. Nesta fase, o ser humano ainda está diretamente orientando o modelo; apenas o código é gerado pelo modelo. Mas Boris acredita que isso é apenas uma fase transitória.

As mudanças verdadeiramente interessantes ocorreram recentemente. Ele disse: “Agora eu nem mesmo faço prompts diretos ao Claude mais. Seu trabalho se transformou em outra forma. Ele escreve vários fluxos e ciclos que executam automaticamente. Esses ciclos são responsáveis por fazer perguntas ao Claude, decompor tarefas, gerenciar o contexto e coordenar o trabalho entre várias instâncias do Claude.”

Em outras palavras: antes, as pessoas davam instruções ao Claude. Agora, são programas que entregam essas instruções ao Claude em seu nome. E seu trabalho passou a ser projetar esses sistemas automatizados. Ele resume isso com uma frase muito simples: meu trabalho agora é escrever Loops.

Parece que Boris não está apenas terceirizando o código para o Claude, mas também automatizando o próprio processo de comunicação com o Claude. Isso já não é mais o modelo Copilot familiar. É mais próximo de um sistema composto por múltiplos Agentes em execução contínua.

Boris mencionou que, em novembro do ano passado, ele até desinstalou o seu IDE. A razão não foi um gesto simbólico, mas porque percebeu que já havia passado um mês sem abrir o IDE. Como não o utilizava mais, naturalmente o desinstalou. Durante esse período, ele normalmente executava cinco a dez instâncias do Claude simultaneamente, com diferentes instâncias do Claude responsáveis por tarefas distintas, enquanto ele se concentrava principalmente em supervisionar todo o processo.

O engenheiro não escreve mais código, o que olhar na contratação?

Nesse momento, o apresentador fez uma pergunta muito interessante: se um engenheiro quisesse se juntar à Anthropic hoje, como a Anthropic o avaliaria? Ou, dito de outro modo: em um mundo onde cada vez menos pessoas escrevem código manualmente, quais tipos de pessoas as empresas estão procurando?

A resposta de Boris quase levou diretamente à discussão subsequente sobre a forma organizacional. Ele disse que o tipo de pessoa preferido pela equipe do Claude Code é, na verdade: Generalist.

A razão é simples: as antigas organizações de software tinham divisões muito claras — pesquisadores de usuários se concentravam em entender os usuários, designers se ocupavam de projetar o produto, gerentes de produto planejavam as necessidades e engenheiros implementavam as funcionalidades; cada um trabalhava em seu próprio estágio, como em uma linha de produção.

Mas a equipe do Claude Code descobriu nos últimos seis meses que essa divisão de tarefas está se desintegrando rapidamente. Quase todos os engenheiros da equipe realizam diariamente uma variedade de tarefas que originalmente não faziam parte das responsabilidades de um “engenheiro”. Alguns comunicam-se diretamente com os usuários, outros projetam interações, alguns coletam dados, realizam análises e constroem dashboards. Ninguém se limita a uma única etapa estreita.

Boris até citou um exemplo ainda mais extremo: os designers da Anthropic também escrevem código, e colegas do setor financeiro também escrevem código. Satya Nadella chama esse tipo de função de "Builder". Esse termo pode ser mais preciso do que "engenheiro", pois a verdadeira fronteira já não é "você sabe ou não escrever código", mas sim "você consegue ou não transformar uma ideia em realidade".

Do ponto de vista de Boris, a IA não simplesmente substitui programadores; ela realmente transforma a relação entre conhecimento e execução. No passado, uma pessoa não podia desempenhar múltiplos papéis ao mesmo tempo principalmente devido ao alto custo de aprendizado. Agora, os modelos estão reduzindo continuamente o custo de transferência entre essas habilidades. Portanto, as pessoas mais vantajosas no futuro não serão necessariamente os especialistas mais profundos em um único campo, mas sim aqueles capazes de atravessar rapidamente diferentes áreas e integrar constantemente recursos.

É por isso que Boris acredita: estamos entrando numa era dourada para os generalistas. Para aqueles dispostos a fazer muitas coisas, este pode ser o melhor momento da história.

Member of Technical Staff não é um golpe, é uma prévia do futuro

O apresentador mudou o foco do produto para cultura e design organizacional. Ele observou que o título de Boris não é “Diretor de Produto” nem “Diretor de Engenharia”, mas sim Member of Technical Staff, e que muitas pessoas na Anthropic têm esse título. Ele quer saber: quais são os benefícios disso? Existem desvantagens?

Boris foi muito sincero. Ele disse que o pior ponto é: você envia uma mensagem para alguém no Slack cujo título é MTS, e você simplesmente não sabe se essa pessoa é designer, engenheiro ou gerente, nem sabe exatamente em que projeto ela está trabalhando. Mas ele adorava esse título.

Ele lembrou-se da experiência na Meta. Todos os engenheiros de software da Meta tinham apenas um título: Software Engineer, sem níveis como senior ou principal. Inicialmente, ele não compreendia, mas depois percebeu que isso era, na verdade, um design cultural. Se você der a alguém um título de “sênior”, as pessoas terão dificuldade em contestar suas más ideias por deferência. Já colocar todos em um campo aparentemente igualitário força as pessoas a competirem com base nas próprias ideias, e não na experiência.

Claro, ele reconhece que os níveis não desaparecem realmente apenas porque o título não está mais presente. Você sabe que alguém é L7, apenas sem o título escrito. Mas é interessante que, muitas vezes, você realmente não sabe.

Ele contou uma história sobre quando trabalhava como engenheiro L4 no Facebook. Ele teve uma ideia, foi diretamente até o VP responsável por conectividade e disse: “Essa é minha ideia, vamos fazer isso juntos.” Esse VP nem sabia qual era o nível dele. Ele foi até outro VP e falhou novamente. Na terceira tentativa, deu certo. Eles formaram uma equipe e começaram a desenvolver o produto.

Boris disse que, agora, na equipe do Claude Code, ele vê a mesma coisa todos os dias. Engenheiros sênior com 20 ou 30 anos de experiência precisam passar meses desaprendendo — abandonar hábitos antigos que já não são mais aplicáveis. Já um recém-formado universitário que se junta à equipe consegue ensiná-lo a usar melhor o Claude Code, porque os jovens naturalmente pensam em termos de modelos.

Com cada novo modelo lançado, todos precisam recalibrar. A experiência nesta era não é acumulada linearmente; às vezes, é até uma dívida.

Então, o título aparentemente vago de Member of Technical Staff, para Boris, é uma prévia de uma realidade iminente: até o final do ano, as fronteiras entre engenheiros, PMs, designers e pesquisadores de usuários praticamente desaparecerão. Em vez de aceitar passivamente essa mudança, ele propõe usar o título para ativamente reunir todos sob o mesmo papel: Builder.

Sugestão para todos os fundadores: contrate menos pessoas e emita mais tokens

O apresentador pede a Boris que, da perspectiva da Anthropic, dê uma recomendação mais geral aos fundadores e empresas presentes: como as organizações devem ajustar sua mentalidade até o final de 2026?

A primeira frase de Boris já traz um toque de humor: “Dê a todos o máximo possível de tokens.” Assim como a famosa frase de Jensen Huang: “Quanto mais você compra, mais economiza.”

Isso não é uma brincadeira. Ele está sério. As sugestões específicas que ele deu são duas coisas:

Primeiro, forneça o máximo possível de tokens para que todos possam experimentar intensamente.

Em segundo lugar, cada projeto intencionalmente "contrata menos pessoas". Se você acha que um projeto precisa de quatro engenheiros, coloque apenas dois e dê a eles muitos tokens, permitindo que eles encontrem soluções por conta própria. Você descobrirá que, com grande probabilidade, eles realmente conseguirão. Eles automatizarão tudo o que for possível, e, como isso será automatizado, a próxima vez será mais rápida e mais barata. Esse é um efeito de juros compostos.

O apresentador resumiu muito bem a sugestão: use menos pessoas e transfira o orçamento dos salários para tokens. Isso aumentará seu custo inicial, mas reduzirá drasticamente o custo contínuo. É como precompilar — você faz todo o trabalho árduo de uma vez, e cada execução subsequente é quase gratuita.

Boris concordou plenamente. O apresentador fez então uma pergunta mais incisiva: no passado, as pessoas se orgulhavam muito de sua disciplina (área de especialização). Os PMs se orgulhavam de seus artigos de produto, os designers se orgulhavam de seus portfólios elegantes. Será que, em 12 meses, todos terão de abandonar essa identidade de “sou alguém” e se tornar um “saco flexível que consome tokens”?

Boris disse: "Provavelmente usaria uma formulação ligeiramente diferente, mas... sim, é mais ou menos isso."

O gosto também será corroído pelo modelo? O que sobrará no final é apenas "valores".

O apresentador mencionou um tópico discutido anteriormente com outro membro da Anthropic, Jared, e gostaria de ouvir a opinião de Boris: como vocês entendem o “taste” (gosto)?

A resposta de Boris foi muito sincera. Ele disse que toda vez que sentiu ter algum "gosto especial" em programar, acabou se provando errado.

Ele costumava adorar programação funcional, linguagens como Haskell e Scala. No repositório inicial do Claude Code, ele estabeleceu uma regra: não usar class, apenas function. Os engenheiros enviavam secretamente código com class aos fins de semana, e ele o rejeitava às segundas-feiras. Depois, quando o modelo começou a escrever código em grande escala, ele escrevia diretamente class. Ele olhou por muito tempo e, finalmente, disse: “Tudo bem, talvez o modelo esteja certo. Talvez minha obsessão não tenha sentido algum. O resultado de negócios foi alcançado, e mais rápido, e o código não é ruim.”

Então ele fez uma inferência ainda mais ousada. Agora todo mundo diz: "o senso de produto é o último alpha". Mas ele acredita que esse alpha também está desaparecendo rapidamente.

Ele já tem centenas de instâncias do Claude rodando simultaneamente. Algumas estão analisando feedbacks no Twitter, outras estão revisando issues no GitHub, algumas estão monitorando o Slack, e todas estão analisando automaticamente quais funcionalidades devem ser implementadas na próxima fase. Atualmente, a maioria das ideias ainda é ruim — cerca de 20% são boas. Mas, com o próximo modelo, dentro de 3 a 6 meses — a maioria das ideias provavelmente será boa.

O apresentador perguntou novamente: Então, o que ainda é único para os seres humanos? Existe algo que o modelo nunca conseguirá fazer?

Boris pensou um pouco e disse: valores.

Ele disse que, no final, o que queremos ensinar ao modelo é a mesma coisa que ensinamos às crianças: como ser um bom ser. Como fazer o que é certo, e não apenas fazer as coisas corretamente.