Codificação agêntica: uma mesa-redonda com líderes do setor

Olá!

Você ouviu muitos Googlers do Android esta semana ou nos últimos dois dias.

Por isso, achamos que seria muito legal encerrar a conferência ouvindo algumas pessoas de fora, da comunidade de desenvolvedores Android.

Vamos falar sobre programação agêntica e o impacto dela no mundo real.

Vamos começar nos apresentando.

Meu nome é Ben, sou do Android DevRel.

Vocês já me ouviram uma vez nesta conferência, mas vamos passar para o painel.

Olá, pessoal.

Meu nome é Vinay e trabalho com ferramentas de IA na Databricks.

É um prazer estar aqui.

Olá, meu nome é Luis Artola.

Trabalho no Google Maps.

Lidero equipes que usam IA para criar experiências agênticas e melhorar o ciclo de desenvolvimento de software.

Olá, sou Annyce Davis.

Trabalho na Ford.

Eu lidero algumas equipes de engenharia que desenvolvem nossos produtos de assinatura e fidelidade.

Olá, pessoal.

Sou Ty Smith.

Trabalho na Uber, apoiando nossos desenvolvedores.

Isso já é feito em dispositivos móveis há muito tempo.

Nos últimos anos, o foco tem sido esse novo momento empolgante que estamos vivendo com as ferramentas de IA.

Olá, pessoal.

Meu nome é Kaushik Gopal.

Trabalho como engenheiro principal na Instacart e comecei este podcast sobre desenvolvimento Android chamado Fragmented.

Hoje em dia, como o Ty disse, mudamos um pouco as estratégias e, você sabe, falamos sobre o desenvolvimento de IA.

Certo.

Temos 30 minutos.

Acho que vai passar rápido, então vamos direto para as perguntas mais difíceis.

Na equipe de relações com desenvolvedores do Android, sempre dissemos que queremos tornar a criação de apps mais rápida e fácil.

Agora a IA chegou e, como vocês já ouviram aqui, "ela é mesmo.

Achamos que é mais rápido e fácil criar apps."

Mas quero perguntar: estamos realmente lançando apps mais rápido ou estamos apenas gerando um monte de código que não leva a lugar nenhum?

Vamos lá, Vinay.

Ok.

Sim, estamos todos olhando uns para os outros.

Ótimo!

Então, se você olhar apenas para os números, definitivamente vemos que o resultado em termos de PRs, em termos de linhas de código, vimos uma aceleração massiva e, como resultado, também estamos enfrentando desafios de escalonamento quando se trata de coisas como onde estamos armazenando nosso código, certo?

Essa aceleração é muito real.

O que não é óbvio é como isso afeta os resultados, e acho que todo o setor está tentando descobrir qual é a métrica certa para os resultados, como saber como isso afeta o resultado final.

Mas eu definitivamente vejo isso em ação.

Acho que enviamos mais código nos últimos seis meses do que no período anterior, e, novamente, vou manter isso ambíguo, mas como um período muito longo.

Como resultado, acho que nossa estratégia mudou até mesmo em relação à forma de medir a produtividade, certo?

Porque há várias maneiras de pensar sobre isso.

Estamos tentando descobrir como aumentar a mediana, certo?

Porque, quando você analisa os outliers e a mediana, há um delta de 5x a 10x entre essas duas categorias de pessoas, e nosso foco é elevar o piso, elevar a mediana e tornar essas pessoas tão produtivas quanto os colegas ao redor delas que vemos que são tão produtivos.

Vemos uma combinação de papéis.

Algumas pessoas estão se movendo muito mais rápido.

Há pessoas que têm cem PRs por dia e estão fazendo um trabalho incrível.

Mas esse é um tipo de espaço em que eles estão operando.

Isso é mais greenfield, ou eles são mais fluentes com as ferramentas.

Também vemos pessoas que estão muito mais, você sabe, no brownfield ou no trabalho de plataforma, e elas estão apoiando um tipo diferente de trabalho que talvez não seja tão acelerado porque elas precisam passar mais tempo com um julgamento humano e garantir que as coisas não vão quebrar.

E a combinação desses dois é significativamente mais rápida do que antes, mas acho que o tópico realmente interessante para nós é: mesmo que estejamos enviando mais, a empresa está realmente enviando mais para os usuários finais?

Essa é uma área em que investimos no último ano para entender se estamos lançando recursos mais rapidamente, não apenas código.

