Fundador do Instagram, Mike Krieger, sobre o Fable 5 e o futuro do desenvolvimento de software impulsionado por IA

Convidado: Mike Krieger, fundador do Instagram

Apresentador: Dan Shipper

Fonte do podcast: Every

Mike Krieger deixa o Fable 5 codificar enquanto ele dorme

Data de transmissão: 11 de junho de 2026

Mike Krieger, como co-fundador do Instagram, criou pessoalmente um dos aplicativos de consumo mais influentes do mundo humano nas últimas duas décadas. Hoje, ele está na vanguarda do desenvolvimento de produtos "nativos de IA", liderando a Anthropic Labs e guiando sua equipe para se concentrar em uma questão final: quando os modelos de IA mais avançados do mundo são colocados nas mãos de verdadeiros desenvolvedores, até onde os limites da capacidade tecnológica podem ser empurrados?

Cinco meses antes do lançamento oficial do Fable, quando ele teve acesso interno ao modelo pela primeira vez, a sensação de choque e descontrole ainda está gravada em sua memória. “Certo, acho que me tornei um completo iniciante novamente,” ele brincou com a equipe na época. De repente, percebeu que todas as regras de ouro que havia acumulado ao longo de décadas sobre produtividade, estratégia de desenvolvimento e até gerenciamento de tempo estavam obsoletas naquele instante. A velocidade de evolução do modelo havia deixado completamente para trás seu fluxo de trabalho anterior.

Neste episódio, o apresentador conduz uma conversa aprofundada com Mike Krieger, oferecendo aos espectadores uma visão exclusiva: como é trabalhar lado a lado com um modelo revolucionário como o Fable na construção de software? Sob essa nova normalidade de coexistência entre humanos e máquinas, quais novas dinâmicas de desenvolvimento, desafios significativos e possibilidades finais imaginativas estão surgindo?

Como o Fable redefiniu completamente o fluxo de trabalho do Mike

Quando usar Sonnet e quando usar Fable

Arquitetura Agent-native gerada pelo Fable 5

O custo de construção já colapsou

A engenharia de software morreu?

Mechanism of verification and price

Fluxo de trabalho dinâmico

Apresentador Dan Shipper: O convidado deste episódio é Mike Krieger, responsável pela Anthropic Labs e co-fundador do Instagram. Mike, eu gostaria muito de ouvir você falar sobre a experiência real de usar profundamente este modelo. Quando um modelo tão poderoso é lançado, é extremamente útil ter alguém que o use diariamente em alta intensidade dizendo: "Ele é incrivelmente forte nesses aspectos, realmente transformou meu fluxo de trabalho aqui, mas noutros lugares não é tão diferente assim" — isso ajuda as pessoas a realmente entenderem como integrar a tecnologia em suas vidas cotidianas.

Mike Krieger:

É verdade. Essa experiência em si já é muito interessante. Nos meses anteriores ao lançamento oficial do Fable, já estávamos usando internamente vários modelos de nível Mythos. Na época, eu estava ansioso para ver o que os desenvolvedores externos criariam com eles, mas, como você disse, a verdadeira elevação cognitiva veio do uso contínuo e intensivo durante semanas, e não da experiência inicial de teste.

Também passamos por essa reestruturação cognitiva em modelos anteriores. No final de dezembro do ano passado e início de janeiro deste ano, quando todos estavam usando intensamente o Opus 4.5 e 4.6, à medida que o tempo de uso aumentava, as pessoas de repente perceberam: "Antes, não explorei o suficiente seu potencial. Preciso avançar um passo adiante e reconsiderar os limites reais das capacidades desta geração de modelos."

Apresentador Dan Shipper: Na verdade, já temos alguns colegas da equipe Every que estão usando. Alguns relataram: "Sinto que preciso de uma árvore de habilidades totalmente nova para dominar esse modelo", especialmente colegas sem formação técnica, que atuam em funções baseadas em conhecimento, e que até se sentem perdidos; enquanto aqueles que trabalham com orquestração de Agentes comentam: "Há tantas coisas novas para aprender."

Mike Krieger: Você mencionou o "fluxo de transformação" — isso toca no ponto essencial: não se trata apenas de etapas operacionais específicas, mas de uma mudança de mentalidade. Curiosamente, a aparição desse modelo coincidiu com meu período de transição profissional: eu havia acabado de passar de CPO (Chief Product Officer) para o Labs, voltando ao modo de desenvolvedor. Cerca de um a dois meses depois da mudança, o modelo foi executado internamente pela primeira vez. Eu estava sentado na frente do computador pensando: "Certo, eu me tornei um novato novamente." Pois percebi que meus hábitos anteriores de escrever prompts e até minha forma de decompor tarefas já estavam completamente obsoletos diante desse modelo.

Sua percepção de escala temporal e modelo de interação precisam evoluir. No passado, eu poderia ter dito: "Tenho uma ideia de recurso, vamos começar pelo primeiro passo —". Agora, isso absolutamente não é mais adequado. A abordagem correta atual é: transmitir intenções mais amplas e completas, e então soltar completamente para que ele avance. Lembro-me que em março e abril, as capacidades que ele demonstrava já eram impressionantes — ele não apenas entregava resultados surpreendentes de uma só vez, mas, o que é ainda mais assustador, conseguia compreender a direção futura de evolução desse recurso e o contexto geral do projeto.

E essa evolução não parou absolutamente. Esta manhã, ainda estava conversando sobre trabalho — durante o voo, percebi que "a grande maioria do meu trabalho eu realmente consigo fazer remotamente". Nem me preocupo mais se a Wi-Fi vai cair, porque, desde que eu defina o contexto e as instruções corretas antes da desconexão (como um comando em loop), ele mesmo consegue acompanhar o processo até o fim.

Nos últimos dois meses, frequentemente vivi esses momentos de destaque: dizer boa-noite ao Claude antes de dormir, passar-lhe uma tarefa complexa, e acordar no dia seguinte descobrindo que ele já havia concluído tudo — geralmente, ele terminava a parte principal às duas da manhã e gastava as quatro horas restantes aperfeiçoando os detalhes.

O que mais me impressionou foi sua capacidade de fechar automaticamente o ciclo. Por exemplo, ele pensa assim: "Mike me pediu para executar uma tarefa complexa esta noite. Mas fiquei preso porque o servidor remoto caiu. Tudo bem, vou criar um mock de backend por conta própria, registrar esse problema na documentação, completar e salvar todo o fluxo agora, e consertar quando o serviço voltar amanhã." Para mim, ser capaz de delegar tarefas desse nível e confiar completamente no resultado final foi uma experiência extremamente impactante.

