O que um engenheiro de IA faz agora? — Aparna Dhinakaran, Arize AI

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: What Does an AI Engineer Do Now? - Aparna Dhinakaran, Arize AI · Canal: AI Engineer · 15:02 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de software com IA

Resumo

Aparna Dhinakaran descreve como o trabalho de um engenheiro de IA está mudando: em vez de apenas criar funcionalidades, é preciso construir sistemas que permitam a agentes executar e aprimorar continuamente esse trabalho. Usando o Signal, da Arize AI, como exemplo, ela explica como agentes podem analisar traces e dados de observabilidade, encontrar problemas e propor correções. Ela destaca a importância de sandboxes, memória, durabilidade e suporte a diferentes modelos e harnesses. Também defende que engenheiros de IA desenvolvam evals alinhadas ao julgamento humano e avaliem os próprios evaluators. A função, conclui, é fechar a distância entre os avanços dos laboratórios e as necessidades das empresas, criando ciclos de monitoramento e melhoria contínua.

Pontos-chave

O trabalho do engenheiro de IA está passando da criação de funcionalidades para a construção de ciclos que permitem a agentes criá-las e aprimorá-las.
Agentes sempre ativos podem analisar traces e dados de telemetria para identificar problemas e, quando têm acesso ao repo, propor correções ou abrir um PR.
Dados de observabilidade devem ser preparados para que agentes, e não apenas pessoas, sejam seus principais consumidores.
A execução dos agentes pode ser iniciada por uma agenda, por eventos ou por métricas.
Sandboxes isolam o contexto, os acessos e as credenciais de cada execução; informações úteis são preservadas na memória, enquanto recursos temporários são descartados.
A durabilidade permite retomar uma execução após falhas, preservando o estado fora da sandbox.
Evals precisam refletir o julgamento humano, e os próprios evaluators devem ser validados com conjuntos de dados de referência.
O ciclo proposto reúne coleta de dados, evals, agentes que analisam os resultados e melhorias no produto.

Capítulos

Início	Capítulo	Resumo
00:01	A evolução do trabalho de engenheiro de IA	A palestrante apresenta a diferença entre o uso casual de LLMs e a operação de grandes equipes de agentes, e propõe que engenheiros construam sistemas para executá-los.
03:34	Signal: agentes que analisam dados de observabilidade	O Signal analisa traces, mantém memória de problemas encontrados e pode propor correções com acesso ao repo.
05:06	Gatilhos, contexto e memória dos agentes	A palestra detalha os gatilhos que iniciam agentes, o contexto carregado em uma sandbox e como estado e resultados são preservados entre execuções.
10:17	Evals alinhadas ao julgamento humano	Aparna explica como criar evals para testar mudanças, validar evaluators com dados de referência e aproximar suas avaliações do julgamento humano.
12:58	Um ciclo contínuo de melhoria	O encerramento conecta traces, evals offline e online e agentes que usam dados de produção para encontrar problemas e melhorar produtos.

Citações

Seu trabalho já não é apenas escrever a funcionalidade; é construir o ciclo que a escreve. — 02:33

Já não se trata de pessoas consumindo dados de telemetria: os agentes passam a ser os principais consumidores desses dados. — 04:35

Definir o que é bom se torna realmente importante para o engenheiro de IA. — 11:22

Engenheiros de IA são o papel que ajuda a fechar essa distância. — 14:29

Conceitos e entidades

AI Engineer (conceito): Profissional que constrói sistemas de IA, define evals e cria ciclos para que agentes monitorem e aprimorem produtos.
Signal (ferramenta): Produto da Arize AI apresentado como um agente sempre ativo que analisa traces, identifica problemas e pode propor correções.
Arize AI (empresa): Empresa responsável pelo Signal, ferramenta apresentada na palestra.
Aparna Dhinakaran (pessoa): Palestrante que discute a evolução do trabalho de engenharia de IA e a construção de agentes.
Andrej Karpathy (pessoa): Pessoa citada por uma publicação sobre a diferença entre usuários comuns de LLMs e profissionais que operam muitos agentes.
Claude Code (ferramenta): Ferramenta de programação com IA citada como um dos harnesses compatíveis com o Signal.
Cursor (ferramenta): Ferramenta citada como um dos harnesses compatíveis com o Signal.
Codex (ferramenta): Ferramenta citada como um dos harnesses compatíveis com o Signal.
evals (conceito): Testes usados para avaliar mudanças, detectar regressões e verificar se o comportamento do sistema corresponde ao julgamento humano.
observabilidade (conceito): Coleta e análise de traces, logs e métricas para compreender o comportamento de sistemas e agentes.
sandbox (conceito): Ambiente isolado criado para uma execução do agente, com o contexto e os acessos necessários, e descartado ao final.