Os sinais iniciais dizem que sim, mas o cenário é muito diferente do que apenas as relações públicas puras.

Acho que o que aconteceu é que, claramente, as pessoas estão enviando muito mais, sabe, o número de PRs, as contagens aumentaram.

Mas acho que, mesmo agora, o pensamento é: "Como podemos usar a IA e essa ferramenta que temos para turbinar os processos atuais?"

Certo?

Por exemplo, a forma como enviávamos código antes parecia que sempre pensávamos em um humano como alguém que guiaria isso até a produção.

Mas acho que o que estamos vendo agora é que, sim, isso funciona.

Estamos enviando mais.

Mas estamos enfrentando todos os gargalos que não existiam antes, certo?

Porque nunca tivemos esses problemas no passado, mas agora estamos turbinando uma parte de um ciclo de várias etapas, e acho que é aí que as coisas ficam interessantes, tipo: "Ok.

Estamos entregando mais, mas agora é como um jato de efeitos."

Por isso, estamos enfrentando outros desafios.

Esse é um ponto muito interessante, porque, quando você pensa sobre isso, há muitas etapas diferentes, mas, de uma perspectiva de alto nível, é possível agrupá-las em três estágios, certo?

A programação, que está sendo claramente acelerada.

Há a prontidão para produção, que inclui uma série de coisas, como questões legais e de privacidade, e coisas que permitem que você lance algo, e depois há o lançamento, certo?

E o frete significa coisas diferentes dependendo de onde você está, certo?

Se você tem um produto totalmente do lado do servidor, o lançamento provavelmente significa um processo mais simplificado, enquanto que, ao lançar algo que vai para o consumidor, como colocar isso em experimentação, é como o meio de uma jornada, certo?

Ainda é preciso fazer muitos experimentos e medições, e é aí que entra o que você estava dizendo: parece que você está em uma área metropolitana, em uma rodovia, e tem um ponto de estrangulamento, e então começa a acelerar e pensa: "Sim, ótimo.

Estou indo muito rápido", mas agora você atingiu o próximo ponto de estrangulamento.

E o que a IA está deixando muito evidente é que você está vendo os pontos de atrito com mais clareza, e alguns deles não têm nada a ver com programação ou tecnologia.

Tem a ver com processos, pessoas e como otimizar isso com a IA.

Esse é um desafio muito interessante sobre como simplificar de ponta a ponta.

Uma maneira interessante de pensar sobre o espaço é: quanto controle a pessoa ou equipe tem para lançar o produto por completo?

Se olharmos internamente, há muitas equipes que talvez estejam criando ferramentas internas ou coisas que não são enviadas ao cliente.

Eles estão enviando muito mais rápido, certo?

Eles têm total liberdade para disponibilizar isso aos clientes imediatamente.

Se você tem um produto externo que ainda precisa passar por testes com um usuário, ou, sabe, tempos de lançamento na app store, ou, sabe, trabalhar com design e produto, todos esses outros gargalos estão se acumulando, e as pessoas que escrevem o código têm muito menos agência para agir rapidamente.

Por isso, eles estão atingindo os outros gargalos do sistema.

Por isso, acho que dividir esses processos em duas áreas diferentes realmente destaca onde eles podem ser melhorados.

Sim, concordo. E, sinceramente, acho que a engenharia nunca foi o gargalo.

Eu falo isso há anos.

A engenharia tem uma maneira muito rígida de fazer as coisas, e sempre vinha da empresa: "Qual é o problema?"

Você vai receber 10 respostas diferentes.

E depois: "OK.

Agora, vamos traduzir isso em algumas soluções com o produto.

Agora, vamos pensar um pouco sobre isso.

Ah, vamos falar um pouco sobre design.

Chute para lá."

Quando chega à engenharia, já sabemos mais ou menos o que precisamos fazer.

Depois, tentamos acessar o Stack Overflow, copiar e colar algumas coisas e enviar o produto.

Então, com a IA, o que mais está acelerando é o trabalho de compliance.

Aquelas coisas em que sempre quisemos modernizar o XYZ ou atualizar rapidamente a versão do Spring Boot.

Estamos fazendo isso muito rápido.

Mas, em relação à entrega de recursos, não posso dizer que vi uma melhora significativa.

Então, vocês mencionaram que talvez o gargalo tenha mudado, e vocês estão se deparando com esses processos que antes não eram o gargalo, mas agora são.

