Engenharia de harness: como construir uma fábrica de software — Dru Knox, Tessl

Ver no idioma original →

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: Harness Engineering: How to Build a Software Factory — Dru Knox, Tessl · Canal: AI Engineer · 19:59 · Assistir no YouTube

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

Resumo

Dru Knox apresenta a fábrica de software como um sistema em que agents produzem o que é entregue aos usuários, enquanto a equipe de engenharia aprimora o próprio sistema. Ele descreve a engenharia de harness como a prática central para chegar a esse modelo, com loops internos, externos e meta que aumentam autonomia, automação e qualidade. Também aborda desafios de adoção, como a falta de tempo para melhorias e a dificuldade de tornar workflows e dados acessíveis aos agents. Por fim, mostra como a Tessl pretende apoiar esse processo com ferramentas para organizar workflows, automatizar tarefas e manter melhorias contínuas.

Pontos-chave

• Uma fábrica de software usa agents para produzir o que é entregue aos usuários; a equipe se concentra em aprimorar a fábrica.
• Autonomia, automação e qualidade são métricas distintas: um agent pode resolver tarefas sem correções frequentes, mas ainda exigir revisão humana.
• A meta é aumentar autonomia e automação sem reduzir a qualidade e, com o tempo, elevar a qualidade do produto.
• A engenharia de harness cria loops que ajudam os agents a trabalhar melhor e a corrigir erros recorrentes.
• O loop interno captura problemas durante o trabalho do agent; o loop externo executa verificações mais caras quando a PR é aberta.
• O meta loop observa logs, PRs, issues e feedback de usuários para evitar que erros se repitam.
• Um control plane torna legíveis as interações com agents e organiza issues, revisão de PR e distribuição de workflows.
• A integração de agents também exige resolver acessos, governança, documentação de processos e ambientes de execução.
• A Tessl oferece registro de skills, conectores e ferramentas de revisão, além de automações para manutenção de repositórios.
• Métricas úteis incluem reduzir intervenções humanas e comentários em PRs e aumentar PRs iniciadas sem input humano.

Capítulos

Início	Capítulo	Resumo
00:12	Contexto e definição de fábrica de software	Dru Knox apresenta o tema e define a fábrica de software como um sistema em que agents produzem o produto entregue aos usuários.
02:19	Autonomia, automação e qualidade	O palestrante diferencia as três métricas e explica por que uma fábrica pode permitir melhorias de qualidade e colaboração.
05:56	Engenharia de harness e seus loops	A engenharia de harness é apresentada como prática central, com loops internos, externos e meta para aprimorar o desenvolvimento.
09:06	Desafios de adoção	A palestra aborda a rápida mudança das práticas, a competição com o trabalho de entrega e a dificuldade de acessar informações úteis.
11:10	Camadas para aprimorar agents	Knox descreve o control plane, a integração dos agents e os loops de melhoria como áreas de trabalho da engenharia de harness.
15:16	Como a Tessl apoia o processo	A apresentação mostra recursos da Tessl para organizar skills, conectar issues e GitHub e automatizar revisão e manutenção.
17:53	Automação incremental e métricas	O palestrante apresenta automações e tarefas de manutenção e recomenda acompanhar intervenções humanas, PRs e qualidade.

Citações

Uma fábrica de software é qualquer sistema agentic em que todo o produto final que você está construindo e entregando aos usuários é criado por agents. — 02:19

Você pode ter alta autonomia, mas baixa automação, porque ainda não confia no sistema e revisa todo o código diretamente. — 03:21

O meta loop fica fora do processo de desenvolvimento. — 08:03

O que você vai querer priorizar é reduzir as intervenções manuais e os comentários humanos nas PRs. — 19:28

Conceitos e entidades

• Harness Engineering (conceito): Prática de construir e aprimorar loops que aumentam a autonomia, a automação e a qualidade do trabalho de agents.
• software factory (conceito): Sistema agentic em que agents produzem o produto entregue aos usuários e a equipe de engenharia trabalha para aprimorar o sistema.
• Inner loop (conceito): Loop rápido que ocorre enquanto o agent trabalha na PR e ajuda a detectar e corrigir problemas sem intervenção humana.
• Outer loop (conceito): Conjunto de verificações mais custosas, executadas quando a PR é aberta para reduzir o trabalho de revisão humana.
• Meta loop (conceito): Loop que analisa logs, PRs, issues e feedback para identificar erros e alimentar melhorias nos demais loops.
• control plane (conceito): Camada que organiza o início do trabalho por issues, a revisão e a distribuição de workflows para agents.
• Tessl (empresa): Empresa que oferece uma plataforma para habilitar agents e ajudar equipes a avançar em direção a uma fábrica de software.
• Dru Knox (pessoa): Apresentador identificado no título do vídeo como representante da Tessl.

Tradução completa (pt-BR)

