Pare de dar prompts — Greg Pstrucha, Sentry

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: Stop Prompting — Greg Pstrucha, Sentry · Canal: AI Engineer · 15:08 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de software com IA

Resumo

Greg Pstrucha defende que, em vez de repetir instruções ao agent, equipes devem codificar convenções e padrões de qualidade em regras persistentes no repo. Linters determinísticos podem verificar testes, tipagem, endpoints e exemplos usados em skills, mantendo esses elementos alinhados às APIs. Para critérios qualitativos, ele descreve políticas revisadas por subagents, sem substituir a revisão humana. Também alerta que métricas como cobertura de testes podem ser manipuladas e criar uma falsa sensação de segurança.

Pontos-chave

Troque prompts repetidos por regras e políticas persistentes no repo.
Use linters para codificar convenções e evitar erros recorrentes do agent.
Considere testes, tipagem estrita e linters como verificações determinísticas complementares.
Peça ao agent que analise transcrições, revisões de GitHub e feedback para sugerir regras de lint.
Valide exemplos de código em skills para que sejam executáveis e compatíveis com o schema OpenAPI.
Use políticas e subagents para avaliar aspectos qualitativos que não podem ser expressos facilmente em linters.
Mantenha a revisão humana: o objetivo das políticas é elevar o padrão do código, não eliminar code review.
Tenha cuidado ao otimizar métricas numéricas, como cobertura de testes e complexidade ciclomática.

Capítulos

Início	Capítulo	Resumo
00:00	Pare de repetir prompts	Greg apresenta o problema de corrigir repetidamente erros de código do agent e propõe codificar as regras no repo.
03:16	Regras determinísticas e linters	A palestra aborda testes, tipagem e linters, destacando como regras automatizadas podem impedir erros recorrentes.
06:30	Alinhar endpoints, schemas e skills	Exemplos da Sentry mostram linters verificando endpoints e exemplos de código para mantê-los alinhados ao OpenAPI schema.
10:54	Políticas para critérios qualitativos	O palestrante descreve políticas avaliadas por subagents para revisar aspectos que não são facilmente verificáveis por linters.
14:07	Os limites das métricas numéricas	Greg alerta que agents podem otimizar métricas como cobertura de testes sem melhorar a qualidade real do código.

Citações

Você deve parar de dar prompts e começar a codificar as regras que o agent deve seguir. — 02:12

Peça ao agent para analisar suas transcrições e revisões e tentar codificar quais feedbacks podem virar regras de lint determinísticas. — 05:24

Quando a API muda, não precisamos atualizar as skills do agent o tempo todo: elas são mantidas em sincronia pelos linters. — 10:22

Peça ao agent que crie linters e políticas. Experimente e faça o repo lembrar. — 15:08

Conceitos e entidades

Greg Pstrucha (pessoa): Engenheiro de IA na Sentry e palestrante que apresenta práticas para codificar regras de qualidade de software.
Sentry (empresa): Empresa cujo código e infraestrutura de debugging são usados como exemplos na palestra.
linters (conceito): Verificações automatizadas que codificam convenções e regras determinísticas para detectar problemas no código.
skills (conceito): Instruções e exemplos que orientam agents a interagir com APIs e realizar tarefas específicas.
OpenAPI schema (conceito): Descrição estruturada das APIs, usada para verificar se endpoints e exemplos correspondem ao comportamento declarado.
Grumpy engineer (ferramenta): Skill criada pelo palestrante que executa subagents para avaliar políticas de qualidade do repo.
taskless (ferramenta): Ferramenta mencionada que permite descrever em inglês a intenção de uma regra, a partir da qual um linter é derivado.
Django (ferramenta): Framework usado pela base de código da Sentry citada como exemplo.
DRF (ferramenta): Framework mencionado junto com Django como parte da stack da base de código da Sentry.

Tradução completa (pt-BR)

00:00 Tudo bem. [música] Olá, pessoal. Vou tentar falar o mais alto que puder para que dê para me ouvir bem em meio a toda essa agitação. Meu nome é Greg. Sou engenheiro de IA na Sentry. Trabalho na infraestrutura que impulsiona o agent de debugging da Sentry e tenho um título um pouco provocativo para esta apresentação, que diz para parar de dar prompts, mas não estou falando de engenharia de prompts. Vou me aprofundar um pouco mais nisso.