Mas esses processos provavelmente vieram de lições difíceis aprendidas no passado, certo?

Você sente pressão para mudar isso? Acho que o exemplo mais óbvio é a revisão de código.

Qual é o futuro da revisão de código?

O que estamos fazendo atualmente?

Então, sim, eu adoraria ouvir.

Isso volta ao ponto que mencionei.

Sinto que muitos desses gargalos existem porque pensamos em… Se você tivesse uma varinha mágica, por assim dizer, e pudesse reinventar a engenharia de software, e tivesse a IA hoje, usaríamos muitas das mesmas… Faríamos as mesmas coisas?

Por exemplo, a revisão de código era necessária porque precisávamos de um humano para aprovar as coisas, fazer aquela verificação final.

Acho que isso também está mudando. Por exemplo, a forma como pensamos sobre as revisões de código agora é: talvez devêssemos estar abertos à ideia de que, se você estiver refatorando o nome ou tentando refatorar o código, e souber que tem ótimos testes, o que todo mundo claramente tem.

Temos a IA para escrevê-los, está tudo bem.

Não, tipo, você vai fazer um trabalho muito melhor do que aquele agente?

Não sei, talvez não seja necessário gastar tempo revisando isso.

Por outro lado, se você vai lançar um bug e, sabe, recebe uma ligação do CEO dizendo: "Ei, isso está nos custando X dólares", talvez seja melhor identificar áreas e sistemas como: "Ei, esta é uma área crítica.

Esta não é uma área crítica" e tente repensar.

Não acho que seja assim que operamos hoje, certo?

Hoje em dia, é mais como: "Ei, tem um PR.

Eu sou o engenheiro.

Estou focado nisso.

Vai subir.

Eu peço para o Vinay fazer uma revisão de código no meio da noite, porque quero que o recurso seja integrado."

Por outro lado, talvez seja melhor repensar muitas delas.

Concordo plenamente e penso na revisão de código como um problema de verificação. O que quero dizer com isso é que, em um mundo em que tenho total confiança na minha capacidade de verificar algo, eu ainda revisaria 100% das minhas PRs?

Provavelmente não, certo?

Portanto, as revisões de código servem a dois propósitos.

Uma é verificar se estamos fazendo a coisa certa, e a segunda é a educação, certo?

Como as pessoas ao seu redor saberem o que você está fazendo e se concordam ou não com essa decisão.

Portanto, há uma categoria de trabalho que podemos acelerar e garantir que seja incorporada ao código e até mesmo às versões.

Isso pode não se aplicar a 100% dos casos, mas acho que é um número muito alto, de dois dígitos, que deve ser aplicado.

Acho que estamos nos preparando para fazer essas mudanças, e todos nós, como comunidade, precisamos garantir que nossos sistemas estejam prontos para isso, porque está chegando.

Não tem como evitar.

O topo do funil é tão amplo, com várias plataformas, que permite criar mais PRs.

E você é tão rápido quanto a etapa mais lenta do processo.

Para muitas equipes, isso significa revisões de código, e as equipes que estão se movendo mais rápido já entenderam e aceitaram essa realidade.

Sim, e se formos honestos, eu diria que 70% das solicitações de envio que vi parecem boas para mim.

Se pesquisássemos todas as bases de código do mundo, os comentários de PR seriam apenas "parece bom para mim", LGTM, em todos os lugares.

Como profissionais de engenharia, às vezes nos damos mais crédito do que merecemos.

Achamos que estamos no caminho certo.

"Eles usaram o padrão de comando?"

Não, nós só pensamos: "Ok.

Sim, parece bom para mim."

Então, por que não posso pedir para um agente fazer isso?

Acho que esse é o futuro que vamos ver, em que o "parece bom para mim" é definido pelas características e comportamentos que fizeram você se sentir assim.

E vamos garantir que o agente procure a mesma coisa.

Ou, por outro lado, também tente pensar em maneiras diferentes de revisar, certo?

Conheço pessoas que estão no Twitter hoje em dia e dizem o seguinte:

Por exemplo, quando você verifica um PR agora, peça para seus agentes visualizarem de uma forma diferente, certo?

Ei, mostre um antes.

Mostre o depois.

Mostre os testes que você escreveu em vez de revisar o código linha por linha.

Mas isso desafia… Você ia dizer algo, Luis?

Não, acho que é algo que nos faz pensar, né?