Tradução completa (pt-BR)

00:01 [música] >> Incrível. Bom, sejam bem-vindos ao AI Engineer. Pensando em onde estamos, no AI Engineers New York, achei que seria interessante revisitar a pergunta: o que faz um engenheiro de IA? Sinto que, a cada ano, temos uma ideia do que faz um engenheiro de IA, e essa definição muda um pouco.

00:32 E, enquanto preparava esta palestra, o momento não poderia ser mais oportuno, porque Karpathy acabou de publicar um tweet neste fim de semana em que fala sobre essa lacuna crescente entre, basicamente, as pessoas na fronteira, que estão executando milhares de agents e enxames de agents sempre ativos, e o restante. Ele apresenta este funil: mais de 6 bilhões de usuários talvez já tenham usado ou interagido com um LLM. De 1 a 2 bilhões talvez sejam usuários casuais do plano gratuito. 20

01:02 milhões são profissionais que talvez tenham começado a usar isso para reduzir parte de um trabalho que levaria semanas para alguns dias. Mas, na verdade, quem está nos laboratórios de fronteira — uma porcentagem muito pequena — são cerca de 5.000 usuários. São eles que estão executando milhares e milhares de agents ao mesmo tempo. E, quando olho para isso, quer dizer, ele apresentou um pouco desse funil. A primeira pergunta que qualquer pessoa faz ao olhar para isso é: onde eu me encaixo nisso?

01:32 E, sabe, ele traçou um pouco de um roteiro de como todos podem se tornar, nos próximos dois anos, uma dessas 5.000 pessoas que estão executando milhares de agents. E isso vem acontecendo, eu diria, há algumas décadas, à medida que a camada de abstração foi ficando cada vez mais alta. Quer dizer, com certeza isso acelerou nos últimos anos, mas passamos de engenheiros escrevendo linguagens de abstração de nível mais alto para, agora, simplesmente copiar e colar

02:03 código, usar agents locais, usar agents na nuvem. E agora a expectativa é: como todos nós começamos a executar uma equipe de agents ou fábricas de agents internamente e avançamos nessa direção? >> [fungada] >> E isso levou, essencialmente, a um antes e depois do que é um engenheiro de IA. E isso é um pouco… Acho que, para alguns, é um roteiro, mas, internamente, já começamos a caminhar nessa direção.

02:33 Como engenheiro de IA, seu trabalho não é mais apenas escrever o recurso, escrever um recurso de IA; é criar o ciclo para escrever esse recurso. Não se trata mais apenas de ler o diff e fazer a revisão de código; trata-se de configurar sistemas e agents para fazer as revisões de código e de escrever evals para revisar tarefas não determinísticas. Já não se trata nem mesmo apenas de configurar métricas e algum tipo de telemetria de software, mas de fazer com que agents analisem os dados de observabilidade e consumam essa telemetria para encontrar padrões.

03:03 E, então, [fungada] esse ciclo de que temos falado — construir, avaliar, lançar, monitorar e melhorar — agora é responsabilidade do engenheiro de IA não apenas executar cada uma dessas etapas, mas também criar o ciclo que realiza cada uma delas. Na Arize, uma das coisas que lançamos no nosso produto — e vou falar um pouco sobre o que aprendemos ao criá-lo — é o Signal, que desenvolvemos para executar esse ciclo para engenheiros de IA. O que o Signal faz é

03:34 analisar todos os traces, ler a telemetria, identificar padrões nela e até propor uma correção ou abrir um PR, se tiver acesso ao repo. E o Signal é um agent sempre ativo. Este é um exemplo de como o Signal começa, mas ele começa

