Vamos organizar a história do nascimento do Claude Code, que se baseia principalmente em um artigo do blogueiro de tecnologia Gergely Orosz, que entrevistou membros centrais do Claude Code. O Claude Code é realmente impressionante, com uma receita anualizada de 500 milhões de dólares, e em três meses o número de usuários aumentou 10 vezes, agora é também a ferramenta de Coding Agent preferida de muitos programadores. Esta ferramenta era inicialmente apenas um pequeno brinquedo de linha de comando que podia te dizer "o que você está ouvindo agora". 🧵

Gergely Orosz entrevistou três membros centrais da Claude Code: • O engenheiro fundador Boris Cherny (17 anos de experiência, ex-engenheiro chefe da Meta) • O engenheiro número dois Sid Bidasaria (autor da funcionalidade Subagents) • E a gerente de produto Cat Wu. Eles conversaram sobre como a Claude Code passou de protótipo a produto, quais escolhas técnicas foram feitas e como essa pequena equipe de pouco mais de dez pessoas consegue publicar 5 PRs por dia por membro. Este pode ser o exemplo mais próximo de uma "equipe de engenharia com foco em IA" atualmente. Eles usam IA para escrever código, escrever testes, fazer revisões de código, depurar falhas, e até usam a Claude Code para desenvolver a própria Claude Code. 90% do código é escrito por ela mesma. O que eu quero fazer é organizar as partes mais interessantes desta entrevista, falar sobre como essa equipe trabalha, o que pode ser aprendido e o que é determinado por suas condições especiais e não pode ser replicado. Abaixo, dividi em 7 pequenas histórias, cada uma podendo ser lida de forma independente, mas juntas formam um quadro completo.

【1】Uma pequena ferramenta para ouvir música, como se tornou um produto que gera 500 milhões de dólares por ano Em setembro de 2024, Boris Cherny acabou de se juntar à Anthropic e, sem nada para fazer, escreveu um pequeno brinquedo de linha de comando. Para que serve isso? Ele pode usar AppleScript para te dizer qual música está tocando agora e também pode trocar de música de acordo com suas instruções. É tão simples assim. A própria avaliação de Boris é: “Um demo bem legal, mas sem muita importância.”

A verdadeira reviravolta aconteceu depois de ele conversar com a colega Cat Wu. Naquele momento, Cat estava estudando a capacidade de uso de computadores por Agentes de IA, e enquanto conversavam, Boris teve uma ideia: e se desse mais permissões a essa ferramenta de linha de comando? Por exemplo, permitir que ela pudesse ler e escrever arquivos, e executar comandos?

Ele tentou. Então, o momento de testemunhar o milagre chegou. Boris jogou essa ferramenta aprimorada no repositório de código da Anthropic e fez algumas perguntas aleatórias. Claude começou a explorar o sistema de arquivos por conta própria — leu um arquivo, viu as instruções de importação dentro dele e seguiu para ler os arquivos referenciados, cavando camada por camada até encontrar a resposta. "Isso me deixou chocado," Boris lembrou, "eu nunca usei uma ferramenta assim."

No campo da IA, há um conceito chamado "product overhang", que se traduz como "excesso de produto". Isso significa que o modelo já possui certa capacidade, mas a forma atual do produto não liberou essa capacidade. O que Boris descobriu é um enorme "excesso de produto"; o Claude já conseguia fazer isso há muito tempo, mas ninguém lhe construiu uma casca.

Boris começou a trabalhar todos os dias com esta ferramenta e depois a compartilhou com alguns colegas. Dois meses depois, em novembro, lançaram uma versão interna. Os dados são impressionantes: no primeiro dia, 20% dos engenheiros estavam a usar; no quinto dia, 50%.