00:32 Quem ainda lê o código que a IA gera? Alguém? Não é uma pergunta capciosa, e não estou tentando envergonhar ninguém. Acho que depende do contexto. Leio o código quando é código da Sentry e preciso garantir que não estamos causando problemas em produção na Sentry. Mas, ao mesmo tempo, se estou trabalhando em um projeto paralelo, não faz tanta diferença ler cada linha de

01:03 código, e posso ser um pouco mais tolerante. Mas, de vez em quando, volto ao código de verdade porque quero fazer melhorias, e ele está ruim: é excessivamente defensivo, os testes são péssimos, não testam nada. Eu não gostaria mais de manter nem de trabalhar nesse repo. Então, o que você faz é conversar com o agent. Você diz: “Ei, você cometeu um erro. Isso está complicado demais. O código é defensivo demais. Você não precisa criar endpoints para tudo o que está fazendo, senão vou ter que manter isso para sempre.”

01:37 Tive que remover muitos palavrões deste slide, porque nas minhas transcrições originais há muita, muita irritação. Geralmente, são erros muito básicos que os agents cometem quando você não estabelece nenhuma proteção, e isso simplesmente me deixa furioso. Então você faz isso, e o agent diz: “Você tem toda a razão. Deixe-me corrigir.” Ele vai executar e tentar corrigir os erros. Passam-se cinco minutos, o contexto é compactado, e voltamos à estaca zero.

02:12 E agora você precisa se repetir, dar o prompt das correções de novo, colocar o agent de volta no caminho certo. Minha tese inteira para esta palestra, minha afirmação principal, é que você deve parar de dar prompts. Deve começar a codificar as regras que o agent precisa seguir. Regras e políticas que você quer estabelecer no seu codebase, que registrem tanto as convenções quanto a qualidade de código que você espera e da qual se orgulharia.

02:45 E quando digo que você deveria adicionar verificações determinísticas ou regras, o que vem à cabeça? >> Sim. >> O quê? >> Evals. Sim. >> Hooks. >> Hooks. Sim. As três coisas em que estou pensando, antes mesmo de chegar aos hooks e às evals — hooks e evals são importantes — são os testes, que são absolutamente a categoria a que isso pertence; os hooks são como você executa essas coisas no momento certo. Para mim, as três coisas que quero otimizar no nível determinístico são garantir

03:16 que tenho testes, garantir que há tipagem estrita e garantir que há linters. Essas não são afirmações completas e não bastam para fazer seu agent escrever bom código. Por exemplo, se você tirar daqui apenas que precisa implementar tipagem estrita, ainda estará numa situação ruim. Se você não desencorajar ou proibir uma forma de tipagem que elimina casos de borda que você realmente não quer ver, então

03:48 os comportamentos ou estados que podem ser representados no app levarão o agent a introduzi-los. Mas o que quero priorizar nesta palestra são os linters. Linters são uma maneira de codificar, de forma determinística, as regras que queremos aplicar ao codebase. Historicamente, antes da IA, quando você pensava em linters, a relação entre custo e benefício não era clara. Escrever um linter de verdade dava muito trabalho. Havia um custo de manutenção com o qual você precisava se comprometer, e precisava avaliar com que frequência surgia o problema que tentava detectar com o linter e se realmente valia a pena. E, se isso acontecia antes da chegada dos agents, quando eram pessoas trabalhando no meu codebase e a única coisa que eu fazia era, uma vez a cada três semanas, dizer às pessoas para usarem o componente certo do design system, talvez eu não precisasse de um linter para isso, certo? As pessoas têm memória, então, se eu disser isso uma ou duas vezes, geralmente vão se lembrar. Mas isso

04:20 muda completamente neste novo mundo, em que quem escreve código não tem memória e vai repetir os mesmos erros várias vezes. Ao mesmo tempo, criar um novo linter é muito barato e fácil. Você pode simplesmente pedir ao agent para fazer isso, e ele vai ficar muito menos frustrado com as regras de lint que você está tentando escrever. Então, minha afirmação é simples: se você levar uma coisa desta palestra inteira, sobre a qual vou falar um pouco mais, é que, depois desta