Assim, vamos chegar a um ponto em que você se sentirá confortável em permitir que CLs ou PRs sejam processados sem intervenção humana.

Então, vou fazer o papel de advogado do diabo e dizer que, quando falamos de atrito, acho que há uma tendência de pensar que ele é ruim, mas há atritos bons e ruins.

E acho que as avaliações ainda estão na categoria de atrito positivo.

É uma questão de como tornar isso menos oneroso para os desenvolvedores, certo?

E, às vezes, não se trata de como melhorar ou tornar mais eficiente essa análise naquele momento.

É como você pode tornar o desenvolvimento upstream mais preciso com a IA, certo?

Porque, dependendo de como você usa a IA, boas entradas produzem resultados melhores, mas entradas ruins produzem resultados realmente ruins, certo?

Então, para chegar a esse estado final atraente, é preciso que haja uma melhoria holística do processo com a IA desde o início, usando a IA para entender melhor a arquitetura, ter especificações realmente sólidas com menos esforço dos desenvolvedores, para que o código produzido seja de maior qualidade.

Portanto, as análises são menos complicadas para os desenvolvedores.

Acho que o estado final disso, que não seria tão controverso, é que a maioria das pessoas percebe que todo esse código será lançado sem revisão humana em algum momento.

Enquanto isso, estamos em uma situação em que os modelos estão melhorando, e estamos menos preocupados com erros técnicos e mais com erros de negócios ou com o julgamento ou a idealização que os causaram.

Isso também entra no sinal em que você quer separar isso durante a etapa de revisão.

Por exemplo, devemos fazer uma revisão linha por linha na solicitação de envio ou revisar a intenção que eles estão tentando enviar?

Estamos pensando nisso de algumas maneiras diferentes.

Uma delas é como fornecer informações mais relevantes ao usuário para que ele possa começar a priorizar isso.

A outra é: quais são as áreas mais seguras em que podemos experimentar e avançar mais rápido nesses tipos de programas?

Como Kaushik estava dizendo, nem todas as áreas precisam do mesmo nível de rigor.

Podemos identificar isso e começar a acelerar alguns processos, reduzindo o risco e mantendo, por exemplo, áreas mais voltadas para compliance ou muito fundamentais com maior atrito até que realmente possamos confiar não apenas nos modelos, mas também nas entradas que eles recebem.

foram as decisões certas.

Como refatorar um novo módulo do Android no app da Uber, talvez seja aceitável.

Dando carona para todos os desenvolvedores Android, provavelmente querem verificar esse código.

Vou ter que verificar isso com nosso CEO.

Desculpe, Kaushik.

Mas também acho que esse é um problema resolvido.

Já temos flags de recurso.

Já temos a implantação azul-verde.

Já temos muitas das peças.

O desafio é que estamos muito ocupados para fazer isso.

Já temos o acompanhamento comportamental.

Temos todos esses dados, mas eles estão em sistemas diferentes.

Já rastreamos incidentes.

Temos muitos dados, mas o que falta é juntar tudo em um único trace abrangente.

Quando finalmente descobrirmos como é esse tipo de serviço de contexto de engenharia em todas essas empresas, não precisaremos mais nos preocupar, porque mesmo que a solicitação de envio seja mesclada, ela estará segura.

Porque sabemos que temos isso por trás de uma flag de recurso.

Temos a implantação azul-verde.

Temos toda a observabilidade em vigor.

E aí você pode dizer com toda a confiança: "Ah, coloque isso no pipeline".

Se algo der errado, temos todas essas proteções e portões ao longo do caminho.

Acho que a velocidade de resposta também é muito importante, certo?

Se você, por exemplo, vamos pegar o Android como exemplo, se você estiver lançando uma mudança no Android que precisa ser enviada pela Google Play Store e depois ser lançada para os consumidores, sua capacidade de aplicar um hotfix imediato é realmente inibida em comparação com algo que tem uma implantação interna com observabilidade interna e um agente que está nela imediatamente, você tem muito mais oportunidades de agir mais rápido.

Uma das perguntas que eu tinha para vocês é que também há o problema de que há trabalho a ser feito nesses apps, mas há esses apps greenfield que são mais fáceis, depois há esses apps brownfield e, em seguida, há esse momento em que você precisa de tempo para colocar muitas dessas verificações, sabe, para que você possa proliferar o uso da IA.

Sei que muitos de vocês trabalham em apps enormes, certo?