04:04 simplesmente lendo os traces. É um exemplo bem simples, mas ele analisa — tudo isso é configurável — uma determinada quantidade de traces recebidos em certa frequência. Ele os lê, e o objetivo é identificar problemas nos dados de telemetria. Precisa acompanhar os problemas que já encontrou. Então, temos que considerar a memória: ele já viu algo que considerou um problema antes? Algo pareceu um problema, mas não foi registrado e agora, à medida que

04:35 coleta mais dados, ele passa a considerar que é um problema muito mais crítico? Então, o Signal começa lendo os traces para identificar problemas. E uma das primeiras coisas que percebemos foi que mudou bastante quem consome os dados de telemetria. Já não são os humanos que consomem esses dados. Também não se trata mais de humanos consumindo os dados e agents assumindo parte da tarefa; a questão é como configurar seus

05:06 dados de telemetria para que os agents sejam os principais consumidores desses dados. Isso permite que os dados de observabilidade se tornem o gatilho para executar e acionar esses agents sempre ativos. Então, a primeira coisa a considerar ao criar uma equipe ou, sabe, uma fábrica de agents sempre ativos é o que faz esses agents acordarem ou começarem a funcionar. Há vários tipos de gatilhos. No caso do Signal, para nós, é configurável para funcionar em uma frequência contínua. Por exemplo, a cada 3 horas, 6

05:38 horas, buscar os últimos, sabe, X traces, lê-los e identificar problemas. Também pode ser acionado por eventos. Por exemplo, mensagens no Slack; se algum usuário reclamar de alguma coisa, pode ser um gatilho baseado em métricas. Mas esses são, essencialmente, gatilhos que iniciam o agent. Depois que o agent começa, precisamos dedicar algum tempo a entender como é, de fato, uma execução de agent. No nosso caso,

06:08 buscamos todo o contexto dos traces e quaisquer dados adicionais de terceiros. Por exemplo, permitimos coletar logs e métricas de APM, além de todos os dados de telemetria de terceiros que queremos incluir, o acesso ao repo e o acesso a quaisquer chaves necessárias para executar esse agent. Todas essas informações são

06:38 colocadas em um sandbox, que é iniciado toda vez que o agent é ativado. Então, o agent é acionado, criamos um sandbox e colocamos nele tudo de que precisamos. Há um proxy; a única forma de enviar informações para dentro e para fora do sandbox é por esse proxy único. Tudo o que acontece dentro do sandbox já está sendo rastreado, e todos os resultados — por exemplo, os problemas gerados e identificados — são salvos em algum tipo de memória. E isso acontece toda vez

07:09 que o agent é executado. Quando a execução do agent termina, depois de analisar todos os traces, ele pode ter encontrado algo ou não. O que fica e o que é descartado? Se encontrar algum problema, todos os resultados são salvos em algum tipo de memória, para que, na próxima vez que um agent for iniciado, não precise começar do zero. Ele terá um histórico dos problemas que encontrou. Os agents são rastreados, então todos os

07:42 dados de telemetria sobre o que o agent chamou — por exemplo, se ele abriu um PR — são rastreados. E quaisquer skills que ele possa ter aprendido durante uma execução também podem ser salvas no repo. Mas o que é descartado é o sandbox, que é desfeito; todas as credenciais são removidas, obviamente; o acesso ao repo é revogado. Assim, todo o material que não precisa ser salvo é descartado depois da execução do Signal.

08:13 E projetamos o Signal para manter a configuração desse agent durável. Isso significa que, se o sandbox ou o harness falhar, ele não precisa começar tudo do zero no meio da execução. Ele deve simplesmente poder retomar a partir da etapa em que falhou, e todo o estado, por assim dizer, é salvo em uma memória fora do sandbox. Projetamos isso para que seja muito

