O harness que todo programador deveria construir

Autoria: Cortes do Rafael Quintanilha · 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: português

Vídeo original: O Harness que todo programador deveria construir · Canal: Cortes do Rafael Quintanilha · 08:38 · Assistir no YouTube

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

Resumo

O vídeo explica como a IA está mudando partes do trabalho de engenharia de software, como escolher tecnologias, implementar e validar soluções, sem eliminar a necessidade de entender os requisitos e as implicações do software. O apresentador defende que programadores construam um harness pessoal que organize agentes, ferramentas e etapas de validação de acordo com seu próprio fluxo de trabalho. Ele dá exemplos de automatização de tarefas relacionadas a pull requests e issues, com revisão humana dos planos e resultados. Também sugere adaptar o modelo e as instruções à tarefa, mantendo o programador responsável pela qualidade do trabalho.

Pontos-chave

O trabalho de engenharia de software envolve entender problemas, escolher ferramentas e arquitetura, implementar, validar e iterar.
Modelos treinados em muitas code bases podem sugerir stacks e ajudar a trabalhar com linguagens diferentes.
A IA pode reduzir a necessidade de domínio dos detalhes de sintaxe de uma linguagem, mas não substitui a compreensão do software, dos requisitos e de suas implicações.
É possível usar IA para code review, testes end to end e testes com computer use.
Um harness pessoal pode conectar agentes a pull requests, issues e code bases para analisar tarefas e sugerir planos.
A validação humana continua importante: o programador deve revisar as sugestões e corrigir o contexto que o agente deixou passar.
Erros recorrentes podem ser tratados criando uma skill para orientar o agente em situações futuras.
O harness pode escolher modelos e instruções diferentes conforme a tarefa, como trabalho de frontend ou backend.

Capítulos

Início	Capítulo	Resumo
00:00	O trabalho tradicional de engenharia de software	O apresentador descreve as etapas de entender o problema, planejar a solução, implementar, validar e iterar.
02:07	Como a IA muda o processo de desenvolvimento	A IA pode ajudar a escolher tecnologias, trabalhar com várias linguagens e apoiar a validação, sem dispensar a compreensão do software.
04:15	Construir um harness para o próprio fluxo de trabalho	O programador pode escolher suas ferramentas e criar automações pessoais para analisar pull requests e tarefas.
06:27	Revisão humana e personalização do harness	O agente pode analisar issues e sugerir soluções, enquanto o programador revisa o plano, cria skills e adapta modelos e instruções à tarefa.

Citações

Engenharia é resolver problemas com algumas ferramentas específicas. — 00:31

Esse harness para programadores é algo que você deveria aprender para fazer seu trabalho melhor e mais rápido. — 04:15

Você valida humanamente: lê e vê o que o agente esqueceu. — 06:58

Você precisa ter a sua própria fortaleza, as suas próprias ferramentas. — 08:04

Conceitos e entidades

Harness (conceito): Sistema de trabalho que reúne ferramentas, agentes e processos para apoiar as tarefas de programação.
IA (conceito): Tecnologia que, no vídeo, auxilia na escolha de tecnologias, na implementação e na validação de software.
skill (conceito): Instrução ou capacidade reutilizável que pode orientar o agente quando um erro ou situação se repete.
Claude Code (ferramenta): Ferramenta citada como uma das opções que uma equipe pode usar para trabalhar com IA.
Codex (ferramenta): Opção de ferramenta de IA mencionada para uso no trabalho de programação.
Cursor (ferramenta): Ferramenta citada como uma opção para o programador escolher em seu fluxo de trabalho.
Linear (ferramenta): Gerenciador de projetos mencionado como possível lugar para receber notificações de tarefas.
Jira (ferramenta): Gerenciador de projetos citado como alternativa para acompanhar tarefas.
Notion (ferramenta): Ferramenta mencionada como possível opção para gerenciar projetos e tarefas.
Asana (ferramenta): Gerenciador de projetos citado entre as opções para acompanhar tarefas.
GitHub Issues (ferramenta): Sistema de issues citado como fonte de tarefas que podem ser encaminhadas a um agente.
OpenCode (ferramenta): Ferramenta mencionada como uma opção que pode ser escolhida dentro do harness.
Opus (modelo): Modelo que o apresentador sugere selecionar para tarefas de frontend em seu exemplo.
GPT-6 Astra (modelo): Modelo que o apresentador sugere selecionar para tarefas de backend em seu exemplo.
Figma (ferramenta): Ferramenta de design que o agente pode consultar para validar o trabalho de frontend.

