O fundador do Claude Code, Boris Cherny, compartilha 7 julgamentos-chave sobre IA na conferência da Sequoia

Organizado: A Ying

Boris Cherny, fundador do Claude Code, compartilhou na conferência Sequoia, e o conteúdo foi muito abrangente — muitas ideias que ouvi pela primeira vez de forma completa. Esse cara realmente entende bem de IA.

Compartilho minha própria síntese.

Para grandes cenários de desenvolvimento mainstream, escrever código manualmente já está se tornando algo ineficiente.

Antes, para entregar um recurso, os engenheiros sentavam-se, pensavam cuidadosamente sobre como implementá-lo e depois digitavam o código linha por linha. Nesse processo, o maior valor do engenheiro era: saber ou não escrever, escrever bem ou mal, escrever rápido ou devagar.

The way things work now is different.

Para a mesma função, o que os engenheiros fazem é mais como: primeiro esclarecer os requisitos, dividir a tarefa em partes e atribuí-las ao Agente, definir um critério de aceitação e, em seguida, verificar se o resultado gerado pelo Agente está correto; se não estiver, ajustar o prompt e fazer com que ele execute novamente.

A IA já consegue lidar com a maioria das tarefas de codificação. Claro, não é 100%, ainda existem grandes e complexos repositórios de código, linguagens pouco comuns ou ambientes especiais nos quais os modelos atuais ainda não se saem bem.

Em termos gerais, o valor do engenheiro passou de saber ou não escrever código para saber ou não dividir tarefas, explicar claramente os objetivos, validar os resultados e gerenciar Agentes.

Essa mudança é na verdade muito semelhante à Revolução Industrial.

Antes da Revolução Industrial, um ferreiro fazia sozinho todo o processo: forjar, forjar, polir e montar. Ferreiros habilidosos naturalmente tinham mais valor.

Depois, a linha de produção apareceu. Cada trabalhador era responsável por apenas uma etapa, mas a produção total era dezenas ou centenas de vezes maior do que na era artesanal.

Neste momento, o papel mais valioso na fábrica não é mais o artesão que executa melhor um único processo, mas sim quem consegue projetar, gerenciar e fazer com que a linha de produção funcione perfeitamente.

Os trabalhadores não desapareceram, mas o papel dos trabalhadores mudou.

A engenharia de software está passando por uma virada semelhante agora. O próprio código não é mais escasso. Saber escrever código está se tornando uma habilidade básica, como saber usar o PowerPoint.

O que realmente é escasso é a capacidade de transformar necessidades vagas em tarefas claras, a capacidade de escolher a melhor opção entre as várias soluções apresentadas pelo Agente e a capacidade de fazer com que um grupo de IA trabalhe em conjunto para concluir uma tarefa.

Na verdade, muitos engenheiros experientes inicialmente não conseguem aceitar isso. O ato de escrever o código manualmente é, por si só, a razão pela qual muitas pessoas amaram esta profissão nas últimas décadas.

Entregar isso a uma máquina, para muitas pessoas, não é apenas uma mudança na forma de trabalhar, mas uma redefinição da identidade.

Mas a tendência é tendência.

A programação está se transformando de uma habilidade profissional em uma competência básica. Isso pode ser comparado à imprensa na Europa do século XV.

Antes da invenção da imprensa, apenas cerca de 10% da população europeia sabia ler e escrever. Essas pessoas geralmente eram empregadas por nobres analfabetos, encarregadas de ler e escrever em seu nome.

Então surgiu a imprensa. Em 50 anos, o número de livros publicados na Europa superou a soma dos mil anos anteriores, e os preços dos livros caíram cerca de 100 vezes. Apenas após centenas de anos de adaptação (sistemas educacionais e estruturas econômicas gradualmente se alinhando), a taxa global de alfabetização atingiu os 70% atuais.

Boris acredita que a influência da IA no software é uma versão acelerada da revolução da imprensa. O software será completamente democratizado em poucas décadas, tornando-se algo que qualquer pessoa poderá dominar.

No final, fazer software será tão natural quanto enviar uma mensagem de texto.

Quando o limite para escrever código for reduzido pelo AI a um nível extremamente baixo, o que realmente distingue a capacidade de uma pessoa é seu senso de produto e sua compreensão real de um domínio específico.

Por exemplo, duas pessoas estão desenvolvendo simultaneamente um produto voltado para médicos. Uma é um engenheiro que codifica rapidamente, e a outra já trabalhou por vários anos no setor de informações hospitalares.