Neste momento, surgiu um debate interessante: devemos ou não publicar externamente? Os argumentos contra são bastante reais: se esta coisa realmente for tão poderosa quanto pensamos, não seria melhor mantê-la como uma "arma secreta"? Por que entregar a vantagem competitiva de mão beijada? No final, a Anthropic decidiu publicar. A lógica é a seguinte: a missão central da Anthropic é pesquisar a segurança dos modelos, e a melhor maneira de estudar a segurança é permitir que as pessoas realmente utilizem essas ferramentas. Uma vez que foi verificado internamente que o Claude Code seria amplamente utilizado, publicá-lo pode trazer mais insights sobre as capacidades e a segurança do modelo.

Em maio de 2025, o Claude Code foi oficialmente lançado. Três meses depois, o uso aumentou 10 vezes, com uma receita anual superior a 500 milhões de dólares. Curiosamente, Boris inicialmente pensou que era apenas para programadores — por isso o nome "Claude Code". Mas um dia, ao passar pela mesa de um cientista de dados, viu que o Claude Code também estava sendo executado na tela dele. "Para que você está usando isso?" "Estou deixando ele me ajudar a escrever consultas e fazer visualizações." Agora, os cientistas de dados da Anthropic têm um para cada um, e alguns estão usando vários ao mesmo tempo. Uma pequena ferramenta para ouvir música, que, ao receber algumas permissões adicionais, se transformou em um produto avaliado em centenas de milhões de dólares. Isso é provavelmente a melhor prova de "product overhang", onde a capacidade do modelo sempre esteve lá, apenas esperando que alguém a liberasse.

【2】90% do código é escrito por eles mesmos — A filosofia de escolha tecnológica do Claude Code O Claude Code tem 90% do código escrito por ele mesmo. Parece uma jogada de marketing, mas isso se deve à lógica de decisão técnica deles. Vamos primeiro olhar para a pilha tecnológica: TypeScript para o núcleo, React com o framework Ink para a interface de terminal, Yoga da Meta como sistema de layout, e Bun para construção e empacotamento. Por que escolher essas pilhas tecnológicas? Porque elas estão "dentro da distribuição". "Dentro da distribuição" (on distribution) é um termo do campo da IA. Significa que o modelo já viu uma grande quantidade desse tipo de código e é bom em lidar com ele. TypeScript e React são exatamente os pontos fortes do Claude. Se escolher um framework menos conhecido, o modelo terá que "aprender", e o desempenho será comprometido. Essa escolha cria um ciclo maravilhoso: usar a pilha tecnológica que o Claude domina para escrever o Claude Code, e então usar o Claude Code para escrever mais Claude Code. 90% escrito por si mesmo, é assim que funciona. As escolhas deles em termos de arquitetura também são simples. O Claude Code roda localmente. Sem contêineres Docker, sem sandbox na nuvem, é direto no seu computador, lendo e escrevendo arquivos, executando comandos.

Quanto à razão pela qual foi projetado assim? A resposta de Boris é: "Sempre que tomamos decisões de design, quase sempre escolhemos a solução mais simples. Executar localmente é a resposta mais simples." Essa simplicidade se estende a toda a filosofia do produto: escrever o mínimo possível de lógica de negócios, deixando o modelo ser o protagonista. "Isso pode parecer um pouco estranho," diz Boris, "mas queremos que os usuários possam sentir o modelo o mais "puro" possível. Muitos produtos de IA adicionam uma série de estruturas - elementos de UI extras, várias funcionalidades auxiliares - e o resultado acaba limitando a performance do modelo. O que queremos fazer é manter a UI o mais enxuta possível." Para manter a simplicidade, cada vez que Claude lança um novo modelo, eles simplificam muito o código. Por exemplo, quando o Claude 4.0 foi lançado, eles removeram cerca de metade das instruções do sistema, pois o novo modelo não precisava mais dessas "muletas". O número de ferramentas também está sendo constantemente reduzido - o que pode ser removido, é removido; o que pode ser combinado, é combinado. Toda a arquitetura do Claude Code pode ser resumida em três coisas: definir a UI e expor a interface para modificação pelo modelo, expor ferramentas para que o modelo as chame, e então sair do caminho. Claro, simplicidade não significa ausência de partes complexas. O sistema de permissões é uma exceção. Afinal, permitir que a IA execute comandos no seu computador é arriscado. A solução do Claude Code é perguntar antes de executar: você quer aprovar esta operação? Você pode aprovar apenas esta vez, ou aprovar para o futuro, ou recusar. O sistema de permissões suporta configurações em múltiplas camadas - por projeto, por usuário, por empresa. As equipes podem compartilhar arquivos de configuração, adicionando comandos de segurança comuns à lista branca. O princípio por trás desse design de permissões é o seguinte: se você iniciar o Claude Code, ele não deve alterar nada sem o seu consentimento. Mas, ao mesmo tempo, deve dar ao usuário a opção de "delegar" - em cenários de confiança, você pode pular a etapa de confirmação. Simples, mas não rudimentar. Contido, mas não sem funcionalidades.