Tradução completa (pt-BR)

00:00 Então vamos dar um zoom aqui para falar sobre o harness para programadores, beleza? E aí, isso aqui eu posso falar com mais propriedade porque sou engenheiro de software de formação, tá? Se você não me conhece, trabalho com engenharia de software desde 2012. Sou formado em engenharia de software, estudei isso lá fora e trabalho com isso há muitos e muitos anos, tá? Então, essa aqui é a minha formação original: engenharia de software, tá? E aí, tipicamente, quando você é um engenheiro de software, o que um engenheiro de software tradicional precisa fazer? Então vamos

00:31 colocar aqui, ó: tradicionalmente, sei lá, ele precisava, né? Você quer construir um software, né? Eu sempre gosto de usar essa analogia: afinal, o que é engenharia? Engenharia é resolver problemas, e você resolve problemas com algumas ferramentas específicas. É a regra do jogo, é o que o jogo permite que você utilize. Então, um engenheiro de software vai usar software para resolver problemas. Um engenheiro naval vai construir navios, embarcações, para resolver problemas. Um engenheiro mecânico vai estudar a mecânica para resolver problemas naquele domínio e por aí vai, tá?

01:02 Então, o engenheiro de software precisa resolver problemas com software, tá? E o que esse engenheiro de software precisa fazer? Bom, precisa levantar os requisitos, né? Você precisa saber: cara, qual é o problema que está acontecendo aqui? O que eu quero resolver? Qual é a sua dor e como posso pensar numa solução para essa sua dor em particular, tá? Ele precisa planejar o stack, né? Ou seja, agora que já entendi qual é o seu problema e já pensei na solução, qual é o stack, quais são as ferramentas, qual é a linguagem de

01:33 programação, qual é o banco de dados, qual vai ser a arquitetura que vou usar para isso? Vai ser um app mobile, vai ser um site, um web app, vai ser um script? Como consigo resolver esse seu problema, tá? O engenheiro de software vai fazer tudo isso. Vai fazer, claro, a implementação, vai ter que validar e vai iterar sobre isso, tá? Vai iterar. É claro que aqui estou confundindo um pouco o trabalho do que seria um arquiteto com o de um programador, porque, na prática, você acaba tendo que fazer tudo, tá? Então, você vai pensar em criar MVPs, certo? Vai monitorar, vai

02:07 falar de novo com o usuário e ver o que ele achou, né? E vai continuar fazendo isso. Agora, pessoal, algumas coisas mudaram hoje com a IA. Por exemplo, a parte de planejar o stack, que antes demandava muito conhecimento para entender onde cada coisa quebra, né? Onde você pode usar uma tecnologia e onde aquela tecnologia não vai ser tão boa para você. Hoje, não é que isso tenha sumido; continua lá, claro, né? Se você pedir para a IA dizer qual stack vai usar e não entender nada, vai ficar meio vendido. Mas a verdade é que os

02:41 modelos, com os treinamentos que vêm recebendo em diversas bases de código, já meio que sabem ou já vão ter um bom plano para você logo de cara, tá? Então, não vai fugir muito disso, né? Você já consegue fazer coisas, já sabe mais ou menos no que tem que trabalhar. E tem outro detalhe também: antigamente, como você precisava fazer a implementação, cara, precisava entender. Então, pô, vou programar aqui, mas meu time só sabe Java e entendi que o melhor para programar aqui seria JavaScript, certo? Pô, mas meu time só