Claro, você certamente ainda precisará revisar os resultados — isso envolve um mecanismo completo de validação, que podemos explorar mais tarde, pois é uma parte essencial do ciclo fechado. Mas isso realmente me obriga a repensar: diante desse tipo de modelo, o que realmente significa ser "eficiente"? Anteriormente, sempre comparamos esses modelos a "assistentes" ou "companheiros", mas agora, ele se parece mais com um "colega robusto" capaz de assumir a responsabilidade e entregar grande parte do trabalho central.

Apresentador Dan Shipper: Então, como é realmente o seu fluxo de trabalho diário? Notei um fenômeno: se você der a ele uma tarefa grande, falar muito sobre ela e deixá-lo rodar por várias horas ou até a noite inteira, ele se sai melhor. Mas, ao enfrentar tarefas pequenas e cotidianas, ele parece muito lento e caro, o que torna menos atraente usá-lo. Como você equilibra isso na prática? Onde ele se encaixa na sua pilha tecnológica?

Mike Krieger:

Atualmente, uso-o mais para planejamento arquitetônico inicial e alinhamento de soluções. Essa é uma mudança interessante e ainda representa um grande desafio que todos os modelos precisam superar.

Nesse sentido, sou grato pela experiência de trabalhar no Instagram — desde a versão mínima montada inicialmente em um servidor em Los Angeles, até lidar com alto volume de concorrência e escala, e finalmente integrar tudo à infraestrutura do Facebook. Esse processo desenvolve uma intuição sobre "em que fase do projeto usar qual nível de abstração e complexidade arquitetônica".

Então, ainda mantenho interações frequentes com o Fable. Às vezes, ele apresenta uma solução aparentemente perfeita, e eu o faço refletir: "Na verdade, planejo colocar isso no ar em breve — precisamos considerar a capacidade além de um único servidor." Essa interação bidirecional é muito importante. Mas, ao planejar a arquitetura, geralmente peço diretamente que ele gere uma página HTML para visualizar o que discutimos, facilitando o compartilhamento com a equipe. Mesmo um arquivo Markdown serviria, mas prefiro com gráficos.

Isso forma um paradigma interessante: pense e planeje as coisas juntamente com ele, depois produza um documento para alinhar a equipe. Como agora a velocidade de construção de protótipos foi drasticamente reduzida, você precisa ainda mais de consenso e alinhamento anteriores — mesmo que pretenda primeiro "avançar rapidamente em pequenos passos" para criar um demo e depois retroceder para deduzir uma arquitetura de sistema mais rigorosa, a comunicação inicial é essencial. E exatamente aí é onde o pensamento e a colaboração humanos ainda estão profundamente integrados em todo o processo.

Na fase de execução, seja utilizando o tempo noturno ou grandes blocos do dia para atribuir diferentes módulos de tarefas, significa que mantenho simultaneamente muito mais sessões concorrentes do que antes. Às vezes, gosto de manter uma sessão do Claude Code em execução prolongada, fazendo com que ela faça fork (派生) de todas as tarefas para sub-Agents em segundo plano, permitindo que o thread principal responda imediatamente a novos comandos meus; outras vezes, simplesmente abro cinco ou seis abas simultaneamente no navegador, cada uma lidando com tarefas complexas de longo prazo.

Esse modelo de operação, com uma visão de longo prazo e uma atitude de “não se preocupe, deixe comigo, vai levar algum tempo”, realmente oferece grandes possibilidades. Atualmente, também estamos explorando, no nível do produto, como apoiar melhor essa experiência — você certamente deseja equilibrar os dois estados de “resposta imediata” e “execução contínua de longo prazo”, e a forma como eles interagem é muito interessante. Minha preferência pessoal é manter pelo menos uma janela do Claude com alto contexto e resposta extremamente rápida, com a sensação intuitiva de “estou sempre pronto; basta uma palavra sua e eu posso iniciar ou derivar uma sub-tarefa imediatamente”.

Apresentador Dan Shipper: E se, por exemplo, você estiver caminhando pela rua e surgir de repente uma pergunta — você tiraria o Fable? Isso não seria como usar um lançador de foguetes para matar um mosquito? Ou você troca frequentemente entre diferentes modelos?

Mike Krieger:

Recentemente, eu realmente usei o Fable para tudo, e a experiência foi exatamente como você disse — você fica olhando para a tela, vendo-o se esforçar ao máximo para pensar.

Até a semana passada, eu queria pesquisar uma pergunta simples que até me deixava um pouco constrangido, sobre as Finais da NBA. Naquele momento, mudei para o móvel do Sonnet e imediatamente percebi: "Ah, é claro! Antigamente eu sempre usava o Sonnet para perguntas rápidas como essa." Era uma experiência completamente diferente. Isso nem sequer tem a ver com quantos tokens são gerados por segundo, mas sim com quanta capacidade cerebral precisa ser usada para pensar na questão. Às vezes, uma resposta simples não precisa de tanta profundidade e reflexão desnecessária.

Para nossa equipe de produtos, essa também é uma questão muito interessante. Em geral, você certamente não quer que os usuários fiquem diariamente confusos na interface sobre qual modelo escolher. Idealmente, a longo prazo, podemos agrupá-los em alguns cenários extremamente intuitivos e prontos para uso; ou até mesmo direcioná-los diretamente com base na interface — porque, honestamente, na maioria das vezes, quando uso um app iOS, provavelmente não estou tentando fazer coisas que exijam o Fable. Portanto, implementar uma camada de fixação invisível do modelo na interface pode ser uma abordagem válida. Precisamos explorar mais profundamente o que isso significa em termos de produto. Mas essa sutileza de pensar “essa pergunta nem merece o Fable, eu deveria chamar o Sonnet para responder” — recentemente, realmente entendi bem esse sentimento.

Você está certo; para tarefas interativas de alta frequência e alta granularidade, o Fable tende automaticamente a aprofundar demais. Na verdade, o Fable foi o primeiro modelo com o qual encontrei que me fez ativamente ajustar o "nível de esforço" (Reasoning Effort) — às vezes eu sentava e pensava: "Só quero alterar o estilo da IU, basta ajustar o esforço para 'médio' e ver o efeito." Antes, ao usar o Opus, eu quase nunca ajustava isso, pois o intervalo de elasticidade do modelo não era tão amplo, mas o Fable tem uma faixa realmente muito ampla.

Apresentador Dan Shipper: Você pode nos mostrar o que você já fez com ele?

Mike Krieger:

Quando lançamos este novo modelo, fizemos uma coisa — encorajamos toda a equipe a usá-lo em suas próprias contas pessoais, especialmente durante o fim de semana. Foi bem interessante, porque a Anthropic tem muitas ferramentas de produtividade personalizadas internamente, então, de vez em quando, dar um passo para trás e voltar ao estado mais puro: “Só vou usar o puro Claude Code e fazer algumas coisinhas divertidas para mim mesmo no fim de semana.” Essa sensação é ótima.

Apresentador Dan Shipper: Você está executando no aplicativo terminal ou no aplicativo de desktop?

Mike Krieger:

Boa pergunta. Ainda passo a maior parte do tempo no terminal. Mas, curiosamente, minha esposa — que não é engenheira de profissão, com formação mais voltada para design de UX (experiência do usuário) e PM (gerente de produto) — acabou se apaixonando pelo Claude Code por meio do aplicativo de desktop. Acho que o aplicativo de desktop a ajudou a ignorar muitos dos conceitos abstratos avançados por trás. No entanto, quando trabalhei neste projeto, continuei usando o Ghostty e o terminal.

Eu sempre quis um "rastreador de progresso de mídia" perfeito — normalmente jogo, assisto séries e recebo recomendações de amigos, então precisava de uma ferramenta que se ajustasse perfeitamente aos meus hábitos de organização. Meus dois critérios principais eram: primeiro, adicionar itens precisava ser extremamente fácil, bastava dizer ou digitar uma frase para o Claude, que ele mesmo pesquisaria em toda a web, completaria as informações e organizaria adequadamente; segundo, envio ativo de notificações, por exemplo, quando houvesse uma nova temporada ou sequela de um jogo, ele deveria encontrar automaticamente.

A maior parte da UI foi concluída de uma só vez pelo Fable, o que já é impressionante. Mas uma pista que tenho insistido em explorar nos Labs este ano é: como fazer com que a equipe de software — neste caso, a equipe do Claude — fique mais próxima do próprio software?

Foi uma manhã de sábado, e na verdade toda a minha semana estava cheia de atividades com as crianças, então meu desenvolvimento foi totalmente "intermitente": levava as crianças para escalar montanhas, voltava, escrevia algumas linhas, e saía novamente. Às vezes, durante a escalada, eu não conseguia resistir a dar uma olhada no progresso — embora não deva usar o celular enquanto estou com as crianças, monitorar remotamente o andamento das tarefas no celular era uma sensação incrível.

Naquele momento, me ocorreu uma ideia: será que poderia fazer experimentalmente um experimento agressivo, permitindo que o software se modificasse internamente?

Eu fiz versões tanto para móvel quanto para web. Eu já havia criado uma interface de chat interativa onde posso dizer diretamente ao Claude: "Ajude-me a adicionar este URL à lista de rastreamento." Mas eu gostaria que todos os softwares evoluíssem para ter essa capacidade — nunca mais quero precisar navegar por menus complexos e hierárquicos para encontrar funções.

Dan, em muitos níveis, estou realmente tentando levar a arquitetura nativa de agentes até os limites mais extremos.

A chamada arquitetura agent-native tem como primeira fase: todos os componentes e dados principais do produto devem estar totalmente abertos ao agente e possuir interfaces de chamada de ferramentas correspondentes. Isso está se tornando rapidamente a linha de sobrevivência da indústria de software — embora seja triste que a maioria dos softwares disponíveis hoje ainda não consiga atingir esse ponto.

Tenho um ótimo exemplo positivo: recentemente, alguém me indicou uma série brasileira brilhante sobre o acidente com material radioativo em Goiânia. O nome era extremamente longo e difícil de lembrar, então mencionei vagamente o assunto ao sistema, e o Claude imediatamente pesquisou e classificou com precisão. Essa experiência foi muito melhor do que eu tentar procurar aleatoriamente no Google por intuição.

Mas o próximo passo no qual realmente me apaixono é: em cenários móveis, modificar diretamente o próprio software dentro do software — como isso se desenvolverá?

O que eu fiz — mais precisamente, o que eu solicitei ao Claude para fazer — é uma interação em que, ao pressionar longamente o botão de bate-papo no app, acionamos nosso agente gerenciado para receber "instruções de modificação de código" e visualizar imediatamente os resultados usando a funcionalidade de pré-visualização ao vivo do Vercel. Quase todo o módulo funcionou perfeitamente desde o início, foi muito legal; depois, fui adicionando gradualmente algumas novas ideias. Se você for um entusiasta avançado, também pode verificar o gráfico de diff (diferenças de código) ou entrar no histórico de conversas do agente gerenciado para ver exatamente o que foi alterado em nível básico — mas eu quase nunca olho, pois, para um projeto pessoal e brincalhão, simplesmente não me importo com sua manutenibilidade a longo prazo (risos).

Isso é simplesmente viciante. Quando estava brincando com meus filhos fora de casa, percebi que “o botão flutuante está muito baixo na posição no iOS” e disse isso diretamente no app; ele próprio foi ao backend e corrigiu o código. Integrado à cadeia de ferramentas de desenvolvimento do Expo, ele até realizou o hot reload diretamente no meu telefone — a experiência naquele momento foi simplesmente perfeita.

Is it necessary for this to reach a production-level standard capable of handling millions of concurrent users? Absolutely not. But it gives me an excellent sense of control: you don’t have to halt the project the moment the weekend ends and you close your laptop—you can heavily use it while continuously modifying it as you go. This end-to-end real-time feedback loop allows you to iterate endlessly.

Isso não é apenas uma excelente demonstração das habilidades de engenharia robusta da Fable, mas também uma síntese da questão final que sempre discutimos: como o Claude deve ser integrado ao software? Ele não deve permanecer apenas no nível de "uso", mas sim ser profundamente incorporado à medula da "construção" do software.

Apresentador Dan Shipper: Quero realmente destacar um ponto: ferramentas como essa, você poderia ter tentado criar há dez ou vinte anos, mas certamente não desta maneira. O custo de construção de software sofreu uma queda abrupta. Pense na época em que se fazia o Instagram: quantos recursos seriam necessários para levar um projeto a esse nível de conclusão? E agora, quantos são necessários? Nos ajude a quantificar essa transformação época.

Mike Krieger:

Eu frequentemente me lembro daqueles dias. Nos primórdios do Instagram, sempre me considerei um engenheiro extremamente produtivo — apaixonado por desenvolvimento móvel e com forte intuição sobre a direção do produto. Mas mesmo assim, transformar uma ideia na minha cabeça em um produto completo exigia pelo menos quatro ou cinco noites em claro de esforço intenso. Naquela época, ficar acordado até tarde era rotina: eu me mantinha acordado até às quatro da manhã e depois dormia até o meio-dia — esse ritmo era completamente incompatível com a vida familiar, mas era exatamente o meu "modo construtor" daquela época.