No passado, o engenheiro tinha maior probabilidade de criar algo, pois conseguia implementar a ideia.

Agora é o contrário. Qualquer um pode colocar a ideia em prática. Nesse momento, a pessoa que realmente entende o fluxo de trabalho diário do hospital se torna mais valiosa. Porque ele sabe quais funcionalidades os médicos realmente usarão e quais apenas parecem sensatas.

Ou seja, após a IA nivelar a barreira de execução, a diferença no julgamento é amplificada.

This event directly rewrote the meaning of the word generalist.

No passado, quando falávamos em generalist, geralmente nos referíamos a um engenheiro que conseguia desenvolver para iOS, Web e backend. Esse tipo de generalist, em essência, ainda é um full-stack dentro da engenharia.

O generalista do futuro é um full-stack interdisciplinar.

Alguém entende simultaneamente produto, design e engenharia. Alguém entende simultaneamente produto, ciência de dados e engenharia. Essa combinação era quase impossível no passado, pois cada uma exigia um longo período de treinamento especializado.

Mas agora a IA reduziu a barreira de entrada para cada tarefa, permitindo que uma pessoa atue em vários campos, mantendo ainda a profundidade profissional.

A equipe do Claude Code é assim. Gerentes de engenharia, PMs, designers, cientistas de dados, finanças e pesquisadores de usuários todos escrevem código.

Os designers podem executar sozinhos os protótipos interativos para mostrar à equipe, em vez de apenas criar imagens e aguardar os engenheiros para implementação.

Os profissionais de finanças podem criar suas próprias ferramentas de análise para executar modelos financeiros complexos da empresa, sem mais precisar esperar na fila pelo BI. Os colegas de pesquisa de usuários começaram a executar seus próprios dados, assumindo as tarefas que antes dependiam da equipe de dados.

A profundidade profissional de cada um ainda está lá. Mas, com a ajuda da IA, escrever código tornou-se uma linguagem compartilhada por todos.

Nas últimas duas décadas, a indústria de SaaS teve algumas regras quase consideradas axiomas.

O primeiro é o custo de mudança. Uma vez que uma empresa use seu sistema, ela gradualmente acumula dados, configurações, campos e relações de permissões de vários anos, até mesmo décadas.

Mudar para outro sistema, apenas transferir tudo isso exatamente como está e depois trazê-lo de volta, já é suficiente para deixar alguém tão exausto que não quer nem começar.

A segunda é o bloqueio do fluxo de trabalho. As operações diárias dos funcionários, a colaboração entre departamentos e os pontos de aprovação surgem todos ao redor desse SaaS.

Trocar um sistema não é apenas migrar dados; é derrubar e reconstruir toda a memória muscular que a empresa desenvolveu nos últimos anos.

Somadas, essas duas formavam o fosso mais profundo da indústria de SaaS no passado. Mas, com modelos suficientemente poderosos, a lógica das coisas começou a mudar.

Primeiro, veja o custo de migração. No passado, mudar de um SaaS para outro já exigia que a equipe de engenharia trabalhasse horas extras por meses apenas para alinhar os campos e replicar a estrutura de dados.

Agora, envie diretamente as interfaces e estruturas de dados de ambos os lados para o modelo, permitindo que ele mesmo clarifique as relações de mapeamento e suba gradualmente em direção à solução ideal. O que originalmente levaria meses pode produzir uma versão funcional em poucos dias.

Agora, olhando para o lado do bloqueio de fluxo de trabalho, é ainda mais interessante. No passado, os fluxos de trabalho conseguiam bloquear clientes porque esses processos eram complexos, implícitos e dependiam de pessoas.

A compreensão tácita dos funcionários sobre quem precisa aprovar quem e em que etapa o processo é travado não pode ser transferida diretamente.

Mas modelos como o Opus 4.7 são exatamente os mais aptos a compreender, decompor e reconstruir um processo complexo em um novo ambiente. Às vezes, a versão reconstruída pode até ser mais fluida que a original.

Então, o moat construído com base em acúmulo de dados e processos está se desintegrando.

Para quem está desenvolvendo SaaS, isso pode ser uma má notícia. Mas para todos os clientes que usam SaaS e para as equipes preparando a nova geração de SaaS, esta é uma verdadeira janela de oportunidade.

As startups que realmente revolucionarão a indústria nos próximos 10 anos podem ser 10 vezes mais numerosas do que nos últimos 10 anos.

A razão na verdade não é complicada.