Então, estou curioso para saber o que você pensa sobre isso.

É tipo, "Ei, CEO, me dá uns 3 meses, deixa eu preparar esse app para IA", ou, sei lá, adicionar todos os dias?

Sim.

Eles nunca fazem isso mesmo.

Acho que não.

A maioria das empresas nunca terá esse luxo.

Acho que precisamos dedicar o mesmo tempo que dedicávamos à dívida técnica, por exemplo, 20% do tempo para isso, e 5% desse tempo para melhorar um comando.

E até entender o que o comando faz e melhorar o contexto.

Como já mencionamos, acho que muitos engenheiros ainda não entendem como ela funciona.

Ainda parece algo mágico e místico, então eles não configuram e ajustam da melhor forma para obter mais valor e eficiência.

Então, acho que chega um momento em que os líderes precisam se perguntar: "O que precisamos fazer para capacitar nossa equipe para que eles entendam como isso funciona e possamos obter mais?"

É também uma continuidade dele.

Como as coisas estão mudando tão rápido, se eu pedisse para uma equipe passar uma semana aprendendo as novidades e colocando em prática, mas depois eles não tivessem tempo para continuar aprendendo ou experimentando, no ano que vem, eles estariam muito atrasados em relação aos novos recursos.

Então, é preciso que seja tudo isso, sabe, estamos construindo o avião enquanto voamos, colocando as proteções, aprendendo e ajustando conforme as coisas acontecem, e as equipes precisam ficar por dentro disso.

E, em grandes organizações, há equipes como algumas das nossas que tentam destilar algumas dessas informações e torná-las, você sabe, um pouco mais relacionadas e digeríveis.

Mas é um desafio para todos no setor no momento.

Quero mudar um pouco.

Muitos de vocês trabalham com infraestrutura de desenvolvedor.

Milhares de PRs, sua infraestrutura de teste, seus servidores, tudo está derretendo?

E eu adoraria ouvir algumas histórias de batalha.

Ty?

Sim.

Eles estão pegando fogo.

Meu CI chora até dormir todas as noites.

Praticamente todas as nossas equipes de infraestrutura de desenvolvedores estão enfrentando problemas de escalonamento na computação e problemas de eficiência.

Há, você sabe, códigos vermelhos acontecendo.

Eles veem esse enorme aumento de volume.

Estamos fazendo mudanças arquitetônicas com agentes.

Estamos tentando fazer coisas como expandir o mais rápido possível nossa execução de build remoto e armazenamento em cache com o Bazel, analisando coisas como, por exemplo, como todo o principal precisa estar verde o tempo todo ou se podemos começar a corrigir com agentes em determinadas áreas, analisando o volume vindo dos engenheiros, tentando fazer coisas como CI de autocorreção ou loops de feedback mais baixos, e todas as equipes estão investindo ativamente em tudo isso para tentar acompanhar o crescimento e, ao mesmo tempo, manter algum nível de eficiência.

Mas é extremamente desafiador.

Sim, concordo com tudo o que o Ty acabou de dizer, mas acho que isso também nos força a refletir e questionar honestamente se estamos prontos para crescer 10 vezes a partir de agora.

Para a maioria das pessoas, a resposta é "provavelmente não".

Por isso, ao pensar no futuro, estamos tentando alinhar nossa ambição com a escala que a infraestrutura pode suportar.

E uma coisa que a IA fez foi nos tornar mais ambiciosos, porque já vimos esse salto significativo, então estamos repensando nossos sistemas.

Certo, estamos pensando em qual outro sistema vai falhar ou que prevemos que vai falhar, e o que podemos fazer para nos antecipar a isso para que não seja uma surpresa?

Na verdade, estamos tentando evitar surpresas.

Certo, desde que sintamos que estamos no controle, todos ficam felizes.

No minuto em que encontramos uma surpresa, sei que é uma má notícia para todos.

Certo?

Este é um bom momento para refletir, analisar, auditar e descobrir o que vai dar errado em seguida, porque isso vai acontecer.

É inevitável.

Só queremos nos antecipar.

Ouvi uma frase interessante do CEO da Inflow.

Ela estava descrevendo que essa é a linha do tempo que o Google levou para chegar ao, sei lá, bilhão de linhas de código que eles têm agora, e isso levou cerca de 20 anos. Com a aceleração disso, muitas das nossas empresas vão atingir uma escala semelhante em apenas alguns anos, com base na aceleração da IA.