04:53 palestra, você pode pegar seu laptop, ir até seu agent e pedir: “Olhe todas as minhas transcrições anteriores, veja minhas revisões no GitHub e o feedback dos bots e dos meus colegas. Tente codificar quais desses comentários correspondem a regras de lint de alta qualidade, determinísticas e capazes de detectar problemas para os quais, caso contrário, ficaríamos dando prompts repetidamente.” É algo que faço agora, e faço até com mais frequência, meio que de forma programada, para verificar se há coisas novas que ainda não registrei.

05:24 Aqui estão alguns exemplos do que quero dizer com regras de lint personalizadas. São regras que tentam registrar convenções que você quer no seu codebase. Há uma categoria bem simples delas: são as que vocês conhecem e escrevem há muito tempo. Coisas como querer remover instruções console.log de um projeto específico, ou garantir que, se tenho um design system ou práticas de React que quero seguir ou desencorajar, isso esteja codificado e seja imposto pelo linter. Essas são as coisas simples.

05:57 Mas acho que, com agents, estamos entrando em uma complexidade mais interessante. Podemos ir um pouco além. Aqui está um exemplo, um pouco complicado, mas vou explicá-lo. O codebase da Sentry é bem antigo. Usamos Django e DRF. Não temos tipagem estrita em todo lugar. Esse é um caso muito comum em qualquer codebase maduro, em que você não está na vanguarda da tecnologia. Mas ainda queremos melhorar a situação para os agents. Mais especificamente, havia muita discrepância entre o que o schema OpenAPI da Sentry dizia que ia fazer e o que ele realmente fazia, então começamos a introduzir regras de lint para isso.

06:30 A primeira regra de lint é: se algo é um endpoint, uma função de endpoint, precisa retornar um tipo de response, e esse tipo de response não pode conter nenhum tipo genérico, para que possamos inferir as informações reais do tipo. Segundo, se for um endpoint, você recebe aquele decorator de schema adicional para garantir que ele esteja documentado. E, terceiro, garantir que o tipo realmente produzido aqui corresponda ao que o schema OpenAPI

07:07 declara no fim das contas. Isso nos ajuda porque agora as APIs estão um pouco mais alinhadas. E isso nos leva a exemplos ainda mais insanos de linters. O agent da Sentry é um agent de debugging e precisa se comunicar bastante com a Sentry. Ele usa a telemetria da Sentry para depurar problemas e fazer RCA, ou seja, análise de causa raiz e soluções, tudo isso porque precisa

07:39 O esquema da API, no fim das contas, declara. E isso nos ajuda porque agora as APIs estão um pouco mais sincronizadas. E isso nos leva a exemplos ainda mais insanos de linters. Então, o Sir Agent é um agent de depuração e precisa conversar bastante com o Sentry. Ele usa a telemetria do Sentry para depurar problemas, fazer RCA (análise da causa raiz) e fornecer soluções com análise da causa raiz, tudo isso porque precisa

08:11 Para conversar com a API OpenAPI da Sentry, muitas vezes precisamos orientá-la, e fazemos isso por meio de skills. Muitas vezes, são endpoints antigos que não conseguimos corrigir facilmente e que têm algumas complexidades difíceis de descrever apenas no nível do próprio schema. Então, em vez disso, orientamos por meio de skills, o que é um padrão bastante comum no mundo dos agentes. Mas aqui está um exemplo de uma skill que explica como uma métrica deve ser criada na Sentry. Geramos muitas dessas skills e exemplos com blocos de código como exemplos de código que podem ser executados no sandbox pelo agent. E, na

08:46 tentativa original de fazer isso, a precisão do agent caiu significativamente porque muitos desses exemplos foram alucinados. Então, o primeiro verificador que criamos verifica se há um bloco de código dentro da skill: ele extrai esses blocos de código e garante que passem na verificação de tipos, que possam ser executados no nosso sandbox e que tudo o que declaram esteja de acordo com o schema da OpenAPI da Sentry. Isso ajudou. Mas o que o agent fez primeiro