00:12 Uma breve introdução. Meu nome é Drew Knox. Sou responsável por produto e design na Tessle. A Tessle é uma plataforma de habilitação de agents. Ajudamos você a passar da expansão de skills à construção da sua própria fábrica de software. Hoje, vou falar sobre algumas coisas. O foco principal será engenharia de harness, que vemos como uma espécie de nova disciplina do desenvolvimento agentivo, e sobre como você pode usá-la para avançar em direção a uma fábrica de software. Então, antes de começarmos, alguns

00:45 pré-requisitos. Esta é uma palestra um pouco avançada, no sentido de que, se você ainda não está usando agents de programação, o que vou apresentar provavelmente não é por onde você deve começar. Então, parto do princípio de que, se você trabalha com agents de programação, está acostumado a ter algumas sessões ao mesmo tempo. Você chegou a um ponto em que, para tarefas fáceis e talvez de complexidade média, os agents de programação frequentemente fazem a coisa certa. Esse é mais ou menos o ponto ideal para

01:16 começar a pensar em engenharia de harness, começar a pensar em uma fábrica de software. O que vou dizer aqui não se limita a isso, mas é aí que você vai obter os melhores resultados. Vou apresentar algumas coisas. Primeiro, quero definir fábrica de software e falar um pouco sobre por que você talvez queira construir uma. Em segundo lugar, vamos nos concentrar bastante em engenharia de harness, que é uma espécie de prática ou skill central que você vai usar para chegar a uma fábrica de software. Vamos falar sobre quais serão

01:47 os componentes nos quais você trabalha ao fazer engenharia de harness. Por fim, vou mostrar brevemente como o produto da Tessle pode ajudar você nessa jornada. Mas a maioria dos tópicos que vou abordar hoje funciona com qualquer stack. São, em sua maior parte, técnicas. A Tessle facilita sua aplicação, mas elas não são exclusivas da nossa plataforma. Certo. Parte um: fábricas de software. O que são? Não há uma definição rígida. Imagino que todos estejam tão frustrados quanto eu com a rapidez com que a terminologia muda

02:19 e se transforma no setor hoje. Mas, em linhas gerais, uma fábrica de software é qualquer sistema agentivo em que todo o produto final que você está criando e entregando aos usuários é criado por agents, e suas equipes de engenharia de software se concentram efetivamente em construir a fábrica. Então, elas trabalham para tornar a fábrica mais autônoma, mais automatizada e para elevar a qualidade do que ela produz. Vou explicar cada um desses termos daqui a pouco. Essa é, basicamente, a ideia central de uma fábrica

02:50 : todos na sua equipe acabam se tornando, na prática, construtores de ferramentas internas, e então vocês constroem um sistema que produz o seu produto. Mencionei três métricas principais. Elas são como os pilares que você precisa considerar ao construir uma fábrica de software, e seguem mais ou menos esta ordem. Autonomia é, basicamente, quanto de intervenção humana é necessário para chegar à resposta certa. Ou seja, quantas vezes você precisa corrigir o código ou orientar como o agent deve

03:21 construir. Automação… Ah, desculpe, inverti a ordem. Autonomia vem primeiro. É o quanto nós, humanos, precisamos corrigir. Automação é o quanto você pode deixar os agents executarem, certo? Quanto você precisa revisar ou confiar na solução antes de aceitá-la? Os conceitos parecem bem semelhantes, mas há uma diferença. Você pode ter alta autonomia, no sentido de que os agents frequentemente resolvem de primeira os problemas que você apresenta, mas baixa automação

03:51 porque você ainda não confia neles. Então, revisa todo o código diretamente. Verifica tudo manualmente. Portanto, são coisas distintas, embora obviamente relacionadas, certo? Primeiro, é preciso desenvolver a autonomia para depois avançar para a automação. A qualidade final, provavelmente o conceito mais autoexplicativo: quão bom é o produto que você está realmente produzindo para os usuários? Essas métricas são como as análises de usuários de sempre, a qualidade dos testes, a cobertura de testes etc.

04:23 À medida que você avança rumo a uma fábrica, vai melhorar a autonomia e, depois, aumentar a automação, mantendo a qualidade constante durante todo o processo; no fim, vem a recompensa. Por que você gostaria de ter uma fábrica de software? Porque, no fim das contas, acreditamos que você pode elevar a qualidade quando tiver uma fábrica. Vou falar um pouco sobre isso. Acho que a maioria das pessoas vê as fábricas como uma forma de entregar mais rápido. Dizem algo como: “Ah, sim, vai ter um pouco de coisa malfeita, mas, meu Deus, vocês vão lançar muito mais recursos;

04:53 o custo-benefício, o ROI, vai valer a pena.” Acho que esse é um fenômeno de curtíssimo prazo, certo? À medida que os agents começam a ser adotados e ficam melhores. Na realidade, sim, você vai passar a trabalhar em um ritmo mais acelerado com uma fábrica. Mas todas as equipes têm listas de pendências de correções de bugs ou melhorias que gostariam de fazer, mas simplesmente não têm tempo, ou explorações que gostariam de realizar. Com uma fábrica de software, a ideia de uma lista de pendências meio que desaparece. E, assim, você