Revisando a versão V1 do Instagram — ela tinha realmente mais funcionalidades do que o meu rastreador de mídia feito neste fim de semana, mas não havia uma diferença essencial em escala. Na época, para criar aquela V1, Kevin e eu passamos cerca de cinco noites seguidas trabalhando sem dormir: eu assumi todo o frontend e backend sozinho, enquanto Kevin cuidou dos filtros de imagem iniciais. E tudo isso foi feito com base na nossa experiência de muitos anos em desenvolvimento iOS.

Nem se fala na frustração do ritmo de iteração daquela época. Depois que o produto estreou com um sucesso estrondoso, tínhamos inúmeras novas ideias acumuladas na cabeça, mas todo o nosso esforço era dedicado apenas a garantir que os servidores não caíssem sob o tráfego massivo, ou, no máximo, conseguíamos arranjar um tempinho para adicionar uma pequena funcionalidade incremental. Por exemplo, a função de Hashtag levou-me uma semana inteira apenas para ser implementada, enquanto você tinha outras dez mil coisas que queria fazer, todas travadas na fila de prioridades.

Então, não se trata apenas de o tempo ter sido comprimido — embora o tempo de construção tenha realmente sido reduzido a níveis incríveis — mas, mais importante ainda, o outro lado da moeda: agora você pode iterar imediatamente o que já possui, de forma extremamente suave e com grande fluidez.

Além disso, esse benefício já começou a se espalhar, muito além do círculo de profissionais como engenheiros de software e fundadores como eu. Anteriormente, se você tivesse uma ótima ideia de negócio, mas não soubesse programar, suas únicas opções eram duas: contratar terceirização — o que envolvia uma distorção de informação extremamente grave e entregas medíocres — ou tentar levantar capital desesperadamente. Agora, o abismo entre "intenção" e "execução" foi nivelado para pessoas comuns que não sabem programar.

Nos últimos dias, recebi uma mensagem (Ping) de uma colega interna. Nós ajudamos ela a configurar uma ferramenta interna que integrou as capacidades do Fable com o acesso aos nossos próprios MCPs (Protocolo de Contexto de Modelo). Ela trabalha com recrutamento (RH) e, emocionada, me disse: "Pela primeira vez na minha vida, sinto que o que penso na minha cabeça e o que existe no mundo real estão totalmente conectados. Consigo criar diretamente o que imagino."

Naquele momento, para ela, foi absolutamente um instante marcante e impactante. Se fosse há quatro ou cinco anos, para obter uma ferramenta de negócios exclusiva, ela teria que ou montar soluções amadoras com softwares prontos, ou implorar aos engenheiros da equipe de ferramentas internas — cuja fila de demandas no Jira provavelmente já tinha 50 prioridades mais altas. Mas agora? Ela está se divertindo enquanto expande seu território no mundo do código.

Também é isso que acho mais empolgante para o futuro: a criatividade humana é infinita, e a coisa mais notável que estamos fazendo hoje é ampliar infinitamente os limites do grupo de pessoas capazes de transformar seus pensamentos em realidade.

Apresentador Dan Shipper: Concordo plenamente com você. Mas imagino que muitas pessoas agora estejam se perguntando: após tudo o que você acabou de descrever, a engenharia de software está mesmo acabada?

Mike Krieger:

Deve-se dizer que o conteúdo da engenharia de software mudou completamente. Ela está passando por uma transformação radical.

Se você me perguntasse, naquela época em que fazia Instagram: “O que é engenharia de software?”, eu provavelmente lhe diria: compreenda profundamente os desafios de design difíceis, construa uma arquitetura de sistema sólida e gaste inúmeras horas no TextMate ou no Xcode. Lute com os detalhes internos do Django ORM e, em seguida, faça o deploy e sofra consertando bugs. Agora, a maioria dos passos desse processo foi revolucionada e está acelerando em direção aos limites da gestão de produtos. A fronteira entre produtores e engenheiros tornou-se extremamente nebulosa. Isso é muito evidente na nossa própria equipe de desenvolvimento.

Mas se você conseguir sair da definição literal excessivamente rígida de "engenharia de software" e analisar o "desenvolvimento de software" ou a "produção de software" em um sentido mais amplo — em vez de se concentrar apenas na pequena parte que envolve programadores escrevendo código — perceberá que esta indústria não só está se saindo bem, como também está em uma posição central sem precedentes.

A aparição do Fable realmente elevou minha confiança nos modelos de IA a um novo nível — comecei a deixá-lo "executar闭环 automático completo e até mesmo projetar arquiteturas de sistema razoáveis". Do lado da execução técnica, a IA já avançou muito, muito longe. Mas "dominar a alma desta arte de software" — como identificar exatamente quais dores do usuário você está resolvendo e se a experiência do que você criou é realmente impressionante — esses julgamentos de alto nível permanecem como qualidades humanas puras e insubstituíveis por máquinas.

Of course, this painful transition is not painless for many people.

Neste mundo, muitas pessoas já se apaixonaram profundamente pela arte artesanal de escrever código manualmente. Eu mesmo já fui assim. A sensação de prazer de dizer: “Esse bug me prendeu por três dias, e hoje resolvi de forma perfeita!” é irreplaceável. Antigamente, você até sonhava com código — se já teve essa experiência, seus sonhos estavam cheios de lógicas que você estava tentando resolver, e no exato momento em que acordava, uma iluminação súbita lhe trazia a solução. Essa era pura dos artesãos provavelmente já se foi para sempre.

Recentemente, conversei com alguns dos engenheiros mais hardcores que conheço no setor, e todos me expressaram uma emoção complexa intensa: por um lado, uma profunda tristeza ao ver a extinção de ofícios tradicionais, e por outro, uma excitação extrema de "Nossa, minha produtividade concorrente atual é simplesmente incrível".

Apresentador Dan Shipper: Como essa proposição é válida — que a engenharia de software não apenas está viva, mas está se saindo muito bem — como é que a própria equipe de pesquisa e desenvolvimento da Anthropic trabalha no dia a dia?

Mike Krieger:

Há algumas pistas muito claras aqui, e posso discutir em conjunto com o ciclo de vida completo do software e minha rotina de desenvolvimento diária.