09:16 quando tentamos gerar a skill de novo com essa regra foi dizer: “Ah, há erros nas regras de lint; vou remover os blocos de código”. E isso não era o que queríamos. Então dissemos: “Não, não, não, os exemplos têm que ficar em blocos de código”. Então ele colocou os exemplos de volta, mas removeu as crases, porque só verificamos as crases. Vamos corrigir o problema, certo? Então dissemos: “Não, não, não. Se parece código, tem cara de código, se tem sublinhados e parênteses, coloque isso em blocos de código”. Então eu

09:48 fiquei tipo: “Certo, você quer que eu coloque código em blocos de código. Vou descrever as APIs”. Então, agora, em prosa, ele começou a descrever o que as APIs deveriam fazer, mas cometeu um erro: referiu-se às URLs das APIs. Então removemos as URLs na verificação e ficamos nesse jogo de bater na toupeira por um tempo, mas, no fim das contas, acabamos com skills sincronizadas com o nosso schema da OpenAPI, e isso não foi tão caro de fazer. E temos — não vou dizer um modelo inquebrável —

10:22 mas temos um modelo em que, quando a API muda, não precisamos ficar atualizando as skills do agent o tempo todo. Elas ficam sincronizadas por meio das ferramentas de lint. E, quanto às mudanças em si, ou a como fazer isso, você pode usar qualquer ferramenta que já esteja usando: ESLint, Oxlint, Flake8, Clippy, ast-grep. O ast-grep é ótimo porque não depende de linguagem, então, sabe, unifica as ferramentas e dá aquela sensação reconfortante. Há várias ferramentas novas surgindo

10:54 que tentam abordar isso de uma perspectiva diferente. Um exemplo é Taskless, em que, em vez de escrever a regra de lint propriamente dita, você escreve o que quer que ela faça. Você escreve sua intenção em inglês e, então, a própria regra de lint é derivada disso. E a última coisa que vou repetir é: tente pedir ao agent as próprias regras de lint. Você vai se surpreender com o que ele consegue gerar. Mas isso é só metade do quadro. E se houver regras determinísticas

11:26 que não conseguimos expressar, que não podem ser expressas por meio de ferramentas de lint? Há muitas delas, certo? São todos tipos de medidas qualitativas. Por exemplo, você tem uma máquina de estados com apenas três estados e eu crio um pequeno PR para adicionar uma funcionalidade pequena, mas o número de estados aumenta para 10. Não sei como criar uma regra de lint para isso. Não acho que consiga fazer essa verificação de forma confiável. Posso criar medidas táticas pequenas, como não permitir mais de quatro estados, mas isso é

11:56 tudo inventado. Essa é a situação em que estamos falando de medidas qualitativas, e é aí que você usa sua experiência em engenharia ou, como o Twitter diria, seu gosto. Você simplesmente precisa rejeitar a mudança ou pode usar um agent LLM para fazer uma revisão e ajudar com coisas mais simples. Para dar um exemplo concreto, comecei a criar políticas

12:28 para o repo. Essas políticas dizem coisas como: não quero testes demais, quero testes mais robustos ou não quero código defensivo demais. Tenho certeza de que vocês já viram casos em que o agent tenta criar código para todos os casos possíveis, e o resultado são funções longas e desleixadas. Eu preferiria um código cujo sistema de tipos não permita representar estados indesejados. Então, criei essas políticas e depois criei uma skill que chamei de engenheiro rabugento.

13:02 Internamente, chamamos de Garfield. O funcionamento é assim: ela recebe todas as políticas e executa subagents, um para cada política. O subagent pode dar feedback ou não se manifestar. Repetimos esse processo — aliás, é o mais perto que vocês vão me ouvir defendendo loops. Repetimos até o agent não ter mais ressalvas e dizer: “Estou satisfeito com isso; validei que está tudo certo”. Só então leio o código. E, de certa forma, minha métrica de sucesso aqui é quanto estou

13:33 incentivando o agent a melhorar; quanto, quando reviso o código, penso: “Ah, isso não está ideal, mas consigo orientá-lo nessa direção”, sem precisar dar feedback muito básico o tempo todo. Ainda é algo qualitativo, mas o objetivo, por enquanto, não é eliminar a revisão de código. Essas coisas vão mudar à medida que os modelos melhorarem, mas, mais do que isso, o objetivo é elevar o nível mínimo e facilitar o trabalho com os agents daqui para a frente. Também há uma coisa que quero mencionar:

14:07 cuidado com o óleo de cobra. Estamos falando de como o difícil são as medidas qualitativas, e fiz experimentos tentando capturar uma medida qualitativa em uma métrica quantitativa. Dois exemplos concretos são a complexidade ciclomática e a cobertura de testes. A complexidade ciclomática é uma medida que indica o quanto o código é fácil de manter e testar, e tenta calcular isso com base em quantos desvios há no código e em quão profunda

14:38 é a pilha de chamadas. E a cobertura de testes, como vocês sabem, tenta indicar quanto do código está coberto por testes. O problema é que, quando você dá um número ao agent, ele vai otimizar para esse número. E foi o que aconteceu. Acabei com bases de código e projetos com cobertura de testes de quase 100%, ou até 100%. Mas os testes em si são ruins. Eles, por exemplo, verificam se há uma string específica

15:08 em uma saída específica do agent. Não estão medindo nada que tenha valor. E, pior, dão uma falsa sensação de segurança. Então, tomem cuidado com isso. Cuidado com as complexidades das métricas qualitativas de verdade. É isso. Meu chamado à ação para vocês é: depois disso, tentem pedir ao agent regras de lint e políticas e vejam se isso ajuda. Experimentem e façam o repo se lembrar. E é isso, meu tempo acabou. Obrigado.

Transcrição original

[00:00] All >> [music] >> right. Hello everyone. I’m going to try to speak as loud as I can so it’s reasonably good with all the all the commotion. Uh my name is Greg. I’m an AI engineer at Sentry. I work on the infrastructure that powers seir centuries uh debugging agent and I have a little rage baity title of the

[00:32] presentation that calls to stop prompting but I do not mean loop engineering. I’m going to get uh a little bit deeper here. Uh who still reads code that AI generates? Anyone? It’s not a trick question and I’m not trying to shame you. I I think it’s contextual. I read code when it’s sentry code and I need to make sure that we are not breaking the actual production for sentry but at the same time if I am working on a side project it doesn’t really matter uh to read every line of

[01:03] code and I can I can be a little bit more lenient with it uh but then every now and then I go back to the actual code I want to make improvements and um it’s bad it’s it’s overly defensive code it’s tests are crap they are not testing anything. Um, I would not want to maintain or work in that codebase anymore. So then what you do is you you talk to the agent. You say, “Hey, you’ve done a mistake. This is overly complicated. The code’s too defensive. Um, you don’t have to create endpoints for everything you’re doing, otherwise I

[01:37] have to maintain it forever.” And I had to remove a lot of swearing from this slide because in my actual transcripts, there is going to be a lot of a lot of rage. Usually those are very elementary mistakes that the agents are making if you don’t put any guard rails in place and um and that just outrages me. So then you do that, the agent says, “You’re absolutely right. Let me fix this.” And it’s going to run and try to fix the the mistakes. And five minutes pass and compaction of context happens. And we’re back to back

[02:12] to square one. And you would have to now repeat yourself, reprompt your fixes, reprompt the agent on the right track. And my entire thesis for this talk, my entire claim here is you should stop prompting. You should start codifying the actual rules that the agent should be following. um rules and policies that you want to establish inside your codebase that are going to capture both convention and the quality of code that you are expecting and would make you proud.

[02:45] And so when I say you would want to add deterministic checks or rules, what are you thinking of? >> Yes. >> What’s that? >> Evals. Yes. >> Hooks. >> Hooks. Yes. Um the three that I’m thinking of before I even get to hooks and evils, hooks and evils are important. Tests are absolutely the class of that hooks are how you run those things at the right time. Um to me the three things that I want to optimize on the deterministic level are making

[03:16] sure that I have tests, making sure that there is strict typing, making sure that there are there are splinters. Those are not total statements and they are not enough to actually get your uh agent to write good code. as an example, if you just take from this that you have to put strict typing in place, you will still be in a bad place. Um, if you don’t discourage or ban um a way of typing that removes edge cases you don’t really want to see, then