03:12 sabe Java, cara. E aí, como faço? O pessoal que trabalha com Java gosta de orientação a objetos, sei lá. Pô, o pessoal não faz isso em JavaScript, é uma bagunça, não tem tipagem. E aí você dá um jeito de levar aquele profissional para a melhor ferramenta, para a melhor tecnologia para aquele problema. Hoje em dia, com a IA, isso meio que acabou, porque a IA é proficiente em todas as linguagens. Então, você consegue escolher de fato a melhor linguagem e não precisa ter um especialista naquela linguagem. Repito, pessoal, saber é muito importante. Fazer um

03:45 código que você não entenda absolutamente nada, nada do que está acontecendo, abrir o código e dizer: “Cara, não entendo nada”. Obviamente, isso não está certo, mas você consegue se virar, né? Consegue seguir em frente e ter um produto funcional com um nível menor de conhecimento da linguagem. Não estou falando de não entender o software, de não entender as implicações, de não entender os requisitos. Estou falando da linguagem. Como faço um loop for em Rust? Como faço um loop for em Go? Como faço um loop for em Python? São detalhes da linguagem,

04:15 beleza? Hoje você consegue tirar seu projeto do papel sabendo menos, tá? Validar: validar é algo que hoje você também consegue fazer com a IA. Você consegue fazer code review, consegue fazer testes end-to-end, consegue pegar um computer use desses e testar seu projeto. E, claro, iterar: colocar tudo isso num loop, beleza? Então, esse harness para programadores é algo que você deveria aprender para fazer seu trabalho de engenheiro de software melhor e mais rápido. Por quê, pessoal?

04:48 Porque você vai entrar numa empresa e, se ela for boa e AI friendly, talvez deixe você usar o modelo que quiser. Quer usar Cloud Code? Pode usar. Quer usar Codex? Pode usar. Quer usar Cursor? Pode usar. Você escolhe onde se sente mais confortável. Na minha empresa americana, onde sou responsável por estabelecer as regras de como as pessoas vão trabalhar com IA, eu gosto de fazer isso. Cada um tem seu budget: você recebe 500 dólares por mês para gastar com IA. Escolha o que deixa você mais confortável. Não quero saber o que escolheu. Quero que o resultado seja bom. Essa

05:20 é a filosofia que gosto de aplicar nas minhas empresas. Pode ser que a sua empresa seja diferente, tudo bem. Mas aqui estamos trabalhando em qual seria a melhor forma de você usar IA no seu dia a dia. Então, dito isso, você vai receber um budget ou talvez a empresa já diga: cara, você tem esta assinatura do Cloud Code, por exemplo, tá? E você precisa, dentro daquele harness que recebeu para usar ou escolheu para usar, construir o melhor sistema de trabalho para você. Vai construir o que deixar você mais confortável, tá? Então, talvez aqui você faça um loop

05:52 de engenharia para ajudar a ver sempre que houver um comentário no seu pull request e pedir automaticamente para um agente seu implementar e depois validar e, sei lá, fazer o commit. Então, você cria um loop que permite acompanhar isso, ou um loop de engenharia que, quando você receber uma notificação, vai enviar uma mensagem no seu Linear, no seu gerenciador de projetos, né? Hoje o pessoal usa Linear, eu gosto bastante, mas também tem Jira, Notion, Asana, enfim, onde quer que você use para gerenciar seu issue

06:27 tracker, né? GitHub issues e por aí vai. Você vai receber essa notificação aqui e já vai cruzar os dados com, por exemplo, a base de código. Então, caiu um ticket para você aqui, ó, vou fazer o ticket ENG 1234. Aí meu agente já pega esse ticket, cruza com a base de código, analisa mais ou menos onde tenho que mexer — uma análise preliminar — e sugere: “Cara, vamos fazer isso aqui. A solução é fazer isso aqui, ó: solução”. E aí você valida de novo,

06:58 Valida humanamente, tá? Você lê, você vê: “Opa, pera aí, meu agente falou isso aqui, mas calma aí, agente, você esqueceu esta outra parte. Calma aí, agente, você esqueceu que aqui neste projeto a gente faz assim, e não assado.” E aí você entendeu: “Puts, ele está errando isso aqui toda hora, cara. Quer saber? Antes de partir para a implementação, vou fazer um desviozinho aqui e criar uma skill, criar uma skill, porque, da próxima vez que isso acontecer, essa skill já vai ser chamada aqui na solução, beleza?” E aí você ficou feliz com a validação, com o plano, e pediu para o seu agente implementar. Note: isso aqui é da sua empresa? Não, isso aqui foi você que