E não acho que todas as empresas estejam prontas para ter uma infraestrutura de desenvolvimento no nível do Google.

Por falar nisso, as empresas de vocês implementam algum tipo de limite de gasto?

Por exemplo, como você gerencia desenvolvedores que estão gastando tokens em tudo, sabe, usando o melhor modelo possível o tempo todo?

Você encontrou alguma estratégia ou é melhor deixar que eles façam o que quiserem, já que a experimentação leva a resultados incríveis?

Eu diria que o ano passado foi o ano da experimentação.

Faça de tudo.

E talvez até o primeiro semestre deste ano tenha sido apenas para uso razoável.

E agora, desde setembro, temos limites de tokens.

Por isso, temos limites para desenvolvedores no uso de tokens.

E temos instrumentações para que eles possam entender se as sessões estão sendo boas e saudáveis.

O que significa ter uma sessão saudável?

Você está tendo tantos turnos por sessão?

O que é um turno?

Então, estamos tentando usar as ferramentas para educar os desenvolvedores.

Acho que esse é só o primeiro passo.

Sabe, você precisa saber que tem um problema antes de poder corrigi-lo.

E, assim, pelo menos eles veem que isso não é sem custo financeiro.

Antes, parecia que a IA era sem custo financeiro.

E as pessoas estavam usando.

Eu gostaria de dizer "Mude minha agência" e ouvir "Sem problemas, Annyce, vou mudar a agência para você por US$ 5", sabe?

Agora, estamos chegando ao ponto em que você pensa: "Ok, eu poderia simplesmente ir para a linha de comando e fazer isso sozinho, certo?"

Então, acho que vamos começar a educar os engenheiros sobre o custo real.

Não é como se eu fosse criar instâncias do ECS e depois esquecer delas.

Talvez quando a AWS foi lançada, pensamos: "Sim, posso gastar minha própria instância".

E estávamos custando muito dinheiro para a empresa.

Acho que o mesmo está acontecendo agora com os tokens.

Acho que os limites práticos também apresentam oportunidades muito interessantes, certo?

Porque, no início, quando começamos a usar LLMs, jogávamos tudo neles, certo?

Eles analisavam o código, entendiam o que estava acontecendo e faziam mágica para você, certo?

Mas isso teve um custo.

E estamos realmente... sabe, o setor está percebendo isso.

Isso está forçando os desenvolvedores e as organizações a pensarem em como otimizar isso, certo?

Por exemplo, se você tem um gerador que produz componentes de interface do usuário e eles precisam obedecer a uma estrutura específica, testes de unidade e coisas do tipo, por que você faria os modelos gerarem isso em tempo real se pode fazer com que eles gerem uma ferramenta determinística que pode criar isso para você?

Então, há muitas oportunidades para usar os limites de tokens e de uso a seu favor e, assim, se tornar mais eficaz.

Sim, e, de acordo com esses temas, introduzimos limites, pelo menos, como você sabe, na Instacart.

Mas acho que o objetivo não é necessariamente limitar o uso da IA, mas sim trazer algum tipo de higiene ou, como você disse, introspecção, certo?

Por exemplo, quando você deve usar determinados modelos em vez de outros.

Você provavelmente não precisa do Fable ou do Astra para saber as horas ou mudar uma ramificação do Git.

Certo?

Você pode, por exemplo, dedicar um tempo para escrever um script que será sem custo financeiro para sempre.

Nenhum token foi desperdiçado.

Certo?

Então, acho que se você puder adicionar algum tipo de restrição, não necessariamente para limitar o uso, mas para ajudar a pensar além de apenas jogar tudo nela.

Certo?

Gostei do que você disse. O ano passado pareceu o ano da experimentação.

Este ano, a pergunta é: como usar isso de forma eficaz?

Sim.

As histórias aqui também nos impactam muito.

Especialmente ao passar de mais experimentação para, você sabe, um conjunto equilibrado de eficiência e responsabilidade.

Isso vem de uma variedade de investimentos.

Há coisas como educação para os desenvolvedores e visibilidade.

Sabe, como a Annyce estava falando sobre o custo e as informações da sessão de atividade.

Investimentos em padrões seguros que, você sabe, ajudam a evitar interações desnecessárias, garantindo que as habilidades usadas sejam eficientes na busca por regressões e coisas do tipo.

E responsabilizá-los pelos custos que estão gastando.