【3】Vinte protótipos em dois dias — Como é a iteração de produtos na era da IA Antes, ao fazer protótipos de produtos, conseguir fazer dois em dois dias já era considerado uma alta eficiência. Boris fez 20 em dois dias. Isso não é exagero, é um registro real de quando ele desenvolveu a funcionalidade de lista de tarefas do Claude Code. Ele até compartilhou as dicas e capturas de tela de cada passo. Vamos ver como esses 20 protótipos foram iterados. Na primeira versão, ele queria que a lista de tarefas aparecesse abaixo da última chamada de ferramenta. A dica era bem curta: “Faça com que a lista de tarefas não apareça conforme a entrada, mas que exiba uma lista fixa de tarefas acima da caixa de entrada, com o título em cinza '/todo (1 de 3)'”. Depois de ver o resultado, não ficou muito satisfeito. Na segunda versão, mudou para exibir inline a cada atualização da tarefa. A dica: “Na verdade, não exiba a lista de tarefas, mude para que, quando o modelo começar a processar uma tarefa, o nome da ferramenta seja renderizado como um título em negrito. Mantenha a exibição de progresso como 'passo 2 de 4'.” Ainda não estava certo. Na terceira e quarta versões, ele tentou fazer uma “pílula interativa” — um pequeno quadrado na parte inferior da tela que, ao ser clicado, mostrava o progresso. “Adicione uma pílula de tarefas abaixo da caixa de entrada, semelhante ao estilo de tarefas em segundo plano, exibindo 'todos: 1 de 3'.” Depois: “Faça essa pílula ser interativa, como a pílula de tarefas em segundo plano.” Começou a ficar interessante, mas ainda não era bom o suficiente. Na quinta e sexta versões, ele mudou de abordagem: fez um “gaveta” que desliza da direita. “Remova a pílula anterior e o título, mude para exibir a lista de tarefas à direita da caixa de entrada, centralizada verticalmente, separada por uma linha cinza.” “Está um pouco abrupto, não dá para fazer uma animação de gaveta?” Parece legal, mas a utilidade é duvidosa. Da sétima à nona versão, ele moveu a lista de tarefas para cima da caixa de entrada, experimentando diferentes formas de truncamento e estilos de título. “Se houver mais de 5, exiba '... e 4 mais'”, “Adicione um título cinza 'Todo:'”. Estava cada vez mais perto da resposta. Da décima à vigésima versão, ele começou a pensar em como combinar a lista de tarefas com a animação de carregamento. A solução final foi colocar as informações de progresso ao lado do spinner (indicador de carregamento), maximizando a visibilidade. Após o lançamento, os usuários deram feedback dizendo que queriam ver a lista completa de tarefas. Então, foi adicionada mais uma iteração: pressionar Ctrl+T para expandir todos os passos. Esta é a versão que está online agora.