08:44 um agente durável, para que, se ele falhar, possa ser iniciado novamente. Você pode abrir um novo sandbox, iniciar um novo harness para retomar de onde parou. Então, tudo isso é essencialmente a base de como construímos o Signal para executar cada execução. O agent é acionado, começa a funcionar, carregado com todos os contextos e as evidências, percorre os dados de telemetria, encontra algo ou não, e tudo isso é salvo na memória. Se algo falha no meio do processo, o agent pode ser reiniciado. E também construímos o Signal para que ele fosse, digamos,

09:17 agnóstico em relação ao modelo ou ao harness. Hoje, o Signal oferece suporte não só ao Claude Code, com o qual começamos, mas também ao Cursor e ao Codex. E o objetivo é oferecer suporte a todos os principais harnesses, inclusive os open source. E o Signal também oferece suporte, ou oferecerá suporte, a vários modelos. Então, mesmo que você esteja usando o Claude Code, pode escolher qualquer um dos modelos da família Anthropic. E isso

09:47 é muito importante para nós porque, primeiro, é uma ótima maneira de avaliar a qualidade do agent sempre que o iniciamos. Isso nos ajuda a controlar os custos, então podemos ver que, à medida que usamos modelos mais poderosos, talvez a qualidade dos PRs melhore, mas será que podemos reduzir a qualidade do, digamos, será que podemos reduzir o custo e ainda manter o rigor e a qualidade dos problemas realmente detectados pelo Signal? Então, pensamos bastante nisso, a partir de

10:17 dos primeiros princípios, quando estávamos projetando o Signal. E isso é uma boa transição para a pergunta: o que um engenheiro de IA precisa fazer? Bem, um engenheiro de IA realmente precisa aprender a escrever evals. Então, sempre que o Signal é executado e encontra um problema, ele abre um PR. E são executadas evals no agent para testar esse PR. Uma eval pode ser tão simples quanto testar algo como parte do seu workflow de desenvolvimento. Você tem um conjunto de dados, pode ser um prompt simples

10:51 com saídas que você está testando para garantir que não haja regressões. Mas essas evals também precisam estar alinhadas ao julgamento humano. E eu diria que é provavelmente aqui que um engenheiro de IA deveria passar boa parte do tempo enquanto constrói o sistema para realmente executar o loop. Ele deveria passar tempo analisando os traces dos agents e identificando quais são os erros comuns. E acho que há muitas skills. Ontem, ouvi Lance falar sobre

11:22 a skill do Claude para criar evals. Temos uma skill com o avaliador da Arize para ajudar você a criar e escrever evals, além de alinhá-las ao julgamento humano. Mas é provavelmente aqui que definir o que é bom se torna muito, muito importante para um engenheiro de IA. E, para muitas equipes com quem conversamos e trabalhamos, a pergunta é: “Bem, como posso confiar no avaliador?” E será que eu realmente confio que a eval

11:53 vai, digamos, capturar isso? Como posso confiar que ela é tão boa quanto meu julgamento? Eu diria que dedicamos bastante do nosso próprio tempo, nos nossos produtos, para avaliar os avaliadores. Passamos um bom tempo construindo esses conjuntos de dados, conjuntos de dados de referência, com respostas corretas. Executamos evals, verificamos os resultados em relação às saídas humanas e tentamos alinhá-las para garantir que o judge realmente concorde

12:24 com o ser humano e que haja concordância antes de lançarmos um novo avaliador. Essas evals podem ser usadas tanto em testes offline quanto em testes online. E eu diria que, cada vez mais, é nisso que consiste o trabalho de um engenheiro de IA. Então, o que quero deixar para vocês é: como engenheiro de IA, você construiu esse agent, construiu esse agent para funcionar e estar sempre ativo, e

12:58 executa evals antes de colocá-lo em produção. Você pode lançá-lo e, quando ele entra em produção, o objetivo é rastrear tudo. E rastrear tudo agora significa rastrear não só os agents, mas também os agents de programação por trás dos agents que construíram isso. Então, você pode rastrear o Claude Code, o Cursor e o Codex, mas todos esses agents de programação podem ser rastreados para que você entenda o que aconteceu na fábrica de agents que vocês estão