Primeiro, ainda há uma grande quantidade de "alinhamento humano". As pessoas se reúnem em salas de reunião para brainstorming sobre a próxima evolução do Cowork e depois dividem o plano em áreas de responsabilidade para diferentes membros. Este passo continua sendo crucial, pois muitos contextos globais que só os seres humanos conseguem compreender não podem ser percebidos remotamente pelo Claude atual — como a verdadeira intenção comercial deste produto, as linhas de desenvolvimento ocultas atuais e as informações sobre outros produtos que estão prestes a serem descontinuados ou sendo preparados para serem integrados de maneira extremamente sutil.

Embora nossa equipe tenha fornecido a cada membro múltiplas torres Claude, na prática da gestão, cada pessoa ainda carrega o título de DRI (Directly Responsible Individual, Pessoa Directamente Responsável), sendo responsável por um módulo específico do produto. Acredito que esse mecanismo não desaparecerá em curto prazo, pois há uma lacuna fundamental entre a visão macro de "colaboração distribuída e esforço conjunto para aprimorar o produto" e a execução micro de "como faço hoje para fazer a Claude concluir essa tarefa específica". Embora estejamos fortemente promovendo reuniões minimalistas, essas reuniões prévias de brainstorming e alinhamento continuam sendo essenciais.

Em segundo lugar, há uma grande quantidade de "ordens assíncronas". Muitos dos nossos engenheiros criaram suas próprias versões personalizadas de painéis de controle para monitorar o que suas equipes de Claude estão fazendo: "Em que etapa meu Claude Code chegou?", "Há algo preso na fila aguardando minha aprovação?", "Quais PRs precisam da minha intervenção para modificação — porque foram rejeitados por outros colegas ou por uma revisão de código de algum grande modelo?"

Atualmente, uma grande parte do esforço dos engenheiros é dedicada a manter esse tipo de trabalho. Alguns desses ferramentas de colaboração estamos padronizando, mas a maioria ainda mantém um forte caráter pessoal de entusiastas — assim como programadores antigamente gostavam de personalizar suas interfaces de desktop, agora eles estão personalizando seus próprios fluxos de trabalho com grandes modelos.

Além disso, há a compreensão do funcionamento real do código em ambiente de produção. Este é outro fronteira avançada que os grandes modelos estão fortemente buscando superar. O Fable já demonstrou progressos significativos nessa área, mas ainda há um longo caminho a percorrer: por exemplo, compreender profundamente o que realmente acontece após a implantação e o lançamento do código. Sistemas podem entrar em colapso e apresentar falhas estranhas e imprevisíveis — honestamente, durante os anos de 2012 a 2016 no Instagram, grande parte da minha vida foi gasta lidando com esses incidentes em produção e escalando arquiteturas. Ao responder a emergências em produção, o papel do engenheiro sênior ainda é insubstituível: você precisa contar com anos de experiência em resposta a incidentes para manter a calma absoluta, coletar integralmente os dados de logs, implementar medidas de contenção de emergência e, em seguida, elaborar soluções duradouras e fundamentais.

O último ponto que quero enfatizar é que o papel do "protótipo de engenharia" mudou completamente hoje.

Você precisa definir com extrema clareza se o que tem nas mãos é apenas um Demo ou um código de produção pronto para o lançamento. Antigamente, na Vale do Silício, era popular dizer: "Código vence argumentos" (Code wins arguments). Pessoalmente, sempre fui um pouco cético sobre isso, pois sua conotação implícita era que quem sabe programar detinha o poder de decisão. Mas agora, o cenário evoluiu de forma muito interessante: às vezes, ficamos presos em discussões sobre a direção de um produto, e frequentemente algum PM que não escreve código aparece dizendo: "Acabei de criar um Demo sozinho — embora ainda esteja bem rústico em 8 detalhes — mas vejam, este caminho absolutamente funciona!" E isso imediatamente abre uma conversa completamente diferente, de um nível superior.

Olhando para trás, quase todas as nossas abordagens de desenvolvimento agora são completamente diferentes em comparação com seis meses atrás. O traço mais evidente é o incrível grau de paralelismo no desenvolvimento e a necessidade absoluta da equipe de realizar abstrações avançadas no fluxo de trabalho.

Mas há uma coisa que nunca mudou desde o início: a "propriedade e responsabilidade" das pessoas em relação aos produtos.

Apresentador Dan Shipper: Fable também é caro. Quando o testei, senti-me como uma criança em uma loja de doces, empolgada, gritando: "Quero este, este e este!" Mas na hora de pagar, antes de apertar Enter, eu sempre duvidava: "Será que isso vai me custar 100 dólares ou mais de uma vez?" Acho que esse preço elevado cria uma barreira invisível para quem pode usá-lo e para o que se pode fazer com ele. Como você vê o custo-benefício comercial dele?

Mike Krieger:

No campo profissional da engenharia de software, este livro na verdade é o mais bem contabilizado. Em relação à precificação, existem muitas dimensões internas consideradas. Ele é certamente muito mais caro que o Opus, mas se você avaliar a quantidade impressionante de trabalho entregue por cada transação, em muitos aspectos comerciais, ele parece quase de graça. Claro, cada pessoa tem seu próprio cálculo econômico.

Do ponto de vista da equipe de software, se a primeira fase for a empresa fazer com que os funcionários adotem a programação com IA — ainda com modelos e ferramentas imaturos; a segunda fase for criar rankings para ver quem usa mais, o que gerará mecanismos de incentivo pouco ideais; então a terceira fase será identificar quem usa de forma mais eficaz, permitir que essas pessoas usem o máximo possível, ao mesmo tempo em que há um processo claro para evitar desperdícios.

O modelo do nível Fable se alinha perfeitamente à lógica da terceira fase. Se você conseguir produzir resultados concretos de forma consistente e criar valor real e tangível nos negócios, a empresa naturalmente desenvolverá um mecanismo de orçamento positivo que o apoiará ilimitadamente.

No uso pessoal, eu mesmo faço testes usando meu cartão de crédito pessoal para pagar pelos meus próprios serviços. Nesse momento, você realmente se torna mais econômico e cauteloso. Mas, curiosamente, o rastreador de mídia que desenvolvi no fim de semana acabou custando apenas um pouco mais do que o normal — fazer um projeto pessoal como esse não chega nem perto de gastar milhares de dólares.

Agora, os verdadeiramente presos pelos preços são os entusiastas de código aberto ou desenvolvedores independentes (Indie Hackers) que não estão sob a proteção das grandes empresas e são extremamente sensíveis aos preços. Minha sugestão para eles é: vá em frente e veja quanto eles conseguem entregar de uma só vez, sem passar por intermináveis "vaivéns".