[03:48] the behaviors that or the states that are representable in the app are going to lead the agent to introduce them. But the thing that I want to predominantly focus on in this talk is llinters. Lintters are our way to codify um the rules in a deterministic manner that we want to um remove from the from the codebase. Historically like before AI when you think about llinters um the way that this worked is the trade-off wasn’t clear. Writing an actual llinter took a lot of work. um it

[04:20] was a maintenance cost that you had to sort of sign yourself up for and you had to consider how often the issue that you try to lint away comes up is it even worth it and if it’s if it’s pre pre- aents and those are humans that are working in my codebase and the only thing I’m doing is once every free week telling people to use the right component from the design system then I don’t necessarily need a llinter for that right and people have memory so if I tell them once or twice they will usually remember that. But then this

[04:53] shifts entirely into this new world where the things that are writing code do not have any memory and are going to make the same repeated mistakes over and over again. And on the on the at the same time to write a new lter is very cheap and very easy. You can just have the agent do that and it’s going to be much less frustrated with the actual lint rules that you’re trying to to write. So my claim for this is simple and if you take one thing from this entire talk that I’m going to yap about a little bit more is you can after this

[05:24] talk take your laptop go to your agent and ask hey look at all my past transcripts look at my GitHub reviews the feedback from the bots the feedback from my peers and try to codify which ones of those are actual high quality lint rules that are deterministic and will be able to capture issues that we otherwise reprompt all the time. Um, that’s something that I do now and I happen to do that even more often uh sort of on the schedule to try to see whether there are new things that I haven’t captured.

[05:57] So, here are some examples of what I mean when I say custom lint rules. Those are uh lint rules that try to capture conventions that you want in your codebase. There is like a whole simple class of them. Those are the ones that you know and have written for a long time. And those are things like I want to lint out console log statements from a particular project or I want to make sure that if I have a design system or react practices that I want to follow or discourage those are codified and are limited away. Those are the simple

[06:30] things but I think with agents we are getting into more interesting complexity. We can push this a little bit further. So one example here, this is a little bit of a tricky example, but um I’ll go through it. Sentry is a pretty old codebase. We are on Django, we are on DRF. We don’t have strict typing everywhere. This is a very common case for any mature codebase where you’re not going to be at the top leading edge of the technology. Um but we still want to improve the state of the world for for the agents. So concretely here um there is there was a lot of drift of what the open API schema

[07:07] for sentry said it’s going to do and what it did and so we started introducing lint rules for that. First lint rule is if something is a end point endpoint a function for an endpoint it needs to return a response type and within that response type there cannot be any types so that we can infer the actual information of the type. Second, if it’s a endpoint, you get that little extent schema decorator so we can ensure that it’s documented. And then third, enforce that the actual type being produced here agrees with what the open

[07:39] API schema at the end of the day um declares. And that helps us because now APIs are a little bit more in sync. And that gets us to even more insane examples of um of llinters. So sir agent is a debugging agent and it has to talk to Sentry a lot. It uses Sentry telemetry to debug and RCA issues and provide root cause analysis solutions all of that because it has to

[08:11] talk to open to um Sentry API we oftent times have to guide it and the way we do it is through skills. oftentimes those are old endpoints that we are not able to um easily fix and they have some complexities that are hard to describe on the level of schema itself. So instead we guide that through skills which is a pretty common pattern in the agentic world. But here is an example of a skill that tells how a metric should be created at sentry. We generated a lot of those skills and examples with those code blocks as the as the examples of code that can then be run in the sandbox by agent. And in the

[08:46] original attempt to do that, we lost the accuracy of the agent significantly because lots of those examples were hallucinated. So the first lintter we created was a llinter that says if there is a code block inside the skill, you got to extract those code blocks, you have to make sure the type check, they can run in our sandbox and whatever they declare agrees with open API schema from Sentry and that helped. But what what the f the first thing that the agent did

[09:16] when we tried to rerun the skill generation with that rule is oh there are lint rule errors let me remove the code blocks and that wasn’t very desired by us. So we said no no no examples have to be put in code blocks. So it put the examples back but it removed the bactics because only the bactics are linted. So let’s let’s fix the problem right. So we’re like, “No, no, no. If it looks like a code, smells like a code, if it has underscores and parenthesis, push those into codelocks.” So I was