13:29 construindo. E os traces de todos esses agents também podem ser avaliados online. Há uma avaliação offline quando você está testando uma nova mudança, mas, quando ela entra em produção, essas se tornam suas evals online, executadas sobre os dados de telemetria. Para nós, isso acaba se tornando os novos dados que são então enviados de volta aos agents para que leiam os dados de telemetria, as evals e

13:59 identifiquem problemas nos traces. Então, o sistema passa a ser: como coletar dados, avaliar esses dados e executar agents sobre eles, para encontrar problemas e descobrir onde estão as lacunas e, assim, melhorar seus sistemas. Voltando à pergunta com que começamos tudo isso: o que um engenheiro de IA faz? Acho que existe uma grande lacuna entre o que está acontecendo hoje nos laboratórios e o que

14:29 está acontecendo em muitas empresas. Parte disso pode ser simplesmente porque os dados dentro das empresas são muito mais desorganizados do que os dados bem delimitados e testáveis dentro de um laboratório. Mas os engenheiros de IA são o papel que fecha essa lacuna. Eu diria que isso começa com rastrear tudo, rastrear os agents que você está construindo, executar evals, aprender a testar os produtos que estamos realmente construindo e, então, criar um sistema para que os agents possam melhorar com base na telemetria que está

15:02 sendo coletada, para que você não esteja mais apenas construindo recursos individuais, mas construindo o sistema para melhorar seus produtos. Se quiser saber mais, venham visitar nosso estande. Vocês podem conhecer o Signal e saber mais. Muito obrigada por nos ouvir. >> [aplausos] [música] >> Oi.

Transcrição original

[00:01] [music] >> Awesome. Well, welcome to AI engineer. Um uh thought given where at AI engineers New York, we’d kind of revisit the question of what does an AI engineer do? Feel like every year we have an idea of what an AI engineer does and that definition kind of changes. Um

[00:32] And as I was putting this talk together, it was super timely because Karpathy actually just tweeted something this weekend where he kind of he kind of talks about this growing gap between basically folks at the frontier who are running thousands of agents and swarms of always-on agents and he really kind of drops this funnel where 6 billion plus users have maybe touched or interfaced with an LLM. 1 to 2 billion or maybe like casual free tier users. 20

[01:02] million are professionals who have maybe started using it for more taking some piece of work that would have taken weeks down to to days. But really those at the frontier labs are which is a super small percentage. It’s like 5,000 users. Uh are the ones who are running thousands and thousands of agents at once. And as I look at this, it really is I mean he’s kind of dropped a bit of the funnel. I mean the first question anyone looks at this is that where am I on

[01:32] this? And you know, he’s kind of drawn out a bit of a road map of how does everyone get to in the next couple of years one of those 5,000 users who are running thousands of agents. And this has been happening I’d say for for a couple of decades now where the abstraction layer has gotten higher and higher. I mean definitely faster in the last couple of years, but we’ve gone from engineers writing higher level abstraction languages to I mean just copy-pasting

[02:03] code, using local agents to using cloud agents to really the expectation now is how how do all of us start running a team of agents or factories of agents internally and build toward that. >> [snorts] >> And what this has led to is essentially what is a then and now of what an AI engineer is. And this is is this is a bit uh I I think of a of a roadmap for some, but I think internally this is what we’ve already started to kind of push

[02:33] towards. As an AI engineer, your job’s no longer to just write the feature, write an AI feature, it’s about how do you build the loop to write that feature. It’s no longer about you know, just reading the diff and actually doing code review, it’s actually how do you set up systems and agents to do the code reviews, and how do you write evals to actually do the non-deterministic um to review those non-deterministic tasks. It’s actually no longer even about just setting up metrics and and software kind

[03:03] of telemetry, but it’s actually how do you have agents go through and read the observability data and have agents actually consume that telemetry to find patterns. And so, [snorts] this loop that we’ve kind of been talking about, which is the build, the eval, ship, you monitor, you improve it, well, the AI engineer is now actually responsible not just for doing each of those steps, but how do you build the loop that does the that that actually does each of those steps. And at Arize, one of the things we’ve rolled out in our product, and I’m going