O custo atual evoluiu para um conceito multidimensional — você precisa considerar não apenas o “custo por pergunta”, mas sim o “custo total para resolver completamente uma tarefa”. O que mais me impressionou no Fable é exatamente isso: ele sempre tende a fazer as coisas certas desde o início, sem precisar que eu fique diante do computador discutindo nove rodadas com ele, desesperado, gritando: "Não! Não é isso que eu quis dizer!"

Apresentador Dan Shipper: O que mais me impressionou foi que, quando você dá a ele uma tarefa macro, ao receber a resposta, percebe que ele já analisou até os menores detalhes, uma sutileza esmagadora que nunca experimentei em nenhum outro modelo. Você pode revelar algum segredo sobre o treinamento? O que exatamente alimentou essa洞察力 tão impressionante?

Mike Krieger:

Em muitos níveis, é uma continuação do enorme esforço da equipe—tenho apenas admiração pela nossa equipe de pré-treinamento e RL. A evolução mais óbvia para mim é uma "percepção de todo o sistema", e não apenas da parte atual em que estamos trabalhando.

Fico constantemente impressionado com algumas de suas operações geniais. Por exemplo, assim que termina de escrever um trecho de código, ele repentinamente se oferece: "Mestre, sei que, em um ambiente de produção real, essa configuração pode ser diferente. Você ativou esse interruptor de função? Se não ativou, o que eu acabei de escrever não vai funcionar ao ser implantado."

Ou observe como ele responde ao feedback da revisão de código—seja de pessoas ou de outro Claude—ele não simplesmente diz: "Ah, sim, esse é um problema, vou consertar". Ele realmente reflete sobre se deve aceitar um risco na fidelidade atual ou contestar outro revisor—frequentemente outro modelo Fable—dizendo: "Entendo seu ponto, mas contesto; acho que está errado".

É extremamente importante que o modelo tenha essa capacidade de julgamento. Se eu precisasse apontar onde ele mais progrediu, seria que ele não responde imediatamente com um "sim, sim, vou consertar" — ele parece mais com "deixe-me pensar. Ainda assim, não concordo." Essa capacidade é muito útil.

Ter um produto como o Claude Code no mercado é extremamente valioso, pois você tem algo concreto, com o qual as pessoas podem dizer: "Este é o ponto em que o modelo se sai bem, e este é o ponto em que ele se sai mal". Colocamos os parceiros da Every entre as fontes de feedback de mais alta prioridade em nossa confiança, pois eles submetem o modelo a tarefas intensas e prolongadas por vários dias, o que é essencial para pensarmos no que precisa ser aprimorado na próxima geração.

Apresentador Dan Shipper: O chat é a interface de interação mais adequada para este modelo? Não é algo recursivo; é mais como delegar tarefas a alguém. Como isso afeta a maneira como você deve usá-lo ou como você vê essa interface?

Mike Krieger:

O modelo básico de enviar e receber mensagens não está totalmente errado, mas precisamos evoluir em algumas direções.

Primeiro: seu laptop é o local correto? É exatamente aí que eu mencionei anteriormente o quão útil o móvel é para projetos pessoais. Os criadores do Claude Code sempre estão um passo à frente em como esses modelos são usados; cerca de nove meses atrás, conversei com ele e ele disse: "Movi a maior parte do meu trabalho com o Claude Code para o móvel." Eu estava cético na época, mas especialmente no nível do Fable, pois ele mantém a sessão ativa e temos máquinas de desenvolvimento remoto na Anthropic, então o primeiro ponto é: desconectar o local onde o trabalho ocorre do local onde discuto o trabalho.

O segundo ponto continua o que eu disse anteriormente: como você pega tudo o que o Fable discutiu, decidiu e sugeriu e o torna compreensível? Esse é o campo em que estamos pensando. Existem algumas habilidades que permitem criar gráficos, mas a interface de chat atual não é suficiente; às vezes, o Fable lhe fornece uma quantidade excessiva de texto, e você precisa dar uma caminhada para se preparar para entendê-lo. Uma coisa que comecei a fazer foi: "Você tem muito mais contexto sobre isso do que eu. Podemos voltar atrás — fazer mais revelações progressivas da complexidade?"

O terceiro é o modo multiusuário, e ainda estamos em estágios iniciais de exploração. Em certa medida, como temos a estrutura de DRI e áreas de propriedade, normalmente um trabalho importante é um fluxo entre uma pessoa e alguns Claude. Mas em alguns casos, isso não é tão claro — talvez seja uma resposta a incidentes, com várias pessoas pensando simultaneamente; ou projetos onde múltiplos domínios se cruzam. Compartilhar conversas resolve parte disso, mas acho que, no futuro, haverá essa necessidade: você tem um Claude independente, iniciado por uma pessoa e que realizou muito trabalho, mas ele consegue se manter sincronizado com todo o outro trabalho sendo feito pela equipe? Essa é a próxima fronteira interessante e subexplorada. O emocionante é que os modelos agora têm capacidade de se tornar verdadeiros colegas de equipe, e quase estamos atrapalhando-os por não termos as abstrações corretas.

Apresentador Dan Shipper: Isso me lembra que, na maioria do tempo, uso esse modelo para meus próprios projetos de vibe coding, mas há um problema ao usá-lo dentro de uma organização: realmente entendo todas as partes que o modelo acabou de fazer? Como transfiro o contexto do que o modelo acabou de concluir para a minha mente? Esse é um grande gargalo. Como você define a linha de "quanto exatamente preciso saber" e como garante que tem o contexto suficiente para se sentir tranquilo?

Mike Krieger:

Duas grandes partes. A primeira é a validação. No início deste ano, fui totalmente convencido pela validação, algo que se relaciona com uma experiência que tive quando trabalhava full-time como programador: encontrar o ciclo de desenvolvimento mais rápido para girar em torno da sua ideia. Na era do Instagram, às vezes significava criar um novo destino de compilação no Xcode, contendo apenas aquela tela e dados sintéticos, e iterar apenas nesse ciclo. Eu orientava novos engenheiros dizendo: "Se eu só pudesse ensinar uma coisa, seria fazer isso para o seu projeto — as coisas ficariam muito mais rápidas."

A situação atual é: toda vez que eu implemento algo, como garanto que cada PR do Claude venha acompanhado de fotos ou vídeos — seja para alterações no iOS ou na camada de UI. Isso lhe dá muita confiança. O Fable pode ir trabalhar sozinho por algumas horas e voltar dizendo: "Terminei", e então você vê "aqui está a galeria de capturas de tela de toda a UI", o que é extremamente útil. Você diz: "Na captura de tela oito, aquele estado de erro — eu nunca tinha visto antes, mas consigo perceber como o usuário iria se sentir ao encontrá-lo. Vamos corrigir isso." Fazer validações abrangentes é algo em que temos investido fortemente internamente.