Pequenas equipes podem usar IA para criar produtos de nível igual ou superior ao das grandes empresas. Por outro lado, para as grandes empresas realmente utilizarem IA, ela se torna um ativo negativo.

How to say it?

Uma empresa com mais de uma década de história desenvolveu todo um conjunto de processos operacionais, divisão de funções, hábitos de colaboração, sistema de treinamento e métricas de desempenho (KPI). Esses elementos eram, no passado, ativos e barreiras de entrada.

Mas integrar verdadeiramente a IA significa revisar tudo isso: os processos de negócios precisam ser reestruturados, todos os funcionários precisam ser treinados novamente, e cada passo adiante encontra grande resistência interna, exigindo coordenação entre N departamentos e N níveis de aprovação.

Uma equipe inicial de três pessoas tratou a IA como base padrão desde o primeiro dia. Eles não tinham fardos históricos para remover, hábitos para mudar ou pessoas para convencer. Hoje discutem claramente, amanhã lançam um demo, e depois de amanhã já podem colocar online para os usuários usarem.

Essa diferença de velocidade já existia antes com a IA. Startups sempre tiveram vantagem de velocidade sobre grandes empresas. Mas a IA ampliou muito essa diferença.

Why?

Quanto mais poderosa a IA, maior o alavancagem que uma pessoa pode exercer em um determinado período de tempo. Uma pequena equipe que realmente utilize bem a IA hoje pode produzir o equivalente a dez pessoas no passado, e amanhã pode produzir o equivalente a trinta pessoas.

Mas o peso organizacional das grandes empresas não se tornou mais leve; pelo contrário, tornou-se mais pesado devido à necessidade de absorver a IA. Quanto mais poderosa for a IA, maior será a diferença entre a aceleração das pequenas equipes e a resistência das grandes empresas.

É isso que Boris chama de ativos negativos. Não é que as grandes empresas não tenham dinheiro, pessoas ou vontade; é que os músculos que antes lhes geravam lucro estão agora justamente travados no caminho para o verdadeiro valor da IA.

MCP não morrerá.

Depois que Skill ficou popular, muitas pessoas acharam que MCP não era mais necessário. O fundador da OpenClaw também tem uma visão semelhante.

Mas Boris não vê assim. Ele acredita que o MCP se tornará a camada de conexão de software na era da IA.

No passado, a forma de conexão de software da internet era API.

Mas o problema central da API é que ela foi projetada para engenheiros. Para usar uma API, é preciso primeiro ler a documentação, solicitar um Token, escrever código, alinhar os campos e tratar exceções. Em resumo, a API é feita para desenvolvedores humanos.

MCP é diferente. Ele permite que o modelo seja conectado diretamente, e o próprio modelo consegue entender e chamar, sem a necessidade de um programador traduzi-lo no meio.

Então Boris chamou a API de Human Developer Interface e o MCP de Model Interface Protocol. Um é para humanos, o outro é para modelos.

Isso é realmente muito parecido com o passado. Na era da internet móvel, todos os serviços eram considerados como tendo de ser APIizados. Na era da IA, todos os serviços são considerados como tendo de ser MCPizados.

Muitas pessoas agora, ao discutirem Computer Use, acham que essa direção pode não funcionar.

A razão também é bastante válida: consome muitos tokens, é lento e instável. Parece mais um demo de exibição de habilidades, ainda longe de ser realmente utilizável.

Mas Boris enxerga um nível completamente diferente.

O que ele valoriza realmente é que o Computer Use resolve um dos maiores desafios da implementação de IA: no mundo real, existem inúmeros sistemas que não possuem API nem MCP.

Especialmente no mundo corporativo.

Só quem entrou na empresa sabe que muitos dos sistemas centrais são muito antigos. ERP, OA, sistemas financeiros, aprovações internas, back-end da cadeia de suprimentos, diversos sistemas personalizados. Muitos não têm interfaces abertas, sem documentação, sem capacidade de automação. Eles estão lá, operados manualmente por inúmeros funcionários todos os dias.

Por que não criar diretamente uma API para elas?

Porque não é viável. Os fornecedores que desenvolveram esses sistemas podem já não existir mais. O departamento de TI não tem motivação nem orçamento para reestruturar.

O departamento de negócios não pode parar para esperar seis meses ou um ano. Esses sistemas nunca esperarão por uma API perfeita para se salvar.

Nos curtos prazos, os principais modelos ainda devem se concentrar em aprimorar sua capacidade de uso de computador.