05:25 simplesmente passa a ter muito mais capacidade para trabalhar na melhoria da qualidade dos testes e em refatorações arquiteturais. Na Tessle, acreditamos que, sim, no início da transição, você vai querer manter a qualidade constante ou talvez aceitar uma queda muito pequena, mas que a recompensa final deve ser uma qualidade melhor no código que você produz. Isso também é ótimo para os estilos de colaboração da equipe como um todo. Quando você passa a ter uma fábrica de software, fica muito mais fácil para pessoas que não ocupam cargos técnicos contribuírem com ideias. Então,

05:56 fica mais fácil explorar mais possibilidades e contar com mais perspectivas e contribuições, enquanto sua equipe de engenharia se concentra muito mais em construir o sistema subjacente que todos usam para lançar recursos para os usuários. Então, acho que, no fim das contas, isso leva a uma experiência de desenvolvimento mais dinâmica e inclusiva. Então, como chegar a uma fábrica de software? Engenharia de harness — como sinal de que os termos evoluem rapidamente, nas últimas semanas também começou a ser chamada de engenharia de loop. Isso

06:28 é realmente a disciplina central que você vai adotar para avançar rumo a uma fábrica de software. Em sua essência, engenharia de harness é o seguinte: mencionei que, na fábrica de software, você constrói seu produto. Você está construindo os loops que automatizam e melhoram a qualidade da sua fábrica. O que quero dizer com loops? Quais loops você pode estar desenvolvendo? Há três conceitos centrais, cada um correspondendo a uma determinada fase do

06:59 desenvolvimento. Primeiro, você tem o loop interno, que é o período em que o agent de programação está trabalhando em um PR, antes de abri-lo. Certo? São loops iterativos muito rápidos. Você quer que sejam baratos. Espera que o agent os execute o tempo todo. Melhorias aqui aumentam a autonomia. Eles ajudam a detectar problemas e corrigir o agent sem que você precise intervir. Quando o PR é aberto, você passa para o loop externo. É aí que você vai incluir verificações mais caras e exaustivas

07:31 que não faz sentido executar repetidamente enquanto o agent está iterando nos recursos, mas que incorporam verificações que, de outra forma, um humano teria que fazer para confiar no sistema. E, como são mais caras, mas eliminam o tempo de revisão humana, podem valer a pena, certo? É aí que você pode incluir algo como QA agêntico ou pedir para executar testes de mutação e verificar a qualidade do nosso conjunto de testes. São verificações caras que você quer executar uma vez, quando o PR é aberto, e depois fazer o agent iterar nos

08:03 resultados. Por fim, há o loop meta. É por meio dele que você vai impulsionar a qualidade. O loop meta fica fora do processo de desenvolvimento. Ele observa os logs dos agents de programação. Analisa PRs, seu rastreador de issues e o feedback dos usuários; basicamente, encontra erros que estão atravessando o pipeline e chegando aos usuários, ou que você precisou corrigir como humano, para impedir que isso aconteça

08:33 isso retroalimenta o loop interno e o externo para garantir que esse erro não se repita. Então, o loop externo é o que realmente, depois que você tem a infraestrutura para cada um desses loops, vai conduzir — ou, melhor, o loop de metal é onde você vai atuar para aumentar, até certo ponto, o quão nativa em IA é a sua operação. Você vai impulsionar isso investindo no seu loop de metal. Antes de entrarmos nos componentes, no que você faz para realmente conseguir isso, acho que, para ser totalmente transparente,

09:06 desde o início, engenharia de harness — pelo menos a engenharia de harness sem assistência — é difícil por alguns motivos específicos que, basicamente, têm a ver com a psicologia humana. Então, o primeiro — espero que esse problema desapareça com o tempo — é que essa é uma disciplina nova e está mudando muito rápido. Por isso, muitas equipes que começam com engenharia de harness acabam basicamente se tornando pesquisadoras de IA só para tentar acompanhar. Vocês leem artigos, acompanham blogs, criam boas práticas que ficam

09:37 desatualizadas na semana seguinte e, duas semanas depois, ficam ainda mais desatualizadas; e, na verdade, em algum momento, viram práticas a evitar, e você não quer mais adotá-las. Então, você vai dedicar bastante tempo e espaço para acompanhar como fazer engenharia de harness. Se quiser entrar nessa disciplina, precisa ter uma abordagem inicial para resolver esse problema. Como vai reservar tempo e espaço para acompanhar o conhecimento, que muda toda semana? O segundo motivo, e este, na minha opinião, é mais duradouro, é que a engenharia de harness é

10:08 fundamentalmente um trabalho não planejado. Então, você começa a lançar uma funcionalidade. Não tem como prever se os agents vão falhar, como vão falhar nem quanto tempo vai levar para corrigir isso. E todo esse trabalho que você vai fazer para tentar melhorar o agent compete com o lançamento de funcionalidades, certo? Então, isso vai atrasar a entrega delas. E todos sabemos que é uma escolha difícil, que nunca deixa de ser difícil. Ou você não faz esse trabalho e fica preso no máximo local em que o agent nunca melhora, ou faz e perde o prazo da