07:32 construiu para você. Você se tornou um engenheiro de software mais capaz fazendo isso aqui; você se tornou um profissional melhor e mais eficiente fazendo isso aqui. Ninguém pediu para você fazer isso. Talvez seu gerente, seu chefe, seu manager possa perguntar como você está usando IA. E você fala: “Cara, eu criei isso aqui para mim e tal, mas olha só, presta atenção, tá? Eh, estou participando da análise preliminar. Estou vendo que, quando ele implementa, ele cai aqui neste meu loop de validar e tudo mais. Estou olhando o PR, né? Então, nunca fico muito tempo sem responder aos meus

08:04 colegas.” E você construiu isso aqui para você. Então, precisa ter sua própria fortaleza, vamos dizer assim, suas próprias ferramentas. Você construiu o que funciona bem para você. E, claro, aqui você consegue fazer seu Harness decidir se talvez vai usar o Open Code, e aí você tem aqui um processo decisório. Na solução, se for frontend, aí você fala para ele usar o Opus. Se for backend, você fala para ele usar o GPT-6 Astra. E aí você, cara, você, porque sabe que eles vão bem assim. E aí, quando vai começar um trabalho de

08:38 frontend, aí você dá uma instrução. Pera aí, pera aí. Vai trabalhar com isso aqui? Eh, quero que você se conecte ali no Figma. Conecte-se ao Figma e sempre valide com base no Figma, porque é no Figma que meu designer trabalha. Então, pessoal, você vai ser capaz de trabalhar de uma forma muito mais eficiente se criar isso aqui para você. Seja dentro de um time de programação, seja para você mesmo, beleza?

Transcrição original

[00:00] Então vamos dar um zoom aqui para a gente falar aqui do harness para programadores, beleza? E aí eu, isso aqui eu posso falar com mais propriedade porque eu sou engenheiro de software de formação, tá? Se você não me conhece, eu trabalho com engenharia de software desde 2012. Eu sou formado em engenharia de software, estudei lá fora isso, trabalho com isso há muitos e muitos anos, tá? Então essa aqui é a minha formação original de engenharia de software, tá? E aí tipicamente quando você é um engenheiro de software, que que um engenheiro de software tradicional precisa fazer? Então vamos

[00:31] botar aqui, ó, tradicionalmente, sei lá, ele precisava, né? Você quer construir um software, né? Eu sempre gosto de usar essa analogia, que é assim, que que é a engenharia no final das contas, né? Engenharia é você resolver problemas e você resolve problemas com algumas ferramentas específicas. É é a regra do jogo, é o que que o jogo te permite utilizar. Então um engenheiro de software vai usar software para resolver os problemas. Um engenheiro naval vai construir navios, embarcações para resolver o problema. Um engenheiro mecânico vai estudar a mecânica para resolver problemas naquele naquele

[01:02] domínio e por aí vai, tá? Então o engenheiro de software ele precisa resolver problemas com software, tá? E aí o que que esse engenheiro de software precisa fazer? Bom, ele precisa levantar os requisitos, né? Você precisa saber, cara, qual é o problema que tá acontecendo aqui, né? O que que, o que que eu quero resolver, que, qual é a sua dor e como que eu posso pensar na solução para aquela sua dor em particular, tá? Ele precisa planejar o stack, né? Ou seja, agora que eu já entendi qual é o seu problema e eu já pensei na solução, qual o stack, quais ferramentas, quais, qual linguagem de

[01:33] programação, qual banco de dados, qual vai ser a arquitetura que eu vou usar para isso? Vai ser um app mobile, vai ser um web, um web, um web app, vai ser um script? Como que eu consigo resolver esse seu problema, tá? O engenheiro de software vai fazer tudo isso. Ele vai fazer, claro, a implementação, ele vai ter que validar e ele vai iterar sobre isso, tá? Ele vai iterar. É claro que aqui eu tô confundindo aqui um pouco o trabalho do que seria um arquiteto com um programador, porque na prática você acaba tendo que fazer tudo, tá? Então, você vai aqui pensar em, né, criar MVPs, certo? Você vai é monitorar, você vai

