Como Fazer sua Organização Adotar Agentes de Código (Sem Entregar Lixo) — Eyal Blum, Figma
AAI Engineer
Computing/SoftwareManagement
Transcript
00:00:00Eyal Blam: Boa tarde, meu nome é Eyal Blam, sou engenheiro de software na Figma, e
00:00:17na minha palestra de hoje, vamos falar sobre como adaptamos ou estamos adaptando agentes
00:00:25ao nosso fluxo de trabalho na Figma, mantendo alta qualidade em nossa base de código.
00:00:32Como devem saber, a Figma é o editor baseado em navegador onde design, engenharia e agora
00:00:40agentes de IA colaboram juntos para entregar código.
00:00:44Esta Figma passou por uma forte transição, deixando de ser uma ferramenta tradicional para se tornar uma ferramenta voltada para IA,
00:00:52mas nesta palestra não vou falar sobre o nosso produto, vou falar mais sobre a nossa
00:00:55organização interna e como nossa organização de engenharia tem adaptado agentes de IA.
00:01:04E o que percebemos internamente, tanto em organizações, empresas quanto em indivíduos, é que há
00:01:11um processo de adoção de IA em três atos.
00:01:16Você começa testando algo, assim como muitas pessoas nesta sala que
00:01:21são super adeptas da IA e a usam há algum tempo; pegaram algo e conseguiram
00:01:27fazer coisas simples funcionarem muito bem, 10 vezes mais rápido.
00:01:30Depois, você passa a aplicar essas mesmas práticas a problemas maiores e a IA falha bastante nisso, gera conteúdos ruins,
00:01:40muitos bugs.
00:01:41A confiança que você havia construído desmorona e, a partir desse ponto, você começa a desenvolver a habilidade real, que é
00:01:50aprender a usar a IA corretamente, estabelecendo as barreiras de proteção adequadas, o direcionamento certo,
00:01:55o contexto correto e tudo o que viemos discutindo o dia todo aqui em todas as palestras para realmente desenvolver uma habilidade sólida.
00:02:02E algo que acontece internamente conforme adotamos isso, seja em equipes ou indivíduos, é que a adoção é desigual.
00:02:12Temos equipes que são muito avançadas em IA e já transformaram seus fluxos de trabalho inteiros, e temos equipes que ainda estão experimentando no primeiro ato ou perderam a confiança, e todas precisam trabalhar juntas para entregar nosso produto.
00:02:28Portanto, elas precisam coexistir na organização e precisamos encontrar uma maneira de apoiá-las, trazendo todos nessa jornada e levando cada um ao terceiro ato da história.
00:02:44Além desse ponto de atrito principal, também notamos outros pontos de atrito que surgem à medida que adotamos a IA.
00:02:54Algo que ouvimos com frequência dos desenvolvedores e que os gestores têm notado é que a redução da autonomia faz com que os engenheiros percam parte da satisfação no trabalho.
00:03:04Muitas pessoas costumavam sentir muito orgulho e prazer em escrever código e entrar no estado de fluxo, e muitas sentem que isso foi perdido ou estão perdendo grande parte desse elemento, entrando em um ciclo de comandos em que apenas aguardam a saída da IA e conversam com ela, o que não é tão divertido quanto costumava ser.
00:03:22Notamos outra coisa interessante: nossos melhores engenheiros querem reter todo o contexto em suas cabeças e acabam sofrendo com essa carga, e o que acaba acontecendo é que eles sabem onde estão todas as armadilhas, mantêm unidas com fita adesiva mental todas as áreas onde os agentes não funcionam bem e evitam que as coisas realmente ruins entrem, ou possuem todo o contexto institucional que nunca
00:03:52foi escrito e fica apenas na cabeça deles, acumulando tanto peso que se tornam gargalos e ficam muito frustrados, acabando por demorar mais para adotar a tecnologia porque veem todos os problemas de primeira mão.
00:04:04Esse é outro grande problema que temos visto, e tenho certeza de que todos aqui vão se identificar: de repente, todos os documentos de design, mensagens no Slack e e-mails ficaram três ou quatro vezes mais longos, passamos a receber duas ou três vezes mais e-mails, e eles dizem basicamente a mesma coisa que antes.
00:04:28Portanto, a comunicação tornou-se bastante ineficiente, e distinguir o que é de alta qualidade e importante do que não é tornou-se um desafio complexo.
00:04:40Vou passar os próximos minutos falando sobre algumas das lições que aprendemos e como temos tentado aplicá-las.
00:04:50Esta é uma jornada da qual ainda não saímos do outro lado, mas temos visto avanços muito interessantes em várias dessas frentes.
00:04:57Acho que muitos dos palestrantes aqui tocaram nisso, mas investir em verificação é provavelmente a coisa de maior valor que podemos fazer em nossa base de código.
00:05:11Sempre que pudermos antecipar algo em nosso fluxo de trabalho, passando a responsabilidade de um humano para um agente capaz de verificá-lo.
00:05:19Por exemplo, quando o Playwright MCP foi lançado, em vez de fazer os humanos navegarem pelo código, agora o agente pode explorá-lo, o que foi um enorme ganho de produtividade para muitas de nossas equipes.
00:05:33Isso é realmente, isso é sempre uma grande vitória para nós.
00:05:37A outra coisa, ainda melhor, é que quando você descobre algo que o agente considerou útil, reserve um tempo para pegar isso e codificá-lo em um fluxo determinístico.
00:05:51Um fluxo determinístico que possa ser repetido facilmente economiza tokens e tempo, garantindo que você use o LLM quando ele realmente precisar raciocinar.
00:06:01Mas quando você tem algo que já é conhecido e pode ser essencialmente transformado em um teste, gastar esse tempo sempre traz retornos.
00:06:11E outra dica: se você instruir suas habilidades ou seu agente a escrever o código que você está desenvolvendo no estilo TDD, indo do vermelho ao verde, isso quase sempre trará melhores resultados.
00:06:26Porque você define um objetivo e depois instrui o agente a trabalhar em direção a ele.
00:06:30Isso quase sempre gerará resultados melhores ao escrever o código e depois os testes, pois assim ele adequará o teste ao código em vez de tentar ajustar o código para passar nos critérios de verificação.
00:06:42E esta é a pirâmide de testes, a clássica pirâmide de testes anterior, considerando os próprios testes, como os testes de ponta a ponta, de integração e unitários.
00:06:54O movimento ideal aqui é transferir o máximo possível para a análise determinística, como linters, o compilador e os próprios testes unitários; o que puder ser coberto facilmente, você pode delegar para um agente revisar com base em critérios.
00:07:12E padrões arquiteturais que foram.
00:07:15E padrões arquiteturais que foram facilmente codificados na base de código podem ser movidos para o agente.
00:07:19E então, apenas no topo, você precisa ter algum tipo de revisão humana, geralmente voltada para a funcionalidade, garantindo que isso é a coisa certa a ser construída e deixando para o humano apenas o que exige a participação humana.
00:07:31Outro ponto extremamente importante é o planejamento versus o uso de comandos, o que está profundamente ligado a devolver a autonomia aos desenvolvedores e encontrar um substituto para o ofício de programar.
00:07:50Portanto, dedicar bastante tempo à elaboração do plano e depois enviá-lo ao agente como uma implementação que pode ser feita automaticamente é algo que percebemos que realmente resgata o prazer de construir de volta ao processo.
00:08:07Dessa forma, não é incomum passar uma semana escrevendo planos muito detalhados, tomando todas as decisões, refinando-as, iterando e enviando para os colegas de equipe revisarem.
00:08:17E somente quando estiver pronto e todas as decisões estiverem consolidadas, você o envia para o agente, que o devolverá implementado.
00:08:26Isso tem sido muito bem-sucedido tanto para acelerar o processo quanto para restaurar parte da alegria no desenvolvimento.
00:08:36E o que constitui um bom plano? É fundamental começar com o 'porquê' logo no topo.
00:08:43Isso ajuda muito a evitar o desvio do agente se você incluir uma seção grande e em destaque, semelhante a quando se escreve um documento de design.
00:08:49Você quer colocar o resumo executivo lá para o agente; caso contrário, ele começará a se desviar com o tempo e você deve garantir que o agente não volte atrás para alterar isso só porque quer.
00:08:58Portanto, começamos pelo porquê, garantindo que o plano possa ser dividido em pequenas partes que possam ser verificadas de forma independente.
00:09:08E o meu critério pessoal para saber se o tamanho está bom é pensar se eu gostaria de revisar o PR correspondente àquela parte ou se ele seria grande demais para ser revisado de uma só vez.
00:09:18O teste é: vou precisar pegar uma xícara de café antes de ler isto?
00:09:22Se sim, significa que está grande demais e preciso dividi-lo em pedaços.
00:09:26Além disso, asseguro que cada parte possa ser validada de forma independente, pois o que eu quero evitar é ter cinco etapas em que a primeira é escrita mas não validada, e todo o resto é construído em cima de suposições.
00:09:41Portanto, ter um portão de validação ou critérios de exceção para cada fase ajuda muito a tornar o plano resistente a desvios.
00:09:51Existem vários aspectos técnicos sobre como gerenciar o contexto e construir uma fábrica de software sobre isso.
00:09:58Mas, uma vez que você tem o plano, pode usar o loop ou o fluxo de trabalho que preferir para implementá-lo.
00:10:05Esta é a captura de tela de um plano que peguei aleatoriamente, mas é isto que costumo procurar.
00:10:12O resumo executivo no topo.
00:10:14As fases divididas e, em seguida, entro em muitos detalhes em cada uma para poder fornecê-la a um subagente.
00:10:20E o subagente pode trabalhar nisso de forma independente sem precisar se preocupar com o resto.
00:10:24Há também outros fluxos de trabalho que funcionam ou estruturas alternativas para o plano.
00:10:29Acho que uma das coisas ótimas dos fluxos de trabalho com IA é que cada um pode configurar o que funciona melhor para si.
00:10:41Não, obrigado.
00:10:43Todos podem configurar com muita facilidade o fluxo de trabalho exato que lhes atende.
00:10:47Portanto, há retornos decrescentes em tentar centralizar todo mundo em uma única coisa.
00:10:51Mas, desde que funcione para o fluxo deles e outras pessoas possam iterar junto, vejo que geralmente funciona muito bem.
00:10:58E este é apenas um exemplo, quase exibindo o que pode ser o resultado de um plano.
00:11:04Provavelmente existem uns 20 PRs aqui.
00:11:07Alguns deles devem ter cerca de 10 linhas e outros 100 linhas, mas provavelmente nada maior do que isso.
00:11:12E isso nos permite — no mundo pré-IA, eu provavelmente trabalharia nisso por uma semana.
00:11:19Me alinharia com outras três equipes por mais uma semana e depois enviaria para um agente implementar durante a noite.
00:11:26E ele retornou — isto provavelmente veio de dois planos, não apenas um —, mas são basicamente seis semanas de trabalho de código feitas em apenas uma semana.
00:11:36É daí que tiro a aceleração de 5x.
00:11:40Se eu incluir o ciclo de revisão no final, o que você sempre deve lembrar.
00:11:45Passando do planejamento de volta ao problema que tivemos com os céticos e as pessoas sobrecarregadas com mais trabalho:
00:11:53Certifique-se de trazê-los para perto e levar o feedback deles muito a sério.
00:11:59Eles são céticos porque estão vendo onde falta validação e onde suas ferramentas falham.
00:12:05Portanto, o feedback deles é basicamente o roteiro de como melhorar seu agente e sua interação com a base de código.
00:12:12Apenas certifique-se de integrá-los, em vez de tentar descobrir como fazê-los usar IA à força.
00:12:19Coloque-os no comando do roteiro para tornar a IA segura em sua organização.
00:12:25E eles vão aderir assim que perceberem que as melhorias que estão sugerindo estão realmente tornando a vida deles melhor.
00:12:33E como podem ver, eles não hesitarão em dizer o que você precisa consertar.
00:12:37Isso representa menos de uma hora sentado com um grupo de pessoas.
00:12:40E este é o resultado de sessões de brainstorming.
00:12:45Outra coisa que tem sido muito útil especificamente com a minha equipe, e que estamos trabalhando para adotar na organização como um todo,
00:12:53é garantir uma comunicação consciente da atenção.
00:12:58Na era da IA, a atenção humana é um recurso escasso.
00:13:01Acho que ouvi isso em várias palestras, e muitas pessoas chegaram à mesma conclusão.
00:13:06Você não consegue obter mais atenção humana.
00:13:08Portanto, onde você gasta seu tempo e o que está lendo se torna muito importante.
00:13:13E como é um recurso tão escasso, sinalizar o que foi gerado por IA versus o que foi escrito por um humano ajuda muito a saber quanto tempo você precisa gastar lendo isso,
00:13:24e qual profundidade você pode esperar nesta parte da comunicação.
00:13:31E isso é basicamente construir uma nova cultura em torno desse estilo de comunicação.
00:13:35Isso realmente ajuda.
00:13:36E por exemplo, a equipe com a qual trabalho decidiu que sempre -- cada descrição de PR começará com algo assim.
00:13:45Algo que escrevi à mão pode ser bem curto para descrever o que isso está fazendo, e então a descrição da IA virá depois disso.
00:13:54É só que -- eu provavelmente vou ler.
00:13:55Provavelmente vou editar para remover algumas coisas erradas, mas eles não escreveram cada linha aqui.
00:14:00Então eles devem desconfiar mais, prestar mais atenção no que escrevi no topo e devem sobrescrevê-lo.
00:14:05Coisas assim no Slack, no e-mail, apenas aceitando o fato de que todo mundo sabe que você está usando IA para criar sua comunicação,
00:14:15mas sem timidez em dizer o que devem ler e a what devem prestar menos atenção.
00:14:21E eu me lembro no início, talvez no começo deste ano, tentei -- eu tinha alguns engenheiros seniores em nossa organização que eram muito céticos em relação à IA,
00:14:35e tentei falar com eles para ver qual era o problema, o que estava acontecendo, e disse que tentei rodar uma análise em alguns dos comentários de PR que eles fizeram,
00:14:42e obviamente usei IA para fazer isso.
00:14:45E aí eu não distingui muito claramente o que eu escrevi versus o que eles -- o que a IA gerou, e eles ficaram muito chateados.
00:14:54Eles disseram, por que você está enviando -- eu não esperava que alguém que respeito tanto me enviasse algo claramente tão desleixado.
00:15:02E aí, tipo, eu -- tipo, eu pedi desculpas.
00:15:05Percebi que deveria ter sinalizado claramente e marcado minha intenção.
00:15:08Tipo, isto é o que eu escrevi.
00:15:10Isto é o que a IA escreveu, e preciso do seu feedback porque não tenho o contexto para saber se está desleixado ou não.
00:15:15E é isso que estou pedindo a você.
00:15:17Portanto, lições como essa e a mudança de cultura são tão importantes quanto alguns dos desafios de engenharia que temos enfrentado.
00:15:28Outra coisa realmente útil em relação à adoção é que, conforme você avança na adoção, há muitas ferramentas sofisticadas e fluxos de trabalho complexos que temos implementado.
00:15:41Mas uma das coisas mais eficazes é simplesmente deixar as pessoas usarem a IA onde elas já estão.
00:15:47Isso realmente ajuda a normalizar o uso da IA nas tarefas cotidianas e ajuda a reduzir o atrito.
00:15:54E de fato, uma das coisas mais poderosas é poder marcar um agente em uma mensagem do Slack com alguém e dizer, você pode fazer isso para mim?
00:16:02E fazer com que os agentes concluam a tarefa na thread?
00:16:07E esse tipo de coisa é muito poderoso.
00:16:09E então você pode ir além disso e automatizar tudo com várias coisas sofisticadas.
00:16:14Mas se você estiver conversando com alguém que não está totalmente convencido, e puder marcar o agente de forma não passivo-agressiva, você pode dizer, vamos tentar e ver se o agente consegue resolver desta vez.
00:16:26E se a experiência for boa, isso realmente ajuda as pessoas a experimentarem por conta própria em outros casos.
00:16:33E nossa jornada continua.
00:16:37Ainda estamos aprendendo, mesmo entregando IA externamente, nossa adoção de IA e a experimentação constante em tantas frentes mostram que nossa automação ainda não está totalmente madura.
00:16:50Ainda estamos tentando descobrir quando devemos usar e como usar o Cloud Agent de forma eficaz, dadas todas as dependências do nosso sistema de build.
00:16:58E por isso continuamos aprendendo.
00:17:01É uma mudança cultural.
00:17:02É uma mudança de engenharia.
00:17:03E eu não sei quanto a vocês, mas trabalho no Vale há 15 anos, e esta é, de longe, a maior mudança de todas que já vi em termos de cultura e tecnologia.
00:17:16Então estamos todos juntos nessa e descobrindo as coisas.
00:17:19E era sobre isso que eu queria falar com vocês hoje.
00:17:22Obrigado.
00:17:28Obrigado.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video