10:38 funcionalidade, e acaba em apuros; por isso, ninguém nunca faz esse trabalho. A última questão é que, depois de resolver esses problemas iniciais, como reservar tempo e espaço para a engenharia de harness, você vai descobrir que muitas das informações a que gostaria de ter acesso não estão disponíveis. Elas ficam escondidas nos logs locais do coding agent ou na máquina de alguém. Estão na cabeça de alguém. Muitos dos sinais que você quer observar para melhorar os agents exigem algum trabalho para transferir seus workflows para superfícies onde tudo fique salvo

11:10 e disponível publicamente para ciclos de otimização posteriores. Certo, deixando tudo isso de lado, quais são as partes em que você deve trabalhar ao fazer engenharia de harness? Dividi isso em três camadas. De forma alguma são termos padronizados, embora eu fosse eternamente grato se você quisesse me ajudar a torná-los padrão. A primeira camada — e esta é a ordem em que, na opinião da Tessl, você precisa trabalhar nelas — é acertar seu plano de controle. Mencionei que a maior parte dos dados aos quais

11:42 você quer ter acesso para melhorar os agents e avançar rumo a uma fábrica de software não é legível. Se você transferir seus workflows para, por exemplo, a Tessl, todo o trabalho começa como uma issue no rastreador de issues. Ela é enviada a um agent sem interface gráfica, executado em um ambiente isolado. O agent abre um PR, e então os engenheiros interagem por meio de comentários no PR. Assim, ainda há correção manual. Ainda há uma interface manual, mas agora todos os seus pontos de contato

12:12 com o agent são legíveis. Então, podemos — você pode — apontar ferramentas para eles, extrair essas informações e melhorar as coisas. Normalmente, há três coisas que todo mundo busca ao tentar configurar um plano de controle. Você precisa de uma forma de acompanhar issues e iniciar o trabalho do agent a partir delas. Também precisa de uma forma de revisar. A revisão de PR do GitHub provavelmente é a opção mais fácil. E precisa de uma forma de padronizar e distribuir workflows, playbooks e coisas que melhorem os agents. Normalmente, isso acaba sendo

12:43 algo como um registro de skills ou um repo compartilhado do GitHub, onde você publica skills que melhoram a qualidade dos agents. Em seguida, vem um grande apanhado de coisas que chamo de agentização. Se alguém já tentou transferir um projeto com muita configuração local para algo que outra pessoa consiga configurar e percebeu, horrorizado, que muitas dependências que você achava estar isoladas de forma organizada não estão, basicamente vai ter que passar pela mesma coisa com os agents. Vai haver todas essas coisas que você achava que seriam facilmente

13:14 acessíveis a um agent, certo? Como CLI, acesso à API, dar ao agent uma forma de clicar no seu produto para construí-lo. Prometo que é pior do que você imagina. Ninguém começa pensando: “Sim, sim, sim, isso não vai ser tão difícil para nós” e termina ainda dizendo isso. Então, há muitas coisas pelas quais você vai ter que passar. E esse provavelmente é o trabalho mais difícil de planejar; é mais como reservar uma ou duas semanas e simplesmente resolver tudo. Mas isso vai envolver coisas

13:44 como registrar no conhecimento da empresa como o trabalho é feito, quais são os workflows de vocês e assim por diante. Você vai precisar dar acesso a todos os serviços internos, o que vai levantar questões de governança e de acesso à API. Vai querer oferecer uma forma de acessar os logs de produção. E isso vai trazer toda uma série de questões próprias, como qual é a sua posição em relação à conformidade e coisas do tipo. Depois, vai precisar de um ambiente onde o agent possa executar o código que está rodando. Há infinitas outras coisas, mas geralmente são bem específicas de cada empresa, e

14:15 você vai resolvê-las à medida que tentar fazer os agents enviarem código sem a sua intervenção. Vai descobrir rapidamente quais são os problemas. Por fim, é aqui que você vai acabar passando a maior parte do tempo: nos ciclos de melhoria. São aquelas coisas que mencionei antes — os loops interno, externo e de metal. Estes são componentes que costumam fazer parte do seu loop de metal. Manutenção do repo: você vai querer coisas que examinem sua base de código todos os dias, todas as noites, toda semana, ou algo assim, para procurar problemas. Também vai querer playbooks para práticas comuns de

14:46 desenvolvimento. Por exemplo, como adicionar uma funcionalidade à sua CLI. Você vai querer encontrar uma forma de identificar tarefas repetidas e automatizá-las, idealmente da maneira mais rápida e fácil possível, porque, caso contrário, as pessoas não farão isso. E vai querer algo que avalie a qualidade dos resultados de forma consistente e leve melhorias e aprendizados de volta para o restante da sua base de código. Por exemplo: “Ah, vi que o agent cometeu este erro. Vamos atualizar uma skill em adição, tipo, o playbook que vocês têm para adicionar funcionalidades à CLI. Vamos atualizá-lo