Durante todo o processo, as sugestões de Boris eram surpreendentemente curtas — a maioria consistia em uma ou duas frases. Mas cada versão era um protótipo funcional, não uma imagem estática, não um PPT. Ele podia realmente testar e validar essa funcionalidade, sentindo se era fácil de usar ou não. O processo tradicional de desenvolvimento de produtos é: ideia → discussão → criação de wireframes → design de alta fidelidade → desenvolvimento → teste → lançamento. Cada etapa leva tempo, e cada etapa pode travar o progresso. Agora, o processo se transformou em: ideia → uma frase de sugestão → protótipo funcional → se não estiver certo, faça outra versão. Isso realmente exige que os desenvolvedores mudem sua forma de pensar para se adaptarem a esse novo fluxo de desenvolvimento. Antes, a função do protótipo era "validar a ideia" — porque fazer um protótipo é caro, você precisa pensar bem antes de começar. Agora, o protótipo se tornou "explorar possibilidades" — porque o custo de fazer um protótipo é baixo, você pode fazer primeiro e depois decidir, se não estiver bom, é só descartar. Boris disse que, ao usar o Claude Code, ele frequentemente pula a fase de criação de design e vai direto para fazer uma versão que funcione, o que é mais intuitivo do que qualquer outra coisa. O ritmo diário da equipe do Claude Code é: cada engenheiro envia cerca de 5 PRs por dia, publicando internamente de 60 a 100 versões diariamente e externamente 1 versão por dia. Cinco PRs por dia é algo inimaginável na maioria das empresas. Na época mais intensa de reestruturação da Uber, conseguir enviar um PR de médio porte em um dia já era considerado bom. As ferramentas mudaram, o ritmo mudou, e a forma de pensar também precisa mudar.

【4】Redesign do terminal de linha de comando integrado com AI O terminal de linha de comando existe há décadas, por que agora precisa ser redesenhado? Porque antes do surgimento dos LLM, o terminal não se preocupava muito com a experiência de interação. O terminal tradicional é uma pergunta e uma resposta: você insere um comando, ele retorna um resultado, e acabou. Não há diálogo, não há contexto, não há feedback enquanto espera. Você fica olhando para o cursor piscando, sem saber o que está acontecendo nos bastidores. Claude Code é um dos primeiros produtos que realmente precisa pensar na "UX do terminal". Eles adicionaram alguns pequenos detalhes que podem parecer insignificantes, mas a experiência de uso é completamente diferente. Primeiro: dicas de carregamento de contexto. Quando o modelo está pensando, a tela pode exibir dicas relacionadas à tarefa atual: por exemplo, "lendo sua estrutura de código" ou "pensando em uma solução". É um toque muito pequeno, mas dá uma "personalidade" à ferramenta. Você sente que ela está trabalhando seriamente, e não travada. Boris disse que a última vez que viu uma interação tão agradável foi no processo de orientação para novos usuários do Slack. Segundo: dicas de ensino enquanto espera. Quando Claude está executando uma tarefa longa, a parte inferior da tela exibe dicas de uso, como "você pode pressionar Esc para interromper a tarefa atual" ou "tente /help para ver todos os comandos". O terminal ensina a usar o terminal, simples e inteligente. A terceira história é ainda mais interessante: renderizador de Markdown. Um dia antes do lançamento, um engenheiro reclamou que as listas aninhadas estavam feias e o espaçamento entre parágrafos estava errado. O problema estava no renderizador de Markdown. Boris testou todos os renderizadores prontos disponíveis no mercado, e nenhum deles era bonito no terminal. Então, ele usou o Claude Code e passou um dia escrevendo do zero um parser e renderizador de Markdown. Sim, um dia antes do lançamento. Sim, do zero. Sim, usando o próprio Claude Code. O resultado é que esse renderizador "apressado" ficou mais bonito do que todas as soluções prontas. Eles lançaram diretamente. Boris acredita que atualmente não há nenhum outro terminal com a mesma qualidade de renderização de Markdown. Essa história ilustra uma coisa: quando você tem uma ferramenta de programação AI suficientemente boa, o custo de "fazer suas próprias rodas" diminui drasticamente. O compromisso anterior de "serve" agora pode se transformar em "então vamos fazer um melhor". A antiga interface do terminal de linha de comando está renascendo devido à adição dos LLM. O terminal ainda é o mesmo terminal, mas agora, com a adição da AI, precisamos pensar seriamente: como fazer com que as pessoas e a AI no terminal se comuniquem melhor.