[03:34] to talk about a bit of what we’ve learned in building this, is we built signal to actually run this loop for AI engineers. What signal does is that signal actually looks at all of the traces, it reads the telemetry, it identifies patterns in that telemetry, and it can actually put up a fix or a PR if it has access to the repo. And signal signal’s an always-on agent. So, this is an example of how signal starts, but it actually starts off by

[04:04] just reading the traces. Super simple example, but it goes through, reads um and all of this configurable, but and certain volume of traces that came in in some cadence. It reads it and then the goal is to actually identify issues from that telemetry data. It has to keep track of issues that it’s previously seen. So, we have to consider the memory of did see something before that it thought was an issue? Did something seem like an issue, but it wasn’t actually captured and now as it

[04:35] collects more data, it actually thinks it’s much more of a critical critical issue. And so, signal actually starts off by reading the traces to identify problems. And so, one of the first things that we realized was that the future of who’s actually consuming telemetry data has really changed. It’s no longer about humans consuming telemetry data. It’s not even about humans consuming it and agents kind of taking on the task, but it really is how do you set up your

[05:06] telemetry data so that agents are the primary consumers of that data. And what that does is that that observability data can become the trigger for actually running and triggering these always-on agents. And so, the first thing that if you’re building a team of of you know, a factory of really always-on agents is what triggers these agents to wake up or start. And there can be a variety of triggers. For signal, for us it’s you know, it’s configurable to run on an ongoing cadence. So, every 3 hours, 6

[05:38] hours, go pull the last, you know, X amount of traces, read them, identify problems. It can also be triggered by events. So, Slack messages, um if some user complains about something, it can be a metric-based trigger, but these are essentially triggers to kick up the agent actually starting. Once the agent actually starts, we have to spend some time figuring out, well, what is what is an agent run actually look like? For us,

[06:08] we actually pull in all of the context of the traces, um any additional third-party data, so we allow collecting to APM logs, APM metrics, um but all of the third-party telemetry data that we want to pull in, um access to the repo, um access to the actual um the the access to any keys that are needed to actually run run this agent, but all of this information is um put

[06:38] inside of a sandbox, and this is actually what’s started up every time the agent wakes up. And so, the agent’s triggered, we build a sandbox, we put everything that we need inside of that sandbox, there’s a proxy, the only way to get information in and out of the sandbox is by this single proxy, and everything that happens inside of that sandbox is actually already getting traced, and every output, so the issues that are generated and created are all getting saved to some kind of memory. And so, this happens every single time

[07:09] the agent actually runs. Every time the agent finishes running, so it swept through all of the traces, um it either found something or it didn’t, there’s what actually stays and what actually gets thrown away. What stays is that if it found any issues, all of the output is actually saved off in some kind of memory, so that the next time an agent gets spun up, it doesn’t have to start from ground zero. It has a history of what are the issues that it actually found. Um the agents are traced, so all of the

[07:42] telemetry data of what the agent called, um you know, if it actually put up a PR, all of those things are actually traced. And any skills that it may have learned while actually doing a run can also get saved to the actual repo. But, the things that go away is the sandbox gets torn down, any credentials, um you know, obviously get get removed, um the repo access is removed, and so all of the stuff that doesn’t need to be saved kind of gets torn down after the run of signal.

[08:13] And we’ve designed signal in a way to actually keep this agent configure durable. So, that means that either if the if the sandbox fails, or if the harness fails, then it shouldn’t have to start everything from scratch in the middle of the run. It should actually just be able to pick up from the step that it failed, and all of the state, so-called, is kind of saved off in kind of a a memory outside of the sandbox. And so, we’ve designed this to actually be a very

[08:44] durable agent, so that if it fails, it can spin it back up. Um you can launch a new sandbox, launch a new harness to kind of pick back up where it started. So, all of this is essentially the underpinnings of how we built signal to run every single run. Agent gets triggered, agent gets started, loaded with all the contexts, the evidence, uh it sweeps through the telemetry data, it either finds something or it doesn’t, all of that gets saved to memory. If something fails in the middle, the agent can get reset up. And we built signal to also be you know,

[09:17] agnostic of the model or the harness. So, today signal supports not just Cloud Code, which is what we started with, but it also supports Cursor and Codex. And the goal is to actually support all of the the major, even the open source harnesses out there. Um and signal actually also supports um multiple uh it will support kind of multiple models. So, even if you’re using Claude code, uh you can pick any of the models inside the Anthropic family. Um and this is