Então, temos limites de tokens.

E quando um desenvolvedor os alcança, ele pode, com um clique, inserir uma justificativa e o gerente pode aprovar.

Se houver um bom trabalho sendo feito, queremos que eles passem por isso.

Mas, se eles estiverem fazendo algo mais desperdiçador ou experimental, não poderão justificar ao gerente por que deveriam gastar dinheiro com isso. Então, isso também ajuda a manter isso sob controle.

Isso resulta não apenas em não fazer o trabalho, mas em analisar e dizer: "Essa é a escolha certa de modelo?"

Esse é o peso certo?

Como você sabe, o custo desses tokens começou a cair com a pressão competitiva.

Mas, em geral, fazer com que nossos engenheiros pensem nisso como uma forma de administrar bem o dinheiro que estamos dando a eles é, na minha opinião, a abordagem certa e saudável no momento.

E, a longo prazo, poder remover essa decisão deles por completo.

Certo?

Você quer roteamento automático de modelos e coisas do tipo, para que eles nunca precisem pensar nisso.

Mas, enquanto isso, esse é um estado íntegro.

Sim.

Acho que grande parte do nosso foco tem sido em coisas como o roteamento de modelos, para que possamos tirar essa decisão do desenvolvedor e tentar mapear a tarefa para o modelo certo.

Mas também é preciso ter os gatilhos certos.

Por isso, pensamos nos limites de tokens de algumas maneiras.

Não queremos bloquear o desenvolvedor.

Mas queremos garantir que haja momentos em que possamos fazer uma pausa e garantir que ele seja gasto nas áreas certas e da maneira correta.

Por isso, existem limites diários, por exemplo, puramente como um gatilho que um desenvolvedor pode desbloquear por conta própria.

Basta acessar o portal, clicar em um botão e dizer: "Não aconteceu nada de surpreendente.

Eu estou no controle."

Certo?

E essa é apenas uma alavanca simples, porque todo mundo está fazendo loops, e esses loops podem ser executados durante a noite, e não queremos que isso aumente os custos.

Então, isso é muito razoável.

Por outro lado, também queremos garantir que nossos desenvolvedores tenham os melhores modelos disponíveis.

Mas para essa categoria de modelos, criamos um orçamento de fronteira.

Por isso, há um orçamento mensal em vigor.

É alto o suficiente.

Você não está bloqueado.

Se você precisar ser desbloqueado, há um processo de exceção.

Vai para seu gerente.

É um momento em que você descreve o que está fazendo.

E nós não somos os tomadores de decisão como equipe de plataforma, porque essas decisões devem ser tomadas perto de onde o trabalho está acontecendo.

Em termos de uso do modelo de fronteira, oferecemos total flexibilidade com um limite.

Isso funciona porque, no final das contas, traz previsibilidade ao processo.

Certo?

Queremos garantir que, ao definir o orçamento para o gasto de tokens, o que é um desafio para todos, contabilizamos o que planejamos, e essas alavancas nos permitem fazer isso.

Sabe o que eu acho fascinante nessas conversas?

Acho que é porque todos nós trabalhamos em empresas.

E, portanto, as empresas.

Por isso, precisamos pagar por cada token.

Certo?

Mas há um lado inteiro da Internet em que as pessoas usam preços por assinatura.

Para eles, o cálculo é muito diferente.

Certo?

Mas acho que é uma questão de tempo até que todos estejam no mesmo barco, em que é preciso pensar em cada token.

E é aí que, você sabe, as coisas vão ficar mais sérias em termos de responsabilidade, como temos que fazer agora nas empresas.

Ou você trabalha em um laboratório de ponta com orçamento ilimitado.

E aí você continua operando e criando muitas dessas formas de trabalho nativas de IA que estão por todo o Twitter.

Todas as nossas empresas querem espelhar isso, mas não querem gastar os tokens que…

Temos pessoas que trabalham no Google aqui.

Estou muito curioso.

Como ele funciona?

Qual é o orçamento do Google?

Quer responder, Luis?

Não acho que sou a pessoa certa para falar sobre a economia disso.

O Google é uma empresa muito grande, com muitas organizações diferentes.

Mas isso é perfeito, porque estamos no horário.

Isso foi conveniente.

Salvo pelo gongo.

Isso é moderação de primeira, pessoal.

As pessoas de RP são…

Enfim, agradeço ao nosso painel e a todos que vieram ao ADS.