15:16 para que isso não volte a acontecer no futuro.” A Tessl existe, de certa forma, para ajudar você a resolver essas três áreas do plano de controle. Como mencionei, tudo o que eu disse até aqui são apenas técnicas. Você pode fazer tudo isso por conta própria, se quiser. Há muitas ferramentas que fazem isso. Então, vou explicar um pouco como a Tessl pode ajudar você, se quiser usar nossos serviços. Para começar, por que você usaria nossos serviços? Nosso foco é tornar relativamente iterativo e sustentável chegar à vanguarda.

15:49 Então, tentamos fazer isso por meio de várias melhorias pequenas, em vez de uma grande empreitada que tenta resolver tudo de uma vez. Nossa solução já vem com tudo incluído. Resolvemos a lacuna de conhecimento dizendo que vamos acompanhar as novidades, e você terá uma experiência agentic que conhece as melhores práticas de engenharia de harness e se mantém atualizada em seu nome. Temos um compromisso real com a modularidade e a abertura. Não achamos que uma única empresa vá oferecer o melhor componente de cada parte de uma fábrica. Queremos garantir que você possa escolher e

16:19 escolher qual é a parte mais importante para a sua stack. E, como eu disse, nosso foco é facilitar as coisas. Então, temos ciclos automatizados que você pode instalar e simplesmente reagir às mudanças propostas. E realmente tentamos garantir que sejam apenas etapas incrementais, para que, daqui a seis meses, você pense: “Nossa, já chegamos a uns 40% do caminho para uma fábrica de software.” Nunca tivemos que parar nem atrasar entregas por causa disso. Então, o primeiro ponto em que a Tessl ajuda é na configuração do seu plano de controle. Temos um registro de skills onde você pode

16:50 publicar e versionar os workflows e as automações em que está trabalhando, com recursos de governança integrados, como revisões de segurança, revisões de qualidade e controles sobre quem pode publicar e atualizar cada coisa. Também temos conectores simples para conectar rastreadores de issues ao GitHub. No momento, estamos focados na integração do Linear com o GitHub. Assim, você pode basicamente abrir um ticket no Linear e fazer com que ele execute um workflow do GitHub, com mais conectores chegando em breve. Também temos um conjunto de ferramentas para revisão de código. Isso facilita a definição dos seus padrões para revisão de código agentic

17:22 e também para verificações mais específicas. Aqui vocês podem ver um exemplo de um workflow publicado no registro sendo analisado quanto à segurança e à qualidade, e também o quanto ele realmente melhora o resultado do agent. Depois disso, vou exibir um vídeo enquanto conversamos. Vamos ver como funciona. Temos uma experiência agentic chamada Tessl agent, que ajuda você a criar e, depois, manter seus ciclos de melhoria ao longo do tempo. Então, a

17:53 primeira coisa que fazemos é ajudar você a gerenciar essa mudança: como encontrar tempo para identificar tarefas repetidas e configurá-las para automação? O agent analisa PRs, issues e coisas do tipo, e identifica, por exemplo, que toda semana você procura testes instáveis. Por que não transformar isso em uma skill para o workflow e, depois, automatizá-lo com uma GitHub Action? Assim, ajudamos você a encontrar tempo para criar automações, um workflow de cada vez. A segunda

18:23 coisa é que oferecemos muitas tarefas de manutenção prontas para usar. Mencionei que você vai querer fazer análises semanais de aspectos como a qualidade da arquitetura, a duplicação de código, a qualidade dos seus conjuntos de testes e a existência de vulnerabilidades de segurança. Se você usar a Tessl, pode simplesmente instalar várias dessas ferramentas com um clique e obter melhorias semanais na sua base de código, sem nenhum esforço adicional. Por fim, oferecemos uma maneira de transformar qualquer skill em um workflow automatizado. Isso é feito por meio de um comando chamado Tessl launch, com o qual você pega uma sk

18:56 skill que formaliza um workflow. Depois, você pode escolher um agent de programação específico para executá-lo. O Tessl agent pode ser uma das opções. Mas, para a maioria das tarefas de programação, provavelmente você vai querer usar algo como Codex, Claude Code ou Gemini. Temos acesso a todos eles e vamos executá-los em um ambiente isolado com as permissões apropriadas. Eles podem rodar por bastante tempo. Terão um token do GitHub para abrir um PR e responder aos comentários à medida que você os deixar. Isso facilita muito a automação de workflows desse tipo. E, com tudo isso junto, fica muito fácil começar

19:28 e encontrar, uma por uma, oportunidades de melhoria, pegar um workflow, transformá-lo em uma skill, disponibilizá-lo para todo mundo e, então, colocar seus ciclos de melhoria em andamento. Ao fazer esse trabalho, você vai querer se concentrar em reduzir as intervenções manuais e os comentários humanos nos PRs. Essas são métricas que você pode acompanhar para saber o quanto avançou rumo a uma fábrica de software. Com o tempo, você vai querer ver mais PRs iniciados sem intervenção humana. Isso é um sinal de que você está automatizando mais. E, claro, você