[09:47] really important to us because one, it’s an awesome way for us to evaluate the quality of the agent um every time we spin it up. It helps us control costs, so we can see, you know, as we use more powerful models, the better quality maybe the PRs are, but can we reduce the quality of the the you know, can we reduce the cost and actually still maintain the rigor um and maintain the quality of issues that are actually detected by Signal. So, this is something we deeply thought about from

[10:17] from first principles when we were designing Signal. And this is actually a pretty good segue into what does an AI engineer need to do? Well, an AI engineer really needs to kind of learn how to write evals. And so, we actually every time Signal runs, Signal finds an issue, it puts up a PR. Well, there’s evals that are run on top of the agent to test that PR. Um and an eval can be as simple as um you know, testing something as part of your development workflow. You have a dataset, you can be a simple prompt um

[10:51] it with with outputs that you’re testing to make sure that there’s no regressions. Um but these evals can also they need to be kind of aligned with human judgment. And I’d argue that this is actually probably where an AI engineer should be spending a lot of their time as they’re building the system to actually run the loop. They should be actually spending time looking at the traces with their agents, identifying what the common errors are. Um and there’s a lot of skills I think I was hearing Lance yesterday talk about

[11:22] the Claude skill to build evals. We have a skill with the arise um evaluator to actually help you build and write evals as well as align those evals with the human judgment. But, this is probably where the shift to defining what is good becomes really, really important for an AI engineer to actually do. And for a lot of teams I I think we speak with and we work with, their question becomes, “Well, how do I trust the evaluator?” And do I do I really trust that the eval

[11:53] is um you know, is going to capture you know, how how do I trust that it’s as good as my judgment? And I’d say what we spend a lot of our own time doing for our own products is that we actually evaluate the evaluators. Um we spend a decent amount of time on actually building these data sets, golden truth data sets. We run e-vals, verify them against the human output, and then try to align to make sure that the judge actually agrees

[12:24] with the human um and and they’re in agreement before we actually ship out uh a new evaluator. And these e-vals can then be used both in an offline testing as well as in an online testing manner. Um and this this is probably what I would say as an AI engineer is more and more of what the job is becoming. Um and so, what I’m going to leave you guys with is as an AI engineer, you’ve built this agent, you’ve built this agent to actually run, be always on, you

[12:58] run e-vals before you actually ship it into production. You can ship it, and then once it goes into production, the goal is to actually trace everything. And tracing everything now means not just tracing the agents, but also tracing the coding agents behind the agents that built this. So, you can trace um cloud code, you can trace cursor, you can trace codex, but all these coding agents can be traced so you can understand what happened um in the factory of agents that you all are

[13:29] building. And then these agents that all the traces can then also be evaluated online. So, there’s an offline evaluation when you’re actually testing what you’re what a new change is, but as it goes into production, these become your online evals that you’re running on top of the telemetry data. This for us ends up becoming the new data that then gets pulled back into the agents to read the telemetry data, the evals, and

[13:59] surface up kind of problems inside of the traces. So, the the system really becomes how do you go from collect data, eval that data, run agents on top of it so that you can find problems and figure out where the gaps are to actually improve improve your systems. So, if I go back to kind of the question that we started this whole thing with, it’s what does an AI engineer do? I mean, the gap between I think there’s a pretty big gap between what’s happening in the labs today and what’s

[14:29] happening with a lot of businesses. And some of it could just be the data inside of businesses are a lot more messy than what is very constrained and testable inside of a lab. But, AI engineers are kind of the the role to close that gap, and I would think it really starts with tracing everything, tracing the agents you’re actually building, running evals, so being able to learn how to test these test these products that we’re really building, and then how do you build a system so that agents can actually improve from the telemetry that’s

[15:02] actually being collected so that you’re no longer just building individual features, but you’re actually building the system to improve to improve your products. If you want to learn more, come check out we have a booth. You can check out Signal, learn more, but thank you so much for listening to us. >> [applause] [music] >> Hey.