Segundo ponto: você ainda será responsável pelo trabalho que realiza. Muitas pessoas usam Claude todos os dias, mas ainda existe responsabilidade — "Claude pode ter escrito o código, mas você precisa entender quais decisões macro foram tomadas". Vejo um número considerável de engenheiros adotando uma prática: Claude conclui o trabalho, mas segue-se uma conversa subsequente — "Posso garantir que compreendi completamente todas as trade-offs que você fez?". Independentemente do artefato gerado, qualquer esforço que torne o conteúdo mais fácil de entender vale a pena.

Durante as reuniões, é interessante — alguém diz: "Pronto, já preparei esse PR", e outra pessoa pergunta: "Você fez X ou Y?" E há aquele momento de pausa: "Para ser honesto, não tenho certeza — vou verificar antes de mergear." Adaptar-se a essa nova normalidade e aprender como lidar com ela é algo que todos nós precisamos aprender.

Apresentador Dan Shipper: O ciclo de verificação que você mencionou há pouco tem um grande potencial imaginativo. Além da captura de tela automatizada e do compartilhamento de tela, quais outras abordagens mais avançadas vocês estão explorando?

Mike Krieger:

Nosso ponto de entrada principal é: você consegue fazer com que ele execute o fluxo real, em vez de apenas injetar dados estáticos? À medida que o sistema se torna mais complexo, isso se torna cada vez mais difícil. Por exemplo, precisamos que o aplicativo iOS gerado pelo Fable consiga fazer login em um clique em nosso ambiente de simulação, chamando apenas contas de teste reais e dados de fluxo realistas de alta fidelidade. Ao mesmo tempo, não queremos que ele execute, a cada vez, o longo e tedioso processo de registro de novo usuário em 8 etapas apenas para testar um simples ajuste de botão. Por isso, desenvolvemos especificamente para a IA um sistema especial de permissões avançadas e chaves criptografadas compartilhadas, permitindo que a IA pule automaticamente as etapas iniciais e entre diretamente no núcleo do negócio, garantindo que a experiência de teste da IA seja quase idêntica à experiência real do usuário.

A segunda parte é a combinação do caminho conhecido e do caminho modificado atualmente — o primeiro é muito valioso para testes de regressão. Já expressamos por escrito alguns fluxos de trabalho idealizados, que o Claude pode revisar repetidamente. Além disso, o Claude também se sai muito bem ao expressar a intenção por trás das alterações que está realizando no momento, portanto essa parte será profundamente praticada. A combinação desses dois elementos é importante.

A verificação visual também é crucial, e o vídeo é uma ferramenta extremamente subutilizada para o Claude. Recentemente, estive trabalhando em um protótipo: gravar vídeos do que o Claude construiu e entregá-los a ele, combinado com o FFmpeg, observando-o analisar quadro a quadro e dizer: "Esta animação está com travamentos, vou consertar". Capturas de tela nunca capturariam isso, pois perdem esse momento.

Para partes que não são fáceis de testar de ponta a ponta, fazer com que o Claude construa um backend simulado confiável, ou use um existente, também é muito interessante. Na era do Artifact, já tínhamos testes abrangentes na era pré-LLM. Cada componente de infraestrutura tinha uma implementação em memória robusta que podia ser executada rapidamente nos testes unitários. Agora, estenda isso para o domínio do Claude: estou desenvolvendo algo com um backend bastante sólido, que não é fácil de iniciar no meu servidor de desenvolvimento, mas ele criou imediatamente um excelente substituto. Com o tempo, esse substituto evolui junto com o próprio código. Antes, eu diria: “Sincronizar isso é muito trabalhoso.” Agora, penso apenas: “O Claude vai ler as alterações, adaptar o substituto e manter ambos sincronizados. É só isso.”

Apresentador Dan Shipper: Existem algumas arquiteturas muito interessantes: quando você recebe um bug, um agente o corrige automaticamente e envia uma mensagem ao cliente dizendo "consertado". Você notou alguma mudança nesse fluxo no Fable?

Mike Krieger:

Vários aspectos. No nível humano com o Claude, há uma coisa que vejo repetidamente: se alguém relatar um bug no canal de feedback do nosso Slack, esse tópico é encaminhado para a sessão do Claude Code. Graças ao Slack MCP, ele pode realmente buscar esse tópico e responder em meu nome: "Este é o Claude do Mike, consertei isso — aqui está o link do PR." Mas então ele diz: "Espere — ainda não foi implantado. Quando for, eu aviso você novamente." Horas depois: "Esta implantação foi enviada. Você deveria testar para ver se foi consertado?" Esse tipo de acompanhamento cíclico é relativamente novo. Tenho várias sessões de Claude Code em execução prolongada interagindo em meu nome. Também incluí algumas isenções de responsabilidade nelas.

A segunda parte volta ao nosso diálogo anterior sobre gosto e julgamento. Um nível é: “Há um bug relatado, então preciso consertá-lo”; outro nível é ter bom julgamento. No fim de semana, me deparei com uma situação: tínhamos um sistema interno funcionando há muito tempo sem reiniciar, e ocorreu um vazamento de memória. O bom julgamento seria: “Mike, é fim de semana. Reinicie o servidor agora, isso resolverá imediatamente; eu abrirei assincronamente um PR para a correção de longo prazo.” Se você quiser que o Claude participe desse fluxo de bug para correção, você realmente deseja que ele entenda exatamente o que qualquer bom SRE ou engenheiro entenderia: resolver o problema imediato; sobre trocar a plataforma ou refatorar, isso é outra discussão. Compreender esse equilíbrio é extremamente importante.

Apresentador Dan Shipper: O que mais empolga sobre este novo modelo é que ele não apenas elevou o piso, permitindo que qualquer pessoa sem experiência crie seu próprio aplicativo com um clique, mas também derrubou o teto dos especialistas. Se você é atualmente um engenheiro profissional ou fundador de uma startup, tem toda a capacidade de realizar sozinho projetos complexos que antes nem ousava imaginar. Em sua opinião, quais são os campos de ponta que as pessoas ainda não perceberam plenamente, mas que podem ser totalmente abordados com este novo modelo?

Mike Krieger:

Alguns pensamentos, talvez começemos com algo divertido. As pessoas sempre têm muitas ideias criativas sobre como expressar a complexidade do seu mundo; em cada área, há algo que você conhece bem, e sempre surge a pergunta: “Como explico isso a alguém? Posso aplicar tecnologias de outros lugares no meu trabalho?” No caso da minha amiga Tai Tan, ela recentemente mergulhou na engenharia ambiental, focando em energia geotérmica — um campo repleto de modelos matemáticos complexos e simulações de dinâmica dos fluidos que deixam qualquer um com dor de cabeça. Mas, com a atualização revolucionária dos modelos de raciocínio da geração Fable, ela conseguiu integrar perfeitamente tecnologias extremamente especializadas, totalmente fora da sua área de formação, ao seu próprio trabalho de pesquisa. Agora, ela até consegue pedir ao Fable para construir um sistema completo de simulação de aprendizado profundo end-to-end com PyTorch — algo que, antes, seria pura ficção científica para uma acadêmica não especializada em computação.

A segunda parte é a capacidade de combinar software para resolver problemas que são muito únicos para você. Internamente, fizemos muito trabalho para transformar o máximo possível de nossos sistemas internos em MCP, com a estrutura de permissões e configurações de implantação corretas. Existem também ótimas plataformas PaaS externas; você só precisa perguntar ao Claude, e ele ajudará a montar para você. Mas eu particularmente adoro aquela sensação de "criar algo que você sempre quis".

Outra coisa que me surpreendeu profundamente recentemente: temos um colega da equipe de comercialização que não tem formação técnica, mas integrou profundamente o Claude em cada detalhe de seus processos diários de negócios. O mais assustador é que ela não parou após concluir a versão V1 — ela continuou usando essa ferramenta, trabalhando silenciosamente nos bastidores junto com o grande modelo, realizando iterações intensas por vários meses.

Isso revela exatamente o ponto mais subestimado e mais atraente desta geração de modelos de raciocínio: nas fronteiras de sobrevivência dos modelos das gerações anteriores, os projetos frequentemente apresentavam um "teto de complexidade". Assim que seu código de negócios ou lógica atingia um certo volume, o grande modelo começava a "ignorar a parte de trás". Quando você tentava adicionar novas funcionalidades, ele começava a gerar erros frenéticos e estragava diretamente a arquitetura que você já havia construído.

Mas agora, essa colega que não sabe programar, com o apoio de modelos no nível do Fable, já vem mantendo seu sistema em segundo plano por vários meses. Você pode claramente ver o software crescendo, crescendo e evoluindo loucamente, como um organismo vivo, irrigado pela IA. Hoje, ela já começou a implantar totalmente esse sistema autoconstruído, extremamente grande e complexo, em todo o departamento comercial da nossa empresa.

Um indivíduo com absolutamente nenhuma formação em programação agora consegue, por conta própria, elevar a complexidade de um software de longo prazo a um nível esmagadoramente alto — isso é um milagre sem precedentes na história da tecnologia humana.

Apresentador Dan Shipper: Outra coisa muito poderosa que você mencionou são os fluxos de trabalho dinâmicos; pode explicar mais sobre isso?

Mike Krieger:

Nós frequentemente desenvolvemos internamente ferramentas avançadas como essa, e eu fico pressionando os engenheiros que as criam no escritório: "Quando essa ferramenta será lançada oficialmente?" Às vezes, devido a limitações de infraestrutura básica, só é possível usá-la internamente por enquanto, mas estamos fazendo todo o possível para levar essas jóias ao mercado o mais rápido possível. Para mim, o fluxo de trabalho dinâmico é absolutamente um dos que impressionarão o mundo.

Existem duas grandes razões pelas quais modelos como o Fable são particularmente poderosos. A primeira é que ele pode ajudá-lo a criar estruturas para trabalhos profundos e significativos. A coisa mais louca que fiz com ele foi entregar diretamente ao Fable um projeto Python interno bastante complexo e pedir que ele reestruturasse inteiramente um conjunto completo de negócios principais na versão TypeScript — tínhamos uma consideração muito específica de implantação online naquela época.

Na época, quando estávamos no Instagram, a alta administração também discutiu seriamente: "Devemos reescrever todo o código base do IG na linguagem Hack para integrá-lo perfeitamente à infraestrutura do Facebook?" Nossa conclusão na época foi: de jeito nenhum, isso não é viável na prática.

Mas apenas no fim de semana passado, diante de um repositório de código-base igualmente complexo, eu simplesmente enviei um fluxo de trabalho dinâmico em segundo plano e fui aproveitar o fim de semana. Defini para ele o seguinte fluxo: compreender profundamente o código existente, gerar um documento detalhado, semelhante a uma especificação, explicando como tudo funciona, depois traduzir módulo por módulo, testar incrementalmente, realizar validações adversariais e verificar itens omitidos. Quando voltei na segunda-feira, liguei o computador e vi o milagre — ele já havia transformado tudo em um sistema totalmente novo rodando na cadeia de ferramentas TypeScript e Bun, e, em alguns níveis arquiteturais, ele até superou minha versão original em Python em elegância e velocidade.

Outra razão mais atraente a longo prazo é que, com a adoção de fluxos de trabalho dinâmicos, em um futuro próximo, poderemos distribuir seamlessmente tarefas filhas de diferentes níveis de dificuldade para梯队 de modelos correspondentes em complexidade.

Apresentador Dan Shipper: Para quem nunca usou, me conte como você criou esse fluxo de trabalho. Como você o projetou? Como garantiu que ele fosse bom?

Mike Krieger:

Todo o processo de treinamento é, na verdade, repleto de um prazer iterativo tipicamente geek. No início, apenas abri o Claude Code e disse: "Irmão, tenho agora um projeto de refatoração extremamente complicado — vamos começar criando juntos um fluxo de trabalho totalmente automatizado."

Ele me mostrou o plano, e eu disse: "Isso está bem próximo, mas preciso de três a quatro camadas adicionais de validação para verificar funcionalidades omitidas." Então ele respondeu: "Este é o seu plano. Está pronto?" O fluxo de trabalho é expresso em código, e acho isso extremamente valioso — você pode ver exatamente como ele pretende proceder.

Após a conclusão da portabilidade completa, tenho algumas pequenas ajustes subsequentes, que vou tratar como mini fluxos de trabalho, continuando a partir da saída do fluxo de trabalho anterior. Isso retorna à questão: o chat é a interface correta? O fluxo de trabalho é um bom ponto intermediário: você usa o chat para orquestrá-lo, mas ele é expresso em código e executado em uma interface limpa, mostrando passo a passo o que está acontecendo. Acho que, no futuro, usaremos abordagens semelhantes para conectar trabalhos de longo prazo ao chat.

Organizado e compilado por Shenchao TechFlow