[02:07] falar de novo com o usuário e ver o que que ele achou, né? E você vai seguir fazendo isso aqui. Agora, pessoal, algumas questões aqui hoje mudaram com a IA. Por exemplo, a parte de você planejar o stack, que era algo que antes, né, demandava muito conhecimento para você entender onde que cada coisa quebra, né? Aonde que você pode usar uma tecnologia, onde aquela tecnologia não vai ser tão boa para você. Hoje não é que ela sumiu, ela continua lá, claro, né? Se você pegar e pedir para a IA te dizer qual stack você você vai usar e você não entender nada, você vai ficar meio vendido. Mas a verdade é é que os

[02:41] modelos, com os treinamentos que eles vêm recebendo em diversos code bases, já meio que sabem ou já vão ter um bom plano para você de cara, tá? Então, não vai fugir muito ali, né? Você já consegue fazer coisas, né? Já sabe mais ou menos o que você vai você tem que trabalhar. E tem o detalhe também, tem o detalhe que antigamente, como você precisava dessa parte aqui de implementação que você ia fazer, cara, você precisava entender. Então, pô, eu vou eu vou programar aqui, mas o meu time só sabe Java e eu entendi que o melhor para eu programar aqui seria JavaScript, certo? Pô, mas meu time só

[03:12] sabe Java, cara. E aí, como que eu faço? O pessoal ali do Java gosta de orientação a objeto, sei lá. Pô, o JavaScript o pessoal não faz isso, é uma bagunça, não tem tipagem. E aí você vai lá e dá o seu jeito para pegar aquele aquele seu profissional, tentar colocar ele para a melhor ferramenta, para a melhor tecnologia para aquele problema. Hoje em dia com a IA, isso meio que acabou, porque a IA ela é proficiente em toda a linguagem. Então, você consegue escolher de fato a melhor linguagem e você não precisa ter um especialista naquela linguagem. Repito, pessoal, saber é muito importante. Fazer ele um

[03:45] código que você não entenda absolutamente nada, nada do que tá acontecendo, você abrir o código e falar: “Cara, não entendo nada”. Obviamente, isso não é certo, mas você consegue get away, né? Você consegue passar, ter um produto funcional com um nível de entendimento menor da linguagem. Eu não estou falando de você não entender o software, de você não entender as implicações, de você não entender os requisitos. Eu estou falando da linguagem. Como que eu faço um for loop em Rust? Como que eu faço um for loop em Go? Como que eu faço um for loop em Python? São detalhes da linguagem,

[04:15] beleza? Você consegue hoje, sabendo menos, conseguir tirar o seu projeto do papel. Tá? Validar, validar é algo que hoje você consegue fazer com a IA também. Você consegue code review, você consegue, eh, fazer ali testes end to end, você consegue pegar um computer use da vida e testar o seu projeto. E, claro, iterar, colocar tudo isso aqui num loop, beleza? Então, esse harness para programadores é algo que você deveria aprender para que fizesse o seu trabalho de engenheiro de software melhor e mais rápido. Por quê, pessoal?

[04:48] Porque você vai entrar numa empresa e, se a sua empresa for boa, AI friendly, ela talvez te deixe usar o modelo que você quiser. Quer usar Cloud Code? Pode usar. Quer usar Codex? Pode usar. Quer usar Cursor? Pode usar. Você escolhe onde você se sente mais confortável. Eu, na minha empresa americana, onde eu sou responsável por estabelecer as regras de como as pessoas vão trabalhar com IA, eu gosto de fazer isso. Cada um tem o seu budget, você recebe ali 500 dólares por mês que você pode gastar com IA. Escolha o que te deixa mais confortável. Eu não quero saber o que você escolheu. Eu quero que o seu resultado seja bom. Essa