19:59 vai querer primeiro manter a qualidade constante e, depois, tentar elevá-la. É isso. Se quiser saber mais, o estande da Tessl fica logo ali. Faça uma visita, venha falar com a gente. Adoraríamos conversar. Obrigado pelo tempo de vocês.

Transcrição original

[00:12] Quick introduction. My name is Drew Knox. I’m the head of product and design at Tessle. Tessle is an agent enablement platform. We help you go from scaling skills to building your own software factory. So today I’m going to talk about a few things. The core is going to focus on harness engineering which we see as sort of the new discipline of agentic development and how you can use it to ladder up to a software factory. So before we get started a few

[00:45] prerequisites. This is a bit of an advanced talk in the sense that like if you aren’t already using coding agents what I’m about to walk through is probably not where you want to get started. So, I’m sort of assuming that if you’re working with coding agents, you’re used to having a couple sessions at a time. Uh you’ve gotten to a place where coding agents will for like easy tasks and maybe medium complexity tasks frequently do the right thing. This you’re sort of at the sweet spot for

[01:16] starting to think about harness engineering, starting to think about a software factory. What I’m going to say here is not exclusive to that, but that’s where you’ll get your best results. So, I’m going to walk through a few things. First, I want to define software factory and talk a little bit about why you might want to build towards one. Second, we’re going to then focus a lot on harness engineering, which is kind of the core practice or skill that you’ll use to reach a software factory. We’ll talk about what are going to be

[01:47] the components you work on while you’re doing harness engineering. And finally, I’ll walk through how the Tesla product uh briefly can help you along that journey. But most of the topics I’m going to talk through here today work with any stack. They’re mostly techniques. Tesla makes them easy, but they’re not exclusive to us. Okay. Part one, software factories. What are they? There’s no strict definition. I’m sure you’re all probably as frustrated as I am with how quickly terminology changes

[02:19] and migrates in the in the industry today. But roughly speaking, a software factory is any agentic system where all of the end product of what you’re building and shipping to users is created by agents and your software engineering teams effectively focus on building the factory. So they work on making the factory more autonomous, more automated, and raising the quality of what it produces. I’ll go into each of those terms in just a second. That’s kind of the core idea of a factory

[02:50] though is everyone on your team effectively becomes internal tool builders and then you’re building a system that produces your product. So I mentioned three key metrics. These are sort of like the pillars you need to think about when building towards a software factory and they sort of go in this order. So autonomy is effectively how much human intervention do you need to get to the right answer. So how many times you need to correct the code or provide a nudge on how the agent should

[03:21] be building. Automation uh oh sorry I’ve gotten them flipped here. Uh autonomy is the first one. It’s how much do you have to do humans have to correct? Automation is how much can you let them run, right? How much do you need to review or build trust in the solution before you accept it? They sound quite similar, but there is a difference. You can have high autonomy in the sense that agents frequently are oneshotting the problems you’re giving them, but low automation

[03:51] because you don’t trust it yet. And so you’re reviewing all of the code directly. You are manually verifying everything. So they are distinct things that obviously have a connection, right? You have to build up autonomy first before you can move to automation. The final quality, probably the most self-explanatory, how good is the product that you’re actually producing for your users? These metrics are like your usual user analytics, your uh test quality, your test coverage, etc.

[04:23] As you work towards a factory, you’re going to go improving autonomy. then approving automation all while keeping quality constant and then the sort of payoff at the end. Why would you want a software factory is that ultimately we think you can raise quality once you have a factory. So talk about this a bit. I think most folks look at factories as a way to ship faster. They’ll say like oh yeah you’ll get a little bit of slop but my god you’ll you’ll launch so much more features like

[04:53] the cost return the ROI will be worth it. I think that’s a very shortterm phenomenon, right? As agents are sort of coming online and getting better. In reality, yes, you will move to higher velocity with a factory. But every team has backlogs of bug fixes or improvements that they wish they could be making that they just don’t have time to do or explorations that they wish they were they were doing. With a software factory, the idea of a backlog kind of goes away. And so you actually

[05:25] just have much more capacity to work on test quality improvements, architectural refactors. So at Tesla, we believe that yes, at first as you transition, you will want to keep quality constant or maybe like a very small dip, but that the ultimate payoff is you should see better quality uh in the code that you’re producing. Also, it’s great for your overall team collaboration styles. So once you’ve moved to a software factory, it’s much easier for people who aren’t in technical roles to contribute ideas. So

[05:56] it’s easier to explore more and to have more perspectives coming in and contributing while your engineering team is much more focused on building the underlying system that everyone is using to push features out to your users. So I think ultimately it leads to a more dynamic and inclusive uh development experience. So, how do you get to a software factory? Harness engineering, uh, as a sign of how fast terms evolve, it’s also started to be called loop engineering over the last couple weeks. Um, this is

[06:28] really the core discipline that you’re going to take to get towards a software factory. At its core, harness engineering is, you know, I mentioned the software factory is building your product. you are building the loops that automate and improve the quality of your factory. So what do I mean by loops? What are the loops that you might be working on? There are three core concepts each at maps to a certain phase of

