00:00:00(música animada)
00:00:02- Olá pessoal, como vocês estão?
00:00:23É um prazer estar aqui, eu sou o Dex.
00:00:25Como disseram naquela ótima introdução,
00:00:27tenho trabalhado com agentes de IA há um tempo.
00:00:29Nossa palestra, "12-Factor Agents", no AI Engineer em junho,
00:00:32foi uma das mais assistidas de todos os tempos.
00:00:34Acho que ficou no top oito ou algo assim,
00:00:35uma das melhores do evento de junho.
00:00:38Posso ou não ter dito algo sobre engenharia de contexto.
00:00:41Por que estou aqui hoje e sobre o que vim falar?
00:00:44Quero falar sobre uma das minhas palestras favoritas
00:00:46do AI Engineer de junho,
00:00:47e eu sei que todos vimos a atualização do Igor ontem,
00:00:49mas não me deixaram mudar meus slides,
00:00:50então falarei sobre o que o Igor abordou em junho.
00:00:54Basicamente, eles pesquisaram 100.000 desenvolvedores
00:00:56de empresas de todos os tamanhos,
00:00:58e descobriram que, na maioria das vezes,
00:01:00ao usar IA para engenharia de software,
00:01:01você acaba refazendo muito trabalho e gerando rotatividade no código.
00:01:04E ela não funciona muito bem para tarefas complexas
00:01:07em bases de código legadas.
00:01:08Como podem ver no gráfico, basicamente,
00:01:10você está entregando muito mais,
00:01:11mas boa parte disso é apenas refazer o "lixo"
00:01:14que você entregou na semana passada.
00:01:15E por outro lado,
00:01:18se você estiver fazendo algo do zero, um painel simples no Vercel,
00:01:21algo desse tipo, aí funciona muito bem.
00:01:25Mas se for mexer em um código Java de 10 anos atrás,
00:01:28talvez nem tanto.
00:01:29E isso condizia com a minha experiência.
00:01:30Pessoalmente, e conversando com muitos fundadores
00:01:32e ótimos engenheiros, há muita sujeira no código,
00:01:35fábricas de dívida técnica; não vai funcionar na nossa base.
00:01:37Talvez algum dia, quando os modelos melhorarem.
00:01:40Mas é disso que trata a engenharia de contexto.
00:01:42Como podemos tirar o máximo dos modelos atuais?
00:01:44Como gerenciamos nossa janela de contexto?
00:01:46Falamos sobre isso em agosto.
00:01:48Preciso confessar uma coisa.
00:01:49A primeira vez que usei o Claude Code, não fiquei impressionado.
00:01:53Pensei: "Ok, é um pouco melhor, entendi, gosto da interface".
00:01:54Mas, desde então, nossa equipe descobriu algo
00:01:56que nos permitiu alcançar
00:01:59duas a três vezes mais produtividade.
00:02:01E estávamos entregando tanto que não tivemos escolha
00:02:02a não ser mudar a forma como colaboramos.
00:02:06Reformulamos tudo sobre como construímos software.
00:02:07Éramos uma equipe de três, levou oito semanas e foi muito difícil.
00:02:11Mas agora que resolvemos, nunca mais voltaremos atrás.
00:02:12Essa é a questão de eliminar o código de má qualidade.
00:02:14Acho que chegamos a algum lugar com isso.
00:02:16O assunto viralizou no Hacker News em setembro.
00:02:18Temos milhares de pessoas que foram ao GitHub
00:02:20e pegaram nosso sistema de prompt "Pesquisa-Plano-Implementação".
00:02:23Os objetivos aqui, aos quais chegamos meio que sem querer,
00:02:25são: precisamos de uma IA que funcione bem em bases de código legadas.
00:02:28Que consiga resolver problemas complexos.
00:02:31Sem mais lixo no código, certo?
00:02:35E precisávamos manter o alinhamento mental.
00:02:38Vou falar um pouco mais sobre
00:02:40o que isso significa em um minuto.
00:02:42E claro, como em tudo, queremos gastar
00:02:43o máximo de tokens possível.
00:02:44O que podemos delegar de forma significativa para a IA
00:02:46é realmente muito importante.
00:02:47É um ganho de produtividade enorme.
00:02:50Então, isto é engenharia de contexto avançada para agentes de código.
00:02:52Vou começar contextualizando isso.
00:02:53A forma mais ingênua de usar um agente de código
00:02:56é pedir algo e depois dizer por que está errado
00:02:58e ir corrigindo, pedindo e pedindo
00:03:01até que o contexto acabe, você desista ou comece a chorar.
00:03:03Podemos ser um pouco mais espertos que isso.
00:03:05A maioria das pessoas descobre logo cedo
00:03:09em suas explorações com IA que pode ser melhor,
00:03:11se uma conversa sair do trilho,
00:03:13simplesmente abrir uma nova janela de contexto.
00:03:17Você diz: "Ok, fomos por aquele caminho, vamos recomeçar".
00:03:21Mesmo prompt, mesma tarefa.
00:03:24Mas desta vez, vamos seguir por este caminho.
00:03:25E não vá por ali, porque aquilo não funciona.
00:03:26Então, como saber quando é hora de recomeçar?
00:03:27Se você ver isto,
00:03:29(plateia ri)
00:03:31provavelmente é hora de recomeçar, certo?
00:03:34É isso que o Claude diz quando você avisa que ele está errando.
00:03:37Mas podemos ser ainda mais inteligentes.
00:03:39Podemos fazer o que eu chamo de compactação intencional.
00:03:41Basicamente, esteja você no caminho certo ou não,
00:03:45você pode pegar sua janela de contexto atual
00:03:47e pedir ao agente para resumi-la em um arquivo Markdown.
00:03:50Você revisa, adiciona tags e,
00:03:53quando o novo agente começar,
00:03:56ele vai direto ao trabalho em vez de ter que fazer
00:03:59toda aquela busca e compreensão da base de código
00:04:00para se atualizar.
00:04:02O que entra na compactação?
00:04:04A questão é: o que ocupa espaço
00:04:05na sua janela de contexto?
00:04:07Ele busca arquivos, entende o fluxo do código,
00:04:09edita arquivos, gera saídas de testes e builds.
00:04:11E se você tiver um daqueles MCPs jogando JSON
00:04:13e um monte de UUIDs no seu contexto,
00:04:17que Deus te ajude.
00:04:20Então, o que devemos compactar?
00:04:22Vou entrar em detalhes específicos aqui,
00:04:25mas isto é uma compactação muito boa.
00:04:26Isto é exatamente no que estamos trabalhando:
00:04:28os arquivos exatos e os números das linhas
00:04:30que importam para o problema que estamos resolvendo.
00:04:31Por que somos tão obcecados por contexto?
00:04:33Porque os LLMs — e já fui criticado no YouTube por isso —
00:04:34não são funções puras pois são não-determinísticos,
00:04:37mas eles são "stateless", sem estado.
00:04:39E a única forma de obter melhor desempenho de um LLM
00:04:42é inserindo tokens melhores,
00:04:45para então obter tokens melhores na saída.
00:04:46A cada iteração do loop,
00:04:49o Claude, ou qualquer agente de código, escolhe a próxima ferramenta.
00:04:51Pode haver centenas de próximos passos certos
00:04:52e centenas de passos errados.
00:04:53Mas a única coisa que influencia o que vem a seguir
00:04:55é o que está na conversa até agora.
00:04:56Portanto, vamos otimizar essa janela de contexto
00:04:58para precisão, completude, tamanho
00:05:00e um pouco de trajetória.
00:05:03A questão da trajetória é interessante
00:05:05porque muita gente diz:
00:05:07"Mandei o agente fazer algo
00:05:10e ele fez errado.
00:05:11Aí eu corrigi, dei uma bronca nele
00:05:12e ele errou de novo.
00:05:13Aí xinguei de novo."
00:05:16E o LLM olha para essa conversa e diz: "Beleza, eu errei,
00:05:17o humano gritou comigo, eu errei de novo
00:05:18e o humano gritou comigo de novo".
00:05:20Então, o próximo token mais provável nessa conversa é:
00:05:21"É melhor eu errar de novo
00:05:23para o humano poder gritar comigo mais uma vez".
00:05:24Portanto, cuidado com a sua trajetória.
00:05:25Para inverter isso,
00:05:26a pior coisa é ter informação incorreta,
00:05:29depois informação faltando e, por fim, excesso de ruído.
00:05:31Se você gosta de equações, tem uma equação simples
00:05:33se quiser pensar dessa forma.
00:05:35Jeff Huntley pesquisou muito sobre agentes de código.
00:05:36Ele definiu muito bem:
00:05:39quanto mais você usa a janela de contexto,
00:05:42piores serão os resultados.
00:05:44Isso leva a um conceito.
00:05:47Um conceito acadêmico muito profundo chamado "zona burra".
00:05:51Você tem sua janela de contexto.
00:05:51Tem cerca de 168.000 tokens.
00:05:53Alguns são reservados para saída e compactação.
00:05:55Isso varia por modelo,
00:05:56mas usamos o Claude Code como exemplo aqui.
00:05:59Perto da linha dos 40% é onde você começará
00:06:01a ver retornos decrescentes, dependendo da tarefa.
00:06:03Se você tiver MCPs demais nos seus agentes de código,
00:06:05estará fazendo todo o trabalho na zona burra
00:06:07and nunca terá bons resultados.
00:06:09As pessoas já falaram disso.
00:06:10Não vou me alongar nesse ponto.
00:06:14Os resultados variam.
00:06:17Os 40% dependem da complexidade da tarefa,
00:06:18mas é uma boa diretriz.
00:06:21Voltando à compactação ou, como chamarei de agora em diante,
00:06:21evitando inteligentemente a zona burra.
00:06:22Podemos usar subagentes.
00:06:23Se você tem um subagente de front-end, um de back-end,
00:06:26um de QA e um de ciência de dados, por favor, pare.
00:06:28Subagentes não servem para personificar cargos.
00:06:31Eles servem para controlar o contexto.
00:06:33O que você pode fazer é: se quiser descobrir
00:06:37como algo funciona em uma base de código grande,
00:06:39pode instruir o agente de código a fazer isso,
00:06:44se ele suportar subagentes,
00:06:47ou você mesmo pode criar seu sistema de subagentes.
00:06:49Basicamente, você diz: "Ei, descubra como isso funciona".
00:06:51E ele pode abrir uma nova janela de contexto
00:06:53que fará toda aquela leitura, busca,
00:06:55análise de arquivos inteiros
00:06:56e compreensão da base de código,
00:06:58para então retornar uma mensagem bem sucinta
00:07:00ao agente principal, tipo:
00:07:03"Ei, o arquivo que você quer está aqui".
00:07:05O agente principal lê só esse arquivo e vai direto ao ponto.
00:07:07Isso é muito poderoso.
00:07:09Se você usar essas ferramentas corretamente,
00:07:13conseguirá boas respostas como esta
00:07:14e gerenciará seu contexto muito bem.
00:07:17O que funciona ainda melhor que subagentes,
00:07:20ou como uma camada sobre eles,
00:07:22é o fluxo que chamo de compactação intencional frequente.
00:07:23Falaremos de Pesquisa-Plano-Implementação em um minuto,
00:07:25mas o ponto é que você está constantemente
00:07:29mantendo sua janela de contexto pequena.
00:07:30ou uma camada acima dos subagentes
00:07:32é um fluxo de trabalho que chamo de compactação intencional frequente.
00:07:35Vamos falar sobre pesquisar, planejar e implementar em um minuto,
00:07:37mas o ponto é que você está constantemente
00:07:39mantendo sua janela de contexto pequena.
00:07:41Você está construindo todo o seu fluxo em torno da gestão de contexto,
00:07:45então ele vem em três fases: pesquisar, planejar, implementar,
00:07:48e vamos tentar permanecer na "zona inteligente" o tempo todo.
00:07:51A pesquisa serve para entender
00:07:53como o sistema funciona, achar o arquivo certo e manter a objetividade.
00:07:55Mantendo-se objetivo.
00:07:56Aqui está um prompt que você pode usar para pesquisar.
00:07:58Aqui está o resultado de um prompt de pesquisa.
00:08:00Todos estes são de código aberto.
00:08:01Você pode pegá-los e testar por conta própria.
00:08:04No planejamento, você vai delinear os passos exatos.
00:08:06Você vai incluir nomes de arquivos e trechos de linhas.
00:08:08Você será muito explícito sobre como vamos testar as coisas
00:08:10após cada mudança.
00:08:11Aqui está um bom prompt de planejamento.
00:08:12Aqui está um dos nossos planos.
00:08:13Ele contém trechos de código reais.
00:08:16E então vamos implementar.
00:08:17E se você ler um desses planos,
00:08:17verá facilmente como até o modelo mais simples do mundo
00:08:20provavelmente não vai estragar tudo.
00:08:23Então, apenas seguimos e executamos o plano
00:08:24mantendo o contexto baixo.
00:08:26Sobre o prompt de planejamento, como eu disse,
00:08:27é a parte menos emocionante do processo.
00:08:30Eu quis colocar isso em prática.
00:08:31Trabalhando conosco, eu faço um podcast com meu amigo Vaibhav,
00:08:34que é o CEO de uma empresa chamada Boundary ML.
00:08:37E eu disse: "Ei, vou tentar corrigir de primeira
00:08:39sua base de código em Rust de 300.000 linhas
00:08:41para uma linguagem de programação".
00:08:42E o episódio inteiro mostra isso.
00:08:45Dura cerca de uma hora e meia.
00:08:46Não vou detalhar tudo agora,
00:08:47mas fizemos várias pesquisas
00:08:48e depois as descartamos porque estavam ruins.
00:08:49Fizemos um plano sem pesquisa e outro com pesquisa
00:08:51e comparamos todos os resultados.
00:08:53Foi divertido.
00:08:54Isso foi na segunda à noite.
00:08:55Na terça de manhã, estávamos no programa
00:08:57e o CTO tinha visto o PR
00:08:59sem perceber que eu estava fazendo aquilo para o podcast.
00:09:03E basicamente ele disse: "Sim, parece bom.
00:09:04Vamos incluir na próxima versão".
00:09:05Ele ficou um pouco confuso.
00:09:08Aqui está o plano.
00:09:09Mas enfim, sim, confirmado.
00:09:12Funciona em bases de código legadas e sem erros bobos.
00:09:14Mas eu queria ver se podíamos resolver problemas complexos.
00:09:17O Vaibhav ainda estava um pouco cético.
00:09:19Nós nos sentamos por umas sete horas num sábado
00:09:21e enviamos 35.000 linhas de código para o BAML.
00:09:24Um dos PRs foi aceito uma semana depois.
00:09:26Devo dizer que parte disso é geração de código.
00:09:28Você atualiza seu comportamento,
00:09:29todos os arquivos de referência são atualizados e tal,
00:09:31mas enviamos muito código naquele dia.
00:09:33Ele estima que fizemos o trabalho de uma a duas semanas em sete horas.
00:09:36E isso é legal, podemos resolver problemas complexos.
00:09:40Existem limites para isso.
00:09:41Eu me sentei com meu amigo Blake.
00:09:42Tentamos remover as dependências do Hadoop do Parquet Java.
00:09:46Se você sabe o que é Parquet Java,
00:09:47sinto muito pelo que quer que tenha acontecido
00:09:50para você chegar a esse ponto na carreira.
00:09:53Não correu bem.
00:09:55Aqui estão os planos, aqui está a pesquisa.
00:09:57A certa altura, jogamos tudo fora
00:09:58e voltamos para o quadro branco.
00:10:00Tivemos que, de fato, após aprendermos
00:10:01onde estavam todas as armadilhas,
00:10:03voltar ao ponto de: ok,
00:10:05como isso vai se encaixar de verdade?
00:10:06E isso me traz a um ponto muito interessante
00:10:09que o Jake vai abordar mais tarde.
00:10:11Não terceirize o pensamento.
00:10:13A IA não pode substituir o raciocínio.
00:10:14Ela só pode ampliar o pensamento que você teve
00:10:17ou a falta dele.
00:10:19As pessoas perguntam: "Então, Dex,
00:10:21isso é desenvolvimento orientado por especificações, certo?"
00:10:23Não, o desenvolvimento orientado por especificações está quebrado.
00:10:27Não a ideia, mas o termo.
00:10:30Ele não é bem definido.
00:10:33Esta é a Brigetta, da ThoughtWorks.
00:10:35E muita gente diz apenas "especificação"
00:10:37querendo dizer apenas um prompt mais detalhado.
00:10:39Alguém se lembra desta imagem?
00:10:41Alguém sabe de onde ela é?
00:10:43Tudo bem, essa é uma referência antiga.
00:10:44Nunca haverá o "ano dos agentes"
00:10:46por causa da difusão semântica.
00:10:47Martin Fowler disse isso em 2006.
00:10:49Criamos um bom termo com uma boa definição,
00:10:52e então todo mundo fica empolgado
00:10:53e cada um começa a dar um significado diferente,
00:10:56até que o termo se torna inútil.
00:10:59Tivemos agente como pessoa, agente como microsserviço,
00:11:02agente como chatbot, agente como fluxo de trabalho.
00:11:05E obrigado, Simon.
00:11:06Voltamos ao início.
00:11:07Um agente é apenas ferramentas em um loop.
00:11:09Isso está acontecendo com o desenv. orientado por especificações.
00:11:11Eu costumava usar o slide do Sean no início desta palestra,
00:11:15mas isso fazia muitas pessoas
00:11:15focarem nas coisas erradas.
00:11:17A ideia dele de "esqueça o código, agora é como Assembly"
00:11:19e focar apenas no Markdown.
00:11:21É uma ideia legal, mas as pessoas dizem que o desenv. orientado por specs
00:11:24é escrever um prompt melhor ou um documento de requisitos.
00:11:26Às vezes é usar loops de feedback verificáveis
00:11:28e contrapressão.
00:11:30Talvez seja tratar o código como Assembly,
00:11:32como o Sean nos ensinou.
00:11:34Mas para muitos, é só usar vários arquivos Markdown
00:11:36enquanto você programa.
00:11:37Ou o meu favorito, que descobri semana passada:
00:11:39uma especificação é a documentação de uma biblioteca aberta.
00:11:43Então, já era.
00:11:44O desenv. orientado por specs está saturado, é inútil agora.
00:11:48Ele sofreu difusão semântica.
00:11:49Então eu quis falar sobre quatro coisas
00:11:52que realmente funcionam hoje, os passos táticos e práticos
00:11:55que vimos funcionar internamente e com vários usuários.
00:11:59Fazemos a pesquisa e entendemos como o sistema funciona.
00:12:02Lembram do filme "Amnésia"?
00:12:03É o melhor filme sobre engenharia de contexto,
00:12:05como diz o Peter.
00:12:07O cara acorda sem memória,
00:12:09tem que ler as próprias tatuagens para saber quem é
00:12:11e o que está fazendo.
00:12:12Se você não orientar seus agentes, eles vão inventar coisas.
00:12:17E aqui está sua equipe, isso é bem simplificado
00:12:19para a maioria de vocês.
00:12:19Muitos têm organizações bem maiores que esta.
00:12:21Mas digamos que você queira fazer um trabalho aqui.
00:12:23Uma coisa que você pode fazer é colocar a orientação
00:12:26em cada repositório.
00:12:27Você coloca um monte de contexto.
00:12:28Aqui está o repo, aqui está como ele funciona.
00:12:29Isso é uma compressão de todo o contexto da base de código
00:12:32que o agente pode ver antecipadamente
00:12:34antes de começar a trabalhar.
00:12:36Isso é desafiador porque às vezes fica longo demais.
00:12:39Conforme sua base de código cresce,
00:12:41ou você deixa esse arquivo maior,
00:12:43ou precisa omitir informações.
00:12:45E assim, enquanto você lê isso,
00:12:48você vai ler o contexto
00:12:49desse monorepo gigante de cinco milhões de linhas
00:12:52e vai gastar toda a sua "zona inteligente"
00:12:53só para aprender como funciona, e não vai conseguir
00:12:55fazer boas chamadas de ferramentas na "zona burra".
00:12:57Então, você pode fragmentar isso na estrutura.
00:13:02Eles estão falando apenas sobre divulgação progressiva.
00:13:04Você poderia dividir isso, certo?
00:13:05Poderia colocar um arquivo na raiz de cada repositório
00:13:08e então, em cada nível, ter contexto adicional
00:13:11baseado em: se você está trabalhando aqui,
00:13:13isso é o que você precisa saber.
00:13:15Não documentamos os arquivos em si,
00:13:17porque eles são a fonte da verdade.
00:13:18Mas então, enquanto seu agente trabalha,
00:13:19você puxa o contexto da raiz
00:13:21e depois puxa o subcontexto.
00:13:22Não falaremos de nada específico,
00:13:23você poderia usar CloudMD para isso,
00:13:24poderia usar Hoax, o que for.
00:13:26Mas assim você ainda tem espaço na "zona inteligente"
00:13:28porque está trazendo apenas o necessário.
00:13:31O problema é que isso fica desatualizado.
00:13:33E assim, cada vez que você lança um novo recurso,
00:13:35você precisa validar o cache
00:13:38e reconstruir partes dessa documentação interna.
00:13:42E você poderia usar bastante IA
00:13:43para tornar essa atualização parte do seu processo.
00:13:46Por que não faço uma pergunta?
00:13:48Entre o código real, os nomes das funções,
00:13:50os comentários e a documentação,
00:13:51alguém quer adivinhar o que está no eixo Y deste gráfico?
00:13:57- Lixo. - Lixo.
00:13:58Na verdade, é a quantidade de mentiras que você encontra
00:14:01em qualquer parte da sua base de código.
00:14:03Você poderia incluir a atualização disso no seu processo,
00:14:06mas provavelmente não deveria, porque provavelmente não o fará.
00:14:08O que preferimos é o contexto comprimido sob demanda.
00:14:11Se estou criando um recurso relacionado a provedores SCM,
00:14:14JIRA e Linear,
00:14:15eu apenas daria um pouco de orientação.
00:14:17Eu diria: "Ei, vamos mexer
00:14:18nesta parte específica da base de código"
00:14:21e um bom prompt de pesquisa ou comando
00:14:24poderia usar sua habilidade,
00:14:27lançar subagentes para analisar essas fatias verticais
00:14:30pelo código e, em seguida, criar um documento de pesquisa
00:14:33que seja apenas um recorte do que é realmente real,
00:14:35baseado no próprio código, nas partes da base que importam.
00:14:39Estamos compactando a verdade.
00:14:41Planejamento é alavancagem.
00:14:43Planejar é sobre a compactação da intenção.
00:14:45E no plano, vamos delinear os passos exatos.
00:14:48Pegamos nossa pesquisa e nosso PRD, ou nosso ticket de bug,
00:14:50ou o que quer que seja.
00:14:52Criamos um plano e um arquivo de plano.
00:14:54Portanto, estamos compactando novamente.
00:14:55E quero fazer uma pausa para falar sobre alinhamento mental.
00:14:58Alguém sabe para que serve a revisão de código?
00:15:00Alinhamento mental, alinhamento mental.
00:15:05É sobre garantir que as coisas estejam corretas e tudo mais.
00:15:08Mas o mais importante é: como manter todos
00:15:10da equipe na mesma página
00:15:11sobre como a base de código está mudando e por quê?
00:15:14E eu consigo ler mil linhas de Golang toda semana.
00:15:17Desculpe, eu não consigo ler mil.
00:15:18É difícil, mas eu consigo.
00:15:19Eu só não quero.
00:15:20E conforme nossa equipe cresce, todo o código é revisado.
00:15:23Nós não deixamos de ler o código.
00:15:24Mas eu, como líder técnico da equipe,
00:15:27posso ler os planos e me manter atualizado.
00:15:29E isso é o suficiente.
00:15:30Consigo detectar alguns problemas cedo
00:15:32e mantenho a compreensão de como o sistema está evoluindo.
00:15:35Mitchell fez um post muito bom
00:15:36sobre como ele tem colocado seus tópicos do AMP
00:15:38em seus pull requests para que você veja não apenas
00:15:41um monte de texto verde no GitHub,
00:15:43mas os passos exatos, os prompts,
00:15:44e o fato de que ele rodou a build no final e ela passou.
00:15:46Isso leva o revisor por uma jornada
00:15:49de uma forma que um PR no GitHub simplesmente não consegue.
00:15:51E conforme você entrega cada vez mais,
00:15:52duas a três vezes mais código,
00:15:54cabe a você encontrar maneiras de manter sua equipe
00:15:57na mesma página e mostrar os passos que você seguiu
00:16:00e como testou isso manualmente.
00:16:01Seu objetivo é alavancagem, então você quer alta confiança
00:16:04de que o modelo realmente fará a coisa certa.
00:16:06Eu não consigo ler este plano e saber o que realmente
00:16:08vai acontecer e quais mudanças de código ocorrerão.
00:16:11Então, com o tempo, evoluímos para planos que incluem
00:16:14trechos reais do código que será alterado.
00:16:17Portanto, seu objetivo é alavancagem.
00:16:18Você quer compactação da intenção
00:16:19e quer uma execução confiável.
00:16:22E, bem, eu tenho formação em física.
00:16:23Gostamos de traçar linhas pelo centro de picos e curvas.
00:16:28À medida que seus planos ficam mais longos, a confiabilidade sobe,
00:16:30mas a legibilidade desce.
00:16:31Existe um ponto ideal para você, sua equipe
00:16:33e sua base de código; você deve tentar encontrá-lo.
00:16:35Porque quando revisamos a pesquisa e os planos,
00:16:37se eles forem bons, conseguimos o alinhamento mental.
00:16:40Não terceirize o raciocínio.
00:16:42Já disse isso antes: isso não é mágica.
00:16:44Não existe o prompt perfeito.
00:16:46Simplesmente não funcionará se você não ler o plano.
00:16:50Por isso, construímos todo o nosso processo para que você, o criador,
00:16:53esteja nessa interação com o agente,
00:16:55lendo os planos conforme eles são criados.
00:16:56E então, se precisar de uma revisão por pares,
00:16:58você pode enviar para alguém e perguntar:
00:16:58"Ei, este plano parece certo?"
00:17:00"Esta é a abordagem correta?"
00:17:00"Esta é a ordem certa para analisar essas coisas?"
00:17:03O Jake também escreveu um post muito bom sobre
00:17:05o que torna valioso o ciclo pesquisar-planejar-implementar:
00:17:07é você, o humano no controle, garantindo que esteja correto.
00:17:11Se você levar apenas uma coisa desta palestra,
00:17:14que seja: uma linha de código ruim é uma linha de código ruim.
00:17:17E uma parte ruim de um plano pode virar 100 linhas ruins.
00:17:22E uma linha de pesquisa ruim, como um mal-entendido
00:17:25de como o sistema funciona ou de onde as coisas estão,
00:17:27vai arruinar tudo.
00:17:29Você estará enviando o modelo na direção errada.
00:17:31Por isso, ao trabalhar internamente e com usuários,
00:17:34tentamos constantemente mover o esforço e o foco humano
00:17:36para as partes de maior alavancagem deste fluxo.
00:17:39Não terceirize o raciocínio.
00:17:41Cuidado com ferramentas que apenas cospem
00:17:43um monte de arquivos markdown só para você se sentir bem.
00:17:45Não vou citar nomes aqui.
00:17:47Às vezes, isso é exagero.
00:17:49E a forma como gosto de pensar nisso é tipo:
00:17:51é, você nem sempre precisa de pesquisa-plano-implementação completo.
00:17:54Às vezes você precisa de mais, às vezes de menos.
00:17:56Se você estiver mudando a cor de um botão,
00:17:57apenas fale com o agente e diga o que fazer.
00:18:00Se estiver fazendo um plano simples para uma funcionalidade pequena,
00:18:04ou funcionalidades médias em vários repositórios,
00:18:07então faça uma pesquisa e depois crie um plano.
00:18:09Basicamente, o nível dos problemas que você consegue resolver
00:18:10sobe conforme você aceita fazer mais dessa compactação
00:18:13e dessa engenharia de contexto.
00:18:15E se você estiver em um nível de alta complexidade,
00:18:18provavelmente terá que fazer mais.
00:18:19Muita gente me pergunta: como eu sei
00:18:21quanta engenharia de contexto usar?
00:18:23É preciso prática.
00:18:24Você vai errar, e precisa errar
00:18:26muitas e muitas vezes.
00:18:27Às vezes você vai exagerar, às vezes vai fazer pouco.
00:18:29Escolha uma ferramenta e pratique.
00:18:32Eu não recomendo tentar otimizar tudo entre Claude e Codex
00:18:35e todas essas ferramentas diferentes.
00:18:36Eu não sou muito fã de siglas.
00:18:40Dissemos que o desenvolvimento guiado por specs estava quebrado.
00:18:42Não acho que pesquisar, planejar e implementar serão os passos finais.
00:18:44O importante é a compactação, a engenharia de contexto
00:18:47e manter-se na zona de inteligência.
00:18:48Mas as pessoas estão chamando isso de RPI
00:18:50e não há nada que eu possa fazer a respeito.
00:18:52Portanto, fiquem atentos: não existe prompt perfeito,
00:18:55não existe bala de prata.
00:18:56Se você realmente quer um termo da moda,
00:18:58pode chamar isso de "engenharia de arreio" (harness engineering),
00:19:00que faz parte da engenharia de contexto
00:19:01e trata de como você se integra aos pontos de conexão
00:19:03no Codex, Claude, Cursor ou o que for,
00:19:05e como você customiza sua base de código.
00:19:07Então, o que vem a seguir?
00:19:11Acho que as ferramentas de agentes de codificação
00:19:12vão se tornar commodities.
00:19:13As pessoas vão aprender a usá-las e vão melhorar nisso.
00:19:15E a parte difícil será como adaptar sua equipe
00:19:17e seu fluxo de trabalho no ciclo de vida de software
00:19:21para funcionar em um mundo onde 99% do código é feito por IA.
00:19:24E se você não conseguir descobrir isso, você está perdido.
00:19:26Porque está surgindo um certo distanciamento,
00:19:27onde engenheiros experientes não adotam IA
00:19:29porque ela não os torna tão mais rápidos assim,
00:19:31enquanto engenheiros iniciantes e plenos usam muito
00:19:33porque ela preenche lacunas de habilidade,
00:19:35mas também produz um pouco de código malfeito,
00:19:36e os engenheiros seniores odeiam isso cada vez mais
00:19:38porque passam a semana limpando a sujeira
00:19:40que foi entregue pelo Cursor na semana anterior.
00:19:42A culpa não é da IA,
00:19:44nem do engenheiro de nível médio.
00:19:46Mudança cultural é muito difícil
00:19:48e precisa vir de cima para funcionar.
00:19:50Então, se você é um líder técnico na sua empresa,
00:19:52escolha uma ferramenta e comece a praticar.
00:19:54Se você quiser ajudar, estamos contratando,
00:19:56estamos construindo uma IDE agente para ajudar equipes
00:19:59a acelerar a jornada rumo aos 99% de código gerado por IA.
00:20:03Adoraríamos conversar se você quiser trabalhar conosco.
00:20:06Acesse nosso site, envie um e-mail,
00:20:08ou venha falar comigo aqui no corredor.
00:20:09Muito obrigado a todos pela energia.
00:20:11(público aplaude)
00:20:13(música eletrônica animada)