[05:20] é a filosofia que eu gosto de aplicar nas minhas empresas. Pode ser que a sua empresa seja diferente, tudo bem. Mas aqui a gente tá trabalhando pro qual que seria a melhor forma de você usar IA no seu dia a dia. Então, dito isso, você vai receber ali um budget ou talvez a empresa já te dê, cara, você tem a assinatura aqui do Cloud Code, que seja, tá? E você precisa, dentro daquele harness que você recebeu para você usar ou que você escolheu para você usar, construir o melhor sistema de trabalho para você. Você vai construir o que te deixa mais confortável, tá? Então, talvez aqui você faça um loop

[05:52] engineering para te ajudar a ver sempre que tem um comentário no seu pull request e automaticamente você pedir para um seu agente implementar e aí validar e, sei lá, comitar. Então, você cria lá um loop que permite que você acompanhe isso ou um loop engineering que quando você receber ali vai pingar uma mensagem ali no seu linear, no seu gerenciador de projeto, né? O pessoal hoje usa linear, eu gosto bastante, mas também tem o Jira, também tem Notion, né? Também tem Asana, enfim, onde quer que você use para gerenciar o seu issue

[06:27] tracker, né? GitHub issues e por aí vai, você vai receber essa notificação aqui, você já vai cruzar os dados com, por exemplo, a code base, então caiu um ticket para você aqui, ó, vou fazer o ticket ENG 1234, aí o meu agente já pega esse ticket, ele já cruza ali na code base, ele já analisa mais ou menos onde eu tenho que mexer, análise preliminar, e aí ele te sugere: “Cara, vamos fazer isso aqui, a solução é fazer isso aqui, ó, solução”. E aí você valida de novo,

[06:58] valida humanamente, tá? Você lê, você vê: “Opa, pera aí, o meu agente falou isso aqui, mas calma aí, agente, você esqueceu dessa outra parte, calma aí, agente, você esqueceu que aqui nesse projeto a gente faz assim e não assado”. E aí você entendeu: “Puts, ele tá errando isso aqui toda hora, cara, quer saber? Antes de eu de partir para a implementação, eu vou fazer um detourzinho aqui e vou criar uma skill, criar uma skill, porque a próxima vez que isso acontecer, essa skill já é chamada aqui na solução, beleza?” E aí você ficou feliz com a validação, com o plano e aí você pede para o seu agente implementar. Note, isso aqui é da sua empresa? Não, isso aqui foi você que

[07:32] construiu para você, você se tornou um engenheiro de software mais capaz fazendo isso aqui, você se tornou um profissional melhor, mais eficiente fazendo isso aqui. Ninguém te pediu para fazer isso. Talvez possa te pedir o seu gerente, seu chefe, seu manager pode perguntar como que você tá usando IA. E você fala: “Cara, eu criei isso aqui para mim e tal, mas olha só, presta atenção, tá? Eh, eu tô participando da análise preliminar. Eu tô vendo, quando ele implementa, ele cai aqui nesse nesse meu loop de validar e tudo mais. Eu tô olhando, né, o PR. Então, eu nunca fico muito tempo sem sem responder os meus

[08:04] colegas”. E você construiu isso aqui para você. Então, você precisa ter a sua própria fortaleza, vamos botar assim, as suas próprias ferramentas. Você construiu o que funciona bem para você. E, claro, aqui você consegue fazer no seu Harness decidir se talvez você use o Open Code e aí você tem aqui um processo decisório. Na solução, se for front-end, aí você fala para ele usar o Opus. Se for back-end, você fala para ele usar o GPT-6 Astra. E aí você, cara, você porque você sabe que eles vão bem assim. E aí quando vai começar um trabalho de

[08:38] front-end, aí você dá uma instrução. Pera aí, pera aí. Vai trabalhar com isso aqui? Eh, eu quero que você eh se conecte ali no Figma. Se conecta no Figma e sempre valida frente ao Figma, porque é o Figma que o meu designer trabalha. Então, pessoal, você vai ser capaz de trabalhar de uma forma muito mais eficiente se você criar isso aqui para você. Seja dentro de um time de programação, seja você para você mesmo, beleza?