[06:59] development. So you have your inner loop which is as the coding agent is working on a PR before it has put it up. Right? So these are very fast iterative loops. You want them to be cheap. You’re expecting the agent to run them all the time. Improvements here will drive better autonomy. The they help catch things and correct the agent without your uh coming in and human intervention. Once the PR is up, you move to the outer loop. So this is where you’re going to put more expensive exhaustive checks

[07:31] that don’t make sense to run over and over again as the agent is iterating on features, but they do encode things that otherwise a human would have to verify to build confidence in the system. And so this is because they’re more expensive, but they are taking away human review time. They can be worth it, right? So this is where you might put something like aentic QA or where you might say like run mutation testing to check the quality of our test suite. This is for expensive things you want to run once when the PR goes up and then have the agent iterate on on the

[08:03] results. Finally, you have the metal loop. This is where you’ll drive quality. So the metal loop sits outside of the development process. It observes your coding agent logs. It looks at PRs, your issue tracker, user feedback, and it’s basically finding mistakes that are making their way through the pipeline to your users or that you had to correct as a human to stop that from happening and

[08:33] it feeds back into the inner and the outer loop to make sure that that mistake is not made again. So the outer loop is what really kind of once you have the infrastructure for each of these loops, the outer loop or sorry the metal loop is where you’re going to be actually driving from a certain percentage of like how AI native am I? You’re going to be driving it up by investing in your metal loop. Before we get into like what are the components, what do you do to actually accomplish this? I think full disclosure

[09:06] upfront harness engineering at least uh raw unassisted harness engineering is hard for a few specific reasons that basically come down to human psychology. So the first hopefully this one will go away over time but it’s a new discipline and it’s changing very fast and so a lot of teams that get into harness engineering you basically become an AI researcher just to try and keep up. you’re reading papers, you’re watching blogs, you’re coming up with best practices that go

[09:37] out of date the next week and then two weeks after that and actually at some point they become antiatterns and you don’t want to do them anymore. Uh, and so there just like a lot of time and space you’ll devote to keeping up with how to do harness engineering. And so if you want to get into this discipline, you need to have a sort of upfront approach to how you’re going to solve this problem. How are you going to make time and space to keep up with the knowledge that’s changing every week? The second, and this one is more durable in my opinion, harness engineering is

[10:08] fundamentally unplanned work. So you will start shipping a feature. You have no way to anticipate will agents fail? How will they fail? How long is it going to take me to fix it? And all of that work that you’re going to do to try and make the agent better competes with shipping, right? So it will slow you down from getting the features out. And we all know that is just a perpetually hard trade-off to make. You either don’t do it and you get stuck in the local maxima of the agent never improves or you do it and you miss your deadline for

[10:38] the feature and you get in trouble and so no one ever does it. The final piece is that once you’ve solved these initial problems to like make time and space for harness engineering, you’ll find that a lot of the information you want access to is not available. it’s hidden away in local coding agent logs or it is on someone’s machine somewhere. It’s in someone’s head. A lot of the signals that you want to see to make agents better, you need to do some work to move your workflows onto surfaces where everything is saved

[11:10] and publicly available for later optimization loops. Okay, with all that aside, then what are the pieces that you should be working on as you’re doing harness engineering? I’ve broken it into three layers. These aren’t by any means standard terms, though if you want to help me make them so, I would be forever grateful. The first layer, and these are sort of like in the order you need to do them as far as Tesla is concerned, is you have to get your control plane right. And so I mentioned how most of the data that

[11:42] you want to have access to to make agents better and move towards a software factory is not legible. If you move your workflows into for example at Tessle we have all issue all work starts as an issue on the issue tracker. It gets sent to a headless agent running in a sandbox. The agent puts up a PR and then engineers engage with comments on the PR. So it still has manual correction. It still has manual interface but now all of your touch

[12:12] points with the agent are legible. So we can you can then point tools at them to pull that information down and make things better. Typically the three things that everybody comes to when they’re trying to set up a control plane. So you have some way of tracking issues and kicking off agent work from that. You’re going to have some way to review. GitHub PR review is probably like the easiest. Uh and then you’re going to have some way to uh standardize and distribute workflows, playbooks, things that make the agents better. Typically, that ends

[12:43] up being something like a skills registry or a shared GitHub repo where you push skills that improve agent quality. Next is a massive grab bag that I call agent it, which is uh if anyone’s ever tried to move like a project that had a lot of local config into something that someone else can set up and you realize with horror all of the dependencies that you thought were cleanly isolated and are not, you basically are going to have to go through the same thing with agents. There’s going to be all these things that you thought were easily

[13:14] accessible by an agent, right? Like CLI, API access, giving a way for the agent to click through your product to build it. I I promise it’s worse than you think. Like there’s no one who has come in thinking like, yeah, yeah, yeah, it’s not going to be that hard for us has left saying that at the end. And so there’s just like a lot of pieces you’ll work work through. And this is probably the most unplannable and most like spend a week, spend two weeks and just get it done. But it will come through things