[09:48] like, “Okay, so you want me to put code into codelocks. I’m going to describe the APIs.” So now in pros, it started describing what the APIs should do, but it did one mistake, which is it referred to the URLs uh of the APIs. So then we linted away the URLs and we played this little whack-a-ole for a little while, but at the end of the day, we ended up with skills that are synced to our open API schema and that wasn’t that expensive to do. And we have I’m not going to say unbreakable model,

[10:22] but we have a model where when API changes, we actually don’t have to follow up on the agent skills all the time. it it’s it’s kept in sync through the through the llinters. And when it comes to the actual movements or the actual how do we do this you can use any sort of tool that you’re using already es oxlin flake 8 clippy as grabb as grabb is great uh because it’s language agnostic so it kind of you know unified tooling warm fuzzy feelings about that um there is a bunch of new tools that are popping up

[10:54] that are trying to approach it from a different uh perspective one example is taskless where is instead of writing the actual lter you write what you want the llinter to do. You write your intent in English language and then the actual llinter is um derived from it. Um and then the last thing that I uh that I will repeat is try asking the agent for the actual lers. You will be surprised uh what it can what it can generate. But that’s only half the picture. What if there are rules that are deterministic

[11:26] cannot express um cannot be expressed through llinters? There is plenty of those, right? Those are all types of qualitative measures like you have a state machine with just three states and I created a small PR to add small functionality and ballooned up the number of states into 10. I don’t know how to lint against that. I don’t think I reliably can link against that. I can like create small tactical things like no more than four states, but it’s

[11:56] all It’s all made up. This is a this is the situation where we’re talking about qualitative measures and um this is where you are engaging your engineering experience or if tweet as as Twitter would say your taste um and you just have to decline it straight up or you can have an LLM agent that is going to do a pass and for simpler thing help you with that concretely here I’ve uh I’ve started to create policies

[12:28] for the repository and those policies are such as I don’t want too many tests, I want stronger tests or I do not want a code that’s too defensive. I’m sure you’ve seen those where every single possible case is try code by the agent and it’s it’s just sloppy long long functions. I would rather have code that in its type system does not allow to express states that are undesired. Um so I created those policies and then I created a skill that I called grumpy

[13:02] engineer. We call it Garfield internally and the way it works is it takes all the policies and run sub agents for each of the policies and the sub agent can either give feedback or stand down and we loop that and this is the closest you will hear me doing loops by the way. uh we will loop that until the agent stands stands down and says I I’m okay with that I validate that this is fine and only then I read the code and sort of my metric of success here is how much I’m

[13:33] casting up the agent how much when I’m reviewing the code I’m like oh yeah this is not ideal but I can I can steer it here and I don’t have to do very elementary feedback all the time it is still qualitative but the goal here isn’t to remove the code review quite yet you So this things will change as models get better but more so to raise the floor and make it easier to um to work with the agents uh as you as you’re going forward. There is also one thing that I want to mention that is

[14:07] um beware of a snake oil. We are talking about the tricky part being qualitative measures and I’ve done experiments where I tried to capture a qualitative measure in a quantitative metric. So two concrete examples one of them is um cyclomatic complexity and the other one is test coverage. Cyclomatic complexity uh is a measure that says how maintainable and testable the code is and it tries to base that on how many branches happen in the code and how deep

[14:38] the call stack goes and um and test coverage you know test coverage tries to tell you how much of the code is covered by test. Um, and the problem with that is when you give a number to the agent, the agent will optimize the out of that number. And it did. And I I got code bases, I got projects where I got to like a 100% or close to 100% of test coverage. But the actual tests are bad. They are like asserting particular string in

[15:08] particular output of the agent. They are not measuring anything of value. Um, and more so they are giving you a false sense of security. So be aware of that. beware of um the complexities uh of of actual qualitative metrics. Um and that’s it. That’s that’s my call. My call to action for you is after this try to ask your agent for llinters and policies and see whether that helps you. Um try things and make the repo remember. And that’s that’s my time. Thank you.