【5】A IA penetra em cada etapa - um experimento de "totalização da IA" de uma equipe de engenharia A equipe de engenharia da Anthropic pode ser uma das que mais utiliza ferramentas de IA atualmente. Não se limita apenas à escrita de código, mas abrange todas as etapas do projeto. Revisão de código: a primeira revisão de todos os PRs é feita pelo Claude Code, e o engenheiro faz a segunda. Boris diz que o Claude Code consegue identificar muitos problemas na primeira revisão. Essa funcionalidade era originalmente usada apenas internamente, mas depois eles a tornaram pública, e todos podem usar o Claude Code para revisões de segurança. Escrita de testes: a suíte de testes do Claude Code é quase toda escrita pelo Claude Code. Boris diz: "Antes, se alguém apresentasse um PR sem escrever testes, eu hesitava em dizer algo - parecia que eu estava sendo muito crítico. Mas agora, com o Claude, escrever testes é apenas uma questão de dar um comando, não há desculpa para não escrever." Resposta a incidentes: o engenheiro de plantão pede ao Claude Code para ajudar a analisar a Causa Raiz (a razão mais fundamental do problema). Ele consegue puxar discussões relevantes do Slack, puxar logs de erros do Sentry, puxar dados de vários sistemas de monitoramento e, em seguida, fazer uma análise abrangente. Boris diz que o Claude Code encontra a Causa Raiz mais rápido que as pessoas em certos cenários. Desvio de issues do GitHub: sempre que uma nova issue chega, o Claude Code faz uma análise primeiro, e então o engenheiro pergunta a ele "pode implementar isso?". Boris diz que, em cerca de 20%-40% das vezes, ele consegue resolver na primeira tentativa. Gráficos e consultas: os dados do produto estão no BigQuery, e quase todas as consultas e visualizações são geradas pelo Claude Code. Os engenheiros até pedem que ele produza gráficos ASCII diretamente.

O que mais me surpreendeu foi o renascimento do TDD (Desenvolvimento Orientado a Testes). TDD é um conceito antigo: primeiro escreva os testes, depois escreva o código que faz os testes passarem. Em teoria, é muito bonito — força você a pensar claramente sobre o que precisa. Mas na prática, a maioria das pessoas acha que é muito lento e complicado, então esse método foi lentamente marginalizado nos últimos dez anos. Mas Boris disse que, após usar o Claude Code, ele fez uma quantidade enorme de TDD: "Eu primeiro deixo o modelo escrever um teste, enquanto digo a ele que esse teste vai falhar agora, não tente fazê-lo passar. Depois eu deixo ele escrever o código para implementar a funcionalidade e fazer o teste passar, mas não posso mudar o teste em si." "Quando o modelo tem um objetivo claro para iterar — como um teste unitário ou um mock — ele se sai muito bem." Ele mencionou especialmente que o Claude 4.0 é a primeira série de modelos que permite que o modelo escreva a maior parte dos testes. As versões anteriores podiam escrever uma parte, mas precisavam de muita intervenção manual. Há também um novo conceito: multi-clauding. Isso significa executar várias instâncias do Claude Code ao mesmo tempo, permitindo que elas processem diferentes tarefas em paralelo. Sid disse que ele faz isso com frequência — inicia vários agentes durante as reuniões e depois volta para ver os resultados. A Anthropic descobriu que 25% dos usuários do Max (usuários premium que pagam mensalmente entre 100 e 200 dólares) estão usando multi-clauding diariamente. Essa é uma mudança muito interessante. A programação sempre foi uma atividade "de thread única": você só pode fazer uma coisa de cada vez, só mudando de tarefa quando está revisando o código ou fazendo o deploy. Mas agora, a "programação paralela" se tornou possível — você pode avançar em várias coisas ao mesmo tempo. Claro, há muitas incógnitas: trabalhar em paralelo é realmente mais eficiente ou apenas parece mais eficiente? Que tipo de tarefas são adequadas para o trabalho paralelo? A atenção de cada agente diminuindo, isso pode causar problemas? Essas perguntas ainda não têm resposta. Mas temos uma nova ferramenta para experimentar. Por fim, um caso. Uma empresa precisava fazer uma migração de framework, originalmente estimando que levaria dois anos de engenharia — um engenheiro trabalhando por dois anos, ou dez engenheiros trabalhando por dois meses e meio. Eles usaram o Claude Code e um engenheiro resolveu em duas semanas. Boris disse que antes ele seria cético em relação a esse tipo de afirmação, mas histórias semelhantes eles ouviram muitas vezes.