[13:44] like writing writing down in your company brain how you get work done, what are your workflows, etc. You’re going to have to give access to all your internal services, which will require governance and like API access questions. You’re going to want to give a way to access production logs. Uh, and that’s going to have its whole own question of like what’s your compliance stance, things like that. Uh, and then you’ll need an environment where the agent can execute the code that it is running. There’s infinite more, but they’re generally pretty company specific, and

[14:15] you’ll just work through as you try to get agents to put code up without you intervening. You’ll quickly learn what are the problems. Finally, this is where you’ll end up spending most of your time. These are the improvement loops. So these are the things I mentioned before the like inner outer metal loop. These are components that tend to go into your metal loop. So repo maintenance. You’re going to want things that sweep your codebase every day, every night, every week, something like that to look for problems. You’re going to want playbooks for common

[14:46] development practices. So how to add a feature to your CLI. You’re going to want to find a way to identify repeated tasks and automate them and ideally as quickly and easily as possible because otherwise people won’t do it. And then you’re going to want something that looks at the output quality just on a consistent basis and brings back improvements and learnings to the rest of your codebase. So say things like, oh, I saw the agent made this mistake. Let’s update a skill on add like the playbook you have for adding features to the CLI. Let’s update

[15:16] that so it doesn’t make this mistake again in the future. So those three control planes Tessle sort of exist to try and help you solve them. As I mentioned, everything I’ve said before here are just techniques. You could go do them all yourself if you wanted. There’s plenty of tools that do that. So I’m going to talk a little bit through how Tessle will help you if you want to use us. To start, why would you want to use us? So we focus really hard on making it relatively iterative and sustainable to

[15:49] get to the cutting edge. So we try to make it like a bunch of small lifts rather than one massive snake eating the moose all at once. We’re batteries included. So we solve the knowledge gap by saying we will keep up and you will have an agentic experience that basically knows the best practices of harness engineering is kept up to date on your behalf. We have a real commitment to being modular and open. So we don’t think every component of a factory is going to be bestin-class with a single company. We want to make sure you can pick and

[16:19] choose what is the most important piece for your stack. And then like I said, we focus on making it easy. So we have automated loops for you that you can install and just react to the changes that are proposed. And we really try to make sure it’s just incremental steps so that you six months later like, oh wow, we’re like 40% there to a software factory. We never had to stop and delay shipping or anything like that. So the first place that Tesla helps is in setting up your control plane. We have a skills registry where you can

[16:50] publish and version the workflows and the automations that you’re working on with built-in governance things like security reviews, quality reviews, controls for who can publish and update what. We also have easy connectors for issue trackers to GitHub. Right now we’re focused on linear to GitHub. So you can basically file a linear ticket and get it to run a GitHub workflow uh with more connectors coming soon. Uh and then we also have a suite of tools for code review. So this make it easy to set up your standards for agentic code

[17:22] review as well as more targeted checks. See here an example of something that like a workflow that has been posted to the registry being scanned for security quality uh and how much it actually improves the agents output. After this, I’m going to play a video while we talk. See how this goes. So, uh, we have an agentic experience called Tesla agent, which will help you with creating and then maintaining your improvement loops over time. So, the

[17:53] first thing that we do is we will help you with that change management of like how do I actually make the time to find repeated tasks and set them up in automation. So the agent will mine through PRs, issues, things like that and find like every week you do a hunt for flaky tests. Why don’t we just set that up as a skill for the workflow and then we’ll put it in automation on a GitHub action. So we help you actually make time to do the automations just like one workflow at a time. The second

[18:23] is that we come with a lot of out ofthe-box maintenance tasks. So I mentioned you want to have weekly scans for things like architecture quality, code duplication, uh how good are your test suites, do you have any security vulnerabilities? So if you use Tesla, you can just sort of like oneclick install a bunch of those things and just get weekly improvements to your codebase without any other effort. And then finally, we offer a way to turn any skill into an automated workflow. So it’s through a command called Tesla launch where you effectively take a sk a

[18:56] skill that codifies a workflow. You can then pick a particular coding agent that you want to handle it. Tesla agent can be one of them. But for most coding tasks you probably want to use something like codeex, cloud code, gemini. We have access to all of them and we will run them in a sandbox that has the appropriate permissions. Can be long running. Uh we’ll have GitHub token so that it can put up a PR and respond to comments as you leave them. Uh, so it just makes it really easy to automate workflows like that. And so with these things together, we just make it really easy to get started

[19:28] and just one at a time find an improvement, take a workflow, turn it into a skill, ship it to everyone, and then get your improvement loops going. The what you’re going to want to focus on as you’re doing this work is driving down manual takeovers, driving down human PR comments. So these are like metrics that you can track to see like how far am I towards software factory. And then over time you want to see more PRs initiated without human input. That’s a sign that you’re automating more. And then of course you

[19:59] want to first hold quality constant and then aim to drive it up after that. That’s it. If you want to learn more Tesla booth is just that way. Please give a scan, come over, see us. We’d love to chat. Um thank you all for your time.