【6】Três dias de hackathon — Como a funcionalidade Subagents foi criada A funcionalidade Subagents foi inspirada em uma postagem no Reddit. Alguém disse que estava executando cinco instâncias do Claude Code ao mesmo tempo, definindo diferentes papéis para cada instância e, em seguida, usando um sistema de arquivos para permitir que se comunicassem entre si. Quando Sid Bidasaria viu essa postagem, sua primeira reação foi: essa abordagem é muito legal, mas os usuários não deveriam precisar passar por tanto trabalho. Devemos transformar isso em uma funcionalidade integrada ao produto. Coincidentemente, a empresa estava realizando um hackathon interno de três dias, e Sid decidiu usar esses três dias para trabalhar nisso. No primeiro dia, a equipe animadamente esboçou várias estruturas complexas de agentes: comunicação entre agentes usando barramento de mensagens, modos assíncronos, interações de muitos para muitos... O desenho ficou muito bonito, e o conceito era avançado. No segundo dia, eles perceberam que isso parecia inviável. O problema não era a implementação técnica — aqueles padrões complexos poderiam ser realizados. O problema era que os usuários não conseguiriam entender. A interface do usuário do Claude Code é um terminal simples; como você faria para que os usuários compreendessem aqueles complexos padrões de comunicação entre agentes em uma interface tão simples? Decidiram recomeçar e voltar a uma questão fundamental: qual é a forma mais simples que um desenvolvedor comum pode usar? Eles se impuseram duas restrições: Primeiro, não inventar nada novo. Usar apenas as capacidades já existentes do Claude Code — comandos “/” e arquivos .md. Segundo, não fazer comunicação entre agentes. Mudar para um modo de orquestração simples: ter um agente principal que pode chamar subagentes, e os subagentes retornam resultados após completarem suas tarefas, e só isso. Eles também conversaram com a equipe de pesquisa da Anthropic. Os pesquisadores estavam estudando o modo de múltiplos agentes, mas a conclusão era: a eficácia de topologias complexas de agentes ainda não está definida. Isso lhes deu mais confiança: já que até a equipe de pesquisa disse que o complexo não é necessariamente bom, então deveriam fazer uma versão simples. Ao final do terceiro dia, eles criaram uma versão utilizável. Os usuários podem definir os papéis e capacidades dos subagentes em arquivos .md (por exemplo, "subagente de front-end: usando React 19 e Next.js"), e o Claude Code os chamará no momento apropriado, ou os usuários podem acioná-los manualmente. Após o hackathon, fizeram alguns ajustes e a funcionalidade foi lançada. Agora você pode definir vários subagentes especializados: um agente de back-end com especialização em auditoria de segurança, um agente de front-end familiarizado com frameworks específicos, um agente de QA especializado em escrever testes... Eles podem trabalhar em paralelo nos bastidores, cada um cumprindo seu papel. Muitas equipes em hackathons hesitam em descartar suas soluções complexas, afinal, passaram um dia inteiro desenhando e discutindo, e criaram um apego. Reconhecer que "esse caminho não funciona" e recomeçar do zero requer coragem e uma crença na "simplicidade". Simplicidade não é preguiça. Simplicidade é encontrar a forma que o usuário realmente pode usar entre inúmeras possibilidades.

【7】Como será a equipe de engenharia do futuro? Algumas coisas que podem ser inspiradoras e outras que não podem ser copiadas. Boris disse: "Programar agora é muito interessante. A última vez que tive essa sensação foi no ensino médio, quando escrevi código pela primeira vez em uma calculadora gráfica. Aquela sensação mágica, eu não a experimentei há muito tempo, mas agora voltou." Sid tem sentimentos semelhantes: "Duas coisas me empolgam. A primeira é a velocidade com que lançamos — às vezes parece até rápido demais. A segunda é o tanto de espaço para experimentação — trabalhos anteriores, embora rápidos, eram mais rotineiros, sabíamos qual era a resposta, era apenas executar. Agora é diferente, o modelo muda a cada três meses, temos que repensar constantemente como fazer as coisas." Esses sentimentos são muito reais e contagiosos. Mas antes de discutir "como será a equipe de engenharia do futuro", não devemos esquecer a singularidade da Anthropic. Primeiro, a Anthropic é um laboratório de pesquisa, não uma empresa de produtos. Sua missão central é pesquisar a segurança e a capacidade da IA, e os produtos são um meio, não um fim. Isso significa que eles têm uma tolerância muito maior para "experimentos rápidos" do que a maioria das empresas. Segundo, seu principal produto é o próprio modelo Claude. O Claude Code é apenas uma "casca" do modelo. Portanto, "remover código para que o modelo faça mais coisas" é uma escolha natural para eles, mas para outras empresas pode significar entregar a lógica central de negócios a uma caixa-preta. Terceiro, todos os funcionários têm acesso ilimitado ao Claude, incluindo o modelo Opus, que é o mais caro. Na maioria das empresas, a taxa de assinatura de IA é um item orçamentário que precisa ser conquistado, não é possível que todos tenham acesso livre. Quarto, a equipe tem apenas algumas pessoas, com um processo extremamente simplificado. Eles quase não usam feature flags (interruptores de funcionalidade), porque "é muito lento". Isso é impensável em produtos com uma grande base de usuários e altos custos de erro. Portanto, copiar diretamente as práticas da equipe do Claude Code pode não ser realista para a maioria das equipes. Mas algumas coisas podem ser inspiradoras. A mentalidade de prototipagem rápida: mesmo que você não consiga fazer 10 protótipos por dia, pode mudar de "um a cada duas semanas" para "três por semana"? As ferramentas mudaram, e as expectativas sobre "quão rápido os protótipos devem ser" também devem ser atualizadas. Revisão de código assistida por IA: deixe a IA fazer a primeira revisão, e uma pessoa faz a segunda. Esse processo não depende de acesso ilimitado à API, a maioria das equipes pode tentar. O renascimento do TDD: se escrever testes se tornar fácil o suficiente, então "não ter tempo para escrever testes" não será mais uma desculpa. Isso pode ser um ponto de entrada de baixo custo para melhorar a qualidade do código. A ampliação do valor de engenheiros com mentalidade de produto: a equipe do Claude Code não tem designers, nem PMs, apenas alguns engenheiros com sensibilidade para produtos. As ferramentas de IA ampliaram significativamente o que esses "talentos full-stack" podem fazer.

Claro, há coisas que as ferramentas não podem substituir. Boris consegue escolher o melhor protótipo entre 20 porque ele tem discernimento — ele sabe o que "parece certo" e o que é apenas "aparentemente utilizável". Esse gosto é o resultado de 17 anos de experiência em desenvolvimento de software, não algo que a AI pode fornecer. A equipe fez um plano complexo no primeiro dia e no segundo dia teve a coragem de recomeçar, essa capacidade de decisão também é um julgamento humano. Saber quando deve-se apagar código e quando deve-se mantê-lo, essa intuição arquitetônica é igualmente assim. A AI acelerou a execução, mas não tornou mais fácil saber "o que fazer". Pelo contrário, devido à redução dos custos de execução, a decisão sobre "o que fazer" tornou-se mais importante — você pode rapidamente criar 20 versões, mas precisa saber qual é a correta. Como será a engenharia de software daqui a alguns anos? Ninguém pode prever com precisão. Mas o que a equipe Claude Code faz hoje pode ser um tipo de ensaio para muitas equipes amanhã — iterações mais rápidas, menos "trabalho braçal", mais julgamento e decisão. As ferramentas estão mudando. O que não muda é que, no final, quem toma as decisões ainda é o ser humano.